CNBV and Banxico rules: test your mobile banking app before and after every release.

1. 01

   Disposiciones de carácter general aplicables a las instituciones de crédito (CUB), Article 168 Bis 11, sections III and VI (Spanish text)

   Secure every technology component across its lifecycle

   What the text says

   The CUB makes the chief executive responsible for an information security control system covering the technology infrastructure, whether owned or provided by third parties. Each component's processes, configurations and development or acquisition methodology must be documented, with change and update records and a detailed inventory. Information security aspects must be considered at every stage of the lifecycle: requirements, design, development or acquisition, implementation and acceptance testing, and release processes that include vulnerability testing and code analysis before production, periodic tests, change management, replacement and destruction of information. Information must be encrypted according to its sensitivity, including when transmitted or stored, and access is granted under the least-privilege principle.

   Source:Disposiciones de carácter general aplicables a las instituciones de crédito (CUB), Article 168 Bis 11, sections III and VI (Spanish text)

   What it means for your mobile app

   Your mobile banking app and the APIs behind it are components of that infrastructure. The CUB expects security requirements, vulnerability testing and code analysis before the app reaches production, and periodic testing afterwards.

   How Ostorlab helps

   Mobile SAST analyses the APK, AAB or IPA binary, including embedded SDKs, with no source code needed. Mobile DAST tests the running app. Both run from your CI/CD pipeline on every build, and SCA covers the libraries inside.

   What stays with you

   The security requirements themselves, architecture and design reviews, access management, and the replacement and destruction of components.

2. 02

   CUB, Article 168 Bis 12, sections II to VII (Spanish text)

   Scan for vulnerabilities and run independent penetration tests

   What the text says

   The CUB requires an annual vulnerability scanning calendar for the components that store, process or transmit information, prioritised by data classification, with quarterly reviews so that every critical component is covered by the end of the year, and a scan of new components before they are put into production. It requires an independent third party, with staff holding industry certifications, to run penetration tests on different systems and applications at least twice a year, to detect errors, vulnerabilities, unauthorised functionality or any code that puts customer information and assets at risk. Scope and methodology must be validated by the chief information security officer. Test conclusions must be sent to the CNBV within 20 business days; vulnerabilities must be classified under a methodology approved by the risk committee; and remediation plans, validated by the CISO, must reach the CNBV within 10 business days.

   Source:CUB, Article 168 Bis 12, sections II to VII (Spanish text)

   What it means for your mobile app

   The app and its APIs belong in this programme. The CUB separates the scanning cadence from the penetration tests, and gives both fixed deadlines and reporting duties.

   How Ostorlab helps

   The AI-agent pentest tests the app and its APIs behind login, on the build you ship, with a working exploit you can replay for each AI-agent finding. 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. Ostorlab is not the independent third party the CUB requires and does not send reports to the CNBV.

   What stays with you

   Contracting the independent third party, validating scope and methodology, classifying vulnerabilities in the risk committee, and the reports to the CNBV.

3. 03

   CUB, Articles 308, 310 and 313 (Spanish text)

   Apply the CUB authentication factors

   What the text says

   To start a session, the CUB requires the user identifier and an authentication factor from Category 2 (information only the user knows, such as a password or PIN, at least six characters), Category 3 (information contained in, received or generated by electronic means or devices, which cannot be duplicated or altered, is used only once and is valid for no more than two minutes), or Category 4 (biometrics, transformed so that each authentication generates a single-use password). For transfers to third-party destination accounts, registering destination accounts, setting or raising limits, changing the notification medium, unlocking credentials and other listed operations, the institution must require a second factor from Category 3 or 4, in addition to the one used to start the session.

   Source:CUB, Articles 308, 310 and 313 (Spanish text)

   What it means for your mobile app

   The second factor has to be enforced by the server on every listed operation, including when the app, or an attacker, skips a step. One-time codes must be single-use and short-lived, and biometric data must produce single-use values.

   How Ostorlab helps

   Authenticated testing logs in with one-time codes and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind them. Ostorlab completes SMS, email or TOTP one-time codes with your test accounts.

   What stays with you

   Choosing and deploying the factors, the biometric enrolment process and the vendor that generates the codes.

