Ecosystem reconnaissance
Mapping of exposed interfaces, the institution's role (transmitter, receiver or initiator) and the attack surface in the participant directory.
Financial Sector · Open Finance
Open Finance Security
Open Finance security is the set of tests that prove the resilience of APIs, authentication and consent in Brazil's Central-Bank-regulated ecosystem. Berghem assesses FAPI, mTLS, Dynamic Client Registration (DCR) and the consent journey against abuse, data leakage and payment-initiation fraud.
What is Open Finance security?
It is the technical assessment of the controls that protect data sharing and payment initiation between participating institutions. It focuses on the APIs, FAPI authentication, mutual TLS (mTLS), Dynamic Client Registration (DCR) and the integrity of the user consent flow.
Participating institutions — banks, fintechs, payment initiators and aggregators — are accountable for the security of the interfaces they expose and consume. Berghem tests every layer of the Open Finance Brasil standard the way an adversary would: forging tokens, reusing consents, escalating scopes and exploiting logic flaws in the payment journey, always within the authorized scope.
What's included
•Penetration testing of Open Finance APIs (FAPI)
•mTLS, certificate and sender-constrained token validation
•Dynamic Client Registration (DCR) and client lifecycle
•Consent journey — creation, revocation and scope
•Payment-initiation fraud and business-logic abuse
•Mapping to OWASP API Security Top 10 and LGPD
The landscape
Why Open Finance concentrates risk
Open Finance Brasil turned API security into an ecosystem-wide problem. A single participating institution that exposes a poorly protected interface widens the attack surface of every other participant connected to it. Unlike a point-to-point integration, here sensitive data and the ability to initiate payments flow across dozens of counterparties, and trust is upheld by cryptography, certificates and a strict authentication standard — not by a network perimeter.
That means classic API authorization flaws gain systemic impact: a poorly validated token, a consent that never expires or a client registered improperly can expose the financial data of thousands of account holders or enable fraudulent payment initiation. That is why we treat Open Finance penetration testing as an extension of the financial-sector security program, not an isolated exercise against a single API.
Technical coverage
Every Open Finance layer, tested
From the certificate handshake to a revoked consent, we assess the controls the standard requires — and the points where implementations tend to fail.
FAPI APIs
Penetration testing of data and payment interfaces against the OWASP API Security Top 10, focused on broken authorization (BOLA/BFLA), signature validation and FAPI profile conformance.
mTLS and certificates
Validation of mutual TLS authentication, the directory's certificate chain and the sender-constrained tokens that bind the access token to the client certificate.
Dynamic Client Registration
Analysis of dynamic client registration (DCR), software statement handling and client lifecycle — where registration abuse opens the door to unauthorized access.
Consent and data
Testing of the consent journey — creation, scope, expiry and revocation — and adherence to LGPD in personal-data sharing between participants.
Payment initiation
Assessment of payment security — business-logic abuse, amount and payee tampering, and fraud in the initiation journey (Pix and other arrangements).
Regulatory compliance
Alignment with the cybersecurity framework of the Central Bank and CMN applicable to financial institutions, with audit-ready evidence.
Methodology
How we run the assessment
A penetration test oriented to the Open Finance Brasil standard, pairing automated FAPI conformance testing with manual logic exploitation.
FAPI conformance
Execution of FAPI conformance suites and verification of PKCE, PAR, JARM and sender-constrained tokens, plus message-signing requirements.
Manual exploitation
Authorization attacks, consent reuse, scope escalation, token replay and payment-journey tampering carried out manually.
Evidence and remediation
Report with CVSS, reproducible proof of concept, business impact and a prioritized remediation roadmap — ready for the technical team and the audit.
Why Berghem
Financial-sector security specialists
Open Finance security demands someone who understands both the OAuth/OpenID standard and Brazilian regulation — and how an attacker chains the two.
FAPI and OAuth focus
We know the Financial-grade API profile in depth: where the spec is strict and where implementations relax controls and open exploitable gaps.
Brazilian regulatory context
We translate technical findings into the language of the Central Bank, the CMN and LGPD, tying each flaw to its corresponding regulatory requirement.
Real exploitation proof
Every finding ships with a proof of concept and demonstrated impact — not just scanner output. You know exactly what an attacker could achieve.
FAQ
Open Finance security — frequently asked questions
What is FAPI and why does it matter in Open Finance?
FAPI (Financial-grade API) is the OpenID Foundation security profile adopted by Open Finance Brasil. It hardens OAuth 2.0 with PKCE, PAR, JARM and certificate-bound tokens. We test whether the implementation truly meets the profile or merely claims to. Where it does not, we show the exact gap and its impact.
Does Berghem test mTLS and the certificate chain?
Yes. We validate mutual TLS authentication, the certificate chain issued by the participant directory and the sender-constrained tokens that bind the access token to the client certificate, preventing token reuse by third parties. We also test whether a captured token is accepted on a connection with a different certificate.
How do you assess Dynamic Client Registration (DCR)?
We analyze dynamic client registration, software statement validation and the client lifecycle. We look for flaws that let an actor register a rogue client, escalate scopes or impersonate another participating institution. Each finding ships with the proof of concept that reproduces the abusive registration.
Does the test cover the consent journey and LGPD?
It does. We test consent creation, scope, expiry and revocation, checking whether data stays accessible after revocation. We map findings to LGPD principles on personal-data sharing between participants. We also check whether tokens issued under the old consent remain valid after it expires.
Does the service help with Central Bank compliance?
Yes. The evidence produced aligns with the cybersecurity framework of the Central Bank and CMN applicable to financial institutions. The report is a direct input for audits and for demonstrating the required security diligence. It includes the inventory of controls tested and the status of each recommended fix.
Let's talk
Test your Open Finance security
In a 30-minute conversation we map your role in the ecosystem, the exposed interfaces and the ideal penetration-test scope — from FAPI to consent.