Here's what banks must do to secure open banking data

Internet Bank Transfer Using Checking Account
Andrey Popov/Adobe Stock

The concept of open banking, or financial data sharing between banks and fintechs, comes with a number of security concerns.

What if an application programming interface — a tunnel through which data passes from one application to another — is compromised? What if data stored at a fintech or data aggregator gets hacked?

The Consumer Financial Protection Bureau's 1033 rule, which would have put security guardrails around this movement of data, is likely to be scrapped, given the agency itself, under a new administration, has said the rule is unlawful and needs to be set aside.

So, banks and fintechs need to continue to police themselves and use industry standards and general principles of security, privacy and reliability.

For banks, this means not only building APIs and authentication systems, but also implementing strict security oversight, monitoring third-party connections, and keeping detailed records of data access requests and responses.

Secure API access

There is no specific technology or protocol mandated for APIs — banks can choose the technical implementation — but there have been calls for standardized, machine-readable formats and reliable performance.

To guide this, the CFPB had intended to recognize standard-setting bodies, or SSBs, that develop qualified industry standards, or QISs, for data sharing.

Adhering to an SSB's standards (for formatting, authentication, security and so on) would have served as a safe harbor "indicia of compliance for data providers" under the CFPB rule, according to attorneys who wrote about the matter for law firm Ballard Spahr. 

Setting security standards

One standard-setting body has been recognized by the CFPB: the Financial Data Exchange, or FDX.

In the January decision recognizing FDX, the CFPB said it "continues to evaluate other applications for recognition."

The CFPB has received one other application, from the Canada-based Digital Governance Standards Institute, or DGSI. The CFPB received the DGSI application a month after it received FDX's application but has not yet issued any statement about it.

The American Bankers Association publicly opposed the recognition of the institute as a standards-setting body on the grounds that the application "fails to meaningfully address any of the standards in the rule, or the organization's relationship with them," and it "fails to demonstrate a significant nexus between the organization and the U.S. data sharing ecosystem," according to Ryan T. Miller, vice president and senior counsel for innovation policy at ABA.

Different standards for banks and fintechs

The final 1033 rule would have explicitly required any bank or data provider to apply to its open banking interface an information security program meeting the standards of the Gramm-Leach-Bliley Act, or GLBA, Safeguards Rule (or equivalent FTC safeguards for nonbanks).

This means banks would have needed written security policies, risk assessments, access controls, encryption and ongoing monitoring for their APIs consistent with GLBA's requirements for protecting customer data.

Similarly, any third-party fintech accessing the data would need to certify and maintain a security program for its systems that complies with GLBA/FTC safeguards standards.

In short, under the CFPB's rule, all parties handling the data were expected to uphold bank-level data security practices. Instead, this is now an implicit standard.

Court challenge

Rule 1033 was challenged in court by banking industry groups on the same day it was issued. A coalition including the Bank Policy Institute and a community bank filed a lawsuit seeking to invalidate it. According to the complaint, the CFPB exceeded its authority and that the rule "jeopardizes consumers' privacy, financial data, and account security" by not imposing more oversight on third parties.

BPI and its counterparts argued, among other things, that the rule "fails to hold third parties accountable" and still permits potentially "unsafe" practices like screen scraping during the transition, according to the lawsuit. 

In late May, the CFPB's new leadership told the court the rule will be set aside, rendering the lawsuit moot. 

Liability for data breaches: existing law applies

Existing consumer protection laws like the Electronic Fund Transfer Act (EFTA) or Truth in Lending Act (TILA) apply when third parties are involved.

This means if a consumer's deposit account is fraudulently accessed or debited using data obtained via an open banking API, Regulation E rules apply: The consumer can report the unauthorized transaction to their bank and the bank must investigate and make the customer whole as required by EFTA, regardless of the third party's involvement.

In short, from the consumer's perspective, the bank (or card issuer) can't dodge responsibility by pointing to a fintech; the bank must handle the issue and then seek recourse elsewhere.

Third-party responsibilities and accountability

Trade groups for banks have strongly argued that fintechs and aggregators should bear the liability for any data loss or unauthorized transaction that occurs once they have the data.

"Aggregators and other data recipients should be liable for unauthorized transactions or failing to protect consumer data once data is within their possession," reads a joint statement from the Clearing House Association and BPI.

In practice, this might be enforced through contractual agreements.

Protective technical measures

By providing third parties with tokens or limited-access keys, banks ensure that even if those credentials are stolen, they cannot be easily used to perform high-risk transactions outside of controlled channels.

Moreover, banks can issue time-limited data access tokens and require periodic reauthentication (since the rule already limits continuous access to one year without renewal). If a fintech is breached, the bank can quickly revoke the tokens to cut off further access.

These practices, coupled with prompt consumer revocation mechanisms, give consumers and banks the tools to contain damage swiftly if something goes wrong.

In essence, while liability for losses might initially fall to the bank under consumer protection laws, banks are not helpless — they can contractually shift liability back to the negligent third party and use technical controls to reduce the likelihood and impact of breaches.

Regulatory outlook on liability

The unresolved questions about who ultimately bears the cost of a breach remain a hot topic. Lawmakers and industry officials have already signaled that liability allocation may be revisited.

Members of Congress questioned Biden-era CFPB Director Rohit Chopra on this issue in November 2023, after the proposed rule came out, indicating interest in clearer rules to make aggregators explicitly liable for data security failures.

"So where have you come ashore on who bears liability for a data breach?" asked Rep. French Hill, R-Ark., now the chair of the House Financial Services Committee, during that hearing.

"Generally speaking, when a consumer permissions their data, they're handing over their data to that new financial institution," Chopra said at the time.

The CFPB's final rule, however, kept traditional frameworks in place: Consumers are protected via Reg E/Z, and "private network rules, contracts, and other laws," according to the rule, will sort out the responsibility among the bank, the fintech and any intermediaries.

Banks, therefore, should proactively shore up those private arrangements. By doing so, they not only protect themselves financially, but also bolster the overall trust in open banking: Consumers will feel safer using these new services if they know everyone in the data chain has the incentive to keep their information secure.

For reprint and licensing requests for this article, click here.
Open banking Technology Regulation and compliance Magazine Issue Year 2025
MORE FROM AMERICAN BANKER