Brazil's cyber security rules for the mobile banking app your customers use.
Since the December 2025 amendments, the National Monetary Council and the Banco Central do Brasil ask institutions for periodic vulnerability testing, penetration tests at least once a year by an independent specialist, secure development, and security requirements for systems integrated through electronic interfaces. Pix rules add robust payer authentication and registered devices. Ostorlab helps you test those controls in your app and its APIs, on every release.
- Penetration testing by AI agents behind login, with a replayable exploit for each AI-agent finding
- Static and dynamic testing of the build you ship, with no source code needed
- Login, one-time codes and step-up flows tested with your test accounts
- The APIs behind Pix and account flows tested, even with TLS pinning
- Who it applies to
- Banks and other institutions authorized by the BCB; payment institutions follow BCB Resolution 85
- Legal basis
- CMN Resolution 4,893 of 26 February 2021, amended by CMN Resolution 5,274 of 18 December 2025
- Focus
- Vulnerability testing, yearly independent pentests, secure development, Pix and Open Finance security
- Reference
- CMN Resolution 4,893, BCB Resolution 85, Pix Regulation, Joint Resolution 1/2020
Brazil's cyber security rules, date by date
The cyber security resolutions have applied since 2021. The December 2025 amendments added detailed testing rules, with an adaptation deadline of 1 March 2026.
- 1 July 2021
CMN Resolution 4,893 in force
Cyber security policy and cloud contracting rules for institutions authorized by the Banco Central do Brasil. It replaced CMN Resolution 4,658 of 2018.
- 1 August 2021
BCB Resolution 85 in force
The same rules for payment institutions. The scope was later extended to securities and exchange brokers and dealers, and to virtual asset service providers.
- 1 November 2024
Pix fraud controls
Pix participants must use a fraud risk management solution, and Pix transactions by individuals must come from a previously registered access device, with limited exceptions.
- 18 December 2025
CMN Resolution 5,274 and BCB Resolution 538
New minimum controls, including vulnerability assessment and correction, penetration tests at least once a year, and security requirements for electronic interfaces.
- 1 March 2026
Adaptation deadline
Institutions already operating had until this date to adapt to the December 2025 amendments.
- Every year
Pentest and annual report
Penetration tests at least once a year. The annual report, with a base date of 31 December, includes pentest and vulnerability test results and is presented to the board by 31 March.
The BCB's cyber security rules, applied to your mobile app
CMN Resolution 4,893 sets the rules for banks, and BCB Resolution 85 mirrors them for payment institutions. The Pix and Open Finance rules add controls for payments and data sharing. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- CMN Resolution 4,893, Art. 3, §2 and §8
Test for vulnerabilities, and fix them on time
What the text says
The cyber security policy's procedures and controls must cover, at a minimum, authentication, encryption, intrusion prevention and detection, leak prevention, and the assessment and correction of vulnerabilities in systems. Vulnerability work includes periodic tests and analyses to detect vulnerabilities in information systems, penetration tests and the timely correction of the vulnerabilities found.
What it means for your mobile app
The mobile app and the APIs it calls are information systems. They need a testing cadence that finds vulnerabilities, and a record that each one was fixed on time.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
The policy itself, patch deadlines, and testing of the rest of your estate, such as networks and devices.
- CMN Resolution 4,893, Art. 22-A; BCB Resolution 85, Art. 22-A
Pentest at least once a year, with independence
What the text says
Penetration tests must be run at least once a year. They must be carried out with independence and impartiality by a natural person or specialized firm the institution hires for that purpose, without prejudice to tests by the institution's own teams. Results must be documented, especially the vulnerabilities found and the action plans to correct them.
Source:CMN Resolution 4,893, Art. 22-A; BCB Resolution 85, Art. 22-A
What it means for your mobile app
The yearly pentest of your app and its APIs is a hired, independent test. Your own team can test more often, and the text keeps room for that.
How Ostorlab helps
Your security team runs Ostorlab between annual tests. An AI-agent pentest tests the app and its APIs behind login, typically in a few hours, with a working exploit you can replay for each AI-agent finding, so you go into the annual test with known issues already fixed.
What stays with you
Hiring the independent tester, deciding whether a test qualifies, and the action plans.
- CMN Resolution 4,893, Art. 3, §3 and §6
Apply the controls to secure development
What the text says
The procedures and controls must be applied in the development of secure information systems and in the adoption of new technologies. The institution must verify this, where applicable, for systems it acquires or that third-party providers develop and that run on its own computing resources.
What it means for your mobile app
Each release of the app should pass security testing before it reaches the store. Code built by an agency or a vendor, and the SDKs inside the app, fall under the same verification.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app, keeps authenticated sessions and captures traffic, stack traces and screenshots. SCA fingerprints statically compiled libraries that manifest-based scanners can miss.
What stays with you
Your secure development lifecycle, code reviews outside the app, and vendor contracts.
- CMN Resolution 4,893, Art. 3, III and §2
Authentication, encryption and leak prevention
What the text says
Authentication, encryption mechanisms and mechanisms to prevent information leaks are among the minimum procedures and controls of the cyber security policy. The policy must also include specific controls to ensure the security of sensitive information.
What it means for your mobile app
In a mobile app, these controls live in login and session handling, in how data is stored on the device, and in how it travels to the backend.
How Ostorlab helps
Ostorlab logs in with your test accounts, completes SMS, email or TOTP one-time codes, and tests login and logout, token refresh, timeouts, session invalidation and MFA enforcement. It looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections.
What stays with you
The choice of authentication and encryption standards, and staff access.
- CMN Resolution 4,893, Art. 3, §2, XIII, and Art. 24
Secure the interfaces between systems
What the text says
The minimum controls include security requirements for integrating information systems through electronic interfaces. The Banco Central do Brasil may specify those requirements, keeping them in line with technological innovation.
What it means for your mobile app
The APIs your app calls are electronic interfaces. Broken authorization in one of them can expose other customers' accounts.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation, with request and response evidence for each finding.
What stays with you
API design, the gateway, and any technical requirements the BCB publishes.
- Pix Regulation (annex to BCB Resolution 1/2020), Art. 89
Robust security for Pix authentication and initiation
What the text says
Pix participants must adopt robust mechanisms to ensure the security of payer authentication and payee identification, Pix initiation, account opening, Pix key processes, and funds entering and leaving accounts. Pix initiation by individual customers must come only from an access device the customer registered beforehand, with exceptions set by the BCB.
Source:Pix Regulation (annex to BCB Resolution 1/2020), Art. 89
What it means for your mobile app
The app is where customers authenticate and start Pix payments. Device registration, step-up checks and the APIs behind Pix keys and transfers must hold up against abuse.
How Ostorlab helps
Ostorlab completes one-time codes with your test accounts and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes. The AI-agent pentest tests the business logic of payment and account flows.
What stays with you
The fraud risk management solution, DICT checks, limits and the handling of suspected fraud.
- Joint Resolution 1/2020, Arts. 16 to 18; BCB Resolution 32/2020, Art. 16
Open Finance authentication and API security
What the text says
The data transmitting or account holding institution must adopt procedures and controls to authenticate the customer and the receiving or initiating institution. Customer authentication must be compatible with that used in the institution's own electronic channels, and with its cyber security policy. The Open Finance Security Manual details the security standards, certificates and technical requirements for the APIs.
Source:Joint Resolution 1/2020, Arts. 16 to 18; BCB Resolution 32/2020, Art. 16
What it means for your mobile app
The consent and authentication steps in your app, and the APIs that serve Open Finance, belong in the same testing scope as the rest of your digital channel.
How Ostorlab helps
Authenticated testing covers login and logout, token refresh, timeouts, session invalidation and MFA enforcement, and traffic analysis shows how credentials travel from the app to the backend.
What stays with you
Conformance with the Open Finance standards, certificates and the directory.
- CMN Resolution 4,893, Arts. 8 and 23
Report the results and keep records for five years
What the text says
The annual report on the action and incident response plan, with a base date of 31 December, must include the results of penetration tests and of periodic vulnerability tests, scans and analyses, with the action plans to correct them. Pentest results and action plans must be kept available to the BCB for five years from the test date.
What it means for your mobile app
Each test of the app needs a dated result, the fixes that followed, and proof they worked, ready for the annual report and for the supervisor.
How Ostorlab helps
Scan results, findings with reproduction steps and retest results give you a dated record of how the app's controls were tested and fixed, release after release.
What stays with you
The annual report, its presentation to the board by 31 March, and record retention.
Summary of Portuguese-language texts published by the Banco Central do Brasil, as amended, checked on 27 September 2026. Some texts apply to specific licence types, as noted. This page is not legal advice.
BCB rules, control by control
The controls the CMN and BCB texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Periodic tests to detect vulnerabilitiesCMN 4,893, Art. 3, §8, I | Automated scans from your CI/CD pipeline on every build, including scheduled runs, and monitoring of store releases. Details | Scan results per build and per store release |
| Penetration testsCMN 4,893, Art. 3, §8, IV; Art. 22-A | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Timely correction of vulnerabilitiesCMN 4,893, Art. 3, §8, V | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
| Secure development of information systemsCMN 4,893, Art. 3, §3 | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Systems built or supplied by third partiesCMN 4,893, Art. 3, §6 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| AuthenticationCMN 4,893, Art. 3, §2, I | Logged-in testing with one-time codes, and checks of sessions, tokens, timeouts and MFA enforcement. Details | Findings on login, session and step-up flows with reproduction steps |
| Security of electronic interfacesCMN 4,893, Art. 3, §2, XIII | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
| Leak prevention and sensitive dataCMN 4,893, Art. 3, III and §2, IV | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Hardcoded credentials in the appCMN 4,893, Art. 3, §2, IV | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| Robust Pix authentication and initiationPix Regulation, Art. 89 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
Ostorlab tests controls in the app and its APIs. Network segmentation, the Pix and STR environments, certificate and key management, fraud risk management, dark web monitoring, business continuity and reporting to the board and the BCB stay with your teams.
Mobile app controls to test for the BCB rules
A practical list for security and compliance teams working on the CMN and BCB cyber security rules.
Map your licences
Confirm whether CMN Resolution 4,893 or BCB Resolution 85 applies to each entity, and whether you take part in Pix and Open Finance.
Scan every release
Run static and dynamic tests on each build before it reaches the store, including the SDKs and code supplied by vendors.
Plan the yearly independent pentest
Book the penetration test, at least once a year, with an independent and impartial person or specialized firm, and include the app and its APIs in scope.
Test between annual pentests
Use your own team's testing on critical changes, so issues are found and fixed before the annual test.
Login, sessions and step-up
Check MFA enforcement, one-time code handling, session time-outs and re-authentication for high-risk actions, enforced by the server.
Pix flows and registered devices
Test that Pix initiation, Pix key changes and device registration cannot be bypassed through the app or its APIs.
APIs and data on the device
Test authorization on every account and payment API, and look for tokens, personal data and hardcoded secrets in the app.
Evidence for the annual report
Keep pentest and scan results, action plans and retests for the report due to the board by 31 March, and for five years.
A suggested list, not a BCB template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Resolução CMN nº 4.893, de 26 de fevereiro de 2021National Monetary Council, published by the Banco Central do Brasil, in force since 1 July 2021, consolidated text. Cyber security policy and cloud contracting for authorized institutions. Portuguese only
- Resolução CMN nº 5.274, de 18 de dezembro de 2025National Monetary Council. Amends Resolution 4,893 with minimum controls, penetration tests at least once a year and interface security, with adaptation by 1 March 2026. Portuguese only
- Resolução BCB nº 85, de 8 de abril de 2021Banco Central do Brasil, in force since 1 August 2021, consolidated text. The cyber security rules for payment institutions and other institutions in its scope. Portuguese only
- Resolução BCB nº 538, de 18 de dezembro de 2025Banco Central do Brasil. Brings the December 2025 changes, including yearly penetration tests, into BCB Resolution 85. Portuguese only
- Resolução BCB nº 1, de 12 de agosto de 2020: Regulamento do PixBanco Central do Brasil, consolidated Pix Regulation. Article 89 covers fraud risk management, fraud controls and registered access devices. Portuguese only
- Resolução Conjunta nº 1, de 4 de maio de 2020National Monetary Council and Banco Central do Brasil. Implementation of Open Finance, including customer and institution authentication. Portuguese only
- Resolução BCB nº 32, de 29 de outubro de 2020Banco Central do Brasil. Technical requirements for Open Finance, including the Security Manual for API security standards and certificates. Portuguese only
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app against the BCB rules
Start with a free scan of your app from the store, or book a demo to run logged-in tests and an AI-agent pentest with our team.