4 Reasons Wealth Platform Migrations Fail to Reconcile and How to Avoid Them

Instrument identity, the entity graph, cost basis and performance – the four things that make an export disagree with the system it came from

A firm decides to move platforms. The negotiation goes well, the vendor agrees to an export, the files land. Positions, transactions, a document archive – all of it, exactly as promised.

Then someone loads it into the new system, runs the reports, and nothing reconciles. Holdings resolve to the wrong instruments, or to nothing at all. Ownership rolls up to totals the family has never seen. Gains are wrong because the acquisition prices came across as a single blended number per position. And the three-year return, the figure that appears in every client review, comes out different from the one the clients have been reading for three years.

Nobody was dishonest. The export contained everything it said it contained. The problem is that in wealth management software the valuable figures are not stored – they are produced, by an engine, from inputs and policies that the export was never going to include.

In the financial data migrations we see, four areas account for most of the reconciliation work. They are also, not coincidentally, where the schedule of a platform replacement actually goes.

1. Instrument identity

A reasonable engineer designs a security table with a price column, then discovers that different exchanges carry different prices for the same instrument on the same day; that each day has an open, close, high and low, and which one you want depends on the use case; and that identifiers misbehave – an ISIN is globally unique, a ticker is not, and every exchange has its own.

On one build the breakthrough was not a library. It was putting a business analyst with real financial knowledge on the problem to write a data model and a dictionary the developers could follow. After that, in the team's own words, the data was not big – it had simply been misunderstood.

Your sources will not agree on this either, and the gap is wider than people expect. Comparing the published holdings models of the major aggregators: one returns CUSIP, ISIN and SEDOL; another returns CUSIP, ISIN and FIGI; a third returns ticker symbol and a description, and dropped CUSIP support in January 2025.

If your canonical model resolves instruments by ISIN and one of your feeds can only give you a ticker, that is not a mapping task you discover in week eleven. It is a scope item, and it belongs in the connector contract before anyone writes an ingest job.

Three further complications are routinely missed at planning time:

1. The security master is a time series, not a table. Instruments change identity. Tickers get reassigned. Companies merge, spin off, redomicile, re-denominate. A holding you resolve correctly today may have had a different identifier when it was bought. A security master with no effective dating cannot reproduce last year's report – it can only produce this year's answer about last year.

2. Corporate actions rewrite history, quietly. A share split does not just change a quantity; it changes every historical quantity, every per-share price, and the cost basis attached to every lot. Handled well, corporate actions live in an adjustment layer with an audit trail; handled badly, they leave you a chart with a cliff in it. When two platforms' numbers diverge with a step-change on a specific date, check corporate actions first.

3. Currency is three decisions, not one. A base currency, a rate source, and a rate date convention – spot on trade date, spot on valuation date, or an average. Two systems that agree on every position and every transaction will still disagree on a multi-currency household total if they picked different answers to any of the three. And nobody writes those choices down until the numbers diverge.

2. The entity graph

Ultra-high-net-worth wealth is not held in accounts. It is held in structures: trusts, holding companies, partnerships, partial ownership, look-through to underlying assets, and a permission model where different family members legitimately see different subsets of the same picture.

Retail platforms model a customer. This work models a family across jurisdictions.

The practical consequence is that the hierarchy has to exist in your schema from the first release, whether or not the interface exposes all of it. Household, client, account group, registration, account – modelled up front, this is a matter of hours. Retrofitted after a year of production data, it is a migration with a reconciliation attached. Getting it wrong is not a UI bug; it is a data-model rewrite.

The subtler point is that a household total is a modelled number, not a sum. Once you have partial ownership and structures that hold other structures, "the family's wealth" depends on decisions your platform makes:

• Does a 40%-owned holding company contribute 40% of its assets, or does it appear as a single participation valued at cost?
• When two family entities both hold units in the same fund, does look-through count the underlying exposure once or twice?
• Does a discretionary trust appear in the beneficiary's total at all?

None of these has a universally right answer. All of them have a house answer, applied consistently, which the previous platform also had – and which was never written down anywhere in the export. When your totals differ from the incumbent's by an amount nobody can explain, this is usually the reason, and it is found by reconciling structure by structure rather than by checking the arithmetic.

3. Cost basis and tax lots

Cost basis looks like a column and behaves like a subledger.

Many aggregation feeds will give you a cost basis figure per position: one number, blended across everything that was ever bought. That is adequate for showing an unrealised gain and inadequate for almost everything else – because the moment a client sells part of a position, the answer depends on which lots went out, and that depends on an accounting method the platform was configured with, possibly years ago.

What travels badly:

• Lot-level detail. Acquisition date and price per lot, not per position. Without it you cannot do specific-lot selection, you cannot age a holding for long-term treatment, and you cannot reproduce a realised-gain report.
• Transfers in with unknown basis. Assets that arrived from another custodian frequently arrive without basis, get a placeholder, and are corrected later by hand. Those corrections are a human artefact of the old system and do not appear in a positions extract.
• Gifts, inheritance and step-up. Basis events that have nothing to do with a trade and everything to do with a document in a file somewhere.
• Basis adjustments from corporate actions. Splits, spin-offs and returns of capital all move basis between lots. Two platforms applying the same corporate action in a different order will not agree.
• Wash-sale and disallowed-loss adjustments, where they apply, which are computed across accounts and across time rather than per position.

