I’ve talked about APIs before from the perspective of how Open Banking Standards are creating exciting opportunities for the banking industry. In my conversations with industry leaders I still encounter occasional hesitation and this is nearly always based on justified concerns around security.
Any organisation that has consistently and responsibly invested vast sums in protecting its data and meeting the requirements of the regulators is likely to feel apprehensive about the notion of offering outsider access into its systems. One of the factors behind this feeling is that the financial services sector is now regularly shaken by news of fresh and increasingly ingenious hacker intrusion. So it’s only natural that a sense of trepidation pervades the boardroom.
Nervous or not the fact remains that, within any organisation, those who are charged with exploring and exploiting the API opportunity are facing new security challenges. They need to encourage the bank to open up and think differently about data and the commercial value it can deliver, shaping the bank to retain and reinforce its relevance in the future. Openness entails exterior access to data, in the form of APIs.
De-risk your API strategy
Best practice is to address security arrangements now, before plunging into the world of opportunity that APIs offer. It will create risks and complications if you decide to put it all in place once your API ecosystem is up and running.
At the same time it’s best to also address your strategy around monetisation; identify the areas and potential partnerships where you believe you will be best positioned to add value, attract commercial tie-ins, and increase revenues. Simply making your APIs available will not result in others beating a path to your door. There is an outside chance that it might, but you need to decide now how you can take the first important steps to meeting opportunity halfway.
Structuring the API
Banks do not have to provide access to all data to all comers. PSD2 will be mandating the types of information that banks will be obliged to share but there will still be a high degree of choice around the matter when it comes to going deep down into the vaults and announcing open house.
Layer your security in accordance with the objectives of each API. An API will expose a range of data which comprises a range of commercial values to others. Some will be merely functional and of no great commercial value, but simply composite information in the whole story. Other data will contain the gems, the reason organisations will want to deal with you in the first place. You should look to monetise some data whilst leaving other parts freely available. Once again, this is an essential first step, not a bolt-on. Once you make these distinctions, the security infrastructure should support the business model. Much of the security focus is ensuring the APIs are structured in three modes, to ensure that the appropriate level of data is exposed to authorised users:
- Open Public APIs (not a great amount of sensitive data here, fairly mundane) e.g. the types of accounts a bank operates
- Private APIs (these require additional security, login credentials)
- Internal: only to an organisation
Security and access to these APIs is managed by encryption keys, assigned to the authorised entity (person, app etc.). Effectively there is far less risk to customer data and privacy than is involved in exposing anonymised data which can be analysed by powerful algorithms.
The age of bigger thinking
Believe it or not, how you perceive APIs will also have a bearing on how effective your strategies will be for making the most of them, realising their commercial value. Traditional organisations have been caught on the hop before by new developments that have initially been all too easy to disregard and endeavour to marginalise by nonchalantly underestimating their significance.
My colleague, David Rimmer, recently published a blog in which he talked about examples of FinTech collaboration. FinTechs were largely ignored by traditional players for a while. Then they made significant inroads to the market very quickly and were then viewed as a threat. They disrupted the sector.
Now disruption has entered into the mainstream and many traditional players are learning from and collaborating with organisations to which they once wouldn’t have given the time of day. These disruptors have a high agility factor and an unrestricted approach to what’s possible – through sheer imagination and innovation. They have demonstrated to longer-standing organisations just how quickly fresh revenue can be accessed by taking highly relevant customer services to market and crafting the customer experience to reflect the modern lifestyle.
Not just another slot-in system
If you perceive APIs as an integration issue you need to get back to the drawing board pretty pronto. APIs bring a level of flexibility and dynamism to a bank’s systems that has not been seen before. To optimise these benefits, any approach that seeks simply to find the right connectors to link them into other systems will be missing both the point and the opportunity (whilst also creating a huge amount of re-work and realignment at a later stage).
My emphasis in this blog is that the first steps absolutely have to be well-planned. Forgive me for returning to the much used and oft-maligned analogy of a ‘journey’ but APIs are exactly that.
Integration involves tightly bound and coupled data, supporting connected systems. Being an API provider, which is how financial organisations should perceive themselves, is about providing external access to data. Its focus is accessibility. Any commercial partner should be able to access the data, as long as it qualifies in terms of security, regulation, and payment capabilities.
Where to now?
The API ecosystem is sitting there waiting for innovators to piece together the business opportunity that best suits their models and their customers. This is not a task that should be shunted over to IT just because APIs have an overwhelmingly technological ring to them. Bear in mind that the considerations of how individual APIs can be manipulated to expose sensitive data while ensuring security is not a normally a consideration of the IT development team.
One of the recurrent themes in the conversations I have with financial sector decision makers is in first identifying their current API Adoption maturity and then working with them to create their roadmap. ‘Comfort zone’ is a phrase for the history books. It’s time to board the train.