By Hugh Cumming and Vinay Prabhakar for LTP

Open APIs promise to fundamentally transform the experience of payments for end-users, ranging from private individuals to global corporations. Whether driven by the global rise of FinTechs and real-time payments, or by regulations such as PSD2 in Europe, it’s clear that the momentum towards open APIs is now irreversible. As a result, it will soon be the norm for consumers and businesses to obtain account information and initiate and track payments using third-party applications that connect directly into banks’ systems via public domain APIs. But this isn’t just a big change for customers – it also brings huge implications for banks, not only around how they source, manage and use payments technology but also around how they differentiate themselves in the payments marketplace.

Application Programming Interfaces (APIs) are neither new nor as complicated as their name suggests. Originally developed 15 to 20 years ago in the era of enterprise systems and service-oriented architecture (SOA), APIs are software tools that enable different systems and applications to talk to each other and share processing and data. In their early days, APIs were largely internally-focused, proprietary and non-standardized, meaning they were inaccessible to the outside world and that substantial customization work was needed to link to them. But today, with the emergence of open APIs, their role and importance have escalated to a whole new level.

The big differences with open APIs are that they’re visible externally and easier and simpler to access – and their emergence over the past decade or so reflects the rise of the developer as a force in corporate IT. In an era when enterprise software was traditionally procured by the central IT function, open APIs emerged as an almost grassroots response to enable new software to be developed on top of other products and platforms. To meet these needs, open APIs share a number of characteristics. They’re developer-friendly and developer-centric; accessible from outside the corporate firewall; built using web-based programming; and “fine-grained” and standardized, enabling developers to take advantage of multiple APIs from multiple vendors and attach new utility to existing systems quickly and easily.

These qualities have seen open APIs take off rapidly in industries such as technology and social media. Now these same attributes are positioning them as a disruptive and potentially revolutionary force in banking and payments. Traditionally, banks have built, owned and controlled the channels and applications through which customers access their services – be a retail customer checking their balance online or undertaking a mobile transfer, or a corporation initiating a batch of cross-border payments. With open APIs, third-party developers can gain access to banks’ systems and build their own channels and interaction screens for customers to use. The result is that customers are able to see and manage their banking transactions and accounts through portals that the banks haven’t set up and can’t directly control.

Multiple Drivers for Adoption of Open APIs

For both banks and the third-parties tapping into their systems, this is a seismic shift that’s being driven by a number of forces. A specific driver in Europe – and one that may have wide implications globally, depending on how the rules are interpreted – is the European Union’s second Payments Services Directive (PSD2), which mandates that banks must open up access to accounts, payment flows and end-customer data to third-parties approved by those customers. But even without such regulations, the global move towards open APIs in banking is unstoppable, for two main reasons.

The first is the rapid worldwide emergence of the FinTech industry, delivering a constant stream of innovation focused on meeting customers’ financial services needs more effectively, especially in areas like payments, mortgages, and financial management for small and medium-sized enterprises (SMEs). All bank customers – including major corporations – are now demanding payments, cash management and treasury service experiences that mirror the speed, ease and convenience provided by consumer applications and devices. They don’t mind whether these solutions are provided by their bank or a non-bank third-party – and the rise of FinTechs means the latter is increasingly the case.

Banks are eager to harness this innovation quickly and flexibly within their own offerings to win and retain customers. To help them do this, they’re moving away from purpose-built solutions to an environment where they assemble solutions from a series of vendors, using open APIs as the “glue” to link all the components together and create the customer experience they’re seeking to deliver. This approach generally involves using software-as-a-service (SaaS) platforms, where applications can be provisioned easily at low up-front cost, and then dialed up and down as needed. For example, a bank looking to attach a mortgage calculator to its website is now more likely to attach a third-party solution via open APIs than create one from scratch.

The second key driver for adoption of open APIs is the growing need for real-time service experiences and information, including the ongoing implementation of real-time or “immediate” payments infrastructures across the world. This trend means the traditional model of creating batch files of transactions and sharing them via an FTP site is no longer fit for purpose, with organizations and applications needing to exchange data in real time – a requirement ideally suited to the use of publicly-available APIs. Among banks, a leader in this area is BBVA, which has effectively published its entire banking platform on the Internet for other organizations to innovate around. This move reflects the wider pivot in the software industry from products to platforms, enabling problems to be solved faster, more efficiently and more holistically.

