How to detect conflicts in AI banking requirements

AI banking requirements conflict detection uses artificial intelligence to identify requirements that may contradict one another, then presents the relevant text for review. It helps QA and product teams find conflicts across banking workflows, channels and system specifications. A person must confirm each finding, because the model may miss context or infer a contradiction where the requirements describe different cases.

What counts as a requirements conflict?

A conflict exists when two applicable requirements prescribe incompatible outcomes for the same condition. For example, one may say that a payment is released immediately, while another says that the same payment must wait for approval. The requirements may be in separate documents or use different terms for the same action.

Conflicts differ from ambiguity and omission. An ambiguous requirement allows more than one interpretation. An omission leaves a behaviour unspecified. AI analysis can flag both for review, but a conflict finding should identify the incompatible statements and the conditions under which they overlap.

Banking requirements often qualify behaviour by payment type, customer segment, channel, currency, time or approval role. A rule that applies to a mobile transfer may not conflict with one for a branch payment. Detection therefore depends on preserving scope and conditions, rather than comparing sentences in isolation.

How to detect conflicts

1. Prepare a controlled requirements set. Include approved requirements, acceptance criteria and relevant process or interface specifications. Retain each item’s identifier, source, version, status and scope. Exclude superseded text or label it clearly. Confirm that the analysis environment is approved for the material, especially if documents contain confidential information.
2. Ask the AI to find candidates with evidence. The analysis should compare requirements semantically, extract conditions and expected outcomes, and return the requirement identifiers with exact supporting passages. Ask it to classify the finding, describe the shared conditions, explain the incompatibility and state any assumptions. A result without traceable source text is difficult to verify.
3. Check candidates against business rules and system boundaries. Use deterministic checks where they fit, such as comparing limits, dates, status transitions or role permissions. AI can help connect differently worded rules; a rules check can validate explicit values. Review conflicts across relevant systems too, such as an online banking instruction and a core banking posting rule.
4. Have the accountable owner resolve each finding. Record whether it is a confirmed conflict, a valid exception, a duplicate or a false positive. For a confirmed conflict, agree which requirement changes and update its version and trace links. Do not let an AI-generated interpretation silently become the approved rule.
5. Turn the agreed behaviour into tests. Link the clarified requirement to acceptance criteria and test cases. Include the conditions that distinguish the conflicting rules, then check the expected result in the relevant service or cross-application workflow.

Worked example: payment cut-off rules

Suppose a specification contains these statements:

• R-104: “Eligible domestic transfers submitted through digital banking are processed immediately, 24 hours a day.”
• R-219: “Digital transfers submitted after 18:00 are queued until the next banking day.”

An AI finding should cite both identifiers and explain that the rules appear to apply to the same transfer type and channel, while specifying incompatible processing times after 18:00. The finding should also state that eligibility, time zone, banking-day calendar and any exceptions need confirmation. Those details may show that the rules have distinct scopes, or that the conflict is genuine.

After the product owner clarifies the rule, testers can check eligible transfers submitted before and after the cut-off, including a non-banking day if that condition is in scope. Verify the payment status and processing time in the digital channel and downstream payment service. The expected results must come from the approved clarification, not from the AI’s suggested interpretation.

How to verify detection quality

Build a review set from requirements with known conflicts, valid exceptions and similar wording that does not create a conflict. Check whether the analysis finds the known cases, whether its evidence supports each finding, and whether reviewers can explain false positives and missed conflicts. Repeat the checks when changing the model, prompt, source documents or processing rules.

Keep the model and prompt version, input document versions, findings and human dispositions with the requirements review record. In a continuous integration pipeline, AI findings can be raised as review items. Make them an automatic release blocker only when the team has defined and validated that control; otherwise, route them to an accountable reviewer.