Why you must track “open banking”

At the end of a 50-minute interview, we asked Gareth Lodge this question: “For a mid-sized U.S. bank, of the various corporate payment-related initiatives discussed in your recent report, which would you suggest they have on their watch list?”

He doesn’t take long to respond: APIs and real-time payments.

Lodge, a senior analyst for Celent, based in the U.K., says that if a bank engages in both of these, the resulting capabilities will allow it to offer all sorts of solutions for customers.

These topics are less about payments than they are about what a bank can do for customers. It’s in contrast, he adds, to the one-size-fits-all and “You’ll get it when you get it” approaches that business customers too often get from their banks.

Open banking wave

API stands for “Application Programming Interface,” but in actuality the term means more. API represents a dividing line of sorts between old technology and new technology, as well as an almost cultural mindset.

APIs lie at the heart of the ongoing transition to open banking in Europe and many other parts of the world. In the U.S. APIs are the backbone of the fintech movement. They are also being embraced increasingly by banks here, but so far mainly among the largest institutions (with exceptions) in more limited applications than in countries where API use is now mandated.

Lodge says if he were running a U.S. bank, he would have at least a “watching brief” on how the global market is responding to the wave of open banking initiatives around the world. In addition to the U.K.’s Open Banking initiative—mostly implemented—and Europe’s revised Payment Services Directive (PSD2), scheduled to be implemented in January 2018, similar initiatives are under way in Mexico, South Korea, Australia, and India, Lodge notes.

Open banking is one of the topics covered in a recent Celent report, authored by Lodge, entitled Top Trends in Corporate Payments—2017 Edition. Altogether the report covers seven major trends: PSD2, the ISO20022 communication standard, real-time payments, cross-border payments, APIs, artificial intelligence, and GDPR (Europe’s General Data Protection Regulation, taking effect in May 2018). Secondarily the report also looks at blockchain developments relating to corporate payments.

Our interview with Lodge, however, concentrated on the significance of APIs and open banking to U.S. financial institutions. (A related article covering real-time payments cites several points made in the Celent report.)

European influence

Under the U.K.’s Open Banking initiative, it became “mandatory for the biggest banks in the U.K. to adopt and give third parties access to standardized product and reference data by March 2017,” as noted in the Celent report. Further, they must “provide secure access to specific current accounts in order to read the transaction data and initiate payments by January 2018.”

The PSD2 regulations, although somewhat narrower and simpler, according to Lodge, also mandate that banks provide third-party access to account-level information.

Taken together, these mandates are a “game-changer,” says Lodge.

He adds that many banks see the move to third-party access as a threat. And there is good reason for that. As Lodge wrote: “Some big retailers [in Europe] have been investigating the possibility of replacing cards by initiating credit transfers or real-time payments from their customers’ accounts.”

Further, he notes that banks subject to the PSD2 regulations (any bank that sends payments to or receives payments from Europe, per the report) are primarily using APIs to provide third-party access, and that “many, if not most, banks would seem to be aiming for regulatory compliant APIs. That is, what is required and little more.”

As stated in the report: “Celent believes that this approach will miss the opportunity that PSD2 presents to banks.” The opportunity is to use APIs as a differentiator.

Because open banking is not mandatory in the U.S., said Lodge, banks here are taking a slightly different approach.

“U.S. banks do see the benefits of open banking,” he said, but they “are being more circumspect about who they’re giving access to and what they’re giving access to.” Security issues are one reason.

Why APIs matter

Like many technology terms, “API” is used broadly and often loosely by some vendors, consultants, and the media. Application programming interface is hardly a new concept. We asked Lodge for some context as to why it matters now and what bankers need to know.

In non-technical terms, he compares APIs with the technology approach now typically used by banks.

“The way banking software typically has been built is as a product,” Lodge explains. “Somebody sat there and coded it—a black box that tended to work how a developer or bank built it.” When they wanted to add a new product, he continues, they effectively had to rebuild the black box again. “Until we had modern technology, that’s the way you had to build it,” concludes Lodge.

