An update of the interface specifications will be published in December to align with the EPC VoP Official field definitions coming from ISO 20022.

This API based service is provided to responding PSPs participating in the Worldline VoP Hub ecosystem. It allows responding PSPs to manage account holder identification data via the Worldline VoP Hub. It allows the Hub to use this locally stored data to provide answers to requesting PSPs, verifying the identity of payee for their payer user (Requester).

The data of the responding PSP is maintained and secured by Worldline on a mutualized infrastructure in the public cloud. Logical segregation and at rest data encryption is in place.

Features

The service, offers a CRUD real time interface to manage account holder identification data for the responding PSP.

The API supports storing multiple names, as well as additional identifiers when supported by the responding bank.

File based account data management

For clients wanting to avoid API integration, Worldline can put in place file based daily upload and updates of account holder identification data via CSV or JSON formats (see API format for bulk creation), transferred via dedicated SFTP channels, and via manual upload in our Backoffice in the future.  

API Security

• Authentication: The Worldline VoP Hub uses an authentication service that adheres to the OIDC standard protocol. 
  For enhanced security, the client must present a (qualified) SSL certificate to authenticate.
• Secure Communication: All communications utilize MTLS with TLS 1.2 or higher, ensuring that data in transit is secure.

This API definition is provided for responding PSPs participating in the Worldline VoP Hub ecosystem and EPC scheme. It allows the Hub to dynamically retrieve account holder identification data to provide answers to requesting PSPs, verifying the identity of payee for their payer user (Requester).

The data of the responding PSP can remain under its control and in the desired infrastructure.

Features

The service, exposed by the responding PSP, will receive an account identifier and information about the requesting PSP performing the VoP request, and return account holder identification data to the Worldline VoP Hub, which will in turn compute a matching result to answer the VoP request.

The API supports returning multiple names, as well as additional identifiers when supported by the responding bank.

API Security

• Authentication: The Worldline VoP Hub uses an authentication service that adheres to the OIDC standard protocol. 
  For enhanced security, the client must present an (qualified) SSL certificate to authenticate.
• Secure Communication: All communications utilize MTLS with TLS 1.2 or higher, ensuring that data in transit is secure.

In the EPC VoP scheme

According to the EPC Document 218-23, "Verification Of Payee Scheme Rulebook" first version for public consultation :

The Requesting PSP is the Participant with whom or through whom the Requester intends to make its Account-based Payment. The Requesting PSP receives a Payment Account Number, a Name of the Payment Counterparty and potentially in addition an unambiguous identification code about a Payment Counterparty from the Requester.
The Requesting PSP may also be the Requester.
Upon explicit request by the Requester or due to the laws applicable to the Requesting PSP, this Participant must initiate the request to verify these details about the Payment Counterparty as provided by the Requester.
The Requesting PSP Instantly sends a VOP Request to the PSP managing the Payment Account of the indicated Payment Counterparty.

Worldline provides API based services for scheme participants who need to fulfil this role and intend to comply with all the scheme rules. 

The following processing diagram represents the interactions of the Requesting PSP with the Requester and the WL VoP Services :

Services

To let Requesting PSPs send requests to other EPC scheme participants, the Worldline VoP solution offers API and file based services, which are detailed at the following location in the developer portal :

• Requesting PSP API
• Requesting PSP API - Bulk payments (Coming soon)

Overview

The newly introduced Instant Payment regulation mandates that Account Servicing PSPs need to perform a Verification of the Payee for any credit transfer initiated by their payment service users. The EPC has edited a rulebook to organize a scheme called VoP, to standardize the needed interactions between the participants.

The diagram below shows a generic VoP processing flow and the different involved actors, as the rulebook defines it. 
A glossary defining the scheme specific terms used below can be found at the bottom of this page.

Instant Payment Regulation & VoP compliance timeline

A final publication of the Worldline VoP APIs will be made available after the publication of the EPC rulebook first definitive version, in October 2024. 

Verification of Payee by Worldline

Discover Verification of Payee by Worldline on our website ! 

