← Payment Reference GuidesAPI Security Reference

FAPI: the Financial-grade API Security Profiles

FAPI is the OpenID Foundation's hardened profile of OAuth 2.0 and OpenID Connect for APIs where a stolen token means a stolen payment. This guide covers FAPI 1.0 Baseline and Advanced, the FAPI 2.0 Security Profile and its attacker model, Message Signing and CIBA — what each one requires, the authorization-code flow message by message, which open-banking ecosystems mandate which profile, and a checklist for shipping it.

What FAPI is

Plain OAuth 2.0 is a framework: it leaves dozens of choices to the implementer — which grant, which client authentication, bearer or bound tokens, whether request parameters may travel through the browser, which signing algorithms. Each choice is a place where a real deployment has been broken. FAPI (originally Financial-grade API, now used as a name in its own right) is a profile published by the OpenID Foundation's FAPI Working Group that removes those choices: it keeps the OAuth 2.0 / OpenID Connect building blocks, picks the secure option for every one of them, and adds a handful of hard limits.

It was written for open banking — UK Open Banking adopted it in 2018 before version 1.0 was even final — but the profile is deliberately generic. Anything where an API call moves money, discloses regulated data or asserts identity at high assurance is in scope: account access and payment initiation, open finance and open data, e-health, government and digital-identity schemes.

FAPI 1.0

Baseline & Advanced

Final since March 2021. Part 1: Baseline for read-only APIs, Part 2: Advanced for read-write — signed request objects, hybrid flow or JARM, mTLS or private_key_jwt, certificate-bound tokens. Still what most live open-banking ecosystems run.

FAPI 2.0

Security Profile

Final since February 2025. A simpler, formally analysed redesign: PAR + PKCE, authorization code only, iss in the response, tokens bound by mTLS or DPoP. One profile instead of two, with an explicit attacker model it is proven against.

Add-ons

Message Signing & CIBA

FAPI 2.0 Message Signing (Final, September 2025) adds non-repudiation with JAR, JARM and signed introspection responses. FAPI-CIBA profiles the decoupled, app-to-app flow where the user approves on their phone instead of being redirected.

The three security goals

FAPI 2.0 is defined against goals rather than a list of threats. The Attacker Model states them precisely, and the profile is accepted only because a formal analysis (University of Stuttgart) showed the goals hold against every combination of the attackers it lists:

Authorization — no attacker can access protected resources other than their own. The access token is the credential, so no attacker may obtain and use someone else's.

Authentication — when OpenID Connect is used, no attacker can log in at a client under another user's identity.

Session integrity — no attacker can force a user to be logged in as the attacker, or to operate on the attacker's resources (the CSRF and session-swapping family).

Timeline

When	What
2016–2017	FAPI Working Group formed at the OpenID Foundation; first drafts of the Read-Only and Read-Write profiles.
2018	UK Open Banking (OBIE) mandates the draft Read/Write profile for the CMA9 banks — the first large-scale deployment.
2019	First formal security analysis of FAPI (Fett, Hosseyni, Küsters) finds and fixes attacks on the drafts. FAPI-CIBA Implementer's Draft.
March 2021	FAPI 1.0 Final: Part 1 Baseline and Part 2 Advanced (Baseline and Advanced replaced the Read-Only / Read-Write names).
2021–2024	FAPI 2.0 Implementer's Drafts (Security Profile Implementer's Draft 2 at the end of 2022), the Attacker Model, and a second formal analysis.
February 2025	FAPI 2.0 Security Profile and Attacker Model Final. Final conformance tests and certification followed in July 2025.
September 2025	FAPI 2.0 Message Signing Final.
2025–2026	ISO/IEC track: FAPI 2.0 Part 1 (Security Profile) and Part 2 (Attacker Model) balloted as ISO/IEC DIS 26083; DIS voting closed on 1 January 2026, following the path OpenID Connect Core took to become ISO/IEC 26131 (with its companion parts) in 2024.

