Mark Boyd on banking APIs changing one of the stodgiest sectors

Mark Boyd is a writer and tech storyteller focusing on open data, smart cities and especially APIs, focusing on API breaking news, business models and how APIs are leveraged to engage citizens.

There’s no doubt that with the rise of fintech startups and new open banking standards, the banking sector is feeling pressure, just as it’s regaining its footing after the financial crisis. The application programming interfaces or APIs emerged as a way for the industry to abstract away its legacy architecture and move towards a more agile, technical approach that’s in line with a cross-departmental, company-wide, customer-focused business strategy. To learn more about the the API economy’s effect on the banking industry, we sat down with tech reporter and API analyst Mark Boyd after he’s interviewed dozens of banking and tech strategists of how they are using APIs to drive strategy for this white paper on the topic.

How about we start by you telling us a little bit about your background in the API economy.

I’m a writer for ProgrammableWeb and TheNewStack where I focus on APIs. I was also program chair of API Strategy and Practice [APIStrat] for 2015, and I’ve worked in urban planning and public health for the last 15 years, mostly around opening up datasets, community engagement, user-focused design, population health and urban planning. Seeing the API advantage, one of the things I’m excited about  is to explore how APIs could be used to help build local economic development and address health and urban planning challenges.

What is the current state of software in the banking industry today?

Banking is a very traditional sector that’s very slow-moving when it comes to new technologies, and also it has a lot of technical debt in the industry because they’re using a lot of legacy systems that have been built up over years. It has seen a lot of trends with how IT has been coded and stitched together with varying functionality, often through a range of different new services and languages.

Often, IT was just asked to get it done, so they would get in, write the code to make something happen, and then move on. There wasn’t necessarily a culture of documentation around why decisions were taken or why certain technology or architectural decisions  were made. And because of this, there’s no link with the broader agenda of the enterprise, there’s not really an understanding what the roadmap was meant to be for any specific service or functionality that was added on the fly.

What is the opportunity for APIs in the banking industry?

Because of that legacy, APIs offer a very important advantage because they allow banks to update their infrastructure and allow banks to be more customer facing.

This year [2015] has seen a marked change. As late as December last year [2014], banks were saying, ‘No way. We’ll never open up APIs and make them available to external parties.’ Whereas this year [2015], it’s increasingly been an executive decision to move forward with an API strategy.

Why did this change happen suddenly?

Post the 2008 financial crisis, I think banks have realized that they have to rebuild trust with their customers and that brings them to customer-centric ideas.

Also there are a lot of fintech startups that are disrupting the banking industry especially around payments, and banks are feeling a lot pressure to build up agility.

Finally, there are growing consumer demands for the ability to access a wide range of services via mobile, or to have them integrated into the interfaces and portals that customers choose, and banks are seeing that they need to meet the customers there.

On a regulation front, in the last year, the U.K. introduced an open banking API standard and across the Eurozone, there are requirements coming in a few years for any fintech institution to open up access to payments services — the PSD2 Payment Services Directive.

Regulation is always something that makes the banks sit up and listen more.

Where is the API economy taking the banking industry?

Our research saw this as encouraging the banks to take a move toward a more customer-centric approach. One way that they are doing that is moving toward a technical architecture that is more flexible and responsive.

After talking to 22 banking executives open to talking about APIs, we found that the leaders around APIs  were focused on specific features and characteristics, and generally had a few things in common:

1. Executive sign-off and budget attached to API strategy: Leadership banks had C-level support from the CEO down for a customer-centric strategy that meant leveraging APIs to create new digital services and to automate workflows and internal data sharing. The best banks gave innovation or architect leads some budget to build prototypes and test examples. Amongst this group, business units were aligned via a policy or plan to have goals that required creation of APIs as well. This was a marked contrast to those where there was executive sign-off but the lead then had to advocate to other senior management around the business value and opportunity of APIs, and needed to build business cases and argue for a specific budget for each idea needing to be implemented. The slowest movers were often trying to build APIs in a skunkworks type approach and then hoping they could demonstrate the value afterwards to their executive.

2. Predominantly looking at reorienting their architecture with a build-and-replace program: Within banks, a large proportion of current IT spending goes towards maintaining legacy systems that are a jumble of code and have been built over the last 20 or 30 years. Understandably, banks are worried about having to move these systems wholesale to a more flexible, modern design as a lot of their security reputation is tied up in their existing systems so they are very cautious about changing any of that. Also, because the codebase is such a jumble, they are also concerned that, if they move one thing, other parts of the system will stop working because, like any industry, code documentation often ends up being a last concern and why someone built something one particular way is lost to time and staffing changes. But the bank leaders are taking a build-and-replace approach and as they go through and steadily create new REST-driven APIs, they are making sure that goes deep into their system and isn’t just a surface level interface on top of the spaghetti code. They are slowly rebuilding and reorienting: it’s the ‘one bite of elephant at a time’ approach.    

3. Consolidating their internal services, in packages of services, bounded context and domain-driven design: All banks have built out service-oriented architecture and point-to-point services and all the rest that might speak to one small bit of data: check an address, calculate a balance, etc. That means banks might have thousands of services that need to be converted to REST APIs. So the leadership—what we call API pioneers—are using this as an opportunity to understand domain-driven design and are bundling similar services into the one microservice. A microservice might be designed around all the data points that might be needed to make one change to the system of record data. For example, any data or process that is involved in payments might be bundled together as a microservice and then there is one API build for that, which means maybe retiring a whole bunch of SOAP services when the REST API for payments is up and running.

