Industry blog: Is your bank ready for the first major PSD2 deadline?

Blog provided by: Salt Edge

One more day remains until the next PSD2 milestone. Tomorrow, the EU banks should make available a sandbox to third party providers for connection and functional testing of their applications and how they interoperate with the bank interface. This can be regarded as a rehearsal for the premier of a grand spectacle, where the actors are the EU financial market participants and the audience is the rest of world.

The deadline of March 14, 2019 is linked to the date when Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) apply. RTS are a binding legislative act that supplements PSD2. While PSD2 is a directive that sets the goal that all Member States must achieve and it’s up to each country to decide how to reach the set goals, RTS are a regulation that shall be applied in its entirely across the EU.

So, let’s arrange some key dates in chronological order. On March 13, 2018, the RTS on SCA and CSC entered into force after being published in the Official Journal of the European Union. The obligations set forth in RTS will apply after a transitional period of 18 months, on September 14, 2019. The main obligation is for ASPSPs to make available at least one interface for secure communication with AISP, PISP, and PIISP by the time RTS apply. Yet, RTS stipulate that ASPSPs shall provide a testing facility, including support, for payment service providers “to test their software and applications used for offering a payment service to users”. This testing environment shall be launched not later than March 14, 2019 (6 months prior to the application date of RTS on SCA and CSC). It’s interesting to note that ASPSP includes any entity that supports payment accounts (e.g. e-Wallets and even corporations that offer internal payment cards to be used by their employees to pay for various services).

Both sandbox and live environments shall support the same functionality. The main difference is that no sensitive information must be shared through the sandbox channel. Now, let’s dive into the major obligations that ASPSPs’ access interfaces should meet:

1. The channel must support authentication of payment service providers that want to access the ASPSP interface(s) (Art. 30 (1)(a) and Art. 34 RTS)
2. The ASPSP interface(s) must allow AISP, PISP, PIISP access to all data necessary to provide services to the payment service users (PSUs) (Art. 30 (1)(b),(1)(c) RTS)
3. The interface(s) must conform to the standards of communication that were issued by international or European standardisation organisations (Article 30(3) RTS)
4. The interface(s) must support the PISP’s and AISP’s instructions toward ASPSPs to start the authentication based on the consent granted by PSU (Art. 30 (2b) RTS)
5. The interface(s) must support the same authentication procedures provided by ASPSP to PSU (Article 30(2) RTS) and the ASPSP should meet the SCA requirements
6. ASPSPs are obliged to document the technical specification of the interface(s) defining a set of routines, protocols, and tools needed for payment service providers to interoperate with the interface. The documentation should be made available, at no charge, when providing the testing facility, upon request by authorised AISP, PISP, PIISP or “PSPs that have applied to their competent authorities for the relevant authorisation”. (Article 30 (3) RTS)
7. The interface(s) must support a procedure for 90-day reauthentication for AISPs (Article 10(2)(b) RTS
8. ASPSPs must inform authorised PSPs (or those that have applied for authorisation) about any planned change to the technical specifications of the interface(s) in advance as soon as possible and not less than 3 months before the change is implemented (Article 30(4) RTS)
9. The interface(s) should allow transmission of messages to PSPs explaining the reason for the unexpected event or error occurring during the process of identification, authentication, or the exchange of the data elements (Article 36(2) RTS)
10. ASPSPs must ensure that the dedicated interface “offers at all times the same level of availability and performance, including support, as the interfaces made available to the payment service user for directly accessing its payment account online” (Article 32 RTS)
11. In case the ASPSP opts for providing a dedicated interface, it shall make available a fallback channel to be used when the dedicated interface does not work (unless ASPSP is subject to exemption from the fallback mechanism). Via the fallback channel, the PSPs must be able to identify themselves and to rely on the same authentication procedures provided by ASPSP to PSU (Article 33 RTS and Article 97(5) PSD2)
12. ASPSPs shall have in place a mechanism to check the validity of the PSPs’ authorisation and the passporting rule (when PSP is based in another EU country) when PSPs request access to payment accounts
13. ASPSPs shall display all fees and exchange rate (where applicable) before PSU confirms the payment (Article 45 PSD2)
14. ASPSPs shall make public the statistics on availability of the interface (Article 32 (4) RST)
15. The interface(s) shall enable ASPSPs to count the number of AISPs’ access requests during a given period (Article 36(5) RTS)
16. The interface(s) should allow traceability of PSPs’ actions (Article 29 RTS)

The RTS do not specify the exact requirements for the sandbox, yet it is plain clear that its functionality shall be as close as possible to the production environment so that PSPs can test upfront their applications and offer best possible services and top-notch user-experience to their end-customers. While some bigger banks can afford to develop and support the sandbox in-house, the article Article 19(6) of PSD2 states that ASPSPs can outsource this task to technical service providers. There are several companies on the market that provide technical support to banks in becoming PSD2 compliant and Salt Edge is one of them.

Salt Edge is a fintech company specialised in building Open Banking APIs for interoperability between banks, payment service providers, and end-customers. With 60+ PSD2 sandboxes being built in just weeks (to be launched on March 14), the company has extensive expertise in PSD2 and RTS requirements imposed upon ASPSPs.

So, tomorrow will show which banks have decided to sit back and wait for the storm and which are bravely sailing towards the Open Banking revolution.