The API in Transaction Banking

Within our industry we are always looking for the ‘next big thing’, from mobile payments, cloud, biometrics and behavioural biometrics through to Blockchain and Artificial Intelligence (machine intelligence).

Why do we do this? Well in terms of our consumer base there has been a massive shift in the understanding of technology and indeed in usage of technology by our consumers. Long gone is the day where a few technical minded folks (I’m steering away from using the word nerd here: as I belong in this group) hold the keys to understanding what technology can do. These days everyone has this, and most even understand what is coming on the horizon as well. This creates a dynamic that is hard for us to keep pace with……our customers are more technically focused, agile and demanding than we can keep up with, so we are always on the lookout for that impossible idea, edge in the market place or new paradigm that will make our services stand out to the tech-savvie public and client base.

Ever decreasing circles

Against the back drop of our clients more mature view of technology and interaction capabilities we are struggling with our own pressures;

• ·       Tighter budgets
• ·       Cyber Security & Financial Crime concerns
• ·       Regulation, regulation and more regulation

So let’s face it, we have less money, less time and higher levels of focus on security which really doesn’t help us, focus and deliver what’s needed in the competitive market of today.

What we are seeing is Fintec disrupters providing the kind of services and apps that we sorely want to provide for our client base, stealing all the good ideas and just…..well just getting on with it. It almost feeling like they have the keys to our city at no cost and with no benefit for us – so what do we do? How can we change this?

The Keys to our city

So it’s our city, we should have the keys right? Well yes and no.

Yes we should control how access to core banking platforms is provided and used, yes we should control who has this access, yes we should monitor and control the gates. But why should we have the keys? Why can’t we give the keys to trusted third parties – if there are issues it’s not as if we can’t change the locks. But how do we do this? How do we create our own ‘Open Banking Ecosystem’ and keep control at the same time.

For me one way of doing this is through provision of APIs and robust SDKs for the APIs. But the question is how does this help?

Well it starts the process of empowering our commercial clients and also shares the burden of innovation with them, as banks we can sometime be accused of not thinking outside of the box, but our clients do it more often and with more success.

Let’s use this by giving them the keys to our city – one secure and manageable way of doing this is by creating and providing APIs for our services and investing time and effort in helping our clients use this services effectively – not a new idea but one worthy of further investment – especially now.

The API conundrum

APIs are about balance, exposing the services; in a secure and manageable manner. Complete openness will not work, banking APIs are not something you would publish onto Opensource platforms and let the world use, and abuse them. It’s a controlled mechanism for commercial clients to engage with us (the banks) and process transactions in a secure and trusted manner.

Having been involved in a number of large projects of this manner the successful ones in my opinion are the ones that have allowed the client to ‘merge’ the payment process into their own application (be it mobile or web based). For one Tier One bank this meant opening up the payment processing and all the required handshakes to them; allowing the client to brand the transaction in their own way and to suit their service being provided.

This allows the client and end user to make the most of a user experience driven model where the old models do not fit (rather like going from chip and PIN to contactless payments – it’s about trust and experience rather than security overload).

The old foe security

Security is as always a key to any successful end to end transaction, and in order to maintain the levels of trust and security we need to make sure we implement a handshake that is trusted by both parties, be this through certification, 2FA or some other new manner still the brainchild of a bank technical team. This is still key to maintain the relationship and success of any transactional system and our own sanity in a world of cyber vulnerabilities that appear on a daily basis.

What an API does however do is leave the reliance on the end user (our clients customer) to validate themselves with our client – all too strained? Well we are all carrying this trust mechanism out with Apple Wallet and google Pay today so it’s nothing new to most of us from a personal perspective, but as banking professionals we are still trying to own the full payment chain which in today’s world seems a little strained. So what does good look like for an API?

APIs that tick all the boxes

For me a successful API is one that sits comfortably in today’s world, does not slow down our clients in their drive for innovation and maintains the security we desire and require so much.

 It should open up our services to trusted parties and increase our revenues in ways we were planning but also in new and surprising ways. As cash becomes more and more of a second class citizen in transactions an API should also start to fill the voids that contactless payments cannot. I can see in the very near future the Internet of Things (IoT) driving low value transactions in the same way that mobile phones do today for app and other purchases.

 I can’t see the business case right now but it’s the next logical step that for example a connected device that uses consumables is authorised by the owner to make purchases on their behalf when consumables are running low – the only way for this to work would be through automated transactions and a banking API that enables these for the supplier. Regular purchases such as bus tickets, road toll payments and service supply subscriptions could also be driven this way. But they need to be secure – again we must always pay respect to the need for security. If APIs are successful they will answer a fair number of the questions faced in the drive towards Open Banking.

PSD2, Open Banking and the API

In a recent publication my colleague Grant Osborn points toward PSD2 Open Banking, and specifically mentions APIs as a way of answering at least some of the challenges around flexibility to address commercial goals. I believe that APIs go one step further and create co-ownership with clients and partners – spreading the cost of innovation and potentially shortening the time to market for services.

APIs benefit the entire payment chain and a well-defined and supported API will be an attractive selling point to commercial clients, in other words; done well it should drive business development for banks.

We do not know what will drive the next payments challenges yet, but the world of Chip & PIN and contactless already feels very ‘old school’ to me - so we have to create flexibility in how we answer the questions to come; and it seems to me that exposing services via APIs is the only cost effective manner to do this.

New business, at a lower Total Cost of Ownership is after all never a bad thing.