AI risk-based test selection in banking uses machine learning or other artificial intelligence (AI) methods to rank or recommend tests according to the risks associated with a change. It helps a team focus execution on tests linked to affected banking functions, data and controls, while leaving risk ownership and release decisions with accountable people.
How AI supports risk-based test selection in banking
A selection system can combine change information with test and defect history. Inputs may include changed services or configuration, requirement-to-test links, affected interfaces, recent failures, test execution results and known business impact. A model can identify patterns in these inputs and estimate which tests are most relevant to a change. Rules can also enforce mandatory tests for designated critical workflows.
The output should be a ranked, explainable recommendation. For example, it might identify tests for payment authorisation, posting, reconciliation and customer notification after a change to a payment service. Test owners can inspect the evidence behind each recommendation, add missing scenarios and approve the execution set.
AI supports risk assessment; it does not determine business impact by itself. Teams need agreed risk criteria, such as the consequence of failure, the likelihood of a defect and the reach of the affected change. A model trained on past failures may reflect what was easy to detect or frequently tested, rather than the bank's current risk priorities.
A practical selection workflow
Start with a maintained inventory of tests, components, requirements and critical banking workflows. Traceability matters: if a test has no reliable link to the function or control it covers, a model cannot confidently select it from change data. Review the quality and permitted use of historical results, including whether test failures represent product defects, environment problems or flaky automation.
For each release or change, provide the system with a consistent change description. This could include changed requirements, code or configuration, dependency updates and affected interfaces. The system can map those inputs to components and risks, then rank candidate tests using risk rules and learned relationships. Preserve mandatory checks, such as tests required for a critical workflow, outside any optimisation that could omit them.
Have a tester review the proposed suite before execution. Record why tests were selected or excluded, the model or rule-set version, the input change set and any human overrides. After execution, compare outcomes with the recommendation and investigate failures that appeared in tests ranked low or omitted. Feed verified results into later reviews; avoid treating every failed run as a product defect.
Worked example: a payment routing change
Suppose a release changes routing and timeout handling for domestic transfers. The change record identifies the payment service and its connection to the ledger and an external payment network. The selection process should surface tests that cover successful routing, timeout and retry behaviour, duplicate prevention, posting, reconciliation and customer-visible status. It should also include relevant negative cases, such as a rejected payment or an unavailable network.
A tester checks the links and confirms the mandatory payment controls are present. The suite runs in a representative environment with valid test accounts and network responses. If an omitted reconciliation test later finds a defect, the team investigates whether the change mapping, test metadata or model recommendation failed, then updates the selection process. This makes the recommendation auditable and gives the team a concrete basis for revising it.
How to verify the approach
Check that selected tests map to identified risks and that critical workflows retain agreed coverage. Review recommendations against decisions made by experienced testers, including tests that were selected, excluded or added manually. Track missed defects and false recommendations by cause, and separate product failures from test, data and environment issues.
Run the selection process in observation mode before allowing it to reduce a release suite. Compare its recommendations with the existing approach across different change types. Reassess performance when systems, test inventories or banking rules change. Environment drift and stale traceability can make previously useful relationships unreliable, so teams need ongoing data and model governance.
Risk-based test selection chooses which tests to execute for a change. Test prioritisation orders tests within an execution plan, for example to run high-risk checks earlier. A banking team may use both, while retaining a full regression suite for releases where broader coverage is required.
Frequently asked questions
Can a bank use AI for test selection without a large history of defects?
Yes. A bank can begin with expert-defined risk rules, test-to-requirement links and change-impact data, then evaluate whether machine learning adds value as reliable execution history accumulates. The initial recommendations should remain subject to review.
How should teams handle an AI test recommendation that cannot be explained?
Treat an unexplained recommendation as untrusted until the team can identify its supporting change, risk or test evidence. Keep selection decisions reviewable, record overrides and exclude opaque recommendations from release-critical decisions.
Should AI-selected tests replace a bank's full regression suite?
Only where the bank has approved that operating model and has evidence that selected tests cover the risks relevant to the change. Teams can retain full regression runs for defined release types or use them periodically to detect gaps in the selection process.