Open Banking v4 hardened security and tidied the data model. Moving from the v3.1.x line to v4.0.1 (published 18 March 2026), it adopted the FAPI 1 Advanced security profile, made payload signature verification mandatory, reclassified Meta and Links as conditional, split payment status codesets by payment type, added optional rate-limit headers and introduced the OBIntermediaryAgent class.
The path to v4
v4 did not arrive all at once; it is the current point on a line that ran through the v3.1.x versions. The current release is v4.0.1, published 18 March 2026, with Read/Write API release notes dated 1 April 2026. There is no separately dated "v4.0" release to track; v4.0.1 is the version you target.
The key changes
| Change | What it means |
|---|---|
| FAPI 1 Advanced | The security profile to use; FAPI 1.0 ID2 and the legacy UK open banking profile are deprecated. |
| Payload signature verification | Moved from recommended to required: parties must verify message signatures. |
| Meta and Links reclassified | Changed to conditional, so they are not always present; handle their absence. |
| Status codesets split | Payment transaction status codes are split by payment type (scheduled, domestic and international, file, domestic VRP). |
| Rate-limit headers | Optional rate-limit headers added, to signal how close a caller is to a bank's limits. |
| OBIntermediaryAgent | A new class, able to appear up to three times; returning its fields requires the ReadTransactionDetail permission. |
These are the changes that touch an integration most directly. For the security detail see the security profile, and for the status detail see error codes and payment status.
CEG, OG and Good Practice
v4 is not only the API. The Customer Experience Guidelines, Operational Guidelines and Good Practice were updated to v4.0.1 on 18 March 2026 as well, keeping the journey, operational and implementation guidance aligned with the API changes. If you are checking a provider or a bank is current, it is the whole v4.0.1 set that matters, not just the Read/Write API; the standards tracker lists each part.
Migration implications for a data consumer
- Security: ensure your provider is on FAPI 1 Advanced and verifies payload signatures, now that both are required.
- Data model: handle Meta and Links being conditional, so code does not assume they are present.
- Payments: reconcile per payment type, because status codes are no longer one shared set.
- Reliability: respect rate-limit headers where provided.
In practice, a data consumer using a maintained platform inherits this migration from the provider. The reason to understand it is to confirm your provider has done it: ask which version they are on and whether they verify signatures, and check it against the tracker.
From the data consumer's side
You do not run the migration, but you should verify it happened. The short checklist is: FAPI 1 Advanced, signature verification on, per-type status handling, and conditional Meta and Links handled. A provider on v4.0.1 who can confirm these is current; one who cannot is behind, which eventually shows up as failures and security gaps.
How Credit Canary does it
Credit Canary works through a provider on the current v4.0.1 Standard, with FAPI 1 Advanced and payload signature verification, per-type status handling and conditional-field handling in place. You inherit a current, maintained integration rather than managing version migrations yourself.
Common questions
What changed in Open Banking Standard v4?
v4 adopted the FAPI 1 Advanced security profile, made payload signature verification mandatory, reclassified Meta and Links as conditional, split payment status codesets by payment type, added optional rate-limit headers and introduced the OBIntermediaryAgent class. The current version is v4.0.1, published 18 March 2026.
When was Open Banking v4.0.1 published?
v4.0.1 was published on 18 March 2026, with Read/Write API release notes dated 1 April 2026.
Is payload signature verification mandatory in v4?
Yes. In v4 payload signature verification moved from recommended to required, so parties must verify message signatures rather than treating it as optional.
What does the v4 status codeset split mean for integrations?
Payment transaction status codes are now split by payment type, so scheduled, domestic and international, file and domestic VRP payments use their own status codesets. Reconciliation must be handled per payment type.
Related pages
Primary sources
- Read/Write API v4.0.1 version control (release notes) (checked 14 Oct 2026).
- Operational Guidelines v4.0.1 (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.