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 use a different interface for each bank where an account was held. This led some to hope that regulators would provide or enable a move towards industry-wide standard APIs.
There have indeed been some moves in this direction, primarily in the UK. For example, the UK’s Open Banking Working Group (OBWG) produced its first report, “The Open Banking Standard”, in February 2016. More recently, the Competition and Markets Authority (CMA) made the development of standardised open APIs the principal “remedy” in its report on the UK’s retail banking industry, and tasked the biggest banks with setting up an Implementation Entity to carry on and complete the OBWG’s work. The final delivery date was deliberately chosen to be 13 January 2018, the date of application of PSD2.
Meanwhile, pan-European payments initiative the Berlin Group is working on a detailed “Access to Account Framework” with data model (at conceptual, logical and physical data levels) and associated messaging, aiming to publish this in the autumn of 2017.
However, the regulatory technical standards (RTS) for PSD2, which are now being finalised by the European Banking Authority (EBA), do not in themselves include any overarching requirement for standardisation of the API (or “dedicated interface” to use its language), apart from a statement that the data structures should be based on ISO 20022. The banks are free to design their own PSD2-compliant APIs, provided only that they meet the various security requirements, and provide free technical documentation to any service provider which wants to use them.
The challenges of ISO 20022
API developer Intive, responding to the EBA’s draft RTS, have pointed out that ISO 20022 does not fit well with the mainstream of API development. No open banking APIs currently exposed by the banks directly use ISO 20022 messages or elements. Most of existing interfaces are RESTful, and as such use the transport protocol to convey semantic value, while ISO 20022 makes no provision for that. Also, most APIs use JSON for syntax of the requests and responses, but ISO 20022 currently does not define JSON syntax, and is usually implemented in XML.
Over and above these technical issues, a basic problem with ISO 20022 is that it allows for any amount of variation and development. Multiple “variant” forms of a given message, such as the Payment Instruction, can exist at the same time. On top of this, different implementations may restrict the message – prohibiting the use of certain optional fields for example – in different ways.
The outcome is thus likely to be that the banks will create a diverse range of APIs, each of which uses a different flavour of ISO 20022 to structure its data. This will create a major challenge for the service providers who will need to call the APIs of multiple banks.
A separate issue for the banks’ API designers is that of retrieving data from one or more legacy systems and restructuring it for publishing via the API, or in the case of payments initiation, a transformation in the other direction. The process might involve multiple in-house systems and require a range of different types of communication; from database updates to message exchanges.