Companies like Amazon, he said, have built things in a very different way.

“Each process goes into a library,” Lodge says. As an example, he cites the process to “check card balance.”

“That becomes an API—a little process that is automated,” Lodge says. The “little process” can be reused multiple times by multiple systems across the bank as part of a library of building blocks.

Amazon founder and CEO Jeff Bezos wrote a letter, that, as Lodge recalls, says, “Anybody caught rebuilding something we’ve already built will be fired.”

In other words, says Lodge, Why reinvent the wheel every time you want to launch something new?

Fintech companies are built on APIs from the ground up, Lodge notes. As an example of why API capability matters for banks, he posits this scenario from the viewpoint of the head of a fintech company:

“If I was shopping around for a banking partner or a banking relationship, who would I choose? The one that speaks my language and is easy to integrate into? Or the ones who are still using old-fashioned industrial banking technology?”

In sum, Lodge says a growing number of banks see APIs and open banking as a strategic move, not only to better serve their own customers but to also win new business. He adds that the subject certainly is top of mind in the U.S. It dominated discussions at the NACHA Payments Conference earlier this year, and, says Lodge, NACHA is developing an API strategy body.

Is CBW the bank of the future?

Celent named CBW Bank, of Weir, Kan., as one of its 2017 Model Bank award winners. CBW is a very different financial institution that in truth is more a tech company than a bank. It is run by two former Google employees—the husband and wife team of Suresh Ramamurthi and Suchitra Padmanabhan.

Lodge said CBW completely rebuilt the bank’s software using APIs. As reported in a Banking Exchange interview earlier this year, Ramamurthi related how he launched a technology subsidiary called Yantra to develop the tools he needed because even after switching core vendors, he still wasn’t getting them.

Lodge says CBW will sell its technology to anyone—and Ramamurthi gets many visits from other banks—but primarily the technology is built to serve the bank’s corporate customers. CBW is creating complex customer solutions for clients, using real-time payments and other things that are connected directly into client software, such as a fleet management application for a trucking company.

“Because it’s all pre-built,” Lodge explains, “what CBW effectively is doing is a creating a work flow—that is, ‘what API is used in what order and what do we want it to do’.”

So the creation of custom solution for a client takes about seven days whereas for most banks it would have been either declared impossible or been a two- or three-year project.

“That’s why fintechs are so agile and quick to market,” Lodge adds. “Whenever they launch something new, 90% of what they need is already there.” They use their own library of APIs—some built themselves and some open-sourced.

By contrast, Lodge continues, many core banking systems can be 20-30 years old. These systems now have to support online and mobile banking and new types of payments, that were never envisioned by their designers. The connections for those products were not built in.

Two API approaches

We asked Lodge what he would suggest for U.S. banks in terms of doing more with API development than simply watching what others are doing. He says there are two distinct strategies:

1. Build a deep collection of APIs so you never have to rebuild again—basically what Amazon and CBW Bank have done. But rebuilding a core banking solution is difficult, expensive, and not something you do overnight. Which leads to the other strategy…

2. Build an integration layer. Working out what systems, what products, what connections you need to API-enable them. You’re putting an integration layer on top of your core system so it becomes API-enabled.

“If you had a magic wand,” says Lodge, “you’d do it all at one time, but people don't have unlimited budgets or unlimited time. So thinking about what provides the most value makes sense.”

He notes that one of the big U.S. banks is using this approach, so the decision is not necessarily size related.

All this, says Lodge, is not meant to be criticism of banks. He feels their pain:

“On the one hand we [analysts, et al] want them to be more agile and tech savvy. On the other hand, as customers of banks, we want our banks to be safe and secure. And third, we want good interest rates, which means banks need strong revenue and low costs. You can’t have it all, and I feel for them.”

That said, Lodge continues, “given what’s happening in the world with open banking and with the shift in what customers want and expect, we will see a competitive shift when some banks can meet those changes, and differentiate themselves.”