Is everybody API?

Application programming interfaces (APIs) have been a standard method of interconnecting system components for decades, but in the past few years they have been discussed in the context of financial services as ‘a game changer’. A number of factors are behind this, but a striking fact is that they are now always referred to as open APIs – publicly available services that allow anyone to connect to services.

The word open is important for both the main drivers of API development in financial services: the rise of financial technology companies and regulatory initiatives to open up the market to further innovation and competition.

APIs are at the heart of smartphone applications and service-driven websites because they allow the app to pull in data from multiple sources and manipulate it in different ways. Many of these come from the world of financial technology, but usually they are limited in their functionality compared to some more general applications.

Spend any amount of time with app developers and you will soon be pointed in the direction of Citymapper, a smartphone app and website for navigating around cities. The cleverness of the app is not simply that it uses geographical information services to plot routes – the smartphone has that built in – but how it pulls publicly available information together. This includes real-time data from transit authorities and search information from Google, allowing the app to calculate routes comparing different modes of transport between different locations, to suggest alternatives and to point the user in the direction of nearby stops and so on.

Originally developed for London in 2012 (the year of the summer Olympic Games), it is available in 29 cities (including Singapore). That level of expansion could not have happened if the company had had to build the data sets itself. “Citymapper was started on the back of the open data movement – the idea that if you make information accessible, someone will make good use of it and people will benefit. We couldn’t have done what we did without the work done by many over decades in pushing this agenda,” the company says.

In financial services, the nearest equivalent is arguably the Open Bank Project, which describes itself as “an open source, developer-friendly ‘API for banks’ that developers and companies can use to build innovative applications and services based on the account holders’ transaction data”.

Founded in 2010 by Simon Redfern, chief executive of Berlin-based software company Tesobe, the original catalyst came from his idea of creating a bank where all transactions were visible to everyone. He believed this would help to fight corruption. The idea then matured into the concept of an API that “exposes transaction data in a simple and consistent structure by abstracting away the peculiarities of each banking system”.

It has now been tested by several German banks, including Postbank, GLS Gemeinschaftsbank and Landesbank Berlin. There are around 20 apps and services that can take transaction data via the API.

This capability has, unsurprisingly, caught the attention of larger banks, all of which have set up incubators and accelerator programmes to try to harness APIs. Developments are under way in both retail banking and transaction banking. For example, Royal Bank of Scotland’s (RBS’) global transaction services business is exploring collaboration with a number of start-up companies as a way of combining its own services with the innovation provided by smaller companies, through API sharing.

“Fintech start-ups are often agile, lean and nimble,” says James Lynn, head of e-channels, global transaction services at RBS. “There are obvious advantages for RBS to partner with some of these firms. That’s where the APIs come in. The concept is to enable the services provided by global transaction services to be accessed directly and securely by players in the market, such as fintechs, software firms or other service providers.”

It is this account access by third parties that is at the heart of governmental and regulatory reforms, with competition and innovation the goal, but while the Open Bank Project and others are well down the road, different government initiatives are running at different speeds and are not necessarily aligned.

Last year a report commissioned by the UK Treasury came down heavily on the side of pushing for a standard Open Banking API, arguing that “deployment of APIs would offer substantial potential for increased competition in the UK banking market and would enable innovative, value-added tools”.

The report concluded that APIs would mean that banks could securely pass personal account data (with the account holder’s permission) to another entity, enabling a number of competitive scenarios. These include comparison websites that find the bank account provider whose charges are best suited to a specific individual’s transaction behaviour. Other scenarios could involve lenders being able to access more details of a borrower’s creditworthiness (and so offer better terms) and personal finance management tools that aggregate data from a number of accounts and make suggestions for appropriate products or changes in behaviour.

