Risk-based testing for central banks is a way to direct test effort towards failures that could cause the greatest harm to monetary operations, payment and settlement services, financial stability, or public confidence. Teams assess service criticality, change scope, threats and existing controls, then select test depth and release evidence accordingly. The assessment should be documented, reviewed by accountable owners and updated when systems or dependencies change.

How risk-based testing for central banks works

Start by defining the service and the decisions testing must support. A central bank may operate a real-time gross settlement (RTGS) system, manage monetary operations, issue currency or provide financial data services. The consequences of failure differ across these functions, so a single priority score for every application can hide important distinctions.

Map each service to its users, business processes, data, technical components and external dependencies. Include settlement participants, messaging networks, identity services, network links, data feeds and recovery facilities where they affect the service. Record the impact of plausible failures, such as delayed settlement, incorrect balances, unauthorised access, data corruption or loss of service during a critical operating period.

Assess risk using evidence such as service impact, likelihood of failure, exposure to threats, size of the change and strength of preventive or recovery controls. A scoring model can help teams compare work, but its output is a prioritisation aid, not proof that a service is safe. Record assumptions and rationale, and involve service and risk owners when a rating or test exclusion could affect a high-impact function.

Turn the assessment into a test plan. High-risk changes may need end-to-end tests, negative and boundary cases, performance and resilience tests, security testing, recovery exercises and checks of operational procedures. Lower-risk changes may need focused regression tests and verification of affected interfaces. In either case, retain traceability from risks and requirements to test results, defects and release decisions.

A practical payment-system example

Suppose a release changes queue handling in an RTGS service. The assessment identifies risks of duplicate settlement, incorrect queue release after recovery and delayed processing when a participant connection is unavailable. The test plan can then include:

  • Submitting a payment and confirming that it settles once, with the expected debit and credit entries.
  • Replaying a message after a timeout and checking that the system does not settle it twice.
  • Restarting a component with queued payments and verifying that queue state, ordering rules and audit records remain correct.
  • Simulating a participant link failure and recovery, then checking processing, alerts and reconciliation against the source records.

The release evidence should show which scenarios passed, which defects remain open, what recovery behaviour was observed and who accepted any residual risk. A test that confirms the application restarts successfully does not establish that settlement records reconcile or that operational staff can restore service safely.

Controls for prioritisation and release

Set entry conditions before testing begins. The team needs an agreed change scope, usable requirements, representative test data, an environment that reflects relevant production dependencies and access to service owners who can confirm expected outcomes. Where production data cannot be used, data controls should preserve the properties needed for testing without exposing sensitive information.

Agree release gates in advance. These may include passing tests for critical risks, resolved defects above an agreed severity, successful recovery evidence and approval from the relevant service owner. Record tests that could not run, the reason, compensating controls and the person who accepted the remaining exposure. This makes the release decision reviewable by operations, audit and oversight teams.

Common weaknesses include treating every component in a critical service as equally risky, relying on a score without explaining its basis, and testing only the changed module while missing dependencies. Environment drift can also invalidate results if a test environment differs from production in configuration, capacity or connected services. Reassess risk after material changes, incidents, new threats or failed controls, and update regression coverage when the assessment changes.

Risk-based testing complements wider banking software testing. For payment flows, teams can also use banking payment processing testing to define relevant transaction and settlement checks. The approach is most useful when it connects public and operational impact to concrete tests, clear release criteria and retained evidence.

Frequently asked questions

Are all central bank systems high risk?

No. Risk depends on a system's function, data, users, dependencies and failure impact. A supporting application may warrant less test depth than a settlement service, although a dependency that can disrupt that service may still require close testing.

How often should a central bank reassess testing risk?

Reassess risk when a material system change, incident, threat, dependency or control failure could alter the service's exposure. Teams should also review assessments at the points required by their governance process, even when no major change has occurred.

Who should accept residual risk before a release?

The person authorised under the organisation's governance to own the affected service or risk should accept residual risk. Test teams provide evidence and explain gaps, while the release decision remains with the accountable owner.

Can risk-based testing replace regulatory or internal control requirements?

No. It helps prioritise testing within applicable obligations and internal controls. Teams should map required controls to tests and evidence, and escalate any conflict between a proposed test reduction and a formal requirement.