FAPI

FAPI (Financial-grade API) is a family of security profiles from the OpenID Foundation that tighten OAuth 2.0 and OpenID Connect for APIs where a compromised token means real financial or personal harm. Base OAuth leaves too many choices open for high-stakes use, so FAPI removes the loose options and mandates the strong ones — sender-constrained tokens, strong client authentication, and message-level protections — turning “authorization framework” into an interoperable, bank-grade security bar.

• Sender-constrained tokens - Access tokens are bound to the client via mTLS or DPoP, so a stolen token is useless to anyone else.
• Strong client authentication - Private-key JWT or mutual TLS replaces shared client secrets, raising the floor on who can call the API.
• Hardened OAuth flows - Authorization code with PKCE, PAR (Pushed Authorization Requests), and JARM close the redirect and request-tampering gaps in vanilla OAuth.
• Two evolving profiles - FAPI 1.0 (Baseline and Advanced) is the widely-mandated generation; FAPI 2.0 simplifies and strengthens it around a clear attacker model.
• The open-banking default - It is the security layer that regulators and ecosystems point to when they need “secure enough to move money.”

In real API operations, FAPI is the auth floor beneath the open-banking and open-finance rails — it is what FDX implementations, PSD2 SCA obligations, and national schemes like Australia’s Consumer Data Right lean on so that fifty different banks expose the same strong security contract. When a provider claims financial-grade security, FAPI conformance is the machine-checkable proof, and it increasingly frames how agentic clients are allowed to hold and present tokens against sensitive APIs. For anyone governing high-risk APIs, adopting a FAPI profile is the shortest path from “we use OAuth” to “our tokens can survive a hostile network.”