

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.
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.

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:
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.
Regulators prioritize outcomes like security, interoperability, and accountability, and FAPI aligns with these.
FAPI is now the default security profile in open banking and finance, making it a vital piece for modern Open Banking APIs.
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.
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 leads in FAPI adoption.
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.
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.
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.
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?
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:
Implementing all this in a bespoke server is costly, error-prone, and hard to update.
Backend services like Authlete are the answer.
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.
This allows you to become FAPI 1.0 or 2.0 compliant without re-architecting your entire infrastructure.

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.
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.
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 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.
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.