The Wealth Platform Ownership Line: What to Build, What to Buy, and Why AI Changes It

The reference architecture, layer by layer – and why AI finally makes the data layer non-optional

We keep a record of every inbound request the firm has been asked to scope since 2018. Six hundred and six of them carry a written brief. Recently we went back through all of them looking for a specific thing: how many asked us to build a data layer.

The answer is none. Not one, in nine years, in either of the two languages we log them in.

Firms ask for a portal. A mobile app. A dashboard for advisors. A client experience that looks like the one their competitor demoed. Since 2023 they increasingly ask for an assistant. What nobody asks for is the layer underneath, because from outside it looks like plumbing, and plumbing is what you assume comes with the building.

It doesn't. It is much of the work, much of the cost – and the layer on which most of the durable value compounds. For the first twenty years of this market you could get away with not owning it, because the output was a PDF and a PDF looks the same whoever computed it.

That is the part that has now changed.

The ownership line

Here is the architecture we build when a firm decides to own its wealth platform. It is deliberately drawn as a stack with one bold line across it, because that line is the only architectural decision that really matters.

Rent the sources. Own the normalization, data model, history, workflows and intelligence. That is the whole argument in one line, and it is worth fixing before anything else, because "plumbing" gets used loosely below – sometimes for the sources themselves, sometimes for the pipe that carries them. Only the sources are rented. Everything that touches what the data means is owned.

Below the line: sources. Custodian feeds, local aggregators per market, market data, documents. These are priced, swappable and never your schema. You will rent most of them for years, and you should – building several hundred institutional feed relationships from a standing start is the most expensive thing in this business and the last thing you should attempt yourself.

Above the line: everything else. And the design rule for everything above it is that no supplier's model, schema, tenancy or roadmap is allowed to leak upwards.

Get that line in the right place and a source becomes a connector change. Get it wrong – let the vendor that supplies your coverage also define your entity model and hold your history – and a source becomes a migration.

The connector layer

Every source lands through one contract. Scheduled extraction, validation, mapping into your model, and – the part usually missing – an explicit capability declaration: what this source can and cannot give you.

That last item does more work than it looks like. A connector that quietly returns nothing for cost basis is indistinguishable, three layers up, from a portfolio with no gains. A connector that declares it cannot supply cost basis lets the interface show a gap instead of a zero, and lets the roadmap price the gap.

A connector contract with only one implementation is not a contract; it is a coincidence. The second source is what proves it holds. With a stable connector contract, replacing Custodian A with Custodian B should change the ingestion implementation – not portfolio accounting, reporting, permissions or AI retrieval.

The data layer – the part that compounds

This is the reservoir, and it has more structure than "a database."

Three zones. Raw, exactly as it arrived and immutable – because when a figure is disputed eighteen months later, the argument is settled by what the custodian actually sent, not by what your pipeline made of it. Refined, where instruments resolve and entities reconcile. Ready, the golden record every screen and every report reads from.

Open format, on purpose. Store the reservoir in an open table format rather than a proprietary one. This is the discipline that stops the whole exercise being circular: a firm that escapes a vendor's data layer only to lock itself into its own bespoke store has bought a better landlord, not a freehold. If your storage format is open and your model is documented, your platform is replaceable by you – which is the only real test of ownership.

Governance is a layer, not a policy document. Catalog, quality rules, lineage, access. Lineage in particular stops being paperwork the moment a client asks why a number changed: either you can walk from the figure back through the transformation to the source record, or you cannot, and no amount of process makes up for it.

Serving is three shapes, not one. The golden-source database that the application reads. A vector index for retrieval over documents and text. A document store holding the originals every extracted figure links back to. All three are views onto the same governed data, which is what keeps an assistant's answer and a report's number in agreement.

History is the asset nobody budgets for. The daily snapshots you accumulate from the night you switch the sync on are a time series no vendor will sell you retrospectively. It is also the part with the strangest economics: it costs almost nothing to start and cannot be bought later at any price.

Business services

The logic that turns rows into figures: aggregation across custodians and entities, portfolio accounting at lot level, analytics and risk with look-through, the report engine, and the advisory workflow that turns an exception into somebody's task.

