How to test duplicate action prevention in banking AI agents

Banking AI agent duplicate action prevention testing checks that an agent’s repeated or retried instruction cannot create unintended extra banking effects, such as a second transfer or payment. It verifies the agent, its tools and downstream services across uncertain outcomes, including timeouts and concurrent requests, against the transaction and idempotency rules defined for the workflow.

What to test in banking AI agent duplicate action prevention

An agent can call a payment tool, lose the response, then retry because it cannot tell whether the first request reached the payment service. It may also repeat a tool call during recovery or submit the same action after a user restates an instruction. The risk is a second financial effect even when the first action succeeded.

Test the full path from the agent’s decision to the authoritative transaction record. Depending on the design, that path can include the agent orchestrator, tool adapter, payment API, core banking system and ledger. A chat response saying a payment was submitted does not prove that only one payment was created. Check transaction records, relevant downstream messages and account or ledger effects.

Define expected behaviour from the system’s contract. If the payment API supports idempotency keys, verify how it handles a repeated key with the same request, a repeated key with changed data and a new key for a new instruction. If duplicate detection uses transaction attributes or another mechanism, test its documented matching rules and limits. Do not assume that two similar transfers are duplicates: a customer may legitimately send the same amount to the same beneficiary twice.

Set up controlled tests

Use a non-production environment with isolated test accounts, known opening balances and a payment route that does not send real funds. Record the agent’s tool calls and correlate them with payment identifiers, API responses, audit events and ledger entries. Where downstream services are simulated, make their response timing and failure behaviour controllable.

Before each test, confirm that the test data is in the expected state and that no earlier run has left a pending payment or reused identifier. Keep the agent prompt, model configuration, tool schema and relevant service versions fixed for repeatability. Since agent decisions can vary, assert the financial outcome and policy behaviour, not only an exact sequence of internal reasoning.

Exercise retries, replays and separate instructions

Include tests for these cases:

• Response lost after acceptance: The payment service accepts the request, but the response times out. The agent retries. Confirm that the outcome matches the API contract and that the account and ledger show no unintended second debit or credit.
• Repeated tool call: The agent submits the same instruction twice, either with the same idempotency key or through the system’s specified duplicate-detection path. Check the returned status and persisted effects.
• Concurrent requests: Submit equivalent requests close together. Confirm that any duplicate control remains effective when requests overlap, rather than relying only on a sequential check.
• Changed instruction: Reuse a key with a changed amount or beneficiary if the contract allows that test. Verify the specified rejection or handling, and confirm that no ambiguous payment is created.
• Legitimate repeat: Submit two separately authorised transfers with matching details but distinct instruction identities. Confirm that duplicate controls do not suppress a valid second payment.
• Failure before acceptance: Make the service fail before it accepts the action, then retry according to the workflow. Verify that the retry can complete without leaving a misleading success state.

Worked example: retry after a timeout

Suppose an authorised agent instruction requests a transfer of £25 to a test beneficiary. The payment service records the payment, but the response is delayed until the agent times out. The agent retries the request using the workflow’s expected duplicate-control mechanism.

Check the request and correlation identifiers, the payment service’s response to the retry, and the resulting transaction records. Reconcile the source and destination test accounts and inspect ledger postings. The expected result is the one defined by the service contract: for example, the original payment may be returned as the result of a replay. In every case, there must be no unintended second financial effect, and the agent’s final status must accurately describe the payment outcome.

Verify controls and failure handling

A passing test needs evidence from the system of record, not just the agent transcript. Check that the action is authorised, any required approval gate was respected, duplicate requests are traceable, and the agent does not report success when the payment status remains unknown. For asynchronous workflows, continue checking until the payment reaches the relevant terminal or review state.

Test the duplicate-control store or service through its actual lifecycle. Its retention period, scope and behaviour after recovery or failover affect whether a delayed replay can create another action. Confirm these expectations with the system design. Also test how the workflow handles an unresolved result: it may need to query payment status or escalate for review before attempting another transaction. This is related to Payment idempotency testing and Banking AI agent retry safety testing, with agent-specific checks for tool selection and status reporting.