Blog
Continuous Testing for Wealth Platforms and Migrations
Rishabh Kumar
Published on
Table of contents
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
Lorem ipsum
On a wealth platform, the cost of a bug grows with every account it touches and every day it goes unnoticed. Fees, valuations, contributions, switches and income are calculated every day. So the time between a bug going live and someone finding it drives most of what it ends up costing.
Running regression before each release isn’t enough. Continuous testing of your most important journeys means you find problems in days, not months.
Most software only does something when a user clicks a button. Wealth platforms are different. They keep calculating with customers’ money whether anyone’s looking or not.
A wrong fee basis, a wrongly mapped fund or a broken switching rule doesn’t wait for someone to notice. It runs every night in the batch, on every affected account, and the cost of fixing it keeps climbing.
Why Wealth Platforms Need Continuous Testing
Because the platform recalculates all the time. A bug in a daily process doesn’t happen once. It happens again every day, on every affected account, until someone spots it.
The exposure is roughly the number of accounts affected, times the days it goes undetected, times the value at stake per account per day. Of those three, how long it goes undetected is usually the easiest to change.
We call this the Defect Interest Rate:
The formula is simple on purpose, and every number in it comes from your own platform.
It makes one point clearly:
Part of the Formula | What Sets It |
|---|---|
Accounts affected | The bug itself |
Value at stake per account | The product |
Days undetected | How often you check |
Here’s an illustrative example. Say a fee bug affects 4,000 accounts and overcharges each by 15p a day:
How Often You Check | Days Undetected | Rough Exposure |
|---|---|---|
Every day | 1 | About £600 |
Every month | 30 | About £18,000 |
Every quarter | 90 | About £54,000 |
Those figures don’t include the cost of recalculating accounts, writing to clients and handling complaints, which often adds much more.
That’s why on a wealth platform, how often you test is a financial decision, not just an engineering one. If you run full regression before quarterly releases and nothing in between, you’ve accepted that a bug could run for a whole quarter before you find it.
And that applies whatever caused it: your own release, a platform vendor update, a change to fund data or a partner’s integration.
Where Do Wealth Platform Defects Hide?
In the daily processes and the connections between systems. That means fee calculations, valuations, income and corporate actions, contributions and switches, and the data moving between the platform, adviser tools, portals and custodians.
They also hide in migrations. Moving accounts to a new platform means a whole book of business is recalculated under new rules at once.
Where | What Can Go Wrong | Why Periodic Testing Misses It |
|---|---|---|
Fees and charges | The wrong basis, tier or frequency is applied after a product or platform change | Fee runs happen monthly or daily, and test suites usually check the screen, not the charge |
Valuations and pricing | Changes to fund mappings or price feeds value holdings wrongly | Feed changes happen outside your release cycle |
Contributions and switches | Rules for allocating, rebalancing or switching are applied wrongly | Edge cases, like part-switches or contributions mid-cycle, are rarely in the regression set |
Income and corporate actions | Distributions or events are processed with the wrong rule | Events don’t happen often, so their tests go stale |
Adviser and client portals | The values shown don’t match the platform’s own records | Portals and the platform are tested separately |
Migrations | Accounts are recalculated under new rules or mappings at go-live | Testing focuses on whether the data matches, not how the new platform behaves day to day afterwards |
The answer isn’t testing everything every day. It’s checking the business-critical journeys continuously, either daily or after any change from any source. That keeps the days undetected low for the bugs that would cost the most.
Full regression still has its place before releases. It’s just not enough on its own when the platform never stops calculating.
Illustrative Scenario: The Migration Bug Found on Day 70
This scenario is illustrative. It describes how things can go wrong, not a specific firm or platform.
A wealth manager moves its client book to a new platform. The data reconciliation passes, so balances, holdings and cash all match on cut-over day. Regression testing of the main client and adviser journeys passes too, and the migration is signed off.
But on the new platform, an older product class has been mapped to a fee schedule that uses a different charging basis. Nothing looks wrong on day one, because no fees have been taken yet. The first monthly fee run applies the new basis to every account in that product class. Then the second one does the same.
It’s day 70 before an adviser questions a client’s statement and someone spots the pattern. By then, every affected account needs recalculating and refunding, and every client needs an explanation.
With continuous checks, the fee journey for each product class runs daily from cut-over, using sample accounts at the edges of each fee schedule and checking them against the documented charging rules. The first fee run on day 30 is checked the next morning, so the bug is caught after one run, not two.
Better still, a check before cut-over of how fees are calculated for every mapped product class would have caught it before go-live.
Here’s what that check might look like as test data, with one row for each product class and fee boundary:
The honest part: continuous checks take running time and attention, and some daily checks will never find anything.
The point isn’t to check everything all the time. It’s to check the processes where every extra day costs money, on the same schedule those processes run.
Where Does Virtuoso QA Touchstone Fit?
Touchstone makes it practical to check a wealth platform’s critical journeys continuously, against the documented rules, with a record of every check. AI works out what needs checking, a deterministic engine runs the checks, a named person approves what matters, and each step is recorded.
Available Today
Capability | What It Means for a Wealth Platform |
|---|---|
Rules from your product documents | Touchstone reads the fee schedules, product terms, switching rules and process documents you choose, and drafts test requirements that cite where each rule came from. So every check links back to the rule it protects |
Every boundary as data | Virtuoso QA runs each journey across a data table, with a separate result for each row. One approved fee or switch journey can cover every product class, tier and edge case, like the example above |
Scheduled and repeatable | Journeys run on a schedule or on demand, with the same result every time. So daily checks become routine, not a project |
Across all your systems | Virtuoso QA tests any browser-based application, including the platform, adviser and client portals, and CRM, end to end. It also checks APIs where systems swap data without a screen |
Named, versioned approval | Nothing is built without a named person approving it, and every decision is recorded, timestamped and versioned |
To see how Virtuoso QA tests portfolio, onboarding and reporting journeys across wealth platforms, take a look at our wealth management software testing solution.
Coming Next
The plan is change-aware checking. Touchstone will recognise when a release, a fund data change or a vendor update affects a rule, and automatically recheck the journeys involved. That keeps the days undetected as close to zero as each process allows. This is on the roadmap and isn’t available today.
What It Doesn’t Do
Touchstone checks that the platform applies the documented rules. It doesn’t reconcile large migrated data sets, judge fair value or replace your operational controls. Batch processes with no browser or API access, and load or performance testing, are outside its scope.
When a regulator, auditor or client asks how a fee change was checked, Virtuoso QA’s release evidence shows the rule it came from, the result and who approved the test.
What Can You Do This Quarter?
Here are four things you can do without buying anything:
Step | What to Do |
|---|---|
1. List the daily processes that touch client money | Fees, valuations, contributions, switches, income and corporate actions. For each one, write down how often it runs and how often you check it |
2. Work out your worst-case days undetected | For each process, that’s the gap between checks. If the gap is a quarter, a bug could run for a quarter |
3. Pick one process to check continuously | Start with fees. Write down the charging rules for each product class, and check an account at each boundary every time the process runs |
4. Test how the platform behaves after migration, not just the data | For any migration in progress, check the new platform calculates correctly for every mapped product class before the first fee run, not after it |
Your platform grows clients’ money every day. Checking it just as often is how you make sure it’s growing in the right direction.
Wealth Platform Testing FAQs
How do you test a wealth management platform?
Why do defects cost more on wealth platforms?
What is the Defect Interest Rate?
How do you test a wealth platform migration?
Is continuous verification the same as running every test every day?
![](data:image/svg+xml,<svg display="block" id="540005799" role="presentation" viewBox="0 0 12 10" xmlns="http://www.w3.org/2000/svg"><path d="M 6.602 10.182 L 5.727 9.318 L 9.33 5.716 L 0 5.716 L 0 4.466 L 9.33 4.466 L 5.727 0.875 L 6.602 0 L 11.693 5.09 L 6.603 10.182 Z" fill="rgb(8, 7, 7)" height="10.182000000000016px" id="C361dJxCp" width="11.692999999999984px"/></svg>)
