How to test a wealth management platform

Wealth management platform testing checks that a platform manages client, account and portfolio data accurately across investment workflows, connected systems and user roles. It covers functions such as valuations, orders, fees, reporting and client servicing, with testing depth shaped by which activities the platform performs and which it delegates to other services.

Plan wealth management platform testing around risk

Map the client and investment journeys first. A typical flow may start with client onboarding and account setup, continue through cash funding and order placement, then update holdings, valuations and client reports. Identify which system owns each data item and which platform or service performs each step. A wealth platform may route orders to an execution service and obtain positions from a custodian, for example.

Use the map to set scope and priorities. Errors in trade capture, asset ownership, valuation or permissions can have different impacts from a layout defect. Link requirements and controls to test cases, expected results and evidence. Include operational users, such as advisers and administrators, alongside client-facing roles where relevant.

Prepare controlled test data for different account types, currencies, investment mandates and portfolio states. Cover empty accounts, cash-only accounts, holdings with different prices, restricted assets and accounts with pending transactions. Use synthetic or appropriately protected data in non-production environments. Keep test data internally consistent across client, account, portfolio and transaction records.

Test calculations and workflow behaviour

Check calculations against independently worked expected results. Test valuation inputs, currency conversion, fee schedules, tax handling where in scope, rounding and effective dates. Include boundary values and rule combinations, such as a fee tier changing at a defined portfolio value. Verify the displayed result and any persisted values used in statements or downstream processing.

Exercise state changes as well as successful paths. For an order, test submission, validation, rejection, partial execution, cancellation and amendment where supported. Check that each state is visible to the correct users and that retries or repeated messages do not create duplicate trades. Test permissions for viewing client records, changing mandates and approving restricted actions.

Verify integrations and data integrity

Integration testing should cover the contracts and failure behaviour between the platform and connected services. These may include custody, order management, market data, client relationship management, identity services and document or reporting systems. Check valid and invalid messages, missing fields, timeouts, delayed responses and out-of-order updates. Verify that errors can be identified and safely recovered without silently losing or duplicating business events.

Compare records across systems at defined points in the workflow. Reconcile client and account identifiers, instrument identifiers, quantities, cash balances, currencies, transaction status and timestamps. Take timing into account: a valuation may use a market price from a different time from a custodian position update. The expected result should specify the applicable source, timestamp and any permitted processing delay.

Security testing should check authentication, role-based access, client and account separation, session handling and audit records. Attempt access through both the user interface and available application programming interfaces (APIs), since a restricted screen does not prove that the underlying service enforces the same permission. Confirm that sensitive data is masked in logs and that actions such as mandate changes leave an attributable record.

Worked example: test a buy order

Assume an account has £1,000 cash and holds 10 units of a fund priced at £100 each. Submit a valid buy order for four units at £100, with a £5 fee and no market movement. Verify the accepted order and execution details, the increase in holdings to 14 units, the £400 investment amount, the £5 fee and the resulting £595 cash balance. Net account value should be £1,995: £1,400 in fund units plus £595 cash.

Then check the same event in the platform's transaction history, accounting records and any connected custody feed. Submit a duplicate execution notification and confirm it does not change the position or cash a second time. Repeat with a rejected order or an interrupted integration to verify the expected status and recovery behaviour.

Check release readiness

Run focused regression tests after changes to calculation rules, interfaces, permissions or data mappings. In a continuous integration (CI) pipeline, automate deterministic checks such as API assertions, schema validation and reconciliation rules. Keep tests that depend on live market feeds or external services controlled through stable snapshots, simulators or agreed test endpoints.

Review failures by separating product defects from environment drift, stale test data and unavailable dependencies. Before release, confirm that critical journeys pass, unresolved defects have an assessed impact, and test evidence links results to requirements or controls. For broader context, see [Integration testing in banking] and [Banking test data management].