PSD2 Deadline 14 March: Questions You Should Be Asking Yourself

February 28, 2019
Saira Guthrie
Product Marketing Manager

Ready or Not, Here Comes the First PSD2 Deadline
The deadline for all EU member states to transpose the Revised Payment Services Directive (PSD2) into national law was over a year ago on 13 January 2018. Now banks are nearing the first of two deadlines to comply with regulatory technical standards imposed by PSD2.

  • To give third parties at least six months to test authorising payment services, all banks are required to set up a testing “sandbox” environment that includes APIs, documentation and support by 14 March 2019.
  • The final PSD2 compliance deadline is 14 September 2019, requiring strong customer authentication, access to accounts (XS2A) and a host of other requirements.


What exactly do banks need to have in place for the 14 March deadline?
A publicly available testing facility, commonly called a “sandbox” environment, with secure APIs, documentation and support.


What happens if you don’t meet the PSD2 deadline?
If you aren’t able to set up a sandbox environment as required, then you need to provide a “contingency mechanism” for Third Party Providers (TPPs) to access the customer account data that PSD2 allows. This can be a dedicated web-based or mobile interface that’s scoped for third party use and limits some of the functions of the full consumer digital interface.

Most banks won’t openly condone screen scraping, so this “contingency mechanism” really isn’t your bank’s best option. Your customers don’t necessarily want to be insecure, but without secure financial APIs in place, digital-native and finance-savvy customers will continue using consumer-focused fintech apps from third parties—and they’ll continue to hand over their banking credentials to do so.


Are your testing APIs in place yet?

YES. What’s the next step?
Congratulations! Now that you have the APIs, documentation and support plan in place, are your APIs secure? It’s important that you evaluate your existing access management and security components to make sure they are specifically capable of protecting API resources since most legacy WAM systems aren’t.

If you’re interested in seeing firsthand what modern API security looks like, from both a customer and backend perspective (including OAuth and OpenID Connect workflows), we’ve built a Quickstart Private Sandbox for PSD2 to accelerate hands-on testing and deployment of sample consumer fintech apps and several key components of the Ping Intelligent Identity Platform to protect banking APIs. And beyond OAuth security flows, many organizations are getting proactive about monitoring API traffic and AI-powered cybersecurity.

NO. I need to find a trusted partner.
With the deadline fast approaching, we don’t recommend building the APIs and security profile yourself. The quickest route to compliance is to find the right combination of technology partners who can provide you with a ready-made set of secure financial APIs to snap in place. Ping’s global partner network includes dedicated, specialized financial technology companies that serve banks. Many have created platforms or provide an API layer/portal, often as a managed service with all the PSD2-compliant APIs you need to have by the deadline.

These technology companies can accelerate getting the APIs you need, but securing them is still an important component—and that’s Ping’s primary role. Rather than build security and access management from scratch, many of these companies are using Ping’s capabilities as the security component, either white-labeled or openly powered by the Ping platform. Ping is helping banks navigate the financial technology partner landscape to find the right organizational fit and expertise to accelerate PSD2 compliance.


Which API format are you adopting?
The most common critique of PSD2 is that it forces banks to provide open APIs, but it doesn’t specify a standard format for APIs across the EU. Huge network complexities and costs would ensue if every bank developed their own proprietary API interface. That’s why several initiatives across Europe and elsewhere are helping specify and standardize API formats.

OAuth 2.0 and OpenID Connect (OIDC) form the backbone of many API standardization initiatives across industries, however you’ll find slight differences among the major API standardization frameworks that have emerged specifically for finance, such as OpenID, Open Banking (UK), the Berlin Group, Financial Data Exchange and more.

OpenID’s Financial-grade API (FAPI)
Financial-grade API (FAPI) is an international working group draft specification designed by technical folks who are thought leaders for defining identity security standards for global and major industry use cases. For financial-grade specifications, they are working to model APIs for security and privacy, including protection with secure OAuth tokens and REST/JSON data schema recommendations. This group’s standardization efforts have the benefit of not being associated with a specific region’s political or economic motivations since it’s an open, global community of developers, vendors, and users.