The Worldline Verification of Payee services allow banks to comply with the new Instant Payment regulation and its Verification of Payee requirement, as requesting and responding PSP, and compliant participant of the EPC VoP scheme.

In this documentation you will find detailed information and draft specifications on how Worldline facilitates VoP processing in this context, letting PSPs fulfill both scheme roles, with the products highlighted in the diagram below :

• Requesting PSP
• Responding PSP

Glossary

• EPC : European Payments Council
• VoP : Verification Of Payee, process of verifying the identity of a payer prior to a payment initiation via SEPA Credit Transfer, as mandated by the Instant Payment Regulation.
• IPR : Instant Payment Regulation
• RVM : Routing and verification mechanism. In the EPC VoP rulebook defined actors, an intermediate service provider for the requesting or responding PSP, acting on behalf of the PSP in the scheme.
• PSP : Payment Service Provider. In this context, an Account Servicing PSP (Bank).
• Requesting PSP : In the VoP ecosystem, the party (bank) performing a verification of Payee, for the Payer.
• Responding PSP : In the VoP ecosystem, the party (bank) responding to a request of verification of Payee.
• Requester : Payer / Payment Service User (PSU)
• Worldline VoP Hub : The SaaS offering of Worldline that will route VoP requests between the necessary systems and provide matching results in accordance with the EPC scheme rules.
• OIDC : OpenId Connect standard, based on Oauth2, used by the WL VoP Hub authentication service. See here and API specifications for more details.

• CRUD : Create, Read, Update, and Delete operations.

DELETE Consents

Endpoint: DELETE /psus/{psuId}/consents/{consentId}

Base URL: /xs2a/routingservice/services/ob/ais/v3

This endpoint is used to revoke a consent. When this endpoint is called, the Open Banking Service will also try to revoke the consent at bank's side. If this is successful, the status of the consent will be changed to ‘Revoked’. If it’s not possible to revoke the consent at the bank's side, the status of the consent will be set to ‘RevokedAtTpp’, The consent might still be active on the bank's side bit will no longer be used by the Open Banking Service.

Data model

The response is an HTTP response with the HTTP code 204

Request	Response

GET Transactions

Endpoint: GET /psus/{psuId}/aspsps/{aspspId}/accounts/{accountId}/transactions

Base URL: /xs2a/routingservice/services/ob/ais/v3

This endpoint is used to retrieve the balances of an account of a PSU.

Data model

Request	Response (click to enlarge)

GET Download Transactions

Endpoint: GET /download/psus/{psuId}/aspsps/{aspspId}/accounts/{accountId}/transactions

Base URL: /xs2a/routingservice/services/ob/ais/v3

Some banks do not provide paginated transactions response. In those cases it isn’t possible to predict the number of transactions to be received in response of a GET transactions request. Even if the bank is supporting paginated responses it might be possible that response of the GET transactions request contains a download link only and no transactions, if the number of transactions is considered too high. In this cases or if the bank isn’t giving the response (instead of JSON in CAMT format for example), the Open Banking Service response on the GET transactions will have a download link instead of a set of transactions.

By calling that download link, the response will be given in a streamed JSON structure starting the stream of transactions already before all transactions are downloaded from the ASPSP. If the bank provides the transactions in a non-JSON format the transactions are converted to JSON on the fly.

Data model

Request	Response
	The JSON structure of the response to this request is the same as it is for GET transactions. The only difference is that there will be no MetaData and no links like First, Prev, Next, Last or Download be contained.

GET Balances

Endpoint: GET /psus/{psuId}/aspsps/{aspspId}/accounts/{accountId}/balances

Base URL: /xs2a/routingservice/services/ob/ais/v3

This endpoint is used to retrieve the balances of an account.

Data model

Request	Response (click to enlarge)

GET Accounts

Endpoint: GET /psus/{psuId}/accounts

Base URL: /xs2a/routingservice/services/ob/ais/v3

This endpoint is used to retrieve the list of accounts of the account holder.

Data model

Request	Response (click to enlarge)