INTRODUCTION

You have now mastered the five dominant open banking frameworks:

1. PSD2 (EU) — Legislative mandate, payment accounts only

2. UK CMA Order 2017 — Competition law mandate, world’s first API standard

3. CDR (Australia) — Consumer rights mandate, economy-wide

4. FDX (US/Canada) — Industry-led consortium, >130M accounts

5. Brazil Open Finance — BCB mandate, >30M consents, Pix integration

Each framework emerged from a distinct regulatory philosophy. The EU legislated from the top down (Directive). The UK used competition law to force market change (CMA Order). Australia grounded its framework in consumer property rights (Treasury Laws Amendment Act). The US let industry build the standard (FDX consortium). Brazil used central bank authority to mandate the broadest-scope framework globally.

This lesson synthesises these frameworks into a comprehensive comparative analysis—identifying common patterns, critical differences, and the architectural decisions required for multi-jurisdictional deployment. You will learn how to design a single API layer that satisfies the most stringent requirements across all frameworks while maintaining the flexibility to accommodate the least stringent.

LEARNING OBJECTIVES

Upon completing this lesson, you will be able to:

1. Compare the five frameworks across twelve dimensions—regulatory basis, scope, security profile, consent model, consent revocation SLA, API throughput, write access, authentication methods, certificate standards, active users, penalties, and future trajectory.

2. Identify the five universal requirements that emerge across all frameworks—secure API access, explicit consent, consent revocation, non-discrimination, and audit logging.

3. Design a multi-jurisdictional reference architecture that satisfies the most stringent requirements (FAPI 1.0 Advanced, mTLS, 25 RPS, ≤2-hour consent revocation) while maintaining compatibility with the least stringent (FDX’s optional FAPI).

4. Calculate the compliance burden differential—quantifying the engineering effort required for each framework using a standardised “compliance unit” metric.

5. Articulate the forward-looking convergence—the global movement toward FAPI 2.0, the expansion from open banking to open finance, and the role of international standards bodies in reducing fragmentation.

PART 1: COMPREHENSIVE FRAMEWORK COMPARISON MATRIX

1.1 Twelve-Dimension Comparison

PART 2: THE FIVE UNIVERSAL REQUIREMENTS

Despite their differences, all five frameworks share five universal requirements that form the foundation of any open banking implementation:

2.1 Universal Requirement 1 — Secure API Access

• OAuth 2.0 with PKCE is mandatory in all frameworks

• mTLS is mandatory in four of five frameworks (exception: FDX recommends but does not mandate)

• FAPI (or equivalent) is mandatory in UK, Brazil, and Australia; recommended in PSD2; optional in FDX

2.2 Universal Requirement 2 — Explicit Consent

• The PSU must explicitly grant permission for each data access or payment

• Consent must be granular—the PSU chooses which data fields and for how long

• Consent must be revocable at any time

2.3 Universal Requirement 3 — Consent Revocation

• The PSU must be able to withdraw consent through a clearly accessible mechanism

• Revocation must propagate to all downstream systems within a defined SLA (ranging from ≤15 minutes in EU/UK to ≤24 hours in Brazil)

2.4 Universal Requirement 4 — Non-Discrimination

• TPPs must receive the same SLA, SCA policy, and rate limits as the bank’s own channel

• This is explicitly codified in PSD2 Article 67(3)(b) and implicitly required in all frameworks

2.5 Universal Requirement 5 — Audit Logging

• All consent events, API calls, and data accesses must be logged

• Logs must be tamper-evident and retained for regulatory inspection (typically 5-7 years)

PART 3: MULTI-JURISDICTIONAL REFERENCE ARCHITECTURE

3.1 Design Principles

To operate across multiple jurisdictions with minimal re-engineering, the certified practitioner must follow these principles:

1. Implement the most stringent security profile — FAPI 1.0 Advanced with mTLS satisfies UK, Brazil, and CDR requirements

2. Support granular consent — Per-account, per-field consent satisfies CDR’s most granular model

3. Implement consent revocation with ≤2 hours — Satisfies the most stringent SLA (CDR)

4. Support 25 RPS per client — Satisfies UK and CDR throughput requirements

5. Design for sector expansion — Use extensible data models to accommodate energy, telecom, and insurance data

3.2 The Multi-Jurisdictional API Stack

