Daily sanctions screening under the Instant Payments Regulation is an evidence problem before it is a latency problem

Instant payments provoke an understandable engineering instinct: how do we run every check in milliseconds? That question matters for fraud, payment execution and user experience. But it can hide a different operational challenge in the EU’s Instant Payments Regulation: the ability to show, on every relevant day, what customer-base sanctions verification actually happened.

The European Payments Council’s Verification of Payee material is useful context for payment teams, but Verification of Payee and sanctions screening are not the same control. One helps verify that the named payee corresponds to payment-account information. The other concerns restrictive-measures risk and the screening process around a payment-service user base. Treating one as a substitute for the other is a category error.

This article is an operational explainer, not legal advice. PSPs, EMIs and CASPs should validate their exact scope, timelines and jurisdictional obligations with counsel and the relevant authority.

Short answer

The durable answer is not “we ran a batch overnight.” It is a daily decision record: which population was in scope, which source versions were available, when the sweep started and ended, which records changed, which alerts were reviewed, which exceptions existed, and who accepted the outcome. A fast API is valuable only when the organisation can prove how it was used.

The wrong mental model: one screening call per payment

For conventional payment screening, it is tempting to attach a watchlist call to every transfer. In instant-payment flows, that model creates cost, latency and false-positive pressure. More importantly, it can make teams focus on the moment a payment is sent rather than on the maintained customer relationship.

An evidence-led daily model begins with a defined population: active payment-service users, legal entities, authorised representatives and beneficial owners where the firm’s policy requires them. The population cannot be an informal database query that changes every day without trace. It should be versioned or reconstructable.

What a daily screening record needs to show

1. The population

How many subjects were in scope? Which product states were included or excluded? Were closed accounts, dormant accounts, pending-onboarding cases and recently updated UBOs handled consistently? A daily total alone is weak if it cannot explain who was in it.

2. The source state

This is the most neglected field. “Screened against sanctions lists” leaves several unanswered questions: which lists, which successful ingestion timestamp, what happened if a source was unavailable, and whether a stale source was still being relied upon.

Source state should be part of the screening evidence, not an internal ingestion metric hidden from the control owner. A source that is delayed can be a reason to open an exception case, run a compensating control or hold a decision. It should never silently become a green result.

3. The run itself

Record the run identifier, start/end timestamps, engine/version configuration and population count. This allows an operator to distinguish an incomplete job from a completed job that found no candidates.

4. Delta and alert handling

The practical workload is not the entire population every day; it is the set of records that need human attention. A good system can identify new candidates, material changes to an existing candidate, changed ownership data and newly relevant source updates. It should also preserve known, well-supported false-positive decisions without automatically treating them as eternal truths.

5. Exceptions and approvals

No operational control runs perfectly every day. A provider delay, data quality problem, failed job or overloaded review queue may occur. The danger is not the exception itself. The danger is the exception that disappears into a monitoring dashboard without an owner, impact assessment, compensating action and closure record.

A useful daily workflow

This workflow is intentionally boring. That is its strength. It turns a regulatory conversation into a system that can be operated on an ordinary Tuesday.

Verification of Payee is not the evidence record

The EPC’s Verification of Payee scheme has API specifications, rulebooks and security requirements. It addresses a specific account-and-name verification interaction between payment-service providers. It may reduce certain payment risks, but it does not on its own answer the questions above about sanctions source state, customer screening or disposition rationale.

Teams should model these controls as related but separate:

• VOP: does the payee-name response align with the account information in the relevant payment flow?
• Sanctions-screening control: has the relevant customer/party population been assessed against the required restrictive-measures sources with an auditable review path?
• Transaction and fraud controls: does this payment’s behaviour, device, amount, pattern or route create a separate risk signal?

Joining all three into one opaque “risk score” makes incident investigation harder. Keeping their evidence distinct makes the final decision clearer.

Why this is a Verifex-shaped problem

Verifex should not market itself as a magic way to comply with the IPR. It can make a narrower, better claim: it can provide a reviewable screening and evidence workflow for the customer-base screening component, subject to the live source inventory and the customer’s own policy.

The product demonstration should show an actual daily sweep: a source update, the resulting delta, a known false positive, an analyst decision, an exception, and a compact Evidence Capsule export. That demo is more credible than a landing page full of regulation badges.

Sources

• European Payments Council: Verification of Payee rulebook
• European Payments Council: VOP updates effective 20 September 2026
• Verifex: daily sanctions screening evidence
• Verifex: Sources & Freshness