Les règles de la BCRA pour l'application bancaire mobile que vos clients installent.

1. 01

   Règles sur les services financiers numériques, 3.2 et 3.2.1 (texte en espagnol)

   Sécuriser les applications fournies aux clients

   Ce que dit le texte

   Les entités doivent concevoir et mettre en œuvre des mesures de sécurité pour les appareils et les applications qu'elles fournissent aux clients, ce qui inclut la banque mobile, la banque en ligne et les portefeuilles numériques. Les données échangées doivent rester chiffrées pendant toute l'interaction, les sessions non autorisées doivent être détectées et terminées, et le service doit être désactivé en cas de défaillance qui compromet sa sécurité. Pour les applications qui s'exécutent dans des environnements contrôlés par le client, les contrôles minimaux comprennent le blocage de l'accès depuis les appareils qui ne respectent pas les critères d'admissibilité, l'atténuation des risques liés à la configuration du système d'exploitation mobile, la demande des seules autorisations nécessaires, l'association de l'application à l'appareil et au client lors de l'enrôlement ou d'une réinstallation, des contrôles sur les changements de carte SIM et de ligne, ainsi que le blocage de l'accès et le verrouillage automatique de la session après inactivité.

   Source :Règles sur les services financiers numériques, 3.2 et 3.2.1 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Le texte cite directement l'application de banque mobile. Les téléphones rootés ou jailbreakés, la réinstallation sur un nouvel appareil et les sessions inactives sont des cas que vous devez traiter et pouvoir démontrer.

   Comment Ostorlab vous aide

   Mobile Shielding Scan exécute l'application dans des environnements rootés et jailbreakés, tente de contourner la détection du root et du jailbreak, l'anti-altération, l'anti-instrumentation et le TLS pinning, et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner. Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions.

   Ce qui reste de votre ressort

   Vos critères d'admissibilité des appareils et la façon dont vous les communiquez aux clients, les choix d'autorisations de l'application, l'association à l'appareil côté serveur et les contrôles de changement de carte SIM avec les opérateurs.

2. 02

   Règles sur les services financiers numériques, 3.1 et 3.1.1 (texte en espagnol)

   Exiger la MFA pour les transactions et les actions critiques

   Ce que dit le texte

   Le client doit être identifié et authentifié pour toute transaction, avec une authentification multifacteur adaptée aux niveaux de risque, aux résultats du suivi transactionnel et aux seuils. L'authentification multifacteur ou l'identification numérique est requise pour confirmer au moins les actions critiques suivantes : création, activation ou réactivation de facteurs d'authentification, souscription à de nouveaux produits ou à des crédits préapprouvés, modification des points de contact ou des paramètres de transaction, ajout de comptes de tiers pour les virements, et transactions qui s'écartent des schémas surveillés.

   Source :Règles sur les services financiers numériques, 3.1 et 3.1.1 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Changer de numéro de téléphone, enregistrer un nouveau bénéficiaire ou réenrôler un appareil sont des étapes classiques d'une prise de contrôle de compte. Le second facteur doit être imposé par le serveur pour chacune de ces actions, y compris lorsque l'application ou un attaquant saute une étape.

   Comment Ostorlab vous aide

   Ostorlab saisit les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test et teste 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 derrière les modifications de compte.

   Ce qui reste de votre ressort

   Les seuils de risque, les règles de suivi transactionnel et le processus d'identification numérique.

3. 03

   Règles sur les services financiers numériques, 3.4 à 3.4.3 ; règles sur la technologie et la sécurité, 5.7.2.2 et 5.7.2.3 (texte en espagnol)

   Respecter les règles sur les mots de passe et les codes à usage unique

   Ce que dit le texte

   Les facteurs d'authentification des clients ne peuvent pas être connus du personnel ni de tiers, ne peuvent être conservés que pour leur vérification et doivent être protégés par des techniques cryptographiques. Les secrets mémorisés doivent compter au moins 8 caractères avec des minuscules, des majuscules, des chiffres et des caractères spéciaux, avec des limites sur la saisie automatisée, par exemple un Captcha, et sur les tentatives échouées. Les codes à usage unique doivent être valables 120 secondes au plus, compter au moins 6 chiffres et circuler sur un canal chiffré. Les authentificateurs hors bande ne doivent pas être visibles lorsque l'appareil qui les reçoit est verrouillé. Ces règles s'ajoutent aux exigences générales d'authentification, qui demandent un canal protégé et le hachage ou le chiffrement des secrets stockés.

   Source :Règles sur les services financiers numériques, 3.4 à 3.4.3 ; règles sur la technologie et la sécurité, 5.7.2.2 et 5.7.2.3 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   La durée de validité des codes, les limites de tentatives et les règles de mot de passe sont appliquées par votre backend, et un testeur mobile peut vérifier chacune d'elles. Les codes et mots de passe ne devraient jamais non plus se trouver en clair sur le téléphone ou dans les journaux.

   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 l'application de la MFA, et l'analyse du trafic montre comment les identifiants circulent de l'application vers le backend. Ostorlab recherche aussi les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran.

   Ce qui reste de votre ressort

   Votre politique de mots de passe, la génération des OTP et leurs graines, les contrôles du fournisseur SMS et les réglages de notification des téléphones des clients.

