Risk-based testing for custodian banks

Risk-based testing for custodian banks is a way to assess and prioritise testing according to the potential harm a software failure could cause to clients, assets, settlement obligations, financial records or regulatory duties. It directs test effort towards custody services and changes with the greatest exposure, while recording what remains untested and why.

How to assess custody risk

Start with the service and its business outcomes. Map the relevant workflows, applications, interfaces, controls and operational hand-offs. Custody workflows can span settlement processing, securities position keeping, corporate actions, income collection, tax services, cash movements and client reporting. A failure may affect one account or many clients, and can have consequences after the original transaction has completed.

For each workflow or change, assess the possible impact and the chance of failure. Consider client asset or cash misstatement, missed settlement deadlines, incorrect entitlements, financial loss, inaccurate reporting, control failure and the time needed to detect and correct the issue. Also consider change exposure: new code, configuration, data mappings, market rules, interfaces or operational procedures can make a familiar process riskier.

Use a documented rating method that fits the bank's governance. A qualitative scale such as high, medium and low can work if each rating has clear criteria and reviewers apply them consistently. A numerical score can help order a large backlog, though the score is a prioritisation aid, not proof that a workflow is safe. Record assumptions, evidence and named owners so that reviewers can challenge the assessment.

Turn risk ratings into test scope

For each high-risk area, identify failure modes and controls, then define scenarios that show whether the system behaves correctly. Include expected processing and relevant exceptions. For settlement, this may mean checking that valid instructions reach the correct market, rejected instructions enter the intended repair process, and resulting positions and cash movements reconcile. Test authorisation and audit evidence where changes or manual intervention can affect client assets.

Set priorities across more than individual test cases. A scenario that crosses the custody platform, settlement network, accounting service and client reporting may expose failures that isolated component checks miss. Include negative and boundary cases where they could breach a control or produce an incorrect financial outcome. For shared services, assess the effect of a defect across clients, markets and asset classes.

Test selection also depends on reliable conditions. Confirm that test accounts, securities, calendars, market rules and reference data match the scenario. Check that the environment has the required interface versions and configuration. Environment drift or unrealistic test data can make a passing result weak evidence. Protect confidential client information and use approved data controls.

Worked example: changing a settlement instruction

Suppose a release changes how a standing settlement instruction (SSI) is amended. The risk assessment identifies the possibility of an unauthorised or incorrect instruction routing a security settlement to the wrong place, causing a failed settlement or client impact. The team rates this as high under its documented criteria because the change affects payment or securities routing and depends on controlled reference data.

The test set should verify an authorised amendment, the effective date, the market and currency mapping, and the instruction sent downstream. It should also check that an unauthorised user is rejected, invalid data is held for repair, and a repeated request does not create an unintended second change. Assertions should confirm the stored instruction, relevant audit record and downstream message. Where the workflow affects positions or cash, reconcile those outcomes against the expected processing. A test that only confirms a success message on screen would leave important risks unchecked.

Use results to support release decisions

Link risks to requirements, controls, scenarios, execution results and defects. For high-risk scenarios, retain enough evidence to identify the build, configuration, test data and outcome. Review failures for cause: a product defect, test-data problem, environment issue or external dependency needs a different response.

Before release, compare executed evidence with the agreed risk-based scope. Review open defects, failed or blocked tests, changed assumptions and areas without adequate coverage. A passing test suite does not remove risk if important scenarios were excluded or the test environment did not represent the relevant workflow. Record residual risks and obtain approval from the accountable owners under the bank's release process. Repeat the assessment when a change, incident, market rule or control dependency alters the exposure.