FAPI 2.0 Explained: Financial-Grade API Security Patterns for API Gateways

Financial APIs carry some of the most sensitive data on the internet — account balances, transaction histories, payment instructions, and identity credentials. Standard OAuth 2.0 flows were never designed to protect this level of value. That’s why the OpenID Foundation created the Financial-grade API (FAPI) security profiles, and in 2026, FAPI 2.0 compliance is quickly becoming the baseline expectation for banks, fintechs, insurance companies, and wealth management platforms.

If you’re building or operating APIs in financial services, FAPI 2.0 isn’t optional — it’s the standard your partners, regulators, and auditors will expect you to meet. This guide breaks down what FAPI 2.0 requires, the security mechanisms it mandates, and how your API gateway fits into the compliance picture.

What Is FAPI 2.0?

FAPI 2.0 is an API security profile built on top of OAuth 2.0 (and aligned with OAuth 2.1) that defines the minimum security requirements for APIs handling high-value data. Developed by the OpenID Foundation’s FAPI Working Group, it was originally known as the “Financial-grade API” standard, though the scope has expanded to cover any high-value API scenario — healthcare, government services, and insurance included.

How FAPI 2.0 Differs from FAPI 1.0

FAPI 1.0 worked by layering additional security constraints on top of standard OAuth 2.0 flows. The result was effective but complex, with many optional features that led to inconsistent implementations across different ecosystems.

FAPI 2.0 is a ground-up redesign that simplifies the profile while raising the security bar. Key differences include:

Mandatory sender-constrained tokens — Bearer tokens are no longer acceptable. Every access token must be bound to the client that requested it, using either DPoP or mTLS certificate binding.
Required Pushed Authorization Requests (PAR) — Authorization parameters must be sent directly to the authorization server, not passed through the browser.
Reduced optionality — FAPI 2.0 makes previously optional security features mandatory, ensuring consistent behavior across implementations.
Formal security analysis — The profile has been mathematically proven to meet its stated security goals through formal verification by researchers at the University of Stuttgart.

Who Needs FAPI 2.0?

If your organization falls into any of these categories, FAPI 2.0 is relevant to you:

Banks and credit unions — Especially those subject to open banking mandates
Fintech companies — Payment processors, lending platforms, neobanks
Insurance providers — Health and property/casualty API integrations
Wealth management platforms — Aggregation and portfolio management APIs
Government agencies — Tax, benefits, and identity verification APIs
Healthcare organizations — APIs handling protected health information

Core FAPI 2.0 Security Requirements

FAPI 2.0 mandates several specific security mechanisms. Understanding each one is essential for evaluating whether your API infrastructure can support compliance.

DPoP: Demonstration of Proof-of-Possession

Standard OAuth bearer tokens have a fundamental weakness: anyone who obtains the token can use it. If an attacker intercepts or steals a bearer token, they can replay it to access protected resources.

DPoP (RFC 9449) solves this by binding access tokens to a specific cryptographic key pair held by the client. Here’s how it works:

The client generates a public/private key pair
When requesting a token, the client includes the public key
The authorization server binds the issued token to that public key (via a jkt — JSON Web Key Thumbprint — claim)
On every API call, the client creates a short-lived DPoP proof JWT signed with its private key
The resource server (or API gateway) verifies that the DPoP proof matches the key bound to the access token

If an attacker steals the access token but doesn’t have the private key, the token is useless — the API gateway will reject any request without a valid DPoP proof.

PAR: Pushed Authorization Requests

In a standard OAuth flow, authorization request parameters (scopes, redirect URIs, state) travel through the browser as URL query parameters. This creates several risks: parameters can be tampered with, logged in browser history, or leaked through referrer headers.

PAR (RFC 9126) eliminates these risks by requiring the client to push authorization parameters directly to the authorization server via a back-channel POST request. The server returns a request_uri reference that the client uses in the browser redirect — no sensitive parameters exposed.

PAR also solves practical problems: long authorization URLs can exceed browser or proxy limits, and back-channel submission allows the authorization server to authenticate the client before the authorization flow begins.

JARM: JWT-Secured Authorization Response Mode

Authorization responses typically arrive as plain query parameters or fragments in the redirect URI. JARM (JWT Secured Authorization Response Mode) replaces these with signed (and optionally encrypted) JWTs.

