Account Aggregation

Account aggregation is the collection of a consumer's financial account data, balances, transactions and account details, from multiple providers into a single view controlled by an application the consumer has chosen. The application is rarely doing the collecting itself. In between sits a data aggregator, a specialist firm that maintains connections to thousands of banks, card issuers, brokerages and payroll systems and resells that connectivity. The federal rule on consumer financial data uses that exact term and defines it as "a person that is retained by and provides services to the authorized third party to enable access to covered data" (12 CFR 1033.131). Plaid is the best-known example of one.

Aggregation is not the same as the app that uses it, and the difference is worth holding onto. A budgeting app is one consumer of aggregated data; so is a financial planner's software, a net-worth tracker, a lender underwriting from cash flow rather than from a credit file, and the account-verification step that confirms a routing and account number before a transfer is set up. The app category and how to choose one belong to the budgeting apps page. This page is about the plumbing underneath all of them.

There are two ways an aggregator gets in, and a consumer can usually tell which one is being used by what they are asked for. The older method is credential-based, often called screen scraping: the consumer types their online banking username and password into the aggregator's flow, the aggregator stores or holds those credentials, signs in as the consumer, and reads the pages. It works everywhere, including at institutions that offer nothing else, and it has two structural problems. The credential it holds is the same one that can move money, so the connection is only as narrow as the aggregator's own discipline makes it. And it breaks whenever the bank changes its login flow or adds a security step.

The newer method is a permissioned interface. The consumer authenticates at their own bank, in the bank's own screen, and the bank issues the aggregator a token scoped to reading specified data. No banking password reaches the aggregator or the app. The connection can be revoked at the bank as well as at the app, and the token can be limited to particular accounts and particular categories of data. From the consumer's side the visible tell is whether the password is typed into the app's screen or into the bank's.

Aggregation is used well beyond budgeting, which is the reason it is worth understanding as its own subject. Planning software builds a household balance sheet from linked accounts rather than from a questionnaire. Net-worth trackers do the same thing for the consumer directly. Lenders use cash-flow data as an alternative or a supplement to a credit file. Payment setup uses it for instant account verification, replacing the micro-deposit test that used to take days. Each of those is a different bargain, because each collects a different amount of data for a different purpose, and the purpose is what a consumer should be reading before authorizing anything.

The federal framework has a name, and stating what it is and when it binds is more useful than a slogan about open banking. In November 2024 the Consumer Financial Protection Bureau published a final rule, "Required Rulemaking on Personal Financial Data Rights", codified at 12 CFR part 1033. It requires data providers, meaning the institutions holding the accounts, to make covered data available to the consumer and to authorized third parties on request, and it bars them from charging a fee for doing so (1033.301(c)). Covered data includes transaction information, and a provider is deemed to have supplied enough history if it makes available at least 24 months of it, along with balances, the information needed to initiate a payment, terms and conditions, upcoming bill information and basic account verification information (1033.211). Compliance is staged: 1033.121(b) sets April 1, 2026 for the largest depositories and nondepositories, then April 1 of 2027, 2028, 2029 and 2030 for successively smaller ones, and 1033.111(d) leaves depository institutions at or below the Small Business Administration size standard outside those subparts altogether. So whether a particular bank owes a particular duty today is a question about that bank's size, not a general fact. The Bureau published an advance notice of proposed rulemaking on August 22, 2025 headed "Personal Financial Data Rights Reconsideration", so the rule's future content is a live policy question even though the rule is codified.

What the rule asks of the third party is the part a consumer actually sees. To become authorized, a third party must give the consumer an authorization disclosure that is clear, conspicuous and segregated from other material, and obtain the consumer's express informed consent by having it signed electronically or in writing (1033.401). The disclosure has to name the third party and the data provider, describe the product being provided, list the categories of data to be accessed, state that collection will not last longer than one year after the most recent reauthorization, and describe how to revoke (1033.411(b)). The third party then has to limit collection, use and retention to what is reasonably necessary for the product the consumer asked for, and the rule says outright that targeted advertising, cross-selling of other products and the sale of covered data are not part of, or reasonably necessary to, any product (1033.421(a)). Collection is capped at one year from the most recent authorization, after which a new authorization is required (1033.421(b)). Revocation must be "as easy to access and operate as the initial authorization", with no cost or penalty, and the third party must then tell the data provider, any aggregator and anyone it passed the data to (1033.421(h)). After revocation it must stop collecting and stop using or retaining the data unless retention remains reasonably necessary for the product (1033.421(i)).

The aggregator itself is separately named, which is unusual and useful. Under 1033.431 an aggregator may perform the authorization procedures on the third party's behalf, but the third party stays responsible for them; the authorization disclosure must name the aggregator and briefly describe what it does; and the aggregator must certify to the consumer, before touching the data, that it agrees to the same conditions the third party agreed to. That is the provision that turns an invisible intermediary into a named one.

None of this is a security guarantee, and the practical advice is unglamorous. Aggregation widens the number of organizations holding a copy of your financial data, which is a real cost weighed against a real benefit. Review the list of connected applications at each institution, not only inside each app, because those are two separate places and revoking in one does not always revoke in the other. Disconnect anything you no longer use. And where an institution offers a permissioned connection, prefer it to typing a banking password into somebody else's screen.

From the consumer's side the flow is short. Choose an app or adviser. Select an institution from a list. Authenticate, either by typing the banking credential into the aggregator's screen or by being handed to the bank's own login and returning with a token. Choose which accounts to share. The app then receives balances and transaction history, refreshed on a schedule, and shows them alongside everything else.

A worked example of the authorization clock, which is the part with an actual deadline. Suppose a consumer authorizes a planning tool on March 3, 2026 under the federal rule. Collection of their data may run for at most one year after the most recent authorization, so the third party must obtain a new authorization no later than March 3, 2027 to keep collecting (12 CFR 1033.421(b)(2) and (b)(3)).

If the consumer instead revokes on September 1, 2026, three things follow under 1033.421(h) and (i). The revocation method must have been as easy to use as the original authorization and must cost nothing. The third party must notify the data provider, any data aggregator and anyone it passed the data to. And from that point it must stop collecting, and stop using or retaining what it already collected, unless keeping it is still reasonably necessary to provide the product the consumer asked for. Note what the last clause does: revocation stops the flow, and it does not automatically erase the history.

Pros

• One view of accounts held at different institutions, which is what makes a household balance sheet or a spending picture possible at all.
• It removes manual entry, which is the step that ends most attempts at tracking money.
• A permissioned connection shares read access without giving anyone your banking password, and can be revoked at the bank as well as at the app.
• The federal rule requires a named disclosure, express consent, a one-year limit on collection and a revocation method as easy as the sign-up.
• The same rule states that targeted advertising, cross-selling and selling your data are not reasonably necessary to any product, which is a limit on what an authorization can be stretched to cover.

Cons

• Every connection adds another organization holding a copy of your financial data, and that cost does not go away when you stop using the app.
• A credential-based connection means a third party holds a password that can also move money, and it breaks whenever the bank changes its login.
• The rule's duties on institutions phase in by size through 2030, and the smallest depositories sit outside them, so a reader's own bank may owe nothing yet.
• Revoking inside an app and revoking at the bank are different actions, and people usually do only the first.
• Revocation stops future collection but does not by itself delete data already held where retention is still reasonably necessary for the product.
• Aggregated data is only as good as the categorization applied to it, and connections silently stop refreshing more often than anyone expects.