4. Tended to use an API definition format like Swagger, RAML or API Blueprint: Banks with leadership and an eye to the future are trying to avoid the mistakes of their past. So using an API definition format is helping them better document—and to create a culture of documentation—around API design and implementation, as well as preparing themselves so that, if at a later point they want to open up APIs to authorized access by partners or third parties, they can do that fairly easily and external users can use the definition format to understand what the API does.

Are banks moving away from SOAP?

Banks are using microservices to adjust and break away from their legacy architecture. Through their build-and-replace program, they are going to create new REST APIs to replace their SOAP services, as others are building a REST interface on top of SOAP services.

A lot of these enterprises are working with a predominantly SOAP-based architecture. The best practice is to decommission your SOAP and replace it with REST, but that’s sort of tricky with a lot of these legacy systems because there’s not been a lot of good documentation. They’ve just gone through and created changes one-offs. You see a lot of the technical debt that’s coming and you can’t even untangle that spaghetti code and see why one of those decisions was made at any given time.

They see it as almost the stages of grief. The first one is like complete Denial: ‘No, no, we can’t touch the legacy system. Don’t touch it. Don’t talk about it.’ Then the Bargaining Stage of ‘Maybe we could leave it where it is and then sort of build on top of it.’

What about containers in the banking space?

Yes, they are experimenting with container technology. Amongst the banks we spoke to, there was a move toward testing containers for pilot projects, but overwhelmingly there was interest in seeing how this architectural approach could eventually be deployed in production across the enterprise.

You said APIs are helping banks be more customer-centric. How?

The customer-centric move that they’re taking is building an API roadmap so they have a clear picture for the next six months that they want to develop—usually payment APIs and customer transaction history so customers can understand their financial histories and payments. Then the next suite is also related to improving customer responsiveness—allowing customers to modify their credit card limits via API or payment transfers via API.

Another thing that banks are doing to ensure that they are more customer centric is the way they’re measuring engagement. In the past, banks were looking at a monetization model—what is the sale-ability of a new products is and the uptake in the market. Now they are taking a more customer-centric view and measuring levels of engagement—how many times customers are using their product and how much time spent. All this is built on top of APIs.

What other API-enabled trends are you seeing in banking?

The bank leaders we spoke to are all sold on the idea of an open banking platform. An open banking platform would see banks make APIs available that external developers can use to create new applications and services. For example, a customer might give consent to an app to check the transaction history and build a predictive savings engine that would help the customer achieve financial planning goals, or a startup could create a dashboard service where a customer could look at all their financial information from multiple sources in one place. Those sorts of services would need banks to open up access via APIs to the bank customer’s data and use authentication APIs to ensure the customer’s consent had been given. Open banking platforms are expected in the next two to five years, but that is not the internal culture within their banks at the moment. You can see early steps that are being taken by banks to see that they were moving in that direction when they are ready: things like uptake in API definition formats like Swagger and RAML—which will make it easier for third party developers to understand an API when it is opened to them—and many banks are also sponsoring startups, innovation labs and hackathons. There’s a great-looking hackathon coming up from Emirates NBD for example. In a huge move [this March], Capital One has become the first major bank to create an open banking platform with their DevExchange. It’s a bold move way ahead of the other banks. Now BBVA and Sutor Bank are following that lead in Europe.

But overall, most banks are instead focusing on building internal APIs with a view to opening them up in the future—building the capabilities now so that they can pretty much flip a switch down the track and ensure security is in place to only let authenticated users have access. They are treating their internal developers like external developers. They are trying to build these kind of classy APIs that are attractive to users.

What will the API economy look like in five years?

That’s a tough one because we are still so very much at the start of what impact APIs will have, and five years in technology is a very long time! I’m most excited by Dion Hinchcliffe’s take on APIs: he reminds us that, according to ProgrammableWeb, there are only around 14,000 open APIs. Imagine a time when we only had 14,000 websites. Steve Sammartino made a similar comment in Melbourne at APIdays Australia recently when he mentioned that the car was only built 150 years into the industrial revolution, and API researcher at CA Technologies has said that in eight years, three-quarters of the S&P top 500 companies will be new businesses that you haven’t heard of yet. It means anyone can come along and create a viable business.

We are still very much at the dawn of the API economy and the most exciting thing for me is that anyone can get in there and build market share and grow a real business. Some of the today’s strongest tech companies didn’t exist even five years ago, and APIs are helping accelerate that competition turnover and the impact of disruption. My hope is that in five years, the API economy will have been responsible for leveling the playing field and allowing a lot of new market entrants to emerge based on their knowledge, innovation, creativity and diversity, rather than the industry being locked down by existing powerful players who have the money and resources to keep new players out.

What advice do you want to offer developers to join the future of the API economy?

Dogfood your own APIs. That will show you the best practices fastest and give you ideas about API design best practices from the user’s point of view.

What are your three favorite apps? (Not the ones you like the most, the ones you really use the most.)

I use Evernote, Google Drive, Dropbox, Sunrise, Ulysses, Slack, Skype, Pocket and Spotify pretty much daily. Out of those I would say Spotify, Evernote and Ulysses are my favorites, if you really just want three.

Who is the must-follow, undercover API expert?

I would keep an eye on the blog at Capital One DevExchange, they are really leading the thinking around how to implement open banking platforms. I also love @JackGavigan Jack Gavigan’s blog for a European and UK perspective.

Please comment below or share your thoughts to @APIEconomist and @mgboydcom on Twitter!