Gestion du risque technologique de la MAS : testez votre application bancaire mobile comme le décrit la MAS.
Les Technology Risk Management Guidelines de la MAS prévoient des mesures spécifiques pour les applications bancaires mobiles : anti-hooking et anti-altération, certificate pinning, blocage des appareils rootés et jailbreakés, authentification multifacteur et signature des transactions. Elles attendent aussi des tests d'intrusion en boîte noire et en boîte grise des services financiers en ligne au moins une fois par an. Ostorlab teste ces contrôles dans votre application et les API qui la sous-tendent, à chaque version.
- Vérifie la détection du root et du jailbreak, l'anti-altération, l'anti-instrumentation et le pinning, ainsi que la réaction de l'application lorsqu'ils se déclenchent
- Teste la connexion, les codes à usage unique, les vérifications d'authentification renforcée et la gestion des sessions avec vos comptes de test
- Suit l'application jusqu'à ses API, même avec TLS pinning
- Prouve chaque défaillance par des preuves de contournement ou un exploit rejouable
- Qui est concerné
- Les banques à Singapour et, pour les TRM Guidelines, les autres institutions financières régulées par la MAS
- Base juridique
- Notices FSM-N05 et FSM-N06 prises en application du Financial Services and Markets Act 2022, en vigueur depuis le 10 mai 2024
- Objet
- Services financiers en ligne, sécurité des applications mobiles et tests d'intrusion
- Texte de référence
- Technology Risk Management Guidelines de la MAS, janvier 2021
Comment les règles de la MAS pour la banque numérique se sont construites
Les TRM Guidelines fixent le socle technique. Des notices contraignantes et des mesures contre les arnaques s'y sont ajoutées depuis.
- 18 janvier 2021
TRM Guidelines révisées
Des pratiques de gestion du risque technologique pour les institutions financières, avec un chapitre sur les services financiers en ligne et une annexe sur la sécurité des applications mobiles.
- 19 janvier 2022
Mesures anti-phishing
La MAS et l'ABS annoncent des mesures pour les banques de détail, dont l'absence de liens cliquables dans les e-mails et SMS, et un délai d'au moins 12 heures avant l'activation d'un nouveau jeton logiciel sur un appareil mobile.
- 10 mai 2024
Notices FSM-N05 et FSM-N06
Les notices sur la gestion du risque technologique et sur la cyberhygiène des banques entrent en vigueur au titre du Financial Services and Markets Act 2022, en remplacement des Notices 644 et 655.
- 16 décembre 2024
Shared Responsibility Framework
Le cadre et les E-Payments User Protection Guidelines révisées entrent en vigueur, avec des obligations comme une période de réflexion et des alertes en temps réel qui déterminent qui supporte les pertes liées aux arnaques par phishing.
- 10 juin 2026
Consultation sur les TRM Notices
La MAS propose des modifications des TRM Notices, dont un inventaire des actifs informatiques couvrant les composants open source et tiers. La consultation s'est close le 31 juillet 2026.
- Chaque année
Tests d'intrusion
Pour les systèmes directement accessibles depuis Internet, la MAS attend des tests d'intrusion au moins une fois par an, ou à chaque changement ou mise à jour majeurs des systèmes.
Les règles de la MAS, 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.
- MAS TRM Guidelines, 14.1.4 et annexe C
Traiter les risques propres aux applications mobiles
Ce que dit le texte
Une institution financière qui propose des services financiers en ligne sur appareils mobiles devrait mettre en place des mesures spécifiques contre les risques des applications mobiles. L'annexe C les énumère : éviter de stocker ou de mettre en cache des données dans l'application, protéger les clés cryptographiques privées, mettre en œuvre des mécanismes anti-hooking ou anti-altération, des contrôles d'intégrité et l'obfuscation du code, le certificate pinning ou public key pinning, un clavier sécurisé intégré à l'application et le rattachement du jeton logiciel à l'appareil.
Ce que cela implique pour votre application mobile
L'annexe C se lit comme un plan de test de votre application. Chaque mesure peut être vérifiée sur le build que téléchargent vos clients.
Comment Ostorlab vous aide
Mobile Shielding Scan 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. Ostorlab recherche aussi les jetons et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran.
Ce qui reste de votre ressort
Le choix et la configuration de votre produit de blindage, la conception du clavier intégré et du rattachement à l'appareil.
- MAS TRM Guidelines, 14.1.7 et 14.2.8
Tenir les appareils rootés et jailbreakés à l'écart des transactions
Ce que dit le texte
Les appareils rootés ou jailbreakés ne devraient pas pouvoir accéder aux applications mobiles de l'institution financière pour effectuer des transactions financières, sauf si l'application est sécurisée dans un sandbox ou un conteneur qui la protège de l'altération et de l'interception par des malwares. L'activation des jetons logiciels devrait inclure des mesures comme la vérification de l'identité du client, la détection et le blocage des appareils rootés ou jailbreakés, et le rattachement à l'appareil.
Ce que cela implique pour votre application mobile
La détection seule ne suffit pas. L'application doit bloquer la transaction ou l'activation du jeton lorsque l'appareil est compromis, et la vérification ne devrait pas être facile à désactiver.
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 et montre ce que fait ensuite l'application. Vous obtenez un score de durcissement et des preuves de contournement.
Ce qui reste de votre ressort
La politique applicable aux appareils compromis et le choix de la technologie de sandbox ou de conteneur.
- MAS TRM Guidelines, 14.2.1 à 14.2.5
Utiliser la MFA à la connexion et signer les actions à haut risque
Ce que dit le texte
Déployez l'authentification multifacteur à la connexion aux services financiers en ligne. Chiffrez les mots de passe des clients de bout en bout entre l'application mobile ou le navigateur et le système qui les vérifie. Mettez en œuvre la signature des transactions pour les activités à haut risque, comme la modification des coordonnées, l'enregistrement d'un bénéficiaire tiers, les virements de montant élevé et la modification des plafonds de virement. Maintenez la validité des OTP basés sur le temps aussi courte que possible.
Ce que cela implique pour votre application mobile
Les modifications de bénéficiaire, les relèvements de plafond et les changements de coordonnées sont les cibles des fraudeurs. L'étape de signature doit tenir côté serveur, quoi que l'application envoie.
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
Le choix des méthodes d'authentification et de signature, et la fixation de la validité des OTP et des plafonds.
- MAS TRM Guidelines, 14.2.6, 14.2.9 et 14.2.11
Protéger les sessions et les identifiants
Ce que dit le texte
Préservez l'intégrité de la session authentifiée et de son chiffrement tout au long de l'interaction, détectez et interrompez les sessions détournées, et mettez fin automatiquement aux sessions en ligne après une période d'inactivité prédéfinie. Chiffrez les données biométriques et les identifiants au repos et en transit, et stockez les identifiants sous une forme qui résiste à la rétro-ingénierie.
Ce que cela implique pour votre application mobile
L'expiration des sessions, l'invalidation des jetons à la déconnexion et la manière dont les identifiants sont conservés sur l'appareil sont des comportements concrets et testables de l'application et de son backend.
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 effective de la MFA, et l'analyse du trafic montre comment les identifiants transitent de l'application vers le backend.
Ce qui reste de votre ressort
Les valeurs des délais d'expiration, le calibrage biométrique et le processus de révocation des identifiants.
- MAS TRM Guidelines, 6.4.4 à 6.4.7
Sécuriser et tester vos API avant la mise en production
Ce que dit le texte
Définissez pour les API des normes de sécurité qui protègent les clés d'API et les jetons d'accès, avec une expiration raisonnable et effectivement appliquée pour les jetons d'accès. Utilisez un chiffrement fort pour les données sensibles transmises par les API. Soumettez chaque API à un contrôle et à des tests de sécurité rigoureux avant son déploiement en production, surveillez l'usage des API pour détecter toute activité suspecte, et soyez en mesure de révoquer rapidement les clés ou jetons après une violation.
Ce que cela implique pour votre application mobile
Les API que votre application appelle véhiculent les mêmes données que l'application. Leur contrôle d'accès et leur gestion des jetons doivent être testés avant chaque version, et pas une seule fois.
Comment Ostorlab vous aide
Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR), d'usages abusifs des jetons et des sessions, et d'abus comme l'énumération, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui de chaque résultat.
Ce qui reste de votre ressort
La conception des API, l'évaluation des tiers, la surveillance des API en temps réel et la révocation des clés.
- MAS TRM Guidelines, 6.1 à 6.3 et annexe A
Tester la sécurité applicative au fil du développement
Ce que dit le texte
Adoptez des normes de développement sécurisé, de revue de code source et de tests de sécurité applicative. Examinez et testez le code tiers et open source avant son intégration, et suivez ses mises à jour et les vulnérabilités signalées. Combinez des méthodes de test statiques, dynamiques et interactives. Suivez tous les problèmes détectés, et corrigez les problèmes majeurs avant le déploiement en production. Appliquez les mêmes normes en Agile et en DevSecOps.
Ce que cela implique pour votre application mobile
Chaque version de l'application devrait passer des tests de sécurité automatisés avant d'arriver sur le store, y compris les SDK et bibliothèques qu'elle embarque.
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) sur les SDK intégrés. Mobile DAST exécute l'application, et SCA identifie les bibliothèques compilées statiquement. L'ensemble s'exécute depuis votre pipeline CI/CD à chaque build.
Ce qui reste de votre ressort
Les normes de développement sécurisé, la formation des développeurs, la revue manuelle du code et la séparation des tâches.
- MAS TRM Guidelines, 13.1, 13.2 et 13.6
Réaliser des évaluations de vulnérabilité et des tests d'intrusion
Ce que dit le texte
Réalisez régulièrement des évaluations de vulnérabilité, à une fréquence adaptée à la criticité et à l'exposition du système, y compris sur les vulnérabilités applicatives. Combinez des tests d'intrusion en boîte noire et en boîte grise pour les services financiers en ligne ; la boîte grise consiste à tester avec les mêmes droits qu'un client ordinaire. Pour les systèmes directement accessibles depuis Internet, réalisez des tests d'intrusion au moins une fois par an ou à chaque changement ou mise à jour majeurs. Suivez et résolvez les problèmes avec des niveaux de gravité et des délais de remédiation.
Ce que cela implique pour votre application mobile
Votre application bancaire mobile et ses API sont exposées à Internet. Prévoyez au moins un test d'intrusion par an, testez à nouveau lors des versions majeures, et incluez des tests authentifiés.
Comment Ostorlab vous aide
Un pentest par agents IA teste l'application et ses API derrière la connexion, sur le build 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 et retestés une fois le correctif publié.
Ce qui reste de votre ressort
Le choix de l'intervenant chargé de votre test d'intrusion annuel, les tests en production, le bug bounty et les exercices red team.
- MAS Notice FSM-N05, paragraphe 9 ; MAS Notice FSM-N06, paragraphes 4.2, 4.3 et 4.6
Respecter les notices contraignantes pour les banques
Ce que dit le texte
La Notice FSM-N05 impose aux banques de mettre en œuvre des contrôles informatiques pour protéger les informations des clients contre l'accès ou la divulgation non autorisés. La Notice FSM-N06 impose d'appliquer les correctifs de sécurité dans un délai proportionné au risque de chaque vulnérabilité, de disposer d'un ensemble écrit de normes de sécurité pour chaque système, et d'utiliser l'authentification multifacteur pour tous les comptes de tout système utilisé pour accéder aux informations des clients via Internet.
Source :MAS Notice FSM-N05, paragraphe 9 ; MAS Notice FSM-N06, paragraphes 4.2, 4.3 et 4.6
Ce que cela implique pour votre application mobile
Il s'agit d'obligations, pas de recommandations. C'est par l'application et ses API que les clients accèdent à leurs informations : leurs contrôles font donc partie des preuves.
Comment Ostorlab vous aide
Ostorlab teste les contrôles qui protègent les informations des clients dans l'application et ses API, et SCA rapproche les composants de chaque version des vulnérabilités connues et suit leur résolution.
Ce qui reste de votre ressort
L'application des correctifs sur les serveurs et l'infrastructure, les normes de sécurité de chaque système et les comptes d'administration.
- Guidelines on Shared Responsibility Framework, 4.2 et 6.2
Intégrer les obligations anti-arnaque dans l'application
Ce que dit le texte
Au titre du Shared Responsibility Framework, une institution financière responsable doit imposer une période de réflexion d'au moins 12 heures, pendant laquelle les activités à haut risque ne peuvent pas être effectuées, lorsqu'un jeton de sécurité numérique est activé sur un appareil. Elle doit envoyer des alertes en temps réel pour l'activation des jetons et les activités à haut risque, proposer une fonction en libre-service permettant de bloquer l'accès mobile et en ligne, et assurer une surveillance de la fraude en temps réel. L'institution est censée supporter les pertes résultant du non-respect de ces obligations.
Source :Guidelines on Shared Responsibility Framework, 4.2 et 6.2
Ce que cela implique pour votre application mobile
Plusieurs de ces obligations se trouvent dans l'application : la période de réflexion, les alertes et le kill switch. S'ils peuvent être contournés via l'application ou ses API, la perte pourrait être la vôtre.
Comment Ostorlab vous aide
Le pentest par agents IA teste la logique métier des parcours de paiement et de gestion de compte, et les tests d'API vérifient les autorisations et le rejeu sur les appels derrière les modifications de compte.
Ce qui reste de votre ressort
La surveillance de la fraude, l'envoi des alertes, le canal de signalement et l'évaluation des pertes.
Synthèse des textes publics de la MAS, vérifiés le 27 septembre 2026. Les TRM Guidelines sont des recommandations, et la MAS prend en compte le degré de respect de leur esprit lorsqu'elle supervise une institution financière. Cette page ne constitue pas un avis juridique.
Les règles de la MAS, contrôle par contrôle
Les contrôles visés par les textes de la MAS, 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 |
|---|---|---|
| Anti-hooking, anti-altération et pinningTRM, annexe C | Modifie le binaire, injecte des débogueurs et des hooks, et tente de contourner le TLS pinning. Détails | Preuves des protections qui ont tenu et de celles qui ont été contournées |
| Blocage des appareils rootés et jailbreakésTRM 14.1.7, 14.2.8 | Exécute l'application dans des environnements rootés et jailbreakés et tente de contourner la détection du root et du jailbreak. Détails | Score de durcissement, et preuves de contournement pour chaque protection qui a échoué |
| Aucune donnée sensible stockée ou mise en cache dans l'applicationTRM, annexe C | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Protection des clés et des identifiants dans l'applicationTRM, annexe C, 14.2.11 | 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 |
| MFA à la connexion et signature des actions à haut risqueTRM 14.2.1 à 14.2.5 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Expiration des sessions et sessions détournéesTRM 14.2.9 | Teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Jetons d'API et tests avant la mise en productionTRM 6.4.4 à 6.4.6 | 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 |
| Tests statiques et dynamiques avant la mise en productionTRM 6.1.6, 6.1.7, annexe A | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, avant la mise en production. Détails | Résultats avec contexte du code décompilé, trafic, traces d'appels et captures d'écran |
| Code tiers et open sourceTRM 6.1.3, 6.1.4 | 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 |
| Tests en boîte grise et suivi de la remédiationTRM 13.2.1, 13.6 | Pentest par agents IA de l'application et de ses API, derrière la connexion, avec tickets et retests. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et les résultats de retest |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance de la fraude, la surveillance SOC, les objectifs de reprise, le signalement des incidents à la MAS, les cyberexercices, le red teaming et la supervision par le conseil d'administration restent du ressort de vos équipes.
Les contrôles de la MAS à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque technologique, fondée sur les TRM Guidelines et les obligations anti-arnaque.
Appareils compromis
Exécutez l'application sur des appareils rootés et jailbreakés et vérifiez que les transactions et l'activation du jeton logiciel sont bloquées.
Protections de l'annexe C
Testez l'anti-hooking, l'anti-altération, les contrôles d'intégrité et le pinning face à un build modifié et à des hooks à l'exécution.
Données laissées sur l'appareil
Recherchez les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, ainsi que les clés et identifiants dans le package de l'application.
Signature des transactions
Vérifiez que l'ajout d'un bénéficiaire, le relèvement des plafonds et la modification des coordonnées exigent tous une signature, imposée par le serveur.
Sessions et OTP
Vérifiez l'expiration après inactivité, l'invalidation des sessions, la validité des OTP et la protection contre le rejeu.
API avant la production
Testez les autorisations et l'expiration des jetons sur chaque API appelée par l'application, avant que chaque version n'arrive en production.
Test annuel en boîte grise
Planifiez des tests d'intrusion de l'application et de ses API au moins une fois par an et lors des changements majeurs, y compris des tests avec des identifiants clients.
Obligations anti-arnaque
Confirmez que la période de réflexion, les alertes en temps réel et le kill switch ne peuvent pas être contournés via l'application ou ses API.
Une liste indicative, et non un modèle de la MAS. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- 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
- 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
- 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.
- Guidelines on Risk Management Practices: Technology Risk (Technology Risk Management Guidelines)MAS, janvier 2021, publiées le 18 janvier 2021. Chapitres 6 (développement logiciel et API), 13 (évaluation de la cybersécurité) et 14 (services financiers en ligne), et annexes A et C
- MAS Notice FSM-N05: Notice on Technology Risk ManagementMAS, émise le 9 mai 2024 en application de la section 29(1) du Financial Services and Markets Act 2022, en vigueur le 10 mai 2024. S'applique à toutes les banques à Singapour
- MAS Notice FSM-N06: Notice on Cyber HygieneMAS, émise le 9 mai 2024, en vigueur le 10 mai 2024. Remplace la Notice 655, abrogée avec effet au 10 mai 2024
- Guidelines on Shared Responsibility FrameworkMAS et IMDA, émises le 24 octobre 2024, en vigueur le 16 décembre 2024. Obligations des banques et des grands établissements de paiement contre les arnaques par phishing, et répartition des pertes
- E-Payments User Protection GuidelinesMAS, version en vigueur depuis le 16 décembre 2024. Obligations des institutions financières responsables et des titulaires de comptes protégés
- MAS and ABS Announce Measures to Bolster the Security of Digital BankingCommuniqué de presse de la MAS, 19 janvier 2022. Mesures anti-phishing pour les banques de détail, dont le délai de 12 heures avant l'activation d'un jeton logiciel
- Additional Measures to Strengthen the Security of Digital BankingCommuniqué de presse de la MAS, 2 juin 2022. Mesures supplémentaires, dont un kill switch et un plafond de virement en ligne par défaut de 5 000 S$ ou moins, pleinement effectives au 31 octobre 2022
- Consultation Paper on Proposed Amendments to Notices on Technology Risk Management (P012-2026)MAS, 10 juin 2026, close le 31 juillet 2026. Exigences proposées uniquement, pas encore 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.
Testez votre application bancaire mobile au regard des contrôles de la MAS
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests de blindage et des tests authentifiés avec notre équipe.