April 29, 2026

Open Banking’s Security Standard Is Here: Global FAPI Adoption Is Accelerating

Why regulators are requiring FAPI for open banking and how to securely and quickly implement FAPI

Open banking is gaining momentum and becoming a global movement. Since the UK launched the world’s first open banking system in 2018, dozens of countries have followed, building national frameworks that allow consumers to securely share financial data with trusted third parties. What began as a regional initiative has become a worldwide shift in how financial APIs are designed, regulated, and secured.

As these ecosystems mature, a clear pattern has emerged: an increasing number of regulators and industry bodies are mandating or formally recommending a common security baseline for open banking APIs. That baseline is FAPI (formerly Financial-grade API). Across established and emerging markets alike, FAPI adoption is accelerating as the preferred approach to ensure interoperability, auditability, and strong security at scale.

This shift exposes a hard truth for engineers: standard OAuth 2.0, by itself, is no longer sufficient for modern finance. While OAuth powered the early web, its flexibility becomes a liability in regulated ecosystems. In the first wave of open banking, banks and FinTechs filled the gaps with custom OAuth profiles, often creating a fragmented, brittle landscape that was expensive to audit and difficult to extend across borders.

The industry’s answer is FAPI. Built on OAuth 2.0 and OpenID Connect, FAPI assumes a hostile network environment and replaces optional security measures with mandatory ones. Requirements like sender-constrained tokens, Pushed Authorization Requests (PAR, RFC 9126), and verifiable consent are no longer “best practices” but are enforced by design. The result is a security profile that regulators can trust, and developers can implement consistently.

This article explores why FAPI has become the global standard for open banking security, why developers need to understand it now, and how it can be implemented without rebuilding your entire identity stack.

The Role of FAPI in Modern Open Banking

What is FAPI?

FAPI is a set of security profiles developed by the OpenID Foundation for secure access to high-value data in hostile environments. It hardens OAuth 2.0 and OpenID Connect (OIDC) to protect high-value APIs against attacks like token theft, replay, and authorization code interception. There are two major generations of FAPI: FAPI 1.0 and FAPI 2.0.

FAPI 1.0 is the original, mature standard that sets a strict security baseline for open banking. It requires strong client authentication, sender-constrained tokens, request integrity, and explicit consent. It addresses OAuth attack patterns such as authorization code interception, front-channel token leakage, and replay of captured authorization requests or access tokens, i.e., common attacks that OAuth profiles leave largely optional to mitigate.

FAPI 2.0 is the next generation. It simplifies implementation, consolidates profiles, clarifies attacker models, and aligns with modern extensions like Pushed Authorization Requests (PAR, RFC 9126) and Demonstrating Proof of Possession (DPoP, RFC 9449), aiming to make correct, certified implementations easier without weakening security. This is the version we’ll focus on in this article.

Why "Just OAuth" Isn't Enough

Standard OAuth 2.0 is flexible, but in regulated finance, flexibility is a liability. Without strict profiling, crucial security controls like Proof Key for Code Exchange (PKCE, RFC 7636), client authentication, and token binding remain optional, leading to implementations that vary wildly and are difficult to scale. 

FAPI 2.0 is not merely "more OAuth." It is a hardened profile that transforms these optional controls into standards.

FAPI enforces:

  • Strong client authentication via a Private Key JWT or mutual TLS (mTLS), ensuring that only vetted clients can access sensitive endpoints. 
  • Request integrity by using Pushed Authorization Requests (PAR), which protect against tampering, as outlined in RFC 9126. 
  • Sender-constrained tokens that are cryptographically bound to the client with mTLS or DPoP, preventing reuse if stolen. 

By standardizing these requirements, FAPI creates a clear, auditable framework that supports rigorous conformance testing via OpenID test suites. These features shift financial APIs from best-effort to verifiable security.

Why regulators trust FAPI

Regulators prioritize outcomes like security, interoperability, and accountability, and FAPI aligns with these. 

  • It's threat-model driven, with explicit attacker assumptions reviewed globally, giving regulators confidence in its risk management. 
  • It’s testable via conformance programs, replacing self-attestation with objective proof. FAPI is technically portable across diverse legal frameworks like the UK, Australia, and  Brazil, reducing costs and barriers. 

