Twice this year we have had the same conversation on two continents, with firms that have nothing in common except the size of the balance sheets they look after.
One was a North American advisory firm running its book on a large portfolio-accounting suite. The other was a cross-border multi-family office running one platform in its European market and a completely different one in its Latin American market, because neither vendor had the local bank connections in the other’s territory.
Both said a version of the same sentence: we don’t want to depend on these software companies any more.
And both, at the outset, believed roughly the same thing about what that would take – that the platform they were renting was, underneath the interface, a database; that the data in it was theirs; and that with a competent engineering team the data could simply be moved somewhere they controlled.
That belief is the most expensive misconception in wealth technology – and the reason so many wealth platform migrations are priced wrong before they begin. It is also completely understandable, because everything about how these platforms are sold encourages it.
What a licence actually covers
The consolidated view your advisors look at every morning is not a product. It is the output of a pipeline – and that pipeline has at least six layers, only two of which you have meaningful control over.
Here is a test worth running before you plan anything. Ask your vendor, in writing, what you receive if you leave.
The answer will be figures. Positions, transactions, perhaps a document archive. What you will not receive is the thing that made those figures appear: the feed agreements with each custodian, the parsers that turn a fund administrator’s PDF into a number, the reconciliation rules that decide which source wins when two disagree, and the accounting engine that turns a stream of transactions into a return series someone is willing to sign.
There is a specific version of this that catches good engineering teams by surprise.
Derived figures are not rows. On most portfolio-accounting platforms, cost basis, time-weighted return and IRR do not live on the position object at all. They are produced by the accounting engine and exposed through a reporting interface – asynchronous, report-shaped, generated server-side and polled. So when you “export your data,” you get the rows. The numbers your clients actually read – performance, gain and loss, cost basis – are not rows. They were a service you were renting, and the export does not include it.
This is why “we’ll replicate the data layer” is not a plan. The value of a data layer is not its schema. It is the ingestion capability: hundreds of feed relationships, years of parser edge cases, and a reconciliation discipline earned one break at a time.
Before someone on your team offers data-protection law as the lever, it is worth knowing that it draws exactly the same line. The GDPR right to data portability covers personal data the individual provided; the regulators’ own guidance (Article 29 Working Party, WP242 rev.01, endorsed by the EDPB) states that “inferred data and derived data … do not fall within the scope of the right to data portability.” In a wealth platform, the figures your clients actually read – computed performance, attribution, reconciled positions, look-through exposure – are precisely such derived data. It is also a right belonging to the individual client rather than to your firm. Portability law reaches the raw inputs. It does not reach the layer you actually need.
Five questions to ask your wealth management platform vendor before you plan a migration
- What exactly is in the export – the rows alone, or also the derived figures my clients read: performance, cost basis, gain and loss?
- At what history depth and granularity – daily snapshots, or period-end only?
- What do my contract’s API terms actually permit – rate limits, record caps, and bulk extraction into a store I own?
- Are market data, prices and valuations licensed for redistribution into my own systems?
- Which relationships, if any, can transfer with me – feed agreements, credentials, custodian connections, and in whose name do they sit?
Ask in writing. The gaps in the answers are your real migration scope.
Independence is four things, not one
Independence is not a single purchase. It is four things you can own separately, and in this order:
- The client and advisor experience – the layer your clients judge you on.
- The data – a copy, in your schema, your infrastructure, your region.
- The models – how you compute allocation, exposure, performance, risk.
- The connections – the feed relationships themselves, in your own name.
The failed replacements we have seen typically tried to buy all four at once. The ones we have watched work bought them in that order.
That ordering is not a preference. It follows from a structural asymmetry that almost nobody prices correctly:
The top of the stack holds nearly all of the visible value and is the cheapest layer to change. The bottom holds nearly all of the risk and is the most expensive.
The advisor experience – the screen where a family officer loses twenty minutes every morning stitching together five reports – is typically the fastest layer to replace. The connectivity layer beneath it is by far the slowest, and most of that time is commercial rather than technical: getting each institution to agree to send data, getting into their delivery process, agreeing formats, and handling the day they change those formats without telling you.
Why the big bang loses
The instinct with a platform you dislike is to replace it: pick a cutover date, run a single-event platform migration, switch off the old system on a Monday morning.
In wealth management this fails for reasons that have little to do with engineering skill. You are not replacing an application. You are replacing a book of record whose outputs are read by clients, auditors and regulators, and whose history has to stay defensible after the switch. A consumer app can ship a bug and fix it by Tuesday. A performance figure that changes after a client has seen it is a different category of event.
What the record actually shows
The best-documented case is TSB’s 2018 core-banking migration in the UK – roughly five million customers moved onto a substantially new platform in a single event.
The independent review that followed, commissioned from Slaughter and May, did not conclude that big-bang migration is wrong. Its finding was narrower and harder to dismiss: the approach “would not necessarily have been the wrong approach had the right mitigants been put in place” – but the bank “did not give sufficient consideration as to whether a largely single event migration was the right choice, what the risks of this approach would be, or how those risks would be mitigated,” and that choice “was not substantively discussed by the TSB Board.”
Three specifics from the review will be familiar to anyone who has shipped under a fixed date:
- “This timetable was ambitious and unrealistic. The pattern of setting a desired end date and then creating a plan to fit that date, whether or not it was realistic or involved taking too much risk, was set for the remainder of the Programme.”
- Test targets were lowered after tests failed at the original load. Real post-go-live volumes exceeded the lowered targets.
- After go-live, rollback was not available.
The cost: £330.2m of post-migration costs, a £162.7m profit turned into a £105.4m loss, 225,492 complaints and £32.7m of redress – then, four years later, £48.65m of regulatory fines from the FCA and PRA, and a personal fine for the CIO. Severe disruption lasted about a week; the bank did not return to business as usual for some seven months.
None of that says migrations are impossible. It says a single-event migration spends your entire risk budget in one night, and everything protecting you has to be perfect at the same moment. Staging spends the same risk in instalments, each small enough to survive.
Nor is it a freak event. The FCA’s own cross-sector survey (Cyber and Technology Resilience, November 2018) found that failed IT changes caused 20% of the operational incidents reported to it between October 2017 and September 2018 – the largest single root cause. The 2012 RBS/NatWest/Ulster Bank outage, which drew £56m in fines and affected at least 6.5 million customers, traced to a batch-scheduler upgrade backed out along a path that had never been tested.
In a wealth context the equivalent failure is quieter but longer-lived: performance history that no longer reconciles, cost basis that arrived blended, statements a client has already seen that change after the fact – and an audit trail that stops at the cutover date.
The alternative is not heroism. It is sequence: build your own interface on your own copy of the data first, leave the incumbent running as the system of record, and buy the expensive layer in instalments.
How to buy custom software without buying a new dependency
The most honest question we are asked in these conversations is blunt: once you have built this, how do we get rid of you?
It is the right question. A firm replacing a vendor to escape dependency has gained nothing if the replacement is a development partner it cannot leave.
It is worth noticing how little help you get from anywhere else. The industry built a standardised, deadline-enforced rail for moving the custody relationship – FINRA Rule 11870, a customer securities account transfer process rather than a general data-portability standard: validate a transfer instruction in one business day, complete it in three. It built nothing equivalent for moving the analytics and reporting history. And the recordkeeping obligation sits on the regulated firm, not on its software vendor: a firm that cannot extract its own records because a vendor will not release them is still the party in breach. Lock-in is not only a commercial inconvenience. It is a compliance exposure that the vendor does not carry.
The answer is architectural, not contractual:
- The client’s cloud, the client’s repositories, the client’s ticket system, from the first commit – not a handover at the end.
- Their engineers on the team from day one, so knowledge transfer is continuous rather than an event.
- No vendor IP in the build. Everything delivered belongs to the client; reusable components come under terms that create no hook.
- Documentation and training as deliverables, not as the phase that gets cut when the schedule tightens.
- No production access required by the builder for the system to run.
- Contract tests against every external interface, so that when the incumbent changes a response shape – and it will – the build fails loudly instead of the numbers going quietly wrong.
Continuity is a property of how the system was built. A support contract is what you buy on top of that if you want it, not the thing that keeps you safe.
What this looks like as a piece of work
Firms in this position usually ask us for a proposal for the whole platform. We almost always suggest something smaller first, because the whole-platform number is unknowable until somebody has actually looked at the hardest layer.
What that first engagement produces is a short list of concrete things, and it is worth naming them, because “discovery” has been devalued into meaning “a month of meetings”:
- An extraction verdict on your incumbent. Not “they have an API” – what their API actually returns, at what volume, under what rate limits, with what history depth, whether your contract permits bulk extraction into your own store, whether market-data redistribution is licensed, and what the fallback path is when the answer is partly no.
- A source capability matrix for every market you operate in. Per source: positions, transactions, cost basis, tax lots, corporate actions, documents, history – declared, not assumed, with the gaps written down as gaps.
- A canonical model and connector contract. The instrument identity, entity graph, currency policy and “as of” semantics every future source will have to meet. This is the artefact that makes the second market cheap.
- A reference architecture your group IT can review. Deployment per region, where data rests, where inference runs, how identity and entitlements are enforced at the data boundary rather than in the interface.
- A phased plan with the ownership line drawn on it – what you own at the end of each phase, what you are still renting, and what each phase costs.
That work is measured in weeks, not quarters, and it is deliberately structured so its output is useful even if you then decide to buy rather than build. A firm that walks away from a build with an accurate source map and a canonical model has still gained the two things that make every later decision cheaper.
The reason we sequence it this way is not caution. It is that the single largest cost driver in these programmes – the extraction rights and the true shape of the incumbent’s data – is knowable in weeks and unknowable from a specification. Pricing a platform before that is guessing, and the guess is always wrong in the same direction.
The shape of the answer
Independence is not a purchase. It is a sequence.
You can own the client experience quickly. You can own a normalised copy of your data as fast as your incumbent’s exportability allows. You can own the models once the data is trustworthy. And you can own the connections gradually, one market and one institution at a time – while the platform you are replacing keeps running, and while every release along the way puts something in front of an advisor that was not there the week before.
The firms that get this right are not the ones who choose the best vendor. They are the ones who work out which layers they actually need to own, and buy them in the right order.
Related reading
- Coverage is local – why no single aggregation platform covers every market, what open banking does and does not compel, and how to compose sources instead.
- Why the numbers don’t travel – instrument identity, the entity graph, cost basis and performance: the four things that make an export disagree with the system it came from.
- What an owned wealth platform is made of – the reference architecture, layer by layer, and where the intelligence layer actually belongs.
Itexus builds wealth-management and capital-markets platforms, from multi-custodian aggregation to the intelligence layer on top. When a firm is weighing build against buy, we usually suggest starting small: a short, scoped assessment of the hardest layer settles the question faster than any full-platform proposal. If you want to know what your hardest layer is – and what leaving your incumbent would actually get you – that’s a one-call conversation with our team.
Sources
- Regulation (EU) 2016/679, Article 20; Article 29 Working Party, Guidelines on the right to data portability (WP242 rev.01), 5 April 2017, endorsed by the EDPB.
- Slaughter and May, Report of the Independent Review of the 2018 TSB Migration, 31 October 2019 (¶¶2.7, 2.13–2.18, 2.24, 2.39, 2.43); FCA Final Notice to TSB Bank plc and PRA Final Notice, both 20 December 2022; TSB 2018 full-year results, 1 February 2019.
- FCA, Cyber and Technology Resilience: Themes from cross-sector survey 2017/2018, November 2018 (¶¶2.6, 2.7, 3.21).
- FCA Final Notice to Royal Bank of Scotland plc, National Westminster Bank plc and Ulster Bank Ltd, 19 November 2014.
- SEC Rule 204-2 (17 CFR 275.204-2); FINRA Rules 4511 and 11870.