Ultimate DORA Guide: How the Incident Rule Will Change the Stakes for AML and Sanctions
- FinScan
- 7 days ago
- 5 min read
When sanctions screening breaks, who do you tell?
For most financial institutions, sanctions screening failures have historically been handled quietly. A system slowdown, a temporary outage, or a delayed alert queue would trigger internal investigation, remediation, and perhaps a retrospective review. In most cases, these events never left the organization.
That model is no longer viable. This is especially true as SEPA Instant accelerates the speed of payments. With batch processing fading as the norm, the impact of a failed payment or a risky payment getting through sanctions checks is greater.
Under the Digital Operational Resilience Act (DORA), disruptions to critical systems, including sanctions screening, can now trigger mandatory incident notification to regulators, often within hours.
This is not a subtle shift. It fundamentally changes how firms must think about operational risk within AML and sanctions programs.
From Internal Issue to Regulatory Event
DORA requires firms to identify and report major ICT-related (that is, “Information or Communications Technology”) incidents that impact critical services or create significant risk.
Sanctions screening systems, particularly those tied to payments, sit squarely within that definition. If those systems fail, degrade, or behave unpredictably, the consequences are no longer contained internally.
To prevent such a risk, firms must rapidly answer a series of difficult questions:
When did the disruption begin?
Which services were affected?
Were transactions processed without proper screening?
What is the potential regulatory exposure?
If the answers indicate material impact, then the incident becomes reportable.
This introduces a new kind of pressure: understanding and articulating the impact in real time, in addition to fixing the problem.
What Counts as a “Material” Sanctions Disruption?
One of the more challenging aspects of DORA is its definition of “materiality.”
A disruption does not need to result in confirmed sanctions breaches to be significant. The threshold can be met if there is a credible risk that controls were compromised.
Consider the following scenarios that were once viewed as operational inconveniences:
A screening engine goes offline for several minutes during peak payment processing
Alerts are delayed due to system latency
A data feed failure results in incomplete screening inputs
A third-party provider outage interrupts sanctions checks
Under DORA, each of these could represent potential compliance exposure, depending on scale and timing. The focus shifts from confirmed outcomes to risk of impact, which is far harder to assess in the moment.
The Operational Challenge: Detect, Assess, Report
DORA’s incident notification requirements introduce a new operational burden for AML and sanctions teams.
Detection
Must be immediate. Firms need to know, in real time, when screening is not functioning as expected. This requires deeper system monitoring than many AML programs currently maintain.
Assessment
Must be fast. Teams must determine whether the disruption affects critical services and introduces compliance risk. Rather than a purely technical judgment, this requires coordination between operations, compliance, and risk.
Reporting
Must be structured and defensible. Regulators will expect clear timelines, impact assessments, and remediation actions, often under tight deadlines.
In practice, this means AML programs must look more like incident response frameworks than traditional compliance workflows.
When Third Parties Fail, You Still Own the Outcome
Many sanctions programs rely heavily on external providers, such as screening engines, data vendors, payment platforms, and identity services. DORA does not change that model, but it does change the accountability.
If a third-party failure disrupts sanctions screening, the institution is still responsible for detecting the issue, assessing the impact, and reporting the incident.
This creates a new level of scrutiny around vendor resilience and transparency. Firms must understand whether their providers are reliable, how they will behave under failure conditions, and how quickly issues can be identified and escalated.
Growing Interest in Screening Failover Strategies
This heightened accountability is prompting some institutions to take a close look at potential single points of failure within their financial crime technology stacks.
For organizations relying on a single sanctions screening platform, data provider, or screening service, a third-party outage can quickly become both an operational and compliance risk. As a result, some firms are exploring options to build their resilience, such as secondary screening environments, backup data sources, or alternative screening platforms that can be activated during a disruption.
Although DORA does not require firms to retain a secondary screening vendor, it does require them to understand critical dependencies and demonstrate resilience in their ability to support regulatory compliance. For sanctions screening programs, that means thinking beyond traditional disaster recovery plans and considering how critical controls will continue to operate if a key provider becomes unavailable.
A New Requirement: Explain the Failure, Not Just the Control
Perhaps the most significant change is what happens after the incident is reported. Regulators will expect firms to explain:
The root cause of the disruption
The sequence of events
The scope of impacted transactions or customers
The steps taken to mitigate and prevent recurrence
This requires detailed audit trails and data lineage that extend beyond normal operations into failure scenarios. But for many institutions, this is a significant gap. Many systems are designed to process and screen transactions efficiently, but not always to reconstruct events under stress with the level of clarity regulators now expect.
Why This Matters Beyond the EU
Although DORA is an EU regulation, its implications extend far beyond Europe.
In the UK, regulators including the Financial Conduct Authority (FCA) and Bank of England, continue to strengthen expectations around operational resilience, incident reporting, and third-party risk.
A similar trend is emerging across Asia and the Middle East. The Monetary Authority of Singapore (MAS) has established extensive technology risk management and operational resilience requirements, including expectations for incident reporting, third-party oversight, and availability of critical systems.
Across major GCC financial centers, regulators such as the Dubai Financial Services Authority and the Saudi Central Bank are increasing their focus on cyber resilience, operational continuity, and technology governance as part of broader financial sector modernization efforts.
The direction is clear. Regulators are converging on a model where disruptions to critical controls are treated as regulatory events rather than internal operational matters.
For global institutions, this creates a consistent expectation: sanctions controls must function effectively, as well as provide transparency and accountability into outages, delays, and potential compliance impact.
A New Standard for Accountability
Firms must be able to detect issues immediately, assess impact quickly, and communicate clearly under pressure.
DORA introduces a new kind of visibility into financial crime operations.
Sanctions disruptions that were once contained internally are now subject to regulatory scrutiny, often in real time. The challenge is no longer just preventing failure. Managing and explaining failure when it occurs is becoming paramount.
This raises the bar for AML programs in a fundamental way.
Firms must be able to detect issues immediately, assess impact quickly, and communicate clearly under pressure. They must understand their dependencies, maintain detailed audit trails, and operate with the assumption that any disruption could become a reportable event.
Because under DORA, the question is no longer just whether your sanctions controls work. It’s what happens—and who you tell—when they don’t.