4. 04

   CUB, Articles 316 Bis 2 and 316 Bis 3 (Spanish text)

   Control sessions and lock accounts

   What the text says

   Once a user is authenticated, the CUB requires the session to be unusable by a third party. The session must end automatically after more than twenty minutes of inactivity, and after no more than one minute for Pago Móvil, ATMs and point-of-sale terminals. It must also end when there are relevant changes in communication parameters, such as the device identification, the range of communication protocol addresses or the geolocation. Simultaneous sessions with the same user identifier are forbidden, with a notice to the user. Institutions must automatically block passwords and other authentication factors after no more than five consecutive failed attempts, and after a period of inactivity set in their policies, which cannot exceed one year. Users must be able to unlock factors or reset credentials through the contracting procedure or a Category 1 factor.

   Source:CUB, Articles 316 Bis 2 and 316 Bis 3 (Spanish text)

   What it means for your mobile app

   Timeouts, the single-session rule and the lockout threshold are concrete behaviours of the app and its backend. Skip a step in the app and the server should still refuse the operation.

   How Ostorlab helps

   Authenticated testing covers login and logout, token refresh, session timeouts, session invalidation and lockout behaviour, together with the API calls behind them.

   What stays with you

   The timeout values, the lockout and unlock procedure, and the customer notifications.

5. 05

   CUB, Articles 309, 316 Bis 4 and 316 Bis 10 (Spanish text)

   Keep credentials unreadable and protected

   What the text says

   The CUB requires institutions to prevent the identification and authentication information provided by the user from being read on the screen of the access device, and to ensure that only the user receives, activates, knows, unlocks and restores authentication factors. It prohibits mechanisms, algorithms or procedures that allow the institution to know, recover or decrypt authentication information, and prohibits staff from asking users for their Category 2 or 3 factors. It requires messages or communication channels to be encrypted for sensitive information from the access device to the institution, passwords and PINs to be encrypted when stored, cryptographic keys to be administered in high-security devices such as HSMs, and card-based electronic banking to hold industry certifications such as PCI-DSS, PA-DSS and PTS.

   Source:CUB, Articles 309, 316 Bis 4 and 316 Bis 10 (Spanish text)

   What it means for your mobile app

   Credentials and codes should never appear on screen, sit in clear text on the phone or travel unprotected to the backend, and passwords must never be sent by SMS or email without encryption.

   How Ostorlab helps

   Ostorlab finds API keys, tokens and credentials in the app package and validates whether they work. 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

   Key management, HSM operations, the PCI-DSS and PTS certification programme and card-data rules.

6. 06

   Banco de México Circulars 9/2026 and 10/2026 (DOF, 17 June 2026) and the Guías, version 1.1 (Spanish text)

   Ship the standardised mobile transfer flow

   What the text says

   Banxico Circulars 9/2026 and 10/2026 amend the SPEI rules and the rules applicable to credit institution operations to require that instructions for electronic fund transfers presented through mobile devices follow the Guías para la homologación de la experiencia de usuario. The guidelines set a single flow of at most four stages, covering authentication, entry of the transfer information, verification and notification. They require a shortcut to start a transfer on the login and home screens, a review screen where the user validates the beneficiary, the amount and the concept, and authorisation using the designated authentication factor. Beneficiary data read from a QR code cannot be edited. Participants have until 14 December 2026 to comply.

   Source:Banco de México Circulars 9/2026 and 10/2026 (DOF, 17 June 2026) and the Guías, version 1.1 (Spanish text)

   What it means for your mobile app

   From 14 December 2026 the transfer flow in your app is prescribed in detail, and it still has to uphold the CUB authentication requirements behind the screens.

   How Ostorlab helps

   The AI-agent pentest completes the transfer flow with your test accounts and tests the business logic of payments, and API testing checks the calls behind beneficiary registration and transfers, with request and response evidence for each finding.

   What stays with you

   The UX design and build, the choice of the designated authentication factor and the release schedule.

