How to test a central bank RTGS application

Central bank RTGS application testing verifies that a real-time gross settlement (RTGS) system processes high-value payments individually, updates settlement accounts correctly and follows the central bank's operating, security and recovery rules. It covers payment processing from participant submission through settlement or rejection, including liquidity constraints, queues, interfaces and operational controls. The system's rules and the jurisdiction's legal framework determine when settlement is final.

Define scope and settlement rules

Start with the system specification, operating rules, message profiles and participant procedures. Record the expected behaviour for payment validation, settlement accounts, participant access, transaction priorities, queue handling, operating hours and end-of-day processing. Identify which rules are configurable and which depend on the applicable settlement model. A queue may, for example, hold a valid payment until funds become available, while a malformed payment may be rejected immediately.

Map each requirement to test conditions and observable evidence. Include participant gateways, the central bank's account or ledger service, monitoring and reporting interfaces, and any connected payment or messaging services. Confirm whether the implementation uses ISO 20022 messages and which version, market practice or local profile applies. Schema validation alone cannot establish that the system enforces the intended business rules.

Use controlled environments with isolated test participants and synthetic balances. Keep environment configuration, business calendars and message profiles aligned with the target release. Differences in configuration or reference data can produce false failures or conceal defects. Do not submit test payments to live settlement accounts.

Test payment processing and liquidity

Exercise valid payments, invalid fields, insufficient funds, closed or restricted participants, duplicate submissions, cancellations and status enquiries. Check both the response to the participant and the resulting account entries. Verify that rejected or queued payments do not create unintended postings, and that a settled payment produces the expected debit and credit exactly once.

Test liquidity and queue behaviour against the documented rules. Cover payment priority, queue ordering, release after incoming funds and any supported gridlock-management process. Check that a payment is not released when its conditions remain unmet. If the system supports bilateral or multilateral offsetting, validate the calculation and resulting settlement against an independent expected result.

For messages and interfaces, test valid and invalid payloads, correlation identifiers, status mapping, timeouts and retries. Simulate a lost acknowledgement after submission: a participant retry must not cause a second settlement. Verify that operators can trace the original instruction and its current state across connected components.

Verify integration, performance and controls

Integration testing should cover participant connectivity, message translation, account updates, operational dashboards, statements and reconciliation outputs. Compare the system's transaction records with an independent ledger or test oracle. Check totals by participant and settlement date, and investigate differences in amounts, identifiers, status or value date.

Performance testing should use realistic message sizes, participant concurrency and traffic patterns agreed for the test environment. Measure processing time, queue growth, rejection rates and recovery after a traffic burst. Confirm that the system meets its specified service and capacity targets without losing, duplicating or misordering payments. A fast response is insufficient evidence if the resulting settlement records are wrong.

Security testing should cover participant authentication, authorisation, privileged operator actions, separation of duties, message integrity and audit logging. Test unauthorised access and attempted changes to payment data. Confirm that logs preserve enough information for investigation while following the system's data-handling rules.

Exercise component failure, communication interruption, restart and recovery. Verify that in-flight payments retain a consistent state, that recovered services reconcile with the ledger, and that operators can identify any work requiring manual action. Recovery objectives and procedures should come from the system's approved requirements.

Worked example: payment with a retry

Assume a test participant has a settlement balance of 100 units and submits a valid payment of 70 units to another participant with a balance of 20 units. The test should confirm one debit of 70, one credit of 70, and resulting balances of 30 and 90. Simulate a timeout after the system commits the payment but before the sender receives its acknowledgement. Resubmit the same instruction using the agreed duplicate-detection key. The expected result is a status response for the original payment, with no additional debit or credit.

Keep evidence for each test linked to its requirement: submitted message, response, account entries, audit record and reconciliation result. This helps distinguish application defects from participant connectivity, configuration or test-data problems.