Application Programming Interfaces (APIs) in Transaction Banking
Introduction to Mobile API development
Within the Financial Services industry, we are always looking for the ‘next big thing’. Whether this is disruption from Mobile Payments, Cloud, behavioural biometrics (non-invasive) through to Distributed Ledger Technology (Blockchain) or Artificial Intelligence (machine intelligence).
Why do we do this? In terms of the consumer base, there has been a massive uplift in their understanding, expectation and usage of technology. Long gone are the days where a few “technically minded people” hold the keys to understanding what technology can do. Now it is de facto and many understand what’s coming over the horizon too. This creates a dynamic that is a challenge for us to keep pace with. Clients are more technically focused, agile and demanding than we have ever known so we continue to look for that new idea, an edge in the market place or new paradigm that will make our services as an IT — and Technology Consultancy stand out to those now technically proficient.
Ever Decreasing Circles
Against a backdrop of a client’s more advanced view of technology and interaction capabilities we face up to the pressures of:
Cyber Security & Financial Crime concerns
Regulation, regulation and more regulation
There is typically less investment, less time to deliver and higher levels of focus on security, which really impacts our focusing and delivering what is needed in the competitive market today.
We see Fintech providers leading the disruption by providing the kind of services and applications, that we wish to provide to our client base, bringing forward good ideas and just…well just getting on with it. It has a feeling that they have the keys to this new City without perceived constraints — 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? Yes, and no.
Yes, we should be in control of 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 those trusted third parties — if there are issues it is not as if we could not change the locks. But how do we do this? How is an ‘Open Banking Ecosystem’ created and yet controlled at the same time?
Often the obvious means of achieving this autonomy is through provisioning Application Program Interfaces (APIs) and robust Software Development Kits (SDKs) for the APIs. But how does this help?
It enables a process of empowering our commercial clients and also shares the burden of innovation with them. We can instil an innovation mind-set proving that Banks can think outside of the old box.
Let us use this opportunity to give them the keys to our City. One secure and manageable way of doing this is by creating and providing APIs for services and investing time to help our clients use these services effectively — not a radically new idea but one worthy of further commitment — especially now.
The API Conundrum
APIs are about finding a practical balance and exposing services in a secure and manageable way. There needs to be pragmatism. Complete openness does not work. Banking APIs are not something that should be published onto Open-Source platforms and leave exposed to an unchecked user. It requires a significant level of control to enable transactions in a secure and trusted manner.
The Old Foe — Security
Security is key to any successful end to end transaction, and to maintain the levels of trust and security, it’s important to ensure the implementation of an exchange that is trusted by both parties, whether through certification, 2-Factor Authentication or the newest approaches to authentication and encryption. Security remains pivotal in maintaining the relationship and success of any transactional system in a world of cyber vulnerabilities that seem to appear on a daily basis.
What many APIs still rely upon is that the consumer, the “customer’s customer”, is required to validate themselves with our client — all too demanding? Many of us, as consumers, perform this behaviour regularly with Apple Wallet and Google Pay today. We find it normal on a personal level, but as Banking professionals we are still trying to retain ownership of the full payment chain which itself is becoming hard to achieve. So what does good look like for an API?
APIs That Tick All the Boxes
In my opinion, a successful API is one that sits comfortably in today’s world and enables, not detracts, 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 revenue and highlight new commercial opportunities. As cash itself becomes secondary in the transaction lifecycle, APIs should start to fill the voids that contactless payments cannot. Internet of Things (IoT) can already be seen to drive low value transactions in the same way that mobile devices do today for app and other purchases.
It is 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 — using automated transactions and a Banking API between the consumer, the supplier and the Bank. Regular purchases such as bus tickets, road toll payments and service supply subscriptions can be achieved this way, retaining security in this Ecosystem. Again, we must always acknowledge to the need for security. If APIs are successful, they will answer many questions faced in the drive towards Open Banking.
APIs in the real world
Based on MHC’s longstanding experience in a large number of projects of this type, the most successful were largely those service providers which allowed the client to ‘augment’ these payment processes into their own application (be it mobile or web-based). For one Tier One Bank, this meant opening the payment processing and all of the required handshakes and exchanges to them, enabling them to adopt and brand the transaction in their own way in order to suit the service they wished to provide.
This allowed the client and their consumers to maximise a User Experience driven model where the old approach simply would not work (rather like the evolution from Chip & PIN to Contactless Payments — it is about trust, collaboration and experience rather than security overload).
PSD2, Open Banking and the API
In a recently published article, MHC Associate Director 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. APIs can 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 Payments can already feel ‘old’ — so we must create flexibility in how we answer the questions to come; and it seems, that exposing services via APIs is the only cost effective method to do this.
New business, at a lower Total Cost of Ownership is after all never a bad thing.
About the Author
Oliver Parker is an experienced Associate Partner at Mansion House Consulting with a wide range of Business Analysis, Programme — and Project Management, Technical, Functional and Business Strategy skills. His background is highly technical, centred on the development of complex mobile and Internet Apps and Application Integration projects.
About Mansion House Consulting
MHC is an international business and technology consultancy, focused exclusively on the financial services sector. We provide high quality, practical and robust solutions for the industry through our team of highly experienced consultants and subject matter experts.
We specialise in change and transformation management, toolkits, regulatory and governance frameworks. We deliver solutions globally to the transaction and investment banking communities, including leading Tier One clients from the financial services industry.
Established in 2009 we have been expanding and evolving ever since, with a team in excess of 300 and listed in the Sunday Times Tech Track 100 on four consecutive years 2013–2016, the London Stock Exchange’s 1000 Companies to Inspire Britain 2015 as well as the Investec Mid-Market 100 list in 2016. Headquartered in London, we have a global presence through offices in Frankfurt, Singapore, New York, Jacksonville (Florida) and Bangalore (India).
To find out more about our services around Infrastructure Technology Service, visit our website www.mansion-house.co.uk or contact:
Managing Director — Infrastructure Technology Service
Mansion House Consulting Limited
40 Gracechurch Street
+44 (0) 20 3440 3770
This publication has been prepared for general guidance on matters of interest only, and does not constitute professional advice. You should not act upon the information contained in this publication without obtaining specific professional advice. No representation or warranty (express or implied) is given as to the accuracy or completeness of the information contained in this publication, and, to the extent permitted by law, the Mansion House Consulting Limited Group, its members, employees and agents do not accept or assume any liability, responsibility or duty of care for any consequences of you or anyone else acting, or refraining to act, in reliance on the information contained in this publication or for any decision based on it.
© 2016 Mansion House Consulting Limited. All rights reserved.
In this document, “MHC” refers to the UK entity, and may sometimes refer to the MHC group network. Each MHC entity is a separate legal entity. Please see www.mansion-house.co.uk for further information.