---
title: "FAPI 2.0 Explained: Financial-Grade API Security Patterns for API Gateways"
description: "Learn what FAPI 2.0 requires, how DPoP, PAR, and JARM secure financial APIs, and what your API gateway needs to enforce compliance across open banking regulations."
canonicalUrl: "https://zuplo.com/learning-center/fapi-2-financial-grade-api-security-patterns"
pageType: "learning-center"
authors: "nate"
tags: "API Authentication"
image: "https://zuplo.com/og?text=FAPI%202.0%20Explained%3A%20Financial-Grade%20API%20Security%20Patterns"
---
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](https://openid.net/wg/fapi/), 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)](https://datatracker.ietf.org/doc/html/rfc9449) solves this by
binding access tokens to a specific cryptographic key pair held by the client.
Here's how it works:

1. The client generates a public/private key pair
2. When requesting a token, the client includes the public key
3. The authorization server binds the issued token to that public key (via a
   `jkt` — JSON Web Key Thumbprint — claim)
4. On every API call, the client creates a short-lived DPoP proof JWT signed
   with its private key
5. 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)](https://datatracker.ietf.org/doc/html/rfc9126) 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](https://openid.net/specs/oauth-v2-jarm-final.html))
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](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound)
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](https://zuplo.com/docs/articles/policies)
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](https://zuplo.com/docs/policies/jwt-scopes-inbound)
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](https://zuplo.com/docs/policies/mtls-auth-inbound) 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](https://zuplo.com/docs/articles/securing-backend-mtls)
— 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](https://zuplo.com/docs/policies/request-validation-inbound)
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](https://zuplo.com/docs/policies/rate-limit-inbound)
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](https://www.consumerfinance.gov/personal-financial-data-rights/)
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](https://www.consumerfinance.gov/rules-policy/rules-under-development/personal-financial-data-rights-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](https://financialdataexchange.org/) (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:

1. **mTLS Auth policy** — Validate client certificate on connection
2. **JWT Auth policy** — Validate and decode the access token
3. **Custom DPoP validation policy** — Verify proof-of-possession
4. **JWT Scope Validation policy** — Enforce authorized scopes
5. **Request Validation policy** — Validate request body against OpenAPI schema
6. **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](https://zuplo.com/docs/managed-edge/overview),
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:

1. **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)
2. **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
3. **Configure your API gateway** — Set up token validation, scope enforcement,
   mTLS, and custom policies for sender-constrained token verification
4. **Validate request schemas** — Define strict OpenAPI schemas for all
   financial API endpoints and enforce them at the gateway
5. **Implement rate limiting** — Protect financial APIs with user-aware rate
   limiting that aligns with your SLA commitments
6. **Test and certify** — The OpenID Foundation provides
   [FAPI conformance testing tools](https://openid.net/certification/) 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](https://portal.zuplo.com) and start building APIs that
meet the security bar financial services demands.

## Further Reading

- [API Strategy Guide for Financial Services Companies](/learning-center/api-strategies-for-financial-companies)
- [How to Secure API Endpoints in Banking Applications](/learning-center/how-to-secure-api-endpoints-banking-applications)
- [API Gateway Security and Compliance: A Buyer's Checklist](/learning-center/api-gateway-security-compliance)
- [Zero Trust API Security: Never Trust, Always Protect](/learning-center/zero-trust-api-security)
- [JWT API Authentication Guide](/learning-center/jwt-api-authentication)
- [Custom Scopes in OAuth: Step-by-Step Guide](/learning-center/custom-scopes-in-oauth-guide)