JARM is not required by the base FAPI 2.0 Security Profile — it is mandatory in the separate FAPI 2.0 Message Signing profile, which adds non-repudiation guarantees on top of the baseline. However, many financial ecosystems adopt JARM regardless because the additional integrity protection is valuable for high-stakes transactions.

A JARM response includes:

iss — The authorization server’s issuer URL, preventing mix-up attacks
aud — The intended client, ensuring responses can’t be replayed to different clients
exp — Expiration time, limiting the window for replay attacks

By signing the authorization response, JARM provides integrity protection, sender authentication, and audience restriction — all valuable for financial-grade security.

Client Authentication: private_key_jwt and mTLS

FAPI 2.0 requires strong client authentication. The two approved methods are:

private_key_jwt — The client authenticates to the authorization server by creating a signed JWT assertion using its private key. The server verifies the signature against the client’s registered public key.
mTLS (Mutual TLS) — The client presents a TLS certificate during the connection handshake, and the authorization server validates it against a pre-registered certificate or certificate authority.

Both methods ensure that even if client credentials are exposed, they can’t be used without the corresponding private key or certificate.

What Your API Gateway Must Enforce

Your API gateway sits between clients and your backend services. For FAPI 2.0 compliance, the gateway must enforce several security checks on every request.

Token Validation with Sender Constraint Verification

The gateway must validate incoming access tokens — checking signatures, expiration, issuer, audience, and scopes. But for FAPI 2.0, it must go further: the gateway needs to verify that the request includes a valid DPoP proof matching the token’s bound key, or that the client’s mTLS certificate thumbprint matches the token’s cnf (confirmation) claim.

This is where Zuplo’s JWT authentication policies provide a foundation. The built-in OpenID JWT Auth policy validates token signatures, expiration, issuer, and audience claims out of the box. For the FAPI-specific sender constraint verification (like DPoP proof validation), Zuplo’s programmable policy pipeline lets you add custom TypeScript logic that runs inline with built-in policies:

typescript

import { ZuploContext, ZuploRequest } from "@zuplo/runtime";

export default async function validateDpopProof(
  request: ZuploRequest,
  context: ZuploContext,
) {
  const dpopHeader = request.headers.get("DPoP");
  if (!dpopHeader) {
    return new Response(JSON.stringify({ error: "missing_dpop_proof" }), {
      status: 401,
      headers: { "Content-Type": "application/json" },
    });
  }

  // Decode and verify the DPoP proof JWT
  // Check that the 'htm' claim matches the HTTP method
  // Check that the 'htu' claim matches the request URL
  // Verify the proof signature against the public key in the JWT header
  // Confirm the key thumbprint matches the token's 'jkt' claim

  return request;
}

Scope Enforcement

FAPI 2.0 requires proper scope management — clients should only access resources within their granted scopes. Zuplo’s JWT Scope Validation policy handles this declaratively:

json

{
  "name": "fapi-scope-check",
  "policyType": "jwt-scopes-inbound",
  "handler": {
    "export": "JWTScopeValidationInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "scopes": ["accounts:read", "transactions:read"]
    }
  }
}

mTLS Client Authentication

For APIs that use certificate-based client authentication, Zuplo provides an mTLS Auth policy that authenticates incoming requests based on client certificates. The gateway validates the certificate, checks expiration and revocation status, and populates the request’s user context with the certificate’s distinguished name. Note that mTLS authentication is available as part of Zuplo’s enterprise plans.

For outbound connections to backend services, Zuplo also supports mTLS for upstream requests — ensuring mutual authentication in both directions.

Request Validation

Financial APIs must validate every incoming request against a strict schema. Malformed requests should never reach your backend. Zuplo’s Request Validation policy validates request bodies, query parameters, path parameters, and headers against your OpenAPI specification automatically.

Rate Limiting and Abuse Prevention

Financial APIs are high-value targets for abuse. The Zuplo Rate Limiting policy lets you set granular limits based on user identity, API key, IP address, or custom attributes — protecting your services from both intentional attacks and accidental overload.

Regulatory Drivers

Several regulations are pushing FAPI 2.0 adoption and making financial-grade API security non-negotiable.

Section 1033: Consumer Financial Data Rights (US)

The CFPB’s Section 1033 rule requires covered financial institutions to make consumer data available to authorized third parties through APIs. The largest institutions face compliance deadlines starting in 2026, with smaller institutions phased in through 2030. While the rule is currently subject to litigation and reconsideration, the direction is clear: consumer-authorized data sharing through secure APIs is coming.

