Knowing who's calling an API used to be enough. In financial systems, it isn't anymore — what's needed instead is confidence that a specific action is tied to the legitimate client, the legitimate user, and the exact context it was actually approved in. That shift, from authenticating a caller to binding a transaction, is the throughline connecting most of what the Financial-grade API (FAPI) profiles actually require.
Traditional API security starts simple: authenticate the client, issue a token, let the client call the API with that token. For a huge share of applications, that's genuinely sufficient — reading a public feed or updating a user's display name doesn't need much more than proof that a legitimate, recognized client is making the request.
A bank transfer isn't that kind of request. A payment isn't just an HTTP call with a JSON body attached, and a customer identity change isn't a routine field update — each is a high-impact, often irreversible action, and "the client that called this endpoint was authenticated at some point" doesn't actually answer the question that matters: was this specific action legitimately authorized, by the right user, in the right context, right now?
The first piece of this shift replaces a shared secret with cryptographic proof of client ownership. Instead of a client_secret both sides hold, the client signs a JWT with a private key only it possesses, and the authorization server verifies that signature against the client's registered public key. The server isn't trusting a password anyone with access to a config file could copy — it's verifying that whoever's making this specific request actually controls the private key tied to this specific client's registered identity.
Mutual TLS pushes proof-of-possession down a layer, binding identity to the TLS connection itself rather than to an individual signed token. The client presents a certificate; the server verifies its validity, its ownership, and its chain of trust, and the resulting connection is cryptographically tied to that authenticated client for its duration. RFC 8705 formalizes this for OAuth specifically — certificate-bound access tokens that a resource server can confirm were actually issued to, and are being presented by, the same client that established the mTLS connection. It's a natural fit for bank-to-bank integrations and other controlled enterprise environments where certificate infrastructure is already part of how systems talk to each other.
DPoP (RFC 9449) takes the same underlying idea — prove possession of a key, not just presentation of a credential — and applies it per HTTP request. The client attaches a signed proof to each call, covering the method, the URI, a timestamp, and a hash of the access token itself, all signed with a private key bound to that token at issuance. A stolen token, on its own, is worthless to an attacker who doesn't also hold the key that has to sign every request made with it.
This is where FAPI's shift becomes most explicit, and it's the piece easy to miss if the story stops at "who's the client." Client authentication and proof-of-possession answer who's calling. They say nothing about what, exactly, was approved. Traditional OAuth scopes are coarse — "payments:write" authorizes payment-initiation in general, but says nothing about which account, which amount, or which recipient a user actually consented to.
RFC 9396, Rich Authorization Requests (RAR), closes exactly that gap. It introduces a structured authorization_details parameter that lets a client specify precisely what's being authorized — a payment of a specific amount, to a specific account, in a specific currency — as part of the authorization request itself, rather than relying on a generic scope string. A payment request under RAR isn't "this client has payment-initiation access." It's "this exact transaction, for this exact amount, to this exact recipient, is what the user is being asked to approve," and the token that's ultimately issued carries that specific detail rather than a broad grant that happens to cover it. That's the mechanism that actually lets a system claim it's binding the transaction to the client — not just the session, and not just the connection.
The remaining piece is making sure a human, specifically the right human, actually approved the action — which is where flows like Client-Initiated Backchannel Authentication earn their place in financial contexts. A customer approving a payment isn't just accessing an API endpoint. They're authorizing an irreversible business action, on a device the bank already recognizes as theirs, and a push-based approval model built on the same possession-based logic as the rest of this stack — approve this specific transfer, on this specific registered device, right now — closes the last gap between "a valid token was presented" and "the actual account holder said yes to this specific thing."
Private Key JWT proves client ownership. mTLS proves connection identity. DPoP proves possession of the signing key on every request. RAR proves the specifics of what's actually being authorized, not just that authorization exists in some general sense. CIBA strengthens the link between the approval and the actual human behind it. None of these mechanisms exist in isolation — together, they move financial APIs away from a single upfront credential check and toward continuous, specific, cryptographic proof that a particular client, a particular user, and a particular transaction genuinely belong together.
For high-value systems, authenticating the client was never the finish line — it was the floor. The real target is trusted authorization: not just confidence that a recognized caller is on the other end of a request, but confidence that this specific action, at this specific moment, for this specific amount, was legitimately approved by the person it claims to represent. That's a meaningfully higher bar than "did we check the token," and it's exactly the bar FAPI was built to enforce.
Your Secure APIs May Need More Than Bearer Tokens
If possession of a stolen token is enough to access your API, the token has become the password. DPoP, mTLS, and why proof-of-possession asks a fundamentally different question than a bearer token ever could.
Clean Architecture or Not? Why the Real Question Is Autonomy and Pragmatism
Popularized by Robert C. Martin, Clean Architecture divides opinion for good reason. On the Big Ball of Mud, Vertical Slice Architecture, and why the real question is autonomy paired with pragmatism.