Comparing the Berlin Group and Open Banking UK API Standards for PSD2

Major changes are under way in Europe’s payments landscape. In the UK, the Competition & Markets Authority (CMA) has triggered a fundamental reshaping of the UK’s digital financial industry ecosystem through the Open Banking regulation. And in the EU, the PSD2 (Payment Services Directive 2) regulations – coming into force on 13 January 2018 – require banks to open their systems to third-parties, and provide interfaces for them to initiate payments and retrieve account information.

However, PSD2 leaves open the details of the application programming interfaces (APIs) that third-parties will use to connect with banks. While the CMA has required British banks to set up an independent implementation entity called Open Banking Limited, the European Banking Authority’s (EBA’s) draft Regulatory Technical Standards (RTS) for PSD2 specifies only technical framework conditions and no interface standard.

As a result, cross-bank or pan-European API standards have yet to be clarified. Creating these standards is vital: PSD2 aims to develop a unified, innovative, pan-European digital ecosystem for financial products, and uniform interfaces and processes are essential for achieving this goal. So the lack of an implementation entity for the EU is a significant gap.

To help fill it, the Berlin Group – consisting of almost 40 banks, associations and PSPs from across the EU – has defined a common API standard called "NextGenPSD2" for the use cases specified in PSD2. Initiatives are also being launched in Poland, Slovenia and France. However, given that the standardization initiatives of the Berlin Group and Open Banking are the most advanced, it makes sense compare these two frameworks to identify their main differences. Here they are:

• Use cases covered: Open Banking supports the use cases "Payment Initiation" (PSD2 article 66) and "Account Information" (PSD2 article 67). The Berlin Group covers all PSD2 use cases by adding "Fund Confirmation" (PSD2 Article 65).

• Data fields: Working with numerous EU banks, the Berlin Group analyzed various online banking masks to create a minimum standard set of data fields which all banks must offer via their APIs. In contrast, the Open Banking standard was negotiated only among the CMA9 banks and a UK third-party advisory group, and provides more extensive information such as more detailed balance information and more available balance types that’s particularly relevant to FinTechs.

• Consent model: Open Banking allows the customer to allow specific data clusters for use by third parties – for example, only account balances, deposits or direct debit transactions. This approach is close to the data minimization requirements in the EU General Data Protection Regulation (GDPR). The Berlin Group provides for consent only for account balances and transaction histories for a certain period.

• Message formats: The Open Banking Standard uses only the JSON (JavaScript Object Notation) format with field names based on ISO 20022, while the Berlin Group offers alternative industry standard formats. On top of JSON, Berlin Group supports JSON with encapsulated ISO 20022 based pain.00x for payments and camt.05x and MT94x for account information.

• Authentication: Open Banking supports strong customer authentication (SCA) through the "redirect" approach, while the Berlin Group offers two more approaches: “decoupled” (using a dedicated bank app), and “embedded” (the credentials of the customer is carried directly through the bank API).

• User experience: In addition to the API specifications, Open Banking standardizes the user experience and text modules in the click route, unifying consent issuing, authentication (2FA) and account information/payment authorization. The Berlin Group allows each bank to devise its own user experience.

• Transaction Risk Analysis: The Transaction Risk Analysis defined in the RTS is supplied differently, with Open Banking offering more parameters via the API.

While these are the main current differences, the gap may narrow. For example, the Berlin Group is expected to incorporate FinTechs’ requirements in the final version of its proposals, scheduled for publication by the end of 2017. It’s also important to remember that implementing a standard does not automatically make a bank PSD2-compliant, since it still needs to comply with other aspects of the RTS like authentication methods, exemptions from SCA, and API testing systems.

The EBA’s RTS is expected to be ratified by the European Parliament at the end of February 2018 – after which banks and other PSPs will have 18 months to implement it, including providing APIs. In choosing between the available standards, banks should make their evaluation as early as possible and take strategic and technical aspects into account so they can hit the ground running. Time is short – and having the optimal APIs in place will be critical to success in the PSD2 world.

An updated blog to NextGenPSD2 can be found in my new blog.