Règles de la Banque de Thaïlande : évaluez votre application bancaire mobile par rapport aux normes minimales.
La notification de la Banque de Thaïlande sur la sécurité du mobile banking fixe des normes minimales pour les applications bancaires : aucun lien intégré dans les messages aux clients, un seul compte sur un seul appareil, comparaison faciale avec détection d'attaque par présentation au-delà de 50 000 bahts, contrôles anti-altération et blocage des appareils rootés. La notification sur le risque informatique ajoute un test d'intrusion annuel pour les systèmes exposés à Internet, et la PDPA fixe les obligations relatives aux données des clients. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Vérifie la détection du root et du jailbreak, l'anti-altération, la gestion des sessions et le pinning, et ce que fait l'application lorsqu'ils se déclenchent
- Teste la connexion, les codes à usage unique et l'étape de vérification faciale au-delà du seuil de 50 000 bahts avec vos comptes de test
- Suit l'application jusque dans ses API, même avec TLS pinning
- Détecte les clés, jetons et données personnelles laissés dans le package de l'application, le stockage, les caches et les journaux
- Qui est concerné
- Les banques et institutions financières publiques sous la supervision de la BOT, et les prestataires de monnaie électronique ayant une application mobile ; les obligations PDPA relatives aux données personnelles s'appliquent à tous
- Date clé
- Notification n° 4/2568 sur la sécurité du mobile banking publiée le 7 février 2025, en vigueur 30 jours plus tard ; normes contre la criminalité technologique applicables depuis le 8 août 2025
- Objet
- Sécurité des applications bancaires mobiles, vérification faciale pour les virements élevés, contrôles de l'appareil, tests d'intrusion annuels et obligations PDPA
- Texte de référence
- Notification de la Banque de Thaïlande n° 4/2568 (sécurité du mobile banking)
Les textes de la BOT qui encadrent votre canal mobile
La notification sur la sécurité du mobile banking complète la notification sur le risque informatique, les normes contre la criminalité technologique et la PDPA. Les dates ci-dessous concernent les textes cités sur cette page.
- 1er juin 2022
Entrée en vigueur de la PDPA
La loi sur la protection des données personnelles B.E. 2562 (2019) devient pleinement applicable : obligations de sécurité pour les données personnelles et notification des violations au PDPC sans délai et dans les 72 heures.
- 16 octobre 2023
Notification sur le risque informatique
La notification n° สกช. 5/2566 remplace les règles de 2019. Les systèmes exposés à Internet, dont le mobile banking et la banque en ligne, doivent faire l'objet d'un test d'intrusion au moins une fois par an et après tout changement important.
- 7 février 2025
Sécurité du mobile banking
La notification n° 4/2568 est publiée au Journal officiel. Elle fixe des normes de sécurité minimales pour les applications bancaires et entre en vigueur 30 jours après le lendemain de la publication, et 60 jours pour la clause sur le risque des systèmes d'exploitation. Les notifications n° 17/2568 et n° 18/2568 étendent les mêmes mesures aux institutions financières publiques et aux applications de monnaie électronique.
- 8 août 2025
Normes contre la criminalité technologique
La notification n° 19/2568 entre en vigueur : aucun lien dans les messages aux clients, un seul compte sur un seul appareil, seuils de vérification faciale, anti-altération, blocage des applications à risque et ligne d'assistance, en application du décret d'urgence sur la prévention de la criminalité technologique.
- 17 décembre 2025
Gestion de la fraude numérique
La notification n° 57/2568 entre en vigueur et remplace la politique de 2023 sur la fraude pour les prestataires de services financiers. Elle couvre la gestion de la fraude de bout en bout, dont l'authentification adaptée au risque client, les alertes de transaction et les plafonds quotidiens par défaut. La surveillance et le traitement des pertes restent du ressort de vos équipes fraude.
- 23 juillet 2026
Consultation Digital Channel Security
La BOT ouvre une consultation sur un projet de notification Digital Channel Security. Il étendrait les règles à la banque en ligne et aux prestataires non bancaires et supprimerait les codes à usage unique par SMS pour l'authentification des transactions. Les commentaires ont été clos le 24 août 2026. Le projet n'est pas en vigueur.
- Chaque année
Tests d'intrusion
Les systèmes connectés à des réseaux publics, comme le mobile banking et la banque en ligne, font l'objet d'un test d'intrusion par des experts internes ou externes indépendants au moins une fois par an, et après tout changement important.
Les règles de la BOT sur le mobile banking, appliquées à votre application
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 Banque de Thaïlande sont en thaï et sont résumés ici.
- Notification sur le risque informatique n° สกช. 5/2566, 6.6 et 6.7 (texte thaï)
Tester les systèmes exposés à Internet au moins une fois par an
Ce que dit le texte
Évaluez les vulnérabilités de chaque système selon son niveau de risque. Pour les systèmes critiques, réalisez l'évaluation au moins une fois par an et à chaque changement important. Réalisez un test d'intrusion par des experts internes ou externes indépendants, couvrant les systèmes et réseaux connectés à des réseaux publics, au moins une fois par an et après tout changement important. La BOT peut ordonner un test supplémentaire par un expert externe indépendant si le rapport, le périmètre ou les méthodes ne sont pas adéquats.
Source :Notification sur le risque informatique n° สกช. 5/2566, 6.6 et 6.7 (texte thaï)
Ce que cela implique pour votre application mobile
Votre application bancaire mobile et ses API sont des systèmes exposés à Internet. Le test annuel est une attente explicite, et il couvre des systèmes et des réseaux, pas seulement l'application visible.
Comment Ostorlab vous aide
Un 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 après la publication du correctif.
Ce qui reste de votre ressort
Le choix des testeurs indépendants pour le test annuel, et la décision de savoir si leur rapport couvre l'application et les API.
- Notification sur le risque informatique n° สกช. 5/2566, 7.2 ; IT Risk Management Implementation Guideline, 2.7.2 (texte thaï)
Tester avant la mise en production et intégrer la sécurité
Ce que dit le texte
Concevez, développez et testez les systèmes pour qu'ils préservent la confidentialité des données, restent fiables et disponibles. Les tests de sécurité devraient inclure une évaluation de vulnérabilité du système et, lorsque le système se connecte à un réseau externe, un test d'intrusion par des experts externes avant la mise en service. Faites une revue indépendante du code source à chaque développement ou modification d'une partie transactionnelle critique. Séparez les environnements de développement, de test et de production, et validez les résultats de test avant la mise en production.
Ce que cela implique pour votre application mobile
Chaque version de votre application bancaire est une modification d'un système exposé à Internet. Les tests de sécurité font partie du processus de release, pas d'un exercice annuel effectué après coup.
Comment Ostorlab vous aide
Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans code source, avec analyse de propagation (taint) sur les SDK intégrés. Mobile DAST exécute l'application, et les deux tournent dans votre pipeline CI/CD à chaque build.
Ce qui reste de votre ressort
La revue du code source pour les changements transactionnels critiques, la séparation des environnements, la validation et l'approbation des mises en production.
- Notification sur le risque informatique n° สกช. 5/2566, 6.6, 6.10 et les règles relatives aux tiers (texte thaï)
Gérer vulnérabilités, correctifs et tiers avec des délais
Ce que dit le texte
Mettez en place un processus de gestion des vulnérabilités pour chaque système, à une fréquence adaptée à son risque. Maintenez un processus de gestion des correctifs pour les systèmes et les appareils, et appliquez les correctifs de sécurité dans un délai correspondant au risque de la vulnérabilité et à l'importance du système. Lorsque l'éditeur n'a pas publié de correctif, mettez en place des mesures compensatoires, et utilisez un processus d'exception formel lorsqu'un correctif ne peut pas être installé. Gérez les tiers qui fournissent des services informatiques, se connectent à vos systèmes ou peuvent accéder aux données clients, avec des vérifications préalables et des droits d'audit.
Ce que cela implique pour votre application mobile
Les SDK et bibliothèques natives de votre application sont des logiciels que vous livrez. Chacun a besoin d'une version connue, d'une gravité lorsqu'une vulnérabilité apparaît, et d'un délai de correction dont vous pouvez apporter la preuve.
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, suivis sous forme de tickets et retestés après la publication du correctif.
Ce qui reste de votre ressort
L'application des correctifs sur les serveurs et l'infrastructure, les contrats fournisseurs, les approbations d'exception et les décisions d'acceptation des risques.
- Notification sur la sécurité du mobile banking n° 4/2568, 5.3.2(2) (texte thaï)
Durcir l'application contre l'altération et les anciennes versions
Ce que dit le texte
Maintenez et améliorez l'application selon les normes internationales et face aux nouvelles menaces. Ne demandez que les autorisations dont vous avez besoin et revoyez-les à chaque changement important. Ne servez pas d'anciennes versions de l'application susceptibles de contenir des vulnérabilités. Vérifiez l'altération à chaque ouverture de l'application et ne laissez pas une application modifiée s'exécuter. Gérez la session pour prévenir le détournement de session, et obscurcissez le code source pour qu'il ne puisse pas être lu facilement.
Source :Notification sur la sécurité du mobile banking n° 4/2568, 5.3.2(2) (texte thaï)
Ce que cela implique pour votre application mobile
L'altération, le détournement de session et un code lisible sont la base sur laquelle un attaquant s'appuie. Chacune de ces protections est un comportement testable sur un build modifié et une session active.
Comment Ostorlab vous aide
Mobile Shielding Scan tente de contourner la détection du root et du jailbreak, l'anti-altération et l'instrumentation, montre ce que fait ensuite l'application et fournit un score de durcissement. Les tests authentifiés couvrent la gestion des sessions.
Ce qui reste de votre ressort
La politique de version pour les anciennes versions, les autorisations demandées et le choix des produits de durcissement.
- Notification sur la sécurité du mobile banking n° 4/2568, 5.3.2(3) ; Notification sur la criminalité technologique n° 19/2568, 4.2.1(5) (texte thaï)
Bloquer les appareils rootés, jailbreakés et à risque
Ce que dit le texte
Ne laissez pas l'application s'exécuter sur des appareils rootés ou jailbreakés. Ne la laissez pas s'exécuter lorsque des applications à risque sont actives, par exemple des services d'accessibilité non nécessaires, des applications de contrôle à distance ou des applications capables de masquer ou de voler ce qui s'affiche à l'écran. Évitez de fournir le mobile banking sur des systèmes d'exploitation qu'un organisme de sécurité reconnu, comme Thailand Banking Sector CERT (TB-CERT), considère à risque. Si vous servez malgré tout ces appareils, avertissez le client et plafonnez les virements à 5 000 bahts par jour. Lorsqu'une nouvelle vulnérabilité apparaît, fermez-la dans un délai approprié ou avant l'échéance fixée par la BOT.
Ce que cela implique pour votre application mobile
Les logiciels malveillants de paiement sur le téléphone du client sont la menace visée. Une détection qui n'arrête pas le parcours ne suffit pas, et les politiques de mise à jour forcée et de support des systèmes d'exploitation font partie du contrôle.
Comment Ostorlab vous aide
Mobile Shielding Scan exécute l'application dans des environnements rootés et jailbreakés et en présence de superpositions, tente les contournements et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner.
Ce qui reste de votre ressort
La politique de support des systèmes d'exploitation, les avertissements aux clients et les plafonds appliqués aux appareils à risque.
- Notification sur la sécurité du mobile banking n° 4/2568, 5.3.2(1) (texte thaï)
Protéger les données au repos, en transit et à l'écran
Ce que dit le texte
Évitez de stocker des données clients importantes sur l'appareil et, si vous devez les stocker, chiffrez-les selon une norme reconnue et détruisez-les lorsqu'elles ne sont plus nécessaires. N'affichez les informations sensibles que dans la mesure nécessaire, masquez les mots de passe et cachez l'écran lorsque l'application passe en arrière-plan. Utilisez des protocoles sécurisés et prouvez l'identité du serveur par certificate pinning ou une méthode équivalente, et chiffrez les données importantes au niveau applicatif pour qu'elles ne puissent pas être interceptées ou modifiées en transit.
Source :Notification sur la sécurité du mobile banking n° 4/2568, 5.3.2(1) (texte thaï)
Ce que cela implique pour votre application mobile
Ce que l'application écrit dans le stockage, affiche à l'écran et envoie sur le réseau est là où les données clients fuient. Les trois sont des comportements concrets et testables.
Comment Ostorlab vous aide
Ostorlab recherche les jetons et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, vérifie le masquage d'écran et le flou en arrière-plan, et intercepte le trafic même avec TLS pinning pour inspecter ce qui part vers le backend.
Ce qui reste de votre ressort
La classification des données, la gestion des clés côté backend et les règles de conservation.
- Notification sur la sécurité du mobile banking n° 4/2568, 5.3.1(4) ; Notification sur la criminalité technologique n° 19/2568, 4.2.1(3) (texte thaï)
Vérifier les virements élevés par comparaison faciale
Ce que dit le texte
Ajoutez une étape de vérification du client pour les transactions de mobile banking, par comparaison faciale avec détection d'attaque par présentation résistant aux photos, vidéos et usurpations biométriques, par exemple la détection de vivacité. L'étape est requise pour les virements de 50 000 bahts ou plus en une transaction, les virements cumulés atteignant 200 000 bahts sur une journée, et les demandes de relèvement du plafond quotidien à 50 000 bahts ou plus. Les clients qui ne peuvent pas utiliser la comparaison faciale, comme les personnes malvoyantes, ont besoin d'une alternative documentée avec des contrôles de risque.
Ce que cela implique pour votre application mobile
Le seuil se situe dans le parcours, pas dans un document de politique. Le serveur doit exiger l'étape faciale sur la transaction, et le relèvement du plafond est un événement d'authentification renforcée à part entière.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion, les changements de plafond, les virements et les parcours d'authentification renforcée avec vos comptes de test, y compris les appels d'API déclenchés par l'étape faciale.
Ce qui reste de votre ressort
Le produit biométrique, le calibrage de la détection de vivacité, le processus d'exemption pour les clients qui ne peuvent pas l'utiliser et les informations aux clients.
- Notification sur la sécurité du mobile banking n° 4/2568, 5.3.1(3) et (5) ; Notification sur la criminalité technologique n° 19/2568, 4.2.1(2) (texte thaï)
Un seul compte sur un seul appareil, avec des plafonds
Ce que dit le texte
Limitez le mobile banking à un compte utilisateur par service de mobile banking et par institution, et à un seul appareil mobile. La limite s'applique par application lorsqu'une institution en exploite plusieurs. Fixez un plafond quotidien maximal de retrait et de virement pour chaque groupe de risque client ; pour les clients de moins de 15 ans, le plafond combiné ne dépasse pas 50 000 bahts par jour. Lorsqu'un client demande à relever le plafond, prouvez son identité et examinez la raison selon des critères clairs.
Ce que cela implique pour votre application mobile
La liaison à l'appareil et les plafonds quotidiens sont des règles côté serveur. Si un ancien appareil, une session copiée ou une demande de relèvement peuvent les contourner via l'application ou l'API, le contrôle n'est pas réel.
Comment Ostorlab vous aide
Les tests authentifiés vérifient la liaison à l'appareil, l'invalidation de session après un changement d'appareil et les appels d'API derrière les changements de plafond, avec vos comptes de test.
Ce qui reste de votre ressort
Les groupes de risque, les valeurs des plafonds et le processus d'exception pour les clients qui demandent davantage.
- Notification sur la sécurité du mobile banking n° 4/2568, 5.3.1(1) et (2) ; Notification sur la criminalité technologique n° 19/2568, 4.2.1(1) et 5 (texte thaï)
Arrêter les liens de phishing et répondre aux fausses applications
Ce que dit le texte
N'envoyez pas de liens par SMS ou e-mail aux clients. Sur les réseaux sociaux, évitez les liens qui demandent une authentification ou des données personnelles. Un lien ne peut être envoyé que lorsque le client le demande à chaque fois, avec un message clair indiquant qu'il s'agit d'une réponse ponctuelle à sa demande. Surveillez les magasins d'applications officiels pour détecter les applications qui imitent la vôtre, et disposez d'un processus de réponse avec responsables, étapes de retrait et délais, y compris pour les fausses applications hors des magasins. Maintenez une ligne d'assistance pour que les clients signalent la criminalité technologique, pendant et en dehors des heures ouvrables.
Ce que cela implique pour votre application mobile
Le phishing commence dans les canaux auxquels les clients font confiance. Les contrôles sont une politique de liens vérifiable dans les messages que vous envoyez et un processus de retrait que vous pouvez répéter.
Comment Ostorlab vous aide
Ostorlab teste l'application et les API derrière ses parcours de compte et de paiement contre les abus qui suivent un lien de phishing, comme le bourrage d'identifiants, le rejeu de session et les autorisations défaillantes.
Ce qui reste de votre ressort
La politique de messagerie, le processus de retrait des fausses applications et la ligne d'assistance client.
- Loi sur la protection des données personnelles B.E. 2562 (2019), article 37, et notification du PDPC sur les mesures de sécurité B.E. 2565 (2022) (texte thaï)
Répondre aux obligations PDPA sur les données personnelles
Ce que dit le texte
Mettez en place des mesures de sécurité appropriées pour empêcher la perte, l'accès, l'utilisation, la modification ou la divulgation non autorisés des données personnelles, avec des mesures organisationnelles, techniques et physiques adaptées au risque, y compris le contrôle des accès et la capacité d'auditer ces accès. Notifiez au PDPC toute violation de données personnelles sans délai et dans les 72 heures après en avoir pris connaissance, sauf si la violation ne présente aucun risque pour les personnes, et informez les personnes concernées lorsque le risque est élevé. La norme de sécurité fixée par la notification du PDPC est un plancher qui s'applique en plus des règles de la BOT.
Ce que cela implique pour votre application mobile
Les données clients sortent de la banque par l'application, ses SDK et ses journaux. Une violation de ces données déclenche le délai de 72 heures, et les tests d'application permettent de trouver les expositions avant quelqu'un d'autre.
Comment Ostorlab vous aide
Ostorlab recherche les données personnelles et les identifiants dans le package de l'application, le stockage, les caches, les journaux et les captures d'écran, et indique ce que l'application et ses SDK envoient à quels backends.
Ce qui reste de votre ressort
Les registres de traitement, le plan de réponse aux violations, la notification au PDPC dans les 72 heures et les informations aux personnes concernées.
Synthèse des textes publics de la Banque de Thaïlande et du PDPC, vérifiés le 27 septembre 2026. Les textes de la BOT sont en thaï et sont résumés ici. Le projet de notification Digital Channel Security n'est pas en vigueur et est présenté comme un projet. Cette page ne constitue pas un avis juridique.
Les règles de la BOT, contrôle par contrôle
Les contrôles visés par les textes de la BOT, 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 |
|---|---|---|
| Test d'intrusion annuel des systèmes exposés à InternetRisque informatique 6.7 | 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 sécurité avant la mise en production et lors des changementsRisque informatique 6.6, 7.2 | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, dans la CI/CD à chaque build. Détails | Résultats de scan par build, avec contexte de code décompilé, trafic et captures d'écran |
| Composants vulnérables, correctifs et SDK tiersRisque informatique 6.6, 6.10 | 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 recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| Anti-altération, gestion des sessions et obscurcissementSécurité mobile banking 5.3.2(2) | Modifie le binaire, instrumente l'application et tente de contourner les contrôles d'intégrité et les protections de session. Détails | Preuve des protections qui ont tenu et de celles qui ont été contournées |
| Appareils rootés, jailbreakés et à risqueSécurité mobile banking 5.3.2(3) | Exécute l'application dans des environnements rootés et jailbreakés et en présence d'applications de superposition ou de contrôle à distance. Détails | Score de durcissement et preuve de contournement pour chaque protection qui a échoué |
| Certificate pinning et API derrière l'applicationSécurité mobile banking 5.3.2(1.3) | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs de 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 |
| Clés et identifiants dans le package de l'applicationSécurité mobile banking 5.3.2(1.1) | 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 |
| Données sur l'appareil : stockage, caches, journaux et captures d'écranSécurité mobile banking 5.3.2(1.1) et (1.2) | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie le masquage et le flou en arrière-plan. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Vérification faciale et authentification renforcée au-delà des seuilsSécurité mobile banking 5.3.1(4) | Se connecte avec vos comptes de test et teste les virements, les plafonds et les parcours d'authentification renforcée, ainsi que les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours d'authentification renforcée, avec étapes de reproduction |
| Un seul compte, un seul appareil et plafonds quotidiensSécurité mobile banking 5.3.1(3), (5) | Teste la liaison à l'appareil, l'invalidation de session après un changement d'appareil et les appels d'API derrière les changements de plafond. Détails | Résultats sur les sessions et la liaison à l'appareil, avec journaux des requêtes et réponses |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance de la fraude, la ligne d'assistance client, la réponse aux incidents et leur signalement, la remédiation des appareils et des systèmes d'exploitation, les décisions de groupes de risque, la notification des violations au PDPC, les sauvegardes et la reprise, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles de la BOT à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque des systèmes, fondée sur la notification sur la sécurité du mobile banking, les normes contre la criminalité technologique et la notification sur le risque informatique.
Test annuel
Intégrez l'application et ses API exposées à Internet au test d'intrusion annuel, et retestez après tout changement important.
Avant la mise en production
Ajoutez une évaluation de vulnérabilité et, pour les systèmes exposés à Internet, un test d'intrusion indépendant au processus de release, avec des résultats validés avant la mise en production.
Durcissement de l'application
Exécutez l'application sous forme de build modifié et vérifiez l'anti-altération, la détection du root et du jailbreak, la gestion des sessions et le blocage des anciennes versions.
Appareils à risque
Testez en présence d'applications d'accessibilité, de contrôle à distance et de capture d'écran, et vérifiez ce que fait l'application lorsque l'appareil est rooté ou que l'OS figure sur la liste de risque du TB-CERT.
Données et identifiants
Recherchez les clés, jetons et données personnelles dans le package de l'application, le stockage, les caches, les journaux et les captures d'écran, et vérifiez le certificate pinning et le chiffrement applicatif.
Vérification faciale
Testez que les virements de 50 000 bahts ou plus, 200 000 bahts cumulés sur une journée et les relèvements de plafond déclenchent la comparaison faciale côté serveur.
Un seul compte, un seul appareil
Vérifiez la liaison à l'appareil, l'invalidation de session après un changement d'appareil et les plafonds quotidiens de chaque groupe de risque.
Composants et correctifs
Tenez une liste versionnée des SDK et bibliothèques natives, fixez des délais de correction selon le risque et retestez après la publication d'un correctif.
Une liste indicative, et non un modèle de la BOT. 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.
- ประกาศธนาคารแห่งประเทศไทย ที่ 4/2568 เรื่อง การรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินและการชำระเงินบนอุปกรณ์เคลื่อนที่ สำหรับสถาบันการเงินNotification de la Banque de Thaïlande n° 4/2568 sur la sécurité du mobile banking pour les institutions financières. Signée le 31 janvier 2025, publiée au Journal officiel le 7 février 2025. En vigueur 30 jours après le lendemain de la publication, et 60 jours pour la clause sur le risque des systèmes d'exploitation. Texte thaï
- ประกาศธนาคารแห่งประเทศไทย ที่ 17/2568 เรื่อง การรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินและการชำระเงินบนอุปกรณ์เคลื่อนที่ สำหรับสถาบันการเงินเฉพาะกิจBOT, publiée au Journal officiel le 7 août 2025. Les mêmes mesures de sécurité du mobile banking pour les institutions financières publiques. Texte thaï
- ประกาศธนาคารแห่งประเทศไทย ที่ 18/2568 เรื่อง การรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินและการชำระเงินบนอุปกรณ์เคลื่อนที่ สำหรับผู้ประกอบธุรกิจบริการเงินอิเล็กทรอนิกส์ที่ให้บริการ e-Money Mobile ApplicationBOT, publiée au Journal officiel le 7 août 2025. Les mêmes mesures pour les applications de monnaie électronique, avec la limite d'un compte et un appareil appliquée par application. Texte thaï
- ประกาศธนาคารแห่งประเทศไทย ที่ 19/2568 เรื่อง มาตรฐานและมาตรการเพื่อป้องกันอาชญากรรมทางเทคโนโลยีสำหรับสถาบันการเงินBOT, datée du 25 juillet 2025, publiée au Journal officiel le 7 août 2025, en vigueur depuis le 8 août 2025. Normes antifraude pour les applications bancaires : aucun lien, un compte sur un appareil, seuils de vérification faciale, anti-altération, blocage des applications à risque et ligne d'assistance. Texte thaï
- ประกาศธนาคารแห่งประเทศไทย ที่ สกช. 5/2566 เรื่อง หลักเกณฑ์การกำกับดูแลความเสี่ยงด้านเทคโนโลยีสารสนเทศ (Information Technology Risk) ของสถาบันการเงินและสถาบันการเงินเฉพาะกิจBOT, datée du 16 octobre 2023, annoncée par lettre du 9 novembre 2023 avec les lignes directrices IT Risk Management et Third Party Risk Management. Tests d'intrusion annuels pour les systèmes exposés à Internet, délais de correctifs et développement sécurisé. Texte thaï
- ประกาศธนาคารแห่งประเทศไทย ที่ 57/2568 เรื่อง หลักเกณฑ์การบริหารจัดการภัยทุจริตดิจิทัล (Digital Fraud Management)BOT, datée du 4 décembre 2025, publiée au Journal officiel le 16 décembre 2025, en vigueur depuis le 17 décembre 2025. Gestion de la fraude numérique de bout en bout pour les prestataires de services financiers, remplaçant leur politique de 2023. Texte thaï
- Personal Data Protection Act B.E. 2562 (2019)Thaïlande, en vigueur depuis le 1er juin 2022. Article 37 sur les mesures de sécurité et notification des violations sans délai et dans les 72 heures, et notifications du PDPC sur les mesures de sécurité et la notification des violations, B.E. 2565 (2022). Traduction anglaise publiée par le PDPC
- Consultation Paper: หลักการของการรักษาความมั่นคงปลอดภัยของการให้บริการทางการเงินผ่านช่องทางดิจิทัล (Digital Channel Security)BOT, juillet 2026, consultation du 23 juillet au 24 août 2026. Projet d'exigences uniquement : banque en ligne dans le périmètre, suppression des codes à usage unique par SMS pour les transactions, ajout des émetteurs de cartes et des prêteurs. Pas en vigueur
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écrit la BOT
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests de durcissement et authentifiés de votre application et de vos API avec notre équipe.