Circulaire 50/2024 de la Banque d'État du Vietnam : testez votre application bancaire mobile au regard des règles de la SBV.
La circulaire 50/2024 sur la sécurité des services en ligne s'applique depuis le 1er janvier 2025 et, telle que modifiée par la circulaire 77/2025 à compter du 1er mars 2026, cite la norme OWASP Mobile Application Security pour les applications Mobile Banking, impose l'arrêt des applications sur les appareils rootés, jailbreakés ou débogués, et fixe la fréquence de scan des vulnérabilités et les délais de correctifs, avec un délai d'un jour pour les correctifs critiques exposés à Internet. 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 au regard des exigences de la SBV, sur le build que téléchargent vos clients
- Teste la connexion, les codes à usage unique et la confirmation des transactions avec vos comptes de test
- Vérifie à l'exécution la détection du root, du jailbreak, des débogueurs et du repackaging, et recense les SDK de chaque version
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les établissements de crédit, les succursales de banques étrangères, les prestataires de services de paiement intermédiaires et de monnaie mobile, et les sociétés d'information sur le crédit sous la supervision de la SBV
- Date clé
- Circulaire 50/2024 en vigueur depuis le 1er janvier 2025 ; les modifications de la circulaire 77/2025 s'appliquent à partir du 1er mars 2026
- Objet
- Sécurité des logiciels Online Banking et Mobile Banking, confirmation des transactions et OTP, gestion des vulnérabilités et des correctifs
- Texte de référence
- Circulaire 50/2024/TT-NHNN de la SBV, modifiée par la circulaire 77/2025/TT-NHNN
Les textes de la SBV qui encadrent votre canal mobile
La circulaire sur les services en ligne complète la circulaire sur la sécurité des systèmes d'information et les décisions de la SBV sur les paiements en ligne. Les dates ci-dessous concernent les textes cités sur cette page.
- 21 octobre 2020
Circulaire 09/2020/TT-NHNN
La SBV fixe les exigences minimales de sécurité des systèmes d'information bancaires, en vigueur depuis le 1er janvier 2021. L'article 42 impose des tests d'intrusion pour les systèmes connectés à Internet, aux clients et aux tiers, une évaluation de sécurité avant la mise en service, et des tests périodiques de six mois à deux ans selon la classe du système.
- 17 avril 2023
Décret sur la protection des données personnelles
Le décret 13/2023/ND-CP s'applique depuis le 1er juillet 2023 : consentement, mesures de sécurité, notification des violations et dossiers d'évaluation d'impact pour les données personnelles, y compris les données de compte, de transaction et biométriques traitées par une application bancaire.
- 18 décembre 2023
Décision 2345/QD-NHNN
La SBV instaure la vérification biométrique des paiements en ligne, en vigueur depuis le 1er juillet 2024 : les virements d'un particulier supérieurs à 10 millions de VND, ou plus de 20 millions de VND dans la journée, ainsi que la première utilisation de Mobile Banking ou l'utilisation depuis un nouvel appareil, exigent une correspondance biométrique.
- 31 octobre 2024
Circulaire 50/2024/TT-NHNN
La SBV remplace la circulaire 35/2016 par des règles de sécurité pour les services en ligne, en vigueur depuis le 1er janvier 2025. Elle reprend les règles biométriques aux articles 10 et 11 et dans les annexes de classification des transactions, fixe les durées de validité des OTP et impose des scans de vulnérabilités au moins une fois par an, et tous les trois mois pour les composants exposés à Internet, avec des délais de correctifs selon la gravité.
- 30 décembre 2024
Abrogation de la décision 2345
La décision 2872/QD-NHNN abroge la décision 2345/QD-NHNN à compter du 1er janvier 2025, son contenu figurant désormais dans la circulaire 50/2024. L'exigence biométrique continue de s'appliquer via la circulaire et ses annexes.
- 31 décembre 2025
Circulaire 77/2025/TT-NHNN
La SBV modifie la circulaire 50/2024, en vigueur depuis le 1er mars 2026. Les logiciels Mobile Banking doivent respecter OWASP Mobile Application Security et les logiciels Online Banking l'OWASP Top Ten ; les applications doivent se fermer en présence de débogueurs, d'émulateurs, de hooks, de repackaging, de root ou de jailbreak ; et les établissements doivent examiner la sécurité des versions installables au moins tous les trois mois.
Les règles de banque en ligne de la SBV, 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. La circulaire 50/2024 et son amendement sont résumés d'après le texte vietnamien.
- Circulaire 50/2024/TT-NHNN, article 7(3)(c), modifié par la circulaire 77/2025/TT-NHNN, article 4(1) (texte vietnamien)
Tester les logiciels bancaires mobiles avant la mise en production, au regard d'OWASP
Ce que dit le texte
Les logiciels Online Banking et Mobile Banking doivent être testés avant leur mise en service : un plan de test approuvé précisant les conditions de sécurité, la détection des erreurs de saisie et des fraudes, et le scan des vulnérabilités et faiblesses techniques. Le test doit évaluer les défenses contre des classes d'attaques dont l'injection (SQL, XPath, LDAP), le cross-site scripting, le cross-site request forgery, le server-side request forgery et le brute force, ainsi que contre les défauts de contrôle d'accès, d'authentification, de cryptographie, de configuration et de journalisation. À partir du 1er mars 2026, le test doit couvrir l'OWASP Top Ten pour les logiciels web et OWASP Mobile Application Security pour les logiciels mobiles, dans la version la plus récente ou une version publiée depuis moins de six mois.
Ce que cela implique pour votre application mobile
La SBV cite explicitement la norme mobile OWASP. Le binaire de votre application et les surfaces web et API qui la sous-tendent sont concernés, et le test a lieu avant la mise en production puis à intervalles réguliers.
Comment Ostorlab vous aide
Mobile SAST analyse l'APK, l'AAB ou l'IPA, y compris les SDK intégrés. Mobile DAST et le pentest par agents IA testent l'application en cours d'exécution et ses API, derrière la connexion, dans la CI/CD à chaque build. Les résultats sont rattachés aux catégories OWASP citées par la circulaire.
Ce qui reste de votre ressort
La rédaction du plan de test et l'approbation de la mise en production, ainsi que les plateformes serveur, VPN et infrastructure hors application.
- Circulaire 50/2024/TT-NHNN, articles 7(1) et 7(2) ; circulaire 09/2020/TT-NHNN, article 40 (texte vietnamien)
Intégrer la sécurité dès le développement et contrôler le code source
Ce que dit le texte
Les exigences de sécurité doivent être définies avant le développement et appliquées tout au long de l'analyse, de la conception, de la construction et des tests. Le code source doit être contrôlé : pour le code développé en interne, le vérifier périodiquement et à chaque changement de l'application afin d'éliminer le code malveillant et les vulnérabilités, avec des vérificateurs indépendants des développeurs, et conserver le code source dans au moins deux lieux géographiquement séparés. Pour le code externalisé, exiger du fournisseur qu'il corrige les vulnérabilités avant la livraison, ou qu'il scanne le logiciel livré et s'engage à l'absence de code malveillant. Les données de test ne doivent pas être des données clients réelles, sauf si elles sont masquées ou modifiées.
Ce que cela implique pour votre application mobile
La SBV traite l'application comme un logiciel sous contrôle des changements, y compris le code écrit par des prestataires. Les revues doivent être indépendantes des développeurs, et les environnements de test ne peuvent pas contenir de données clients réelles.
Comment Ostorlab vous aide
Mobile SAST travaille sur le binaire compilé avec une analyse de propagation (taint) sur l'application et ses SDK intégrés : il couvre donc du code que vous ne pouvez pas lire et des composants tiers. Le scan des secrets détecte les clés et identifiants laissés dans le build.
Ce qui reste de votre ressort
Les normes de développement sécurisé, la validation des revues de code, les contrats fournisseurs et les dépôts de code source eux-mêmes.
- Circulaire 50/2024/TT-NHNN, article 8(2) à (5), modifié par la circulaire 77/2025/TT-NHNN, article 5 (texte vietnamien)
Arrêter l'application sur les appareils rootés, jailbreakés, débogués ou repackagés
Ce que dit le texte
Les applications Mobile Banking doivent être distribuées via les stores officiels, protégées contre l'ingénierie inverse, protégées contre les interférences dans leurs flux de données et avec le serveur, et capables de détecter les interférences non autorisées. À partir du 1er mars 2026, l'application doit se fermer ou s'arrêter automatiquement et expliquer au client pourquoi lorsqu'elle détecte un débogueur, un émulateur ou une machine virtuelle, Android Debug Bridge, du hooking ou du repackaging, ou un appareil rooté, jailbreaké ou dont le bootloader est déverrouillé. Mémoriser le mot de passe d'accès est interdit, sauf lorsque la biométrie de l'appareil est la forme de confirmation.
Ce que cela implique pour votre application mobile
La détection du root, du jailbreak et des altérations est désormais une exigence explicite avec une réaction définie, et non un durcissement facultatif. Ce sont des comportements d'exécution que vous pouvez tester, sur le build installé par les clients.
Comment Ostorlab vous aide
Mobile Shielding Scan teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et montre quelles protections ont tenu et lesquelles ont été contournées. Le pentest par agents IA teste si la détection peut être évitée ou contournée par repackaging.
Ce qui reste de votre ressort
Le choix et la configuration du SDK de protection, et la définition du message client et du parcours d'assistance.
- Circulaire 50/2024/TT-NHNN, articles 9, 10 et 11, modifiés par la circulaire 77/2025/TT-NHNN, article 7 (texte vietnamien)
Confirmer les transactions avec les formes approuvées par la SBV, dont la biométrie
Ce que dit le texte
Les clients disposent d'un compte de transaction électronique et se connectent avec au moins une forme de confirmation prévue par la SBV. La circulaire fixe les formes et leurs limites : mots de passe d'au moins huit caractères et codes PIN d'au moins six chiffres, valables au maximum douze mois et trente jours pour un premier identifiant par défaut ; OTP par SMS et e-mail valables au maximum cinq minutes, OTP vocal trois minutes, soft et token OTP deux minutes, confirmation à deux canaux cinq minutes ; et verrouillage après au maximum dix tentatives erronées. Lorsqu'une transaction est confirmée par correspondance biométrique, la solution doit respecter des normes de précision et de détection du vivant, avec une détection d'attaque de présentation certifiée ISO 30107 niveau 2 ou équivalent à partir du 1er mars 2026. L'exigence biométrique pour les transactions de valeur élevée demeure via les annexes de classification des transactions.
Ce que cela implique pour votre application mobile
L'étape de confirmation doit être imposée par le serveur pour la bonne classe de transaction, y compris les transferts de valeur élevée, et les règles OTP et biométriques ont des propriétés testables : durées de validité, verrouillage et détection du vivant.
Comment Ostorlab vous aide
Les tests authentifiés saisissent les codes à usage unique par SMS, e-mail et TOTP avec vos comptes de test et vérifient la validité des OTP, le verrouillage, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Ils testent si une étape de confirmation peut être sautée ou rejouée ; ils ne certifient pas la détection du vivant.
Ce qui reste de votre ressort
Le choix des fournisseurs de biométrie et de détection du vivant et la conservation de leurs certifications FIDO ou ISO, ainsi que la classification des transactions et les limites que vous appliquez.
- Circulaire 50/2024/TT-NHNN, articles 7(6)(h) et 8(6) (texte vietnamien)
Vérifier le client sur un nouvel appareil et notifier les connexions
Ce que dit le texte
Pour les clients particuliers, l'application doit vérifier le client lors du premier accès ou d'un accès depuis un appareil autre que le dernier utilisé, au minimum par correspondance d'un OTP SMS ou vocal envoyé au numéro enregistré, ou d'un soft ou token OTP, ou par correspondance biométrique lorsque le droit sectoriel impose de collecter ces données. Le logiciel Online Banking doit également informer le client, par SMS ou un autre canal enregistré, de la première connexion ou d'une connexion depuis un autre appareil.
Source :Circulaire 50/2024/TT-NHNN, articles 7(6)(h) et 8(6) (texte vietnamien)
Ce que cela implique pour votre application mobile
La liaison à l'appareil et la vérification sur nouvel appareil sont des contrôles explicites : un nouveau téléphone ne doit pas accéder au compte sans une vérification, et la notification fait partie du parcours.
Comment Ostorlab vous aide
Ostorlab teste la connexion et la première connexion, saisit les codes à usage unique avec vos comptes de test, et vérifie si les contrôles d'appareil et les notifications peuvent être contournés côté API.
Ce qui reste de votre ressort
Le choix des méthodes proposées et la gestion de l'assistance à l'enregistrement des appareils.
- Circulaire 50/2024/TT-NHNN, article 8(1a), inséré par la circulaire 77/2025/TT-NHNN, article 5(1) (texte vietnamien)
Contrôler les versions installées et les examiner tous les trois mois
Ce que dit le texte
À partir du 1er mars 2026, les établissements doivent évaluer la sécurité des versions de l'application qu'ils permettent aux clients d'installer au moins tous les trois mois, afin d'identifier les vulnérabilités et d'évaluer le risque d'interférence par la cybercriminalité. Lorsqu'un client active l'application sur un nouvel appareil ou la réactive, il doit installer la version la plus récente, ou une version qui respecte encore les exigences de sécurité, et la rétrogradation doit être bloquée. Lorsqu'une vulnérabilité élevée ou critique est découverte, l'établissement doit contrôler et suspendre les transactions ou appliquer des mesures contre l'exploitation, et corriger et mettre à jour l'application dans les délais de l'article 14(6).
Ce que cela implique pour votre application mobile
Toutes les versions encore installables sont concernées, pas seulement la dernière livraison, et une ancienne version présentant un problème critique doit être bloquée ou restreinte.
Comment Ostorlab vous aide
Ostorlab scanne chaque version publiée sur les stores et peut scanner les anciennes versions encore prises en charge, avec des résultats par version, pour décider des versions à bloquer et prouver la correction dans la version suivante.
Ce qui reste de votre ressort
La politique de version, la logique de mise à jour et de blocage dans l'application, et le processus de revue des stores.
- Circulaire 50/2024/TT-NHNN, article 14 (texte vietnamien)
Scanner les vulnérabilités et corriger dans les délais de la SBV
Ce que dit le texte
Les établissements doivent gérer les vulnérabilités du système Online Banking : détecter les modifications non autorisées de l'application, mettre en place la détection d'intrusion, suivre les informations de gravité CVSS v4 ou équivalentes, et scanner les vulnérabilités au moins une fois par an, et au moins tous les trois mois pour les composants directement connectés à Internet. Chaque vulnérabilité est évaluée en impact et en risque avec un plan de correction, et corrigée dans les délais de la SBV : une journée pour les vulnérabilités critiques des composants exposés à Internet et un mois pour les autres, une journée et deux mois pour les vulnérabilités élevées, et un délai libre pour les moyennes et faibles.
Source :Circulaire 50/2024/TT-NHNN, article 14 (texte vietnamien)
Ce que cela implique pour votre application mobile
Le délai d'un jour pour les problèmes critiques exposés à Internet donne le rythme pour l'application et les API qui la sous-tendent, et les preuves doivent montrer la gravité, le calendrier et la clôture.
Comment Ostorlab vous aide
Les résultats sont classés critiques, élevés, moyens ou faibles et suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, avec retest après la publication du correctif : vous pouvez montrer quand un résultat a été signalé, corrigé et vérifié.
Ce qui reste de votre ressort
L'application des correctifs sur vos serveurs et votre infrastructure, et la surveillance SOC et la réponse aux incidents autour du système.
- Circulaire 50/2024/TT-NHNN, articles 7(7) et 19 (texte vietnamien) ; décret 13/2023/ND-CP ; loi 91/2025/QH15
Protéger les données clients, les secrets de confirmation et les journaux
Ce que dit le texte
Les données clients doivent être protégées conformément à la loi. Les mots de passe, codes PIN et informations biométriques doivent être chiffrés ou masqués au repos, l'accès aux données clients est limité aux rôles qui en ont besoin et surveillé, et les appareils et supports de stockage contenant des données clients sont contrôlés pour prévenir les fuites. En cas de fuite, l'établissement doit informer les clients et le signaler sans délai à la SBV. Le logiciel Online Banking doit conserver en ligne les informations d'identification des appareils et les journaux de transaction et de confirmation pendant au moins trois mois, avec une sauvegarde d'au moins un an, y compris les dix confirmations biométriques les plus récentes de chaque client. Le traitement des données personnelles relève aussi du décret 13/2023/ND-CP et, depuis le 1er janvier 2026, de la loi sur la protection des données personnelles.
Ce que cela implique pour votre application mobile
Les secrets de confirmation et les données biométriques ont leurs propres règles de stockage, et l'application est le point de départ le plus probable d'une fuite : stockage local, caches, journaux et captures d'écran sont donc concernés.
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, vérifie la protection du transport et les erreurs de configuration, et détecte les identifiants et clés dans le package de l'application et ses API.
Ce qui reste de votre ressort
La classification des données, le chiffrement et la gestion des clés, le consentement et les dossiers d'évaluation, et l'information des clients et de la SBV.
Synthèse de textes publics de la SBV et du Gouvernement vietnamien, vérifiés le 27 septembre 2026. La circulaire 50/2024 et son amendement sont résumés d'après le texte vietnamien. Cette page ne constitue pas un avis juridique.
Les règles de la SBV, contrôle par contrôle
Les contrôles visés par les textes de la SBV, 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é de l'application mobile au regard d'OWASP MASCirculaire 50/2024 art. 7(3), circulaire 77/2025 art. 4 | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Tests de l'Online Banking et des API au regard de l'OWASP Top TenCirculaire 50/2024 art. 7(3), circulaire 77/2025 art. 4 | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs des jetons et les abus comme l'énumération et le rejeu. Détails | Requêtes et réponses à l'appui de chaque résultat d'API |
| Revue indépendante du code source et développement sécuriséCirculaire 50/2024 art. 7(1) à (2) | Mobile SAST avec analyse de propagation (taint) sur l'application et ses SDK intégrés, sans besoin du code source. Détails | Résultats de l'analyse binaire par build, y compris les chemins de code des SDK intégrés |
| Composants vulnérables et délais de correctionCirculaire 50/2024 art. 14(4) à (6) | Identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Détails | Vulnérabilités identifiées avec gravité CVSS, recommandations de mise à niveau ou de remplacement, et clôture d'une version à l'autre |
| Détection du root, du jailbreak, des altérations et du repackagingCirculaire 50/2024 art. 8(4), circulaire 77/2025 art. 5(2) | Teste à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et le déclenchement de la fermeture sur appareil non sûr. Détails | Résultats montrant quelles protections ont tenu et lesquelles ont été contournées, avec étapes de reproduction |
| Confirmation des transactions, OTP et verrouillageCirculaire 50/2024 art. 9 à 11 | Se connecte avec des codes à usage unique et teste la validité des OTP, le verrouillage après des tentatives erronées et les parcours d'authentification renforcée, ainsi que les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et de confirmation, avec étapes de reproduction |
| Vérification sur nouvel appareil et notifications de connexionCirculaire 50/2024 art. 8(6), art. 7(6)(h) | Teste la première connexion et la connexion depuis un nouvel appareil, en saisissant les codes à usage unique avec vos comptes de test. Détails | Résultats sur les contrôles d'appareil et les notifications, avec journaux des requêtes et réponses |
| Secrets, codes PIN et données sur l'appareilCirculaire 50/2024 art. 19 ; circulaire 09/2020 art. 24 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels, et recherche les données clients dans le stockage, les caches, les journaux et les captures d'écran. Détails | Secrets validés avec les permissions qu'ils exposent, et preuves sur le système de fichiers montrant ce qui a été écrit et où |
| Contrôle des versions et revue des versions installablesCirculaire 50/2024 art. 8(1a), circulaire 77/2025 art. 5(1) | Scanne chaque version publiée sur les stores et les anciennes versions prises en charge, avec des résultats par version plutôt que par trimestre. Détails | Résultats de scan par version de l'application, et le retest qui prouve la correction dans la version suivante |
| Signalement à la SBV et information des clientsCirculaire 50/2024 art. 19(5) et 20 | Fournit les preuves de résultat et les comptes rendus de retest qui étayent vos rapports ; il ne dépose pas de rapport auprès de la SBV et n'informe pas les clients. | Résultats, versions concernées et comptes rendus de retest conservés comme pièces justificatives |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance SOC, la réponse aux incidents et leur signalement, la certification de détection du vivant, la logique de blocage des versions, les sauvegardes et la reprise, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles de la SBV à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque des systèmes, fondée sur la circulaire 50/2024 modifiée par la circulaire 77/2025 et sur la circulaire 09/2020.
Délimiter l'application et ses API
Intégrez l'application Mobile Banking et les API qu'elle appelle au plan de test avant mise en production, en nommant les catégories OWASP MAS et OWASP Top Ten exigées par la circulaire.
Revue indépendante du code et des composants
Vérifiez le code interne avec des réviseurs qui ne l'écrivent pas, scannez les composants externalisés et tiers, et tenez un inventaire des composants par version.
Comportement de durcissement
Vérifiez qu'un environnement rooté, jailbreaké, débogué, hooké ou repackagé arrête l'application, et que le pinning tient.
Contrôles de confirmation
Testez les durées de validité des OTP, le verrouillage après des tentatives erronées, et que la bonne forme de confirmation est imposée pour chaque classe de transaction.
Certification biométrie et détection du vivant
Vérifiez que la solution biométrique et sa détection d'attaque de présentation disposent de la certification FIDO ou ISO 30107 niveau 2 attendue par la SBV.
Nouvel appareil et notifications
Testez la première connexion et la connexion depuis un nouvel appareil, et que la notification client est envoyée sur les bons événements.
Versions et délais de correctifs
Examinez les versions installables tous les trois mois, bloquez les rétrogradations et fixez des délais internes conformes aux règles d'un jour et d'un mois.
Signaler et retester
Conservez les résultats, la gravité, les dates de correction et les retests comme traces, et utilisez-les dans les rapports à la SBV et aux clients après une fuite de données.
Une liste indicative, et non un modèle de la SBV. 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 la connexion, les codes à usage unique et les parcours d'authentification renforcée 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 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.
- Circulaire 50/2024/TT-NHNN sur la sécurité et la confidentialité des services en ligne dans le secteur bancaireBanque d'État du Vietnam, datée du 31 octobre 2024, en vigueur depuis le 1er janvier 2025, modifiée par la circulaire 77/2025/TT-NHNN. Remplace la circulaire 35/2016/TT-NHNN et abroge l'article 25 de la circulaire 09/2020/TT-NHNN (texte vietnamien)
- Circulaire 77/2025/TT-NHNN modifiant la circulaire 50/2024/TT-NHNNBanque d'État du Vietnam, datée du 31 décembre 2025, en vigueur depuis le 1er mars 2026, ses articles 3 et 10 s'appliquant à partir du 1er juillet 2026 et du 1er octobre 2026. Ajoute les normes OWASP, les règles de fermeture sur appareil non sûr, le contrôle des versions et la certification de détection du vivant (texte vietnamien)
- Circulaire 09/2020/TT-NHNN sur la sécurité des systèmes d'information dans les activités bancairesBanque d'État du Vietnam, datée du 21 octobre 2020, en vigueur depuis le 1er janvier 2021. Les articles 40 et 42 à 43 couvrent le développement sécurisé, les tests d'intrusion obligatoires pour les systèmes exposés à Internet ou connectés aux clients, et la gestion des vulnérabilités (texte vietnamien)
- Décision 2345/QD-NHNN sur les solutions de sécurité des paiements en ligne et par carteBanque d'État du Vietnam, datée du 18 décembre 2023, en vigueur depuis le 1er juillet 2024. A instauré la vérification biométrique pour les transferts de valeur élevée et l'usage depuis un nouvel appareil ; abrogée à compter du 1er janvier 2025 par la décision 2872/QD-NHNN, son contenu étant repris dans la circulaire 50/2024. Référencée via le portail du Gouvernement vietnamien
- Décret 13/2023/ND-CP sur la protection des données personnellesGouvernement du Vietnam, daté du 17 avril 2023, en vigueur depuis le 1er juillet 2023. Consentement, mesures de sécurité, notification des violations et dossiers d'évaluation d'impact ; la loi de 2025 sur la protection des données personnelles et son décret d'application ont repris le cadre à compter du 1er janvier 2026 (texte vietnamien)
- Loi sur la protection des données personnelles, n° 91/2025/QH15Assemblée nationale du Vietnam, adoptée le 26 juin 2025, en vigueur depuis le 1er janvier 2026. Données personnelles sensibles dont la biométrie, transferts transfrontaliers et dossiers d'évaluation d'impact ; le décret 356/2025/ND-CP en précise les modalités à la même date (texte vietnamien)
- Décret 356/2025/ND-CP précisant la loi sur la protection des données personnellesGouvernement du Vietnam, daté du 31 décembre 2025, en vigueur depuis le 1er janvier 2026. Dispositions d'application pour le traitement et la protection des données personnelles (texte vietnamien)
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 mobile comme le décrit la SBV
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.