4. 04

   Règles sur la technologie et la sécurité, 9.2.2 (texte en espagnol)

   Faire réaliser des tests de vulnérabilité indépendants, et tester avant chaque version

   Ce que dit le texte

   Les entités doivent définir et exécuter des plans de test des logiciels fondés sur l'analyse des risques, combinant tests automatisés et manuels, avec des tests spécifiques documentés avant la mise en production de modifications ou de nouvelles versions de logiciels internes ou de tiers, et des résultats acceptés avant la production. Les applications qui traitent des données de clients, transactionnelles ou financières doivent faire l'objet de tests de vulnérabilité réalisés par des tiers indépendants. Les constats issus des revues de code source et des tests de sécurité doivent être documentés, et leurs risques enregistrés, évalués et traités.

   Source :Règles sur la technologie et la sécurité, 9.2.2 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile traite des données clients et transactionnelles : elle doit donc faire l'objet de tests de vulnérabilité indépendants. Chaque nouvelle version de l'application doit aussi passer des tests documentés avant d'arriver dans les stores.

   Comment Ostorlab vous aide

   Ostorlab lance des scans automatisés depuis votre pipeline CI/CD à chaque build et surveille les versions publiées sur les stores sans déclenchement manuel. Le pentest par agents IA teste l'application et ses API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.

   Ce qui reste de votre ressort

   Le choix du testeur indépendant et la décision de savoir si un test est recevable, les tests manuels et l'approbation des versions.

5. 05

   Règles sur la technologie et la sécurité, 9.2 et 9.2.1 (texte en espagnol)

   Intégrer la sécurité au cycle de vie du logiciel

   Ce que dit le texte

   Les entités doivent établir un cadre pour le cycle de vie du développement, de l'acquisition et de la maintenance des logiciels, qui comprend des normes de sécurité, la modélisation des menaces, des critères pour les tests logiciels et la revue de code, et des procédures d'évaluation des composants de tiers avant leur intégration, y compris l'open source, les API et les algorithmes d'IA. Les exigences de sécurité doivent être définies et documentées, et les évaluations de sécurité documentées notamment lorsque des composants de tiers sont intégrés ou lorsque les systèmes échangent des données avec des tiers. Des mécanismes doivent vérifier l'intégrité du logiciel tout au long du cycle de vie.

   Source :Règles sur la technologie et la sécurité, 9.2 et 9.2.1 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Les SDK intégrés à votre application sont des composants de tiers couverts par ce cadre. Chacun devrait être évalué avant sa mise en production, et les applications développées par une agence ou un prestataire relèvent des mêmes règles.

   Comment Ostorlab vous aide

   Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans besoin du code source, avec une analyse de propagation (taint analysis) qui couvre les SDK intégrés. La SCA identifie les bibliothèques compilées statiquement que les scanners basés sur les manifestes peuvent manquer, et Ostorlab montre ce que l'application et ses SDK échangent avec les backends sur le réseau.

   Ce qui reste de votre ressort

   Votre cadre de cycle de vie, vos modèles de menaces, les revues de code et l'évaluation des prestataires.

6. 06

   Règles sur la technologie et la sécurité, 5.8.2 et 9.2.2 (texte en espagnol)

   Gérer les vulnérabilités de tous les systèmes et applications

   Ce que dit le texte

   Les entités doivent établir un processus de gestion des vulnérabilités pour tous les systèmes et applications, les leurs comme ceux de tiers, lié à la gestion des incidents. Il comprend des points de contact pour signaler des vulnérabilités dans les services internes et externes, l'analyse de l'impact des vulnérabilités publiées ou signalées, un plan et un calendrier de traitement selon la criticité, des mesures d'atténuation alternatives lorsqu'aucune mise à jour n'est disponible, et la transmission d'informations au processus de mise à jour de sécurité. Les procédures de maintenance doivent couvrir l'évaluation et la mise à jour des composants obsolètes, les leurs comme ceux de tiers.

   Source :Règles sur la technologie et la sécurité, 5.8.2 et 9.2.2 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Les bibliothèques de votre application sont du logiciel que vous livrez. Chacune a besoin d'une version connue, d'une criticité lorsqu'une vulnérabilité apparaît et d'une date de traitement que vous pouvez prouver.

   Comment Ostorlab vous aide

   SCA identifie les bibliothèques compilées statiquement et les rapproche des vulnérabilités connues, version après version. 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é.

   Ce qui reste de votre ressort

   Le point de contact pour le signalement des vulnérabilités, les correctifs des serveurs et de l'infrastructure, et les décisions d'acceptation du risque.

