Open banking guide: consent, APIs, aggregators, permissions, and data flows

What to take away

Open banking lets you send your own financial information from one provider to another service. A budgeting app reads balances and transactions. A lender pulls a one-time cash-flow record. A payment service asks for separate authority to move money.

The label tells you none of that. Who touches the data, how the connection runs and what the app may do live in the connection record, not the marketing page.

No nationwide U.S. open banking license exists yet. A U.S. connection rests on contracts, privacy law and provider terms, not a live federal regime.

Who touches your data

One company can hold several of these roles at once. A clean map follows the data, not the brand names on the screen.

Named U.S. aggregators include Plaid, Yodlee, MX, Finicity and Akoya. A budgeting app such as YNAB may reach your bank through one of them without saying so.

Where the U.S. rule stands

The CFPB says its Personal Financial Data Rights Rule implements section 1033 of the Dodd-Frank Act. Its personal financial data rights status page reports that a federal court stayed the rule's compliance dates on October 29, 2025, and notes possible amendments.

Anyone publishing a deadline should re-check that page and the court record on the day of use. A stayed date is not an operative one.

As finalized in October 2024, the rule staged compliance from April 1, 2026 for the largest providers to April 1, 2031 for the smallest. The stay suspends those dates. Verify them at the CFPB page before citing one.

The stay does not erase privacy, security or contract duties that already apply.

What happens next:

Consent is not the same as login

Authentication answers whether you are the account holder. Consent answers what a service may reach, why, and until when.

In a redirected flow you sign in on a bank-controlled page and the bank returns a token. In a credential-sharing flow an aggregator receives your login and retrieves account pages itself. Neither path proves informed permission on its own.

Keep a separate authorization record. It should name the app and any aggregator, the connected institution and accounts, the data categories, and whether access is one-time or ongoing. Add the refresh trigger, the stated purpose, and any payment-initiation authority. Add the expiration rule, the revocation method, and the retention terms.

A scope line reads: read balances and transaction history for account ending 4417, for 12 months, refreshed daily. A payment scope is narrower: one payment of a stated maximum on a stated date.

Access tokens are often opaque strings, sometimes signed JSON web tokens. The refresh token is the durable credential.

How a read-only connection flows

A budgeting connection runs roughly through several stages. These are:

Each arrow is a handoff. The bank may send a transaction code and a timestamp. The aggregator may turn that code into a category. The app may cache the result under a friendly label. A wrong label can therefore start life after the bank sent an accurate record.

A payment-enabled service adds a second path:

Scope, freshness and provenance

"Account access" is too vague to audit. Scope can cover balances, pending and posted transactions, merchant fields, and routing details. It can also cover recurring payments, rewards positions, identity details, and payment instructions.

Ask whether the service can do its job with fewer accounts, fewer fields or a shorter period. A rent-verification service may need selected cash-flow records once. It does not need continuing access to every account in the household.

Available balance and ledger balance answer different questions. Pending items can post at a different amount or vanish. Preserve the bank's own field name rather than flattening both into "current balance."

What it costs

Most consumer apps charge nothing extra. The app's subscription is the visible price.

Aggregators bill banks and apps per connection, often per linked account or per API call, under private contracts. The price varies with volume, data types and whether access runs through a bank-owned network or a third party.

Why an API is not a clean bill of health

An API can define fields, authentication, rate limits and error responses more precisely than automated page reading. It can also let you authenticate straight with the bank.

It still needs secure operation. Watch for these issues:

Revocation, expiration and deletion

These are five different acts, not one button.

Deleting the phone app removes local software. It proves nothing about server-side access. The five acts are:

Records worth keeping

Save the consent text and its version, the date, the named entities, and the selected accounts.
Save the scopes, the purpose, the token or connection ID, and the access log.
Save refresh failures and any change to the terms. Add the revocation request, the deletion request and the confirmation.

As a consumer, keep screenshots or exported confirmations that do not expose full account numbers or passwords.

If a dispute arises, the CFPB accepts complaints through its own filing process, and state attorneys general take consumer complaints in their states. For anything with legal consequences, consult a licensed attorney.

What to do next

Common questions

Is open banking the same as online banking?

No. Online banking is your interface to one institution. Open banking covers permissioned data or service connections between separate providers, often through an aggregator you never see.

Does an API mean the app never sees sensitive data?

No. An API can cut credential sharing, but the app or its aggregator may still receive detailed account records. Read the scope, not the architecture diagram.

Can read access move money?

It should not. Check the actual scope and the approval step before you rely on it.

Does revocation delete old data?

Not necessarily. Stopping future access and requesting deletion are separate requests. Ask what retention exceptions apply, and get the answer in writing.