FAPI is now the default security profile in open banking and finance, making it a vital piece for modern Open Banking APIs.

The Global Shift to FAPI

A key signal that FAPI is here to stay is the convergence of global markets. Despite different legal frameworks, diverse regions are independently standardizing on the same technical profiles.

This convergence reduces fragmentation for developers, enabling cross-market systems without re-architecting security.

North America: From custom OAuth to standardized FAPI

Historically, open banking in the US relied on customized OAuth 2.0 profiles tailored to local needs. But they lacked a shared attacker model or conformance framework. 

This is changing. The Financial Data Exchange (FDX) has incorporated FAPI security into the FDX API 6.0. This "Blue Profile" is a rigorous security schema closely aligned with FAPI principles. The FDX is a North American, industry-led standards body whose members, including several major Canadian banks, collaborate on interoperable APIs and security profiles for open banking and financial data sharing.

This is a milestone for US implementers, signaling FAPI's move from “recommended” to foundational. The industry is coalescing around these FAPI-based controls. For developers, this means the era of proprietary bank APIs is ending; standardized, FAPI-grade security is the future.

Canada has not yet formally adopted FAPI as part of its open banking framework, which remains under active development. However, the emerging requirements around consent, authorization, and secure data sharing mirror the same problems FAPI was designed to solve. As Canada finalizes its technical standards, alignment with FAPI-based profiles would reduce fragmentation and ease cross-border interoperability.

Latin America: Leading the world in mandated FAPI adoption

Latin America leads in FAPI adoption. 

  • Brazil is a prime example, where its Open Finance ecosystem mandates FAPI and operates FAPI-compliant servers at scale, like Nubank using Authlete. Brazil adopted FAPI in 2021 for its Open Banking system, which has evolved into Open Finance.
  • Chile is expected to require FAPI 2.0 from launch, with strong industry interest. 
  • Colombia, still early, recognizes FAPI 2.0 as the standard for bank and third-party communication, indicating a clear movement toward FAPI-aligned Open Finance.

Middle East: Designing for FAPI-first interoperability

Several Middle Eastern countries, such as Bahrain, Saudi Arabia, and the United Arab Emirates, are notable for actively applying FAPI to their open finance programs. 

  • Bahrain’s Central Bank bases its Open Banking API security on the OpenID Foundation’s FAPI profile, emphasizing authentication, authorization, encryption, and consent, with external certification preferred to ensure a secure ecosystem. 
  • The UAE’s security profile is even more directly linked to FAPI 2.0, requiring sender-constrained tokens, client authentication, short-lived access tokens, and signed request objects to enhance interoperability and reduce optionality. 
  • The Saudi Central Bank (SAMA) requires rigorous certification, driving banks to adopt FAPI-compliant architectures to meet the KSA Open Banking Framework.
  • Oman’s Central Bank (CBO) integrates FAPI security profiles into its regulatory framework for open banking, mandating secure, API-driven interoperable data sharing between banks and fintechs.

For cross-region platform developers, Latin America and the Middle East show that FAPI is increasingly the standard choice for robust security, interoperability, and scalable certification from the start.

Early Adopters: The UK and Australia

The UK pioneered large-scale open banking, shaping global API security standards. In 2018, the UK launched the first national open banking system, followed by Australia’s Consumer Data Right (CDR) in 2020. Both adopted FAPI 1.0 for security, setting high standards for authentication, consent, and token protection. Although neither has mandated FAPI 2.0, their ongoing deployments show FAPI-based security works at a national level. These examples demonstrate FAPI’s effectiveness, encouraging newer ecosystems to adopt FAPI directly, often starting with FAPI 2.0. For developers, the UK and Australia prove that financial-grade API security is both interoperable and sustainable.

Why this global view matters to developers

These regional efforts show a clear trend: new open banking ecosystems launch on FAPI 2.0, and industry groups in fragmented markets standardize around the same profiles. 

