Introduction

Over the last few years a growing list of banks – including Crédit Agricole, Standard Chartered, Citi, CapitalOne, Saxo Bank, HSBC and digital banks such as Monzo – have launched open application programming interfaces (open APIs).  These aim to attract fintechs and other front-end service providers to write apps that take advantage of the bank data made available via the API.

At the same time regulatory authorities have been getting behind this move. Under the banner of Open Banking they aim to stimulate new entrants into the provision of innovative banking services by opening up the data silos of the traditional banks, enabling third parties to offer such services as product comparison, payments initiation and account aggregation.

The need for standards

So far each bank has created its own API without any reference to any other bank. A provider of, say, an aggregated accounts display would thus have to write a different interface for each account. Hence the growing recognition that standards are needed in this area. At present no less than three initiatives are relevant to the UK, with overlapping but not identical agendas – the Open Banking Standard, the Competition and Markets Authority’s Retail Banking Markets Investigation, and the EU’s second Payment Service Directive (PSD2).

The Open Banking Standard

HM Treasury initiated the drive towards Open Banking in the UK with the Fingleton Report (2014) titled ‘Data Sharing and Open Data for Banks’, followed by a commitment in the 2015 budget to deliver an open standard for APIs and data sharing in UK retail banking. This led to the formation of the Open Banking Working Group (OBWG), which produced an ambitious set of proposals in February 2016, the Open Banking Standard.

Despite its title the document is not in fact a fully fledged standard but a work-in-progress – a “framework … to enable the accelerated building of an Open Banking Standard in the UK”.  The document develops the governance principles, core technologies and future development roadmap for an “open API environment” in which “documentation, development code and reference implementations … will be published on the web for anyone to use”.  The Open Banking Standard is treated as comprising Data Standards, API Standards, and Security Standards, supported by an over-arching governance model and practical developer resources.

The API Standards section gives some high-level technical direction, following the Fingleton Report and common market practise in proposing the use of REST as an architecture and JSON encoding for requests and responses. The Security Standards section recommends the use of OAuth 2.0.

Regarding data, the document proposes to use existing data standards where possible. In a short appendix on this topic it references ISO standards such as currency codes and the ISO 20022 definition of an account, but elsewhere states that “it is still open to further investigation whether existing data models can be used, such as the ISO 20022 Financial Repository …”.  Another appendix attempts to define the range of bank data that is in scope, providing a structured list of over 140 high-level data attributes under a number of schema headings (e.g. ‘Branch’ contains Location, Address, Hours, Facilities, Services). This area will clearly require considerably more work to flesh out.

While focusing primarily on technical framework and governance issues the document does give some examples of possible business uses and sets out a development roadmap. Potential uses differ mainly in the ownership of the data that is shared. A service (e.g. a price comparison website) which offered comparisons between several banks’ products – account types, loan facilities, etc. – would only use data owned by the banks themselves. On the other hand, a service which extracted transaction history to a loan provider for risk assessment purposes would use customer data and thus require prior customer approval and authentication.

The roadmap therefore proposes the initial delivery of a ‘minimum viable product’ covering such data as branch location and hours, ATM locations, etc.  Subsequent releases would include more use of customer data and hence tighter security.

There is however a large fly in the Open Banking ointment, as noted industry commentator Chris Skinner has pointed out: “No bank is going to just roll-over and give away their core asset: the customer; and by giving away the customer’s data, they might as well be doing that”.

That is why two major regulatory initiatives may be needed to force the banks to move on the issue.

CMA’s Retail Banking Markets Investigation

The Competition and Markets Authority (CMA) published its 766-page Retail Banking Markets Investigation report in August 2016, and on 2nd February 2017 published its ‘final order’ formally implementing the reforms. Among other remedies aimed at increasing competition in the retail banking sector this report requires banks to adopt Open Banking.

The principal remedy described in the report instructs the largest banks in Great Britain and Northern Ireland to collectively take the following actions:

