Fintech and Digital Bank Pentesting in Brazil: What CMN Resolution 4,893 Requires

Yes — Brazil’s Central Bank now requires penetration testing. Since CMN Resolution 5,274 of December 18, 2025, CMN Resolution 4,893 (often called “BACEN 4,893”) explicitly lists penetration tests among the minimum cybersecurity controls for institutions authorized by the Central Bank of Brazil. The test must happen at least once a year, be performed by an independent specialist or firm, and be documented with the findings and the remediation plan. Payment institutions, brokers and distributors follow the same rule under BCB Resolution 85.

This guide covers what changed, who must comply, what exactly the rule requires from a pentest, what the test should cover in a fintech, and how to turn the report into evidence for the regulator. It’s useful both for Brazilian institutions and for foreign fintechs operating in — or entering — Brazil.

What changed in December 2025

The original 2021 text of CMN Resolution 4,893 already asked for “periodic tests and scans to detect vulnerabilities,” without detail. CMN Resolution 5,274 (official text in Portuguese) turned that item into a list of minimum controls and created specific rules for penetration testing:

The resolution took effect on publication, and institutions already operating had until March 1, 2026 to comply.

Who must comply

• Institutions authorized by the Central Bank — banks, digital banks, finance companies, direct credit companies (SCD) and peer-to-peer lending companies (SEP), among others: they follow CMN Resolution 4,893.
• Payment institutions, securities brokers and distributors, and foreign exchange brokers: they follow BCB Resolution 85, which received the same pentest rules through BCB Resolution 538, also of December 18, 2025.
• Fintechs without their own license, operating through a partner bank or a BaaS provider: the rule doesn’t apply to them directly. But the licensed institution must define procedures and controls for service providers that handle sensitive or relevant data on its behalf, at a level compatible with its own (art. 3, item V, “b”, and § 5). In practice, that requirement tends to show up in the partner contract.

What the rule requires from the pentest

Article 22-A, added in December 2025, is direct (our translation):

Art. 22-A. Institutions must ensure that the penetration tests mentioned in art. 3, § 8, item IV: I - take place at least once a year; II - are performed with independence and impartiality by an individual or specialized firm hired by the institution for this purpose, without prejudice to tests performed by the institution’s own teams; and III - have their results documented, especially any vulnerabilities identified and the action plans established to fix them.

In practice:

1. At least one pentest per year. “At least” — major product changes justify additional tests.
2. Performed by an outside party. The internal team can (and should) test, but that doesn’t replace the independent, contracted test.
3. With a report and a remediation plan. A PDF listing the flaws isn’t enough: the rule asks for action plans to fix them. And § 8 also requires “timely remediation of the vulnerabilities identified” — fix it, and prove you fixed it.

The results also go into the annual report on the incident action and response plan, with a December 31 base date, which goes to the risk committee (if there is one) and to the board or executive board by March 31 of the following year (art. 8). The documentation must stay available to the Central Bank for 5 years (art. 23).

What a fintech pentest needs to cover

The resolution doesn’t define the test scope. The cybersecurity policy — and, by extension, the tests — must fit the institution’s size, risk profile and business model (art. 2, § 1), and the minimum controls in article 3 show where to look. In a fintech, a serious pentest covers at least:

• Authentication and access control — login, account recovery, sessions, MFA (including for remote access to the corporate network, now mandatory) and the permissions of internal and outsourced staff.
• Authorization between accounts — one customer must never see or touch another’s balance, statement or data. It’s the most common API flaw in financial platforms.
• API integrations — the rule now specifically addresses security requirements for integrating systems through electronic interfaces (art. 3, § 2, XIII): partner APIs, webhooks, Open Finance, KYC and payment providers.
• Transaction logic — limits, chargebacks, refunds, withdrawals and transfers made in parallel (race conditions), rounding and negative amounts.
• Pix environment, for participants connected to the national financial network (RSFN) — MFA for administrative access, environment isolation, safekeeping of certificates and signing keys (art. 3-A).
• Traceability — whether transactions and access generate audit trails that make it possible to investigate an incident (art. 3, § 7).

For authorization between accounts, the most efficient approach is grey box testing (with test accounts); for critical modules such as wallets, Pix and limit engines, the code review of a white box pentest pays off. A real example of the kind of flaw this testing finds is in BOLA in Fintech: One Endpoint Leaks Every Tenant.

How the report becomes evidence for the regulator

During supervision or internal audit, documentation is what counts. A pentest report that meets article 22-A makes clear:

1. Who performed it and under what terms — a contracted firm or specialist, with no conflict with the team that built the system.
2. Scope and period — which systems, environments and APIs were tested, and when.
3. Methodology — how the test was run and with what level of access.
4. Vulnerabilities found — with severity, evidence and reproduction steps.
5. Action plan — what will be fixed, by whom and by when.
6. Retest — proof that the fixes work.

Keep everything together (report, action plan and retest) with the test date: the 5-year period counts from the date the test was performed.

A calendar that works

Since the annual report has a December 31 base date and goes to the board by March 31, the year’s pentest, fixes and retest should ideally be done before year-end. In practice: plan the pentest for the first half or the third quarter, leave time to fix, run the retest and reach December with the cycle closed. Major mid-year changes — a new product, an Open Finance integration, joining Pix — justify additional focused tests.

How much it costs

At No Vuln, pentests are contracted by the hour, at US$ 150 to US$ 250 per hour. For a fintech with a product in production, the most common package is the Deep Dive (50h), US$ 7,500 to US$ 12,500; for digital banks and platforms with several products, APIs and Pix, the Full Scope (100h+), from US$ 15,000. If you prefer testing throughout the year rather than only annually, PTaaS (continuous pentesting with a monthly or quarterly hour bank) is an option. See also how much a pentest costs in Brazil.

What to do now

1. Confirm which rule applies to your institution (CMN 4,893 or BCB 85) — or to your partner, if you operate through BaaS.
2. Check that your last pentest was less than 12 months ago, by an independent firm, and is documented.
3. Make sure there is an action plan and a retest for each relevant finding.
4. Review MFA for remote access and, if you’re on Pix, environment isolation and key safekeeping.
5. Schedule the next pentest so the cycle closes before December 31.

For the technical scope, see fintech penetration testing, payments penetration testing and Pix security testing. To talk about your case: talk to a researcher — mutual NDA before the first technical call.

This article summarizes the rules to guide technical planning and doesn’t replace reading the official text or advice from your legal and compliance teams. Sources (official texts in Portuguese): CMN Resolution 4,893, CMN Resolution 5,274, BCB Resolution 85 and BCB Resolution 538.