How aggregators reach your brokerage account

Every aggregator advertises a number of supported institutions, and none of those numbers says how each institution is reached. That is the thing that decides whether a portfolio app works on a Monday morning. This page is about the three ways in, what each one costs somebody, and the US rule that was supposed to settle the question and never reached brokerage accounts at all.

How it works

There are three parties to every connection: the customer who owns the account, the broker that holds it, and the aggregator that sits between the broker and your app. What varies is how the aggregator proves to the broker that the customer said yes.

The customer's password. The customer types their brokerage username and password into the aggregator's widget. The aggregator stores them and logs in as the customer, then reads the web pages or the private endpoints the broker's own site calls. The rulemaking record calls this credential-based screen scraping. It needs nothing from the broker, which is why it reaches institutions that have no API at all.

A token the broker issued. The customer is sent to the broker's own login page, signs in there, approves a list of permissions, and is sent back. The broker hands the aggregator an access token tied to that grant. The aggregator never sees the password. This is OAuth, and it only exists where the broker has built it and approved the aggregator to use it — usually after a security review and a bilateral data-access agreement.

An API key the customer fetched. Some brokers run a retail trading API and issue keys to their own customers. The aggregator asks the customer to paste the key in. It depends on the broker running such an API at all, and on the customer finding a settings page most never open; the keys also carry the broker's own expiry and approval rules.

Our cards show how unevenly those three are spread. SnapTrade publishes the mechanism per broker: of 40 integrations, 26 are OAuth, 10 take the customer's login and 4 need a broker-issued key. Wealthica, in Canada, lists 125 providers of which 117 are credential-based. Akoya is the other extreme — a network owned by Fidelity, The Clearing House and eleven banks that is token-only and refuses to scrape, so a broker that has not joined is simply unreachable. None of these is better in the abstract. They are different answers to whether coverage or stability matters more.

Why the password is the problem

The case against the first method was written down long before anybody applied it to brokerage accounts. The introduction to RFC 6749, the OAuth 2.0 specification of October 2012, lists what goes wrong when a third party holds the user's password: it has to store it, typically in clear text; it gets access to everything rather than a subset; the user cannot revoke one third party without changing the password for all of them; and a breach of the third party is a breach of the password. RFC 9700, the IETF's OAuth security guidance of January 2025, goes further for OAuth's own password-passing mode: it "MUST NOT be used", partly because it trains users to type credentials in places other than the institution's login page, and partly because it is not designed to work with two-factor authentication.

That last clause is the operational problem. A scraper logs in the way a person does, so every time a broker adds a one-time code, a device check or a redesigned login page, the connection fails until the customer comes back and re-authenticates. The customer sees your app break, not the aggregator's. A token grant happens on the broker's own page, where the broker's two-factor check runs as designed, and what it produces carries only the scopes the customer approved.

FINRA's investor guidance on aggregation, dated January 2024, puts the customer's side plainly: the risks are heightened for aggregators that need the customer's security credentials, because one company then holds credentials for many accounts in one place, and many aggregators "might operate under limited regulatory oversight". The questions it tells investors to ask — who bears the loss after unauthorised access, and whether the aggregator can pay for it — are the ones your users will eventually ask you.

A token is not a free pass either. An OAuth grant carries the scopes the broker chooses to offer, and nothing more. SnapTrade's card records that the eleven brokers requiring per-application approval — Chase, Fidelity and Schwab among them — are read-only without exception. The more stable route is also the one where the broker decides what you may do.

FDX is a format, not an obligation

Once a broker decides to offer tokens, it still has to decide what the responses look like. In North America that answer has a name: the API published by Financial Data Exchange, a standards body operating in the United States and Canada with, in the CFPB's description, over 200 member organisations — data providers, data recipients, aggregators, trade bodies and consumer groups. It specifies the structures a response uses, for balances, transactions, investment holdings and tax data among others, so that a recipient does not map each institution separately.

The CFPB gave FDX a formal role on 8 January 2025, when it recognised the organisation as a standard setter under the Section 1033 rule. The recognition runs to 8 January 2030. Two details in the order are worth knowing before you read a vendor's slide about it. It recognises the organisation, not any particular version of the API. And it states that no standard FDX issued before recognition is a consensus standard in the rule's sense — only standards adopted afterwards through the process the order approves can be.

