The thesis: bank data access is already a governed API relationship, mandate or not.
Most finance teams still describe connecting to a bank as picking a file format: an SFTP drop, a host-to-host feed, maybe a screen-scraping aggregator when the bank does not offer either. That description is going stale. The Financial Data Exchange, the nonprofit standards body behind the FDX API, reported 114 million accounts already connected through its permissioned interface as of April 2025, on version 6.4 of a specification whose stated scope covers both consumer and business financial data.
None of that adoption waited for a federal mandate. The CFPB’s Section 1033 rule, the regulation that was supposed to force large banks into open data APIs, sits enjoined and under reconsideration. Banks built the connectivity anyway, because their business customers and treasury platforms asked for it. The practical question for a finance team is no longer whether to accept an API connection to a bank account. It is whether anyone in the organization can say, for every existing connection, who authorized it, what it can see, and how to shut it off.
What actually changed, and what did not.
The CFPB finalized its Personal Financial Data Rights rule in October 2024, covering consumer credit card and Regulation E deposit accounts. A federal court in the Eastern District of Kentucky enjoined its enforcement, and the CFPB opened an Advance Notice of Proposed Rulemaking in August 2025 to reconsider the rule’s scope, including whether banks can charge fees for data access. The rule’s first compliance date, April 1, 2026, for the largest data providers, passed with the injunction still in place, so no enforceable federal API mandate exists today, and the original rule never covered business accounts in the first place.
New York is filling part of that gap at the state level. Assembly Bill A10640 and its Senate companion, S9483, both introduced in March 2026, would require financial institutions serving New York residents to give consumers and small businesses free, machine-readable access to transaction data, balances, and payment-initiation information through a standardized developer interface. Both bills remain in the Assembly Banks committee, so nothing is law yet. What the bill signals matters more than its current status: the next mandate, whenever it lands, is expected to name small business accounts explicitly, not just personal ones.
Meanwhile the security layer underneath all of this reached its own milestone. The OpenID Foundation finalized FAPI 2.0, the financial-grade API security profile built on OAuth, in February 2025. It defines the scoped, time-bound, revocable token model that makes a governed bank connection possible in the first place, and it is the same approach already in production in the UK’s Open Banking framework and Australia’s Consumer Data Right.
From a shared password to a scoped grant.
The operational shift is bigger than a new API to call. Enterprise treasury teams today typically reach their banks through a patchwork of SWIFT integrations, ERP-native connections, regional bank-specific setups, and manual spreadsheets, a landscape where onboarding a single new banking partner can trigger months of integration work and cash position visibility lags by hours or days. An FDX or FAPI 2.0 based connection replaces a shared credential with a token scoped to a specific data type, a specific duration, and a specific, named grantee, which is the difference between a password and a consent record.
| Dimension | Legacy connectivity | API and consent connectivity |
|---|---|---|
| Credential handling | Bank username and password shared with a screen-scraping aggregator, or a static SFTP key held by one person | A scoped OAuth token issued to one named connection, tied to a consent grant |
| Data scope | All-or-nothing: whatever the login can see | Defined per connection: balances only, transactions, or payment initiation, each a separate grant |
| Audit trail | No record of who authorized the connection or when it was last reviewed | Consent grant date, scope, and revocation event are all logged by design |
| Revocation | Requires a password change that breaks every other integration using it | One connection can be revoked without touching any other |
| Format | Bank-specific file layouts (BAI2, proprietary CSV) parsed by hand-built mapping code | A common FDX data model across participating institutions |
| Typical lag | Hours to days, since batch files run on a schedule | Near real time, since the API is queried on demand |
Building the bank-connection register.
A connection register does for bank access what an access-provisioning log already does for internal systems: it turns a scattered set of technical grants into one place an auditor, an incident responder, or a new treasury hire can read. Seven fields carry most of the value.
Financial institution and account
Which bank, which account number or masked identifier, and which entity in the org chart owns it.
Connecting party
The aggregator, treasury platform, or ERP module holding the token, and whether it is FDX or FAPI 2.0 certified.
Data scope
Read-only balances and transactions, statement history, or payment-initiation rights, recorded as separate grants, not one bundle.
Consent start and expiry
When the grant was authorized, when it expires or renews, and who authorized it.
Business owner
A named person accountable for the connection, not a shared inbox or a departed employee.
Review cadence
A fixed interval, independent of the token’s technical expiry, at which a human confirms the connection is still needed.
Revocation trigger
The events that force immediate revocation: vendor offboarding, role change, security incident, or a decommissioned integration.
The record one governed connection needs.
The register does not need a new platform to start. A structured record like the one below, held in whatever system already tracks vendor or access data, carries every field a review or an incident response would ask for.
Example bank connection register record
{
"connection_id": "bank-conn-00417",
"institution": "example-regional-bank",
"account_ref": "op-****4821",
"connecting_party": "treasury-platform",
"certification": "fdx_fapi2",
"data_scope": ["balances", "transactions"],
"payment_initiation": false,
"consent": {
"granted_by": "treasury-ops-lead",
"granted_at": "2026-05-04",
"expires_at": "2026-11-04",
"review_cadence_days": 90,
"last_reviewed_at": "2026-08-01"
},
"owner": "treasury-ops-lead",
"revocation_trigger": ["vendor_offboarding", "role_change", "security_incident"],
"linked_process": ["cash_positioning", "bank_reconciliation"],
"status": "active"
}The same structure applies whether the connection is a treasury platform pulling balances for cash positioning or an AP system reading transactions for reconciliation. What changes is the data scope and, for any connection capable of initiating a payment, the review cadence, which should run tighter than for a read-only connection.
Implementation checklist.
Inventory every existing bank connection today, screen-scraping aggregator, host-to-host SFTP, and API alike, before deciding which to modernize first.
Separate every connection into read-only data access and payment-initiation-capable access, and gate the second category with materially tighter review.
Assign a named business owner to each connection, and remove any connection that has no owner of record.
Set a review cadence for every consent grant that runs independently of the token’s own expiry date, so nothing coasts on a technical renewal alone.
Wire connection revocation into vendor offboarding and role-change checklists, so access ends the same day a relationship does, not on the next audit cycle.
Prefer FDX or FAPI 2.0 certified integrations over screen-scraping aggregators wherever a bank offers both, since a token can be scoped and revoked and a shared password cannot.
Map every governed connection to the ERP process it feeds, cash positioning, bank reconciliation, or an AP payment run, so an incident response starts with a lookup, not a scramble.
Log every consent grant and revocation as audit evidence, using the same discipline already applied to user access provisioning and deprovisioning.
Start with the inventory, not the policy. Most finance teams are surprised by how many live bank connections exist once every ERP module, treasury platform, and AP tool is checked, rather than assuming the list is limited to whatever IT provisioned directly.
Constructive failure modes to design around.
A screen-scraping connection set up years ago by an employee who has since left, running on a shared password nobody has rotated or reviewed since.
A payment-initiation-capable token handled with the same casualness as a read-only reporting connection, when the two carry very different fraud exposure.
Consent renewed automatically without a human check, so scope creep, a connection that started as balance visibility and later gained transaction rights, goes unnoticed.
No connection inventory at all, so an incident response begins with the open question of which banks were even affected, instead of a lookup in a register.
Waiting on Section 1033 or New York’s bill to resolve before building any of this, when banks are already offering FDX-based API access regardless of what happens to either.
Every one of these is fixable with the same access-governance discipline finance teams already apply to internal system logins. None of it requires waiting for Section 1033 or New York’s bill to resolve.
What to ask ERP or treasury-platform vendors now.
Can the platform maintain a single register of every bank API connection, including data scope, consent start and expiry, and a named business owner?
Does it separately gate read-only data connections from payment-initiation-capable connections, rather than treating access as one bundled permission?
Can a connection be revoked from inside the platform in a single action, with a timestamped record of who revoked it and why?
Does it support FDX or FAPI 2.0 certified integrations, rather than relying only on screen-scraping aggregation for coverage?
Will it alert a named owner before a consent grant expires, or when a connection has gone unreviewed past a set cadence?
Does the connection log feed the same audit-evidence trail used for other access controls, so it is ready for a SOX or similar review without manual reconstruction?
A vendor that can answer all six with a live screen, rather than a roadmap slide, has already built the connection register this article describes.
Practical takeaway.
The regulatory mandate for open bank data is still working its way through a federal court and a New York committee room, and neither is likely to resolve soon. That is not a reason to wait. FDX-based connectivity is already live at 114 million accounts and growing, banks are building to it regardless of what happens in Washington or Albany, and every one of those connections into a treasury or ERP system needs an owner, a scope, and a revocation path today. A finance team that builds the register now is ready for whichever mandate eventually lands, and gets a cleaner, faster, better governed bank relationship in the meantime.
Sources.
- Financial Data Exchange (FDX): official standard, membership, and account-connection figures
- New York State Senate: Assembly Bill A10640, the financial data rights act (introduced March 13, 2026)
- Consumer Finance Monitor: Open banking regulation in 2026, federal rulemaking and state data-sharing bills
- Cozen O’Connor: Section 1033 compliance date, open banking rule enjoined and under reconsideration
- OpenID Foundation: FAPI Working Group, the FAPI 2.0 security profile for financial-grade APIs
- OpenText: The treasury visibility crisis, why global enterprises are rebuilding financial connectivity
- Davis Wright Tremaine: New York proposes open banking-style financial data access legislation
Targeted searches for public X and Twitter commentary on Section 1033’s status, New York’s open banking bill, and FDX’s account-connection figures returned law-firm, standards-body, and vendor pages rather than a credible set of two to four high-signal posts from a regulator, standard setter, or independent practitioner. Ordinary citations are used instead, and nothing is fabricated.