Overcoming sanctions screening challenge under the EU's Instant Payments Regulation

The European Union’s Instant Payments Regulation (IPR) has fundamentally changed the rules for moving money. All payment service providers (PSPs) in scope must be able to send and receive euro instant payments within 10 seconds, 24/7/365. This is arguably the most profound operational shift since the introduction of the Single Euro Payments Area (SEPA). It has transformed instant euro-denominated credit transfers from a premium, optional service into the mandatory baseline for all SEPA players.

One distinction matters: the 10-second window is the total budget for the entire payment, from initiation to funds landing in the recipient's account. Sanctions and fraud screening is just one step inside that journey — in practice, it must complete in well under a second, ideally under 100 milliseconds, since the rest of the 10 seconds is consumed by everything else the payment passes through to settle.

For compliance teams, this creates an operational paradox and puzzle to solve. Traditional sanctions screening – i.e., the process that pauses payments halfway to manually check names against watchlists is a no-go under this process architecture. It takes too long for a 10-second time window.

The European Union addressed this by explicitly decoupling sanctions screening from live transaction workflows for intra-EU instant payments. To prevent instant rails from grinding to a halt, the IPR introduces an important structural change in the approach: it grants a waiver for transaction-by-transaction screening for EU sanctions on intra-EU transfers. Instead, banks must screen their customer databases daily.

However, in shifting the burden from transaction-level blocking to continuous account-holder profiling, the IPR introduces complex technical, infrastructural, and regulatory compliance pressures. This creates compliance gaps and operational challenges, the results of which and the best solutions for which are yet to be seen. Below, we break down the practical screening options, weigh their pros and cons, and explore how a modern risk model can bridge the gap safely.

1. Navigating the Options - Database vs. Transaction Screening

To comply with the IPR while managing international compliance obligations (such as US OFAC or UK OFSI lists, which are not excluded from transaction screening requirements by the EU), financial institutions generally rely on two primary screening methods.

Option A: Database Screening (The IPR Mandate)

Instead of checking individual payments, the institution screens its entire customer database against relevant sanctions lists at least once every 24 hours, as well as immediately following any official list updates.

• Pros:
• Near-Zero Latency: Payments execute instantly because there is no compliance checkpoint built into the live transaction flow.
• Full IPR Compliance: Fully aligns with the EU’s vision of mutual trust across the SEPA network.
• Cons:
• The "Time Gap" Vulnerability: If a customer is sanctioned two hours after the daily batch run, they can freely send and receive instant payments until the next daily cycle runs.
• The Bulk False-Positive Backlog: While considered less disruptive to live payments, database screening is a large-scale process. A single watchlist update can trigger thousands of false positives overnight, creating huge operational backlogs and straining compliance teams.

Option B: Transaction Screening (The Traditional Model)

Every individual payment message is scanned in real-time, checking the sender and beneficiary names against watchlists before the funds clear.

• Pros:
• Real-Time Protection: Catches newly sanctioned individuals instantly, preventing money from moving immediately.
• Global Compliance Safety Net: Essential for cross-border transactions involving non-EU jurisdictions (like OFAC) that still demand active, real-time blocking.
• Cons:
• High Failure Rates: Traditional tools rely on "exact match" rules. They routinely trigger false positives over minor typos, hyphenations, or name inversions.
• Breaches the 10-Second Window: Resolving a false-positive flag manually takes minutes or hours, causing the transaction to time out and directly violating the IPR mandate.

2. Key Nuances and Strategic Discussion Points

Transitioning to an IPR-compliant framework requires compliance officers to look past the surface-level text of the regulation and evaluate several deeper operational realities.

The Myth of Equal PSP Compliance

The IPR’s "mutual trust" model assumes that because all PSPs must comply with EU sanctions regulations, they all do so with equal quality and speed. In reality, this is a risky assumption. Screening capabilities vary wildly across the industry. A Tier-1 bank might deploy advanced AI-driven delta screening within minutes of an EU list update, while a smaller, less tech-mature institution might rely on basic daily batch jobs that lag hours behind. If your counterparty bank is slow or ineffective, your institution is exposed to downstream risk.

Database Screening is Not an Operational Free Lunch

While database screening keeps the live payment rail clear, it shifts the operational burden rather than eliminating it. Because a database check scans millions of names against massive watchlists simultaneously, it creates a high volume of false positives all at once. If an institution's data hygiene is poor, a minor list update can generate a massive backlog of alerts that compliance staff must manually resolve, tying up resources and creating internal operational bottlenecks.

Reconsidering Transaction Screening via Advanced Technology

Many compliance teams assume transaction screening is entirely dead under the IPR because it risks delaying the 10-second timeline. However, with modern technology, strict parameterisation, and narrow risk scoping, real-time transaction screening can still play a viable role.

By applying smart rules—such as only screening specific ultra-high-risk corridors, skipping low-value retail transactions, and using sub-millisecond fuzzy matching—transaction screening can become fast enough to run in the background without breaking the 10-second limit.

Ultimate Liability Remains with the PSP

Despite the focus on speed, interoperability, and automated technology, one legal truth remains unchanged: payment service providers are strictly liable for any breach of sanctions, embargoes, and restrictive measures. The regulator will not accept a 10-second processing mandate as an excuse for allowing funds to reach a sanctioned entity. PSPs bear the full financial and reputational penalties of a failure, making a robust safety net essential.

