What is account information service testing?

Account information service testing verifies that an open banking service obtains a customer’s authorised account data from a financial institution and handles it accurately, securely and for the permitted period. It covers consent, authentication, API responses, data presentation and failure handling. The service is commonly called an account information service (AIS), and its provider an account information service provider (AISP).

What account information service testing covers

An AIS lets a customer view information from one or more accounts through a third-party application. Depending on the customer’s permission and the bank’s API, this can include account identifiers, balances, transactions and account details. AIS access is for retrieving information. Initiating a payment is a separate service and requires separate testing.

Testing usually crosses several systems: the customer-facing application, the AISP’s services, the bank’s application programming interface (API), and identity or consent services. The exact authorisation flow and available data vary by market and provider, so test conditions should reflect the interfaces and permissions in scope.

A useful test scope includes:

• Consent creation, the accounts and data scopes covered, expiry, renewal and revocation.
• Authentication and authorisation, including access tokens, token expiry and attempts to access data outside the granted scope.
• API behaviour, such as response schemas, pagination, rate limits, timeouts and documented error responses.
• Data correctness, including account identity, currency, transaction amount, booking date and balance values.
• Customer-facing behaviour when an account is unavailable, consent has expired or a bank returns incomplete data.
• Protection of credentials and financial data in transit, logs, test evidence and stored test data.

Consent is a dependency for data access. Tests need a known consent state and test identities with defined account permissions. A request may fail because the customer has not completed authentication, the consent is out of date, or the bank’s service is unavailable. Assertions should check both the returned status and the resulting behaviour in the application, including whether stale or partial data is labelled appropriately.

How to verify an AIS workflow

A practical scenario starts with a customer selecting a bank and approving access to a specified account. The application completes the bank’s authorisation flow, receives an access token, requests permitted account data and displays the response. Verify that the data belongs to the authorised account, matches the API response and remains within the consent scope.

For example, give a test customer consent to view one current account. Confirm that the AISP displays that account’s balance and transactions, and that a request for a second account is rejected or excluded when it is outside the granted permission. Revoke the consent, then repeat the data request. Verify that access is denied and that the application communicates the loss of access without continuing to show newly fetched data as current.

API assertions should cover field values and semantics, not just successful HTTP status codes. Check that decimal amounts and currencies are preserved, transaction ordering follows the API contract, and pagination does not omit or duplicate records. Where balances have different meanings, such as a booked balance and an available balance, verify that the application labels and maps them correctly.

Test environments and failure modes

A bank sandbox can exercise real API contracts and authorisation flows, but its data and availability may differ from production. Mocks make edge cases such as timeouts, malformed responses and rate limiting repeatable. Use both where practical: contract-focused checks against the available bank environment, and controlled tests for failures that are difficult to trigger reliably. A mock passing does not prove that the live integration is configured correctly.

Common failures include expired or revoked consent, token refresh problems, changed API schemas, delayed transaction feeds and environment drift between test and release. Record the consent state, request identifiers, API response and application outcome for each failure. Mask personal and financial data in logs and evidence, and use synthetic or appropriately controlled test data.

AIS testing is a focused part of open banking API testing. It also connects to open banking consent lifecycle testing, which examines consent states and transitions in greater depth.