A consent flow is the security boundary of open banking. Under the CFPB's Personal Financial Data Rights rule, issued October 22, 2024, a consumer's authorization cannot last longer than one year without renewal, and revoking it must be as easy as granting it (CFPB, 2024). The plumbing that enforces those promises is OAuth 2.0.
Nuv Media publishes information, not financial advice. This explainer covers the mechanics of authorized data access — scopes, tokens, revocation and the FDX API standard — rather than the rulemaking politics.
What does a consent flow look like end to end?
The standard sequence has five steps. One: the consumer clicks connect inside a budgeting app or lender portal. Two: the app redirects her to the bank's hosted consent screen, where she logs in with the bank — the app never sees the banking password. Three: the screen lists requested data categories and accounts, and she approves or edits the selection. Four: the bank returns a one-time authorization code to the app. Five: the app exchanges that code server-side for tokens and begins pulling data through the API.
Every step is specified in OAuth 2.0, the authorization framework published by the IETF in 2012 (IETF, 2012). Financial implementations add PKCE, a code-interception defense from 2015 that binds the code exchange to the original app (IETF, 2015). The result is directed access: credentials stay with the bank, and the app holds tokens that represent narrow, revocable permission.
For security teams, the audit trail sits in that fifth step. Each API call presents an access token whose scope, account list and expiry the bank issued and can inspect, so every data pull is attributable to a specific consent event rather than to a shared login.
What are scopes and why do they limit the blast radius?
A scope is a named data category: account identity, balances, transaction history, bill payment initiation. The consent screen translates scopes into plain-language choices, and the issued tokens carry only what was approved. A personal-finance app that needs balances and transactions to build a dashboard has no business reading identity documents, and a properly scoped token makes that impossible rather than discouraged.
The CFPB rule pushes in the same direction. It restricts secondary use — data collected for one product cannot be resold or reused for targeted advertising or cross-selling without separate authorization — and it requires data providers to limit collection to what the consumer approved (CFPB, 2024). Scopes are the technical control that makes the legal limit enforceable.
In FDX-based implementations, the scope list maps to the API's resource set: the consumer can tick specific accounts rather than all accounts, which matters when a business owner connects a company account to an expense tool but wants her personal accounts left alone.
How long does consent actually last?
Two clocks run in parallel. The access token is deliberately short-lived — minutes, not months — and the app presents a refresh token to mint new access tokens without bothering the customer. The consent itself is the longer clock: under the CFPB rule it expires after one year unless the consumer reauthorizes, so apps must bring customers back through the consent screen annually (CFPB, 2024).
The two-clock design is what limits damage from a leaked token. A stolen access token dies quickly; a stolen refresh token can be invalidated centrally when the bank or customer notices; and the consent cap guarantees that even a forgotten integration loses access within twelve months of the last renewal.
Operationally, banks instrument the long clock: dashboards show which third parties hold live consents per customer, when each expires, and what scopes each token carries. Those dashboards become the front line for the next question — turning consent off.
How does revocation work in practice?
OAuth 2.0 defines a revocation endpoint, published as RFC 7009 in 2013, where a token can be invalidated on demand (IETF, 2013). In banking flows the customer usually revokes from the bank's own connected-apps page; the bank kills the refresh token, access tokens expire on their own within minutes, and the third party's next API call fails. The CFPB rule adds the legal overlay: revocation must be as simple as authorization, effective promptly, and followed by deletion of the retrieved data within a reasonable period unless another law requires retention (CFPB, 2024).
Deletion is the hard half of revocation. The token dies instantly, but copies of transactions sitting in the fintech's analytics store must be tracked and purged, which is why consent inventories on both sides — grant records at the bank, data-lineage records at the app — are the operational cost of doing this properly. Auditors ask for both.
What role does the FDX API play?
The Financial Data Exchange, a nonprofit standards body founded in 2018, maintains the FDX API — a REST-based, JSON-payload interface secured with OAuth 2.0 that has become the de facto U.S. data-sharing specification (FDX, 2024). Its consent model, data fields and security requirements are what most large U.S. banks and aggregators implement, and the CFPB built its rule to accommodate industry standards of exactly this kind, anticipating accreditation of a standard-setting body (CFPB, 2024).
For product teams, the practical takeaway is that open banking in the United States means OAuth 2.0 tokens with banking-grade consent screens on top: scopes that limit what is readable, short-lived credentials that limit how long exposure lasts, annual reauthorization that limits how long silence continues, and revocation that ends both. Build those four controls and the rest is integration work.
For more context, read How a Card Gets Bound to a Phone Wallet During Provisioning.
For more context, read agentic commerce payments.
For more context, read ai underwriting banks.
