What is open banking API testing?

Open banking API testing verifies that financial services exchange data and payment instructions through application programming interfaces (APIs) correctly, securely and in line with the applicable regional rules and technical specifications. It covers interactions between a customer, an authorised third-party provider and a bank, including consent, authentication, access to permitted data and payment outcomes.

What open banking API testing covers

Tests should follow the relevant API specification and regional profile. Requirements differ between markets, so teams need to confirm which data models, security protocols and payment rules apply to the service under test. OAuth 2.0, OpenID Connect and Financial-grade API (FAPI) profiles may form part of the required implementation, depending on that profile.

Functional tests check that valid requests return the expected account information or payment status. They also check that responses follow the agreed schema, contain the required fields and handle errors consistently. An account-data test might verify that a transaction request returns only the accounts covered by the customer's consent.

Authentication verifies the identity of the parties involved. Authorisation checks what an authenticated party may do. Tests should confirm that a third party cannot access data outside the granted scope, use an expired token or continue accessing data after consent has been withdrawn. They should also check that sensitive information does not appear in error messages or logs.

Payment initiation tests cover the request, validation, customer approval and resulting status. Depending on the API, checks may include duplicate requests, invalid payment details, insufficient funds and payment cancellation. A successful API response does not by itself prove that a payment has settled, so tests should verify the relevant status or downstream result defined by the service contract.

Dependencies and failure modes

Testing depends on stable API specifications, suitable credentials, representative test data and access to the systems involved. A bank sandbox can support repeatable tests, but it may differ from production in data, authentication flows, error behaviour or connected services. Record these limits and verify production configuration through controlled checks where permitted.

Common failures include accepting a token with the wrong scope, returning data after consent revocation, mishandling expired credentials and reporting a payment as complete when it remains pending or has failed. Environment drift can also cause a journey to pass in one environment and fail in another. Keep configuration and API versions aligned, and investigate failures against the request, response, consent state and relevant service logs.

Automated tests in a continuous integration (CI) pipeline can check schemas, contract behaviour and core security rules on each change. They do not replace broader security testing, operational checks or review of the applicable requirements. Use synthetic or appropriately protected test data, and avoid sending real customer credentials through test pipelines.

Practical example: account-data access

A test for access to account transactions could follow this sequence:

1. Create a test customer and grant consent for transaction access to one account.
2. Obtain a token with the expected scope and request that account's transactions.
3. Assert that the response matches the API schema and contains transactions for the permitted account only.
4. Revoke consent and repeat the request using the same token.
5. Assert that access is denied according to the API contract and that no transaction data is returned.

This test checks the full link between consent, token scope and data access. A separate test should cover a token that has expired or lacks the required scope, since each condition can fail through a different control.