7. 07

   Circular 14/2017, Rule 58a, section I, and Rule 46a (Spanish text)

   Meet the SPEI security requirements

   What the text says

   Circular 14/2017 requires SPEI participants to maintain documented security policies and procedures: a designated security area, secure communication protocols, malware detection tools, vulnerability detection and management tools for the computing infrastructure, detection and management of security incidents, centralised log collection with anomaly detection, and penetration tests on the technology infrastructure with the periodicity, reports and tester qualifications set in Appendix M of the Manual. The development process for the SPEI application must consider security at every stage, review the application statically and dynamically, and keep access and operations logs for at least six months. Participants must notify the system administrator of incidents and imminent threats by phone and in a digitally signed communication within sixty minutes.

   Source:Circular 14/2017, Rule 58a, section I, and Rule 46a (Spanish text)

   What it means for your mobile app

   If you are a SPEI participant, the infrastructure and the applications that connect to the SPEI are in scope, and the incident clock is short. Part of this work falls to the same teams that run your mobile channel.

   How Ostorlab helps

   Ostorlab tests the mobile app and the APIs it calls, including the calls that reach payment services, with request and response evidence. It does not test the SPEI application or its infrastructure, and does not notify the administrator.

   What stays with you

   The SPEI security programme, the Appendix M and Appendix AN controls, the penetration test schedule and the notifications to Banxico.

8. 08

   Disposiciones aplicables a las IFPE (DOF, 28 January 2021), Articles 8, 11, 12, 34 and 42; Ley Fintech, Article 76 (Spanish text)

   Fintech: independent factors, lockouts, pentests and APIs

   What the text says

   The CNBV dispositions for electronic payment funds (IFPEs) require at least two independent authentication factors for changes to beneficiaries, changes to authentication factors, account statement requests and changes to the notification medium. They require automatic session termination after five minutes of inactivity, detection of communication-parameter changes, a ten-minute block of the factor after three consecutive failed attempts and a permanent block after a further failed attempt, and procedures for the client to deactivate operations temporarily. IFPEs must contract an independent firm with certified staff to run penetration tests at least every two years, send conclusions to Banxico and the CNBV within twenty business days, file a remediation plan for high or very high findings within twenty business days, and retest within two months. Article 76 of the Fintech Law also requires standardised API interfaces for open, aggregated and transactional data, and requires access to be interrupted when vulnerabilities put customer information at risk, with notice to the supervisors within two hours of detection.

   Source:Disposiciones aplicables a las IFPE (DOF, 28 January 2021), Articles 8, 11, 12, 34 and 42; Ley Fintech, Article 76 (Spanish text)

   What it means for your mobile app

   The wallet rules are more prescriptive on the mobile channel than the banking rules in some places: shorter timeouts, three attempts before a block and a two-year penetration test floor. The API interfaces carry customer data and their own security and shutdown duties.

   How Ostorlab helps

   Ostorlab tests those behaviours in the app and its APIs with your test accounts: factor independence, session timeouts, lockout and unlock, and the calls behind beneficiary changes, with a replayable exploit for each AI-agent finding.

   What stays with you

   The penetration test contract, the reports to Banxico and the CNBV, the remediation plan, the API authorisations and the customer notifications.

9. 09

   Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF, 20 March 2025; last reform 14 November 2025), Articles 18 to 20 (Spanish text)

   Protect personal data under the LFPDPPP

   What the text says

   The LFPDPPP, published on 20 March 2025 and last reformed on 14 November 2025, requires every controller to maintain administrative, technical and physical security measures that protect personal data against damage, loss, alteration, destruction or unauthorised use, access or processing. The measures are set according to the existing risk, the possible consequences for data subjects, the sensitivity of the data and technological development, and cannot be weaker than those the controller applies to its own information. Breaches that significantly affect the patrimonial or moral rights of data subjects must be notified to them immediately. Everyone involved in processing must keep personal data confidential, and that obligation survives the end of their relationship.

   Source:Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF, 20 March 2025; last reform 14 November 2025), Articles 18 to 20 (Spanish text)

   What it means for your mobile app

   Personal data in the app, in transit and in the backend needs technical protection, and the institution needs a way to tell customers immediately when a breach is significant.

   How Ostorlab helps

   Ostorlab looks for personal data and tokens in local storage, caches, logs, screenshots and app backups, and tests whether the APIs behind the app expose other customers' data.

   What stays with you

   The privacy notice, data subject rights, the breach assessment and customer communications.

Summary of public CNBV, Banxico and Fintech texts, checked on 27 September 2026. The texts are in Spanish; requirements are summarised from the originals. Appendices M and AN live in the SPEI Manual referenced by the circulars and are not quoted here. This page is not legal advice.