When banks say ‘I do’ – an API love story

Leda Glyptis believes banks needn’t be afraid of the API era. They should build a workforce that can deliver a future that’s shared and interdependent.

One of the very first slides I had to produce for my boss in my first ever banking job was entitled ‘Change is the new normal’. A decade and a half later, the conversation hasn’t changed much. We talk of disruption in the same part-smug part-startled tones, we organise conferences, produce slides and run pilots. Yet, the realities on the ground have changed a lot: executives are learning tech terms they never thought they would need to understand, and speaking to kids in jeans who they never thought they would have to tolerate. Things are changing, and with all our conferences and pilots and presentations, we can (if nothing else) be safe in the knowledge that we’re keeping an eye on things and there will be no hidden surprises. Right? Wrong.

You don’t find love, love finds you

While we’ve been busy curating convoluted conversations about blockchain, and ring-fencing analytics pilots with more failsafes than nuclear tests; while we’ve been committing to accelerators and ‘partnering’ with startups in superficial minimum-commitment ways and long sales cycles, the API brigade (anthropomorphise them for me for a second, will you?) walked in, unpacked, settled in and waved cheerfully. The silent revolution happened while we were busy arguing about DLT. APIs seemed innocuous compared to other disruptive forces: they were known, and to a certain degree used, in banking already, extensively used in ecommerce and digital service delivery. They were a thing we understood, or at least the IT folks in the basement did. They were fine. Right? Wrong.

Something old …

APIs are known. We understand how they work. We trust that they are real, relevant and robust. That isn’t the problem. The problem is everything else. Open banking suggest and PSD2 (as well as many corporate clients) demand that banks should leverage APIs to deliver their services going forward. That means that the service itself, the systems hitherto used to deliver said service and the data that said service boils down to, need to get suited and booted and ready for this brave new world. Easier said than done. Banks have legacy infrastructures. That isn’t shorthand for “bad” or “outdated”. Far from it. But it is a clear label suggesting “we were solving a different problem when we built this”.

Existing infrastructure was designed to service silos, jealously guarding its data and accepting a high degree of manual manipulation of data sets to deliver results to clients. Every single one of those facts has changed and every single underlying assumption no longer holds. The infrastructure, however, hasn’t changed – it still holds, it works fine – so a thing that works fine has to be changed, at great cost, because the world around it changed. Oldest story in the book. Yet, this doesn’t mean it’s pleasant, or easy, because the other thing that suffers under the legacy banner is the mindset that built and used the legacy infrastructure, day in day out. Banks are organisms, and the systems are as much a product of the experiences and context of business as the people who designed and operate them. The advent of APIs and open banking baffles the mind as well as the motherboard.

… something new

Like most relationships, this one also started with a misconception that wasn’t clarified early enough: there may be nothing new about APIs. The disruption isn’t in getting your head around them, it’s in getting your head around what they can do to your business model given what they’re doing to your market. APIs require a whole new infrastructure and present sizeable challenges around architecture, design, data integrity and so on. Yet, these are the (comparatively) easier beasts to tackle, hard as they may be, because once you’ve tackled those, you think you’re done. But it’s then that you’re faced with three seemingly minor (but actually massive) hurdles to overcome, three hurdles that, if you successfully overcome them, will transform your organisation entirely. So you’d better take pause, take stock, and while you are at it, a deep breath wouldn’t hurt.

– You know how to hire a dude to cut an API, but do you know how to manage an API developer? APIs allow system to system connectivity. That means that for the first time in the history of your firm (unless you are eBay) your devs have a direct impact on your bottom line and the greatest control over your strategy execution. Does your organisation know how to manage these fresh graduates in order to help them understand the impact their routine acts of coding have? Does your organisation have the ability to re-stack itself and articulate the purpose of its enterprise in a way that will drive the subtle changes a developer can bake into your API store? We are not talking strategy here. We are talking coal-face. Plus, with your margins shrinking and a different work ethic emerging among digital natives, you are competing for talent with employers who offer a more relaxed environment, a more fulfiling way of working, more respect to the individual and their quirks and (dare I say it) potentially a much more emotionally or at least intellectually engaging work subject. These guys have options. Have you thought about what it takes to keep them? Because you need them and they don’t need you. You have finally understood the value of UX, but have you thought of DX? Welcome to the new world.