Open Banking Standard
If you’re in the UK, it’s safe for you to look no further than the Open Banking Standard. Aiming to stay ahead of the curve and already in an independent mindset with Brexit looming, the top banks in the UK formed the Open Banking Implementation Entity, charged with defining a standard, managing a trusted registrar for all bank and third parties and certifying conformance so all parties can interact securely. Open Banking also strictly aligns to ISO20022 attributes and GDPR requirements for data minimization.

The usefulness of the Open Banking Standard isn’t restricted to the UK, and due to its early adoption and continued maturation, many thought leaders around the world are using the UK Open Banking Standard as a jumping off point to define their own with slight modifications. Another thing to note is that the Open Banking Standard is becoming more and more aligned with FAPI over time. Pretty soon, it could be safe to say that the Open Banking Standard and FAPI will be essentially the same.

The Berlin Group’s NextGenPSD2 Framework
The Berlin Group, a European coalition of banks and payment processors, has created the Access to Account (XS2A) framework based on the PSD2 and EBA RTS requirements. It can be loosely flexed in terms of message formats beyond JSON and user experience. While FAPI and Open Banking are prescriptive API standards, NextGenPSD2 is a more flexible framework to assemble your own.

It includes the data model (at conceptual, logical and physical data levels) and associated messaging for each of the use cases mentioned in PSD2, including fund confirmation. This framework has greater appeal to FinTechs as compared to the Open Banking Standard, because it has a slightly more comprehensive standard set of data fields included in a bank’s APIs and the option for banks to submit additional data attributes with Berlin Group approval.

Financial Data Exchange’s Durable Data API (DDA) Standard
In October 2018, the Financial Data Exchange (FDX) was launched, supporting the Durable Data API (DDA) standard with the aim of making it easier and safer for consumers to use financial data and apps to make good decisions. In the U.S., consumer concern for financial data security and privacy is high. According to an August 2018 survey, 67% said they are “extremely concerned” or “very concerned” about data privacy using fintech apps, and 56% said they would like to control which of their financial accounts and data types can be accessed by any third party.

Most FDX members are based in the U.S., where there isn’t a regulation requiring open APIs for banks, however most financial institutions can agree that screen scraping is insecure and standard APIs are the answer. This new standard meets all of PSD2’s requirements, incorporates OAuth 2.0 and can be used by banks, data aggregators, fintechs, as well as insurance companies, broker/dealers and more.

Owned by six major banks in France, STET has created PSD2 API v1.4 to provide a secure and easy-to-use set of services to be implemented on the server side by European ASPSPs. STET is actively collaborating with many stakeholders and other standardization initiatives across the EU for the sake of having a high quality PSD2 API that will satisfy all European actors.

It provides features around authentication, authorisation, proof management and fraud detection and has been built with the latest technology standards using REST, OAuth2, JSON and HTTP-signature. It relies on ISO20022 elements for structuring the data to be exchanged between TPPs and ASPSPs.

PolishAPI Standard
The PolishAPI Standard is the Polish payment sector’s response to the need to strengthen financial innovation in Poland in a non-discriminatory and sustainable manner. It’s aimed at reducing the costs of implementing PSD2 for ASPSPs and TPPs. The creators of the standard are assuming it will be in constant new version development to respond to changes in the Polish and European market. One thing to note is that the PolishAPI Standard may be the only standard in the EU that does not embrace the idea of RESTful APIs (at least in its initial version).

Ping Identity Helps Shape API Standards
The flexibility of the Ping Intelligent Identity Platform and our participation in digital identity standards bodies ensures that regardless of which standard API model you choose (because they have similar aims), Ping Identity will continue to be a trusted partner for financial enterprises today and in the future. We are currently fully conformant with FAPI 2, Open Banking v2, and we’re working on Open Banking v3 conformance testing. Since Berlin Group’s NextGenPSD2 broadly accommodates many points of view, Ping can help you navigate which point of view to adopt and the security technology that will underpin it.

For additional information on how Ping Identity can help with a PSD2 solution for your bank, read about how you can seize the customer experience opportunity through PSD2 compliance or get the technical solution guide on how to implement financial-grade API security.