The rule leans on that process rather than naming a format. Its developer-interface section requires data in "a standardized and machine-readable format" and says that conforming to a consensus standard is an indication the requirement is met. The design splits the work: a recognised body's standard answers "what format", the rule answers "whether". The second half is the one now in court, and nothing about FDX's recognition obliges any broker to publish anything.

For somebody choosing an aggregator this reduces to one fact. Two FDX-shaped responses are built to the same structures whoever serves them; a scraped page follows nobody's structure and is parsed per institution by whoever scraped it. The format tells you about maintenance, not about access.

What Section 1033 says, and what it never covered

Section 1033 of the Consumer Financial Protection Act, part of Dodd-Frank, says a covered person "shall make available to a consumer, upon request," information about the consumer financial product or service the consumer obtained from it. For fourteen years it had no implementing rule. The CFPB finalised one in October 2024 and published it in the Federal Register on 18 November 2024 as the Personal Financial Data Rights rule, the thing most coverage calls the open banking rule.

Three of its provisions bear directly on aggregators:

• An obligation to run a developer interface. A covered data provider must maintain one, in a standardised format, with minimum performance requirements.
• No fees. Section 1033.301(c) bars a data provider from charging the consumer or an authorised third party for establishing the interface or for answering requests through it.
• No reliance on scraping. The rule does not let a data provider satisfy its obligations by leaving third parties to log in with customers' credentials; it has to offer the interface.

Compliance was staggered by size, from 1 April 2026 for depository institutions holding at least 250 billion dollars in assets to 1 April 2030 for the smallest covered banks.

Now the part that matters on this page. The rule covered three kinds of product: Regulation E asset accounts, Regulation Z credit cards, and services that facilitate payments from them. Securities accounts are not on the list. The preamble records that commenters asked for investment products and retirement accounts to be added, and that the CFPB declined to expand the scope, saying it intended to reach other products "through future rulemaking".

There is also a reason that future rulemaking would not simply extend to brokers. Section 1027(i) of the same Act, codified at 12 U.S.C. § 5517(i), says the Bureau "shall have no authority to exercise any power to enforce this title with respect to a person regulated by the Commission" — the SEC. A broker-dealer is exactly such a person.

So the load-bearing fact for anyone reading positions out of brokerage accounts is not the litigation below. It is that even the 2024 rule, fully in force, would not have obliged a US broker to give your aggregator a token for a securities account. Access to brokerage holdings has always been a commercial arrangement between the broker and the aggregator, and every token route in this category exists because a broker chose to build it and chose whom to let use it.

Where the rule stands

It still matters for the bank accounts an aggregator reads alongside brokerage ones, and for the precedent on fees. The sequence, from the court record:

• 22 October 2024. Forcht Bank, the Kentucky Bankers Association and the Bank Policy Institute sue in the Eastern District of Kentucky, on the day the rule is finalised. The Financial Technology Association later intervenes to defend it.
• February and March 2025. After the change of administration the court pauses summary-judgment briefing for a total of 90 days and extends the compliance dates by the same period, moving the first one from 1 April to 30 June 2026.
• 23 May 2025. The CFPB tells the court it has concluded the rule "is unlawful and should be set aside", and then asks for it to be vacated.
• 29 July 2025. The CFPB changes course and asks for the case to be stayed while it writes a new rule instead. The court grants the stay the same day. The compliance dates are not touched.
• 22 August 2025. The CFPB publishes an advance notice of proposed rulemaking reopening four questions: who may act as the consumer's "representative", whether data providers may charge fees to cover their costs, and the security and privacy risks of the whole arrangement.
• 29 October 2025. The court postpones the rule under 5 U.S.C. § 705 and orders that the CFPB is "ENJOINED from enforcing the Personal Financial Data Rights Rule until it has completed its reconsideration of the Rule." The opinion found the plaintiffs likely to succeed on the merits. The first of their four arguments goes to the root of this category: that Section 1033 requires a bank to make data available to the consumer, not to third parties such as aggregators. The fee ban was another.
• Appeal. The FTA (No. 25-6164) and the CFPB (No. 26-5005) both appealed to the Sixth Circuit. On 30 March 2026 that court held briefing in abeyance while the rulemaking runs, with the banks to file status reports every 60 days. In the report filed 28 July 2026, the statement the CFPB supplied says it is reconsidering the rule "with a view to substantially revising it".
• 4 August 2026. The White House Office of Information and Regulatory Affairs receives a CFPB proposed rule titled Personal Financial Data Rights Reconsideration for review, flagged as economically significant. On 27 September 2026 it was still listed as pending review.

