How to test authorisation in banking APIs

Banking API authorisation testing checks that each authenticated customer, employee or service can access only the operations and financial resources permitted by its identity, entitlements, consent and business rules. It verifies both access to API functions and access to specific accounts or transactions, including whether a payment can proceed under the required approval rules. Authentication establishes identity; authorisation decides what that identity may do.

What banking API authorisation testing covers

A sound test model maps identities and actions to resource ownership and business conditions. Depending on the API, relevant controls include customer or corporate roles, account mandates, delegated permissions, OAuth scopes, open banking consent, transaction limits and maker-checker approval rules. A valid token alone does not establish permission for every request.

Test function-level access, such as whether a user can initiate a payment or manage a beneficiary. Test object-level access, such as whether that user can read or amend the requested account, payee or transaction. Include cross-customer and cross-tenant cases where the system serves multiple customers or organisations. For payment APIs, verify both API permission and the payment workflow's approval state.

The expected result should come from the API contract and the bank's entitlement rules. A denied request may return 403 Forbidden, or use 404 Not Found to avoid revealing whether a resource exists. Check the documented response, and verify that rejection leaves balances, payment state and downstream instructions unchanged.

A practical test method

1. Translate requirements into access rules. Record the permitted identities, operations, resource boundaries and relevant conditions. Include allowed and denied combinations. For example, an organisation's preparer may create a payment, while only an authorised approver may release it.
2. Prepare controlled test identities and data. Create separate customers or organisations, accounts, roles and consent states in a non-production environment. Give each identity the minimum permissions needed for its test. Keep tokens and financial data out of source control and test logs.
3. Exercise permitted requests. Confirm that an identity with the required entitlement can perform the operation on its own resource. Check the response and the resulting state, such as a payment entering the expected approval status.
4. Exercise denied requests. Reuse the request with a different customer's account identifier, an insufficient role, a missing scope, revoked consent or an expired entitlement. Assert the documented denial and verify that no prohibited read, update, posting or downstream action occurred.
5. Check policy changes and lifecycle states. Test access before and after role changes, consent revocation, mandate expiry and payment approval. Where tokens can outlive a permission change, verify the intended revocation or refresh behaviour.
6. Review evidence and repeat in CI. Retain request identifiers, test identity, relevant policy state, response and state checks without recording secrets. Run stable authorisation cases against controlled data in the CI pipeline, and investigate failures against the deployed policy and environment configuration.

Worked example: payment access

Assume an organisation's payment API allows a preparer to create a payment and a separate approver to release it. The test fixture contains two organisations, Org A and Org B, each with its own account. The preparer token has payment-creation permission for Org A; the approver has release permission for Org A.

• As Org A's preparer, submit a payment from Org A's account. Expect acceptance into a pending-approval state, with no settlement instruction yet.
• As the same preparer, call the release operation. Expect the contract's authorisation denial. Confirm that the payment remains pending.
• As Org A's approver, release that payment. Expect the permitted state transition and the documented downstream result.
• As Org A's preparer, substitute Org B's account identifier in the creation request. Expect denial and verify that Org B's account and payment records remain unchanged.

This sequence checks both role permissions and resource ownership. It also checks side effects, which a response-code assertion alone cannot establish. The precise status codes and payment states must match the API contract and configured banking rules.

Common failure modes and trade-offs

A test can give false confidence if every request uses an administrator token, fixtures share the same customer, or assertions check only HTTP status. Include identities with different permissions and resources owned by different customers. Check response bodies and side effects for sensitive data exposure, even when access is denied.

Gateway checks may reject a request before it reaches the banking service, while the service may apply additional account or transaction rules. Test through the public API boundary and, where architecture or risk warrants, verify the enforcement at service boundaries as well. Keep test identities, policies and environment configuration aligned: drift can make a permission defect appear to be a test-data problem, or conceal a defect behind an unexpectedly restrictive environment.

API authorisation testing concerns permission to access operations and resources. It is distinct from authentication testing, which checks how identity is established, and from payment-card authorisation, which concerns approval of a card transaction by the relevant payment process.