Open banking API testing means proving three things: that your APIs behave correctly under the standard, that consent and authentication cannot be bypassed, and that your integration survives the way real banks actually behave. A passing happy-path call is the start of that work, not the end of it.
Whether you are a bank exposing APIs or a fintech consuming them, the same gaps cause the failed launches and the late-night production incidents. Here is how to test properly.
Why open banking APIs are harder to test than ordinary APIs?
An open banking journey is not a single request. It is a chain: the third-party provider registers, the customer is redirected to their bank, authenticates and gives consent, a token is issued, and only then do the data or payment calls happen. Each link depends on the one before it, and each bank implements the standard slightly differently.
That creates three kinds of risk:
- Functional risk. The payment or account data is wrong, incomplete, or arrives in the wrong state.
- Security risk. These APIs move money and personal financial data, so a flaw in consent or token handling is a direct exposure.
- Integration risk. The specification allows variation, so code that works against one bank can fail against the next.
Start with the standard
In the UK, the Open Banking Read/Write API standards are the reference point. The latest published version is v4.0.1, which builds on v4.0, the first major update since 2018. According to industry analysis of v4.0, payment APIs adopt ISO 20022 code values and the security profile moves to FAPI 1.0 Advanced. Check the current specification on the Open Banking standards site before you build your test plan, as versions and governance continue to change.
Open Banking Limited also provides conformance tooling, including a functional conformance tool for account information, payment initiation and confirmation of funds, and a dynamic client registration tool. Run these early. They are a baseline, not a substitute for your own testing, because they check conformance to the specification rather than how your product behaves end to end.
Functional testing: what to cover?
Functional open banking API testing should follow the customer journey, not the endpoint list. Cover at least:
- Consent lifecycle. Create, authorise, amend, revoke and expire consents. Check that revoked or expired consent actually stops access.
- Account information. Accounts, balances, transactions, pagination, date ranges, and what happens with large histories or accounts with no activity.
- Payment initiation. Single payments, scheduled payments, and variable recurring payments where you support them. Test the status model carefully, including pending, rejected and failed states.
- Idempotency and retries. A retried payment request must not create a second payment.
- Error handling. Insufficient funds, closed accounts, invalid references, timeouts and bank downtime. Your product should fail clearly, not silently.
- Data accuracy. Amounts, currencies, references and timestamps must match the source system exactly, including at boundaries such as month end and time-zone changes.
This is where our functional testing approach starts: map the journey, then test every state a payment or consent can be in.
Security testing: where the real exposure is?
Security is the part of open banking API testing that cannot be skipped. The checks that matter most:
- Authentication and token handling. Tokens must be bound correctly, expire when they should, and be rejected when replayed or presented by the wrong client.
- Consent enforcement. A token granted for one account or permission must not return data for another. Test for broken object-level authorisation by trying to read other customers’ resources.
- Redirect and authorisation flow. Validate redirect URIs, state and nonce handling, and the behaviour of the flow when a step is repeated or interrupted.
- Transport and certificate security. Mutual TLS, certificate validation and revocation behaviour.
- Input handling and rate limits. Injection, malformed payloads, oversized requests and abusive call volumes.
Our security testing work covers these areas, including penetration testing of the API layer and the authorisation flow around it.
Non-functional testing: performance and resilience
Open banking traffic is bursty and the dependencies are outside your control. Test:
- Performance under load, including month-end and payday peaks.
- Latency and timeouts when a bank responds slowly.
- Resilience when a bank is unavailable or returns unexpected errors, including your retry and fallback behaviour.
- Version changes, so a bank moving to a new specification version does not break your integration without warning.
Test against reality, not only the sandbox
Sandboxes are useful but forgiving. They rarely reproduce production data volumes, edge-case account types, rate limits or intermittent failures. A reliable approach is:
- Contract and conformance tests against the specification, run on every build.
- Sandbox integration tests for each bank you connect to, because banks differ.
- Controlled production checks with real test accounts, to catch what the sandbox hides.
- Monitoring after launch, so a bank-side change is spotted by you before your customers report it.
The mistakes we see most often
- Testing only the happy path and one bank.
- Treating conformance tool results as proof the product is secure.
- No negative testing of consent and token boundaries.
- No test for duplicate or retried payments.
- Ignoring bank-specific behaviour until a customer hits it.
The practical starting point
If you are about to launch or change an open banking integration, begin with a journey map. List every consent and payment state, mark which have automated tests, and check which security cases (token misuse, cross-account access, replayed requests) have never been tried. Fix the security and payment-state gaps first, then widen coverage bank by bank.
It is far cheaper to find a consent bypass or a duplicate payment in your own test cycle than in production.
Launching or changing an open banking integration? We test the full journey, from consent and payments to API security. Get in touch.