Definition
FAPI (Financial-grade API) is an OAuth 2.0 and OpenID Connect security profile designed for financial APIs.
Standardised by the OpenID Foundation, it is the global reference standard for Open Banking security. It hardens OAuth/OIDC by mandating strong algorithms (PS256, ES256), strict token binding (mTLS, DPoP), anti-tampering mechanisms (JAR, PAR), signed responses and rigorous certification.
Two major versions coexist: FAPI 1.0 (final in March 2021, with Read-Only and Read-Write profiles) and FAPI 2.0 Security Profile (final in February 2025), which simplifies things and natively integrates PAR and DPoP/mTLS.
Why FAPI
OAuth 2.0 is too loose for finance: variable implementations, known attacks (CSRF, mix-up, code injection), unbound tokens. FAPI tightens the screws:
- token bound to the client (mTLS or DPoP) — a stolen token is unusable;
- signed request (JAR) — a consent cannot be altered in transit;
- PAR — the request_uri is short and not leakable in logs;
- strong algorithms only;
- signed ID Token — verifiable on the client side.
FAPI 1.0 vs FAPI 2.0
| Aspect | FAPI 1.0 (Advanced) | FAPI 2.0 (Security Profile) |
|---|---|---|
| Profiles | Baseline (read) + Advanced (write) | A single one |
| Token binding | mTLS or OAuth Token Binding | mTLS or DPoP (your choice) |
| Request | JARM required | PAR + JAR required |
| Algorithms | PS256, ES256 | PS256, ES256 (simplified) |
| Hybrid flow | Required (Advanced) | Removed (PAR replaces it) |
| Adoption | Massive (2021-2024) | Under way (2024-2027) |
FAPI 2.0 is easier to implement correctly, more secure by default and more interoperable.
Technical components
- mTLS: the client authenticates with an X.509 certificate (often a QWAC in the EU); the token is bound to this certificate.
- DPoP: an alternative to mTLS, based on a JWT signed by a private key, simpler for mobile and SPAs (adopted in FAPI 2.0).
- PAR: the client pushes its authorisation request via a back-channel API and receives an opaque
request_uri— anti-tampering, anti-leak. - JAR: the OAuth request is wrapped in a signed JWT, impossible to alter in transit.
- JARM: a signed OAuth response in a JWT, verifiable on the client side.
The typical FAPI 2.0 flow
Adoption
- United Kingdom (OBIE): FAPI 1.0 Advanced, with banks and TPPs all compliant — the global reference model.
- Brazil (Open Finance Brazil): FAPI 1.0 Advanced (then 2.0), mandated by the BCB, more than 800 institutions — the largest Open Finance ecosystem.
- Australia (CDR): FAPI 1.0 Advanced, mandated by the ACCC and the Treasury.
- Elsewhere: Berlin Group and STET draw inspiration from it but are less strict (mTLS and JAR often optional). The EU remains the most permissive zone, hence recurring debates about mandating FAPI in DSP3.
FAPI vs Berlin Group / STET
| Aspect | FAPI 1.0 Advanced | Berlin Group XS2A |
|---|---|---|
| OAuth profile | Strict (mTLS + JAR + JARM) | More flexible (mTLS optional) |
| Client auth | Mandatory QWAC mTLS | QWAC often (variable) |
| Message signing | Bank + client (QSealC) | QSealC often required |
| Token binding | mTLS-bound | Not bound (bearer) |
| Certification | FAPI Conformance | No global certification |
DSP2/DSP3 is therefore less "FAPI" than the UK, BR and AU, which complicates international interoperability.
Conformance and certification
The OpenID Foundation offers a FAPI Conformance test suite (for AS and clients). On success, the certification is published on its website, with the list of compliant banks and TPPs — a quality passport for joining the OBIE, CDR or OFB ecosystems.
What FAPI is not
- Not a business API standard: it covers OAuth security, not the format of the
/accountsor/paymentsendpoints (defined by OBIE, Berlin Group, STET, FDX). - Not mandatory under DSP2 / DSP3: recommended, not imposed by the RTS.
- Not reserved for Open Banking: applicable to any financial API.
- Not a replacement for OAuth: it is a hardened profile of OAuth 2.0 + OIDC.
In the PSD2 / Open Finance ecosystem
FAPI is the global gold standard of Open Banking security: a reference outside the EU (UK, BR, AU), less strict in the EU (Berlin Group, STET), with a convergence towards FAPI 2.0 expected via DSP3 and FIDA. Paired with the EUDI Wallet, it forms the identity + secure API combo of extended Open Finance.
Concrete examples
- OBIE UK: a mature FAPI implementation, with certified banks and TPPs.
- Plaid, TrueLayer, Tink: FAPI 1.0 Advanced (Tink certified by the OpenID Foundation).
- Bridge: STET + Berlin Group, not strict FAPI.
- Banco do Brasil, Bradesco, Itaú: FAPI-certified in the OFB.
- Tools: Authlete (JP), Curity (SE), ForgeRock (US) support FAPI natively.
- FAPI 2.0 migration: the OFB plans a 2025-2027 transition, the OBIE is studying it.
- Cost: for a bank, supporting FAPI 2.0 represents a €2 to €5M project (vs ~€200K for basic OAuth), justified by security and international interoperability.