On 27 September 2026 the Federal Register held no proposed rule on the subject later than the August 2025 advance notice, and the CFPB's own rulemaking page listed nothing after it. The 2024 rule is on the books and cannot be enforced; a replacement has been drafted and sent for review, and its text has not been published. When it is, the two questions to read first are the fee question and the representative question, because between them they decide whether an aggregator has a right to ask at all and what it pays when it does.

What it costs

The customer pays nothing directly, and nobody publishes what the broker charges the aggregator. What is visible is the aggregator's price to you and the shape it takes.

Per connected user or per connection, monthly. SnapTrade is the one vendor in the category that prints a production price. Its free Build plan covers five connected accounts for development; going live on Launch costs a 100-dollar monthly platform fee plus 1 dollar per connected user per month for daily, read-only data or 2 dollars for real-time data with trading. The platform fee includes no users, so twenty real-time users cost 140 dollars a month, not 40. Plaid bills Investments as a monthly subscription per Item — one customer's link to one institution — for as long as a valid access token exists, and shows the rate only on the last page of its production application. The others quote privately. The SnapTrade and Plaid Investments cards carry the detail, dated.

Broken connections are billed too. This is where the access method becomes money. As recorded on the Plaid card, the Item fee is charged even while the Item is in an error state and no call succeeds; SnapTrade's card records the same for a broken connection, which bills until you delete it. A credential-based connection that fails every time the broker changes its login page is a connection you keep paying for until the customer re-authenticates or you remove it.

The upstream fee is moving into the price. The 2024 rule's ban on data-access fees is one of the four provisions the banks challenged in the case that produced the injunction, and one of the four questions the CFPB reopened. The market did not wait. On 16 September 2025 JPMorgan Chase and Plaid announced a renewed data-access agreement that, in JPMorgan's words, "includes a pricing structure"; the announcement does not give the terms. None of this appears as a line on your invoice. It appears as the per-connection rate your aggregator quotes next year.

Support is the cost nobody lists. Every reconnect prompt is a customer who thinks your product is broken. Across a user base the difference between a mostly-token broker list and a mostly-password one shows up in the support queue before it shows up anywhere else.

What you can do about it

Ask for the mechanism per broker, not the institution count. Take the ten brokers your users actually hold accounts at and get, in writing, which of the three routes each one is on. SnapTrade and Wealthica publish this; where a vendor will not, that is your answer about how the connection behaves. Ten brokers on tokens is a better product than three hundred behind passwords.

Design the reconnect flow before the connect flow. A credential-based connection will break on the broker's schedule, not yours. Decide what the customer sees when it does, how you detect a stale connection, and whether you remove a dead one or keep paying for it. On a per-connection bill, removing it is a line of code with a monthly value.

Do not plan around a legal right that does not exist. No US rule obliges a broker to give an aggregator a token for a securities account — the 2024 rule did not reach them and the CFPB has no enforcement power over SEC-regulated firms. If a broker your users need offers no API and blocks scraping, that is the end of it, and no regulatory date changes that.

If you only need to read, you have a market; if you need to trade, you have a handful of vendors. Even at SnapTrade, the one aggregator in this category that places orders, 24 of 40 integrations are read-only, and a bank-owned network like Akoya is read-only by design. Settle which side you are on before you compare prices.

Put the upstream fee in your model now. Bank data-access fees exist already by private agreement, and the replacement rule may permit them outright. Ask a vendor directly whether its per-connection price can change when an institution starts charging it, and how much notice it gives.

For your own account, prefer the broker's page to the aggregator's form. If an app offers to send you to your broker's login to approve access, that is the token route. If it asks for your brokerage password in its own window, it is the password route, and FINRA's questions — who holds the credentials, who bears a loss, how you revoke access — are yours to ask before you type.