What was once unthinkable is now fashionable: a bank exposing its proprietary software to outside developers so they can develop their own applications on top of it.
Citigroup, BBVA Compass, Bank of America and Capital One are among the large U.S. banks that have been making pieces of their internally developed software code available to outsiders. Other banks are likely to follow.
The banks and others are sharing code through application programming interfaces software gateways that let applications work together. Some consider APIs a key to banks' survival and relevance in a mobile-first world. By sharing APIs to their proprietary software with nimbler, unregulated tech companies, the argument goes, banks can innovate much faster than they could by limiting application development to their own compliance-inhibited, resourced-strapped IT organizations.
"It's like breaking a few windows to let free air and light in," said Andres Wolberg-Stok, global head of emerging platforms and services at Citi. "It ends up benefiting fintech as a space."
The new openness is unprecedented, unless you look at other industries.
"Google makes their Maps API available. PayPal makes their payment API available. FedEx makes their location and tracking APIs available," pointed out Eric Connors, senior vice president of products at Yodlee, a company that provides account aggregation and API integration services to banks. For those well-known brands, the motive is to move more transactions or users through their systems.
For banks, the main driver is innovation. By sharing APIs, in some cases through hackathons in which outside developers are given software tools for a prescribed amount of time with which to build new apps, new ideas can be generated and tested.
In Citi's case, this was a natural extension of the bank's efforts to use APIs internally to integrate systems and channels.
"For banks that are large enough and that have sufficient complexity, there's a big incentive to use APIs for their own channels, so the opening up begins at home," said Wolberg-Stok. "Once you start going down that road, you start to see the attraction of, in our case for instance, the Citi Mobile Challenge giving all these very smart people at fintech startups and other companies a way to build something on and with Citi, which leads to great ideas making their way into the organization."
BBVA Compass made a set of authentication and payment APIs available to payment network provider Dwolla this year. The bank and Dwolla worked together to develop a way to authenticate customers and tokenize their credentials such that no personally identifiable information is passed to Dwolla. Yet Dwolla can link to BBVA accounts and move money in real time.
"We're bypassing the traditional ACH model, which by the time you do deposit verification and transfer the money could take three to six days," said Chad Ballard, director of mobility and new digital business technologies at BBVA Compass. "We're allowing that all to occur in real-time."
A second reason banks are giving outside software developers access to their code is so tech-savvy business customers can create their own banking services. A pioneer here is Silicon Valley Bank, which has some of the largest U.S. tech companies in its client base.
Today, the bank lets its tech company clients access its products through tools using the OFX standard. (OFX, or Open Financial Exchange, is a unified specification for the electronic exchange of financial data among financial institutions, businesses and consumers via the Internet.)
"We're working with clients to figure out what we can do to make it easier to interact with SVB," said Megan Minich, head of product development and channel delivery at Silicon Valley Bank. "We're starting to create an API platform that we plan to launch later this year."
The effort will play a big role in the bank's overall digital transformation, according to Minich.
"What APIs have done as a technology is change the way companies expect to interact with each other," she said. "The API platform will allow us to leverage the things we're good at, like authentication and payments, and provide a new paradigm for innovation. By building out this platform that will open up to certain key clients, I think it will grow tenfold."
Some clients might use the APIs to pull their own account information into their own systems, such as an enterprise resource planning program. Others might try to be more inventive. For instance fintech startups might come out with new payment products.
"We focus on trying to stay relevant to our clients. We think this is a really important way to do that," Minich said.
A third reason banks are exposing APIs is they're a good alternative to screen-scraping when working with aggregators like Yodlee and Geezeo. Account aggregators can pull account information from other financial institutions into an app that, for instance, lets a customer see how well she's sticking to her savings goals across all her financial relationships. Through the time-honored process of screen scraping, the customer provides her online banking usernames and passwords; the aggregator logs in as her and "scrapes" her account information into another app. This approach has limitations and risks.
"There's only so much fintech aggregators can do in standoff or arms-length mode," said Wolberg-Stok. "They have to ask their users to [share] their credentials, which creates potential challenges of trust." Aggregators have to figure out how to connect to banks' systems, which is time-consuming, and keeping track of changes on each bank's website is a challenge. APIs are a much cleaner way of accessing the needed data, he said.
Sandboxing the Bank
Of course, banks have to be selective about what software and services they give third parties access to.
"It's not like letting someone connect to the bank's systems," said Wolberg-Stok. "These APIs are like soda straws -- they provide very narrow, well-delimited access to certain data points that you choose and you control. You decide who gets to use those APIs." Clients would need to log in with their bank credentials, but the bank can also decide who's entitled to use its APIs, so it doesn't become a free-for-all.
In its hackathons, Citi provides sample data, rather than real, live customer data.
"In something like the Citi Mobile Challenge where you could have a lot of people trying out a lot of new and different stuff, you would never want customer data to be accessible," Wolberg-Stok said. "But you want to make the API as realistic as possible, so that whoever is developing something doesn't have to go back to the drawing board this is good, but now go try it out in real life."
The more experimental the app, the less willing a bank would be to provide access to real data, he said. Well-known, established, trusted aggregators might be given API access to live data.
Some have argued that the sharing of APIs will hasten the unbundling or disaggregation of the financial supply chain (read: traditional bank services), by enabling smart aggregators to pick apart the chain and reassemble the pieces in new ways.
Wolberg-Stok sounded unconcerned about that scenario.
"I would see it as an opportunity to go meet our clients wherever they choose to live their digital lives, instead of forcing them to come to a Citi channel all the time," said Wolberg-Stok. "The extent to which that unbundling might take place is something that remains under the control of banks. The bank decides which APIs to open up and which ones not to open up." For example, a bank might choose to provide an aggregator read-only access to checking account balances, but not transaction data.
"There are layers of value," Wolberg-Stok said. "No one is forcing you to expose anything to an API that you don't want to expose as an API. It's up to you as a bank where you put the barrier, where you draw the line."