'Data Wants to Be Free': Why Banks Should Open APIs to Others

Dan Kimerling, head of API banking for Silicon Valley Bank, is nothing if not blunt.

"The biggest problem banks have is that they're run by bankers, not software engineers," he said to a room full of bankers at American Banker's Digital Banking 2016 conference in New Orleans on Wednesday. "Banking will eventually become a software business, because all they do is move bits. They call it money, but it's just bits."

No one in the ballroom batted an eye. (These were digital bankers, after all.)

Fourteen years after Jeff Bezos famously put out a memo to all of Amazon's software development teams, ordering them to create application programming interfaces for every program, some bankers say their industry ought to do the same. And it's not just the ones in Silicon Valley.

"It has to be part of the DNA of everything we build," Chris Thompson, chief architect at Orrstown Bank of Shippensburg, Pa., said at the Wednesday panel discussion. "APIs can't be a bolt-on or an add-on after the fact."

Twice, Thompson used a modified version of a famous tech industry rallying cry: "data wants to be free."

"It's already floating around," he said. In many community banks, critical functions and business processes are handled with stale copies of data in flat files.

"An API can make that staleness go away," he said. "Especially in certain risk scenarios, more timely access to data can create a compelling business case."

Silicon Valley Bank was one of the first banks to offer APIs to its commercial clients, which include some of the largest tech companies in the world.

"Our customers demand API accessibility and real-time interoperability," said Kimerling, who joined the bank last year when it acquired his startup, Standard Treasury. "Customers don't understand why they can't interact with anyone over API. We recognize how much an open architecture helps in our own business." Such architecture helped the bank forge a partnership this year with hypercool payment processing company Stripe, and similar partnerships are expected.

For community banks, Thompson said, the oligopoly of core financial technology vendors gets in the way of fully exploring an API strategy.

"It's an ecosystem of products where we have a little bit of flexibility to customize, but not to radically alter the platform capabilities," he said.

Banks can mitigate the problem by presenting a united front to the vendors, he said.

"Finding like-minded bankers who are willing to think about what the right solutions are and then ganging up on Jack Henry, Fiserv and FIS to alter features is effective," Thompson said. "If you come with 50 other financial institutions and say, 'We all want this, can we all support this?' we can force a little bit of change."

Kimerling suggested that community banks should make their core systems open-source. "It's galling that these three companies are holding back so much innovation," he said. "Red Hat gives away their software and people pay Red Hat for service and support functions. So why isn't there a business that does this in the core banking space?"

The sharing and mining of customers' data raises clear security and privacy issues, but panelists argued they could be easily overcome.

"There's been a debate around whose data is it," Kimerling said. "I think that's a bit of a canard. It is the customer's data. We can acknowledge that for what it is. But when you look at other companies like Google, gmail is your email, but Google sniffs the digital exhaust and monetizes that digital exhaust. In banking, by trusting us with their data, customers give us some right to monetize the digital exhaust. I've been surprised by how the banking business has not followed Google's lead by mining the data and monetizing it with ads or something."

Thompson said Orrstown Bank has been working on data monetization. "You can look at the commercial entities in our system, the money they have, who the guarantors and co-signers are on those loans," he said. "You can look at that and map a social graph of where the money is and the centers of influence in communities and use that as a prospect list. Our customers trusted us. They've taken out a line of credit with us. But we can leverage that data without getting creepy."

Financial institutions feel more obliged to not be creepy than tech companies, Kimerling said. "The way I look at it, Google has an amazing amount of data. In fact, my gmail account is way more valuable and important to me than my bank account. Why aren't we way more aggressive about monetizing data?"

Nicole Sturgill, analyst at CEB TowerGroup, said the problem is that consumers distrust financial institutions. ("A reasonable distrust," Kimerling quickly added.)

"We know that as an industry, banks are going to get blamed a whole lot faster than Google if they are seen to be using a customer's data in a way that consumer doesn't like," Sturgill said.

The best use case for APIs in banking, in her view, it to figure out what to do with internal data.

Banks, she said, "don't even know how to use it internally well to serve customers better, to offer products and services that are customized for them, to minimize risk."

Kimerling brought up the debate over screen scraping (a practice to which banks increasingly object, citing security and practicality issues). "The problem is that banks don't allow open access to their data," he said. "If banks allowed their customers open access to their data, you wouldn't need scrapers, you wouldn't need aggregators. And as customers want to do more things with their own data, banks need to invest in their own data infrastructure or collaborate with third parties."

Thompson agreed. "Customers are going to share their data whether you enable it or not," he said. "They could do it in a comfortable way that you understand and support."

Editor at Large Penny Crosman welcomes feedback at penny.crosman@sourcemedia.com.