What is negative testing in banking?

Negative testing in banking is the practice of checking how a banking system behaves when it receives invalid, incomplete, unauthorised or otherwise disallowed requests. A negative test should confirm that the system applies the relevant rule, returns an appropriate outcome and preserves the required account, transaction and audit state.

What negative testing in banking checks

Banking workflows enforce rules about customer eligibility, account status, payment limits, transaction formats and user permissions. Negative tests exercise cases that breach those rules. Examples include submitting a transfer with an invalid currency, attempting to debit a blocked account, exceeding a payment approval limit or calling an API operation without the required permission.

The expected result depends on the rule. A payment may be rejected before processing, held for review or returned with a specific status. The test should verify the defined outcome, including any permitted side effects. A rejected request may still generate an audit record or security alert, while the ledger must follow the expected posting rules.

Negative testing overlaps with security testing and validation testing. It can check that an unauthorised user cannot approve a payment, for example, while security testing also examines wider threats such as privilege escalation and data exposure. Validation tests often focus on individual fields; negative banking tests can cover the resulting behaviour across a complete transaction workflow.

How to design a negative test

Start with a requirement, business rule or control that defines what the system must reject or restrict. Identify the condition that triggers it, the expected response and the state that must remain unchanged. Check dependencies such as account status, customer permissions, transaction limits, processing windows and downstream service availability. Without controlled preconditions, a rejection may result from the wrong rule and give misleading evidence.

For transaction validation, inspect more than the message shown to a user. Verify the API or channel response, transaction status, ledger entries, available balance and any message sent to a payment processor. For authorization testing, verify that the protected action did not occur and that access controls were applied to the correct user and resource.

Test data and environment state matter. Use accounts with known balances and configured limits, and reset them between runs where transactions can change state. Environment drift, stale permissions or different reference data can cause a valid request to fail or an invalid request to pass. Use test doubles or controlled integrations where a downstream service would otherwise make the outcome unpredictable.

Practical example: transfer above the permitted balance

Assume a customer has an account with an available balance of £200, no overdraft facility and permission to make a transfer of up to £500. The test submits a transfer for £250 to a valid beneficiary. The amount is within the payment limit but exceeds the available balance.

The expected result is a rejection for insufficient funds. The test checks that the transfer is not submitted for settlement and that no debit or credit posting is created. It also verifies that the available balance remains £200 and that the transaction receives the expected rejected status. If the specification requires an audit event, the test confirms that event separately.

This scenario depends on the account having no overdraft and the beneficiary being valid. If either condition differs, another rule may determine the outcome. A useful failure report identifies which assertion failed, such as an unexpected ledger debit, instead of reporting only that the transfer screen displayed an error.

Interpreting failures and coverage

A negative test fails when the system accepts a prohibited request, rejects a permitted request under the same conditions, or produces an incorrect state change or response. It can also fail when error handling exposes sensitive information or leaves a transaction in an ambiguous status.

Coverage should follow the applicable rules and risks. Include invalid values, boundary conditions, conflicting rules and unauthorised actions where they apply. Check retries and repeated submissions if they could create duplicate effects. A rejected transaction should leave the system in a defined state that downstream services and support teams can interpret.