How to test custodian bank settlement instruction changes

Custodian bank settlement instruction change testing verifies that an authorised change to standing settlement instructions (SSIs) is captured, approved, distributed and used correctly for eligible securities settlements. It checks field validation, effective dates, downstream mappings and transaction outcomes across connected systems, while preserving the applicable instruction history. Use controlled test data and non-production routes so tests cannot initiate live settlement.

Define the change and its impact

Start with the change request and identify which instruction fields, markets, currencies, accounts and client or legal entities it affects. Depending on the custodian’s setup, fields may include the safekeeping account, place of settlement, Bank Identifier Code (BIC), cash correspondent or account number. Confirm the source of each value and any market-specific validation rules with the relevant business and operations owners.

Map the affected systems and decision points. These may include the custody platform, reference-data service, trade processing, matching, settlement messaging and client reporting. Establish how the new instruction is selected: for example, by market, currency, security type, client account and effective date. Test the configured rules rather than assuming that every platform uses the same selection logic.

Set out what should happen to trades already booked, matched or instructed when the change takes effect. The expected treatment may depend on the institution’s policy and the trade’s state. Make the rule explicit in acceptance criteria, including whether an existing settlement instruction is retained, amended or sent for repair.

Build controlled test data

Prepare records that distinguish the old and new instructions clearly. Include eligible trades before and after the effective date, trades for an unaffected market or account, and records that test selection boundaries. Keep related trade, client, account and reference data consistent across systems; inconsistent test data can create misleading routing failures.

Use a non-production environment with test endpoints or simulated external responses. Check that refreshed reference data, cached values and interface mappings match the intended release. Environment drift can make a correct change appear to fail, or allow a stale instruction to pass unnoticed.

Test the change lifecycle

Cover the full change path, from entry to settlement outcome:

• Verify that required fields accept valid values and reject missing, malformed or incompatible values. Check field lengths and allowed formats where they are defined.
• Confirm that only users with the required permissions can submit or approve the change. Where maker-checker controls apply, test that the same user cannot perform both actions.
• Check approval status, effective date, version or history record, and the audit details required by the organisation.
• Verify that approved data reaches each dependent system and that rejected, delayed or duplicate messages are handled visibly and safely.
• Confirm that trade selection uses the correct instruction for the relevant account, market, currency and date. Check that unrelated trades retain their existing routing.
• Test operational exceptions, such as an instruction that is missing, inactive or inconsistent with a trade. Confirm the expected hold, rejection or repair path and that the issue can be identified by operations.

Assertions should inspect both the stored instruction and the generated downstream result. For example, compare the approved reference-data record with the settlement message or instruction presented to a test matching service. A successful screen save alone does not prove that downstream processing uses the changed value.

Worked example

A client’s settlement account for a specified market is changing from account OLD-456 to NEW-789, effective on a stated business date. Create test trades for that client and market on the day before and the effective date, plus a same-date trade for a different market.

Expected results should state which account each trade uses under the approved effective-date rule. Verify the approved instruction record, the selected instruction in trade processing and the account in the outbound test message. Confirm that the other market is unchanged. Then submit the change with an invalid account value and with no required approval; each attempt should follow its defined validation or authorisation failure path without changing the active instruction.

Assess failures and release evidence

Investigate failures by tracing the instruction from its source record through approval, distribution, selection and settlement output. This helps distinguish a data defect from a mapping error, stale cache, interface failure or incorrect effective-date rule. Retest the failed path after correction, then run focused regression tests for affected markets, accounts and downstream interfaces.

Retain the change request, test data identifiers, expected and actual results, relevant message or event evidence, defects and approvals. Protect account data in test environments and follow the organisation’s access and retention controls. Link requirements to test cases and results as part of Banking requirements traceability and Banking test data management.