How to test open banking consent in neobanking apps

Neobank open banking consent testing checks that a customer can grant, use, review and withdraw permission for an external financial provider to share specified account data or enable a permitted service, and that the neobank and connected APIs enforce those choices throughout the consent lifecycle. It verifies the customer journey, consent record, access decisions and failure handling against the product's provider contracts.

What neobank open banking consent testing covers

Consent describes the customer's permission for a defined use of financial data or a service. The details can include the provider, selected accounts, data categories, purpose, duration and current status. The exact fields and lifecycle rules depend on the applicable open banking scheme and provider integration, so derive expected results from the relevant contracts and product requirements.

In an open banking flow, an account servicing payment service provider (ASPSP) holds the account, while a third-party provider (TPP) may request access. A neobank may act as the TPP, use another TPP, or present a service delivered through a partner. Map which system creates and stores consent, which component obtains access tokens, and which API enforces permission before writing tests.

Consent testing checks business permission and its lifecycle. Authentication tests check who the customer is; authorisation tests check whether a request is permitted. These concerns interact, but a successful login or valid token does not by itself prove that the requested account and data remain within the customer's consent.

Prepare the test conditions

Use a provider sandbox or controlled integration environment with test accounts and data. Record the expected scopes, account selection rules, expiry behaviour, revocation semantics and error handling for each provider. If an external dependency cannot produce a required failure consistently, use a stub for that case and retain separate tests against the provider's sandbox.

Keep the customer, consent and test account identifiers traceable across the neobank, consent service and provider. Avoid production credentials and real customer data. Ensure test logs and captured evidence exclude access tokens, secrets and unnecessary personal data.

Test the consent lifecycle

Cover the customer journey and the API enforcement behind it:

• Grant: Complete consent for a defined purpose. Check that the displayed provider, accounts, data categories and duration match the request, and that the resulting consent record is bound to the correct customer and provider.
• Use: Request data for an authorised account and scope. Verify the API response and the neobank display. Try another customer's account, an unselected account and data outside the granted scope; each must be denied according to the integration contract.
• Review and renew: Check that the app shows the correct provider and permission status. Test expiry and any renewal or re-consent flow defined by the product. Confirm that changing requested permissions cannot silently broaden an existing grant.
• Withdraw: Revoke consent through the supported journey. Verify the updated status and confirm that subsequent provider requests are rejected or otherwise handled as specified. Check the treatment of previously retrieved data against the product's retention rules.
• Failure and interruption: Test provider timeouts, cancelled authentication, declined consent, callback errors and duplicate submissions. Confirm that the neobank does not show an active consent when completion failed, and that retry or recovery does not create conflicting records.

Consent status and access-token validity can have separate lifecycles. Test expiry and revocation against the provider's defined behaviour rather than assuming a particular HTTP status or token model. Where events or callbacks update consent state, verify that delayed, repeated or out-of-order updates do not restore a revoked permission.

Practical example

For an account information journey, a customer selects one external current account and approves access to its balance and transactions. Verify that the consent record identifies the intended customer, provider and account, and that the neobank can retrieve only the permitted information. Attempt a request for a second, unselected account and expect the provider or integration layer to deny it under the agreed contract. Then revoke the consent and repeat the original request. The app must show the correct revoked state, and further access must follow the provider's revocation rules. Check any displayed cached data against the product's stated retention and presentation behaviour.

Verify results across the integration

Assert outcomes at the user interface and service boundary. Compare the consent shown to the customer with the stored record and provider response, using correlation identifiers to trace the same journey. For failures, check that the interface gives an accurate status, the consent record does not enter a false active state, and retry behaviour is safe. Include these cases in regression tests when provider configuration, consent screens, API scopes or token handling change. For broader account-data flows, see [Open banking API testing] and [Open banking consent lifecycle testing].