Open Banking and APIs: What Community Banks Need to Know

Open banking arrives at a community bank in two forms, and only one of them is a compliance project.

The first is regulatory: a framework requiring institutions to make a consumer's own financial data available, at the consumer's direction, to third parties the consumer chooses. The second is commercial and already here: customers have connected their accounts to budgeting apps, payment services, lenders, and tax software, and the institution's data is already leaving through whatever mechanism those services use.

Most banks have not decided how they want that to work. That is the actual decision in front of them, and it is more operational than technological — because the technology will be built by the core processor and the digital banking vendor, not by the bank.

What Open Banking Means Concretely

Strip the terminology and it is one capability: a consumer can authorize a third party to access their account data, and the institution provides that access in a controlled way.

Two mechanisms deliver it, and the difference between them is the whole subject.

Screen scraping is the status quo. The consumer gives a third party their online banking credentials; the third party logs in as the consumer and reads the pages. It works, it is widespread, and every property of it is bad: the institution cannot distinguish the access from an account takeover, the third party holds credentials that unlock everything rather than a limited scope, the consumer has no way to revoke access short of changing the password, the connection breaks whenever the institution changes its interface, and the traffic looks like an attack.

A permissioned API replaces credential sharing with a token. The consumer authenticates with the institution, authorizes a defined scope, and the third party receives a credential that grants only that scope and can be revoked. The institution knows who is accessing what, can limit it, can log it, and can turn it off.

The direction of travel, both regulatory and commercial, is from the first to the second. An institution still relying on the first is carrying risk it does not need to carry.

The Regulatory Framework

The consumer financial data rights framework under section 1033 of the Dodd-Frank Act establishes a right for consumers to access their financial data and to authorize third parties to access it on their behalf. Its requirements, compliance dates, and applicability by institution size have been subject to litigation and reconsideration, and any institution reading this should confirm the current position rather than rely on a summary.

What the framework has consistently addressed, in general terms, is worth understanding even while the specifics are unsettled:

Scope of covered data — transaction history, account balance, information needed to initiate payments, account terms, and upcoming payment information, for covered accounts.

A developer interface through which authorized third parties obtain data, with performance and availability expectations, rather than access dependent on scraping.

No fees to the consumer or the authorized third party for access.

Authorization and revocation requirements, so the consumer's permission is informed, scoped, time-limited, and reversible.

Obligations on the third party regarding what it may collect, how long it may retain data, and what secondary uses are permitted.

Tiered compliance timing by asset size, with the smallest institutions treated differently from the largest.

Two things follow regardless of how the rulemaking settles. The commercial pressure exists independently of the rule — aggregators, lenders, and payment providers want this data because consumers want the services built on it. And the operational work is the same either way: an institution that builds a controlled, revocable, logged access mechanism has both satisfied the likely regulatory requirement and eliminated the scraping risk.

What a Community Bank Actually Controls

This is the part most coverage of the topic omits. A community bank does not build an API. Its digital banking platform and its core processor do, and the institution's practical position depends almost entirely on what those providers have delivered.

Which makes the real work a vendor conversation, and the questions are specific:

• Does the platform expose a permissioned API for consumer-directed data sharing, and which data elements does it cover?
• Which aggregators and third parties is it already connected to, and through what mechanism?
• Is screen scraping still occurring, at what volume, and can it be identified in the logs?
• What does the consumer's authorization and revocation experience look like, and can the institution see and manage active authorizations?
• What are the performance and availability commitments for the interface, and what happens when it is unavailable?
• What is the cost, and is it charged to the institution, to the third party, or to nobody?
• What is the roadmap and timeline, stated in writing?
• How does the provider handle a third party that misbehaves — excessive requests, out-of-scope access, a security incident?

The answers frequently reveal that the capability exists and has not been enabled, or that it is on a roadmap with no date. Both are useful to know, and both are matters for the contract discussion covered in our vendor management post.

Risk and Compliance Considerations

Authentication and authorization. The consumer authenticates with the institution, not with the third party. Any design in which the third party collects the institution's credentials reintroduces the problem the API exists to solve.

Scope limitation. Access should be limited to the data the service needs. An aggregator supporting a budgeting app does not need the ability to initiate payments.

Revocation that works. The consumer needs a visible list of authorized connections and a functioning way to end one — and front-line staff need to know where it is, because they will be asked.

Unauthorized transfer liability. Where a third party is involved in a transfer the consumer disputes, the institution's obligations under the electronic fund transfer rules do not disappear because an intermediary was in the chain. Error resolution timelines and liability allocation apply as they otherwise would, and the operational question is whether the institution can reconstruct what happened. Our post on Regulation E error resolution covers the framework.

Privacy and information sharing. The institution's obligations under the privacy rules and its information security program extend to this activity. Whether a given third party is a service provider of the institution or a party acting at the consumer's direction changes the analysis materially, and it should be determined rather than assumed. Our post on privacy and information sharing addresses the underlying rules.