For developers, FAPI is the universal security language in open banking. Building with FAPI reduces future rework, simplifies certification, and eases support for multiple markets as open finance expands. 

With FAPI as the baseline, the focus shifts from regulation to the how: How can teams implement FAPI accurately while maintaining architectural flexibility?

How Authlete Simplifies FAPI Implementation

As ecosystems converge on FAPI, the challenge moves from “What security should I build?” to “How do I implement FAPI correctly?” 

Building a FAPI-compliant authorization server from scratch is non-trivial. You need to handle:

  • Complex state management for JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) and PAR.
  • Sender-constrained access tokens with mTLS/DPoP.               
  • Signature validation for Private Key JWTs.
  • Strict adherence to the FAPI 2.0 Attacker Model.

Implementing all this in a bespoke server is costly, error-prone, and hard to update. 

Backend services like Authlete are the answer.

Delegate Complexity, Keep Control

Authlete offers a unique answer: Don't replace your identity provider; upgrade it.

Authlete provides a "headless" OAuth 2.0 and OpenID Connect engine. Instead of forcing you to migrate users to a new monolithic Identity Provider (IdP), Authlete operates as a set of APIs that your existing backend or API gateway calls.

  1. Your System handles user authentication and consent screens.
  2. Authlete handles the protocol heavy-lifting: validating FAPI requests, issuing sender-constrained tokens, and ensuring every authorization and token exchange occurs in a compliant, specification-defined order.

This allows you to become FAPI 1.0 or 2.0 compliant without re-architecting your entire infrastructure.

Authlete is for conformance and regulation-driven ecosystems

A key feature of FAPI adoption globally is the increased emphasis on certification and conformance. Regulators and ecosystem operators now expect objective, testable proof of compliance implementations. This shift reflects the reality that financial-grade security must be demonstrable, repeatable, and independently verifiable.

Authlete aligns directly with the OpenID Foundation conformance program and has achieved certification across multiple profiles, including FAPI 1.0 (Advanced profile), the FAPI 2.0 Security Profile (Final), and Client-Initiated Backchannel Authentication (CIBA). This alignment is critical in regions where certification is mandatory or strongly encouraged, such as Brazil, Australia, the UK, and Saudi Arabia, as well as in emerging ecosystems like Chile and Colombia, and in North America via FDX. By relying on a certification-proven platform, teams reduce the risk of late-stage compliance failures and avoid costly rework when regulatory scrutiny increases.

Authlete also tracks specification updates, including the transition from FAPI 1.0 to 2.0, protecting ecosystems from subtle changes and legacy shortcuts, especially for those launching on FAPI 2.0.

Authlete is Production Proven

This architecture is production-proven. Nubank, one of the world's largest digital banking platforms, used Authlete to build their FAPI-compliant authorization server for Brazil Open Finance

Amid tight timelines and complex security needs, Nubank used Authlete to meet the Central Bank’s FAPI standards without sacrificing its architecture or speed. After successful implementation, Nubank expanded the same infrastructure to secure services like NuPay. 

With Authlete, FAPI compliance was not just a regulatory hurdle for Nubank, but a foundation for future products.

Why this matters for emerging and converging markets

Authlete’s API-driven model allows early adoption of financial-grade security, passing conformance, and staying adaptable as regulations evolve. 

Rather than rebuilding authorization logic per jurisdiction, developers can rely on a common FAPI foundation, adjusting only ecosystem-specific rules and data schemas.

This shifts FAPI from a blocker to an enabler of expansion. Teams can support multiple regions with consistent security, confident that their authorization aligns with the OpenID Foundation's standards.

FAPI is Accelerating

FAPI has evolved from a niche open banking profile to the global standard for secure APIs. Its rigorous requirements are why regulators and industry trust it. 

For developers, the risk of being left behind is real. FAPI is gaining momentum and is now the new interoperability language rather than an edge case. 

Next Steps

If you are looking to implement FAPI 1.0 or 2.0 without disrupting your current architecture, Authlete can help. 

Try Authlete for free. Sign up here.