LESSON 1.5: BRAZIL’S OPEN FINANCE — The World’s Largest Regulated Ecosystem

INTRODUCTION

In Lessons 1.1 through 1.4, you mastered frameworks born of European competition law (PSD2, CMA) and consumer rights (CDR). You navigated the consortium-driven pragmatism of FDX. Now, you cross the equator to Brazil—where open banking was not merely regulated, but weaponised with the most aggressive adoption vehicle in financial history: Pix.

Brazil’s Open Finance (formerly Open Banking) is the largest open finance ecosystem globally by active users. As of 2026, it comprises over 800 participating institutions and over 30 million active consents. It covers not just banking accounts, but insurance, investments, pension funds, and foreign exchange. It is mandatory for all regulated financial institutions above certain size thresholds. And it is built on a strict FAPI 1.0 Advanced security profile known as FAPI-BR.

For the certified practitioner, Brazil represents the ultimate stress test of open finance architecture. You must handle the Pix instant payment integration (settlement in <10 seconds), enforce mTLS with ICP-Brasil certificates (Brazil’s national PKI), and comply with the BCB’s strict availability SLAs. This lesson dissects the BCB’s regulatory framework (Resolução Conjunta Nº 1/2020), the four-phase rollout, the FAPI-BR security profile, and the consent management API (v3.3.0) that has powered Brazil’s explosive growth.

LEARNING OBJECTIVES

Upon completing this lesson, you will be able to:

Cite the exact BCB regulatory instruments—Resolução Conjunta BCB/CMN Nº 1/2020 establishing the framework, and Instrução Normativa BCB nº 720 (April 2026) mandating ICP-Brasil certificates—that govern Open Finance Brasil.
Implement the FAPI-BR security profile (v2.2.0)—a strict subset of FAPI 1.0 Advanced—including mandatory PAR (Pushed Authorization Requests) , JARM (JWT-Secured Authorization Response Mode) , and mTLS with ICP-Brasil certificates.
Calculate the Pix integration latency budget: derive the end-to-end timing from PISP payment initiation to final settlement, including the BCB’s <10-second Pix clearing mandate, FAPI-BR handshake overhead (~12ms), and ICP-Brasil certificate validation (~5ms).
Design the consent lifecycle using the /consents/v3/consents API—implementing granular consent creation (POST), status query (GET), revocation (DELETE), and extension (POST /extends) with OAuth 2.0 scope mapping.
Quantify the availability requirements—99.5% to 99.8% uptime for APIs—and design a multi-AZ failover architecture to meet the BCB’s strict monitoring and incident response mandates.
Articulate Brazil’s evolution from Open Banking to Open Finance—identifying how the expansion from Phase 1 (product data) through Phase 4 (insurance, pensions, FX) created the broadest-scope open finance framework globally.

PART 1: REGULATORY FOUNDATION — Resolução Conjunta Nº 1/2020

1.1 The BCB Mandate

Brazil’s Open Finance framework was established by the Banco Central do Brasil (BCB) and the National Monetary Council (CMN) through Resolução Conjunta BCB/CMN Nº 1/2020, published in May 2020. Unlike PSD2’s payment-services basis or the CDR’s consumer-rights basis, Brazil’s framework is grounded in financial system stability and competition—the BCB’s core constitutional mandate.

Key legal instruments:

Instrument	Date	Purpose
Resolução Conjunta Nº 1/2020	May 2020	Establishes Open Banking framework and governance structure
BCB Communiqué (April 2019)	April 2019	Initial announcement of Open Banking initiative
Instrução Normativa BCB nº 720	April 2026	Mandates ICP-Brasil certificates v5.0 for all Open Finance participants

1.2 The Four-Phase Rollout

Brazil’s implementation followed a carefully sequenced four-phase approach:

+-----------------------------------------------------------------------+
|              BRAZIL OPEN FINANCE — FOUR-PHASE ROLLOUT (2021-2024)      |
+-----------------------------------------------------------------------+
|                                                                        |
|  PHASE 1 (February 2021)                                               |
|  +------------------------------------------------------------------+  |
|  |  • Standardised product data APIs                                 |  |
|  |  • Public data sharing (no consent required)                      |  |
|  |  • Initial participating institutions onboarded                   |  |
|  +------------------------------------------------------------------+  |
|                              |                                         |
|                              v                                         |
|  PHASE 2 (August 2021)                                                |
|  +------------------------------------------------------------------+  |
|  |  • Customer data sharing with explicit consent[reference:32]        |  |
|  |  • Consent API (v1.0) deployed                                    |  |
|  |  • OAuth 2.0 with PKCE mandated                                   |  |
|  +------------------------------------------------------------------+  |
|                              |                                         |
|                              v                                         |
|  PHASE 3 (October 2021)                                               |
|  +------------------------------------------------------------------+  |
|  |  • Payment initiation via Pix[reference:33]                        |  |
|  |  • Transactional data sharing                                     |  |
|  |  • PISP (Payment Initiation Service Provider) role defined        |  |
|  +------------------------------------------------------------------+  |
|                              |                                         |
|                              v                                         |
|  PHASE 4 (December 2023 - 2024)                                       |
|  +------------------------------------------------------------------+  |
|  |  • Insurance, investments, pension funds, FX[reference:34]         |  |
|  |  • Full "Open Finance" scope realised                             |  |
|  |  • >800 participating institutions[reference:35]                  |  |
|  |  • >30 million active consents[reference:36]                          |  |
|  +------------------------------------------------------------------+  |
|                                                                        |
|  REBRAND: "Open Banking Brasil" → "Open Finance Brasil" (Phase 3)[reference:37]|
+-----------------------------------------------------------------------+

Critical observation: Phase 3’s integration with Pix was the catalyst for mass adoption. Pix is Brazil’s instant payment system, settling transactions in <10 seconds with 24/7/365 availability. The PISP can initiate a Pix payment via the Open Finance API, and the funds are available to the payee within seconds—a capability unmatched by any other open banking framework globally.

PART 2: THE FAPI-BR SECURITY PROFILE — FAPI 1.0 Advanced with Brazilian Enhancements

2.1 What Is FAPI-BR?

The Open Finance Brasil Security Profile (FAPI-BR) is an implementation of the FAPI-1-Advanced profile that provides specific implementation guidelines for security and interoperability. It is not a relaxation of FAPI-1-Advanced; rather, it is a strict subset that mandates certain characteristics to facilitate interoperability among Brazilian financial institutions.

FAPI-BR v2.2.0 (current as of April 2026) includes:

Component	FAPI-BR Requirement	Standard Reference
OAuth 2.0	Mandatory	RFC 6749, RFC 6750
PKCE	Mandatory	RFC 7636
OpenID Connect	Mandatory	OIDC Core
FAPI-1-Baseline	Mandatory	FAPI Part 1
FAPI-1-Advanced	Mandatory (subset)	FAPI Part 2
PAR (Pushed Auth Requests)	Mandatory	RFC 9126
JARM (JWT Auth Response Mode)	Mandatory	JARM Specification
mTLS	Mandatory (ICP-Brasil)	RFC 8705

2.2 The FAPI-BR Security Architecture

+-----------------------------------------------------------------------+
|              FAPI-BR SECURITY ARCHITECTURE — MANDATORY COMPONENTS      |
+-----------------------------------------------------------------------+
|                                                                        |
|  +------------------------------------------------------------------+  |
|  |                    TRANSPORT LAYER (mTLS)                         |  |
|  |  • ICP-Brasil certificates[reference:53]                              |  |
|  |  • Certificate chain: V5 or V10 (ICP-Brasil PKI)[reference:54]          |  |
|  |  • Mutual authentication at TLS handshake                         |  |
|  |  • Latency: ~8-12ms (including OCSP stapling)                    |  |
|  +------------------------------------------------------------------+  |
|                                    |                                   |
|  +------------------------------------------------------------------+  |
|  |                    AUTHORISATION LAYER (OAuth 2.0 + OIDC)         |  |
|  |  • PAR (Pushed Authorization Requests) — mandatory[reference:55]    |  |
|  |  • PKCE (Proof Key for Code Exchange) — mandatory[reference:56]          |  |
|  |  • JARM (JWT-Secured Authorization Response Mode) — mandatory[reference:57]|
|  |  • Client assertion JWT with `nbf` ≤90s, `exp` ≤120s             |  |
|  +------------------------------------------------------------------+  |
|                                    |                                   |
|  +------------------------------------------------------------------+  |
|  |                    CONSENT LAYER (FAPI-BR Specific)               |  |
|  |  • Fine-grained access control[reference:58]                        |  |
|  |  • Data minimisation — TPP requests only required fields         |  |
|  |  • `acr` (Authentication Context Reference) claim[reference:59]     |  |
|  |  • Consent revocation via DELETE /consents/v3/consents/{id}[reference:60]|
|  +------------------------------------------------------------------+  |
|                                                                        |
+-----------------------------------------------------------------------+