This is the layer people mean when they say "the platform," and it is genuinely substantial work – but it is ordinary software over trustworthy data. It is only hard when the layer beneath it is not trustworthy, which is why it is so often mistaken for the hard part. Once the governed data layer exists, the application logic becomes conventional – still substantial, but no longer structurally mysterious.

The intelligence layer, and why it changed the argument

For twenty years a firm could rent its data layer and survive, because the output was a quarterly PDF. Nobody asked the PDF a follow-up question.

An assistant is different in a way that is easy to underestimate. When a family member types "what is our liquidity across all the entities, and what is committed to capital calls in the next ninety days?", the answer is assembled live, in natural language, from the entity graph, the position data, the extracted documents and the permission model – and it is delivered without any of the cues a careful reader uses to sanity-check a report. No "as of" line in small type. No blank cell. No footnote. Just a fluent, confident paragraph.

That is why the intelligence layer is not a feature you add on top of a rented data layer. It is the thing that makes blindly renting the data layer increasingly untenable.

Four capabilities carry almost all the value we have seen actually land with users:

• Grounded question answering, where every answer cites the record it came from and refuses when it cannot.
• Document intelligence with a confidence gate – capital calls, statements, fund letters extracted, scored, auto-booked above a threshold and queued to a human below it.
• Report drafting, templated where the format is fixed and generative only in the commentary, with every figure traceable.
• Overnight insight – the system scores portfolios, market context and client data nightly and tells each advisor which handful of clients to call and why, inside the tool they already have open.

Underneath those sits the part that decides whether any of it is deployable in a regulated firm:

A tool gateway, not a data dump. The model does not get a database connection. It gets a small set of governed tools with declared inputs and outputs, each one logged. This is the same pattern the wider industry is converging on for agent-to-system access, and it is the difference between an assistant that can be audited and one that can only be trusted.

Entitlements at the data boundary, not in the prompt. This is the mistake we see most often in pilots. The user's scope – role, family, entity, region – must be compiled into a filter that constrains the query before the data is retrieved. Asking a model politely in a system prompt not to mention the other family's holdings is not an access-control mechanism; it is a hope. If the retrieval layer can return it, eventually something will surface it.

Guardrails and citations as infrastructure. Verification, redaction and an audit trail on the way out, not a review step someone remembers to do.

Model runtime inside the boundary. Inference requests carry client data. That makes the location of the model an architectural question, not a procurement one – and in a private-banking context, usually the first question a security architect asks. Designing for in-region or self-hosted inference from the start costs a configuration decision; retrofitting it costs a re-architecture.

And running across every layer: identity and entitlements, an append-only audit trail, regional key management, lineage, observability, and data residency per region. Cross-cutting concerns are called that because they cannot be added at the end.

Where this is heading

We went looking for evidence that firms are ripping out incumbent wealth platforms and replacing them with custom builds. That is not what the record shows, and the real pattern is more useful than the one we expected to find.

Recent examples argue against building everything in-house. In 2024 Goldman Sachs shut Marcus Invest and sold the digital investing accounts to Betterment. Goldman's president John Waldron, on the record: "We thought we could be competitive. I think we learned it's a lot harder than we thought it was." Citi – arguably the most motivated builder in the sector – still handed its global unified-managed-account programme to an outside vendor in 2026 and built its flagship client-facing AI on Google Cloud and DeepMind rather than in-house. Julius Baer is reported to be replacing its ageing Swiss core with a vendor product, a programme that has absorbed around CHF 400 million and slipped roughly eight years from its original target.

And the plumbing vendors are consolidating, not dying. Follow the capital: in the two years to mid-2026 it went into data rails, not interfaces. iCapital raised over $820 million at a valuation above $7.5 billion and used it to absorb Mirador, a family-office consolidated-reporting vendor. Canoe Intelligence, which extracts data from private-markets documents, raised at more than three times its previous valuation. Addepar and Arch raised at similarly rich multiples, both citing private-markets data as a use of funds. Nearly every general-purpose wealth platform in the set is buying or partnering for private-markets data. If your plan is to build multi-custodian aggregation from a standing start and out-run that, the market is telling you something.

