Marco BrondaniSecurity, AI risk and platform strategyBook a call

Worked example

EuroBank Sentinel

All four OSRA phases run against a live AI deployment at a DORA-regulated bank, published in full so you can read the output of an assessment before you buy one.

The scenario

EuroBank is a mid-tier European bank, €45B under management, headquartered in Frankfurt, regulated under DORA, the EU AI Act and ECB supervisory requirements. In Q3 2025 it deployed Sentinel, an AI transaction monitoring and fraud detection system replacing a legacy rules engine.

Sentinel handles roughly 2.1 million transactions a day. Flagged transactions enter a review workflow that can block payments, freeze accounts or escalate to compliance. Unflagged transactions pass straight through with no human review.

Three teams were involved in procurement. The CTO’s office handled infrastructure, compliance set the regulatory requirements, and an external consultancy selected and fine-tuned the model. Each team owns a piece. Nobody owns the whole thing.

On paper EuroBank looks solid: ISO 27001 certified, progressing toward ISO 42001, DORA procedures documented. The board receives a quarterly AI risk report and it shows green across every metric.

Phase 1: Substrate Mapping

Twenty-eight dependencies mapped across the model, compute, data, energy and contractual layers. Nineteen of them, 68%, are single points of dependency, and 21 have no fallback at all. Visibility breaks down as 12 visible, 10 known but unmonitored, and 6 invisible.

The finding that matters most is organizational rather than technical. Ownership is split three ways, and the split means nobody holds a complete picture of the substrate. Compliance does not know what GPU type runs inference. The CTO’s office does not know what the market data API depends on upstream. The consultancy built the fine-tuning pipeline and the preprocessing logic, and that knowledge lives entirely with them, with no documentation and no handover.

Phase 2: Failure Surface Analysis

Seven failure scenarios were run against the map. Four are critical severity, five involve silent failure, and three have no detection mechanism at all.

Base model silent update. The base model provider has pushed significant behaviour updates with minimal communication to downstream users. If the base model changes, the fine-tuned fraud layer on top of it may behave differently, and EuroBank has no way to know. They monitor flagging volume, not output distribution. A subtle accuracy shift would go undetected.

Sanctions data staleness. The market data API keeps responding while the data behind it goes stale, sanctions lists unrefreshed, matching accuracy quietly degrading. There is no error signal in that scenario. EuroBank monitors whether the API is up, not whether the data is fresh. Detection confidence: none. This is a criminal liability scenario in several jurisdictions.

Co-located monitoring. The dashboards and alerting meant to catch Sentinel failures are hosted in the same cloud region as Sentinel. If the region degrades, monitoring degrades with it, potentially masking the problem underneath. This is the most dangerous failure mode in the analysis: the system that detects failure fails at the same moment as the system it watches, and the dashboards keep showing something that looks roughly normal.

Knowledge concentration. The consultancy contract expires in 2027 with no knowledge transfer clause. If they become unavailable for any reason, EuroBank loses the ability to retrain, debug or modify the model, which makes the continuous model management the EU AI Act expects impossible to deliver.

The pattern is that the visible failures are not the dangerous ones. A regional outage is dramatic and detectable. The dangerous scenarios are the ones where the board report keeps showing green while the system quietly produces wrong outputs.

Phase 3: Trust Surface Audit

Six trust signals audited. Four are unverified or unverifiable, and five carry a scope mismatch, where the verification that does exist does not cover what the organization assumes it covers.

An uptime SLA guarantees that an API will respond. It says nothing about whether the response is correct, consistent with previous behaviour, or timely enough for real-time processing. EuroBank’s continuity planning treats uptime and working correctly as the same thing.

A model deprecation notice period is a policy statement on a website rather than a contractual commitment, and it covers full deprecation rather than behaviour-altering updates inside a version, which is the actual risk.

A vendor accuracy benchmark was reviewed but never independently validated on a holdout set of EuroBank’s own. The precedent is worth stating: a widely deployed proprietary sepsis prediction model claimed 76 to 83% AUC, and independent validation found actual sensitivity of 33%. More than 170 hospitals had deployed it without checking.

An ISO 27001 certificate certifies that an information security management system exists. It does not certify the controls on a specific workload, the security of an inference pipeline, model weight integrity in storage, or tenant isolation. EuroBank’s DORA evidence references that certificate as proof of adequate third-party security, and the certificate does not cover what EuroBank thinks it covers.

The finding that cuts deepest is the board report itself. It tracks uptime, flagging volume, false positive rate and vendor-benchmarked accuracy. None of those metrics would catch a silent model update, sanctions data going stale, monitoring degrading alongside the system, or hardware-level corruption. The report measures what is easy to measure, and the failure modes Phase 2 identified as most dangerous sit entirely outside it. The board believes it is exercising oversight. On this evidence it is not.

Phase 4: Convergence Mapping

Three critical convergences and two convergence points, ranked by weighted score.

AI model behaviour change

The base model can change without notification, EuroBank has no detection mechanism, and the lifecycle policy is unverifiable. The fine-tuned layer’s accuracy hangs entirely on base model stability.

Governance missed it because the EU AI Act Annex IV asks for documentation of the versions of relevant software, and EuroBank wrote down a version label. A version label does not guarantee behaviour, and no framework in use requires continuous monitoring of model behaviour between version changes.

Remediation runs from output distribution monitoring immediately, through an independent monthly validation pipeline at 30 days, to contractual change notification at 90 days, with model stability metrics added to the board report.

Co-located monitoring failure

Every Sentinel component and every monitoring system that would detect its failure sits in the same region. A regional degradation takes out both the patient and the doctor.

Governance missed it because DORA requires incident detection and EuroBank has it. What no framework requires is verifying that monitoring infrastructure is independent of the systems it watches. The architecture was designed for efficiency, same region and lower latency, rather than for the case where efficiency and resilience pull in opposite directions.

The question an auditor asks is how you would know if Sentinel were producing incorrect results. The answer is the monitoring dashboards. The follow-up is where those dashboards are hosted, and the conversation ends there.

Sanctions data integrity

A single point of dependency with no fallback, nobody monitoring data freshness or matching quality, no SLA on either, and no right-to-audit clause. The organization treats using a market-standard provider as evidence of adequate screening.

Governance missed it because using a market-standard provider feels like due diligence. DORA requires assessment of third-party concentration risk and exit strategies, and EuroBank has neither.

What the example demonstrates

Every finding here sits underneath a control environment that passes its audits. ISO 27001 held. The DORA procedures were documented. The board report was accurate about the things it measured. The exposure was in the substrate, which is the layer the governance frameworks assume and none of them verify.

That is the whole argument for running OSRA, and this is what the output of an assessment looks like.

Run it yourself

The methodology, the four practitioner templates, the 22-action catalogue and the scoring calibration are published in full under CC BY-SA 4.0.

OSRA on GitHub ↗

Applying it

Book a call

This is what an assessment produces. If you would rather have it run against your estate than run it yourself, book a call.

Book a call