Custody platform testing is the assessment of software that records and supports the safekeeping, movement and servicing of assets held on behalf of clients. It checks that positions, cash, settlement instructions and asset servicing events are processed accurately across connected systems, with appropriate access controls and an auditable record of each action. The exact scope depends on the assets and services the platform supports.
What custody platform testing covers
A custody platform maintains records of client holdings and supports operational activities around those assets. A custodian may use it to process securities transfers, settlement, income events, corporate actions, fees and client reporting. The platform may exchange data with a central securities depository, broker, cash ledger, market data provider or another custodian. It records and coordinates these activities; the legal and operational arrangement determines how assets are held.
Testing checks both individual functions and the flow of information between systems. A settlement instruction, for example, should retain the correct account, instrument, quantity, settlement date and counterparty as it moves through validation, matching and settlement. A completed transaction should update the relevant position and cash records. A rejected or failed instruction should show the correct status and leave balances unchanged unless the business rules specify otherwise.
Reconciliation testing compares records from separate sources, such as the custody platform and a depository statement. Tests should confirm that matching records reconcile and that differences appear as actionable breaks. A break can result from timing, missing data, a duplicate event or an incorrect quantity, so expected outcomes should distinguish valid timing differences from errors requiring investigation.
Dependencies and failure risks
Results depend on reliable test data and representative integrations. Test accounts need known holdings, cash balances, settlement instructions and permissions. External systems may be simulated, but their message formats, response codes and timing should reflect the integration contract. Differences between test and production configuration can hide defects, so environment versions, calendars and reference data need control.
Common failure modes include duplicate processing after a retry, a position changing before settlement completes, an incomplete corporate action update, or a reconciliation that silently accepts a mismatch. Security tests should check that users can perform only permitted actions, that approval rules are enforced, and that changes and overrides are recorded. Where the platform handles digital assets, key management and transaction signing add separate security and recovery concerns to the test scope.
A practical settlement test
Consider a delivery-versus-payment (DvP) transfer, where securities and cash are exchanged as part of settlement. Set up a client account with a known quantity of a security and enough cash, then submit a valid instruction with an agreed quantity, price and settlement date.
Verify that the instruction is validated and matched, and that the platform records the expected settlement status. After settlement, compare the resulting security position and cash movement with the expected values and the external settlement record. Replay the same instruction using its original identifier: the platform should follow its duplicate-handling rule without creating a second movement. Then test a rejection, such as insufficient cash, and confirm the reason is visible and settled balances remain unchanged.
For each outcome, retain the instruction, response, status history, balance records and reconciliation result. This evidence helps distinguish a platform defect from an external-system delay or a test-data problem.
How to verify coverage
Trace custody requirements to scenarios for normal processing, rejected instructions, amendments, cancellations and recovery after interruption. Include cross-system checks for positions and cash, and verify that reconciliation breaks can be investigated and resolved with an audit trail. Review access by role and test sensitive operations such as changing settlement instructions or approving an override.
Run relevant regression tests after changes to interfaces, reference data, settlement calendars or business rules. A passing user-interface check alone does not establish that records are correct: compare persisted platform data with an independent expected result or source record.
Frequently asked questions
Who should define expected results for custody platform tests?
Expected results should be agreed by product or operations owners with input from QA and relevant integration owners. They should specify the required status, position and cash changes, exception behaviour and audit evidence for each scenario.
How should custody testing handle settlement delays?
Tests should model the agreed pending and delayed states, including timeouts and late external confirmations. They should verify that the platform preserves the instruction, avoids duplicate movements and updates the final state correctly when a valid confirmation arrives.
Does custody platform testing include client statements?
It can include statements when reporting is within the platform's scope. Tests should compare reported holdings, cash, transactions and dates with the underlying custody records, and check that corrections or reversals appear according to the reporting rules.
How is custody platform testing different from portfolio management testing?
Custody testing focuses on asset records, safekeeping operations, settlement and servicing events. Portfolio management testing focuses on investment decisions, allocations and portfolio rules, though both systems may exchange position and transaction data.