You know how to develop a service, but do you know how to price an API call? Capitalism is all about making money. There’s no shame in it. Over the past century and a half, banks focused on the services and developed the products that would make them the most money. Systems and disciplines were honed to ensure the delivery of value in the service of the creation of value: I will do that which you need so you will pay me. Simple motivations, complex mathematics. Enter left, the API brigade (remember, they settled in while you weren’t looking). APIs open a world of possibility, but they also short-circuit and shorten processes, they take a lot of processing out of the equation, and they take a lot of packaging and beautifying out of the mix. You still deliver the ‘thing’ you were getting paid to do, but you visibly and patently do less in order to deliver the thing. So your client inevitably and inexorably wants to pay less to get the thing that you now do less to deliver. Look at your value chain: see what you do that’s deemed valuable for the client and what they’re happy to pay for it. Can you identify where the API brigade will allow you to deliver and extract value at the same time? These decisions are hard. Are you confident that your board and executive management know how to make them? And if they don’t, are you confident that they will ask for help?

Are you as smart as you think you are? Client management is a golden standard in banking, and client data is acknowledged as the holy grail of value creation. Banks sit on a wealth of facts that, if properly harnessed, analysed and understood, could deliver incredible insights that would permit product tailoring, cross- and up-selling to the nth degree, as services would feel bespoke to the client you know so well. Furthermore, given the population size for which banks hold said data, additional services could be devised to reflect the shifting needs of the market. The data is there, the analytics discipline is there … just not in the same place. The banks have the information. But the legacy, the silos, the pressures of the day job, regulatory gospel and a whole host of other reasons mean that information is there, but it doesn’t yield insight in any real sense. (Or at least those who have the data can’t make sense of it, not enough to truly justify the value we all agree it has.) Yet, once the advent of the open API allows access to third parties, who have the analytics capabilities and the vision of what story they want to tell, who have the ability to do what the bank couldn’t do with the data it had, then what?

Something borrowed …

Banking has often indulged in the caricature of itself as the anti-fluffy space: no bright colours, no everyday language, no comfortable clothes, no emotions. The fintech wave is challenging all of this, borrowing relational language and economic models from a non-capitalist paradigm. And APIs are native to this ‘other’ environment. What does that mean when it’s at home? Inside your organisation, it means that you need to truly understand the mechanics and purpose of collaboration. That means reward it, encourage it, expect it and understand it. It means provide the necessary tools, from desks and screens that allow people to work together, to platforms and software that allow for the sharing of content, thoughts, images, burn down charts and whatever else needs to be shared. It doesn’t matter what you think of Slack and Periscope. What matters is that you’re changing your infrastructure to something that rests on a handshake – a meeting of two parts.

You need to build a workforce that understands what kind of conversation you need to have so that they can build infrastructure that delivers it. You are no longer a fortress. It will take some getting used to. Outside your organisation, this gets even harder. The very language of APIs is uncomfortable: APIs are exposed. You cannot hide what’s behind them, which is the whole point, but it’s also the scary part. It’s not how we’ve historically worked and it feels like walking in borrowed shoes. Add to that the unspoken spectre of sharing economies: you don’t just share data in this brave new world, you also share business.

Under PSD2, platform economics can really come to life. Layers of services will make money together, will seek and generate value together. Less money will be made on an instance by instance basis, as profit layers are stripped away by transparency and regulatory fiat. And what’s left of the pie will be shared by a bigger and not universally happy digital family.

… something blue

Let’s not beat around the bush here: having to invest in infrastructure for the pleasure of making less money is rendering decision makers in wood panelled rooms very sad. Not because they’re greedy but because they were charged with safeguarding the profitability of a successful entity, and on some level they cannot deliver against their mission in light of events and changing circumstances. They were meant to do something the facts of life no longer support. Don’t feel sorry for them, but understand that nobody wants to be the guy who will pass on a corporation less profitable than when he was entrusted with it.

The point is: it doesn’t have to be this way. Yes, APIs make everything more transparent: what you do, what you charge, what people get: all this is no longer conveniently obscured by fortress walls. So yes, per function, per existing product or deliverable, you will make less in this new API universe, but that doesn’t mean you will make less overall. Banking evolved because some very smart people thought up very smart ways to solve problems (sometimes caused them and solved them, but you catch my drift). Commercial and retail activities still need money. Transactional and corporate life still needs banking. Finance still needs banking. New technology permits the visualisation of new value, brand new capability building, new services, new ways of making money. This isn’t going to be the old price tag for the old effort. This will be ‘new new’ value in a brave new world.

This story can have a happy ending for all parties when we finally come to terms with the fact that the future is shared and interdependent.

About the author

Leda Glyptis

Leda Glyptis is a lapsed academic and long-term resident of the banking ecosystem, inhabiting both startups and banks over the years. She leads, writes on, lives and breathes transformation and digital disruption. She is a roaming banker and all-weather geek. All opinions her own. You can't have them.