Security of the interface itself. An API is an internet-facing entry point to customer data. It needs the controls any such entry point needs — authentication, rate limiting, monitoring, anomaly detection, and inclusion in the institution's information security program and testing scope, as covered in our cybersecurity post.

Fraud implications. Permissioned access changes the fraud picture in both directions. It removes the credential-sharing exposure and it creates a new one: a consumer socially engineered into authorizing a malicious application has granted real access. Institutions should expect this typology and build the authorization screen to make the grant comprehensible.

Structured coverage is available through Digital Compliance, Privacy/Information Sharing, the Certified Regulatory Vendor Program Manager program, and Payments and Settlements.

The Two-Sided Business Question

Community banks tend to hear open banking as purely defensive — the bank gives up data, competitors use it to take deposits. That is half of it.

The cost side is real. Data sharing makes switching easier, gives competitors visibility into the institution's customers' cash flow, and makes the deposit base more mobile. Rate-shopping becomes frictionless when balances can move on the strength of a connected view.

The benefit side is equally real and less discussed. Permissioned data access is how a bank verifies an account before an ACH origination, underwrites using cash flow rather than only credit score, verifies income without documents, funds a new account instantly, and offers the aggregated view its customers currently get from someone else. Every one of those is a capability the institution can consume as well as supply.

The institutions that treat this as only a compliance obligation implement the minimum and get only the cost. Framing it as a capability — what could we do if we could see, with permission, a customer's full financial picture — is where the offsetting value is.

What to Do Now

Find out whether scraping is happening and at what volume. Most institutions have never asked. The answer usually surprises them and it establishes the baseline for everything else.

Ask the vendor questions above, in writing, and put the answers in the vendor file.

Determine the institution's asset-size position under the current framework and its likely compliance timing, and revisit it as the rulemaking settles.

Update the third-party risk program to address parties accessing data at consumer direction, which is a category most programs do not contemplate.

Decide the consumer experience for authorization and revocation, and make sure front-line staff can find and explain it.

Train the front line on what a connected-application call sounds like — including the calls where a customer reports activity they in fact authorized through an app they forgot about, which is a growing share of disputed-transaction conversations.

Consider the consumption side deliberately rather than only the disclosure side.

Where Institutions Get This Wrong

Assuming it does not apply because of asset size, without confirming the current framework.

Never asking whether scraping is occurring, and therefore carrying an unmeasured exposure.

Treating it as an IT project when the substance is vendor management, privacy, and consumer experience.

No revocation path, or one the institution cannot see and front-line staff cannot find.

Third parties outside the vendor risk program, on the theory that the consumer chose them.

Implementing the minimum and capturing none of the offsetting capability.

No monitoring of the interface, leaving an internet-facing data path outside the security program's scope.

The summary worth carrying: the institution's data is already being shared, the only open question is whether that happens through a mechanism the institution controls, and the lever that determines the answer is the core and digital banking contract rather than anything the bank builds itself.

Frequently Asked Questions

What is the difference between screen scraping and a permissioned API?

Screen scraping means the consumer gives a third party their online banking credentials and the third party logs in as them. A permissioned API replaces credentials with a scoped, revocable token issued after the consumer authenticates with the institution. The API lets the institution see who is accessing what, limit the scope, log it, and revoke it — none of which is possible with scraping.

Does the consumer data rights framework apply to small institutions?

Applicability and compliance timing have been tiered by asset size, and the framework has been subject to litigation and reconsideration, so any institution should confirm the current position rather than rely on a summary. The operational work is worth doing regardless, since a controlled access mechanism eliminates the scraping exposure independent of the rule.

What should a community bank ask its core provider?

Whether a permissioned API exists and what data it covers, which third parties are already connected and by what mechanism, whether scraping is still occurring and at what volume, what the consumer authorization and revocation experience is, what performance commitments apply, what it costs and to whom, the roadmap in writing, and how a misbehaving third party is handled.

Who is liable when a disputed transfer involves a third-party app?

The institution's obligations under the electronic fund transfer rules — including error resolution timelines — do not disappear because an intermediary was in the chain. The practical question is whether the institution can reconstruct what happened, which is considerably easier with token-based access and logging than with credential sharing.

Is open banking only a threat to community banks?

No. It makes deposits more mobile and gives competitors visibility into customer cash flow, and it also lets the institution verify accounts before ACH origination, underwrite on cash flow, verify income without documents, fund accounts instantly, and offer the aggregated view its customers currently get elsewhere. Institutions that implement only the minimum get the cost without the offsetting capability.

What is the first thing to do about open banking?

Find out whether screen scraping is already happening against the institution's online banking and at what volume. Most institutions have never asked, the answer is usually larger than expected, and it establishes the baseline for every subsequent decision.