+-----------------------------------------------------------------------+
|           MULTI-JURISDICTIONAL OPEN BANKING REFERENCE ARCHITECTURE     |
+-----------------------------------------------------------------------+
|                                                                        |
|  +------------------------------------------------------------------+  |
|  |                    API GATEWAY LAYER                              |  |
|  |  • Rate limiting: 25 RPS per client (UK, CDR)                    |  |
|  |  • mTLS termination (UK, CDR, Brazil)                           |  |
|  |  • ICP-Brasil / eIDAS QWAC / ACCC certificate support           |  |
|  |  • Request validation (OpenAPI 3.1)                              |  |
|  +------------------------------------------------------------------+  |
|                                    |                                   |
|  +------------------------------------------------------------------+  |
|  |                    SECURITY LAYER                                |  |
|  |  • OAuth 2.0 with PKCE (all frameworks)                          |  |
|  |  • FAPI 1.0 Advanced (UK, Brazil) / FAPI-BR (Brazil)[reference:109]  |  |
|  |  • PAR + JARM (Brazil mandatory)[reference:110]                    |  |
|  |  • JWT validation (nbf ≤90s, exp ≤120s)                          |  |
|  +------------------------------------------------------------------+  |
|                                    |                                   |
|  +------------------------------------------------------------------+  |
|  |                    CONSENT LAYER                                 |  |
|  |  • Consent grant (per-account, per-field, per-category)          |  |
|  |  • Consent revocation (≤2 hours for CDR, ≤24h for Brazil)       |  |
|  |  • Consent expiry (90 days UK, 12 months Brazil, perpetual FDX) |  |
|  |  • Consent API: /consents/v3 (Brazil)[reference:111]                |  |
|  +------------------------------------------------------------------+  |
|                                    |                                   |
|  +------------------------------------------------------------------+  |
|  |                    RESOURCE LAYER                                |  |
|  |  • /accounts (account information)                               |  |
|  |  • /transactions (transaction history)                           |  |
|  |  • /payments (payment initiation — PISP, Pix[reference:112])        |  |
|  |  • /consents (consent management)                                |  |
|  |  • /vrp (Variable Recurring Payments — UK only)                  |  |
|  +------------------------------------------------------------------+  |
|                                    |                                   |
|  +------------------------------------------------------------------+  |
|  |                    DATA LAYER                                   |  |
|  |  • Extensible data models (JSON with optional fields)            |  |
|  |  • ISO 20022 mapping                                             |  |
|  |  • Multi-sector readiness (banking, energy, telecom, insurance)  |  |
|  |  • Pix integration support (Brazil)[reference:113]                 |  |
|  +------------------------------------------------------------------+  |
+-----------------------------------------------------------------------+

3.3 Compliance Burden Differential

PART 4: THE FORWARD-LOOKING CONVERGENCE — FAPI 2.0 and Global Interoperability

4.1 The Fragmentation Problem

While over 95 jurisdictions are pursuing open banking, the ecosystem remains fragmented. There are currently five different versions of FAPI and 25 possible combinations. This fragmentation creates significant barriers to interoperability.

4.2 FAPI 2.0 — The Convergence Point

FAPI 2.0 represents the next generation of the Financial-grade API security profile. Key differences from FAPI 1.0 Advanced:

Adoption timeline:

• Project Aperta (BIS Innovation Hub) has adopted FAPI 2.0 as its underlying security profile

• FAPI 2.0 and OpenID Federation are already powering open finance ecosystems across multiple jurisdictions

• UK Open Banking, CDR Australia, and Brazil Open Finance are all under consultation for FAPI 2.0 migration

4.3 Migration Effort from FAPI 1.0 Advanced to FAPI 2.0

4.4 The Global Convergence Pattern

Despite fragmentation, a clear convergence pattern is emerging:

1. Security convergence: FAPI 2.0 is becoming the global standard

2. Scope convergence: Open Banking → Open Finance (PSD3/FiDA, CDR expansion, Brazil’s model)

3. Data model convergence: ISO 20022 harmonisation

4. Consent model convergence: Granular, revocable consent is universal

CLOSING — OPERATIONAL RISK OF JURISDICTIONAL MISALIGNMENT

A certified Open Banking practitioner must design systems that can operate across multiple jurisdictions. Failure to implement the most stringent requirements (FAPI 1.0 Advanced, mTLS, 25 RPS, ≤2-hour consent revocation) will result in non-compliance in the most demanding jurisdictions. Conversely, over-engineering for the least stringent jurisdiction (FDX) may result in unnecessary cost and complexity.

Key takeaways:

• All five frameworks share a common security stack (OAuth 2.0, PKCE, mTLS, FAPI)

• The UK CMA Order is the most stringent (FAPI 1.0 Advanced mandatory, 25 RPS)

• The CDR has the most granular consent model and strictest revocation SLA (≤2 hours)

• FDX is the least stringent but has the largest consumer base (>130M accounts)

• Brazil is the largest ecosystem by active consents (>30M) with unique Pix integration

• FAPI 2.0 represents the forward-looking convergence point