- On the “sending” side, a participant needs to know what the endpoint (URL) of the “receiving” participant is.
- On the “receiving” side, a participant needs certainty that the sender (API caller, originating participant) is trusted.
Therefore, the role of OSM 1 is to operate a Directory Service for the EPC schemes and make more data available to participants: the URLs, or endpoints of scheme participants’ APIs, identification and authentication information, but also information on which function participants are performing or which functionalities they are offering, within a specific scheme.
Currently the EPC does not manage data and mechanisms ensuring reachability of participants among each other, i.e. how the participants are to find and connect to each other for the purpose of sending and receiving payments or related transactions. The responsibility for this routing function is left to operational entities such as CSMs (Clearing and Settlement Mechanisms, for the payment schemes) or other specialised entities (SPL, SRTP, etc.).
Requirements for the OSM state that data should be machine-readable (i.e., have a structured electronic format) and available as a single full data file including all participants’ data and changes made since the last update or via API calls (restricted to the scheme participants and their technical solution providers), allowing lookup of individual participant data and search values provided in the API request.
For security reasons, it is recommended to authenticate data requestors using client TLS/SSL certificates (PSD2 API certificates are compatible).
If the data is to be made available publicly as a file that can be downloaded (without need for authentication by the requesting entity), this file has to be signed by the OSM with an electronic signature of at least AdES level (Advanced Electronic Signature). However, it is not required for the OSM to be linked to Certification Authorities (CA) or Qualified Trust Service Providers (QTSP) of the participants for automatic certificate data exchanges.
Data updates can be performed by participants, after authentication, via the GUI or via API calls, and must be fast (i.e. intraday), for instance in case of immediate removal/update of a participant upon request following a certificate revocation or another security issue that could lead to a certificate revocation.
Mandatory data
- Identification and participation data from the EPC Register of Participants
- Legal name
- Address
- Identifier for each scheme
- Participation start date
- Technical and additional data from the participants
- API endpoints (URL)
- API documentation endpoints (URL)
- UID of the certificate(s) and the name of the authority that provided the certificate(s),
- Optional feature(s) supported by the participants
- Contact details to communicate about exceptional intraday update
Optional data
- Commercial/trade name
- Flag indicating the API endpoint type (direct route or proxy)
- Flag indicating the API signature owner (scheme participant or proxy), etc.
Unique identifiers of scheme participants are the “key” values to obtain other information about the scheme participants/proxies (e.g. via API), and for authentication purposes.
TRAVIC-Payment-Client-API can help an OSM or a PSP (ASPSP or asset broker) to connect third-party providers. This API is a stateless Java library enabling a caller to communicate with a financial institution’s payments interface by providing business functions such as querying account information (AIS), balances, transaction data, and submitting payments (PIS) at third-party banks.
Author: Zaher Mahfouz
Source: EPC, TRAVIC-Payment-API
1 Operational Scheme Management