The practical rule: if a source or an incumbent gives you a single cost-basis number per position, treat it as a display value and say so on the screen. Do not let it silently become the input to a tax report. And if lot-level history is genuinely unavailable for older holdings – which is common – decide explicitly whether the platform shows a gap or shows an estimate, and label whichever you choose. An estimate that looks like a fact is the one outcome you cannot recover from.

4. Performance

This is the one that surprises people, because it looks like a field and behaves like a service.

On most portfolio-accounting platforms, cost basis, time-weighted return and IRR do not live on the position object at all. They are computed by the accounting engine and exposed through a reporting interface – asynchronous, report-shaped, generated server-side and polled. So an export gives you the rows. It does not give you the engine, and it does not give you the settings the engine was run with.

If your firm claims compliance with the GIPS standards, the point gets considerably sharper:

• A since-inception money-weighted return must be calculated using daily external cash flows – every dated flow since inception and, for funds using subscription lines of credit, those flows too. Period-end snapshots cannot reconstruct it.
• The thresholds that decide when a portfolio must be revalued – "large cash flow", "significant cash flow" – are explicitly firm-defined and composite-specific. A compliant historical return series therefore needs the policy parameters as they stood in each period, on top of positions and transactions.
• The portability provisions turn this from an engineering question into a marketing-eligibility one. Performance from a prior firm or affiliation may be used and linked only if the firm "must have records to support the performance". Records – not a number, not a prior statement in PDF. And where the data came from a third party, the firm remains responsible for it meeting the standard: a vendor's inability to export supporting detail becomes the firm's compliance problem, not the vendor's.

A migration that carries the figures but leaves the supporting detail behind is more than a reporting inconvenience. It can cost a firm the right to present its own track record.

The practical rule: during a transition, cache the incumbent's numbers rather than recomputing them, and treat rebuilding the return engine as its own project with a parallel run and a sign-off – never as a side effect of a UI feature.

What a credible financial data migration test plan asserts

"The data came across" is not a test. These five are, and they are worth writing into the statement of work before anyone signs it.

1. Instrument resolution rate, per source. What share of incoming positions resolve to exactly one instrument in your canonical master – and what happens to the remainder. A source at 94% is not 94% good; it is a manual queue with a headcount attached. Measure it per source, because the aggregate hides the bad one.

2. Ownership reconciliation, structure by structure. For every family, the platform's household total against the incumbent's, with each difference attributed to a specific modelling decision. Not "totals match within 1%" – differences explained, including the ones that turn out to be the incumbent's error.

3. Return reproduction with a published tail. Recompute returns for every portfolio, compare against the incumbent, and report the distribution of differences rather than the average. The average is always reassuring. The question is what the worst fifty portfolios look like and why, because those are the ones with the client conversations attached.

4. Statement diff, line for line. Take a real reporting pack from the last cycle and regenerate it. Not "looks right" – a mechanical diff, with every delta accounted for. This catches rounding conventions, fee display, footnote logic and date labelling, all of which clients notice and none of which appear in a data test.

5. As-of integrity under failure. Kill a feed mid-run and confirm the platform serves the last good snapshot with an honest date rather than a partial one. A migration test that only exercises the happy path has tested the wrong system.

Any platform that claims to have replicated performance owes you these five, not a screenshot.

Why AI makes reconciliation more important

AI raises the cost of getting this layer wrong. An assistant answering questions about a portfolio is reasoning over the same instrument identity, ownership structure, cost basis and computed performance you have just migrated. If any of the four is wrong, the assistant does not fail loudly – it produces a confident, well-written, wrong answer about somebody's money, faster than a human could have produced the right one. Worse, it produces it in natural language, which strips away exactly the cues – a stale "as of" date, a footnote, a blank cell – that a careful reader would have used to catch it.

So the sequence is the reverse of the order in which AI usually gets bought: reconcile first, then automate. Once the data layer is owned and trustworthy, two things pay for themselves quickly.

Document intelligence with a confidence gate. The alternatives inbox – capital calls, statements, fund letters – is where advisor hours actually disappear. Extraction with a scored confidence, an auto-approval threshold, a human queue beneath it, and a permanent link from every booked figure back to its source page.

Overnight scoring, not a chat box. The pattern that consistently lands with advisors is not conversational. It is a system that recalculates portfolios, market context and client data every night and, in the morning, tells each advisor which handful of clients to call and why, with the evidence attached – delivered inside the tool the advisor already has open.

The governing rule in both cases is the same: no figure reaches a person without either high-confidence extraction or a human approval, and every figure keeps a link to its source. AI does not get to invent numbers, and it does not get to be the reason a number cannot be explained.

What this means for your migration

An export is a snapshot of inputs. The numbers your clients read are outputs, and outputs need the engine and the settings as well as the inputs.

So when you plan a platform change, treat these four separately from the screens: resolving instruments through time, modelling the family, reconstructing basis at lot level, and reproducing the return series. This is where much of the migration effort actually goes – and why what looks like a data-transfer project often turns into an accounting and reconciliation project.

The firms that handle this well are not necessarily the ones with the cleanest export. They are the ones that assume from the start that some numbers will have to be rebuilt, validated and signed off before they can be trusted again.

Itexus builds wealth management and capital-markets platforms across multi-custodian aggregation, portfolio analytics, reporting, advisory workflows and the intelligence layer above them. One practical place to start is a migration and reconciliation assessment: run the five tests above against the incumbent system, identify what can transfer as-is, what must be recomputed, and what should remain cached until a parallel run is complete.

That gives the migration a real scope before the larger build begins. If you are planning a platform migration and want to understand where the reconciliation risk really sits, contact Itexus. We can review the current setup, run the assessment, and help define the safest path forward.