Open banking's security rests on FAPI 1 Advanced, the Financial-grade API profile used in Standard v4. It hardens OAuth 2.0 and OpenID Connect for high-value use, requires strong customer authentication at the bank, and, in v4, makes payload signature verification mandatory. This page is what a CTO should check a provider has in place.
FAPI 1 Advanced
FAPI, the Financial-grade API profile from the OpenID Foundation, is a hardened set of rules on top of OAuth 2.0 and OpenID Connect for APIs where the stakes are high. UK open banking v4 uses the FAPI 1 Advanced profile; the older FAPI 1.0 ID2 and the legacy UK open banking security profile are deprecated. A key v4 change is that payload signature verification moved from recommended to required, so both sides verify message signatures rather than treating it as optional. For where this sits, see the Standard explained and what changed in v4.
Strong customer authentication
Strong customer authentication (SCA) requires the customer to prove their identity with at least two independent factors, from the categories of something they have, something they know and something they are. In open banking, SCA is performed by the customer's own bank during authorisation, not by the provider. This is what makes a connection resistant to stolen passwords, and it is the security point to reassure customers about. See is open banking safe.
Redirect vs decoupled authentication
There are two main ways the customer authenticates, and the Customer Experience Guidelines describe authentication models (commonly labelled A to D) that span them. The two you need to understand are:
| Approach | How the customer authenticates | Good for |
|---|---|---|
| Redirect | Sent to the bank's app or website to authenticate, then returned to you. Includes app-to-app, where it opens the banking app directly. | The common, familiar flow on most journeys. |
| Decoupled | Approves in a separate channel, usually their banking app, without an in-line redirect from your page. | Call-centre, in-person, or cross-device journeys. |
Most consumer journeys use redirect (often app-to-app for a smooth mobile experience); decoupled suits cases where the customer is not on the device that started the request. A good provider supports the model your journeys need.
CIBA
CIBA (Client-Initiated Backchannel Authentication) is the OpenID mechanism behind decoupled flows. In UK open banking it is optional: if a bank implements it, it must adhere to the FAPI CIBA profile. For most data consumers it is a detail handled by the provider, relevant only if you specifically need decoupled authentication for your journeys.
Tokens and clock skew
After authorisation, the bank issues the provider tokens: a short-lived access token scoped to what was consented, and often a longer-lived refresh token for ongoing access within the consent window. Signed assertions used in the flow are time-sensitive, so a small tolerance for clock skew is allowed to account for minor differences between systems' clocks. These are provider-level concerns; what matters to you is that your provider manages token lifetimes and renewal correctly so that access neither expires unexpectedly nor outlives its consent.
OpenID Foundation certification
FAPI conformance can be independently certified through the OpenID Foundation's certification programme, which tests an implementation against the profile. When assessing a provider, certification is a useful, verifiable signal that their security implementation meets the standard rather than merely claiming to. Combined with the v4 signature-verification requirement, it is one of the concrete things to ask for. See choosing a provider.
From the data consumer's side
You do not build the security profile, but you should verify your provider has it right, because it is your customers' data and money. The checklist is short: current FAPI 1 Advanced, payload signature verification as required in v4, OpenID Foundation certification, correct token and certificate handling, and support for the authentication models your journeys use. A provider who cannot answer these clearly is a red flag.
How Credit Canary does it
Credit Canary operates through a regulated provider implementing the current FAPI 1 Advanced profile, with SCA performed by the customer's bank and v4 signature verification in place. You get bank-grade security without implementing the profile yourself, as part of one platform with bureau and identity data.
Common questions
What is FAPI?
FAPI, the Financial-grade API profile from the OpenID Foundation, is a hardened set of OAuth 2.0 and OpenID Connect rules for high-value APIs. UK open banking v4 uses FAPI 1 Advanced, replacing older profiles.
What is strong customer authentication?
Strong customer authentication (SCA) is the requirement for a customer to confirm their identity with at least two independent factors. In open banking it is performed by the customer's own bank during authorisation.
What is the difference between redirect and decoupled authentication?
In redirect authentication the customer is sent to their bank's app or website to authenticate and then returned. In decoupled authentication they approve in a separate channel, usually their banking app, without an in-line redirect.
What should a CTO check about a provider's security?
That the provider implements the current FAPI 1 Advanced profile, verifies payload signatures as required in v4, holds relevant OpenID Foundation certification, manages tokens and certificates correctly, and supports the authentication models your journeys need.
Related pages
Primary sources
- Read/Write API v4.0.1 security profile (checked 14 Oct 2026).
- OpenID FAPI 1 Advanced specification (checked 14 Oct 2026).
- OpenID Foundation certification (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.