Whether a bank aims for just for basic PSD2 compliance or wants to go much further, a practical guide could be helpful. The whitepaper ‘Time to get practical’ is a step-by-step preparation guide for banks, elaborates on the topics and questions mentioned above, and supports banks in their preparation for PSD2.Download whitepaper
28 March 2018
Seven key elements for banks to reach full PSD2 compliance
The introduction of PSD2 in January marked the beginning of the emergence of a new eco-system for banks. equensWorldline and Worldline have written two whitepapers to shed light on the changing landscapes for banks and the payments sector. This blog post is about the first whitepaper ‘Time to get practical – a step by step PSD2 preparation guide for banks’. The next blog post will zoom in on the second PSD2 whitepaper with a practical preparation guide for Third Party Providers (TPPs).
Due to access to accounts (XS2A) in PSD2 banks face the risk of losing the direct relationships with their customers and therefore of being reduced to the role of basic infrastructure providers – and this will mean a drastic cut in their revenues. How to overcome those concerns? As indicated before, PSD2 points in the direction of Open Banking and is likely to inspire banks to innovate faster than they otherwise would and to create connected omni-channel experiences.
The whitepaper addresses seven elements that banks should manage in order to reach full PSD2 compliance:
1. Compliance with a dedicated interface handling communication with TPPs
Banks must be able to offer a dedicated interface managing account access for TPPs based on common and secure communication standards: it seems that open APIs will cover this need, but industry standardization is in progress.
2. Strong Customer Authentication (SCA) approach – how are we, as a bank, going to do this?
According to Article 97 of PSD2: “Member States shall ensure that a payment service provider applies strong customer authentication where the payer: (a) accesses its payment online; (b) initiates an electronic payment transaction; (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.”
3. Authentication reset processes
With the more frequent and versatile use of the banks’ SCA solution across different TPP driven solutions, the banks issuing SCA should anticipate a higher load on their customer care processes as well as more attempts on social engineering.
4. Sizing the problem of handling the API calls into their core system
Any good business needs to be prepared for success. But with PSD2 and TPPs accessing the banks’ systems via APIs, banks also need to prepare for successful TPPs – and even for TPPs that by mistake (or by design) generates high load on the APIs.
5. Stress testing their systems – to make sure the bank is not inadvertently opening up security holes with the new digital payment channel
It cannot be emphasized enough how important it is for the banks to prepare carefully for any possible security incidents that might occur as a consequence of the new PSD2 requirements of XS2A for TPPs. The banks’ IT departments should team up with the internal PSD2 experts as well as with external PSD2 service providers – like equensWorldline – to think through all possible risk scenarios that PSD2 services might inflict on the bank.
6. Figuring out how to identify the TPPs
The large number of expected new encounters between banks and TPPs going forward raises some complex questions. How will the banks be able to authenticate in a sufficiently secure way that the TPPs are who they claim to be, and that they have the rights to gain access to a certain bank customer’s account? Clearly the banks cannot jeopardize security by opening up to TTPs unless they are absolutely certainty of their identity.
7. Figuring out how transaction settlements are made
As there is no governing scheme in place for Payment Initiation Service Providers (PISP) initiated payments – except the SEPA scheme managing the credit transfer – banks must decide for themselves how to handle the request for settlement of the transactions. This includes adding and storing sufficient transaction data (and metadata) to handle monitoring, as well as disputes and claims, efficiently.