Five Verification of Payee Integration Models Compared

The Verification of Payee (VoP) framework offers five distinct integration models for payment service providers (PSPs) to choose from, depending on their desired level of control and the specific requirements of their payment processes. These models differ in terms of ownership boundaries, responsibilities, and the extent of external service involvement in the payment authorization process.

The direct participant model fully controls the VoP flow by implementing both the requester and responder edges within the PSP itself. This includes consuming the Electronic Directory Service (EDS) data, resolving routes, operating the API client and server, performing name matching, and retaining the complete evidence chain. This model is suitable for institutions that already have payment-network infrastructure in place and require full visibility and control over every matching and disclosure decision.

However, the trade-off is the operational burden, which includes managing certificate lifecycles, directory updates, availability, counterparty interoperability, and ensuring client-side and server-side conformance.

In contrast, the routing-only RVM model offloads EDS routing and message forwarding to an external RVM while keeping the responder-side operations, such as name normalization and matching policy, within the PSP. This model is ideal when account data must remain within the PSP's control or when the PSP has already developed a robust name-matching service.

The responsibility for handling response budgets, exposure of routing evidence, and addressing potential issues with limited internal matching capacity falls on the PSP. However, the provider seam, which refers to the interface between the PSP and the RVM, must be carefully defined to ensure seamless communication and correlation of events throughout the VoP request and response lifecycle.

The full-service RVM model takes a step further by combining route resolution, message transport, and responder-side matching within a single external service provider. This model reduces the initial implementation scope for the PSP and centralizes scheme updates. The external provider becomes responsible for all aspects of the VoP process, from routing to matching, thereby simplifying the PSP's integration effort.

However, this model raises complex questions about data provenance, decision-making, and evidence retention. The PSP must ensure that it can verify the source data used to produce the match results, understand the version and policy of the matching algorithm employed, and maintain the ability to replay disputed requests if necessary.

Additionally, the PSP must have a clear understanding of how aliases, legal forms, transliteration, and joint accounts are handled by the RVM.

For PSPs with flexible architecture and the need to support multiple payment schemes or providers, the split or multi-RVM model offers a viable solution. This model involves separating the requesting and responding roles across different providers, with the PSP serving distinct communities or roles. By doing so, the PSP can maintain stability and consistency in its domain contract, policy, telemetry, and provider selection while allowing for swappable routing and matching adapters.

This approach enables the PSP to accommodate various schemes, providers, or even a hard exit requirement without compromising the integrity of its payment authorization process.

Ultimately, the choice of VoP integration model depends on a careful consideration of the trade-offs between control, complexity, and operational burden. PSPs must evaluate their existing infrastructure, expertise, and business requirements to determine which model aligns best with their strategic goals and risk tolerance. Regardless of the chosen model, the external boundary of the VoP process remains firmly within the PSP's control, ensuring accountability and the ability to reconstruct disputed results should the need arise.