A Primer on Banking APIs, OAuth, and Screen Scraping
There are several ways that financial institutions and fintechs can enable consumers to link their financial accounts today. But, as we shared before, not all connectivity experiences are created equal.
Understanding Connectivity Methods
Here’s an overview of the primary connectivity methods used today for data sharing and account aggregation:
1. Screen Scraping
Screen scraping, or credential sharing, is the process of gathering data from one app by inputting user credentials (such as username and password) and displaying that data in another app. Screen scraping requires consumers to share their username and password with the data recipient to gain access to their data.
The biggest downside to screen scraping is that the process relies on the other institution’s website structure, which becomes problematic when scraping happens without coordination with that financial institution. This means organizations are constantly fixing connectivity issues resulting from web updates, changes in login procedures, etc.
Connections also break every time a consumer updates their username or password. It also means that website downtime results in loss of connectivity. In addition, screen scraping results in slower connections compared to APIs.
On the other hand, the financial institutions who have data being scraped don’t always know who is capturing their data and for what purpose. And, it creates added risk for both the institution and consumer as credentials are freely shared with third parties. Scraping can also make it really difficult to decipher the difference between permissioned activity and possible malicious activity.
2. Whitelisted IPs
Whitelisting IP addresses is still a form of screen scraping. However, instead of allowing any app to scrape data, this method allows a financial institution to “whitelist” known third parties and sanction data sharing with those specific IP addresses.
While the downsides of screen scraping remain, whitelisted IPs does eliminate some risk but ensuring only trusted sources can access data and preventing access from unknown scraping sources.
3. Banking APIs
Banking application programming interfaces (APIs) are the next evolution in enabling reliable connections for consumers to link their accounts from third parties. While banking APIs still rely on consumers to input their username and password to create the connection, data sharing is enabled via an API versus screen scraping.
This creates a more reliable connection because an API doesn’t rely on the other institution’s website structure. Connections no longer break any time the other institution makes a change to its login procedures or updates its system. However, connections will still need to be re-established any time a consumer changes their username or password. And, the risk of sharing credentials with a third party remains.
4. OAuth APIs
OAuth APIs, sometimes referred to as an open banking or open finance API, allow consumers to access their transaction data without the need to share usernames and passwords. Instead of asking a consumer to input their username and password, the consumer is redirected to the other institution to log in directly to its system. Then, a token is created and passed back to the third party to establish a connection and enable data access.
This creates the most secure experience for consumers and institutions because it eliminates any credential sharing with third parties. In addition, it clears a more reliable connection as consumers will not need to re-authenticate every time they change their password or when system changes occur.
Finally, OAuth API connections also help financial institutions get ahead of upcoming compliance regulations related to the final rule from the Consumer Financial Protection Bureau (CFPB) under Section 1033 of the Dodd-Frank Act. Currently, the CFPB’s proposed rule would “prevent data providers from relying on screen scraping to comply with the proposal because it is not a viable long-term method of access.” Instead, the CFPB will require data providers to establish and maintain a developer interface that makes data available in a machine-readable, standardized format and doesn’t allow a third party to access the system using consumer credentials.
The downside to OAuth APIs? Standing up an open finance API can be an expensive and time consuming process. For example, the CFPB estimates a “total upfront cost of $250,000 to $500,000 for small depository data providers that choose to build their developer interface in-house” — with “ongoing annual technology costs of $20,000, as well as ongoing staffing costs of $45,000 to $91,000.”
Choosing to build or buy a solution will be a key decision point for financial institutions who don’t yet have an open finance API. MX’s Data Access platform can enable institutions to deliver a safe and secure connectivity experience for their customers — and helps financial providers get ready for potential requirements under Section 1033 rulemaking.
How MX’s Data Access Solution Powers Open Finance
At MX, our solutions and products are built with consumer-permissioned data sharing at the forefront. And, we make it easy for financial institutions of all sizes to accelerate open finance adoption and enhance the money experience for consumers through our Data Access product.
Data Access enables financial institutions to more easily create or evolve their open finance APIs to ensure they meet FDX standards, deliver the required data elements, and follow authentication protocols, such as OAuth and OIDC. In addition, Data Access is interoperable across all intermediaries, enabling financial providers to accelerate their path to eliminate screen scraping from their environment.
Data Access also creates better visibility into the open finance journey by providing real-time performance metrics, insights into data sharing activity, and support tools to easily manage and maintain connections. For instance, Data Access’s API Overview and Test Users feature takes the guesswork out of understanding what data needs to be included in open finance APIs. Financial providers can access — per use case and account type — which data fields are required and under what conditions. And with our Test Users feature, data providers and data recipients can test the APIs before they go live to ensure that all required data is there.
For consumers, Data Access’s Consent Management Dashboard can be easily embedded into mobile and online banking portals so that consumers can see and manage where they have shared their financial data with a third party. Consumers can view when their data was last updated or revoke data sharing access with a third party.
Want to learn more about how Data Access helps financial providers get ready for regulatory obligations? Read our whitepaper.
Setting the Standard — FDX
In June 2024, the CFPB took the next step toward recognizing industry standards-setting bodies as part of its Section 1033 rule making to establish consumer financial data rights in the United States. The CFPB’s rule identifies the attributes that standard setting bodies must demonstrate in order to be recognized, as well as a step-by-step guide for how standard setters can apply for recognition.
Recognizing industry standards is crucial to moving the industry forward with Open Finance, and literally setting the standard for secure consumer-permissioned data sharing. Across the industry, the Financial Data Exchange (FDX) has already driven strong adoption of open finance with 76 million consumer accounts transitioned from sharing data via screen scraping to the FDX API as of April 2024.
FDX is a non-profit, industry standards body dedicated to unifying the financial services ecosystem around common, interoperable, and royalty-free technical standards for user-permissioned financial data sharing. Any company within the financial industry can contribute to the development, growth, and adoption of the FDX API and other objectives. MX continues to be a driving force at FDX by chairing and collaborating in key task forces and representing fintechs on the FDX Board of Directors.
It’s great to see the CFPB listening to industry feedback and moving forward on SSOs in advance of the final Section 1033 rule. This will help ensure little disruption to the data sharing environment and avoid delays in the industry’s ability to implement this rule. We’re excited to continue working with organizations like FDX on accelerating a truly open financial ecosystem.