It has been one year since the EU’s payments directive, PSD2, was implemented. Timely implementation of compliant and reliable interfaces has been a struggle for many European banks. EBAs recent Opinion combined with public pressure from fintechs and early-mover Third Party Providers (TPPs) raises the bar for banks to maintain compliant and user-friendly APIs. This is also a prerequisite for banks to claim their share of the growing open banking market. We have addressed the main implementation challenges of compliance from banks perspective and provide viewpoints for resolution.
1. Environment Inconsistencies
Integrations into PSD2 interfaces developed based on test environments are not consistently able to work in production without additional development. Banks should resolve this through alignment of features and development roadmaps for sandbox and production environments.
2. Additional TPP registrations
Banks should not require additional registration of TPPs aside standard license and validity checks. These could be bypassed through comprehensive automated TPP validity checks.
3. Different SCA flows
The Strong Customer Authentication (SCA) flow through a TPP needs to be the equivalent to when conducted through a bank’s own channels. For instance the flow in mobile channel needs to be consistently enabled for TPPs as well. As an underlying technical challenge, banks face a complex architecture in their customer authentication and modifications to the SCA are expensive and time consuming. Banks could build PDS2 compliant SCA solution as a separate add-on module with modern technologies supporting open standard interfaces.
4. Multiple SCA flows
Banks need to support a single SCA for both Account Information Service and Payment Initiation Service journeys in most cases. Banks’ core banking system architecture may require multiple SCAs. The single authentication requirement can be built using modern authentication technologies and open SCA standards proven in other industries.
5. Additional consents
While some banks require users to provide an upfront consent to be able to use TPP services, this consent structure is not required by PSD2. Banks can rely on the eligibility of the TPP to request AIS and PIS by checking the TPP’s certificate and whitelisting and thus make additional consents redundant.
6. Relying on user input
As part of a smooth and error-free AIS or PIS flow, banks are expected to provide a selection of account number instead of a PSU manual input.
7. Point of sale equal treatment
If a bank is offering a direct payment feature in an online store, a TPP should also be able to initiate an equivalent PIS flow towards the bank. A potential solution for point of sale equal treatment would be for banks making point of sale compliant authentication solutions available for TPPs to the extent banks maintain these for users.
8. Standardizing the reauthentication period
PSD2 allows a user’s AIS consent for a one-time transaction to be valid for up to 90 days. Banks need to make it available for eligible TPPs to fetch account data for this period without reauthentication.
9. Preventing non-compliant behavior
Screen scraping and reverse engineering of bank APIs are in many cases used due to limited availability of compliant APIs. Integrations built on screen scraping are fragile and not auditable. The only solution for banks to prevent non-compliant actions is to improve and stabilize PSD2 APIs.
10. Maintaining compliance
By opening PSD2 interfaces, banks in effect enter a role of data service provider to TPPs with service level expectations dictated by external forces. Ensuring compliance in production requires continuous monitoring, TPP management, developer support and dispute handling, combined with the future development requirements to remain compliant.
Read the full article on how banks can overcome PSD2 compliance challenges or contact us to discuss PSD2 compliance further.
