Wealth Management Data Aggregation: Why Coverage Is Local

What multi-jurisdiction wealth managers actually need from an aggregation platform

There is a segment of this market that platform vendors describe poorly and analysts barely describe at all: external asset managers, multi-family offices and advisory firms operating across several jurisdictions.

Ask one of them why they run two aggregation platforms, and the answer is never about features. It is that the platform they like in one market cannot see the local banks in the other. So they run both, pay for both, and then assemble the consolidated picture the family actually asked for by hand, in a spreadsheet, using the most expensive people in the building.

That is not a procurement failure. It is the structure of the market, and it is worth understanding precisely, because it determines what you should build and what you should buy.

The short version: coverage is local, coverage is commercial, and no regulation is coming to fix it for you.

Which resolves into a three-line decision framework – the rest of this article is the evidence for it:

• Buy: institutional connectivity, market by market.
• Own: the canonical model, the history, the reconciliation and the lineage.
• Design for: multiple local sources behind one contract, rather than one global aggregator.

The rules stop at the payment account

There is a persistent hope in this segment that open banking will eventually solve aggregation. It will not, and the reason sits in the legal texts rather than in anyone's roadmap.

What the rules actually compel an institution to share:

| Market · regime | What it compels | What it does not reach | Status | |---|---|---|---| | EU · PSD2 | Payment accounts | Securities custody and asset servicing – excluded expressly (Art. 3(i)) | In force | | EU · FiDA (proposed) | Savings, investments in financial instruments, pensions | Nothing yet – it is not law | In trilogue as of mid-2026; applies 24 months after entry into force | | UK · Open Banking / Open Finance Roadmap | Payments data | Investments, pensions | In force; open-finance scheme design from 2027, scaling to 2030 | | US · Reg 1033 | Deposit accounts, credit cards, payment facilitation | Securities accounts – the regulator has no authority over SEC-regulated firms | Finalised 2024; enforcement preliminarily enjoined, back at proposal stage | | BR · Open Finance | Investments: funds, equities, fixed income, treasury | Cost basis for funds and equities; history beyond 12 months | In force; binds only the largest banks – 38 of 107 participants expose any investment family | | Custody, brokerage, private markets | Nothing, in any market | Everything your clients actually hold | Bilateral feeds, file drops, documents on the issuer's own schedule |

The rules are different in every market. That, and not technology, is why no single platform covers them all.

In the EU, PSD2's access rights attach to payment accounts, and Article 3(i) expressly excludes securities asset servicing by custodians. Custody sits outside the regime by design, not by oversight. The proposed Financial Data Access framework (FiDA) would extend regulated sharing to savings, investments and pensions – but as of mid-2026 it is still in trilogue, its provisions would apply 24 months after entry into force, and its own recitals concede that beyond payment accounts only a minority of institutions expose interfaces at all. Any practical effect lands at the turn of the decade.

In the UK, the FCA's Open Finance Roadmap of April 2026 describes open banking as a way to share access to payments data. Investments and pensions sit in the later extension, with scheme design starting in 2027 and scaling through 2030.

In the US, the CFPB's Personal Financial Data Rights rule covers deposit accounts, credit cards and payment facilitation – and the statute removes the Bureau's authority over persons regulated by the SEC, so securities accounts are structurally out of reach. The rule is not operative in any case: enforcement was preliminarily enjoined in October 2025, and the agency has reopened it at the advance-proposal stage.

Brazil is the instructive exception. It is the one regime in force that reaches the assets a wealth manager actually cares about: positions, transactions and instrument data for funds, equities and fixed income, at billions of API calls a quarter. And it is the best available lesson in what "covered by regulation" actually buys you. The obligation binds only the largest banks; 38 of the 107 organisations in the production directory expose any investment family at all. Transaction history is capped at twelve months. The funds and equities APIs do not return acquisition price and date – so for a long-held position, cost basis is not reliably recoverable from the API. The most advanced investment-data regime in the world hands you an entitlement, not a reconciled book. You still build the pipeline.

Now read all of that from the position of a firm whose clients hold their wealth in custody accounts, brokerage accounts and limited partnerships. Outside Brazil, no regime in force today compels the institutions holding those assets to hand you the data – and inside it, the coverage is partial and the history is short. Wherever a wealth aggregator has coverage, it has it because someone negotiated for it, one institution at a time – which is exactly why coverage is uneven from market to market, and why the map of who covers what changes every year.

Nor has open banking removed credential-based access even where it applies. Read the aggregators' own developer documentation rather than their marketing and the picture is consistent: the large US aggregators document both an API path and a legacy credential path, per institution, with a migration lifecycle between them. One states in its own docs that legacy connections "require credentials to be captured and utilized" by the aggregator. Another reported in September 2024 that 80% of its traffic was "on or committed to" APIs – a carefully worded sentence in which "or committed to" is doing real work. That residual is not a rounding error; it is the part of your coverage that breaks when a bank changes a login page.

How to read a coverage number

