SAP for Banking is a comprehensive offering for streamlining core processes and producing new innovations in transactional banking, payments, personalized offers, risk analysis and more. More than 14,600 banks in 150 countries rely on solutions from the SAP for Banking portfolio to become more customer-centric across all channels, reduce cost and complexity and more easily manage regulatory and risk compliance. The solutions are the direct result of the company’s more than 40 years of accumulated industry knowledge and a spirit of co-innovation where banks play a role shaping solutions to fit the realities of the modern-day banking institution.
In this context our assumption as of now has been that the European Banking Authority (EBA) will offer a consolidated central register for Third Party Providers (TPPs) to support various use cases. The NCA, operating non-standardized national register, is responsible for checking the application for registration of national TPPs and for onboarding the TPPs. After the TPPs have been onboarded, the data is to be immediately forwarded to the EBA Register. The NCA is responsible for handling any kind of fraud suspicion and, if required, to block the TPPs. Additionally, this information has to be forwarded to the EBA Register as soon as possible. The EBA Register supports the following use cases:
• Human search for TPP information
• API for national directories for data exchange
• API for banks to validate the TPP during runtime (service execution)
• API for banks in case of fraud suspicion which the EBA Register will forward to the respective national directory
• API for TPPs to find bank service endpoints for requested services (AIS, PIS, …)
Answers to Question 1:
Both options need to be supported. In case of an initial load, reload due to inconsistencies or other emergencies, it is required to load the complete data set of the NCA into the EBA Register.
In the case of normal business, updates of existing data or new TPPs onboarded, only the relevant information should be transferred, which should always include the complete data set related to a TPP.
It might also be required that NCA’s staff supports manual maintenance of the EBA Register in case of technical problems.
From our perspective, the EBA Register has to contain all relevant data from banks, including checking and validating the respective TPP either through manual search or, most importantly, through online APIs.
This is especially important since the registers of the NCAs are not harmonized, and therefore, are not offering standardized APIs.
In addition, it should be examined how a replication of the EBA Register into a local storage is required to efficiently support high throughput of payments with high performance and low latency.
Yes, we agree.
No, specifically #33 and #34 are required. In our opinion, all parties that can act as a TPP shall be in scope of the EBA Register, (e.g. banks who act as a TPP toward other banks).
The idea of PSD2 is to first start with AIS and PIS, concentrating on payment related bank products. But it is already clear that the whole banking ecosystem wants to extend and open this for so called value-added services, which will ultimately be responsible for driving real innovations. All infrastructure components introduced in the first step, such as EBA Register, TPP validation, SCA with 2FA etc., should be designed in a way that the future scope will be supported as well. Otherwise, nobody will be able to create and run a parallel infrastructure. If this is not supported by the EBA Register, it becomes irrelevant.
No, all details which are needed to provide a full scope of information about the TPPs and validation during execution need to be in the register.
See answer to Question 5.
EBA is pushing PSD2 which is valid across all the member states of the European Union. As a result, it is on the EBA to drive and ensure the harmonization of the national registers, data stored and APIs provided.
Could you further clarify the role an agent will play in the currently discussed PSD2 processes?