How to classify test failures in AI banking systems

AI banking test failure classification is the process of assigning a failed test to the most likely failure category, such as banking logic, AI behaviour, data, integration, automation or environment. It helps teams decide what to investigate, who should own the issue and how urgently to act. A category records the observed failure; it does not, by itself, prove the root cause.

AI banking test failure classification categories

Use a small, agreed taxonomy so teams can compare results across test suites and releases. Keep the failure category separate from severity, business impact and confidence in the diagnosis.

• Banking rule or application defect: The system violates a specified rule or workflow. For example, a payment is released without the required approval.
• AI behaviour or quality failure: The model or AI component produces an output that breaches a defined acceptance criterion. Examples include an incorrect document field extraction or an unsupported answer from a banking assistant.
• Data or feature failure: Inputs are missing, stale, incorrectly mapped or outside the test's intended profile. A model may receive an outdated account status because a test fixture was not refreshed.
• Integration or orchestration failure: A service call, message, tool action or downstream update fails, even if the AI output itself meets its criteria.
• Test automation or assertion failure: The test uses a brittle selector, incorrect expected value, unsuitable tolerance or flawed result parsing.
• Environment or dependency failure: A service is unavailable, configuration has drifted, or a dependency behaves differently from the controlled test setup.

Treat security, privacy, conduct and regulatory exposure as impact or risk tags that can apply to any category. For example, a data-masking defect could be an application failure with a high privacy impact.

A practical classification workflow

1. Confirm the failure is reproducible. Check the test run, assertion and execution logs. Rerun only where safe and useful. For transaction tests, use isolated accounts or resettable data so a rerun cannot create a duplicate payment or alter shared balances.
2. Compare expected and actual behaviour. Use the approved requirement, model evaluation criterion or interface contract. For probabilistic components, assert the agreed outcome, range or quality threshold rather than assuming every valid run returns identical wording or a fixed score.
3. Trace the result through the workflow. Check whether the input reached the AI component correctly, whether its output met the contract, and whether the banking application applied the appropriate decision and controls.
4. Assign a category and confidence. Record the best-supported category, evidence and unresolved questions. Mark a result as unclassified or low-confidence when evidence is insufficient; avoid labelling every unexpected AI output as a model defect.
5. Assess impact separately. Consider the affected customer journey, transaction state, control and possible financial or data consequence. Escalate failures involving unauthorised actions, incorrect balances, disclosure of sensitive information or bypassed approval controls through the relevant incident process.

Capture enough information to reproduce the result: test and build identifiers, model or prompt version, configuration, relevant input data, output, assertion details, timestamps and correlation identifiers. Where applicable, record random seeds or sampling settings. Mask or minimise customer information in logs, and follow the bank's access and retention controls for test evidence.

Worked example: a payment-risk model

A test submits a transfer that should be held for review under the agreed risk policy. The model returns a low-risk score, and the payment proceeds. Classify the observed failure as AI behaviour or quality only after confirming that the test sent the intended features and used the expected model and threshold configuration.

If the test fixture supplied an old beneficiary status, classify the primary failure as data or feature. If the model score meets the documented criterion but the payment service ignores the review status, classify it as integration or orchestration. If the test read the wrong field from the response, classify it as test automation or assertion. Preserve the evidence and investigate root cause before changing the model, threshold or banking rule.

Keep classification useful over time

Review recurring categories with test, model, application and operations owners. Reclassify when new evidence changes the diagnosis, and retain the original observation for auditability. Track repeat failures by component and release, while keeping one incident or defect linked to the affected test runs where appropriate. This supports test failure analysis without confusing a noisy test with a confirmed product defect.