What is open finance integration testing?

Open finance integration testing checks that a financial service exchanges data and instructions correctly with external providers through agreed interfaces, such as application programming interfaces (APIs). It verifies behaviour across consent, authentication, data mapping, business rules and error handling, including how the service responds when a provider is unavailable or returns invalid data. The scope can extend beyond bank accounts to products such as savings, investments, pensions or credit, depending on the service and applicable arrangements.

What open finance integration testing covers

Open finance connects a customer-facing service to financial institutions and other data holders, often through third-party providers. Integration testing checks the boundaries between those systems: whether requests and responses follow the API contract, whether customer data retains its meaning as it moves between systems, and whether each participant handles the result correctly.

Tests commonly cover consent creation, scope and expiry; authentication and authorisation; account or product data retrieval; transaction or balance updates; and the handling of revoked access. Where a service can initiate an action, such as a payment, tests should also check that the request is authorised, its status is reported accurately and retries do not cause an unintended duplicate action.

The exact interfaces, data fields and consent rules vary by market, scheme and provider. Testers should derive expected behaviour from the integration contract and product requirements rather than assume that every provider follows the same profile. This is financial services testing as well as API testing: a syntactically valid response can still produce a wrong balance, stale record or incorrect customer-facing status.

How the testing works

Before execution, teams need an agreed interface contract, configured credentials and a test environment for each participant. Test data must represent the relevant accounts, products, consent states and transaction histories. Where a provider sandbox is used, its supported scenarios and data should be understood because a sandbox may differ from production in timing, availability or response behaviour.

A useful test checks both sides of an interaction. For example, after a request for account data, assert the HTTP status and response schema, then verify that the application maps the account identifier, currency, balance type and timestamp correctly. Confirm that a failed or incomplete response does not appear as valid customer data. Keep sensitive test data controlled and avoid using real customer credentials in automated runs.

Integration tests should also exercise failure paths. These include expired or revoked consent, an unauthorised request, rate limiting, a provider timeout, malformed data and a response that arrives after a retry. Verify the resulting user-visible state, internal status and any audit record required by the design. For asynchronous updates, check that repeated or out-of-order events do not leave the service with conflicting records.

Practical example

Suppose a personal finance application retrieves a customer's investment account valuation from an external provider. A test can create a valid consent, request the valuation and check that the application displays the returned amount with the correct currency and valuation date. It can then revoke consent and repeat the request. The expected result is an access failure handled according to the contract, with no new valuation shown as current. A separate timeout test can confirm that a retry does not create duplicate records.

These checks are most reliable when assertions cover the provider response, the consuming service's stored or displayed result, and the consent state. A passing API status alone does not establish that the integration is correct.

How it differs from related testing

Open finance integration testing focuses on interactions between participating systems and the correctness of their exchanged data and actions. API testing can validate an endpoint in isolation, while end-to-end testing follows a broader customer journey across applications and services. Both can contribute evidence, but they answer different questions. Contract tests help detect interface changes; provider simulation can make failure cases repeatable when a sandbox cannot produce them consistently.