7. 07

   Règles sur la technologie et la sécurité, 5.7.4 ; loi 25.326, art. 9 (texte en espagnol)

   Protéger les données clients sur l'appareil et en transit

   Ce que dit le texte

   Selon la classification des données, les entités doivent chiffrer l'information en transit, stockée dans les systèmes ou sur les appareils des utilisateurs, masquer et protéger les données dans les environnements hors production, et mettre en place des contrôles pour détecter le transfert non autorisé d'informations confidentielles. La loi 25.326 sur la protection des données personnelles demande au responsable de prendre les mesures techniques et organisationnelles nécessaires pour garantir la sécurité et la confidentialité des données personnelles, et éviter leur altération, leur perte, ou leur consultation ou traitement non autorisés.

   Source :Règles sur la technologie et la sécurité, 5.7.4 ; loi 25.326, art. 9 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Les jetons, les données de compte et les pièces d'identité capturés par l'application ne devraient pas se trouver en clair sur le téléphone ni circuler sans protection vers le backend.

   Comment Ostorlab vous aide

   Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, et vérifie les erreurs de configuration qui affaiblissent la protection du transport et des sessions. Il détecte aussi les clés d'API, jetons et identifiants présents dans le paquet de l'application et vérifie s'ils fonctionnent.

   Ce qui reste de votre ressort

   La classification des données, la gestion des clés, la prévention des fuites de données et vos obligations envers l'autorité de protection des données.

8. 08

   Règles sur les services financiers numériques, 1.2 (texte en espagnol)

   Informer la BCRA avant de lancer un nouveau service numérique

   Ce que dit le texte

   Les entités doivent informer le département d'audit externe des systèmes de la BCRA au moins 60 jours avant la mise en production d'un projet qui implique un nouveau produit ou un nouveau type de service financier numérique. La notification comprend les mesures de protection adoptées, les facteurs d'authentification utilisés, les activités de surveillance prévues et les activités de gestion des cyberincidents.

   Source :Règles sur les services financiers numériques, 1.2 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Un nouveau produit mobile, ou un nouveau type de service dans l'application, doit voir ses mesures de protection décrites avant le lancement. Les résultats de test de la version de pré-lancement aident à étayer cette description.

   Comment Ostorlab vous aide

   Ostorlab teste la version de pré-lancement et les API qui la servent, y compris en préproduction derrière votre pare-feu grâce au scan on-premises, et vous remet un rapport avec des preuves pour chaque résultat.

   Ce qui reste de votre ressort

   La notification elle-même, son contenu et le dialogue avec la BCRA.

9. 09

   Lignes directrices pour la réponse et le rétablissement face aux cyberincidents, section 3, modifiées par la Communication « A » 8280 (texte en espagnol)

   Signaler les cyberincidents significatifs en une heure

   Ce que dit le texte

   Les entités doivent notifier au département d'audit externe des systèmes de la BCRA les cyberincidents qui affectent la prestation normale des services aux clients ou mettent en risque la disponibilité, l'intégrité ou la confidentialité de l'information, y compris la perte ou la divulgation non autorisée de données clients. La notification initiale est due dans la première heure suivant la survenue ou la détection de l'incident, suivie de mises à jour et d'un rapport de clôture dans les 5 jours calendaires après la résolution.

   Source :Lignes directrices pour la réponse et le rétablissement face aux cyberincidents, section 3, modifiées par la Communication « A » 8280 (texte en espagnol)

   Ce que cela implique pour votre application mobile

   Une faille de l'application ou de l'API qui expose des données clients peut devenir un incident à déclarer. La trouver avant la mise en production coûte moins cher.

   Comment Ostorlab vous aide

   Ostorlab ne détecte, ne traite ni ne signale les incidents. Il vous aide à trouver et corriger les vulnérabilités de l'application et des API avant qu'elles ne mènent à un incident.

   Ce qui reste de votre ressort

   La détection, la réponse aux incidents, la notification dans l'heure et les rapports de suivi.

Synthèse de textes en espagnol publiés par la BCRA et de la loi 25.326, tels que modifiés, vérifiés le 27 septembre 2026. Certains textes s'appliquent à des types de licences spécifiques, comme indiqué. Cette page ne constitue pas un avis juridique.