If you are comparing providers, the single most useful thing to know is that their headline numbers are not comparable. Across the major aggregation providers we reviewed, the published figures are denominated in at least five different units: share of traffic, share of connections, share of deposit accounts, count of data sources, and count of feeds. Almost none carries an as-of date or a stated methodology, and several vendors publish figures on one page that contradict figures on another page of the same site.

Two consequences follow. First, nobody publishes brokerage or custodial coverage – the big percentages are deposit-account metrics, reused in wealth contexts where they do not apply. Second, ask for the list, not the number. The most useful public artefact in this market is a vendor that simply publishes its feed catalogue: Addepar's integration centre lists 383 portfolio-data-feed entries, 252 tagged as custodian feeds, with regional tags skewing heavily to North America. That is not a criticism – it is an accurate, checkable map of where feed agreements exist, which is more than any percentage gives you.

Six questions to ask every aggregation vendor:

1. Which custodians and brokers – by name – can you deliver holdings for, in each of our markets?
2. For which of those do you deliver transactions?
3. Which provide cost basis and tax lots – and at what depth?
4. How much history comes with a new connection, and can we backfill?
5. Which connections are API-based and which are credential-based – per institution, not on average?
6. Does our contract permit us to persist the data in our own store and redistribute it – including prices and valuations?

The answers are a much smaller, much more specific list than the headline number. That list is your actual coverage.

One more constraint that surfaces late and hurts: holdings and valuation data may be separately licensable. At least one major aggregator warns in its own documentation that third-party data providers may require a separate market-data licence to receive holdings, market values, transactions and vesting data. Before you design a pipeline that lands prices in your own store, confirm in writing that your contract permits it – question six exists because the default answer is often no.

What You Are Actually Buying When You Buy Connectivity

When a firm weighs acquiring an aggregation platform rather than building one, what it is actually trying to buy is not software. It is a portfolio of signed feed relationships – the years of commercial work required to get several hundred institutions to send data on a schedule, in a format, with someone accountable when it stops.

That is also why acquisition rarely transfers cleanly. Connections live in contracts, entitlements and named relationships. They are not a table you copy into a new parent's stack.

So yes: buy the connectivity. Building several hundred institutional relationships from a standing start is the most expensive thing in this stack and the last thing you should attempt.

But this is where the argument usually takes a wrong turn, so let us be exact about it.

Rent the pipes. Never rent the reservoir.

Two different things get called "the data layer," and conflating them is how firms end up dependent all over again.

Connectivity is the pipes. Feed agreements per institution, credentials, per-format parsers, the operational work of noticing when a bank changes something. Expensive, unglamorous, genuinely commercial – and, importantly, replaceable. Connectivity should be replaceable even when connectors are not interchangeable: sources differ in fidelity, history and licensing, but if a better one appears in your market next year, you should be able to take it.

The data layer is the reservoir. Your canonical model. Your entity graph. Your reconciled golden record and the rules that produced it. Your history – the daily snapshots nobody will sell you retrospectively. Your lineage, your permissions, your document extractions. This is not infrastructure. It is the accumulated, compounding asset of the business.

The mistake is not paying someone for coverage. The mistake is letting whoever supplies your coverage also define your schema, hold your history and compute your numbers – because at that point you have rented the reservoir along with the pipes, and the exit price is everything you have learned about your own clients.

If data is the new oil, then notice what the metaphor actually implies. Crude is close to worthless where it sits. Value appears in the refinery and in who owns the storage. A vendor that runs your refinery and keeps your tanks does not have a supplier relationship with you. It has your margin.

Here is the test, and it takes about a minute to run on your own firm:

If you replaced your aggregation provider next quarter, what would you lose?

If the answer is "a connector, and a few weeks of mapping" – you own your data layer. If the answer is "our history, our reports, our numbers, our client-facing view" – you do not, whatever the contract says.

This matters more every year, not less, because of what sits on top. The moment intelligence becomes the product – a copilot that answers a family's questions, an overnight process that decides which clients an advisor should call – whoever owns the reconciled, permission-aware, lineage-tracked data owns the intelligence. You cannot build a defensible AI layer on somebody else's schema, in somebody else's tenancy, over history you are not allowed to keep. The firms that will be able to do interesting things with AI in 2028 are the ones that started owning their reservoir in 2026.

The good news is that this is not a build-versus-buy choice at all. It is a design choice, and it costs very little at the start: put every source behind one connector contract, land everything in a store you own, and never let a supplier's model become your model. Coverage stays rentable. The reservoir stays yours. And because sources are interchangeable by construction, independence arrives incrementally – each direct feed you add turns the aggregator down a notch rather than requiring a migration.

How to Architect Multi-Vendor Wealth Data Coverage

The workable architecture accepts the fragmentation instead of fighting it.

• A local source per market, chosen for coverage in that market rather than for global brand.
• One connector contract that every source must satisfy – the same instrument identity, entity graph, currency policy and "as of" semantics regardless of who is feeding it.
• A capability matrix per source, declared explicitly: does it deliver positions? transactions? cost basis? tax lots? corporate actions? document images? how much history?