3. Bridging the Sanctions Time Gap: The Transaction Risk Assessment Model

Because daily database screening leaves a potential visibility gap between list updates, banks need a way to protect themselves without slowing down transactions.

The solution is a Transaction Risk Assessment Model. This model does not stop transactions to look up names on a list. Instead, it evaluates the structural risk of the transaction in milliseconds using pre-calculated customer data.

This model operates on a weighted logic that can be expressed in a simple formula:

Transaction Risk Score = Entity Profile x W + Geographic Exposure x W + Behavioural Velocity x W

Where:

• Entity Profile: The pre-calculated risk score of the account holder, based on how clean their data is and whether they have matches against global watchlists.
• Geographic Exposure: Looks at the country of the counterparty bank and the destination routing.
• Behavioural Velocity: Checks if this transaction aligns with normal user behaviour (e.g., historical amounts, typical times, known counterparties).
• Weights (W): Adjusted dynamically based on the bank's risk appetite and risk scores.

How the Model Protects the Bank Mid-Flight

If the resulting risk score stays below a certain safety threshold, the instant payment executes immediately.

However, if a transaction occurs during that critical "time gap" – e.g., a client suddenly attempts to send an unusually large, uncharacteristic instant payment to a high-risk border corridor, the system triggers an instant response:

By utilising this risk assessment model, payment institutions can confidently bridge the processing gap, meet the sub-second technical requirements of the IPR, and prevent financial crime without disrupting the real-time ecosystem.

4. Implementing Compliant Process Architecture. The Synchronous vs. Asynchronous Separation Framework

For compliance officers tasked with building or redesigning the process environment to meet the IPR requirements, the design must cleanly isolate synchronous transaction handling from asynchronous master data management.

To balance regulatory compliance with sub-second performance, the engineering architecture should follow a decoupled processing model:

4.1. The Synchronous Path (Real-Time Execution Loop):

• Step 1: The payment message is received via an API gateway.
• Step 2: The engine pulls the pre-calculated, vectorised risk score for the account holder from an in-memory cache. If the account is clear, the system proceeds immediately.
• Step 3: For outgoing payments, the engine initiates a parallel VoP request to the beneficiary bank. It applies fuzzy token alignment to the response, confirms the match level, and passes the transaction to the clearing rails (such as TIPS or RT1).

4.2. The Asynchronous Path (Continuous Background Loop):

• Step 1: The system ingests global watchlist updates via real-time webhooks or streaming data pipelines (e.g., Apache Kafka).
• Step 2: A dedicated delta-screening engine processes changed entities against the customer database within minutes of publication.
• Step 3: If a match is found, the engine updates the customer's risk profile in the cache and triggers an administrative freeze, taking the account offline before any new transactions can be initiated.
• Step 4: The transaction history is fed into an offline analytics pipeline for model calibration, machine learning optimisation, and regulatory audit trail logging.

5. Essential Capabilities for Modern Sanctions Infrastructure

To successfully transition away from slow transaction screening, a financial institution's compliance platform must possess four non-negotiable capabilities:

• Fuzzy Name Matching: The system must recognise that "Mohammad Al-Shabbaan" and "Mhd Chabaan" are likely the same person, looking past word re-orderings and structural variations.
• Multilingual Transliteration: It must automatically translate non-Latin scripts (such as Cyrillic or Arabic) into Latin variants in real time to catch hidden names on watchlists.
• Typo Tolerance: It must use phonetic matching to align words that sound identical but are spelled differently due to keyboard errors or regional preferences.
• Sub-Second API Speed: To keep the total payment turnaround under 10 seconds, the compliance risk engine must finish its entire lookup and calculation in under 1 second (ideally under 100 milliseconds), requiring high-performance, in-memory databases.

Institutions that rely on legacy, exact-match engines or slow, disk-bound databases face significant operational hurdles. They will struggle with high false-positive rates, system latency penalties, and potential regulatory fines under the IPR’s strict penalty framework. 

Conversely, forward-looking payment service providers treat IPR compliance as an opportunity to modernise their infrastructure. By implementing advanced fuzzy matching engines, real-time transliteration tools, and scalable, decoupled microservices, these institutions achieve a clear competitive advantage. They protect their infrastructure from financial crime risk while delivering the seamless, real-time payment experiences that modern businesses and consumers expect.

The ultimate challenge of the IPR is balancing sub-second compliance speed with strict liability for sanctions breaches. Institutions could successfully solve the problem by shifting away from slow, reactive inline transaction screening to improved technology, a proactive, data-driven approach, and models.

About the author

 

Ivan Stefanov is the CEO and Co-founder of NOTO, with extensive experience in fraud prevention across financial services and the crypto industry. He previously held senior risk and fraud leadership roles at Groupon, Paysafe Group, and Crypto.com.

 

About NOTO

 

NOTO is a modular financial crime prevention platform that unifies fraud prevention and AML compliance in a single, enterprise-grade solution. Built to consolidate data across the customer and transaction lifecycle, NOTO delivers real-time monitoring, centralised risk insights, and alerts that help teams detect threats early and act fast.