2.3 ICP-Brasil Certificates — The Brazilian PKI

Unlike the UK’s QWAC (eIDAS) or Australia’s ACCC-accredited CAs, Brazil mandates certificates from ICP-Brasil—the Brazilian Public Key Infrastructure.

Certificate requirements:

Issuer: Certifying Authority authorised by ICP-Brasil
Certificate type: “CERTIFICATE FOR WEB SERVER – ICP-Brasil”
Certificate chain: Must follow V5 and V10 chains
Usage: Communication between all Open Finance Brasil ecosystem participants
Rotation: Mandatory renewal every 12 months (per BCB Normative Instruction)

Latency impact: ICP-Brasil certificate validation (including OCSP stapling and CRL checking) adds approximately 5-8ms to the mTLS handshake, on top of the standard TLS 1.3 1-RTT handshake (~4ms). Total mTLS overhead: ~12ms (p95) in São Paulo availability zones.

PART 3: CONSENT MANAGEMENT — The /consents/v3 API

3.1 The Consent API Endpoints

Brazil’s consent API (v3.3.0) provides four core operations:

Endpoint	Method	Purpose
`/consents/v3/consents`	POST	Create a new consent request
`/consents/v3/consents/{consentId}`	GET	Retrieve consent details
`/consents/v3/consents/{consentId}`	DELETE	Revoke consent
`/consents/{consentId}/extends`	POST	Extend consent duration

3.2 Consent Creation Flow — Complete Sequence

+-----------------------------------------------------------------------+
|          BRAZIL OPEN FINANCE — CONSENT CREATION FLOW (FAPI-BR)         |
+-----------------------------------------------------------------------+
|                                                                        |
|  TPP (ADR)              ASPSP (Data Holder)         PSU (Customer)    |
|     |                         |                           |            |
|     |--(1) PAR Request------->|                           |            |
|     |  POST /par             |                           |            |
|     |  (OAuth 2.0 PAR)      |                           |            |
|     |                         |                           |            |
|     |<-(2) request_uri-------|                           |            |
|     |  (PAR response)        |                           |            |
|     |                         |                           |            |
|     |--(3) Auth Request------>|                           |            |
|     |  (redirect PSU to       |                           |            |
|     |   ASPSP authorisation)  |                           |            |
|     |                         |                           |            |
|     |                         |<--(4) PSU authenticates--|            |
|     |                         |    (SCA with dynamic     |            |
|     |                         |     linking per FAPI-BR) |            |
|     |                         |                           |            |
|     |                         |<--(5) PSU grants consent-|            |
|     |                         |    (granular permissions)|            |
|     |                         |                           |            |
|     |<-(6) Auth Response------|                           |            |
|     |  (JARM-encrypted JWT)   |                           |            |
|     |                         |                           |            |
|     |--(7) Token Request----->|                           |            |
|     |  (POST /token)         |                           |            |
|     |  (mTLS + client assert) |                           |            |
|     |                         |                           |            |
|     |<-(8) Access Token-------|                           |            |
|     |  (with consent scope)   |                           |            |
|     |                         |                           |            |
|     |--(9) POST /consents/v3/ |                           |            |
|     |     consents            |                           |            |
|     |  (create consent record)|                           |            |
|     |                         |                           |            |
|     |<-(10) 201 Created-------|                           |            |
|     |  Location: /consents/v3/|                           |            |
|     |  consents/{consentId}   |                           |            |
|     |                         |                           |            |
+-----------------------------------------------------------------------+

3.3 Explicit JSON Payload — Consent Creation

POST /consents/v3/consents request body:

{
  "data": {
    "loggedUser": {
      "document": {
        "identification": "12345678900",
        "rel": "CPF"
      }
    },
    "businessEntity": {
      "document": {
        "identification": "12345678000199",
        "rel": "CNPJ"
      }
    },
    "permissions": [
      "ACCOUNTS_READ",
      "ACCOUNTS_BALANCES_READ",
      "ACCOUNTS_TRANSACTIONS_READ",
      "PAYMENTS_PIX_INITIATE"
    ],
    "expirationDateTime": "2027-08-03T23:59:59Z",
    "transactionFromDateTime": "2026-01-01T00:00:00Z",
    "transactionToDateTime": "2026-08-03T23:59:59Z"
  }
}

OAuth 2.0 Scope Mapping — Each permission maps to an OAuth scope:

ACCOUNTS_READ → openid accounts:read
ACCOUNTS_BALANCES_READ → openid balances:read
PAYMENTS_PIX_INITIATE → openid payments:pix:initiate

3.4 Consent Revocation — DELETE Endpoint

DELETE /consents/v3/consents/{consentId}:

Immediate revocation of consent
Access tokens issued under this consent are invalidated immediately
Data Holder must cease all data sharing within 24 hours (Brazil’s regulatory SLA)

Cache invalidation strategy — When a DELETE is received:

Invalidate the consent record in the primary database
Publish a consent.revoked event to a Kafka topic (partitioned by consentId)
Downstream microservices consume the event and invalidate Redis caches
The TPP receives a 204 No Content response upon successful revocation

PART 4: PIX INTEGRATION — The Instant Payment Catalyst

4.1 What Is Pix?

Pix is Brazil’s instant payment system, launched by the BCB in November 2020. It enables:

24/7/365 availability
<10-second settlement (typically 2-5 seconds)
No transaction fees for individuals
QR code and push payment initiation

The Open Finance Phase 3 integration with Pix allows a PISP (Payment Initiation Service Provider) to initiate a Pix payment via the Open Finance API.

4.2 Pix Payment Initiation — End-to-End Latency Budget

Layer	Operation	Latency (p95)	Cumulative
TPP → ASPSP	mTLS Handshake (ICP-Brasil)	12ms	12ms
TPP → ASPSP	PAR + Authorisation Request	15ms	27ms
ASPSP	SCA Dynamic Linking (FAPI-BR)	8ms	35ms
ASPSP	Consent Validation	3ms	38ms
ASPSP → BCB	Pix Payment Submission (SPI)	50ms	88ms
BCB	Pix Settlement (clearing)	2,000-5,000ms	2,088-5,088ms
BCB → Payee ASPSP	Pix Credit Notification	50ms	2,138-5,138ms
ASPSP → TPP	Response (mTLS)	12ms	2,150-5,150ms
Total	End-to-End	~2.2 – 5.2 seconds

Critical observation: The BCB’s Pix clearing engine dominates the latency budget (2-5 seconds). The Open Finance API layer adds only ~100ms of overhead. The PISP must implement idempotency (x-idempotency-key) to handle the case where the ASPSP receives a payment confirmation but the TPP times out waiting for the response.

4.3 Pix Payment Initiation — Pseudo-code

import requests
import uuid
from datetime import datetime

class PixPaymentInitiator:
    """
    Initiates a Pix payment via Brazil's Open Finance API.
    """
    
    def initiate_pix_payment(self, consent_id: str, amount: float, 
                             payee_key: str, tpp_access_token: str) -> dict:
        """
        Initiate a Pix payment using an active consent.
        
        Args:
            consent_id: Active consent ID from /consents/v3/consents
            amount: Payment amount in BRL (max 2 decimal places)
            payee_key: Pix key (CPF, CNPJ, email, phone, or random key)
            tpp_access_token: Valid OAuth 2.0 access token with pix scope
        
        Returns:
            dict: Payment status including endToEndId
        """
        idempotency_key = str(uuid.uuid4())
        
        payload = {
            "data": {
                "payment": {
                    "amount": f"{amount:.2f}",
                    "currency": "BRL"
                },
                "payee": {
                    "personType": "NATURAL",
                    "document": {
                        "identification": payee_key,
                        "rel": "PIX_KEY"
                    }
                },
                "paymentMethod": {
                    "type": "PIX",
                    "instantPayment": {
                        "endToEndId": f"E{datetime.now().strftime('%Y%m%d%H%M%S')}{idempotency_key[:8]}"
                    }
                }
            }
        }
        
        headers = {
            "Authorization": f"Bearer {tpp_access_token}",
            "x-idempotency-key": idempotency_key,
            "x-fapi-financial-id": "BCB-BR-123456",
            "x-fapi-interaction-id": str(uuid.uuid4()),
            "Content-Type": "application/json"
        }
        
        response = requests.post(
            "https://api.bank.com.br/open-finance/v1/payments/pix",
            json=payload,
            headers=headers,
            timeout=10.0  # 10-second timeout for Pix
        )
        
        if response.status_code == 201:
            return response.json()
        elif response.status_code == 409:
            # Idempotency conflict — same key with different payload
            raise IdempotencyConflictError("Duplicate payment with different details")
        else:
            raise PaymentInitiationError(f"Pix payment failed: {response.status_code}")