Open Banking (UK and EU)

The UK’s Open Banking framework and the EU’s Payment Services Directive 2 (PSD2) have required banks to expose account and payment APIs to authorized third parties since 2018. The UK Open Banking Security Profile is based on FAPI 1.0 Advanced, and the ecosystem is expected to migrate to FAPI 2.0 as the standard matures.

Consumer Data Right (Australia)

Australia’s CDR framework mandates FAPI-compliant API security for data sharing across banking (already live), energy, and telecommunications. The Australian standard references FAPI 1.0 Advanced and is expected to evolve toward FAPI 2.0 as the specification gains broader adoption.

FDX Standards (North America)

The Financial Data Exchange (FDX) develops interoperability standards for consumer-authorized financial data sharing in the US and Canada. FDX standards align closely with FAPI security requirements and are widely adopted by major financial institutions.

What This Means for Your API Infrastructure

Across all these regulations, the requirements converge on the same set of technical capabilities:

Strong client authentication (mTLS or private_key_jwt)
Sender-constrained access tokens (DPoP or certificate-bound)
Secure authorization flows (PAR, and JARM where non-repudiation is required)
Comprehensive audit logging
Granular consent and scope management

If your API gateway can enforce these patterns, you have a foundation that works across multiple regulatory jurisdictions.

Implementing Financial-Grade API Security with Zuplo

Building FAPI 2.0 compliance into your API infrastructure doesn’t mean starting from scratch. A programmable API gateway lets you layer financial-grade security on top of your existing APIs.

Why a Programmable Gateway Matters

FAPI 2.0 requirements are complex and still evolving. Standards bodies update specifications, regulators add requirements, and your specific implementation needs will differ from generic templates. A gateway that locks you into XML or YAML-based policy configuration will struggle to keep up.

With Zuplo’s TypeScript-native policy engine, you write security logic in a language your team already knows. Need to validate a DPoP proof? Parse a signed request object? Implement custom consent checking? It’s just TypeScript — no proprietary DSLs, no vendor lock-in.

Composable Policy Pipeline

Zuplo’s policy pipeline lets you chain multiple security checks together, each one handling a specific FAPI concern:

mTLS Auth policy — Validate client certificate on connection
JWT Auth policy — Validate and decode the access token
Custom DPoP validation policy — Verify proof-of-possession
JWT Scope Validation policy — Enforce authorized scopes
Request Validation policy — Validate request body against OpenAPI schema
Rate Limiting policy — Protect against abuse

Each policy runs in sequence. If any check fails, the request is rejected immediately — before it ever reaches your backend.

Edge-Native Security

Financial services demand low latency and high availability. Zuplo deploys to over 300 edge locations globally, which means your FAPI security policies execute close to your users — not in a single-region deployment that adds round-trip latency. For financial institutions with global operations or multi-region redundancy requirements, edge-native deployment is a significant advantage.

Audit Trail and Observability

FAPI 2.0 compliance requires demonstrable proof that security controls are in place and functioning. Zuplo integrates with logging and analytics providers, giving you the audit trail regulators expect — every request authenticated, every policy decision logged, every anomaly flagged.

Getting Started

Financial-grade API security is a journey, not a switch you flip. Here’s a practical path:

Audit your current API security — Identify which of the FAPI 2.0 requirements you already meet (JWT validation, TLS enforcement) and which you don’t (DPoP, PAR, JARM)
Upgrade your authorization server — Your identity provider needs to support FAPI 2.0 features. Check whether your current provider (Auth0, Okta, Azure AD, etc.) offers FAPI 2.0 compliance
Configure your API gateway — Set up token validation, scope enforcement, mTLS, and custom policies for sender-constrained token verification
Validate request schemas — Define strict OpenAPI schemas for all financial API endpoints and enforce them at the gateway
Implement rate limiting — Protect financial APIs with user-aware rate limiting that aligns with your SLA commitments
Test and certify — The OpenID Foundation provides FAPI conformance testing tools to validate your implementation

Financial-grade API security shouldn’t require enterprise-grade complexity. With a programmable API gateway like Zuplo, you get the flexibility to implement FAPI 2.0 patterns using standard TypeScript — no specialized middleware, no vendor-specific markup languages. Get started with Zuplo and start building APIs that meet the security bar financial services demands.