Sanctions screening at instant-payment speed

Screening every SEPA Instant credit transfer against EU sanctions lists, in under ten seconds, end-to-end, including Verification of Payee and authorisation — that is what the Instant Payments Regulation now requires. Standard sanctions-screening engines were built around the rhythm of card and SCT settlement, where a few seconds of decision time was generous. The IPR has compressed that window by an order of magnitude. The architectural and tuning choices are the operational story of 2026.

1. What changed

The Instant Payments Regulation — Regulation (EU) 2024/886 amending Regulation (EU) 260/2012 — sets a hard limit on the time it takes for a SEPA Instant Credit Transfer to complete: ten seconds, from the payer’s instruction to the funds being available to the payee. Inside that envelope sit:

• Customer-side authorisation and SCA
• Verification of Payee — the IBAN-name check
• Sanctions screening of the payment
• Network settlement
• Funds availability at the payee’s PSP

For sanctions screening specifically, the IPR’s Article 5d introduces an important shift: PSPs must screen at customer onboarding and at least daily against updated lists, and they may rely on the customer-level result for individual instant-transfer transactions where the lists have not changed.

2. The shift from transaction-level to customer-level

Historically, payments were screened at transaction time: the payer’s PSP checked both parties (and intermediary fields) against sanctions lists before releasing the message. For instant payments inside SEPA, the IPR replaces that with a customer-level model:

• The PSP screens its customer base at least daily against the EU sanctions lists.
• The screening covers the customer’s identity, beneficial owners, and authorised representatives.
• Individual SEPA-only instant transfers between screened customers do not require a fresh transaction-level check.
• If a list update occurs, the PSP re-screens promptly and freezes any matched relationship.

For non-SEPA instant payments (correspondent transfers touching a non-EU institution, transactions involving non-euro currencies routed through SEPA Inst), traditional transaction-level screening continues to apply.

3. Why this changes the architecture

Traditional screening engines are tuned around a per-transaction stream:

• Each payment is parsed for screenable fields (debtor name, creditor name, address, BIC).
• Each field is checked against fuzzy-match indexes of sanction lists.
• Hits trigger an investigator queue.
• Latency is rarely a hard constraint.

Customer-level screening is a different operational pattern:

• The full customer master is screened on a schedule (at least daily).
• List updates trigger a delta-screen rather than a full re-check.
• The hot path of payment processing reads a precomputed “screened-clean” flag against the customer record.
• Latency on the payment-decision path drops to a single key-value lookup.

For PSPs whose customer-master systems already support fast lookups, the lift is moderate. For those whose KYC and sanctions data sit in separate systems with batch synchronisation, the IPR is an architectural prompt — the two need to converge.

4. Which lists, in what scope

EU sanctions lists are consolidated by the European Union in the Consolidated Financial Sanctions List (CFSL) maintained at EU level. Member-state national lists may apply alongside. For most PSPs:

• EU consolidated list — mandatory for every EU PSP.
• National lists — for example, the French Direction Générale du Trésor list applies to French PSPs in addition to the EU list.
• UN Security Council sanctions — implemented via the EU consolidated list; not a separate feed for EU PSPs.
• OFAC and other non-EU lists — a commercial expectation in many counterparty relationships, not an EU legal obligation.

The IPR does not change which lists apply; it changes how often you must screen against them.

5. The false-positive problem

Customer-level screening at scale produces false positives. A PSP with two million customers will see thousands of name-match alerts on every refresh — not because of true sanctions hits but because of name overlap with sanctioned individuals (common names, transliterations, partial matches).

The operational tooling matters more than the engine itself:

• Calibrated match logic — token-based comparison, transliteration handling, date-of-birth and place-of-birth disambiguation.
• Investigator-tier queues — alerts ranked by genuine match probability.
• Clean-record cache — once an alert is resolved as a false positive, the result is cached and only re-checked on relevant list change.
• Audit trail — every alert, every disposition, every override is persisted with the analyst’s identity.

6. Interaction with VoP

The same instant-payment envelope must accommodate VoP alongside sanctions screening. The two checks run in parallel inside the 10-second window:

• The payer’s PSP queries the payee’s PSP for VoP — under 5 seconds round-trip.
• In parallel, the payer’s PSP confirms the customer-level screening result for both payer and payee references it holds.
• For SEPA-only instant transfers, no separate transaction-screen is needed.
• For non-SEPA or cross-currency edge cases, transaction-level screening runs alongside VoP within the same envelope.

7. The freeze obligation

When a customer-level screening returns a true sanctions hit:

• The PSP must freeze the relationship immediately — no inbound, no outbound transactions.
• The PSP must report to the relevant national competent authority for sanctions enforcement (in Spain to the SEPBLAC counterpart at the Treasury; in France to the Direction Générale du Trésor; in Germany to the BAFA / Bundesbank cooperation; etc.).
• The PSP must coordinate with its AML representative and counsel before any communication with the customer.

“Tipping off” rules — the prohibition on telling a customer that a sanctions or AML report has been filed — apply here as in suspicious-activity reporting.

8. FAQ

9. What to do, today

• Re-architect your sanctions screening around the customer master, with daily-or-better refresh cadence.
• Move the per-payment hot path to a single-key lookup against a precomputed clean-customer flag.
• Calibrate your match-logic for the 10-second envelope — false positives are a latency problem, not just a workload problem.
• Coordinate sanctions-screening alerts with your AML representative and your suspicious-activity-reporting workflow — the two pipelines share a regulator interface.
• Treat list-update events as triggering deltas, not full re-screens.

Related: Verification of Payee under IPR · What is the IPR report? · AML representative across the EU