Almost a year has passed since the Revised Payment Service Directive (PSD2) went fully into force in September 2019. However, timely implementation of the required interfaces has been a struggle for many European banks, especially their ability to ensure the availability and reliability of the interfaces. Acquirers have also faced difficulties of presenting a feasible solution in e-commerce. These challenges have led the European Banking Authority (EBA) to grant a grace period for PSD2’s Strong Customer Authentication (SCA) requirement until December 2020. Certain Competent Authorities have even extended this beyond 2020 on country level.
Parallelly, Competent Authorities have faced increasing pressure to monitor PSD2 compliance and data access stability for Third Party Providers (TPPs). Many of today’s compliance solutions are not fulfilling PSD2’s technical requirements. This is evidenced by issues with delivering complete transaction data (containing reference numbers and receiver information) and by overall interface stability and availability. As consumers of PSD2 application program interfaces (APIs), TPPs have also increasingly demanded a satisfactory level of user experience for their customers, Payment Service Users (PSUs).
After being continuously flagged by prospective TPPs and challenger banks, EBA issued an opinion (the Opinion) to guide banks in reducing major obstacles detected in PSD2 interfaces. This Opinion has been well received within the fintech community. Specifically, it benefits banks through providing guidance for user experience design and interaction with TPPs.
When banks overcome technical implementation challenges of PSD2, they will become more easily and broadly accessible for TPPs. Licensed banking activities and infrastructure will remain as banks’ differentiation in the fintech ecosystem. The Opinion supports the evolution of a European open banking ecosystem. It also helps banks to take one step closer to monetizing Open Banking APIs
Compliance challenges and potential resolution approaches
In this article, we address key compliance and usability requirements of third party integrations required by PSD2. We review the Opinion from a bank’s point of view and provide viewpoints for resolving these requirements.
- Environment inconsistencies
- Additional TPP registrations
- Different SCA flows
- Multiple SCA flows
- Additional consents
- Relying on user input
- Point of sale equal treatment
- Standardizing the reauthentication period
- Preventing non-compliant behavior
- Maintaining compliance
1. Environment inconsistencies
As frequently observed by TPPs, integrations into PSD2 interfaces developed based on test environments are not consistently able to work in production environments. Instead, TPPs moving to production need to conduct additional development for applications to work. We have found that sandboxes have been treated by banks as separate environments. They are often developed by different teams than those developing production environments.
A potential solution to inconsistent environments would be to align features and development roadmaps for sandbox and production environments, even if the two environments contain data and information security procedures that are different. Aside from being a regulatory requirement, the role of the sandbox should be understood more broadly. They drive developer experience and serve as pre-production environment for banks’ inhouse development. They also enable identification of value adding TPP partners.
2. Additional TPP registrations
As pointed out in the Opinion, banks should not require additional registration of TPPs aside standard license and validity checks. An exception would be an explicit technical requirement e.g. securing communication with the bank’s authentication applications. We have seen that uploading TPP certificates in order to obtain new credentials is insufficient to move APIs from sandbox to production. Banks’ pre-registrations require, for example, TPP contact information and detailed company information like employee count prior to accessing bank APIs. This is an obstacle for TPPs.
A potential solution to remove TPPs’ barriers to development and production would be to establish a comprehensive automated flow for TPP validity check. This way additional registrations for TPPs could be bypassed. Banks can further streamline developer experience through self-signup onboarding and alignment between sandbox and production environments. In the long term, banks’ resources are also freed up from handling additional registration information. Additional registrations typically reflect a trust issue or risk mitigation towards TPPs.
3. Different SCA flows
According to the EBA Opinion, the SCA flow through TPPs needs to be the equivalent to when conducted through the banks own channels. We have seen that banks have differences in SCA flows between users and TPPs. For example, if the bank itself has a mobile interface in place for its users, TPPs may not be able to access the bank’s PSD2 user interface consistently in the mobile channel. Many TPPs report being redirected to mobile browser interfaces instead, which causes undesired friction in the user flow provided by the TPP. This is seen as well in bank biometric identification (such as fingerprint or face recognition). Redirections between applications are not yet automatic.
While the ambition and rationale for streamlined SCA flows is clear, there are underlying technical challenges. Banks face a complex and layered architecture in their customer authentication (including for instance SMS OTP, paper code lists, identification devices and mobile apps). Some bank authentication methods rely on legacy infrastructure, which may be run by external service providers. Thus, modifications to the SCA architecture for banks is expensive and time consuming.
A potential solution for different SCA flows would be for banks to build a PDS2 compliant SCA solution as a separate add-on module. Modern technologies supporting open standard interfaces (such as trust networks for secure login) enable this. Legacy SCA solutions can exist on the side and banks can gradually phase these out over time.
4. Multiple SCA flows
According to the Opinion, banks need to support a single SCA for both Account Information Service (AIS) and Payment Initiation Service (PIS) journeys in most cases. This way TPPs can build user flows to access account information or initiate payment under one SCA by the PSU. The Opinion only considers two SCAs acceptable if the PIS transaction request does not contain information of the account to be debited. The underlying technical challenge for banks relies often in system architecture where two SCAs may be required by the core banking system.
A potential solution for multiple SCA flows is similar to the solution for different SCA flows. Modern authentication technologies enable the use of only one authentication. From a bank’s point of view, using open standards in SCA represents a new way of trusting technology. However, open standards and trust networks have been proven by other industries already.
5. Additional consents
We have seen that some banks may require users to provide an upfront consent to be able to use the TPPs services. In this scenario, the bank prompts the user to first give consent to the TPP and then prompted again for the AIS or PIS transaction. This consent structure is not required by PSD2. It may reflect to the user a relationship between the bank and TPP that is not intended.
A potential solution for the additional consents would be for banks to rely on the eligibility of the TPP to request AIS and PIS by checking the TPP’s certificate and whitelisting. As such, in AIS, the user gives consent for a bank to transmit account data via the TPP, and in PIS, the user gives consent for the payment. This consent includes all required information to initiate the actual AIS or PIS transaction. Additional consents requested from PSU have no real value in TPP validation or eligibility in terms of audit trail.
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. Depending on TPP, this should be made possible either in TPP or bank domain in context of authentication. Banks need to be present account selection options to PSU at the payment initiation, equally to how these are presented in the bank’s own payment initiation process.
Additionally, a combined AIS and PIS flow for eligible TPPs should also be enabled. When developing initial solutions to comply with PSD2, we have seen that some banks did not take this requirement into consideration. Due to the different consent durations for AIS and PIS, banks face a technology challenging to address this requirement. Furthermore, PSD2 and the Opinion was not specific enough to clearly define the use case requirements. This may be due to the EBA’s evolving understanding of TPP requirements and use cases. Open Banking standards have only recently specified the technical implementation of hybrid flows.
Even if the TPP would not have an AIS license, banks need to provide the information of the debited account to TPP and PSU after completing a PIS transaction.
7. Point of sale equal treatment
We have seen some banks limiting the options available to their users in point of sale functionalities. In practice, 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.
90 days is a compromise requirement, balancing interests of banks and TPPs. EBA’s Regulatory Technical Standard on SCA provides an exemption for a situation where a PSU accesses limited payment account information (balance or payment transaction data) up to last 90 days. In order to improve user experience and avoid reauthentication, TPPs providing account aggregation can rely on this exemption by fetching transactions not more than 90 days back. Banks should support this exemption by implementing a technical solution supporting this exemption of recurring SCA into their compliance platform.
9. Preventing non-compliant behavior
Screen scraping and reverse engineering of bank APIs can be considered as the technical predecessor of PSD2 APIs. They are in many cases still used due to limited availability of compliant APIs. These approaches do not use PSD2 API but rely on the PSU giving their own credentials to TPP. Integrations built on screen scraping are fragile. If a bank for instance changes a simple HTML tag in their login interface, the TPP application might crash and display the specific bank as “not available”. This again causes bad user experience and reputation harm for bank in the eyes of aggregate services users. Such issues related to version management are not to be expected if interface rely on a standard like PSD2. Further screen scraping allows a varying level of audit trails.
At the moment, banks cannot adequately prevent the usage of screen scraping. A potential solution to preventing non-compliant actions would be to improve and stabilize PSD2 APIs. In addition, banks should work towards increasing the amount of data retrievable through compliant interfaces. Enabling compliant TPP access will increase the data exchange reliability, reduce the opportunity for fraud and provide a basis for enriching and monetizing APIs.
10. Maintaining compliance
Focus on maintenance, monitoring and continuous improvement commence once a compliant PSD2 interface solution is in production. Banks in effect enter a role of data service provider to TPPs with service level expectations dictated by external forces. Ensuring continuous compliance in this role in production has traditionally not been considered as the core business of a bank.
We expect banks’ PSD2 compliance will be monitored more closely, along with its availability and reliability. Dedicated focus is needed on staying up to date with regulatory requirements and defining how these are converted into technical interface requirements. We also expect requirements of TPP validity monitoring to increase, along with the number and origin of TPPs aiming to access the interfaces. The mandatory process of TPP validity monitoring is often cumbersome for banks. It requires using multiple dynamic data sources for verification, including checking TPP certificate validity, authorization of Qualified Trust Service Providers to issue TPP certificates and validating whitelisting of TPPs by Competent Authorities.
As banks gradually start to compete and differentiate with PSD2 interface quality, the developer experience requires specific attention as well. From a developer’s point of view, the signup process to APIs needs to be free from excessive bureaucracy. Further, banks need to continuously maintain the APIs, and provide adequate developer support. As TPPs’ needs evolve and new offerings emerge, PSD2 APIs need to be developed beyond compliance.
For banks, dispute handling is required in production phase. For example, if a product is not delivered, the user typically contacts the online store which forwards the issue to the bank. Hence, the TPP certificate validity at time of transaction needs to be checked. Ultimately, the bank is responsible to reimburse the user and eventually claim the money from the TPP. Thus, the bank’s PSD2 system backend should support error handling by providing logs for later investigation of these cases. Intact audit trails for dispute handling should contain logging TPP activities and certificates. In addition, they should document the explicit scope of user consent and dynamic linking. The latter provides evidence of user approval of an exact amount to a certain merchant at a certain time. Creation and storing this documentation can be easily overlooked for banks due to limited resources that are already overburdened with the numerous PSD2 requirements.
Further, while we do not expected a PSD3 in the near future, it is evident that open banking will expand to encompass trading, lending and wealth management. Banks will face more requirements and increased pressure to invest in modern technology and develop SCA further. In order to follow the regulatory requirements of PSD2, banks have chosen to follow standards like Berlin Group or UK Open banking. These standards are continuously evolving to enable new compliant services like bulk payments. Thus banks need to develop new functionalities to follow them.
Evolution of compliance
EBA expects Competent Authorities to conduct increased and continuous supervision of banks regarding removing obstacles for TPPs without unnecessary delays. Tighter follow-up of local financial institutions is already evident. Financial authorities have approached TPPs during summer 2020 and collected detailed feedback of concrete obstacles pointed out by EBA. The questionnaires have addressed integration feasibility, interface reliability and availability as well as level of user support and issue resolution.
While the EBA or Competent Authorities may have resourcing challenges to conduct spot checks on bank level or launching actual compliance penalties at the moment, closer monitoring is already in place and public warnings on compliance can be expected. Further, TPPs will keep testing user flows and have the mandate to escalate issues to Competent Authorities and EBA. This way they will direct increased pressure on banks to provide credible PSD2 compliance solutions. Compliance comparisons by third parties increase the peer pressure of banks to offer reliable PSD2 interfaces.
Outlook of Open Banking
By pointing out concrete requirements for a smooth user flow and streamlined consent monitoring, the Opinion raises the bar for European banks in terms of not only functionality but also TPP experience of PSD2 APIs. Fintech’s and other early-mover TPPs will conduct increased supervision and public influencing regarding availability and usability of the interfaces. Only until banks can provide and maintain regulatory PSD2 APIs for account information, payment initiation and balance check, they will face challenges in monetizing APIs themselves.
We see increasing potential in corporate banking use cases. Increased volumes of B2B interfaces can provide banks sizeable new transaction volume and revenue when built on top of PSD2 instead of legacy technology and custom interfaces.
Open banking will enable disbursements close to real time, instead of batch payments. This will impact the business models of banks towards e.g. accounting, payroll service and ERP system providers. Banks can match their business-to-business payment and account information services with online banking currently offered to consumers by providing solutions beyond SEPA and batch payments. This will increase their flexibility and speed in serving business customers.
Further, also on consumer banking side banks can capture value and increase customer loyalty through premium APIs. There are early use cases available in for instance personal finance and wealth management. In today’s most advanced open banking markets, annual transactions are calculated in hundreds of millions and market size in billions of euros. A sizeable part of this market can be captured by proactive and compliant banks.
Contact us to discuss PSD2 compliance further.
