How to test the open banking consent lifecycle

Open banking consent lifecycle testing checks that a customer's permission to share account data or initiate payments is created, authorised, used, changed, revoked and expired according to the applicable rules. It verifies the complete flow across the customer interface, the third-party provider, the bank's API and supporting services, including whether each party applies the same consent state and access scope.

Model the consent lifecycle before testing

Consent states and rules vary by jurisdiction, scheme and provider. Start with the relevant API specification, product requirements and security policy. Map the allowed transitions, required customer actions, time limits, permission scopes and expected responses. A typical model may include a pending consent, an authorised consent, and terminal states such as revoked or expired. Treat these as examples, not universal status names.

Record what each consent permits: the accounts in scope, data categories, payment permissions where applicable, duration, and any limits on use. Identify which system owns each field and how changes reach other components. This creates a basis for [state transition testing in banking] and [open banking API testing].

Keep consent separate from the credentials used to access an API. An access token may expire or be invalidated while the underlying consent remains active. Test token expiry, refresh and rejection against the provider's contract, then verify that none of these mechanisms silently extends or broadens consent.

Exercise each transition and boundary

Build tests for the complete customer journey and for API-level state changes. Include successful paths and invalid transitions, such as attempting data access before authorisation or reusing a revoked consent. Check both the response and the resulting state held by each participating service.

For creation and authorisation, verify that the customer sees the requested scope and duration, completes the required authentication and confirmation, and returns to the correct application. Confirm that the bank records the agreed scope, links it to the right customer and accounts, and exposes only permitted data. Test declined, abandoned, timed-out and interrupted authorisation journeys. These can leave an incomplete record, so check whether it can be resumed, safely retried or cleaned up according to the design.

For ongoing access, call the relevant account or transaction API using the consent and token. Assert that permitted resources are returned, excluded accounts remain inaccessible, and requests without valid authorisation fail with the documented error. Include boundary checks for consent expiry and any provider-defined limits on history or data access.

For changes, test any supported scope amendment, account removal or re-authorisation flow. Confirm that the resulting permission set matches the customer's latest choice. For revocation, revoke consent through each supported channel, then attempt access again. Verify denial within the contractually defined propagation period, including across cached permissions, downstream services and active sessions. Test expiry through both natural time progression in a controlled environment and explicit status handling where available.

Verify security and consistency

Use separate test customers and accounts, with data that makes cross-customer leakage easy to detect. Try a valid token with the wrong customer, consent or account identifier. Tamper with identifiers, replay requests, submit duplicate authorisation actions and use expired or revoked credentials. Confirm that the service rejects each request without disclosing account data. These checks support [banking API authorisation testing] and [security testing].

Inspect audit records for consent creation, customer confirmation, scope changes, access attempts, revocation and expiry. Check that events identify the relevant consent and actor, timestamps are coherent, and sensitive values such as tokens are not written to logs. Where services update asynchronously, verify ordering, retries and recovery after a temporary outage. A stale consent state in one component can permit access after revocation or block valid access after authorisation.

Run the suite against representative provider configurations and API versions. Differences in status values, error responses, authentication journeys and event delivery can expose assumptions hidden by a single test environment. Record those differences as explicit configuration or contract expectations.

Practical example: revoke account access

Create a consent for account A, authorise it, and request its balance with a valid access token. Assert that the response contains account A's expected test data. Revoke the consent, then repeat the balance request using the same token. The expected result is denial within the agreed propagation period, with no balance data in the response. Check the consent status, audit event and any downstream cache or subscription. Also request account B and confirm that the original consent never granted access to it.