Les régulateurs bancaires veulent la preuve que vos applications résistent.
De Francfort à Riyad, Singapour et New York, les autorités de surveillance attendent désormais des banques qu'elles testent souvent leurs applications mobiles et leurs API, derrière la connexion, et qu'elles prouvent chaque correction. Voici, en termes simples et avec les sources officielles, ce que demande chaque régulateur, et comment Ostorlab accompagne le volet tests.
- UE : les règles de tests de DORA, et le plan d'action de la BCE attendu pour le 31 octobre 2026
- Moyen-Orient : Émirats arabes unis, Arabie saoudite, Qatar, Koweït et Jordanie
- Asie : Pakistan, Bangladesh, Japon, Singapour et Indonésie
- Amériques : États-Unis et Brésil, ainsi que l'Ukraine en Europe
Réglementations
Les trois textes les plus demandés
Chaque page résume ce que demande la réglementation, renvoie au texte officiel et y rattache les tests d'Ostorlab.
- Lettre de la BCE sur les cybermenaces facilitées par l'IAPour les banques sous la surveillance directe de la BCE : ce que la lettre du 7 juillet 2026 demande dans le plan d'action attendu pour le 31 octobre 2026.Lire la page
- Tests de résilience DORA (articles 24 à 27)Pour les entités financières de l'UE : le programme de tests, les tests énumérés par DORA et la place des tests de pénétration fondés sur la menace (TLPT).Lire la page
- Notice 2176 de la CBUAE et contrôles antifraude mobilesPour les institutions financières agréées aux Émirats arabes unis : les règles de prévention de la fraude de la CBUAE, la Notice 2176 et la manière de tester les défenses de votre application.Lire la page
Ces pages résument des textes publics pour vous aider à planifier vos tests. Elles ne constituent pas un avis juridique. Ostorlab vous accompagne dans vos obligations de test ; il ne vous rend pas conforme à lui seul, vérifiez donc avec votre équipe conformité comment il s'inscrit dans votre démarche.
Par pays
Réglementations bancaires couvertes
Une page par régulateur, chacune fondée sur les textes officiels : ce qu'ils attendent de votre application mobile et de ses API, comment Ostorlab vous aide pour les tests, et ce qui reste de votre ressort.
Union européenne et Europe
- UE : tests de résilience DORAScans automatisés hebdomadaires, tests statiques et dynamiques, tests annuels et TLPT au titre de DORA et de ses normes techniques.
- UE : lettre de la BCE sur les cybermenaces facilitées par l'IALe plan d'action que les banques importantes doivent remettre à la BCE d'ici le 31 octobre 2026, domaine prioritaire par domaine prioritaire.
- Ukraine : règles de la NBU sur la sécurité de l'information et l'authentificationPentests périodiques, OWASP, verrouillage après cinq tentatives, expiration de session à dix minutes et protection contre l'altération : les règles de la NBU pour les applications bancaires mobiles.
- Royaume-Uni : résilience opérationnelle PRA et FCATolérances d'impact, tests de scénarios et CBEST, ainsi que SCA, externalisation et signalement des incidents : les règles PRA et FCA pour les applications bancaires mobiles et leurs API.
- Suisse : résilience opérationnelle et cybersécurité FINMALa circulaire 2023/1, les communications sur le cyber et la nLPD révisée appliquées aux applications bancaires mobiles et à leurs API : pentests, données critiques, exercices et reporting.
- Turquie : règles bancaires du BDDKPentests annuels, durcissement de l'application, restrictions sur les OTP par SMS et onboarding à distance : les règles du BDDK, de la CBRT et du KVKK pour les applications bancaires mobiles.
Moyen-Orient
- Émirats arabes unis : règles de la CBUAE et Notice 2176Prévention de la fraude, authentification, sessions, API et protections de l'appareil dans les textes publics de la CBUAE.
- Arabie saoudite : SAMA Cyber Security FrameworkPentests annuels, tests de sécurité de chaque changement, MFA sur la banque en ligne et détection du root : les règles de la SAMA pour les applications bancaires mobiles.
- Qatar : réglementation de la QCB sur les risques technologiquesPentests semestriels, tests de l'application avant et après la mise en production, et données conservées au Qatar : les règles de la QCB pour les applications bancaires mobiles.
- Koweït : Cyber and Operational Resilience Framework de la CBKLes règles du CORF de la CBK pour les applications bancaires mobiles et les API : appareils rootés, MFA, sessions, OTP et tests de pénétration.
- Jordanie : Cyber Risks Resilience Instructions de la CBJLes règles de la CBJ pour les applications bancaires mobiles et les API : tests de pénétration annuels, TLS pinning, appareils rootés, MFA et limites de session.
- Bahreïn : règles cyber de la CBB et PDPLPentests semestriels, évaluations de l'application, des API et des connexions tierces, et authentification de la banque électronique : les règles de la CBB pour les applications bancaires mobiles.
- Oman : cadre de cybersécurité et de résilience de la CBOLe cadre BM 1194 de la CBO et ses circulaires antifraude appliqués aux applications bancaires mobiles et à leurs API : pentests annuels, MFA, sessions et contrôles sur les stores.
- Égypte : cybersécurité et règles de paiement de la CBECe que le cadre de cybersécurité financière de la CBE, les règles de banque en ligne et de paiement mobile et la loi sur la protection des données personnelles demandent à votre application bancaire mobile et à ses API.
Afrique
- Maroc : règles de Bank Al-Maghrib, DNSSI et CNDPTests d'intrusion, règles de sécurité du m-wallet, loi 05-20 et DNSSI, et obligations sur les données personnelles au titre de la loi 09-08, appliquées aux applications bancaires mobiles et à leurs API.
- Nigeria : le cadre de cybersécurité de la CBNÉvaluations annuelles de vulnérabilité, tests d'intrusion annuels, scans trimestriels, sécurité des API d'open banking et garanties de la NDPA, appliqués aux applications bancaires mobiles et aux API qui les sous-tendent.
- Kenya : la cybersécurité selon la CBKLa Guidance Note on Cybersecurity de 2017, la directive pour les prestataires de services de paiement, les règles du National Payment System et la loi sur la protection des données, appliquées aux applications bancaires mobiles et aux API.
- Afrique du Sud : les Joint Standards de la FSCA et de la PAÉvaluation de vulnérabilité, tests d'intrusion, tests de sécurité applicative, MFA et garanties de la POPIA, appliqués aux applications bancaires mobiles et aux API qui les sous-tendent.
Asie du Sud
- Pakistan : sécurité de la banque numérique selon la SBPLe cadre de gestion des risques technologiques de la SBP et ses mesures de sécurité de la banque numérique de 2023, appliqués aux applications bancaires mobiles et aux API.
- Bangladesh : ICT Security Guideline de la Bangladesh BankL'ICT Security Guideline v4.0 et le Cybersecurity Framework de 2026, appliqués aux applications bancaires mobiles, aux applications de services financiers mobiles (MFS) et aux API.
- Inde : orientations de la RBI sur la cybersécurité et la sécurité des paiementsLes orientations de la RBI de 2026 sur la cybersécurité et la sécurité des paiements numériques : VA semestrielle, PT annuel, contrôles des applications mobiles et authentification à deux facteurs.
- Sri Lanka : directives CBSL sur le risque technologiqueLes directives de la CBSL sur le risque technologique et la ligne directrice sur les applications de paiement : tests avant mise en production, évaluations trimestrielles, pentests annuels et durcissement des apps.
- Népal : lignes directrices informatiques et de cyberrésilience de la NRBLes lignes directrices informatiques de la Nepal Rastra Bank et ses lignes directrices de cyberrésilience : chiffrement de la banque mobile, tests d'intrusion périodiques et MFA pour les systèmes critiques.
Asie-Pacifique
- Japon : lignes directrices de la FSA sur la cybersécuritéLes lignes directrices de la FSA sur la cybersécurité et ses lignes directrices de surveillance des banques : évaluations des applications mobiles, tests des API publiques et MFA résistante au phishing.
- Singapour : Technology Risk Management de la MASLes TRM Guidelines de la MAS, les Notices FSM-N05 et FSM-N06 et le Shared Responsibility Framework, appliqués aux applications bancaires mobiles et aux API.
- Indonésie : tests de cybersécurité selon l'OJKPOJK 11/2022, SEOJK 29/2022, PADK 1/2026 et POJK 21/2023, appliqués aux applications bancaires mobiles et aux API qui les sous-tendent.
- Chine : règles du PBOC et de la NFRA pour les applications mobilesÉvaluations externes annuelles et enregistrement NIFA, catégories de données JR/T 0171, tests des API avant mise en production et obligations MLPS : les règles du PBOC, de la NFRA et du MIIT pour les applications bancaires mobiles.
- Hong Kong : règles de la HKMA sur la banque électroniqueLe module TM-E-1 de la HKMA, les circulaires E-Banking Security ABCD et le PCICSO, appliqués aux applications bancaires mobiles et à leurs API : évaluation indépendante, tests d'intrusion annuels et authentification in-app.
- Taiwan : plan FSC et normes de l'association bancaireTests annuels selon le référentiel de sécurité, couverture OWASP MASVS et Mobile Top 10, restrictions en cas de root ou jailbreak, stockage des clés, SBOM et sécurité des API : les normes taïwanaises pour les applications bancaires mobiles.
- Corée du Sud : règles e-finance du FSC et évaluation FSIAnalyse et évaluation annuelles des vulnérabilités, critères mobiles du FSI, réforme de la séparation des réseaux et PIPA : les règles coréennes pour les applications bancaires mobiles.
- Malaisie : RMiT de BNM et amendements à la PDPALe rythme de tests du RMiT, les contrôles des applications mobiles et des API, les mesures anti-fraude et les règles sur les informations clients, appliqués aux applications bancaires mobiles et à leurs API.
- Thaïlande : sécurité du mobile banking de la Banque de ThaïlandeLa notification de la Banque de Thaïlande sur la sécurité du mobile banking, les règles de risque informatique et la PDPA appliquées aux applications bancaires mobiles et à leurs API, de l'anti-altération à la vérification faciale au-delà de 50 000 bahts.
- Philippines : risque informatique BSP et règles AFASATests applicatifs avant mise en production, évaluation de vulnérabilité et tests d'intrusion externes annuels, restrictions sur les appareils rootés et jailbreakés et sortie progressive des codes à usage unique par SMS et e-mail : les règles de la BSP et de l'AFASA pour les applications bancaires mobiles.
- Vietnam : Circulaire SBV 50/2024Les règles de sécurité bancaire en ligne de la Banque d'État du Vietnam, la norme OWASP de test des applications mobiles, la confirmation biométrique des transactions et les délais de correctifs, appliquées aux applications bancaires mobiles et à leurs API.
- Australie : APRA CPS 234 et CPS 230Le programme de tests CPS 234 de l'APRA, le risque opérationnel CPS 230, le cadre de prévention des arnaques et le Consumer Data Right, appliqués aux applications bancaires mobiles et à leurs API.
- Nouvelle-Zélande : cybersécurité RBNZ et normes DTALes lignes directrices et la collecte de données de la RBNZ sur la cyberrésilience, le projet de norme sur la résilience opérationnelle de la DTA et la Privacy Act 2020, appliqués aux applications bancaires mobiles et à leurs API.
Amériques
- États-Unis : FFIEC et NYDFS Part 500Le FFIEC IT Handbook, les orientations de 2021 sur l'authentification, les normes de sécurité du GLBA et la NYDFS Part 500, appliqués aux applications bancaires mobiles et aux API.
- Brésil : Résolution CMN 4.893 et Résolution BCB 85Pentests indépendants annuels, tests de vulnérabilités, développement sécurisé et authentification Pix : les règles de la BCB pour les applications bancaires mobiles.
- Canada : B-13 et B-10 de l'OSFILes lignes directrices B-13, B-10 et E-21 de l'OSFI, l'avis de signalement des incidents sous 24 heures et le cadre I-CRT, appliqués aux applications bancaires mobiles et à leurs API, ainsi que la LPRPDE et la Loi 25 du Québec.
- Mexique : CUB de la CNBV et SPEI de BanxicoAnalyse de vulnérabilités, pentests semestriels, facteurs d'authentification, verrouillage et flux de virement mobile standardisé : les règles mexicaines pour les applications bancaires mobiles et leurs API.
- Colombie : la Circular Básica Jurídica de la SFCTests d'intrusion deux fois par an, authentification à deux facteurs, chiffrement de bout en bout et normes d'API de la finance ouverte : les règles de la SFC pour les applications bancaires mobiles.
- Chili : les règles de cybersécurité et d'externalisation de la CMFLes chapitres 20-10, 20-7 et 1-13 de la RAN, la loi-cadre de cybersécurité et la norme de la CMF sur l'authentification renforcée, appliqués aux applications bancaires mobiles et à leurs API.
- Argentine : règles de la BCRA sur la technologie et la sécuritéTests de vulnérabilité indépendants, développement sécurisé, MFA, association à l'appareil et notification des incidents en une heure : les règles de la BCRA pour les applications bancaires mobiles et leurs API.
- Pérou : cybersécurité et authentification des cartes selon la SBSTests périodiques au titre du SGSI-C, authentification renforcée des opérations numériques, deux facteurs pour les paiements par carte et notification des violations sous 48 heures : les règles de la SBS et de la protection des données pour les applications bancaires mobiles.
Côte à côte
Trois régimes comparés
À qui chacun s'applique, ce qu'il vous demande de tester et où Ostorlab accompagne le volet tests.
| Lettre de la BCE sur les cybermenaces facilitées par l'IA | DORA | Règles de la CBUAE et Notice 2176 | |
|---|---|---|---|
| Émetteur | Supervision bancaire de la BCE | Parlement européen et Conseil, avec des normes techniques de la Commission | Banque centrale des Émirats arabes unis |
| Nature juridique | Lettre de surveillance prudentielle fondée sur DORA, et non une nouvelle réglementation | Règlement de l'UE, directement applicable dans tous les États membres | Loi fédérale, règlements, normes et lignes directrices, ainsi que la Notice 2176, qui n'est pas publique |
| Qui est concerné | Les établissements importants, c'est-à-dire les banques que la BCE supervise directement | Les entités financières de l'UE, dont les banques, les établissements de paiement et les établissements de monnaie électronique | Les institutions financières agréées aux Émirats arabes unis, avec certaines règles propres à des licences spécifiques |
| Date clé ou fréquence | Plan d'action à remettre à l'équipe de surveillance prudentielle conjointe d'ici le 31 octobre 2026 | En application depuis le 17 janvier 2025 : scans hebdomadaires, tests annuels, TLPT tous les 3 ans pour les entités identifiées | Décret-loi en vigueur depuis le 16 septembre 2025 ; reporting trimestriel des vulnérabilités |
| Tests demandés | Scan priorisé des vulnérabilités à grande échelle, outils fondés sur l'IA sous contrôle humain, sécurité dès la conception | Analyses de vulnérabilité, tests statiques et dynamiques du code, tests de pénétration et de bout en bout, TLPT | Évaluations de vulnérabilité, revue de code, tests de logique métier, tests indépendants annuels des API |
| Ce que cela implique pour les applications mobiles | Les applications mobiles et leurs API sont des actifs exposés à Internet et des logiciels développés en interne | Les applications qui soutiennent des fonctions critiques ou importantes nécessitent des scans automatisés hebdomadaires et des tests de sécurité avant leur mise en production | L'authentification, les vérifications renforcées, les sessions et les protections de l'appareil sont des contrôles antifraude à tester |
| Où Ostorlab vous aide | Des preuves de l'état initial, de la remédiation et des retests pour le volet applicatif du plan | Tests statiques, dynamiques et par agents IA, suivi des dépendances, suivi de la remédiation, travail préparatoire au TLPT | Tests de contournement du blindage, tests authentifiés, tests d'API et preuves pour chaque version |
Fil conducteur
Ce que les trois ont en commun
Des régulateurs différents, les mêmes quatre attentes pour les applications qu'utilisent vos clients.
Tester plus souvent
Des scans automatisés hebdomadaires avec DORA, un scan à grande échelle dans la lettre de la BCE, des évaluations régulières aux Émirats arabes unis : un pentest annuel ne suffit plus à lui seul.
Tester ce que les clients utilisent vraiment
La version publiée sur le store, derrière la connexion, avec les API et SDK dont elle dépend, et non un build de débogage dont les protections sont désactivées.
Prouver la correction
Les résultats sont priorisés, corrigés et validés, et la trace en atteste, pour les auditeurs comme pour les superviseurs.
Garder la maîtrise des données et de l'IA
Des outils d'IA sous contrôle humain, des fournisseurs que vous pouvez auditer et des données conservées là où vos politiques l'exigent.
Ostorlab vous accompagne dans vos obligations de test. Les décisions de conformité restent du ressort de vos équipes. Ceci ne constitue pas un avis juridique.
Des banques et fintechs nous font confiance, dont
FAQ
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.
Testez votre application bancaire avant que votre superviseur ne le demande
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour planifier les tests sur l'ensemble de vos versions.