Open application programming interfaces provide a secure, effective and efficient way to enable third-party developers to build applications and services around a financial institution, accelerating innovation in the industry, as Heather McKenzie reports.
September 2019 is a date that looms large for European financial institutions. From that month they will be obliged, under the revised Payment Services Directive (PSD2), to give third-party payment providers (TPPs) access to their client accounts (with the express consent of the client). PSD2, alongside the UK’s Open Banking, is driving the uptake of open application programming interfaces (APIs), which are seen as the most secure and effective way to provide access to accounts. In the cash management world, this move to open APIs could herald the delivery of services that streamline and reduce the cost of payments and improve risk controls.
While open APIs are not new, they are relatively uncommon in the financial services world and in particular the commercial banking sector. One of the main drivers of APIs in commercial banking is the move away from the ‘walled garden’ of the bank ‘black box’ interface towards an open banking system, according to Thomas Nielsen, chief digital officer at Deutsche Bank.
“The proposition of open banking, where clients can pick and choose services, is closer to being realised,” he says. “Clients are demanding this, and financial institutions realise that each of us is good at different things. It is better to be open than remain closed, as has been demonstrated in other industries, such as mobile handset manufacturing.”
While much of the early API development has been focused on PSD2, the scope has now gone beyond the regulatory space, according to Kieran Hines, head of industries at research firm Ovum. “This is where, as a bank, you can potentially charge for services. There is potential to monetise direct connections to corporates or to third parties providing services,” he says.
Ecosystem engagement
It is one thing being open, but to be successful, financial institutions have to be attractive to TPPs and other API developers. Banks should bear in mind that, as Mr Nielsen stresses, “open banking and APIs are not a threat – there is a much bigger opportunity for banks in the solutions that can be created on an open platform”. For example, he says, financial institutions will be better able to integrate cash management into corporate clients’ enterprise resource planning (ERP) systems, creating greater transparency and reducing friction. Solutions will enable financial institutions to get closer to their clients and the corporate treasurers will spend less time on mundane jobs. Open banking and APIs will enable banks to move upstream and get closer to the end user.
In April, Deutsche Bank and fintech company Serrala launched an API interface for Single Euro Payments Area Instant Credit Transfer (SCT Inst). A part of the Serrala FS2 Payments for SAP solution, it will enable end-to-end automation of payment processes through integration in corporate treasuries’ SAP ERP systems. The bank and fintech claimed a first with the launch, given that previous SCT Inst solutions required mostly proprietary bank systems. The launch means corporates can initiate payments instantly through their SAP ERP systems.
Open APIs have the potential to deliver a platform that is “exciting and transformative”, according to a October 2018 white paper from Swift, ‘APIs: Delivering a Global Platform for the Financial Services API Economy’. “API solutions are rolled out (and torn down) quickly, updated regularly, and often provide access to proprietary, value-added services rather than globally standardised business processes,” the paper states.
Security concerns
But challenges remain, and foremost is security. Open APIs are agile and simple, which means in theory that anyone can develop and publish their own API specifications and update them whenever they wish. However, this leads to fragmentation; inconsistencies in business specifications and in identity and security frameworks negate the potential for universal reach and undermine the ability to switch between service providers quickly and easily and to aggregate data and services from multiple sources to create new services, says Swift.
This fragmentation occurs at multiple levels, including business specification, identity management and security and data protection. Differences in regulatory specifications across countries can increase the costs and risks to banks, particularly those operating in multiple countries.
Mr Nielsen says that if an API is open to everyone, the security model around that, including authentication, has to be rethought. “If we want APIs to be global, banks have to avoid falling into the trap of fragmentation where local deployment differs from the global goal,” he says. “The wonderful thing about mobile operating systems is that apps work in the same way in the US, the UK and Pakistan, for example. Banks, however, are used to local development, partly because of regulation but also because of the traditional bank set-up.”
Ovum’s Mr Hines says open banking and APIs could be viewed as a new area of risk for banks. For example, customers – both large corporates and smaller businesses – might receive marketing information from TPPs to download apps but have no way of validating the authenticity of the TPP. The activity going through TPPs needs to be addressed, he adds.
Additionally there is a challenge around dispute resolution. “In a retail context, credit card companies have developed dispute resolution procedures over a long period of time,” says Mr Hines. “But the scenario with real-time payments is open to question; customers may assume the protections they have with credit cards will be the same for real-time payments.”
For corporates, the question is who carries the liability if errors are present in balance data from a TPP’s API and a corporate has acted based on incorrect data. “These are quite big areas that are challenges for the industry. The regulations leave some areas unaddressed,” says Mr Hines.
The need for standards
Swift identifies standards as an important issue for API development. In its white paper it makes a broad distinction between bespoke APIs and industry standard APIs. Examples of the former include a bank’s proprietary payments overlay service, or APIs published by a central provider such as a Bloomberg price feed for the Swift gpi Tracker. Bespoke APIs are used to expose a dedicated service, which may be entirely internal to the bank, but may just as easily be exposed to external users. Industry standard APIs, on the other hand, are exposed by multiple service providers as part of an overall community or industry initiative. Examples include the PSD2 Payment Initiation API and the Pay Later Loan Initiation APIs.
David Bannister, a senior analyst at Aite Group, says it is difficult to standardise APIs. “You are looking at combining heavy-duty technologists who care about the data level API formats such as Representational State Transfer with businesspeople who want APIs that are more about the process and what data is to be exposed,” he says. “Also, standards in the API world are not very mature. It is like version 1.0, they are being rewritten constantly.”
Mr Bannister says a number of organisations are working on the issue of standardisation, including the Berlin Group, STET and the UK’s Open Banking Implementation Entity. The development of standards and the accompanying business practice across Europe, and the rest of the world, “takes longer than everyone thinks”, he adds.
Revenue potential
It is still early days for APIs in financial services and some banks do not yet view them as a potential profit centre. However, by making a bank attractive to TPPs and other API developers, a bank can offer revenue-generating services to clients. Standards will make it easier to work with others and will help to amplify the services of those banks to a wider market. Like many aspects of financial services, collaboration will be the bedrock of open banking and APIs. Jake Rebuck, lead on open banking and APIs at management consulting company Capco, says banks should view API developers as clients who will “proliferate your services and pollinate the outside world”.
APIs level the playing field, according to Nick Armstrong, CEO of blockchain start-up Identitii. “Banks need to continue to up their game if they are to remain competitive,” he says. “And while they still have an advantage, thanks to their relative position at the centre of the payments ecosystem, non-bank challengers could take 30% of revenue, from corporate banks in particular, over the next five years.”
In cash management, says Mr Armstrong, the clear opportunity for API connectivity is to bring several technologies together to vastly improve the customer experience for corporates as they interact with their bank.
Deutsche Bank’s Mr Nielsen says taking an open approach raises difficult questions about whether the bank owns the entire customer journey. “[But] there is no reason why Deutsche Bank cannot provide a platform for some of the digital banks that are emerging, for example to provide a platform for cross-border transfers and foreign exchange,” he says. “This represents a change in philosophy, business model and technology approach. If we don’t do it, we might end up as dinosaurs.”