a) To establish an Implementation Entity through which they will adopt and maintain common API standards. (The CMA report specifically namechecks the Open Banking Working Group as a foundation for this, and the Implementation Entity has now been set up under the auspices of Payments UK)

b) Release and make available through an open API (i) detailed information on their personal and business customer accounts and loans, and (ii) reference data on branch and ATM locations, by 31 March 2017

c) Provide, through an open API among other methods, service quality indicators (e.g. on customer willingness to recommend)

d) Agree open standards for APIs with ‘full read and write functionality’ and make available through them personal and business customer transaction data sets, by 13 Jan 2018.

The latter date is, not coincidentally, the transposition deadline of PSD2 (see below).

The CMA report is thus forcing the major banks to take steps towards making Open Banking a reality, using the OBWG’s work as the starting point.

PSD2 and open banking

The EU’s Payment Services Directive 2 (PSD2) includes several specific business-level requirements for open banking. PSD2 must be transposed into UK law by 13 Jan 2018.

PSD2 approaches open banking primarily through the lens of two specific services – payments initiation services (PIS) and account information services (AIS) – the latter being providers of aggregated account information. Providers of these services (PISPs and AISPs) are distinguished from the bank or other institution holding the user’s account – known as the Account Servicing Payment Service Provider or AS PSP.

Without going into the detail of PSD2, the key point to note is that under the rules, banks will be obliged to provide licensed third parties with secure access to customers’ accounts.

PSD2 is not in any way a technical document – it never explicitly refers to ‘APIs’. The regulatory technical standards (RTS) for PSD2 have been specified separately by the European Banking Authority (EBA) but these primarily cover customer authentication and secure communications. From a standards point of view the main point of interest is a statement in the final draft RTS that “account servicing payment service providers shall also ensure that the dedicated interface uses ISO 20022 elements, components or approved message definitions, for financial messaging.”

However, the mere reference to a standard like ISO 20022 is not the same thing as creating a standard for open APIs. Given that the EBA has not been given the task of overseeing the creation of an industry-wide standard API – in other words, PSD2 lacks an ‘Implementation Entity’ – it is possible that PSD2 will lead to a free-for-all in which each bank – or local group of banks –  develops its own API, and the benefits of standardisation are not realised.

On 3rd March 2017 it was reported that Nordea has already developed two PSD2 related APIs – for payments initiation and account information – and has set up a site for developers to experiment with them. The bank is quoted as saying that “Our goal is to strengthen our collaboration with fintechs and go beyond the [PSD2] regulation by providing premium APIs which fit your needs.”

In the UK the next date to look out for is the 31st March, when the CMA requires the first open API release to be made.

Capabilities of Transformer

Trace Financial and Transformer are world leaders when it comes to the challenges of working with diverse and complex data structures. Organisations such as SWIFT, Earthport, Currencies Direct, global banks and market infrastructures all rely on Transformer.

Transformer uniquely allows analysts or developers to address all aspects including mapping, validation, enrichment, testing and maintenance without resorting to coding or scripting.

Transformer offers banks and service providers the tools they need to work with Open Banking APIs including full support for  RESTful services, JSON and ISO 20022 based data structures.

Transformer dramatically shortens the time taken to build solutions involving complex data structures. The analyst using Transformer creates solutions directly in the intuitive Design-Time GUI. There is no coding stage, even when the required data transformation is highly complex. In this way projects remain clearly articulated and easy to maintain, and removing the old-fashioned ‘spec handover’ from analyst to developer eliminates a major source of risk and delay. Testing is fully integrated at all stages.

Once configurations are complete and tested they are deployed into any runtime architecture that suits the client. A Transformer configuration can be deployed into the multitude of technical infrastructures found at a client site including Java, .NET, RESTful web services, etc.

Transformer is a truly strategic solution to all the challenges and delivers one best-of-breed solution for any data standard; for deployment in any technical infrastructure; for integration in any version control system and automated testing environment; and can be used by analysts or developers without any need to resort to coding or scripting. Transformer is an essential tool for coping with these evolving and complex demands.