That last point is the one most often skipped and it does real damage. Bank-grade balance aggregation is not the same product as tax-lot-grade custodial aggregation. Consumer-fintech aggregators are excellent at accounts, balances and transactions and much weaker on custodial brokerage detail – positions, cost basis, tax lots – which is what wealth reporting actually runs on. A connector that cannot supply cost basis must say so, and the interface must show the gap rather than render a zero. A zero is a lie your advisor will repeat to a client.

Done this way, the fragmentation stops being a growth constraint. Adding a market becomes a connector plus a mapping exercise against a model that already exists, rather than another platform, another licence, another set of report formats and another spreadsheet to reconcile them.

It also changes what the aggregator is for. In year one it is your only source and it looks indispensable. By year three, if the architecture was right, it is one supplier among several, in one market, feeding a store that would survive its removal. That is what independence looks like in practice – not a dramatic exit, but a dependency that quietly stops mattering.

Private markets will stay documents

For the alternatives sleeve, no API is arriving. Capital call notices, distribution notices, K-1s, quarterly fund letters and custody statements are documents – often PDFs, often unstructured, issued on the general partner's schedule and in the general partner's format.

The evidence for that is not anecdotal. Public markets have machine-readable rails: FIX for order flow, ISO 15022 and ISO 20022 for settlement and custody messaging. Private markets have no equivalent for position data – the ISO 20022 catalogue's alternative-funds messages stop at subscription and redemption orders, and we could find nothing in it that models a capital call, a distribution notice or an LP capital account. The nearest thing to a standard is ILPA's reporting template, and ILPA's own guidance has to ask general partners to deliver it "in Excel or digital format that is compatible with reporting software systems," adding that "PDF format is not recommended." When the standard-setter has to ask its own industry not to send PDFs, you have your answer about what arrives.

The timing is structural too. ILPA's reporting windows run to 60 days after each of the first three quarters and 120 days after the fiscal year for direct funds, and longer for funds of funds. On the tax side, a calendar-year partnership's Schedule K-1 is due 15 March, but a valid six-month extension pushes furnishing to 15 September. Private-markets data is not late because someone is disorganised. It is late by design, and your platform has to be honest about that on the screen.

So document extraction is not a stopgap on the way to a proper integration. It is a permanent layer of the pipeline and should be built like one: extract entities, amounts and dates; score the extraction's own confidence; auto-book above a threshold; route everything below it to a human; and keep every figure linked to the page it came from.

What to do with this

If you operate in more than one jurisdiction, the strategy that works is not to find the platform that covers everything. There isn't one, and the regulatory map says there won't be for years.

It is to accept a portfolio of sources, hold them to one contract, and own the layer above them – the canonical model, the reconciliation, the history, the reporting and the client experience.

Rent the pipes; they are a commodity with a price. Own the reservoir; it is the only part of this stack that compounds, and the only part a competitor cannot buy.

Itexus builds wealth-management and capital-markets platforms: multi-custodian aggregation, portfolio analytics, reporting, advisory workflow and the intelligence layer on top of them. If you are mapping sources across several markets, the useful first step is usually a short scoped assessment of the hardest layer – not a proposal for the whole platform.

Sources

• Payment Services Directive (EU) 2015/2366 – Art. 3(i), Art. 4(12), Art. 67(1).
• Proposal for a Regulation on a framework for Financial Data Access (FiDA), COM(2023) 360 – Art. 2(1)(b), Recitals 5 and 7, Art. 36; procedure file 2023/0205(COD) (status: trilogue, mid-2026).
• FCA, Open Finance Roadmap, 14 April 2026.
• 12 CFR § 1033.111(b) (Personal Financial Data Rights, scope); 12 U.S.C. § 5517(i); Forcht Bank, N.A. v. CFPB, No. 5:24-cv-00304 (E.D. Ky., preliminary injunction 29 October 2025); CFPB ANPRM, 22 August 2025 – both reflected on the CFPB compliance page.
• Brazil: Resolução Conjunta BCB/CMN nº 1 de 4 May 2020, Art. 5º, I; Resolução BCB nº 109/2021, Art. 2º, VI; Instrução Normativa BCB nº 615/2025 (Manual de APIs v7.0); the Open Finance Brasil OpenAPI specifications and the production participants directory, counted July 2026.
• ILPA, Reporting Template Guidance v2.0, January 2025 (delivery format and reporting windows).
• IRS, Instructions for Form 1065 (2025) and Rev. Proc. 2019-32 (Schedule K-1 furnishing deadlines and the six-month extension).
• ISO 20022 message catalogue, alternative-funds messages (setr.059–setr.064).
• Vendor developer documentation, accessed July 2026, for the claims about API-versus-credential connection paths, market-data licensing and published feed catalogues. Each is drawn from the provider's own public documentation rather than from marketing pages or third-party comparisons.