But look at what those same institutions build themselves. Morgan Stanley built its Next Best Action recommendation engine internally over its own client data – piloted with 500 advisers, rolled out to roughly 16,000. Its later advisor assistant reached 98% adoption; the model belongs to a vendor, but the corpus and the workflow belong to the bank. JPMorganChase reported, in its own 2026 shareholder letter, an internal assistant serving 12,000 users across the private bank and US wealth management, with 25 specialised agents delivering around a million personalised insights to front-office staff. Citi Wealth built four AI tools in-house while buying its UMA programme; Wells Fargo put a billion dollars into its own advisor technology while licensing its portfolio-analytics engine from BlackRock. Every one of those sits above the plumbing. Not one of them is an aggregation platform.

So the line is being drawn – and it is being drawn in the same place by every institution large enough to have thought about it properly. Buy the undifferentiated data plumbing. Own the data, the workflow and the intelligence on top of it. That is the ownership line in the figure above, arrived at independently by large institutions facing the same build-vs-buy decision at much greater scale.

It is also worth noting that the line moves, in both directions. UBS – which consolidated 1.2 million inherited clients onto its own platform and decommissioned some 700 applications in a single year – also terminated an inherited BlackRock Aladdin contract and migrated those funds onto its own systems, citing cost. Rented is not permanent. That is the point of renting well.

One honest caveat about scale

This argument scales with the size of the book and the number of jurisdictions, and it is not universal.

A survey of 317 family offices puts technology at about 7% of operating cost, with operating cost averaging 41 basis points of assets – which works out at roughly 3 basis points of AuM, a few hundred thousand dollars a year for a typical office. The same survey finds an average of twelve staff, and technology as the first hire for 1% of offices globally. A separate study of 354 single-family offices found 72% either underinvested or only moderately invested in operational technology. Meanwhile adoption of bought automated reporting among North American family offices jumped from 46% to 69% in a single year.

At that scale a custom platform is not a strategy. A bought platform with an owned data layer behind it is.

The ownership-line argument earns its keep when the book is large enough that the plumbing already costs real money, or when you operate across enough jurisdictions that no single vendor covers you – a multi-family office running four markets, an external asset manager, a bank's wealth division. For a single office with one custodian and twelve staff, buy well, insist on your own copy of the data, and spend the engineering budget on the twelve people instead.

We would rather say that plainly than sell a platform build to a firm that should not have one.

What actually changed

None of the above is new. Institutions have been buying plumbing and building differentiation for twenty years.

What changed is the top of the stack. In our own inbound requests, generative AI appears exactly zero times in the six years to 2022, arrives in 2023, and by 2026 has roughly doubled again as a share of what firms describe. Every one of the production deployments above is a system that reads a firm's own data and speaks to a human in sentences.

That is what moves the data layer from an operational concern to a competitive one. When the output was a quarterly PDF, a rented data layer was survivable. When the output is an answer – assembled live, in natural language, from your entity graph and your permission model – the quality, lineage and governance of the data underneath become the product. And you cannot buy that from the vendor whose schema you are borrowing.

Where we come into this

We build these platforms – the connector layer, the lakehouse, the business services, the advisor and family experience, and the intelligence layer on top of them. Some of it is a full build; more often it starts as a rescue or a rebuild of the top of somebody's existing stack while the incumbent keeps running underneath.

Three things about how we work are worth saying plainly, because they are the parts clients tell us mattered:

It runs in your environment from the first commit. Your cloud, your repositories, your ticket system, your keys. Not a handover at the end – there is nothing to hand over, because it was never anywhere else.

Your engineers are on the team, not on the distribution list. Continuity is not a support contract; it is a property of a codebase that somebody on your side has been reading since week one, with documentation and training treated as deliverables rather than as the phase that gets cut when the schedule tightens.

The build owns no IP you cannot take. Everything delivered belongs to you. Where we reuse components, they come under terms that create no hook. And every external interface gets contract tests, so the day the incumbent changes a response shape, the build fails loudly instead of the numbers going quietly wrong.

The first engagement is usually small and deliberately shaped so that its output survives whatever you decide next: an extraction verdict on your incumbent, a source capability matrix per market, a canonical model and connector contract, a reference architecture your group IT can review, and a phased plan with the ownership line drawn on it. Weeks, not quarters. Useful even if you go on to buy rather than build.

The one thing we would push back on, every time, is starting with the assistant. Build the reservoir first. The intelligence is what it is for – and it is only as good, as safe and as defensible as the layer it stands on.

If you are deciding where that ownership line should sit in your current stack, send us the architecture you have today. We can map what to keep, what to own, and what not to rebuild.