Sanctions Screening Under DORA: When Compliance Speed Meets Operational Resilience

The Compliance Function That Cannot Fail

Sanctions screening occupies a unique position in financial services: it is both a compliance obligation and a critical operational dependency. Every wire transfer, every SWIFT message, every customer onboarding must be screened against sanctions lists — EU restrictive measures, UN Security Council sanctions, OFAC, and national lists. Screening must occur before the transaction executes. Not after. Not in batch.

This creates a hard dependency: payment processing cannot proceed without sanctions screening. If the sanctions screening system is unavailable, payments stop. If it is slow, settlement SLAs breach. If it produces false negatives (missing sanctioned entities), the institution faces enforcement action and potential criminal liability. If it produces excessive false positives, operational costs escalate and customer experience degrades.

DORA classifies any ICT system supporting a critical or important function as subject to the full range of resilience requirements. Sanctions screening supports payment processing — one of the most critical functions in financial services. Under DORA, the sanctions screening infrastructure is a critical ICT system requiring:

• Art. 7 reliability and capacity
• Art. 8 identification and classification in the asset register
• Art. 9 protection and security
• Art. 11 business continuity planning
• Art. 24 resilience testing

The Operational Architecture of Sanctions Screening

Real-Time Screening Flow

The screening engine sits directly in the payment processing chain. Its performance directly constrains payment throughput. A screening engine that takes 500ms per transaction limits throughput to 2 transactions per second per processing thread. With instant payments requiring sub-10-second settlement, the screening step must complete in under 1 second.

Performance Requirements

DORA Requirements Applied to Sanctions Screening

Art. 8: Asset Registration and Dependency Mapping

Sanctions screening infrastructure must appear in the ICT asset register with full dependency mapping:

• Screening engine (in-house or vendor product)
• Sanctions list data sources (EU, UN, OFAC, national lists) — each is a data dependency
• List distribution infrastructure (how lists are received, parsed, and loaded)
• Integration points (APIs connecting screening to payment processing, customer onboarding, correspondent banking)
• Analyst workstations and case management (the human-in-the-loop for potential matches)

Each dependency must have a criticality classification derived from the BIA. The screening engine itself inherits the criticality of payment processing — typically the highest tier.

Art. 9: Security of Sanctions Data

Sanctions lists are public data. But the institution's screening rules, thresholds, fuzzy matching algorithms, and whitelist configurations are confidential — they reveal the institution's compliance strategy and could be exploited by sanctioned entities seeking to evade detection.

Art. 9 protection requirements for sanctions screening:

• Access control: Who can modify screening rules, adjust matching thresholds, or add to whitelists? These are high-risk changes requiring maker-checker approval.
• Integrity protection: Sanctions list data must be verified for completeness and authenticity. A corrupted or incomplete list creates false negative risk.
• Audit trail: Every rule change, threshold adjustment, and whitelist modification must be logged with actor identity and justification.

Art. 11: Business Continuity for Sanctions Screening

If the sanctions screening system fails, the institution faces a binary choice: stop payments (operational impact) or process payments without screening (compliance risk). Neither is acceptable.

Art. 11 continuity planning for sanctions screening requires:

• Redundant screening capability (active-active deployment, failover to secondary engine)
• Degradation strategy (if primary screening is unavailable, can a simplified screening process maintain minimum compliance while reducing operational impact?)
• Communication protocol (notify compliance team, regulators if necessary, and downstream correspondents if screening is degraded)
• Recovery procedures (how to screen transactions that were processed during any degradation period)

Art. 28: Third-Party Screening Risk

Many financial institutions outsource sanctions screening to specialized vendors (Refinitiv World-Check, Dow Jones, NICE Actimize, LexisNexis). This creates Art. 28 third-party risk with particular urgency:

The register of information must include sanctions screening vendors with full contractual detail per Art. 30.

Art. 24: Testing Sanctions Screening Resilience

