BCRA rules for the mobile banking app your customers install.
The Banco Central de la República Argentina sets minimum requirements for technology and information security, and specific rules for digital financial services such as mobile banking and digital wallets. They ask for independent vulnerability tests of applications that handle customer data, secure development, multi-factor authentication for critical actions, device binding and session controls in the app. 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, step-up checks and session timeouts tested with your test accounts
- Root and jailbreak detection, anti-tampering and pinning tested at runtime
- Who it applies to
- Financial institutions, systemically important payment systems and, from 4 August 2026, payment service providers in the BCRA register
- Legal basis
- Communication "A" 7724 of 10 March 2023, in force since 6 September 2023, and Communication "A" 7783 of 2 June 2023 for digital financial services
- Focus
- Secure development and independent vulnerability tests, authentication factors, and controls in the apps provided to customers
- Main reference
- Texto ordenado "Requisitos mínimos para la gestión y control de los riesgos de tecnología y seguridad de la información", as of 13 February 2026
The BCRA texts behind your mobile channel
The BCRA publishes each rule as a consolidated text (texto ordenado), updated by numbered communications. The dates below are for the texts cited on this page.
- 16 April 2021
Cyber incident guidelines
Communication "A" 7266 sets the guidelines for response and recovery from cyber incidents (RRCI).
- 6 September 2023
New technology and security rules
The rules approved by Communication "A" 7724 take effect. They repeal the previous IT risk rules built on Communications "A" 4609 and "A" 6375.
- 29 November 2023
Digital financial services rules
The rules approved by Communication "A" 7783 take effect, with specific controls for mobile banking, internet banking, digital wallets and other digital channels.
- 17 July 2025
One-hour incident notification
Communication "A" 8280 makes notification of significant cyber incidents mandatory, with an initial notification within the first hour.
- 5 February 2026
Third parties and payment providers
Communication "A" 8398 replaces the third-party section and brings payment service providers in the BCRA register into scope.
- 4 August 2026
Payment service providers in scope
Payment service providers in the BCRA register must implement the technology and security rules from this date.
The BCRA rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. The BCRA texts are in Spanish; the summaries below are ours.
- Digital financial services rules, 3.2 and 3.2.1 (Spanish text)
Secure the apps you give customers
What the text says
Institutions must design and implement security measures for the devices and applications they provide to customers, which include mobile banking, internet banking and digital wallets. Exchanged data must stay encrypted throughout the interaction, unauthorised sessions must be detected and ended, and the service must be disabled when failures compromise its security. For applications running in environments the customer controls, the minimum controls include blocking access from devices that do not meet the admissibility criteria, mitigating risks from the configuration of the mobile operating system, requesting only the minimum permissions, binding the app to the device and the customer at enrolment or reinstallation, controls on SIM and line changes, and access lock and automatic session lock after inactivity.
Source:Digital financial services rules, 3.2 and 3.2.1 (Spanish text)
What it means for your mobile app
The text names the mobile banking app directly. Rooted or jailbroken phones, reinstallation on a new device and idle sessions are cases you need to handle and be able to show.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts bypasses of root and jailbreak detection, anti-tampering, anti-instrumentation and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. Authenticated testing covers login and logout, token refresh, timeouts and session invalidation.
What stays with you
Your device admissibility criteria and how you tell customers about them, the app's permission choices, device binding on the backend, and SIM swap controls with carriers.
- Digital financial services rules, 3.1 and 3.1.1 (Spanish text)
Require MFA for transactions and critical actions
What the text says
The customer must be identified and authenticated for any transaction, with multi-factor authentication according to risk levels, transaction monitoring results and thresholds. Multi-factor authentication or digital identification is required to confirm at least these critical actions: creating, enabling or re-enabling authentication factors, subscribing to new products or pre-approved loans, changing contact points or transaction parameters, adding third-party accounts for transfers, and transactions that deviate from monitored patterns.
Source:Digital financial services rules, 3.1 and 3.1.1 (Spanish text)
What it means for your mobile app
Changing a phone number, registering a new payee or re-enrolling a device are classic steps in account takeover. The second factor has to be enforced by the server on each of these actions, including when the app or an attacker skips a step.
How Ostorlab helps
Ostorlab completes SMS, email or TOTP 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.
What stays with you
Risk thresholds, transaction monitoring rules and the digital identification process.
- Digital financial services rules, 3.4 to 3.4.3; technology and security rules, 5.7.2.2 and 5.7.2.3 (Spanish text)
Meet the rules for passwords and one-time codes
What the text says
Customer authentication factors cannot be known by staff or third parties, may be stored only for verification, and must be protected with cryptographic techniques. Memorised secrets must be at least 8 characters with upper and lower case letters, numbers and special characters, with limits on automated entry such as Captcha and on failed attempts. One-time codes must be valid for no more than 120 seconds, be at least 6 digits long and travel over an encrypted channel. Out-of-band authenticators must not be visible when the receiving device is locked. These rules add to the general authentication requirements, which ask for a protected channel and hashing or encryption of stored secrets.
What it means for your mobile app
Code lifetime, attempt limits and password rules are enforced by your backend, and a mobile tester can check each one. Codes and passwords should also never sit in clear text on the phone or in logs.
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. Ostorlab also looks for tokens and personal data in local storage, caches, logs and screenshots.
What stays with you
Your password policy, OTP generation and seeds, SMS provider controls and the notification settings on customers' phones.
- Technology and security rules, 9.2.2 (Spanish text)
Get independent vulnerability tests, and test before each release
What the text says
Institutions must set and run software test plans based on risk analysis, combining automated and manual testing, with specific tests documented before changes or new versions of in-house and third-party software go live, and results accepted before production. Applications that handle customer, transactional or financial data must have vulnerability tests carried out by independent third parties. Findings from source code reviews and security tests must be documented, and their risks recorded, evaluated and treated.
What it means for your mobile app
A mobile banking app handles customer and transactional data, so it needs independent vulnerability tests. Each new version of the app also needs documented tests before it reaches the stores.
How Ostorlab helps
Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. The AI-agent pentest tests the app and its APIs behind login, with a working exploit you can replay for each AI-agent finding.
What stays with you
Choosing the independent tester and deciding whether a test qualifies, manual testing and release approval.
- Technology and security rules, 9.2 and 9.2.1 (Spanish text)
Build security into the software lifecycle
What the text says
Institutions must set a framework for the development, acquisition and maintenance lifecycle that includes security standards, threat modelling, criteria for software testing and code review, and procedures to evaluate third-party components before they are integrated, including open source, APIs and AI algorithms. Security requirements must be defined and documented, and security evaluations documented in particular when third-party components are integrated or when systems exchange data with third parties. Mechanisms must verify software integrity throughout the lifecycle.
Source:Technology and security rules, 9.2 and 9.2.1 (Spanish text)
What it means for your mobile app
The SDKs inside your app are third-party components under this framework. Each one should be evaluated before it ships, and apps built by an agency or a vendor fall under the same rules.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. SCA fingerprints statically compiled libraries that manifest-based scanners can miss, and Ostorlab shows what the app and its SDKs exchange with backends over the network.
What stays with you
Your lifecycle framework, threat models, code reviews and vendor evaluations.
- Technology and security rules, 5.8.2 and 9.2.2 (Spanish text)
Manage vulnerabilities in every system and app
What the text says
Institutions must set a vulnerability management process for all systems and applications, their own or third parties', linked to incident management. It includes contact points for reporting vulnerabilities in internal and external services, analysis of the impact of published or reported vulnerabilities, a mitigation plan and schedule according to criticality, alternative mitigation when no update is available, and input to the security update process. Maintenance procedures must cover the evaluation and update of obsolete components, their own and third parties'.
Source:Technology and security rules, 5.8.2 and 9.2.2 (Spanish text)
What it means for your mobile app
The libraries in your app are software you ship. Each one needs a known version, a criticality when a vulnerability appears, and a mitigation date you can prove.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. 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 vulnerability disclosure contact point, patching of servers and infrastructure, and risk acceptance decisions.
- Technology and security rules, 5.7.4; Law 25.326, Art. 9 (Spanish text)
Protect customer data on the device and in transit
What the text says
In line with data classification, institutions must encrypt information in transit, stored in systems or on users' devices, mask and protect data in non-production environments, and implement controls to detect unauthorised transfer of confidential information. Law 25.326 on personal data protection asks the controller to take the technical and organisational measures needed to guarantee the security and confidentiality of personal data, and to avoid its alteration, loss, or unauthorised consultation or processing.
Source:Technology and security rules, 5.7.4; Law 25.326, Art. 9 (Spanish text)
What it means for your mobile app
Tokens, account data and identity documents captured by the app should not sit in clear text on the phone or travel unprotected to the backend.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections. It also finds API keys, tokens and credentials in the app package and validates whether they work.
What stays with you
Data classification, key management, data loss prevention and your obligations to the data protection authority.
- Digital financial services rules, 1.2 (Spanish text)
Notify the BCRA before launching a new digital service
What the text says
Institutions must notify the BCRA's external IT audit department at least 60 days before going live with a project that involves a new product or type of digital financial service. The notification includes the protection measures adopted, the authentication factors used, the planned monitoring activities and the cyber incident management activities.
What it means for your mobile app
A new mobile product, or a new type of service in the app, needs its protection measures described ahead of launch. Test results from the pre-launch build help back up that description.
How Ostorlab helps
Ostorlab tests the pre-launch build and the APIs behind it, including in staging behind your firewall with on-premises scanning, and gives you a report with evidence for each finding.
What stays with you
The notification itself, its content and the dialogue with the BCRA.
- Guidelines for response and recovery from cyber incidents, Section 3, as amended by Communication "A" 8280 (Spanish text)
Report significant cyber incidents within one hour
What the text says
Institutions must notify the BCRA's external IT audit department of cyber incidents that affect the normal provision of services to customers or put the availability, integrity or confidentiality of information at risk, including loss or unauthorised disclosure of customer data. The initial notification is due within the first hour after the incident occurs or is detected, followed by updates and a closing report within 5 calendar days after resolution.
What it means for your mobile app
An app or API flaw that exposes customer data can become a reportable incident. Finding it before release is the cheaper path.
How Ostorlab helps
Ostorlab does not detect, handle or report incidents. It helps you find and fix app and API vulnerabilities before they can lead to one.
What stays with you
Detection, incident response, the one-hour notification and follow-up reports.
Summary of Spanish-language texts published by the BCRA and of Law 25.326, as amended, checked on 27 September 2026. Some texts apply to specific licence types, as noted. This page is not legal advice.
BCRA rules, control by control
The controls the BCRA 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 |
|---|---|---|
| Independent vulnerability tests of apps with customer dataTechnology and security rules 9.2.2 | 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 |
| Documented tests before each new versionTechnology and security rules 9.2.2 | Mobile SAST and DAST in CI/CD on every build, and monitoring of store releases. Details | Scan results per build and per store release |
| Evaluation of third-party components and APIsTechnology and security rules 9.2, 9.2.1 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Vulnerability mitigation by criticality, and obsolete componentsTechnology and security rules 5.8.2, 9.2.2 | 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 |
| Device admissibility and mobile OS configuration risksDigital financial services 3.2.1 | Runs the app in rooted and jailbroken environments and attempts to bypass root and jailbreak detection, anti-tampering and pinning. Details | A hardening score and bypass evidence |
| Session detection, access lock and inactivity timeoutDigital financial services 3.2, 3.2.1 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| MFA for transactions and critical actionsDigital financial services 3.1, 3.1.1 | 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 |
| Password, OTP and failed-attempt rulesDigital financial services 3.4.1 to 3.4.3 | 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 |
| Encryption of data in transit and on devicesTechnology and security rules 5.7.4; Law 25.326 Art. 9 | 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 |
| Service credentials embedded in the appTechnology and security rules 5.7.2 | 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 |
Ostorlab tests controls in the app and its APIs. Transaction monitoring, SIM swap controls, removal of fake apps and profiles, incident notification to the BCRA, business continuity, third-party notifications and governance stay with your teams.
BCRA controls to test in your mobile app
A practical list for security and technology risk teams, based on the BCRA technology and security rules and the digital financial services rules.
Independent tests
Have the app and the APIs it calls tested by an independent third party, and keep the findings and their treatment on record.
Before each release
Run documented automated tests on every build and accept the results before the version reaches the stores.
Components and SDKs
Keep a versioned list of the SDKs and libraries in each release, evaluate new ones, and set mitigation dates by criticality.
Rooted and jailbroken devices
Check what the app does on a device that fails your admissibility criteria, and whether its protections can be bypassed.
Device binding and sessions
Test enrolment on a new device, reinstallation, access lock, and session lock after inactivity.
Critical actions
Verify that new payees, contact changes and factor re-enrolment require the second factor on the server.
Passwords and one-time codes
Test password length and composition, attempt limits, and that codes expire within 120 seconds and cannot be reused.
Data on the phone
Check storage, caches, logs and screenshots for tokens and personal data, and the app package for working secrets.
A suggested list, not a BCRA 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
- 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
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Requisitos mínimos para la gestión y control de los riesgos de tecnología y seguridad de la información (texto ordenado)BCRA, consolidated text as of 13 February 2026, last updated by Communication "A" 8401. Governance, security, cyber incidents, software development and third parties. Spanish text
- Requisitos mínimos para la gestión de los riesgos de tecnología y seguridad de la información asociados a los servicios financieros digitales (texto ordenado)BCRA, consolidated text as of 2 June 2023, in force since 29 November 2023. Controls for mobile banking, internet banking, digital wallets and authentication factors. Spanish text
- Comunicación "A" 7724BCRA, 10 March 2023, in force 180 days after issue. Repeals the previous IT risk rules and approves the current technology and security rules. Spanish text
- Comunicación "A" 7783BCRA, 2 June 2023, in force 180 days after issue. Approves the digital financial services rules. Spanish text
- Comunicación "A" 8398BCRA, 5 February 2026. Brings payment service providers in the BCRA register into scope within 180 days and replaces the third-party section. Spanish text
- Lineamientos para la respuesta y recuperación ante ciberincidentes (RRCI) (texto ordenado)BCRA, first issued by Communication "A" 7266 of 16 April 2021, consolidated text as of 17 July 2025 with the mandatory notification section added by Communication "A" 8280. Spanish text
- Ley 25.326 de Protección de los Datos PersonalesEnacted on 4 October 2000, updated text on InfoLeg. Article 9 covers data security and Article 12 international transfers. Spanish text
- Resolución AAIP 47/2018Agencia de Acceso a la Información Pública, published on 25 July 2018. Recommended security measures for personal data, including vulnerability management and development environments. Spanish text
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 BCRA 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.