PART 5: AVAILABILITY AND MONITORING — The BCB’s Strict SLAs

5.1 Availability Requirements

The BCB enforces strict availability requirements for Open Finance participants:

Metric	Requirement
API availability	99.5% — 99.8% uptime
Monitoring	Continuous performance and compliance monitoring
Incident response	Documented plan with public monitoring
PCM (Platform de Coleta de Métricas)	Mandatory metrics collection platform

5.2 Multi-AZ Architecture for 99.8% Uptime

To achieve 99.8% availability (allowable downtime: ~17.5 hours per year), the certified practitioner must design:

+-----------------------------------------------------------------------+
|              BRAZIL OPEN FINANCE — MULTI-AZ HIGH-AVAILABILITY          |
+-----------------------------------------------------------------------+
|                                                                        |
|                    +---------------------+                             |
|                    |   AWS São Paulo     |                             |
|                    |   (sa-east-1)       |                             |
|                    +---------------------+                             |
|                              |                                         |
|         +--------------------+--------------------+                   |
|         |                    |                    |                   |
|         v                    v                    v                   |
|  +-------------+     +-------------+     +-------------+             |
|  |   AZ-1      |     |   AZ-2      |     |   AZ-3      |             |
|  | (Active)    |<--->| (Active)    |<--->| (Standby)   |             |
|  +-------------+     +-------------+     +-------------+             |
|  | • API Gw     |     | • API Gw     |     | • API Gw     |             |
|  | • Auth Svc   |     | • Auth Svc   |     | • Auth Svc   |             |
|  | • Consent DB |     | • Consent DB |     | • Consent DB |             |
|  | • Redis      |     | • Redis      |     | • Redis      |             |
|  +-------------+     +-------------+     +-------------+             |
|         |                    |                    |                   |
|         +--------------------+--------------------+                   |
|                              |                                         |
|                    +---------------------+                            |
|                    |   Route 53 / GLB    |                            |
|                    |   (Active-Active)   |                            |
|                    +---------------------+                            |
|                                                                        |
|  Failure tolerance: AZ-1 + AZ-2 failure → AZ-3 takes over within 30s |
+-----------------------------------------------------------------------+

5.3 PCM Metrics Collection

The BCB’s Platform de Coleta de Métricas (PCM) requires all participants to report:

API availability (uptime per endpoint)
Response times (p50, p95, p99)
Error rates (5xx, 4xx distributions)
Consent volumes (grants, revocations, active)
Transaction volumes (Pix payments initiated)

CLOSING — OPERATIONAL RISK OF BRAZILIAN NON-COMPLIANCE

Brazil’s Open Finance is mandatory and strictly enforced. Non-compliance carries severe consequences:

Availability SLA breach: Daily penalties for downtime beyond the allowable threshold
Security non-compliance: Failure to implement FAPI-BR or ICP-Brasil certificates → suspension of participation
Consent mismanagement: Improper consent handling → BCB investigation and potential licence revocation

Key takeaways:

Brazil’s Open Finance is the largest open finance ecosystem globally (>30 million consents, >800 institutions)
FAPI-BR is a strict subset of FAPI 1.0 Advanced with mandatory PAR and JARM
ICP-Brasil certificates are mandatory for mTLS
Pix integration enables <10-second instant payments
Availability target: 99.5% — 99.8%

Transition to Lesson 1.6: You have now mastered the five dominant global frameworks individually. In Lesson 1.6, we synthesise them into a comprehensive comparative analysis—identifying common patterns, critical differences, and the architectural decisions that enable multi-jurisdictional deployment.

Certificate in Open Banking LESSON 1.5: BRAZIL'S OPEN FINANCE — The World's Largest Regulated Ecosystem

Certificate in Open Banking