FAPI 2.0
The OpenID Foundation’s high-security OAuth profile for financial APIs.
FAPI 2.0 is the OpenID Foundation’s security profile for financial-grade APIs: a set of rules on top of OAuth 2.0 for APIs that carry high-value data such as bank accounts and payments. It requires the authorization code flow with PKCE (S256), pushed authorization requests (PAR), confidential clients only, and access tokens bound to the client by mutual TLS or DPoP.
The FAPI 2.0 Security Profile was published as a final specification on 22 February 2025. It succeeds FAPI 1.0 Advanced, the profile behind several open-banking ecosystems, and was written to be simpler to implement while defending against the same attacks, with a formal attacker model behind it. A separate FAPI 2.0 Message Signing specification adds signed requests and responses where non-repudiation is needed.
Worked example
In a FAPI 2.0 flow the client first posts its authorization request to the server’s PAR endpoint and receives a short-lived request_uri. It sends the user to the authorization endpoint with only that request_uri, exchanges the returned code with its PKCE verifier and a DPoP proof or over mutual TLS, and presents the same binding on every API call.
Common mistake
Treating PKCE alone as FAPI. PKCE protects the authorization code, but FAPI 2.0 also requires PAR, confidential clients and sender-constrained tokens, so a public client holding plain bearer tokens sits outside the profile however strong its PKCE.
Grounded in OpenID Foundation — FAPI 2.0 Security Profile guidance. Figures last checked . General information, not tax advice.
Related terms
DPoP (Demonstrating Proof of Possession)
An OAuth method that binds a token to a key the client holds.
Pushed authorization request (PAR)
Sending OAuth request parameters to the server directly, not through the browser.
Open banking connector
Software that moves bank transaction data between systems on published standards.
ISO 20022
The international standard for financial messages — payments, statements and more.
← Back to the full glossary.
Questions about this term
FAPI 2.0: common questions
- What is the difference between FAPI 1.0 and FAPI 2.0?
- FAPI 1.0 Advanced relied on signed request objects and a hybrid flow in which the ID token doubled as a detached signature. FAPI 2.0 moves the request into a pushed authorization request, uses the plain authorization code flow with PKCE, and requires sender-constrained tokens, which makes it simpler to implement correctly.
- Does FAPI 2.0 require mutual TLS?
- Not on its own. FAPI 2.0 requires sender-constrained access tokens, and a server can meet that with mutual TLS certificate-bound tokens or with DPoP. Client authentication likewise uses either mutual TLS or a signed JWT assertion (private_key_jwt).
- Who is FAPI 2.0 written for?
- Any API that protects high-value data and wants a profile analysed against a formal attacker model. Open-banking and open-finance ecosystems, banks exposing their own APIs and the fintechs calling them are its main audience, and the OpenID Foundation runs conformance tests for implementations.
Let Fin handle the jargon for you
Connect your bank and Fin sorts your income, expenses and GST automatically — so terms like this just become numbers that are already worked out. Free to start, no card needed.
Get 2Fin free →