Where a payment engineer meets FAPI. Every PSD2 / open-banking redirect you integrate is a FAPI authorization-code flow; the "sender-constrained token" the bank hands back is FAPI's doing; the conformance certificate an ecosystem demands before it lets your TPP onboard is the FAPI certification. The same OAuth machinery underpins OID4VCI credential issuance in the EUDI Wallet stack, so the FAPI vocabulary — PAR, PKCE, DPoP, JAR — now shows up well beyond bank APIs.

Put it into practice

Next steps

ToolHTTP Signature / Trusted Agent DecoderDecode RFC 9421 HTTP Message Signatures — the Signature-Input and Signature headers behind Web Bot Auth, Visa Trusted Agent Protocol and Mastercard Agent Pay. Rebuilds the signature base, checks freshness and Content-Digest, verifies with a pasted key.Open the tool ToolBase64 Encoder / DecoderEncode and decode Base64 and Base64URL (RFC 4648) — text or hex bytes, padding and MIME/PEM line breaks. Useful for API payloads, certificate data and token inspection.Open the tool ToolASN.1 / DER DecoderDecode ASN.1 DER and BER (including indefinite length) from hex, base64 or PEM — useful for certificate and key data in payment systems.Open the tool FlowFAPI 2.0 authorization code and CIBA flowsSee the animated message flow, step by step, between every party involved.Watch the flow

Keep reading

Open BankingOpen Banking & PSD2AISP/PISP roles, consent & SCA flows, FAPI security, UK / Berlin Group / STET, PSD3 & PSRRead article IdentityEUDI Wallet & PaymentseIDAS 2.0 deadlines, the SD-JWT VC / mdoc / OID4VP stack, wallet-based PSD2 SCARead article Authentication3D Secure (EMV 3DS)Authentication flows, message types, ECI values, SCA exemptionsRead article AgenticAgentic Payments: AP2, ACP & the Trust StackAP2 mandates, ACP/UCP checkout, Web Bot Auth & Visa TAP, EMVCo Intent Services, x402/MPP or card settlementRead article

Common questions

What is FAPI?

FAPI (Financial-grade API) is a set of security profiles from the OpenID Foundation that harden OAuth 2.0 and OpenID Connect for APIs that move money or expose regulated data. It keeps the OAuth building blocks but fixes the choices: confidential clients only, PAR, PKCE S256, sender-constrained tokens, mTLS or private_key_jwt client authentication, and PS256 / ES256 / EdDSA signatures.

What is the difference between FAPI 1.0 and FAPI 2.0?

FAPI 1.0 (Final 2021) has a Baseline profile for read-only APIs and an Advanced profile for read-write APIs that relies on signed request objects, the hybrid flow or JARM, and mTLS-bound tokens. FAPI 2.0 (Final February 2025) is a single, simpler profile proven against an explicit attacker model: PAR plus PKCE replace JAR and s_hash, the response carries only a code and the issuer, and tokens may be bound with DPoP as well as mTLS. Non-repudiation moved to the separate FAPI 2.0 Message Signing profile.

Does FAPI 2.0 require mTLS?

No. FAPI 2.0 requires sender-constrained access tokens and strong client authentication, and offers two ways to do each: mTLS (RFC 8705) or DPoP (RFC 9449) for token binding, and mTLS or private_key_jwt for client authentication. An ecosystem profile usually pins one combination.

Which open banking ecosystems use FAPI?

UK Open Banking, Open Finance Brasil, the Australian Consumer Data Right and Saudi Arabia run FAPI 1.0 Advanced (several with FAPI 2.0 migrations planned); US FDX, UAE Open Finance and ConnectID in Australia adopted FAPI 2.0. EU PSD2 standards such as the Berlin Group do not mandate FAPI but rely on eIDAS certificates.

How do I prove a FAPI implementation is correct?

Run the OpenID Foundation conformance suite against your authorization server or client and self-certify the passing results under the OpenID Certification programme. Certification profiles exist for FAPI 1.0 Advanced, FAPI 2.0 Security Profile, FAPI 2.0 Message Signing and FAPI-CIBA, and most ecosystems require a current certificate before onboarding.