Why PSD2 and Open Banking make it vital to establish industry standards for APIs
Major changes are underway 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 (Revised Payment Services Directive) 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 Payment Service Providers (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 standardisation initiatives of the Berlin Group and Open Banking are the most advanced, it makes sense to compare these two frameworks to identify their main differences. Here they are:
USE CASES COVERED: Open Banking supports the use cases &8220;Payment Initiation&8221; (PSD2 article 66) and &8220;Account Information&8221; (PSD2 article 67). The Berlin Group covers all PSD2 use cases by adding &8220;Fund Confirmation&8221; (PSD2 Article 65).
DATA FIELDS: Working with numerous EU banks, the Berlin Group analysed 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, including on balances and available balance types that are 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 minimisation 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 &8220;redirect&8221; approach, while the Berlin Group offers two more approaches: “decoupled” (using a dedicated bank app), and “embedded” (the name of the customer is carried directly through the bank API).
USER EXPERIENCE: In addition to the API specifications, Open Banking standardises the user experience and text modules in the click route, unifying consent issuing, authentication (2FA) and account information/payment authorisation. 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 differences at this time, the gap may narrow. For example, the Berlin Group is expected to incorporate #fintech 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.
For additional information, see our report, PSD2: Defining new customer journeys
My thanks to Hakan Eroglu for his research and analysis for this blog.
The post Why PSD2 and Open Banking make it vital to establish industry standards for APIs appeared first on Accenture Banking Blog.
Reply