AI test automation for central banks

AI test automation for central banks uses artificial intelligence to help design, maintain, prioritise or analyse software tests for central bank systems. It can support testing of real-time gross settlement (RTGS) services, participant interfaces, monetary operations and supervisory platforms. Testers remain responsible for validating generated tests, expected results and release evidence against approved requirements and controls.

Where AI can support central bank testing

AI can help convert requirements, interface specifications and defect histories into draft test scenarios. For an RTGS service, it might suggest cases for settlement queue priorities, payment rejection rules, participant permissions, operating-hour boundaries and recovery after a service interruption. Testers should check each scenario against the system specification and applicable operating procedures before adding it to a controlled test suite.

AI can also help identify tests affected by a requirements change, group recurring failures, or flag likely selector changes in a user interface. These uses can reduce manual analysis, although the output depends on the quality and currency of the supplied requirements, test results and system metadata.

Central banks may use AI in test automation in two distinct ways. AI can assist testing of conventional software, such as generating RTGS test cases. Separately, AI-based software used by the bank, such as a document classifier, requires its own evaluation for accuracy, bias, security and failure handling. The two activities need different test objectives and acceptance criteria.

How to introduce it safely

Start with a bounded use case that has clear expected outcomes and limited operational risk. Test scenario drafting or failure classification can be suitable starting points when a reviewer can verify every suggestion. Keep transaction execution, settlement decisions and release approval within existing authorised workflows.

Define the evidence required for every AI-assisted change. Record the source requirement, prompt or configuration version, generated test, reviewer decision, execution result and any amendment. Restrict access to the AI service and its inputs. Do not send confidential operational information or identifiable participant data to an external service unless the bank has approved that use and its data handling.

Use synthetic or properly controlled test data. Preserve referential integrity across participant records, accounts, payment instructions and ledger entries so that end-to-end assertions remain meaningful. Document how test data was created and which rules it represents. See [Banking test data management] for related practices.

Keep generated tests in version control and run them through the normal review and deployment process. A test should have explicit preconditions, actions and assertions. For an RTGS payment, assertions might check that an accepted instruction changes the intended participant positions, produces the expected settlement status and leaves the general ledger balanced. Include negative cases such as an unauthorised participant, an invalid message and insufficient available liquidity.

Example: testing a settlement queue change

Suppose a change adjusts how queued payments are released when liquidity becomes available. Give the AI the approved rule and a sanitised interface specification, then ask it to draft scenarios for eligible and ineligible payments, priority ordering and a participant with insufficient funds. A tester checks that the scenarios represent the rule and adds expected results from an approved source.

Run the reviewed tests in a controlled environment with a fixed dataset. Verify payment status, queue order, participant balances and accounting entries through supported interfaces or trusted test data queries. Compare results with the approved expected outcomes, and retain execution logs and reconciliation evidence. If generated tests disagree with the specification, correct or reject them; do not treat plausible wording as evidence of correct behaviour.

Controls and verification

AI-generated tests can omit exceptional cases, infer rules that were never approved, or become unreliable when prompts, models, selectors or source documents change. User-interface automation can also fail after layout changes. Track these failures separately from product defects, then inspect the application state and test evidence before assigning a cause.

Measure the quality of AI assistance through review outcomes: whether scenarios map to requirements, whether expected results are supported, and whether tests execute repeatably in the controlled environment. Check traceability from requirements to tests and results, and confirm that a human reviewer approved changes to the suite. For RTGS coverage, [Central bank RTGS application testing] provides a related testing focus. Governance considerations are covered in [AI test automation governance in banking].

AI test automation can support central bank testing when it operates within existing security, change-control and evidence processes. It does not establish regulatory compliance by itself. The bank must map its obligations to testable controls, retain evidence, and have authorised staff make release decisions.