How to analyse requirements changes in AI banking systems

AI banking requirements change impact analysis is the process of identifying and verifying which banking functions, controls, data, interfaces and tests may be affected by a change to an AI-related requirement. Artificial intelligence (AI) changes can affect model behaviour as well as conventional software, so the analysis needs traceable evidence and review by people who understand the banking process and its risks.

Prepare the change and its evidence

Start with a controlled change request that states the current requirement, the proposed wording, the reason for the change and the intended effective date. Record the product or service, affected customer groups, jurisdiction and relevant release. Resolve ambiguity before asking a tool to assess impact: a change such as “improve fraud detection” is too vague to produce dependable test scope.

Gather the artefacts that connect requirements to implementation and assurance. These may include business rules, process models, application and data-flow diagrams, interface contracts, model documentation, risk and control records, acceptance criteria, test cases, known defects and prior change decisions. Record their versions and owners. If traceability is incomplete, identify that as an analysis limitation rather than assuming that an unlisted dependency does not exist.

For AI components, include the relevant model or service, input features, decision thresholds, prompts or retrieval sources where applicable, human review steps and fallback behaviour. The scope depends on the system: a document extraction model, a credit decision model and a customer-facing language model have different dependencies and failure modes.

Map the change through the system

Use requirements traceability, architecture information and change history to build a set of candidate impacts. An AI tool can help compare requirement versions, extract entities and rules, find related artefacts, and suggest missing links. Its output is a lead for investigation, not proof that an artefact is affected or unaffected. Restrict access to approved data, and check the tool's handling of confidential customer and model information.

Review candidate impacts across the relevant layers:

• Customer or staff workflow, including decision explanations, referrals and manual review.
• Business rules, model inputs, thresholds, outputs and fallback paths.
• Data sources, transformations, quality checks, retention and access permissions.
• APIs, downstream systems, audit events, reports and operational queues.
• Controls, approval responsibilities, monitoring and test coverage.

Assess each impact for likelihood and consequence, including the effect of an incorrect decision, delay, duplicate action or unavailable AI service. Consider affected customers, transaction amounts, reversibility, regulatory or policy obligations, and whether a human can intervene. Keep the rationale and evidence for each rating. AI-generated scores can support triage, but a reviewer should validate the assumptions and decide test priority.

Turn impacts into verification work

For each confirmed impact, update the relevant requirement links, acceptance criteria and test scope. Include positive and negative cases, boundary conditions, integration behaviour, access controls, audit evidence and recovery paths where they apply. For probabilistic outputs, define measurable evaluation criteria and approved test data; an assertion against one exact generated sentence may be unsuitable when wording can vary.

Separate checks of the conventional application from checks of model behaviour. A change to a credit decision threshold may require deterministic tests of the threshold rule, data validation and downstream decision handling, alongside evaluation of model performance on representative, approved cases. Re-run affected end-to-end workflows and regression tests for connected banking services. Select additional tests where trace links are weak or system behaviour is uncertain.

Before closing the analysis, verify that each proposed impact has a source, an owner, a disposition and a test or other control response. Review both the included and excluded items. Confirm that test environments, model versions, configuration and test data match the change under assessment. Record unresolved dependencies and assumptions as release risks.

Practical example: changing a fraud threshold

Suppose a requirement changes the score threshold that sends an instant payment to manual fraud review. Compare the old and new rule, then trace the score to the payment service, review queue, customer status message, audit event and operational dashboard. Check whether the changed threshold affects payment latency, queue capacity, customer notifications or the treatment of a retry.

Create cases immediately below, at and above the threshold, plus cases for missing scores, unavailable model service, repeated payment requests and reviewer rejection. Assert the routing decision, payment state, audit record and customer message. Evaluate the model using approved representative data, then have the fraud and testing owners review the impact list and test results. A changed threshold is verified only when the intended routing and connected workflow behaviour are demonstrated in the relevant configuration.