Imran Haider, head of Wells Fargo Gateway and its APIs, says the bank is positioned to be a leader in developing the behind-the-scenes software that will provide the product customization and flexibility customers will come to expect.

Established by Wells Fargo in 2016, Gateway is an enterprise API channel encompassing all the bank’s business lines. Through this developer portal, commercial and corporate banking customers can integrate Wells Fargo products, services and information into their own digital environments, such as back-office systems, apps or websites.

APIs essentially give customers access to their accounts anytime, anywhere, from any device, in order to accomplish their banking goals in the fewest steps possible. Use cases span across payments and data services, including tasks like account aggregation, identity management, ATM locations, and foreign exchange.

In an interview with Bank Innovation, Haider discussed his vision for APIs and how the bank is keeping things simple for developers. An edited version of Haider’s conversation with BI follows.

Bank Innovation: How long have APIs been in use and why are they taking off now?

Imran Haider: If you think back to mainframes and some of the earliest machines, APIs were built to connect those different software applications and allow them to talk to each other. In any technology, there is a sort of democratization or advancement of that technology. APIs have moved from being complicated and difficult to use, and difficult to implement, to a modern version that is really easy to use for developers — and very fast, from an implementation perspective.

BI: How does Wells Fargo use APIs?

IH: There are two aspects to that. The first way is inside the company, where we’ve got thousands of different APIs. The advantage of an API is that it’s built in a modern or “microservice” architecture. What you do is you build a service once, and then many different applications can use that service. If you build an identity verification service, for instance, then you can have numerous applications within online banking or other channels, all using the same API to do that one task. If you go back 10 or 15 years, you would have had each application built out, sort of as a parallel system. So, there’s some efficiency and speed of development that APIs bring internally to the bank.

On the Gateway side, we’re bringing those solutions to customers, wherever they want to use Wells Fargo, in any digital experience. If you think about banking, especially transactional banking, like paying bills, buying items, or checking your balances, it’s all about access and distribution. What our customers tell us is, “We would like to be able to access Wells Fargo anywhere,” and we’ve followed that strategy for many years, building branches, building ATMs, online banking, mobile banking and, now, APIs.

BI: How does Gateway work?

IH: Basically, you would have a company interested in connecting to Wells Fargo, they would come, view use cases on the developer portal, and ask for access to particular APIs. We would go through a vetting process and provide their developers with access to a secure site, where the developers can then access documentation, view code examples, and get access to a sandbox to test their software with the API and begin building out their application. When they’re ready, they sign a contract with Wells Fargo and we give them access to a live production environment. At that point, if the API is implemented, we’re very focused, almost obsessively, on developer experience. We want to make it really easy and simple. My rule of thumb is, a developer who comes and looks at an API and doesn’t know anything about banking should be able to look at the spec and, in 20 to 30 seconds, understand how the API works. It should be very intuitive from a design perspective. No jargon, no bank lingo, that somebody wouldn’t understand.

BI: How simple or complicated can an API get?

IH: There can be very simple, easy-to-use APIs, and then there are APIs that connect to a foreign exchange system, which can be a little more complicated. If there is complexity, we don’t want to put the burden on our customer to try to figure that out, so we process and organize that complexity behind a curtain and then provide a simple front end, or spec, to the developer. In general, how easy an API is to implement varies not so much by the use case, although it’s somewhat by use case, but by the knowledge and tech savviness of a customer. If you go back five years, maybe 10 years, an integration between a bank and a customer would take probably a minimum of six months, maybe 12 months. We’ve been able to simplify that integration process to where companies can, in a couple of weeks, get access and be up and running, providing solutions to their users.

BI: What’s in store for APIs in 2019?

IH: I think we’re going to see a lot more use cases and a lot more companies interested in connecting to their bank. If you think about the wholesale customer base, every company in America, or in the world, wants to be a digital company — whether they’re a manufacturer or a healthcare company or a media company. Everyone wants to be strong in the digital space and APIs are really the building blocks of digital experiences.