The Basis of Banks’ Differentiation Shifts

As these forces play out across payments and banking, different regions of the world are progressing at different speeds. For example, Europe has advanced more quickly to real-time payments schemes, with North America only now catching up. Yet while the starting-points and speed of progress may vary, the trends we’ve described are driving a common direction of travel, a global convergence towards a new basis of competition and differentiation between banks.

Historically, banks competed against each other on the strength of their own services and technology portals – which, until recently, were almost invariably developed, owned and managed internally. This is no longer. Now they’re moving to a world where the basis of differentiation has shifted to two other criteria: first, their core transaction banking services and fees – essentially the transactional “engine” into which third-parties can integrate their customer-focused front-ends; and secondly the quality of the open APIs they offer to enable third-parties to achieve this integration. In this context, the “quality” of the APIs comes down to the accuracy, timeliness and comprehensiveness of the information they can share. For example, do they enable a customer to track the progress of a cross-border transaction along the value chain in real time?

Back-Office Fragmentation Can Hamper High-Quality APIs

However, for some banks, the ability to provide open APIs that deliver comprehensive, high-quality, real-time information can be hampered by their existing back-office systems and data. If a bank is handling different types of payments using different systems, it can be very difficult to pull together all the information needed to feed into an API that meets the needs of a wide range of third-parties. Also, the value and utility of a payment message are increasingly determined by the commercial and contextual information bundled around the core transaction: for example, a healthcare payment might carry useful data about the insurers who will cover it.

All these factors throw the spotlight onto the ability of banks’ back offices to support high-quality APIs. If a bank’s payments systems resemble spaghetti at the back-end, then the API on the front-end will need to make sense of it for third-parties, and do so in real time – a big challenge. So banks seeking to develop open APIs must take a long, hard look at their back office systems, and decide whether these are up to the job of delivering all the necessary information in real time.

Addressed Through Payments Hubs

In many cases, they may not be capable of doing this – which means the bank needs to act, possibly by re-platforming to create unified systems more fully aligned with the needs of open APIs. This requirement is helping to fuel the accelerating adoption of payments hubs, which bring together the handling of all types of payments on a single platform. Combined with the move we’ve already described towards SaaS, the potentially valuable role of payments hubs in an open API environment opens up two main implementation options for banks.

The first option is on-premise deployment, where banks integrate their preferred API technology into the payment services hub. This model should ideally allow for real-time payment initiation and inquiry all the way from the point of demand by the end-user in the third-party application to the execution in the payment hub. Banks should also look for a solution that offers an extended suite of highly granular services for everything from debit authorization to fee calculation to payment submission.

The second option is hosted applications. With this approach, the bank utilizes a hosted service that houses all the software and hardware required to run its payments operation, under either a multi-tenant service bureau or dedicated managed service model. In an open API world, the solution should enable third parties – payment initiation service providers (PISPs) and account information service providers (AISPs), in the language of the EU’s PSD2 – to connect directly to secure, controlled APIs housed within the infrastructure. Ideally, the chosen solution should combine the benefits of pay-per-use provisioning of best-in-class technology for payments processing and execution, with one-stop access to the world of open APIs.

Clearly, whatever approach banks take to open APIs, security is a key issue. Organizations across all industries are moving from a world where security was defined in terms of “guarding” to one where effective security can only be accomplished through “sharing”. The best example of this shift is the disruptive power of blockchain technology, where strong security can be achieved through a capability that’s both open and public. So while opening up systems through APIs does present risks, these can be overcome through the right technologies and collaborative approaches.

Embracing the API-led Future

Overall, it’s clear that banks must actively embrace the move to open APIs in order to secure their role and position in the new ecosystem of financial services and payments. Achieving this will require banks to develop a clear vision of their future, and reinvent themselves as technology businesses to turn that vision into reality.

Open APIs are rapidly emerging as a vital cornerstone of the future of banking and payments services. Banks must move now to build them into their business – or face playing catch-up in the years to come.

First appeared at LTP