Art. 24-27 testing must include sanctions-specific scenarios:

Performance testing: Validate screening latency under peak transaction volumes. Test with expanded sanctions lists (simulating a geopolitical event that adds thousands of entries simultaneously).

Failover testing: Disable the primary screening engine and verify automatic failover to the secondary. Measure failover time and verify zero transaction loss.

List update testing: Simulate a sanctions list update during peak processing and verify that new entries are screened against in-flight transactions.

False positive management testing: Simulate a spike in potential matches (as occurs during major list updates) and verify that the analyst review queue does not create a payment processing bottleneck.

Regulatory scenario testing: Simulate a major geopolitical event (new sanctions regime against a country with significant correspondent banking relationships) and validate that the institution can implement new screening rules within the required timeframe.

Sanctions Screening and Incident Management

A sanctions screening failure is an ICT incident under Art. 17. Depending on the scope and duration, it may qualify as a major incident requiring Art. 19 notification. The classification depends on:

• Duration of screening unavailability — minutes vs. hours
• Transactions processed without screening — if any, this is a compliance failure
• Customers affected — payment delays, blocked transactions
• Data integrity — were screening results accurate during the incident?

The EBA has emphasized in its ICT risk guidelines that payment-related ICT systems require the highest level of governance and resilience testing. ENISA threat landscape reports consistently rank payment infrastructure among the top targets for financially motivated threat actors.

Post-incident, Art. 13 requires learning and framework improvement. A sanctions screening incident should trigger:

• Root cause analysis of the screening system failure
• Assessment of whether the continuity plan activated correctly
• Review of the degradation strategy's effectiveness
• Updated risk assessment for sanctions screening infrastructure

The Compliance-Resilience Balance

The fundamental tension in sanctions screening is between compliance thoroughness and operational speed. More comprehensive screening (fuzzy matching, phonetic matching, alias checking) produces more false positives and takes longer. Less comprehensive screening is faster but creates compliance risk.

DORA does not resolve this tension — it adds a resilience dimension to it. The institution must not only balance compliance and speed but also ensure that the chosen balance is resilient: that it can be maintained under failure conditions, tested regularly, and documented with evidence.

Key Takeaways

• Sanctions screening is a critical ICT system under DORA, inheriting the criticality classification of payment processing.
• If screening fails, payments stop. Art. 11 continuity planning must include redundant screening capability and documented degradation strategies.
• Sub-second screening latency is required for real-time and instant payments. Art. 7 capacity requirements apply to screening performance.
• Third-party screening vendors are high-criticality ICT third-party relationships requiring full Art. 28 assessment, Art. 30 contractual provisions, and exit strategies.
• Testing must cover sanctions-specific scenarios: failover, list updates during peak processing, false positive spikes, and regulatory geopolitical scenarios.
• A screening failure is an Art. 17 incident — potentially major if transactions are processed without screening.

---

Resume en francais

Le criblage des sanctions est la fonction de conformite avec les exigences de resilience les plus strictes : chaque transaction doit etre verifiee avant execution, creant une dependance critique entre la conformite crime financier et le traitement des paiements. Sous DORA, l'infrastructure de criblage est un systeme TIC critique soumis a l'article 7 (fiabilite), l'article 8 (inventaire), l'article 9 (securite), l'article 11 (continuite) et l'article 24 (tests). Si le criblage echoue, les paiements s'arretent — l'article 11 exige une capacite de criblage redondante et des strategies de degradation documentees. Les fournisseurs de criblage tiers sont des relations TIC a haute criticite necessitant une evaluation complete Art. 28, des provisions contractuelles Art. 30 et des strategies de sortie. Les tests doivent couvrir des scenarios specifiques sanctions : basculement, mises a jour de listes pendant les pics de traitement, augmentation des faux positifs et scenarios geopolitiques. Une defaillance du criblage est un incident Art. 17 — potentiellement majeur si des transactions sont traitees sans criblage.