Being open about Open Banking means adopting technological change, even though there’s no requirement to do so. As Red Hat’s Justin Goldsmith, senior consulting architect, explains in the latest “State Of” discussion with Karen Webster, there’s impetus for U.S. banks to eye real-time payments and more, made easier with APIs — because, after all, customers vote with their feet.
To paraphrase a TV show that many are no doubt watching (or binge watching to catch up), replete with dragons, thrones and rather grisly games: The application program interface (API) is coming. The API seems to be on everybody’s lips, a catchphrase or buzzword for a sea change in banking that has the potential to upend the way we do business across any type of interaction.
In the broadest terms, APIs help speed the embrace of Open Banking, where banks’ data on accounts and transactions can be shared with third parties through the interfaces, with an eye on promoting the development of new apps and financial products.
For B2B, it seems, the advent of the open API cannot come fast enough. The back and forth between businesses, whether centered on payments or data, is mired in paper, phone calls and faxes — in short, wasted time and resources. New applications should streamline those inefficiencies.
In fact, as noted in the latest B2B API Tracker, a joint effort between PYMNTS and Red Hat, 25 percent of B2B transactions will occur through APIs by 2020.
APIs are most readily recognizable as having been codified in the Open Banking concept that debuted in the U.K. at the beginning of last year, but APIs have their place in upending banking in the U.S. as well. The most familiar change, though, is tied to the consumer (through their acceptance or denial of requests to share and use data).
There is not (yet) a mandate in the U.S. to adopt APIs, such as with the Revised Payment Services Directive (PSD2). However, according to Justin Goldsmith, senior consulting architect at Red Hat, in a discussion on the “State Of” APIs with Karen Webster, the impetus is there for U.S. financial services firms to cross the Open Banking Rubicon.
“If you look outside B2B or B2C, or consumer P2P, they are needed just about anywhere,” he said of APIs. “For banks to be competitive, they need to provide APIs.”
Otherwise, the customers and third-party providers that want to access financial data and gain insight into whatever financials they have at their banks will go somewhere else. Thus, he explained, Red Hat has seen growing traction among banks to build out APIs to support their own financial products and applications, in addition to granting access to third parties — tied to “the ability to look up data on payments, and even change the way they do payments.”
He offered the example of Mint, the financial services firm. Originally, he said, one would have to give the company “your actual bank password … and they had to store my password in plain text, so anyone might be able to access my bank account.” Now, the advent of third-party applications provides a more secure integration and less risk through means like tokenization.
About Time For Real Time?
In the U.S., another driver of API adoption comes courtesy of the real-time payments space, where a tailwind exists from the fact that as many as 56 real-time payment rails will be live domestically by 2020. In a B2B setting, this endeavor is one where banks can help businesses make payments immediately, said Goldsmith.
Easier said than done. As he noted, allowing banks to enable real-time payments means grappling behind the scenes with the fact that, as Goldsmith put it, “banks typically have various verticals that deal with their consumer banking or corporate customer … [regardless of the end user], real-time payments is the same.” Goldsmith recounted that his own experience has been one of working with clearing house, ACH and real-time payment rails, and building one system to enable faster payments. “The hardest part has been integrating with all of the various back ends because they are all different,” and banks “want the data a different way. Some of them are batch, still, and some of them are real time.”
There are, of course, mission-critical and legacy systems entrenched at the banks that trace their genesis across decades, and “these systems are being upgraded and modernized to handle [new processes] more easily,” he said. “It’s not an easy task, but is something that needs to be done.”
The Security Concerns
Security dominates top of mind for enabling API calls to go into the banks and offer data to third parties. Goldsmith said security can be viewed across a couple of different tracks, such as ensuring the protection of the endpoints in Open Banking (i.e., the parties requesting and accessing data). However, he noted that security becomes more complicated amid the growth in third-party applications, illuminating how important it is to view security not just from an “edge protection” aspect. He noted that the notorious Equifax breach came amid “a known vulnerability in an open source library.”
In short, he said, “when we are exposing APIs, we need to redo them quickly as regulations change or as we build new functionality. You are not going to have a year-long release cycle anymore … these applications are coming. And if consumers are using them, and one bank doesn’t provide the API that they need, maybe consumers will switch banks.”
We’re always on the lookout for opportunities to partner with innovators and disruptors.
Learn More