Making the case for forcing banks to agree on an open API standard for third party access, the report specifically points out that not being fully open with the deployment of external APIs would constrain competition, especially in the consumer and SME banking markets: “There is an information asymmetry which means that banks’ customers may not know what their bank accounts cost them, impeding their ability to shop around. Alternative lenders may not have access to the same information about a borrower’s creditworthiness, so are less able to compete with banks on the pricing of loans. Likewise, because consumers’ banks have privileged information and access, competing providers of other financial products may be unable to overcome the barriers of a bank account’s gateway product status.”

Work is now under way (and under wraps) to develop a UK API, which HM Treasury has tasked UK Payments and Innovate Finance to produce before the end of this year. As if this were not a tight enough deadline, the situation is complicated by a parallel development in Europe, where one of the main tenets of the Payment Services Directive II is a provision for open access by ‘trusted third parties’ (TTPs) to ‘payment service user’ accounts for payment initiation and account information services.

Details of how this access to accounts mechanism is to be implemented by institutions have yet to be finalised. Recommended technical standards from the European Banking Authority are not expected to be issued for a year after the statute is issued in around the final quarter of this year. Most people agree that APIs are the obvious route.

“Though at first glance the requirements of open access to account information may appear little more than a technical compliance overhead, not only will banks need to create TTP-facing, open access front ends, there clearly will be technical challenges in the back office integration of the existing (sometime legacy) core banking systems to provide the data requested,” says Neil Clarke, head of market engagement for standards evolution at Volante Technologies.

But there are benefits for banks taking the leap, though opening the vault doors to customers’ data appears to offer little value to banks. However, they “should embrace this technology-based evolution, considering how, with customer approval of course, they can leverage the rich source of customer data they hold [about] payment profiles, know your customer information, finance history and so forth,” says Clarke.

Jerry Norton, vice-president, financial services, at systems vendor CGI, agrees that there are many complications. “What goes into the API is effectively a set of services that provide the external parties with basic payments capabilities,” he says. “It might be something simple like ‘make this payment now’ or ‘make this payment tomorrow’. It sounds very easy to do, but when you think through the consequences of it, it’s not so clear. What do you expose to external parties? It might be ‘make a payment’ but it’s not going to be ‘make a high value Chaps payment’, so how do you indicate that is should be a Chaps payment? I don’t think anybody has a smart answer to that, though people are thinking
about it.”

There are also potential issues that arise from local infrastructures and market practices, he says. “In the UK for instance, access to the Faster Payments system for many smaller institutions and payment services providers is via a sponsoring bank that has direct access. How would an API be configured to recognise a Faster Payment request from an indirect provider? And what would it do if the request was made out of hours? APIs aren’t really the right place to be building-in business logic and routing capabilities.”

Norton says banks are starting to realise that opening up via APIs is not incompatible with the systems architectures that have been evolving during the past few years. “I think the big change in the past 12 months – since last Sibos – is that effectively you are protecting the payment utility or hub by putting an API around it and that API potentially has to be published at some point – certainly in Europe – so that other people can have access to those services,” he says. “Those services are implemented through a set of technologies. It could be a payments hub, it could be a gateway to Faster Payments, or an FX conversion function. All of the big banks are thinking along these lines and the issue is at what granularity do you build that API? The picture is of an API that exposes a set of services externally and internally you’ll have a whole set of technologies. In effect, the whole thing is a sort of utility or payments factory. The API piece is the key difference between yesterday and today.”

The adoption of APIs poses some existential questions for banks with which they will have to come to terms. “If you make the API available, are banks forced into just being a transaction entity for payments?” says Norton “Or do they offer other functions? It’s a strategic decision and different banks will do different things.”

Clarke agrees: “With PSD II on the horizon and the general move towards more open consumer data, it’s not a case of if but when banks will need to consider their strategy in open banking,” he says. “It is worth noting that PSD II does not preclude banks themselves becoming TTPs potentially offering competing consolidated and innovative payment services to their clients.”

Whichever approach they take, be it becoming TTPs or forging alliances with emerging TTPs and financial technology companies, it is clear that the industry is on the brink of major change, says Norton: “We are now seeing real innovation from the banks, so the good news is that all this pressure from governments and regulators is pushing things in the right direction.”