Open Banking: Is the U.S. Ready?
The most immediate challenge to open banking in the US is its many definitions. We’re often told that the movement here is “institution led,” meaning it is driven by market players rather than government regulation as is the case in other geographies like Europe. This idea that the industry is embracing data-sharing and collaboration without any push from the government is generally seen as promising. But it’s important to understand what that means. While US institutions have a unique opportunity to define open banking on their own, that freedom also means there are many different perspectives, engendering confusion that makes it challenging to chart a path forward.
For those that haven’t begun to play here, trying to make sense of it all can seem like a daunting task. Ultimately, for all but the largest and most progressive players, it is the domestic core banking providers that set the pace for innovation for a financial institution. To understand where the US is on its open banking journey today, we must grasp how these companies are defining the concept and approaching it. We must also explore those banks that have made real progress and learn from them. Only then can organizations begin to assess their own positions and develop strategies for the future.
In this report, we will take a look at what open banking means in the US and around the world, the core banking providers at the forefront of open banking in this country, those banking institutions that have capitalized on the opportunity successfully, and what it all means for banks just beginning to embark on open banking.
What is open banking?
The concept of open banking originated in Europe with the implementation of the Revised Payment Services Directive (PSD2), which mandates that banks make consumer data available to third parties at the customer’s request. It’s generally accepted that the most effective way to meet this requirement is to develop application programming interfaces (APIs) that allow data to be shared securely between the bank and external parties. In some places, like the UK, the use of standardized APIs is specified by the regulators. APIs have long been used in and outside of financial services to allow different systems to talk to each other — ride-hailing app Uber was built using Google Maps APIs, for example. Open banking mandates around the globe aim to encourage wider use of this technology to foster competition and give customers greater control over their data and how it’s used.
Open banking traditionally refers to the ability to share data, and specifically, consumer data. But, once those foundations are in place, a whole host of possibilities opens up, from the ability to quickly integrate and deploy new products to Banking-as-a-Service (BaaS) models that allow financial institutions to embed their products into third-party platforms, thereby “licensing their charters.” There are two distinct sets of capabilities here: one is the ability to share data (read only); the second is the ability to share bank functionality (read and write). The first is the principal idea behind open banking regulation around the world, but the latter is where a lot of the discussion around open banking in the US falls. That’s because those additional capabilities like BaaS come from being able to share bank functionality with third parties. Now, it’s important to note that the ability to share bank functionality is unlikely to ever be completely open in the PSD2 sense. Because it requires write permissions, or the ability to issue actions, there will generally need to be some level of management of the relationship between the bank and the third party. The open banking movement in the US centers on getting bank systems to a point where that control is a question of oversight not technological limitations, and institutions can support both sets of capabilities easily.
In the US, we’ve seen institutions operating all along the capabilities spectrum, and interest is accelerating — 92% of banks surveyed by Finastra in 2020 were looking to leverage APIs to enable open banking capabilities in the next 12 months, up from just 69% in 2019.1 On one hand, we have big players like JPMorgan and Wells Fargo inking data-sharing deals with open banking platforms like Plaid that are designed to make customer data securely available to third-party fintech apps that consumers want to use. And on the other end are banks like Cross River and Celtic Bank, which power financial products provided by some of the biggest names in fintech like Affirm and Square.
These moves are being driven by multiple factors:
Consumer use of third-party apps. Consumers have made it clear that they want to be able to use third-party apps; one in four consumers with a US bank account has connected to an app via Plaid.2 Absent secure access to this data, these apps will largely pull down what they need via screen-scraping, which requires users to share their login credentials. That means that financial institutions have an interest in building direct connections that will keep their systems more secure.
Heightened competition. The push toward digital from larger banks, coupled with the emergence of popular fintechs that focus on niche problems for consumers, has put a squeeze on everyone else. According to the FDIC, the 4,000 or so US banks with under $1 billion in assets hold about 5% of all bank assets, while a couple of decades ago that stood at about a third.3 Embracing open ecosystems allows banking institutions to tackle this problem in two ways: They can facilitate access to third-party services their customers desire to keep their overall value proposition more attractive, and they can deploy their own services in a BaaS model, broadening their distribution.
M&A activity. Although the pandemic put a damper on deal-making early on, M&A activity is already picking up again heading into the new year. And it’s likely this will continue as bank valuations normalize and the economic outlook improves. In fact, a report by FJ Capital Management suggests that not only will M&A accelerate in 2021, but also that the number of banks in the US could decline by 50% in the next decade and a half.4 API-enabled infrastructures make integration easier. So, for banks looking to acquire, opening up now could make plugging in different solutions less of a lift in the future, while for others, ensuring their systems can easily integrate could make them more attractive acquisition targets.
While banks and credit unions may pursue API enablement for any combination of the reasons above, the central benefit is fairly straightforward — it makes it easier to build and participate in ecosystems with third parties, which is increasingly critical in today’s environment. Nearly half of global financial services institutions surveyed by PwC say they have fully embedded fintech into their strategic operating model, and just 4% report having no strategy for fintech at all. In particular, working with third parties can be very attractive to institutions with limited resources looking to keep pace on capabilities. But, from an execution perspective, things are a little trickier. As mentioned, for most institutions, the first step will be looking at the options offered by their core provider.
How core providers are responding to open banking
By this point, the leading core providers in the US — FIS, Fiserv, and Jack Henry (JHA) — all have API strategies. None of these providers have achieved openness by the standards set in Europe; even their read-only APIs cannot be hit freely by third parties at a customer’s request. However, they have created models that enable data access with varying degrees of openness. Below we take a look at how each is defining and approaching the concept of open banking and what it means for their clients.
A note on APIs: Not all APIs are created equal. As such, their availability doesn’t necessarily make them useful. An API is a set of programming code that allows one computer program to share data with another. Depending on the design, data format, and specifications of an API, it can be easy to use or more challenging. Additionally, APIs are not a catch-all for success; legacy systems can be difficult to integrate with regardless of the APIs available, due to complexity and outdated naming conventions in the programs the API needs to talk to. Even with a well-written API, integration will often require knowledge of the core. When assessing different API strategies, it’s important to consider exactly how they are built and used to determine their utility.
FIS
FIS’ open banking strategy in the US is built around its Code Connect platform. Code Connect provides a centralized API gateway and marketplace where developers and FIS partners can access FIS APIs. Additionally, the platform offers a number of API connections to third-party partners. Core systems exposed via Code Connect so far include its Modern Banking Platform, IBS, and HORIZON. The platform is designed to create a consistent way to connect third parties to bank systems and data, and to connect banks to third-party data they may want to use.
There are three ways for a bank to leverage the Code Connect marketplace:
- FIS API integrations. A bank looking to integrate with a third-party partner can access the FIS APIs it needs through the marketplace. It will then work with its partner to complete the integration. FIS uses RESTful APIs built to the OpenAPI (or Swagger) specification, a language agnostic industry specification. These APIs provide data and functionality, meaning they can be used by banks looking to pursue BaaS strategies. A number of FIS bank clients are already active in providing backend services to fintechs via Code Connect.
- Prebuilt FIS integrations. FIS works with select third-party partners to pre-integrate their services with FIS’ APIs. A bank using any of those solutions can then come to the marketplace and select an integration it would like to use. FIS directs banks back to the vendor for integration and deployment.
- Third-party APIs. There are third-party APIs available on the marketplace that banks can consume. This enables institutions to enrich their existing services with external data. FIS will provide the documentation for these APIs to clients who wish to access to them.
FIS has not yet made all of its solutions accessible via API, but it’s at about 80% penetration on the banking side, according to Amit Aggarwal, SVP of Code Connect & Open APIs, Product Management. (It was on track to reach 85% by the end of 2020.) The upside here is that FIS is taking a lot of the work off of the bank, especially when it comes to prebuilt integrations. However, the need for those integrations comes from the complexity of its systems and how they talk to each other; even with technically competent APIs, some clients say it is difficult to understand how the programs they talk to work. FIS has started to develop composite APIs that can deliver simplified business services to remove this complexity; it’s still early, but the company plans to continue to build these out. The bank also has to pay for access at each turn; the APIs are not made readily available to them. Payment models vary; some clients pay as they go while others pay by subscription or negotiate Code Connect into their contract.
Fiserv
Fiserv has a clear strategic vision for open banking, but it is still early days. The core provider does not yet have market-facing gateway through which all of its APIs are delivered, but it plans to deploy one in 2021. Currently, it provides access to its APIs for third-party integration at a client’s request. Bank clients are able to test drive the APIs with third parties at no cost and will enter into an agreement with Fiserv once they decide to pursue deployment. Clients report paying anywhere from $5,000 to $10,000 for Fiserv to write an integration and provide maintenance. Fiserv uses the Financial Data Exchange (FDX) standard for consumer data APIs (read only) and IFX for those that deliver bank functionality (read and write). It estimates banking functionality coverage at over 80%, per the IFX standards.
Like FIS, Fiserv provides a marketplace portal that includes preintegrated third-party solutions. Today, that portal has over 370 apps, though it currently only supports the DNA core and clients using Fiserv’s core agnostic online banking platform, Architect. In 2021, Fiserv expects to expand this portal, called the DNAapp Development Center, to service all of its additional core systems, as well. The company’s overall API strategy centers on the expansion of this portal to a market-facing platform through which all Fiserv APIs are delivered and pre-integrated solutions are available. This will put it on par with similar offerings like Code Connect. However, clients today say they face the same integration complexity as is common with other legacy systems when it comes naming conventions. Because this complexity has to do with the cores and not the APIs, solving this issue is tricky. Clients will either need to wait for providers like Fiserv to create simplified definitions, which is coming as the market pushes for it but will take time, or they can take more control over the technology stack.
Jack Henry & Associates (JHA)
Jack Henry offers a single API gateway, jXchange, and publishes its APIs on its developer portal. It uses a standardized set of APIs across all of its products and supports two industry protocols, SOAP and REST. Developers can use these APIs to build out their products and experiment with different integrations, and like its peers, JHA runs a vendor partner program through which third parties can pre-integrate with its solutions. However, and crucially, the specifications for these APIs are proprietary and not based on an industry standard.
When it comes to actually integrating with a financial institution, vendors go through JHA’s middleware layer, which provides access through a single endpoint. All of Jack Henry’s core and complimentary products link up to this API layer. As a result, except for a few banks who manage their own middleware, it is not possible to connect without going through the core provider. When a financial institution finds a third party they’d like to integrate with, that vendor is given credentials to the middleware layer, which enables it to tap the API library inside of the bank via jXchange. If a vendor requires an API that is not available, it can be built but must go through an approval process. Mackenzie Kizer, technical product management, senior manager at JHA estimates that the organization is probably at around 40-50% coverage for core functionality.
Jack Henry’s approach to publishing full documentation for its APIs is a step in the right direction. However, its use of proprietary specifications and controlled access through the middleware layer results in an ultimately managed environment. JHA doesn’t charge for access to its APIs or middleware layer; instead, banks pay by consumption, meaning there is a fee every time a third party connected to the bank makes an API call.
New and foreign entrants
In addition to the traditional US players, there are a number of new entrants and foreign providers making strides in the market. Finxact, for example, launched in 2017 and is built entirely of containerized applications using APIs based on the OpenAPI specification. Because it was designed API-first, all of the banking functionality is delivered that way. The cloud-native core serves as the system of record and transaction processing engine for the bank, and 100% of its data is made available. “Finxact is not trying to be all of those things on the periphery, whether that’s account opening or loan origination. We are the position-keeping engine. We’re trying to make sure that all of the data, and the data about the data, is readily available to the bank,” Finxact CMO Christopher McClinton told CCG Catalyst. Other cloud-based, API-first core systems gaining traction include Neocova and Nymbus. This approach may seem novel to US banks, but foreign providers like Temenos and TCS are also able to easily expose core functionality using an API-first strategy. The main difference is that these systems are newer and built to expose discreet services; they are not building APIs on top of an existing system. That reduces integration complexity.
There are a couple of benefits to the more flexible technology these providers offer: First, it affords the bank greater control over the data inside of the organization; second, it allows the bank to define its own partnership strategy; and, finally, it speeds up time to market. However, the more flexibility there is, the more the bank needs to play a role in managing it all. In the case of Finxact, for example, clients need to be willing to play an active role in vendor selection and management.
Banks driving change in the market
The banks at the forefront of open banking in the US are those defining their own paths, whether that includes their existing core or not. Some of these players are working with newer providers like Finxact, while others are creating their own API layer that sits between the core and the third parties they want to work with. Below we take a look at a few institutions that are behind the wheel and how they’ve done it.
Grasshopper Bank
Grasshopper Bank is a digital-only commercial bank that launched in 2019 and focuses on serving entrepreneurial businesses. When it began its search for a core provider, it had several requirements: In addition to being multicurrency and multitenant, Grasshopper wanted to ensure the bank had full data ownership, the ability to white-label, and modularity to ensure it could grow and scale without changing core providers. Grasshopper went with Temenos’ T24 Transact core banking system; it purchased a license and pays Temenos to host it in the cloud. The bank then built its own API layer that connects to Temenos and that connects to everything else. “Nothing is connected to Temenos except for Grasshopper. Everything connects via our API layer,” Judith Erwin, Grasshopper CEO told CCG Catalyst. Temenos provides full API access to its database, which made connecting the API layer to the core much easier than if it had to hardwire the connection to a traditional core provider, she said.
Because Grasshopper controls the layer where the entire bank sits, or the system of record, it has complete freedom to integrate. The bank is currently in the process of completing integrations with Plaid, QuickBooks, and Xero, for example, to provide customers’ bank data securely via API. Additionally, it has completed a number of integrations to consume services itself. In the future, Grasshopper expects to integrate more deeply with fintech providers to give its business customers access to such services through the bank’s platform. “We ultimately have total flexibility to offer different solutions; we could provide three different bill pays if we wanted. It’s really the complete freedom to choose on behalf of our clients. Our goal is to provide highly curated services that are highly repeatable and scalable,” Erwin said.
Being able to select partners freely enables Grasshopper to offer services that many competitors cannot. For example, the bank can do authentication and know-your-customer (KYC) procedures almost instantaneously through its partner Auth0. This eliminates the need for a site visit, meaning it can offer digital account opening to its small business customers. That’s still a rare feature in the commercial banking world; just 20% of US banks surveyed by Bank Director this year can open deposit accounts for small businesses fully digitally.5
Grasshopper built its API layer in house with development resources it invested in. It was able to do this in part because of its license agreement with Temenos; it pays a flat fee. “My costs don’t change. So that’s the beauty of it,” Erwin said. “With a traditional core, you pay for every client, every transaction, every account.” Banks that are looking to replicate Grasshopper’s model will have to invest in not only developing but maintaining their API layer. That means compliance and security considerations as well as development talent. The reward, though, is complete and total freedom.
Top 100 Bank
CCG talked to a retail and commercial bank that uses FIS for its core and leverages Code Connect as part of its API strategy. It created an API platform that it built in-house to connect to Code Connect and other third-party services. The bank, which we’ve left unnamed in this report for privacy reasons, decoupled its data from the core by introducing a cache to power its APIs. This allows the bank to innovate and expose its APIs internally and externally with less dependency on the core processing engine. Data is pushed from the core to the cache when something changes, enabling simple transitions like “get balance” to be faster and more reliable for the customer, mimicking a 24/7 bank even when the core is offline.
By connecting its own technology to FIS and other services, the bank can build its own APIs that make integration much easier. “The biggest problem with the traditional cores is that they were built decades ago, and the way their systems talk to each other isn’t in plain English,” the company’s CIO explained. “If you don’t know how the core works, you can’t call the right services.” The primary benefit to operating its own API layer is that the bank can create simplified definitions of those services and composites that perform certain functions. For example, it created a service to open a new account, with all of the necessary functionality nested underneath it.
The bank is primarily using its API layer to accelerate time to market internally, with plans to expose its APIs externally to drive innovation through partnerships. Developers inside the bank’s digital banking, contact center/IVR, and CRM teams, for example, can call these simple APIs to quickly build new customer experiences without having to understand the systems on the backend. The goal is to eventually expose its internal developer portal, where it will then register external partners, grant access, and manage those relationships.
This is a good example of a bank leveraging the offerings provided by a traditional core but taking it a step further. And, like Grasshopper, the bank has made significant upfront investments in technology to give it the ability to quickly build differentiated customer experiences. Banks that are reluctant to bring technology development in house should think long and hard about this tradeoff; without investing in engineering, differentiation may be harder and time to market longer.
Live Oak Bank
Live Oak Bank provides small business loans, online savings, and CD accounts to customers across the US. It began looking for a new core three years ago after starting to build out its own servicing side, including a mobile app and online banking experience. The bank felt that its existing core wasn’t able to support all of the technology and services that it was looking to layer on top. It now runs on Finxact, (though it’s still in the process of migrating over), which allowed the bank to adopt a plug-and-play strategy for fintech partners because of its fully API-enabled infrastructure. “[Finxact] allows us to go out and be really selective on the partners that we attach to it,” Mark Moroz, head of product at Live Oak Bank, told CCG Catalyst. With older solutions, he explained, you are married to their ancillary services like remote deposit and fraud detection; there isn’t enough freedom to go out and attach what you want.
Live Oak has not only been able to select its own partners, but also easily snap solutions in and out if they don’t work well. For example, the bank started off with one provider for remote deposit capture but didn’t like the experience, so it took the solution off the platform and put in a new player. It took 60 days to do that while with a traditional core it might take nine months to a year including contract negotiations, Moroz said.
The bank has 15 partners in addition to Finxact, and it has selected each one. Moroz estimates that its approach may save the bank somewhere around 45-50% on its savings product and 25-30% on the transactions side versus trying to execute the same strategy with its legacy system, at scale and fully implemented. The bank is in a year-to-year contract with Finxact and pays per account with a monthly minimum it says it can hit. Although its approach is different to those above, Live Oak Bank also dedicates significant resources to managing its technology strategy in house. Selecting its own partners requires time and vetting, for instance, and the integrations require technical resources. Banks that do not have this talent in house would likely need to hire professional services firms to assist them with such a strategy; at least until this technology begins making its way downstream via white-labeling.
Selecting a strategy
First, and no matter what anyone says, it’s very possible that the best open banking strategy for your bank today isn’t all that complex. Not every institution needs the ability to integrate widely with fintechs and other third parties. But, when determining how to approach this movement, it’s important to understand what your goals are now and for the future. If leadership is looking to bring new services to customers, expand distribution through new channels, or even make the business a more attractive acquisition target, then more robust API enablement will be attractive. Ultimately, the right path will depend on what the bank is trying to achieve.
The traditional core providers represent the path of least resistance. Following their lead means a bank doesn’t have to define its API strategy, nor manage any integration layer. The flip side is that the bank is then married to their core provider’s strategy; they are dictating the data flow, the price, and the flexibility. If a bank has just a handful of services it’s looking to add, or the integrations it requires are relatively mainstream (like Plaid, for example), then it may make sense to go through the core. However, for banks that are looking to compete using best of breed services, these offerings are likely to be insufficient, for now. Such institutions should assess their technology positions and explore managing their integrations in-house. Companies like MuleSoft and IBM provide technology that banks can use to build their own integration layers, and some of the core providers like Temenos are beginning to do the same.
Eventually, it is likely that the traditional cores will reach technical parity with newer entrants and their foreign peers from an open banking standpoint, according to Charles Potts, SVP and chief innovation officer at the Independent Community Bankers of America (ICBA). Then, it will be even more a question of strategy. Institutions like Grasshopper that want to have more control over their tech stack will operate their own API layers, while others will follow the route dictated for them. However, even as that route gets more attractive, it will remain managed. Ultimately, the decision for banks today and in the future is to what degree they’re willing to sacrifice openness for help.
©CCG Catalyst 2025 – All Rights Reserved
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage and retrieval system, without prior permission in writing from the publisher.
Read US Open Banking 2024
