Règles de la CNBV et de Banxico : testez votre application bancaire mobile avant et après chaque version.
La Circular Única de Bancos de la CNBV exige une analyse de vulnérabilités et des tests d'intrusion indépendants au moins deux fois par an, fixe les facteurs d'authentification, les délais d'expiration de session et les règles de verrouillage du canal mobile, et impose des tests de sécurité et une analyse de code avant la mise en production. Les règles SPEI de Banxico ajoutent des tests d'intrusion et la notification des incidents pour les participants, et à partir du 14 décembre 2026, tout virement mobile doit suivre le flux standardisé des Guías. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Évalue l'application mobile et les API qu'elle appelle, sur le build que téléchargent vos clients
- Teste les facteurs d'authentification, les codes à usage unique, les délais d'expiration de session et les règles de verrouillage avec vos comptes de test
- Recense les SDK et bibliothèques natives de chaque version et les rapproche des vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les banques et autres institutions de crédit supervisées par la CNBV, les participants au SPEI et les institutions fintech couvertes par la loi Fintech
- Date clé
- Circulaires 9/2026 et 10/2026 de Banxico publiées le 17 juin 2026 ; les guides de virement mobile s'appliquent à partir du 14 décembre 2026
- Objet
- Analyse de vulnérabilités et tests d'intrusion, facteurs d'authentification, sessions, verrouillage et protection des données dans le canal mobile
- Texte de référence
- Disposiciones de carácter general aplicables a las instituciones de crédito (Circular Única de Bancos)
Les textes mexicains qui encadrent votre canal mobile
Le recueil de règles bancaires, les règles du système de paiement, la loi Fintech et la loi de 2025 sur la protection des données touchent tous l'application mobile. Les dates ci-dessous concernent les textes cités sur cette page.
- 2 décembre 2005
Circular Única de Bancos
La CNBV publie les Disposiciones de carácter general aplicables a las instituciones de crédito, le recueil unique de règles bancaires. Le texte compilé cité ici inclut les modifications jusqu'au 1er septembre 2026, avec les chapitres sur la sécurité de l'information et la banque électronique.
- 4 juillet 2017
Règles du SPEI
Banco de México publie la circulaire 14/2017, les règles du système de paiements électroniques interbancaires (SPEI), avec des obligations de sécurité, de tests d'intrusion et de notification des incidents pour les participants. Le texte compilé inclut les modifications jusqu'à la circulaire 9/2026.
- 9 mars 2018
Loi Fintech
La Ley para Regular las Instituciones de Tecnología Financiera est publiée, avec les dispositions de la CNBV pour les institutions fintech le 10 septembre 2018 et des règles spécifiques pour les fonds de paiement électronique le 28 janvier 2021.
- 20 mars 2025
Nouvelle loi sur les données personnelles
La LFPDPPP est publiée et remplace la loi de 2010, avec une dernière réforme le 14 novembre 2025. Elle exige des mesures de sécurité administratives, techniques et physiques pour les données personnelles, et une information immédiate en cas de violation significative.
- 17 juin 2026
Circulaires sur le virement mobile
Banco de México publie les circulaires 9/2026 et 10/2026 au DOF, qui imposent une expérience de virement standardisée dans les applications mobiles. Les participants ont jusqu'au 14 décembre 2026 pour s'y conformer.
- 28 août 2026
Guides de virement mobile, version 1.1
Banco de México publie la version 1.1 des Guías, après la version 1.0 du 16 juin 2026. Les deux entrent en vigueur le 14 décembre 2026 et fixent le flux en quatre étapes, les raccourcis et l'étape de confirmation.
Les règles mexicaines, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe. Les textes de la CNBV, de Banxico et de la loi Fintech sont en espagnol et sont résumés ici.
- Disposiciones de carácter general aplicables a las instituciones de crédito (CUB), article 168 Bis 11, sections III et VI (texte espagnol)
Sécuriser chaque composant technologique tout au long de son cycle de vie
Ce que dit le texte
La CUB rend le dirigeant responsable d'un système de contrôle de la sécurité de l'information couvrant l'infrastructure technologique, qu'elle soit propre ou fournie par des tiers. Les processus, configurations et méthodologies de développement ou d'acquisition de chaque composant doivent être documentés, avec les enregistrements des changements et mises à jour et un inventaire détaillé. Les aspects de sécurité de l'information doivent être pris en compte à chaque étape du cycle de vie : exigences, conception, développement ou acquisition, tests de mise en œuvre et de recette, et processus de mise en production incluant des tests de vulnérabilités et une analyse de code avant la production, des tests périodiques, la gestion des changements, le remplacement et la destruction des informations. Les informations doivent être chiffrées selon leur sensibilité, y compris lors de leur transmission ou de leur stockage, et l'accès est accordé selon le principe du moindre privilège.
Ce que cela implique pour votre application mobile
Votre application bancaire mobile et les API qui la sous-tendent sont des composants de cette infrastructure. La CUB attend des exigences de sécurité, des tests de vulnérabilités et une analyse de code avant la mise en production, puis des tests périodiques.
Comment Ostorlab vous aide
Mobile SAST analyse le binaire APK, AAB ou IPA, y compris les SDK intégrés, sans code source. Mobile DAST teste l'application en cours d'exécution. Les deux s'exécutent depuis votre pipeline CI/CD à chaque build, et SCA couvre les bibliothèques embarquées.
Ce qui reste de votre ressort
Les exigences de sécurité elles-mêmes, les revues d'architecture et de conception, la gestion des accès, ainsi que le remplacement et la destruction des composants.
- CUB, article 168 Bis 12, sections II à VII (texte espagnol)
Analyser les vulnérabilités et mener des tests d'intrusion indépendants
Ce que dit le texte
La CUB exige un calendrier annuel d'analyses de vulnérabilités des composants qui stockent, traitent ou transmettent des informations, priorisé selon la classification des données, avec des examens trimestriels afin que tous les composants critiques soient couverts à la fin de l'année, et une analyse des nouveaux composants avant leur mise en production. Elle impose qu'un tiers indépendant, dont le personnel détient des certifications du secteur, réalise au moins deux fois par an des tests d'intrusion sur différents systèmes et applicatifs, afin de détecter les erreurs, vulnérabilités, fonctionnalités non autorisées ou tout code mettant en risque les informations et les actifs des clients. Le périmètre et la méthodologie doivent être validés par le responsable de la sécurité de l'information. Les conclusions des tests doivent être envoyées à la CNBV dans les 20 jours ouvrés ; les vulnérabilités doivent être classées selon une méthodologie approuvée par le comité des risques ; et les plans de remédiation, validés par le responsable de la sécurité, doivent parvenir à la CNBV dans les 10 jours ouvrés.
Source :CUB, article 168 Bis 12, sections II à VII (texte espagnol)
Ce que cela implique pour votre application mobile
L'application et ses API ont leur place dans ce programme. La CUB sépare le rythme des analyses des tests d'intrusion, et fixe aux deux des délais et des obligations de reporting.
Comment Ostorlab vous aide
Le pentest par agents IA teste l'application et ses API derrière la connexion, sur la version que vous livrez, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif publié. Ostorlab n'est pas le tiers indépendant exigé par la CUB et n'envoie pas de rapports à la CNBV.
Ce qui reste de votre ressort
Le choix du tiers indépendant, la validation du périmètre et de la méthodologie, la classification des vulnérabilités en comité des risques et les rapports à la CNBV.
- CUB, articles 308, 310 et 313 (texte espagnol)
Appliquer les facteurs d'authentification de la CUB
Ce que dit le texte
Pour ouvrir une session, la CUB exige l'identifiant utilisateur et un facteur d'authentification de catégorie 2 (une information que seul l'utilisateur connaît, comme un mot de passe ou un NIP, d'au moins six caractères), de catégorie 3 (une information contenue dans des moyens ou dispositifs électroniques, reçue ou générée par eux, impossible à dupliquer ou altérer, utilisée une seule fois et valable au maximum deux minutes) ou de catégorie 4 (des données biométriques, transformées de sorte que chaque authentification génère un mot de passe à usage unique). Pour les virements vers des comptes destinataires de tiers, l'enregistrement de comptes destinataires, la fixation ou l'augmentation des limites, la modification du moyen de notification, le déverrouillage des identifiants et d'autres opérations listées, l'institution doit exiger un second facteur de catégorie 3 ou 4, en plus de celui utilisé pour ouvrir la session.
Ce que cela implique pour votre application mobile
Le second facteur doit être imposé par le serveur à chaque opération listée, y compris lorsque l'application, ou un attaquant, saute une étape. Les codes à usage unique doivent être à usage unique et de courte durée, et les données biométriques doivent produire des valeurs à usage unique.
Comment Ostorlab vous aide
Les tests authentifiés se connectent avec des codes à usage unique et testent l'application effective de la MFA et les parcours d'authentification renforcée, y compris les tentatives de manipulation par un attaquant, ainsi que les appels d'API qui les sous-tendent. Ostorlab saisit les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test.
Ce qui reste de votre ressort
Le choix et le déploiement des facteurs, le processus d'enrôlement biométrique et le prestataire qui génère les codes.
- CUB, articles 316 Bis 2 et 316 Bis 3 (texte espagnol)
Maîtriser les sessions et verrouiller les comptes
Ce que dit le texte
Une fois l'utilisateur authentifié, la CUB exige que la session ne puisse pas être utilisée par un tiers. La session doit se terminer automatiquement après plus de vingt minutes d'inactivité, et après un délai maximal d'une minute pour Pago Móvil, les distributeurs automatiques et les terminaux point de vente. Elle doit aussi se terminer en cas de changements pertinents des paramètres de communication, comme l'identification du dispositif, la plage d'adresses des protocoles de communication ou la localisation géographique. Les sessions simultanées avec le même identifiant utilisateur sont interdites, avec information de l'utilisateur. Les institutions doivent bloquer automatiquement les mots de passe et autres facteurs d'authentification après au plus cinq tentatives consécutives échouées, et après une période d'inactivité définie dans leurs politiques, qui ne peut excéder un an. L'utilisateur doit pouvoir déverrouiller ses facteurs ou réinitialiser ses identifiants via la procédure de souscription ou un facteur de catégorie 1.
Source :CUB, articles 316 Bis 2 et 316 Bis 3 (texte espagnol)
Ce que cela implique pour votre application mobile
Les délais d'expiration, la règle de session unique et le seuil de verrouillage sont des comportements concrets de l'application et de son backend. Sauter une étape dans l'application ne doit pas empêcher le serveur de refuser l'opération.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et le comportement de verrouillage, ainsi que les appels d'API qui les sous-tendent.
Ce qui reste de votre ressort
Les valeurs de délai d'expiration, la procédure de verrouillage et de déverrouillage, et les notifications aux clients.
- CUB, articles 309, 316 Bis 4 et 316 Bis 10 (texte espagnol)
Garder les identifiants illisibles et protégés
Ce que dit le texte
La CUB impose aux institutions d'empêcher la lecture, sur l'écran du dispositif d'accès, des informations d'identification et d'authentification fournies par l'utilisateur, et de veiller à ce que seul l'utilisateur reçoive, active, connaisse, déverrouille et rétablisse les facteurs d'authentification. Elle interdit les mécanismes, algorithmes ou procédures permettant à l'institution de connaître, récupérer ou déchiffrer les informations d'authentification, et interdit au personnel de demander aux utilisateurs leurs facteurs de catégorie 2 ou 3. Elle exige le chiffrement des messages ou des canaux de communication pour les informations sensibles entre le dispositif d'accès et l'institution, le chiffrement des mots de passe et NIP stockés, l'administration des clés cryptographiques dans des dispositifs de haute sécurité tels que les HSM, et, pour la banque électronique à base de cartes, des certifications du secteur comme PCI-DSS, PA-DSS et PTS.
Source :CUB, articles 309, 316 Bis 4 et 316 Bis 10 (texte espagnol)
Ce que cela implique pour votre application mobile
Les identifiants et les codes ne devraient jamais apparaître à l'écran, rester en clair sur le téléphone ou transiter sans protection vers le backend, et les mots de passe ne doivent jamais être envoyés par SMS ou e-mail sans chiffrement.
Comment Ostorlab vous aide
Ostorlab détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Il recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, et détecte les erreurs de configuration qui affaiblissent la protection du transport et des sessions.
Ce qui reste de votre ressort
La gestion des clés, l'exploitation des HSM, le programme de certification PCI-DSS et PTS et les règles sur les données de carte.
- Circulaires 9/2026 et 10/2026 de Banco de México (DOF, 17 juin 2026) et Guías, version 1.1 (texte espagnol)
Livrer le flux de virement mobile standardisé
Ce que dit le texte
Les circulaires 9/2026 et 10/2026 de Banxico modifient les règles du SPEI et les règles applicables aux opérations des institutions de crédit pour exiger que les instructions de virements électroniques présentées depuis des dispositifs mobiles respectent les Guías para la homologación de la experiencia de usuario. Les guides fixent un flux unique d'au plus quatre étapes : authentification, saisie des informations du virement, vérification et notification. Ils exigent un raccourci pour démarrer un virement sur les écrans de connexion et d'accueil, un écran de revue où l'utilisateur valide le bénéficiaire, le montant et le motif, et une autorisation avec le facteur d'authentification désigné. Les données du bénéficiaire lues depuis un code QR ne peuvent pas être modifiées. Les participants ont jusqu'au 14 décembre 2026 pour se conformer.
Ce que cela implique pour votre application mobile
À partir du 14 décembre 2026, le flux de virement de votre application est prescrit en détail, et il doit toujours respecter les exigences d'authentification de la CUB derrière les écrans.
Comment Ostorlab vous aide
Le pentest par agents IA parcourt le flux de virement avec vos comptes de test et teste la logique métier des paiements, et les tests d'API vérifient les appels derrière l'enregistrement des bénéficiaires et les virements, avec les requêtes et réponses à l'appui pour chaque résultat.
Ce qui reste de votre ressort
La conception et la réalisation de l'UX, le choix du facteur d'authentification désigné et le calendrier de mise en production.
- Circulaire 14/2017, règle 58a, section I, et règle 46a (texte espagnol)
Répondre aux exigences de sécurité du SPEI
Ce que dit le texte
La circulaire 14/2017 impose aux participants au SPEI de tenir des politiques et procédures de sécurité documentées : une zone dédiée à la sécurité, des protocoles de communication sûrs, des outils de détection des logiciels malveillants, des outils de détection et de gestion des vulnérabilités de l'infrastructure informatique, la détection et la gestion des incidents de sécurité, la collecte centralisée des journaux avec détection d'anomalies, et des tests d'intrusion sur l'infrastructure technologique selon la périodicité, les rapports et les qualifications des testeurs prévus à l'appendice M du Manuel. Le processus de développement de l'application SPEI doit intégrer la sécurité à chaque étape, examiner l'application de façon statique et dynamique, et conserver les journaux d'accès et d'opérations pendant au moins six mois. Les participants doivent notifier les incidents et menaces imminentes à l'administrateur du système par téléphone et par communication signée numériquement dans les soixante minutes.
Source :Circulaire 14/2017, règle 58a, section I, et règle 46a (texte espagnol)
Ce que cela implique pour votre application mobile
Si vous êtes participant au SPEI, l'infrastructure et les applications qui se connectent au SPEI sont dans le périmètre, et le délai de notification est court. Une partie de ce travail incombe aux mêmes équipes que votre canal mobile.
Comment Ostorlab vous aide
Ostorlab teste l'application mobile et les API qu'elle appelle, y compris les appels qui atteignent les services de paiement, avec les requêtes et réponses à l'appui. Il ne teste pas l'application SPEI ni son infrastructure, et ne notifie pas l'administrateur.
Ce qui reste de votre ressort
Le programme de sécurité SPEI, les contrôles des appendices M et AN, le calendrier des tests d'intrusion et les notifications à Banxico.
- Disposiciones aplicables a las IFPE (DOF, 28 janvier 2021), articles 8, 11, 12, 34 et 42 ; loi Fintech, article 76 (texte espagnol)
Fintech : facteurs indépendants, verrouillage, pentests et API
Ce que dit le texte
Les dispositions de la CNBV applicables aux institutions de fonds de paiement électronique (IFPE) exigent au moins deux facteurs d'authentification indépendants pour les modifications de bénéficiaires, les changements de facteurs d'authentification, les demandes de relevés et les modifications du moyen de notification. Elles exigent la fin automatique de la session après cinq minutes d'inactivité, la détection des changements de paramètres de communication, un blocage du facteur pendant dix minutes après trois tentatives consécutives échouées puis un blocage permanent après une nouvelle tentative échouée, et des procédures permettant au client de désactiver temporairement les opérations. Les IFPE doivent confier à une société indépendante, dont le personnel est certifié, des tests d'intrusion au moins tous les deux ans, envoyer les conclusions à Banxico et à la CNBV dans les vingt jours ouvrés, déposer un plan de remédiation pour les constats de criticité élevée ou très élevée dans les vingt jours ouvrés et retester dans les deux mois. L'article 76 de la loi Fintech impose aussi des interfaces de programmation d'applications standardisées pour les données ouvertes, agrégées et transactionnelles, et l'interruption de l'accès lorsque des vulnérabilités mettent en risque les informations des clients, avec notification aux superviseurs dans les deux heures suivant la détection.
Ce que cela implique pour votre application mobile
Les règles des wallets sont plus prescriptives sur le canal mobile que les règles bancaires à certains endroits : délais plus courts, trois tentatives avant blocage et un plancher de deux ans pour les tests d'intrusion. Les interfaces d'API transportent des données clients et ont leurs propres obligations de sécurité et d'interruption.
Comment Ostorlab vous aide
Ostorlab teste ces comportements dans l'application et ses API avec vos comptes de test : indépendance des facteurs, délais d'expiration de session, verrouillage et déverrouillage, et les appels derrière les modifications de bénéficiaires, avec un exploit rejouable pour chaque résultat d'un agent IA.
Ce qui reste de votre ressort
Le contrat de test d'intrusion, les rapports à Banxico et à la CNBV, le plan de remédiation, les autorisations d'API et les notifications aux clients.
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares (DOF, 20 mars 2025 ; dernière réforme 14 novembre 2025), articles 18 à 20 (texte espagnol)
Protéger les données personnelles au titre de la LFPDPPP
Ce que dit le texte
La LFPDPPP, publiée le 20 mars 2025 et réformée une dernière fois le 14 novembre 2025, impose à tout responsable de maintenir des mesures de sécurité administratives, techniques et physiques protégeant les données personnelles contre les dommages, la perte, l'altération, la destruction ou l'utilisation, l'accès ou le traitement non autorisés. Les mesures sont déterminées selon le risque existant, les conséquences possibles pour les personnes concernées, la sensibilité des données et le développement technologique, et ne peuvent pas être plus faibles que celles appliquées aux informations propres du responsable. Les violations qui affectent de manière significative les droits patrimoniaux ou moraux des personnes concernées doivent leur être signalées immédiatement. Toute personne impliquée dans le traitement doit garder la confidentialité des données personnelles, obligation qui survit à la fin de la relation.
Ce que cela implique pour votre application mobile
Les données personnelles dans l'application, en transit et dans le backend ont besoin d'une protection technique, et l'institution doit pouvoir informer immédiatement les clients lorsqu'une violation est significative.
Comment Ostorlab vous aide
Ostorlab recherche les données personnelles et les jetons dans le stockage local, les caches, les journaux, les captures d'écran et les sauvegardes de l'application, et teste si les API derrière l'application exposent les données d'autres clients.
Ce qui reste de votre ressort
L'avis de confidentialité, les droits des personnes concernées, l'évaluation des violations et les communications aux clients.
Synthèse des textes publics de la CNBV, de Banxico et de la loi Fintech, vérifiés le 27 septembre 2026. Les textes sont en espagnol ; les exigences sont résumées d'après les originaux. Les appendices M et AN figurent dans le Manuel du SPEI cité par les circulaires et ne sont pas cités ici. Cette page ne constitue pas un avis juridique.
Les règles mexicaines, contrôle par contrôle
Les contrôles visés par les textes de la CNBV, de Banxico et de la loi Fintech, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Tests de sécurité dans le cycle de développement, avant la productionCUB 168 Bis 11, III | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, depuis votre pipeline CI/CD à chaque build. Détails | Résultats avec contexte de code décompilé, trafic, traces d'exécution et captures d'écran, par build |
| Tests d'intrusion indépendants au moins deux fois par anCUB 168 Bis 12, IV | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Ostorlab n'est pas le tiers indépendant exigé par la CUB. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Calendrier annuel d'analyses de vulnérabilités et analyses avant productionCUB 168 Bis 12, III | Mobile DAST exécute l'application à chaque build et les versions publiées sur les stores sont scannées sans déclenchement manuel, ajoutant la couverture de l'application et des API à votre programme. Détails | Résultats de scan par build et par version publiée sur les stores |
| Classification des vulnérabilités et plans de remédiationCUB 168 Bis 12, V et VI | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre, avec des résultats évalués et regroupés en tickets. Détails | Vulnérabilités identifiées avec recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| Second facteur d'authentification pour les virements et modifications de compteCUB 308, 310 et 313 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Sessions, changements de paramètres de communication et verrouillageCUB 316 Bis 2 et 316 Bis 3 | Teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et le comportement de verrouillage. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Identifiants lisibles à l'écran ou récupérables dans l'applicationCUB 309 et 316 Bis 4 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
| Chiffrement des données et des facteurs d'authentification en transit et au reposCUB 316 Bis 10 | Intercepte le trafic de l'application même avec TLS pinning et vérifie ce que l'application envoie et reçoit, y compris les données d'authentification. Détails | Requêtes et réponses à l'appui de chaque résultat d'API |
| Flux de virement mobile standardisé à partir du 14 décembre 2026Circulaires 9/2026 et 10/2026, Guías 1.1 | Parcourt le flux de virement avec vos comptes de test et teste la logique métier des paiements, dans l'application et via les API. Détails | Étapes de reproduction pour chaque résultat de flux, avec les requêtes et réponses à l'appui |
| Notification des incidents à Banxico, à la CNBV et aux clientsSPEI règle 46a ; CUB annexe 64 ; IFPE article 42 | Ostorlab ne notifie ni les autorités ni les clients. Ses résultats donnent à vos équipes les étapes de reproduction et les journaux pour enquêter et déclarer plus vite. | Résultats avec preuves techniques à joindre à un dossier d'incident |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance SOC, la réponse aux incidents et leur signalement à la CNBV, à Banxico et aux clients, l'application et l'infrastructure SPEI, le test d'intrusion indépendant exigé par la CUB, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles mexicains à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque technologique, fondée sur la CUB, les règles SPEI et les textes fintech et de protection des données.
Application dans le programme
Intégrez l'application mobile et ses API au périmètre des tests d'intrusion de la CUB et au calendrier annuel d'analyses de vulnérabilités.
Second facteur
Vérifiez que les virements vers des tiers, l'enregistrement de comptes destinataires, la modification des limites et du moyen de notification exigent un facteur de catégorie 3 ou 4 côté serveur.
Sessions et verrouillage
Vérifiez le délai d'inactivité de vingt minutes, la limite d'une minute pour Pago Móvil, la règle de session unique et le verrouillage après au plus cinq tentatives échouées.
Identifiants et secrets
Recherchez dans le package de l'application les clés d'API, jetons et identifiants, confirmez qu'aucun identifiant n'est affiché à l'écran et renouvelez ceux qui sont fonctionnels.
Composants et délais
Tenez une liste versionnée des SDK et bibliothèques natives de chaque version et fixez des délais de remédiation selon la gravité.
Flux de virement mobile
Testez le flux des guides avec vos comptes : raccourci, quatre étapes, revue du bénéficiaire, confirmation avec le facteur désigné, avant le 14 décembre 2026.
Étapes d'incident SPEI
Confirmez que les étapes de notification en soixante minutes à Banxico sont documentées, et que les résultats sont joints aux dossiers de remédiation et d'incident.
Données personnelles
Vérifiez le stockage, les caches, les journaux et les captures d'écran, et validez avec votre équipe juridique les étapes d'information en cas de violation au titre de la LFPDPPP.
Une liste indicative, et non un modèle de la CNBV ou de Banxico. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Tests authentifiésTestez les facteurs d'authentification, les codes à usage unique, les parcours d'authentification renforcée et les règles de verrouillage avec vos comptes de test.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes, les virements et les paiements.En savoir plus
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- Disposiciones de carácter general aplicables a las instituciones de crédito (Circular Única de Bancos)CNBV, publiées au DOF le 2 décembre 2005, texte compilé avec les modifications jusqu'au 1er septembre 2026. Sécurité de l'information (articles 168 Bis 11 et 168 Bis 12), banque électronique (articles 306 à 316 Bis 19) et annexes 64, 64 Bis et 72. Texte espagnol
- Circular 14/2017 : Reglas del Sistema de Pagos Electrónicos Interbancarios (SPEI), texte compiléBanco de México, publiée au DOF le 4 juillet 2017, incluant les modifications jusqu'à la circulaire 9/2026 du 17 juin 2026. Règles 46a et 58a, appendices M et AN. Texte espagnol
- Circular 9/2026 : modifications des règles SPEI sur l'expérience de virement mobileBanco de México, publiée au DOF le 17 juin 2026, en vigueur le jour bancaire suivant avec une conformité exigée au 14 décembre 2026. Ajoute les Guías et les exigences d'expérience mobile aux règles du SPEI. Texte espagnol
- Circular 10/2026 : modifications de la circulaire 3/2012 sur l'expérience de virement mobileBanco de México, publiée au DOF le 17 juin 2026. Impose aux institutions de crédit de suivre les Guías pour les virements instruits depuis des dispositifs mobiles. Texte espagnol
- Guías para la homologación de la experiencia de usuario en transferencias electrónicas de fondos a través de dispositivos móvilesBanco de México, version 1.0 publiée le 16 juin 2026, version 1.1 publiée le 28 août 2026, toutes deux en vigueur le 14 décembre 2026. Flux de virement en quatre étapes, raccourcis, revue du bénéficiaire et confirmation. Texte espagnol
- Ley para Regular las Instituciones de Tecnología Financiera (loi Fintech) et les dispositions sur les API standardiséesLoi publiée au DOF le 9 mars 2018, avec des réformes ultérieures. Article 76 sur les interfaces de programmation d'applications standardisées. Dispositions de la CNBV sur les API standardisées publiées au DOF le 4 juin 2020, avec des exigences de sécurité pour les fournisseurs de données. Texte espagnol
- Disposiciones aplicables a las instituciones de fondos de pago electrónicoCNBV, publiées au DOF le 28 janvier 2021. Facteurs d'authentification, sessions et verrouillage (articles 8 à 12), tests d'intrusion (article 34) et notification des incidents (article 42). Texte espagnol
- Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP)Publiée au DOF le 20 mars 2025, dernière réforme le 14 novembre 2025. Mesures de sécurité, information en cas de violation et confidentialité (articles 18 à 20). Texte espagnol
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Évaluez votre application bancaire mobile comme le décrivent la CNBV et Banxico
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests authentifiés de votre application et de vos API avec notre équipe.