Verification of Payee (VoP) gives every integrating PSP a similar external exchange: look up reachability, send a request, receive a result and present it before payment authorization. Yet the ownership boundary can sit in five different places. A direct participant stack maximizes control. A routing-only RVM removes network work. A full-service RVM can take on matching. A split-provider model separates roles, while an internal orchestration layer makes providers replaceable. Choose by the failure you need to own, not by endpoint count. The decisive questions are who operates routing, who makes the match decision and who can reconstruct a disputed result.
The European Payments Council (EPC) defines requesting and responding PSP roles, the inter-PSP exchange and the EPC Directory Service (EDS). It also permits a PSP to use the services of one or more Routing and/or Verification Mechanisms (RVMs). An RVM can forward messages, and under an agreement it may perform VoP actions for a responding PSP. Delegation changes the implementation boundary. It does not make the participant's scheme obligations disappear.
At Pharos Production, this control-boundary problem is handled within payments and compliance engineering: route ownership, matching policy, payment-channel behavior and retained evidence are specified as one release contract before a provider is selected. That prevents an attractive API demo from deciding the operating model by accident.
The five models below are an architecture taxonomy, not five labels from the EPC rulebook. They describe where a PSP draws the line between internal systems and an external RVM or platform.
Compare ownership before products
| Integration model | PSP retains | External boundary | Best fit | Disqualifier |
|---|---|---|---|---|
| Direct participant | EDS use, routing, requester API, responder API, matching and evidence | none for core VoP exchange | infrastructure operator needing full policy control | no team for scheme upgrades, reachability and two-sided conformance |
| Routing-only RVM | payment channels, matching, source data, policy and evidence | EDS routing and message transport | PSP that owns beneficiary data and matcher behavior | provider seam cannot fit the response budget or expose route evidence |
| Full-service RVM | channel decision, risk acceptance and evidence review | routing plus responder matching | fast launch with limited internal matching capacity | matcher version, data freshness or replay cannot be inspected |
| Split or multi-RVM | normalization, policy, evidence join and failover logic | requester and responder paths split across providers | PSP serving several communities or separating roles | cross-RVM paths cannot be tested end to end |
| Internal orchestration layer | stable domain contract, policy, telemetry and provider selection | swappable routing and matching adapters | several schemes, providers or a hard exit requirement | traffic and change rate cannot justify another platform |
The external boundary moves across the five models. Accountability and release evidence stay with the scheme participant.
1. Direct participant: control at the cost of reachability work
A direct model implements the requester and, where applicable, responder edges inside the PSP. The PSP consumes EDS data, resolves routes, operates the API client and server, owns name matching and retains the complete evidence chain.
This model fits institutions that already operate payment-network infrastructure and must inspect every matching or disclosure decision. Provider exit is simple because there is no RVM in the core path. The operating burden is the price: certificate lifecycle, directory updates, availability, counterparty interoperability and client-side plus server-side conformance all remain internal.
Its API Reference Toolbox is open to PSPs not using an RVM, which makes this a real supported path rather than a theoretical architecture. Disqualify it when the team can build the API but cannot own scheme change and reachability as a continuing product.
2. Routing-only RVM: outsource transport, keep the matcher
Here the RVM handles EDS routing and message forwarding. The responding PSP still locates the account, normalizes the supplied name, runs its matching policy and returns the result. The requester still owns how Match, Close Match, No Match and verification-not-possible outcomes affect the payer's journey.
Routing-only is often the cleanest boundary when account data must remain inside the PSP or when internal teams have already built a defensible name-matching service. The vendor seam is narrower than in a managed model, but it sits inside the round trip. Correlation IDs, elapsed time, retries and late responses must survive both systems.
Define that seam with the Verification of Payee request and response lifecycle before selecting transport. If the RVM only shows an HTTP success rate, you still cannot prove which endpoint was resolved or whether a delayed result reached the payment channel.
3. Full-service RVM: faster delivery, deeper dependency
A full-service RVM combines route resolution, transport and responder-side matching. The PSP supplies account-holder data or an approved access path, then consumes a normalized result. This can reduce initial implementation scope and centralize scheme updates.
The hard questions move from API shape to decision provenance. Which data snapshot produced the result? Which matcher version and threshold policy ran? Can the PSP replay a disputed request? How are aliases, legal forms, transliteration and joint accounts handled? A status without those fields is an output, not an auditable decision.
The provider can perform the action, but the PSP still needs the policy for acting on its result. Reject this model when matching behavior is opaque, source-data freshness is unverifiable or the evidence export cannot be joined to the payer's authorization record.
4. Split or multi-RVM: flexibility creates a new test surface
A PSP may separate requesting and responding roles, preserve a domestic utility for one community or use more than one RVM for reach and resilience. This can respect existing investments and reduce dependence on a single route.
It also creates failure paths that single-provider tests miss. Jose-M (Chema) Buey described the early operating constraint after go-live:
"Initial challenges included cross-RVMs connectivity issues ... as well as incomplete or incorrect EPC Directory Service (EDS) setups"
Attribution: Jose-M (Chema) Buey, Director and Global Head of Client Account Services at Deutsche Bank's Corporate Bank, "Verification of Payee: Insights from Go-Live," European Payments Council, January 14, 2026.
That is why a multi-RVM test plan needs real cross-provider routes, not two isolated certifications. A request may pass each provider's local checks and still fail at directory configuration, route selection, timeout ownership or evidence correlation. Disqualify this model when nobody owns the joined incident timeline.
5. Internal orchestration: buy adapters, own the contract
The fifth model inserts a VoP domain layer between payment channels and direct or RVM connections. Channels call one internal contract. Adapters map that contract to a selected provider, while one policy layer records timing, result semantics, user treatment and evidence.
This becomes useful when a PSP serves multiple schemes, expects RVM changes or needs independent requester and responder providers. Provider exit becomes an adapter exercise instead of a change across every channel. The layer can also run shadow comparisons during a controlled migration without letting two responses reach the payer.
Do not build it merely to hide one API. Orchestration is another production system with configuration, on-call ownership, version mapping and failure modes. A single-country PSP with one stable RVM and modest change volume may be safer with a direct adapter owned by the payment service.
Rehearse both sides with one acceptance contract
Whichever model you choose, test the requester and responder as separate state machines, then join them through one trace.
Requester states:
INPUT_CAPTURED -> ROUTE_RESOLVED -> REQUEST_SENT -> RESPONSE_ON_TIME | TIMEOUT -> USER_INFORMED -> AUTHORIZATION_DECISION
Responder states:
REQUEST_ACCEPTED -> PARTICIPANT_CHECKED -> ACCOUNT_LOCATED -> INPUT_NORMALIZED -> MATCH_POLICY_EXECUTED -> RESULT_RECORDED -> RESPONSE_RETURNED
Every release candidate should answer five questions from retained evidence:
- Which route was selected?
- Did the trace retain the EDS record and its directory version?
- How much of the response budget did internal and external legs consume, including retries or a timeout?
- Which matcher and reference-data versions produced the result, and can operations reproduce their complete configuration?
- Can replay join the result to what the payer saw and decided?
At the time of this draft, the EPC lists VOP Rulebook v1.1 and its related 2026 API package as becoming effective on September 20, 2026. Treat that change as a migration target: run the same acceptance contract against the current baseline and the incoming version instead of silently changing adapters on the effective date.
Direct integration fits when control and internal operating capacity are both high. Routing-only fits when transport is commodity but matching is not. A full-service RVM fits when speed matters and its decision evidence is sufficient. Split providers only when role or reach differences justify the joined test surface. Add orchestration when provider replacement or multi-scheme normalization is a real roadmap item.
Pharos Production treats the chosen boundary as part of the payment product's release contract, because the payer sees one result even when several systems produced it. The best model is the smallest external boundary that preserves every decision your PSP must inspect, replay or replace.
Is your VoP integration tested from both sides, or is one side still treated as a vendor black box?
Sources
- Scheme baseline: EPC Verification Of Payee scheme overview, for the current rulebook and API-package transition
- RVM boundary: EPC RVM roles and qualification list, for participant, routing and delegated verification responsibilities
- Two-sided conformance: EPC VoP API Reference Toolbox test cases, for requester/client and responder/server coverage
- Directory contract: EPC Directory Service API specifications
- Legal basis: Regulation (EU) 2024/886
About the author
Dmytro Nasyrov. Photo supplied by the author.
Written by Dmytro Nasyrov, PhD, Founder & CTO at Pharos Production. He holds a granted patent for AI processing of medical images. He works directly on chain selection, key management and smart contract audit scope for FinTech and Web3 teams shipping under MiCA.
Top comments (0)