Verification of Payee Is a Latency Problem Dressed as a Compliance Problem
The European Payments Council's Verification of Payee scheme became mandatory for PSPs operating in the euro area on 9 October 2025, under Article 5c of the revised Instant Payments Regulation (EU …
The European Payments Council's Verification of Payee scheme became mandatory for PSPs operating in the euro area on 9 October 2025, under Article 5c of the revised Instant Payments Regulation (EU 2024/886). Most implementation discussions treat it as a KYC-adjacent checkbox: collect the IBAN, call a directory, log the result. That framing is wrong. VoP inserts a synchronous external call into the credit-transfer initiation path, and the latency budget for SEPA Instant Credit Transfer (SCT Inst) is 10 seconds end-to-end. The VoP call is not outside that window — it competes inside it.
Where VoP Sits on the SCT Inst Timeline
SCT Inst requires the beneficiary PSP to confirm funds availability and credit the account within 10 seconds of the originating PSP accepting the transaction. The originating PSP's own processing — fraud screening, sanctions, liquidity checks, and now VoP — must complete before the payment instruction leaves the initiating side. In practice, originators target sub-2-second internal processing to leave headroom for network transit and the receiving-side window.
VoP adds a round-trip to the beneficiary PSP's VoP service or to a scheme-operated proxy directory. The EPC VoP rulebook sets a maximum execution time of 5 seconds for the requesting PSP to receive the response, with a target of 1 second or less. If the call is synchronous and blocking, it consumes 150–300 ms on a well-peered connection inside the euro area, but can reach 1–2 seconds under load or cross-border routing. That is not a rounding error in a 2-second budget.
The VoP call is not a pre-flight check that happens before the payment. It is part of the payment, and it needs to be engineered as such.
Match, Close-Match, No-Match: Three Different Control-Flow Branches
The EPC VoP scheme returns one of four outcomes: MATCH, CLOSE_MATCH, NO_MATCH, or VERIFICATION_NOT_POSSIBLE. Each has distinct handling requirements that affect both the UI layer and the ledger state machine.
MATCH is the clean path: the name provided by the payer corresponds to the name registered against the IBAN at the beneficiary PSP. The payment proceeds without additional payer interaction. CLOSE_MATCH is structurally more complex — the scheme returns a partial or phonetically similar name, and the originating PSP must present this to the payer and obtain explicit confirmation before proceeding. This introduces a human-in-the-loop step that can extend total initiation time by seconds or minutes, depending on channel. Any system that models VoP as a single boolean gate will mishandle this branch.
NO_MATCH requires the payer to be warned and to affirmatively override before the payment can proceed. Critically, the override must be logged and retained; under the Instant Payments Regulation, this record is relevant to liability allocation if the payment turns out to be authorised push payment fraud. VERIFICATION_NOT_POSSIBLE covers cases where the beneficiary PSP is not reachable or the account type cannot be checked. This is not equivalent to NO_MATCH — it should not trigger a fraud warning, but it does require a different disclosure to the payer.
Timeout and Fallback Handling
A VoP service that is slow or unreachable cannot be allowed to block all outgoing credit transfers. The EPC scheme rules permit originating PSPs to proceed without a VoP result if the beneficiary PSP's service is unavailable, provided the payer is informed that verification could not be completed. This fallback path must be implemented deliberately, not discovered during an incident.
The practical architecture decision is whether to treat VoP as a hard gate or a soft gate. A hard gate blocks the payment on any non-MATCH response including timeouts; a soft gate allows the payment to proceed with degraded disclosure. Regulators expect hard-gate behaviour for NO_MATCH, soft-gate behaviour for VERIFICATION_NOT_POSSIBLE. CLOSE_MATCH sits between them: it requires payer confirmation but does not prohibit the payment. These are three separate states in the state machine, and collapsing them is an audit finding waiting to happen.
Timeout thresholds matter. Setting the VoP client timeout at 5 seconds (the scheme maximum) means a slow beneficiary PSP can consume the entire internal processing budget. A 1.5-second timeout with a retry-once pattern is a more defensible default — consistent with the rulebook's sub-1-second target — provided the fallback disclosure path is correctly wired.
The Ledger Boundary Question
At Coreal, the VoP result is captured at the payment instruction layer, before the instruction crosses the ledger boundary. This is not arbitrary. The ledger records a settled or pending transfer; VoP is a pre-settlement verification, and its result — including the match type, the name returned, and any payer override — belongs in the instruction metadata, not in the ledger entry itself.
The distinction matters for reconciliation and for regulatory reporting. If VoP metadata is stored inside the ledger record, it becomes subject to the same immutability and audit constraints as the financial entry. If it is stored in the instruction layer with a foreign key to the ledger entry, it can be amended (for example, when a delayed CLOSE_MATCH confirmation arrives) without touching the settled record. The instruction layer also carries the liability-relevant override flag, which must be queryable independently of payment status for fraud reporting purposes.
| VoP Result | Payer Action Required | Payment Proceeds | Liability Flag |
|---|---|---|---|
| MATCH | None | Yes | No |
| CLOSE_MATCH | Explicit confirmation | Yes, after confirmation | No |
| NO_MATCH | Explicit override | Yes, after override | Yes |
| VERIFICATION_NOT_POSSIBLE | Disclosure only | Yes | No |
Caching and Idempotency
VoP results are not infinitely cacheable. The EPC scheme does not specify a mandatory TTL, but beneficiary PSPs can update their registered name data at any time. A cached MATCH result from 48 hours ago may be stale if the account holder changed their registered name or if the IBAN was reassigned. The practical approach is to treat VoP results as valid for the duration of a single payment session — typically the time between the payer entering beneficiary details and confirming the payment — and to re-query on any session resumption.
Idempotency is a separate concern. If a payer submits a payment, the VoP call completes, and the network drops the response before the originating PSP receives it, the retry must not issue a second VoP call that could return a different result and create a conflicting instruction record. The VoP request should carry a correlation ID that allows the originating PSP to detect and deduplicate retried queries, and the instruction state machine should checkpoint the VoP result before advancing to payment submission.
VoP is, in the end, a distributed systems problem with a compliance label on it. The 9 October 2025 deadline moved it from optional to mandatory, but the engineering constraints were always there.