OPEN APIS: HELP OR HINDRANCE FOR BANKS?
As Citi’s Wandhöfer points out, neither PSD2 nor the EBA RTSs make any explicit mention of APIs as the means by which A2A be facilitated. However, the fact that the official documents omit to mention this key three-letter acronym has done nothing to temper the growing conviction among banks in Europe and beyond that APIs are the key to enabling the openness that PSD2 requires.
This is in part because they are coming anyway, PSD2 or no PSD2. As Roberto Ferrari, General Manager of Italian digital bank CheBanca!, says: “With our middleware – specifically our front end middleware – we are going in this direction because we are already looking into putting information into our API gateway. We already have 700 APIs, because we believe digital banking is very much about APIs and we are getting ready for that. We need a seamless integrated architecture to open up to marketplace banking. That’s the idea and PSD2 fits very nicely with this idea.”
For Blomfield at Monzo too, PSD2 is slightly incidental to the rise of open APIs. “We are as much a technology company as we are a bank,” he says. “Being able to respond to queries from an API functional stack is pretty straightforward for us. PSD2 is this thing in the future that may come to pass and if it does we will react. Our plan to take advantage of it ties in with the opportunity to be a marketplace bank. Being able to provide data via APIs in different formats is pretty straightforward for us. The future of PSD2 in the UK is not clear – if it does come to pass, we will react. PSD2 opens up the opportunity to be a marketplace bank.”
BAML also views “PSD2 as just one of the reasons we are implementing APIs”, confirms Willems-Rosman. “It’s what the market is moving to and what clients are demanding,” she says. “This is happening across the world, and it’s a movement we feel that as an organisation we need to be a part of.”
That the trend towards open banking driven by open APIs is happening regardless of PSD2 is confirmed by the fact that APIs are high on the agenda of banks outside Europe which are not impacted by PSD2 – or are impacted only in a limited way. “We are not required to comply with PSD2 in our core market but that doesn’t mean we can ignore it,” says Mahoney at ANZ. “In our view, open banking and Open APIs are important for us because they will help to fuel the integration of our multinational customers operating or based in Europe. What’s going to happen is that these multinationals doing business in Europe will want to do business in the same way globally and if we want those multinationals as customers – even if we are not specifically impacted by PSD2 – we are preparing ourselves to operate in a world that operates in a similar way.
“We do have a strategy around opening up the front door and developing integration through APIs,” he continues, “though we have to respect the fact that a lot of our integration is done through traditional mechanisms.” That said, the bank is “working right now to create an API stack front to back across the organisation”, he adds, a strategy which includes “leveraging our APIs to external clients and aggregators to enable more retail consumer propositions”. Similarly, Langley confirms that NAB is engaged in “API enablement and restructuring internal architectures, technology and operations to better embrace third party capabilities”. “NAB has a robust API enablement strategy, covering some 150 internal APIs, among them external facing APIs. We are using a small number of technology partners to assist this process,” he continues.
So how challenging is it for established banks to keep up with the demand for open APIs? This will depend on the bank and the state of its existing technology architecture, suggests EBA’s Egner. “For large or multinational banks, it is a fact that they cannot transform legacy core systems into state-of-the-art architectures from one month to the next. Therefore, they need to build service layers to enable successful operation in the world of open APIs.”
It almost goes without saying that established banks with legacy systems will find it more challenging to open up via APIs than will new entrants with infrastructure built for an API-driven world. In this context, it’s clear that many traditional players are in the market right now for tools, such as API management capabilities, to help them tackle this challenge – which will, as mentioned above, be bigger for some banks than for others.
In Blomfield’s view, the challenges for banks is not in having APIs but in exposing them successfully. “The irony is that the banks all have APIs already,” he says. “If you use a mobile application to access your bank account, it’s fetching your account data from your bank’s existing API. “A2A” is just about publicly documenting those APIs and enabling third-party access.”
In the view of Denèle at BPCE, the banks are working on APIs already. “Several banks in France have already worked on APIs and are ready to make them publicly available in the PSD2 required time-frame – the way “true’’ APIs work: providing a URL and the code you need for access,” he says. “If as a fintech you want to code in the next 10 minutes, you can, and if you can’t it’s probably because you don’t have the right expertise. I am quite confident the banks will play their role. Of course it will take time but the banks are well used to complying by the due date, because we don’t have the choice.”
Fragmentation: the enemy of efficient open banking? Robert Oddy, Global Head of Treasury Architecture, Global Wholesale Banking Technology, BAML, plays down the challenge of aligning with the API trend.
“We have seen a lot of interest from clients in accessing client data through APIs,” he says. “From a digital strategy perspective payments have been electronic for 30 years. It’s not such a particular level of work internally. If you have existed in the capital market space, there have been several industry initiatives to bring standardisation – ISDA, TWIST, FIX – driven by the need to more easily exchange information. APIs are the extension of that into the corporate space. The industry has been good at doing this and what we are seeing now is more of an extension of these efforts of the past 30 years. It’s been done through a series of messaging based interfaces – not precanned and not on-demand – so it’s a significant shift to APIs, enabling the exchange of information as and when in snippets, with more interactivity. PSD2 is one trend driving demand for APIs, and our technology has the components to enable it, though they are not necessarily all connected yet.”
The greater challenge than creating APIs will be doing it in a standardised way, Oddy reckons. “It would be very easy for each bank to do this in a subtly different way, thus meeting the letter but not the intention of PSD2, which is all about commonality and synchronisation,” he says. “We have sufficient flexibility in our technology to deal with changing requirements, but there is the expense of doing so. We are trying to plot as short a line as possible to the future – we need a nice, clean, easy, straightforward path. In the context of the UK market there have been pretty good interactions so far, with HM Treasury at the forefront. In the wider European environment we are seeing less cohesion in the way this is being approached at this point in time, which may mean the result is more fragmented. If the EBA were to take the same focus that HM Treasury is pushing it would be a reassuring step and we would be keen to see that,” Oddy adds. Willems-Rosman agrees that “standardisation would be very welcome, because ultimately our clients do generally deal with different banks”.
Fragmentation is a threat – and would be a disappointing outcome, agrees Egner at the Euro Banking Association. “Our whole ethos at EBA is to encourage a pan-European approach when it comes to tackling industry challenges in the collaborative space,” he says. That said, he points out that some of the apparently ‘national’ activities under way are in fact a more solid base for a wider solution than they may seem. “For example, the banks in the UK that are responding to the requirements of the Competition and Markets Authority to improve the competitive landscape by introducing open banking by 2018 are international players, and they will want to see a framework in place that successfully supports the development of solutions that also work across borders.”
Swedbank is also pushing to see a standard for APIs, created by the industry. “We are having a dialogue with other banks across Europe to see what we have to do to come to a good standard,” says Nilsson. “The RTSs provide a framework but not a standard, so somewhere that will have to be done. We are fully open to doing something with the bank and PSP community.”
Chazot at HSBC also expects to see “collaboration between European banks in order to define implement these new standards for PSD2”.
The fact that the RTSs are not prescriptive on APIs does open the potential for the creation of numerous solutions going forward, agrees Versmessen at Swift. “There has to be a question about whether that will help the European consumer as much,” he says. “If there is a plethora of solutions, the uptake will be less good and will take longer. As a TPP, you will want one or two solutions to connect to different banks. If there are too many it will be a bit of a pity from an access perspective.”
For Rollin at Standard Chartered “if there is no standard, the industry will have all the downside and no upside” from open banking. “It will be very clunky if every bank has its own API, and says the fintechs must come to me that way,” he says. “We won’t have the upside of interoperability.”
Lyon at Fire expresses a contrary view. “There won’t be a standardised API – at least I hope not,” he says. “We need to have competition in data services as we do in payments. APIs are brilliant but if everyone makes the same APIs, they will be useless. We need to nurture the creation of good, smart APIs and then rely on aggregators – gateway providers – for API authentication. Amazon won’t integrate 1000 banks; they will use a gateway. We have already seen what a good thing technical access gateways for networks like Faster Payments are. In this way, PSD2 and APIs are creating the opportunity for business models that haven’t been there before.”
Denèle at BPCE agrees that now is not the time for a standard. “APIs have not been done. They are still to be done. It’s something relatively new, and starting on a standard now for something that is not yet in place would harm innovation and probably limit the initiatives that happen and will ultimately harm the ability of some players to operate in the way they want. A better journey is to leave the initiative to the market so everyone can do what they want provided it is compliant with the RTSs. If something is needed in terms of a standard it will emerge: there’s a time for everything, and it’s not the time for a standard. It would be quite incredible to see the regulators limiting innovation just at the time they are introducing regulation to foster innovation.”
The future of integration? If APIs can enable a next generation of services for corporates, moving on from what has been achieved via messaging services like Swift, and if APIs are positioned a new generation of integration technology, what does that mean for established communication methods used between banks and their customers going forward? One strand of continuity is suggested by the draft RTSs which push for the use of ISO 20022 in all exchanges between TPPs and account servicing PSPs. The text states: “To ensure the interoperability of different technological communication solutions, it is appropriate to require that account servicing payment service provider’s communication interface uses common and open standards which are developed by international or European standardisation organisations as well as ISO 20022 elements, components or approved message definitions, if available, since these standards are already widely used in the payment sector, between and within Member States.”
This is a positive development, suggests Versmessen, “because it means that all the payloads will be based on the same standard”. The ISO 20022 data field dictionary can be extended to cover any missing fields, he says, but whether the messages concerned have the coverage required would need to be verified – although it is important to remember that many PSPs are part of SEPA and are therefore already sending ISO 20022 messages, and that many TPPs will be banks.
As to how APIs and messaging-based integration will co-exist, Versmessen points out that they are “different technologies”. “APIs are useful in a typical client/server type environment where there is a need for frequent querying to be carried out. For bidirectional communication – where one bank would like to inform another directly that something has happened – messaging is better. You don’t want to have to query first. So there are advantages and disadvantages to both. An API could actually reach a wide selection of banks, but there could be a need for some complementary capabilities provided by messaging technology,” he contends.
On the question of how far the move to open APIs will herald change, Rollin at Standard Chartered says “APIs are not what is going to trigger a new marketplace for banks”. “You will still need a central authority or a central system or a blockchain,” he says. “APIs are not what will power the infrastructure for data to be exchanged. They will provide the ‘USB plug’ into that infrastructure.”
Change is being driven by other key factors – the underlying digitalisation of key trade documents such as invoices, the banks’ determination to better meet the needs of customers, and the trend to try to integrate the power of fintech innovation – and the main impact of and place for open APIs is in facilitating these, Rollin suggests. “If we really want these drivers to come into alignment, then that’s where open APIs come into play – providing a standard layer into which everyone can integrate.”