Open banking is tested without real money or real accounts: against a model bank and bank sandboxes that behave like production, and against conformance tools that check functional, security and registration behaviour. Your provider does most of this. Your job is to test your own journeys, decisions and error handling before going live.
The model bank
The model bank, provided by Ozone, is a reference implementation of the Standard: a controlled environment that behaves like a compliant bank so you can exercise flows end to end without touching real customer accounts or moving real money. It is where much integration testing happens, because it is predictable and always available, unlike a real bank sandbox that may be undergoing its own changes. For your provider it is a cornerstone of building and maintaining a reliable integration.
Bank sandboxes
Beyond the model bank, individual banks provide their own sandboxes: test versions of their APIs with test data, used to confirm that an integration works against that specific bank, which may have its own quirks. Testing across the banks your customers actually use is part of how a provider achieves real-world coverage. It is also why coverage is a provider strength rather than a given: supporting many banks means testing and maintaining against many sandboxes.
Conformance tools
The Standard comes with conformance tooling that checks an implementation follows the rules. In broad terms there are tests for:
- Functional behaviour, that the APIs do what the Standard says.
- Security, that the FAPI security profile is correctly implemented. See the security profile.
- Dynamic client registration, that registration works as specified. See DCR.
Passing conformance is evidence an implementation is compliant, which is one of the verifiable signals to look for in a provider.
What you test versus what the provider tests
The division of labour is clear. Your provider tests the integration itself: conformance, security, registration, and behaviour across banks. You test your own layer on top: your customer journeys, your decisioning on the enriched data, and your handling of errors, abandonment and edge cases, using sandbox data so nothing is real. In other words, the provider proves the pipe works; you prove your use of it works. See error handling.
Go-live checklist
- Your provider is on the current Standard (v4.0.1) and passes conformance.
- Coverage is confirmed for the banks your customers actually use.
- Your consent journey is tested, including abandonment and re-consent.
- Your decisioning is validated on realistic sandbox and real-case data.
- Error and status handling is tested per payment type, with retries where safe.
- A manual fallback exists for customers who cannot or will not connect.
- Monitoring and support arrangements, and your SLA, are in place.
Working through this before launch turns go-live from a leap into a formality.
From the data consumer's side
You do not need to run conformance tools, but you do need to test your own journeys and decisions, and to confirm your provider has done the rest. Insist on sandbox access so you can validate your flows with test data, check coverage for your customers' banks, and walk the go-live checklist. The discipline pays off in a launch that works on the hard cases, not just the demo ones.
How Credit Canary does it
Credit Canary works through a provider that tests against the model bank, bank sandboxes and conformance tooling, and gives you sandbox access to validate your own journeys and decisioning before go-live. You launch on a tested integration with a clear checklist, not a hope.
Common questions
How do you test open banking?
You test against a model bank and bank sandboxes that behave like production without moving real money, and against conformance tools that check functional, security and registration behaviour. Your provider does most of this; you test your own journeys and decisions.
What is the Ozone model bank?
The model bank, provided by Ozone, is a reference implementation of the Standard used to test integrations in a controlled environment that behaves like a compliant bank, without touching real customer accounts.
What do conformance tools check?
Conformance tools test that an implementation follows the Standard: functional behaviour of the APIs, the security profile, and dynamic client registration. Passing them is evidence an implementation is compliant.
What does a data consumer test versus the provider?
The provider tests the integration, security and conformance. You test your own customer journeys, your decisioning on the enriched data, and your handling of errors and edge cases, using sandbox data before going live.
Related pages
Primary sources
- Open Banking Standard, conformance tools (checked 14 Oct 2026).
- Read/Write API v4.0.1 profile (checked 14 Oct 2026).
Credit Canary provides open banking through fumopay limited, an FCA-authorised account information and payment initiation service provider (FRN 925689), of which Credit Canary is an agent. Underlying bank connectivity is also provided by fumopay limited. This page is an evergreen reference and is reviewed and dated; it is not regulatory, legal or financial advice.