October 2, 2026
October 2, 2026
La plupart des guides sur la création d'une application bancaire raisonnent depuis une position réglementaire occidentale, en citant la DSP2 et le RGPD. Si vous lancez à Singapour ou en Malaisie, un autre corpus de règles écrit une partie de votre backlog, et certaines obligations doivent être remplies avant même d'avoir le droit de lancer. Ce guide expose ce que ces règles exigent, et où part le budget.
En bref : une application bancaire en Malaisie doit satisfaire l'annexe 4 du RMiT de la BNM, qui interdit de stocker les identifiants d'authentification sur l'appareil, impose un environnement d'exécution inviolable et impose de surveiller les magasins d'applications pour détecter les copies frauduleuses. Tout nouveau service digital doit être notifié à la BNM avant son lancement, avec une assurance de sécurité externe indépendante.
Ce que le régulateur inscrit dans votre backlog
Lisez cette liste comme un backlog produit et non comme de la paperasse de conformité. Environ un tiers contraint l'architecture, un tiers représente du travail d'ingénierie, et le reste relève de processus qui tournent après la mise en service.
Les guides publiés sur ce sujet sont fournis et globalement exacts pour les marchés qu'ils traitent. Le problème tient au marché qu'ils présupposent. En examinant les pages actuellement positionnées sur ce sujet, les cadres cités sont la DSP2, le RGPD, le CCPA, la norme PCI DSS, l'ISO 27001 et l'OWASP MASVS. Aucune ne mentionne l'Autorité monétaire de Singapour, Bank Negara Malaysia ou l'Agence de cybersécurité de Singapour.
Cela compte, car les exigences d'Asie du Sud-Est ne sont pas un sous-ensemble des exigences européennes. La DSP2 encadre l'initiation de paiement et l'authentification forte du client. Elle ne dit rien de la surveillance des plateformes de distribution pour détecter les contrefaçons de votre application, que la Malaisie impose explicitement. Construire sur une liste de contrôle européenne en supposant que la région est couverte, c'est découvrir l'écart pendant l'assurance préalable au lancement, au moment le plus coûteux pour le découvrir.
Si vous construisez à la fois pour l'Europe et pour l'Asie du Sud-Est, traitez les deux comme des ensembles qui se recoupent avec des bords différents, et cartographiez leur union avant de chiffrer.
Avant tout chiffrage, établissez ce que vous êtes aux yeux du régulateur, car les obligations s'adressent à des entités agréées et non à des applications.
En Malaisie, le RMiT vise les banques agréées, les banques d'investissement, les banques islamiques, les assureurs, les opérateurs takaful et les institutions financières de développement. La révision de novembre 2025 a élargi ce périmètre aux acquéreurs marchands non bancaires et aux institutions de remise intermédiaires dépassant 5 pour cent de part de valeur ou de volume de transactions, ce qui a fait entrer dans le champ des sociétés de paiement qui en étaient jusque-là exclues.
À Singapour, les lignes directrices du Shared Responsibility Framework visent les banques de plein exercice, constituées localement comme en succursale, ainsi que les grandes institutions de paiement.
Trois situations reviennent souvent et méritent d'être tranchées tôt. Si vous êtes l'établissement agréé, les obligations vous incombent directement. Si vous construisez sous la licence d'un partenaire, elles pèsent sur ce partenaire, mais elles vous parviendront par le contrat, et le prestataire d'assurance du partenaire examinera votre travail. Si vous êtes un prestataire qui construit pour un client agréé, vous n'êtes pas la partie régulée, mais votre livrable devra passer une évaluation dont les critères sont publiés : vous pouvez donc concevoir en vous y conformant dès le départ.
L'erreur à éviter consiste à supposer qu'être une société technologique plutôt qu'une banque met ces exigences hors sujet. Elles s'appliquent au produit, quelle que soit la société qui emploie les ingénieurs.
Les listes de fonctionnalités mélangent le plus souvent trois types d'éléments très différents. Les séparer rend le chiffrage bien plus fiable.
Le socle attendu. Solde et historique des opérations, virements, paiement de factures, pilotage de la carte dont le blocage immédiat, relevés, accès au support. Les utilisateurs s'y attendent et les concurrents les proposent. Ces éléments différencient peu et leur coût est bien connu.
Ce qu'impose le régulateur. Les points du tableau ci-dessus. Ils ne se négocient pas, ils sont fréquemment sous-estimés parce qu'ils sont invisibles dans l'interface, et plusieurs contraignent l'architecture au lieu d'ajouter des écrans. La vérification des identifiants centralisée chez l'hôte en est l'exemple le plus net : décidée tard, elle impose de refaire la couche d'authentification.
Ce qui différencie. Analyse budgétaire, objectifs d'épargne, souscription de nouveaux produits dans l'application, statistiques de dépenses, offres personnalisées. C'est là que les équipes produit veulent investir, et c'est là que le budget part si la deuxième catégorie a été sous-estimée.
L'échec classique consiste à planifier les catégories un et trois, puis à découvrir la catégorie deux lors d'une revue de sécurité. L'ordonnancement compte ici plus que les totaux.
Pour les notions générales de cadrage et de processus, notre guide sur le développement d'applications mobiles couvre les fondamentaux valables pour toute application, et notre article sur le développement d'applications mobiles sur mesure traite des choix de construction.
Le document de politique révisé sur la gestion du risque technologique de Bank Negara Malaysia est entré en vigueur le 28 novembre 2025 et comporte une annexe consacrée aux applications et appareils mobiles. Elle est inhabituellement concrète pour un texte réglementaire, ce qui la rend directement utilisable comme critères d'acceptation techniques.
Les exigences côté client figurent au point 2. L'application doit être conçue pour fonctionner dans un environnement sécurisé et inviolable au sein de l'appareil, afin de protéger les utilisateurs contre les menaces telles que les logiciels malveillants et les accès non autorisés, la note de bas de page définissant cet environnement comme non compromis, non jailbreaké et non rooté. Il est interdit aux applications de stocker les informations d'authentification du client, tels que le code PIN et les mots de passe, et l'authentification ainsi que la vérification des clés uniques et du PIN doivent être centralisées chez l'hôte. L'activation de l'application doit être soumise à une authentification robuste par l'établissement. Le provisionnement et le déprovisionnement sur l'appareil du client doivent l'un et l'autre être sécurisés.
Trois autres exigences portent sur la distribution plutôt que sur le code. L'établissement doit procéder à une due diligence garantissant que les plateformes de distribution utilisées sont réputées, doit encadrer les accès permettant de maintenir et de téléverser l'application sur ces plateformes, et doit surveiller ces plateformes afin d'identifier et de traiter en temps utile la diffusion de fausses applications.
Ce dernier point mérite d'être souligné, car il s'agit d'un coût d'exploitation et non d'un coût de construction. Quelqu'un doit surveiller les magasins après le lancement, et les procédures de retrait doivent exister avant d'en avoir besoin.
Le point 3 vise les appareils utilisés par l'établissement, ses agents ou intermédiaires pour traiter des informations clients : appareils durcis, capacité d'effacement à distance des données en cas de perte ou de vol déclaré, conformité aux normes du secteur des paiements par carte, masquage des informations sensibles à l'écran, et limite de 30 jours pour la conservation des informations clients utilisées pour la sollicitation en assurance et en takaful.
Deux clauses générales s'appliquent également à l'application. La S 10.55 impose une authentification multifacteur capable de résister à l'ingénierie sociale, combinant au moins deux facteurs parmi les facteurs de connaissance, les facteurs inhérents comme la biométrie, et les facteurs de possession comme les jetons. La S 10.57(c) impose de journaliser l'activité des utilisateurs sur les systèmes critiques, avec des journaux conservés au moins trois ans et revus régulièrement.
Singapour aborde le même problème par un autre angle, et la distinction entre contraignant et consultatif y est déterminante.
Les lignes directrices sur le Shared Responsibility Framework ont été publiées par la MAS le 24 octobre 2024 et mises en œuvre le 16 décembre 2024. Elles visent les banques de plein exercice, constituées localement comme en succursale, ainsi que les grandes institutions de paiement. Le dispositif répartit la responsabilité des pertes issues d'un périmètre défini d'escroqueries par hameçonnage entre les consommateurs, les établissements financiers et les opérateurs télécoms, et impose des indemnisations en cas de manquement aux obligations. Parmi les obligations des établissements figure une surveillance de la fraude en temps réel visant à détecter les opérations non autorisées qui vident un compte, l'établissement devant alors soit bloquer l'opération jusqu'à ce qu'il puisse joindre le client pour confirmation, soit notifier le client et suspendre l'opération. La MAS a prévu une période de transition pour cette obligation particulière.
La conséquence est produit est que la détection de fraude n'est pas une fonctionnalité analytique optionnelle. C'est une capacité au comportement défini, assortie d'une responsabilité en cas de défaillance.
Le Safe App Standard relève d'un statut différent, souvent mal rapporté. Il est publié par l'Agence de cybersécurité de Singapour, et non par la MAS, et sa version 2.0 date du 15 octobre 2024. Il couvre huit domaines : authentification, autorisation, stockage des données au repos, protection contre l'altération et la rétro-ingénierie, communication réseau, cryptographie, qualité du code et mesures d'atténuation des exploits, et interactions avec la plateforme. L'Agence encourage fortement son adoption, en particulier pour les applications développées et hébergées à Singapour et pour les applications à haut risque traitant des opérations susceptibles de causer des pertes financières importantes.
Il s'agit d'une norme recommandée et non d'une obligation légale. Traitez-la comme une base de sécurité bien spécifiée et une liste d'acceptation utile, et ne présentez pas à votre conseil comme obligatoire ce qui ne l'est pas.
Voici une observation gênante sur les fourchettes publiées. Deux des guides les plus visibles sur ce sujet situent une application bancaire de base respectivement entre 50 000 et 150 000 dollars américains, et entre 40 000 et 80 000 dollars. Ce sont deux descriptions du même palier qui diffèrent de près du double. Une troisième source place encore ce palier ailleurs.
Ces fourchettes ne sont pas malhonnêtes. Elles résultent de moyennes établies sur des marchés, des taux journaliers, des définitions de périmètre et des hypothèses d'intégration qui ne sont jamais tenus constants. Publier ici une dixième fourchette n'apporterait rien. Cette section fait donc quelque chose de plus utile et décrit ce qui fait bouger le chiffre dans une construction bancaire régulée en Asie du Sud-Est.
Les facteurs de coût généraux d'une application mobile sont traités dans nos guides existants sur les facteurs influençant le prix et le coût et sur le coût de développement d'une application mobile à Singapour. Ce qui suit est le surcoût propre au secteur bancaire, qui s'ajoute à ces facteurs.
Trois conclusions découlent de ce tableau, et ce sont elles qui servent.
D'abord, plusieurs des postes les plus lourds sont récurrents et non ponctuels. Un devis de construction qui s'arrête au lancement n'a chiffré ni la surveillance des contrefaçons, ni la conservation des journaux, ni les effectifs de surveillance de la fraude. En comparant des propositions, demandez explicitement lesquels de ces postes sont inclus, et pour quelle durée.
Ensuite, un poste est une dépendance de calendrier et non une ligne budgétaire. La notification préalable et l'assurance externe se trouvent sur le chemin critique : une date de lancement fixée sans les prévoir est une date qui bougera.
Enfin, les contraintes architecturales sont les moins coûteuses à satisfaire tôt et les plus coûteuses à rattraper. La vérification des identifiants centralisée chez l'hôte, décidée en semaine deux, coûte une discussion de conception. Décidée après une revue de sécurité, elle coûte une refonte de l'authentification et une nouvelle campagne de tests.
Puisque l'assurance indépendante se trouve sur le chemin critique en Malaisie, il vaut la peine de savoir ce qu'elle couvre avant de planifier autour d'elle. L'annexe 7 du RMiT le précise, et le détail change la façon dont on planifie.
L'assurance doit être réalisée par un prestataire de services externe indépendant engagé par l'établissement. Ce prestataire est censé comprendre les services proposés, les flux de données, l'architecture du système, la connectivité et ses dépendances, ce qui exclut une revue superficielle. Sa mission consiste à examiner le caractère complet de l'évaluation des risques menée par l'établissement et à valider l'adéquation des mesures de contrôle mises en place ou prévues.
Le rapport d'évaluation des risques qui en résulte doit indiquer le périmètre de la revue, la méthodologie d'évaluation des risques, une synthèse des constats et les actions correctives éventuelles. La partie D de l'annexe 7 énumère les domaines minimaux que le prestataire doit évaluer, le cas échéant : contrôle d'accès, sécurité physique et environnementale, sécurité des opérations, sécurité des communications, gestion des incidents de sécurité de l'information, et aspects de sécurité de l'information dans la gestion de la continuité d'activité.
Une exigence de la partie C reconfigure tout le calendrier. Le rapport doit confirmer qu'aucune exception n'a été relevée, ce que le texte qualifie d'attestation négative. C'est un standard de rapport sans réserve, et non un standard de constats assortis d'un plan de remédiation.
L'effet pratique est que des constats ouverts bloquent la notification, donc le lancement. Les équipes habituées à livrer avec un arriéré priorisé de constats de sécurité acceptés ne trouveront pas cette souplesse ici. Planifiez l'assurance assez tôt pour permettre un cycle de remédiation et un nouveau test avant la date de notification prévue, et considérez le premier passage comme un diagnostic plutôt que comme un verdict.
Notez aussi que le périmètre d'évaluation dépasse l'application elle-même pour atteindre l'exploitation, la gestion des incidents et la continuité d'activité. Une prestation cadrée comme un simple test d'intrusion mobile reviendra incomplète.
L'ordre ci-dessous reflète la position réelle des dépendances plutôt qu'un cycle en cascade générique.
Commencez par confirmer quel régime s'applique et à quel niveau, car les obligations diffèrent entre une banque agréée, une institution de paiement et un partenaire qui construit sous la licence d'un tiers. Inscrivez les éléments imposés par le régulateur dans le backlog avant les fonctionnalités différenciantes, puisqu'ils contraignent l'architecture. Figez tôt la conception de l'authentification et du traitement des identifiants, car c'est la contrainte dont la portée en aval est la plus large. Commandez la prestation d'assurance indépendante avec assez d'avance pour que ses constats soient corrigés avant la notification, et non après. Planifiez enfin les obligations d'exploitation postérieures au lancement, qui comprennent la surveillance des magasins, la surveillance de la fraude et la conservation des journaux, et attribuez-les à un responsable nommé.
Une règle empirique utile : tout ce que le régulateur impose et qui ne se voit pas dans l'interface doit être planifié plus tôt qu'il n'y paraît nécessaire, car ce sont les éléments qui échouent tard et bruyamment.
Lorsque l'application dépend de systèmes qui doivent rester disponibles, les mêmes régulateurs fixent des seuils distincts pour l'indisponibilité et la déclaration des incidents, qui sortent du périmètre de cet article mais doivent être planifiés en parallèle.
Conclusion
Avant de demander des devis, rédigez la liste des exigences réglementaires sous forme de user stories assorties de critères d'acceptation, et soumettez-la à tout prestataire envisagé. C'est un filtre rapide. Un partenaire qui a déjà construit sur ces marchés reconnaîtra les points et vous dira lesquels contraignent votre architecture. Un partenaire qui ne les connaît pas les traitera comme un chantier de sécurité à planifier plus tard, et c'est la réponse qui coûte cher.
Serdao conçoit des logiciels depuis dix-huit ans, avec un siège en France et une production à Hô Chi Minh-Ville, ce qui réunit la pratique réglementaire européenne et les horaires de l'Asie du Sud-Est dans une même équipe. Nous sommes membres de la CCI France Vietnam et de French Tech. Notre page développement d'applications mobiles détaille notre façon de cadrer ce travail, et vous pouvez contacter notre équipe pour confronter votre liste de fonctionnalités aux exigences ci-dessus.
Le Safe App Standard est-il obligatoire à Singapour ?
Non. Il est publié par l'Agence de cybersécurité de Singapour comme norme recommandée, et l'Agence en encourage fortement l'adoption, en particulier pour les applications développées et hébergées à Singapour et pour les opérations financières à haut risque. Ce n'est pas une réglementation de la MAS, bien qu'il soit fréquemment décrit comme telle. Ses huit domaines de contrôle restent une base d'acceptation pertinente.
Peut-on stocker un code PIN sur l'appareil pour accélérer la connexion en Malaisie ?
Non. Le point 2(b) de l'annexe 4 du RMiT interdit aux applications mobiles de stocker les informations client utilisées pour l'authentification auprès du serveur, tels que le PIN et les mots de passe, et impose de centraliser chez l'hôte l'authentification et la vérification des clés uniques et du PIN. Les schémas de ressaisie rapide doivent être conçus autour de cette contrainte.
Faut-il prévenir le régulateur avant de lancer ?
En Malaisie, oui. La S 16.1 du RMiT impose à un établissement financier de notifier la Banque avant d'introduire de nouveaux services digitaux ou des améliorations aux services existants. Pour les améliorations qui ne relèvent pas de la notification simplifiée, la S 16.4 impose en outre une assurance externe indépendante sur les risques technologiques et les contrôles de sécurité, ainsi qu'une confirmation de préparation par le RSSI, un dirigeant ou le président du conseil.
Combien de temps faut-il conserver les journaux d'activité ?
La S 10.57(c) du RMiT impose de journaliser l'activité des utilisateurs sur les systèmes critiques et de conserver ces journaux au moins trois ans, avec une revue régulière. Prévoyez le budget de restitution autant que celui de stockage : un journal que l'on ne sait pas interroger dans un délai de déclaration ne sert pas à grand-chose.
La connexion biométrique suffit-elle à satisfaire l'exigence de MFA ?
Pas à elle seule. La S 10.55 du RMiT exige au moins deux facteurs pris parmi les catégories connaissance, inhérent et possession, et impose que la combinaison résiste à l'ingénierie sociale. Une empreinte digitale seule constitue un unique facteur inhérent. La vraie question de conception porte sur ce qui l'accompagne, et sur la tenue de ce couple face à une victime manipulée.
Nous sommes déjà conformes au RGPD et à la DSP2. Est-ce suffisant ?
Non. Les deux ensembles d'exigences se recoupent sans que l'un contienne l'autre. La surveillance des applications contrefaites, la notification préalable au régulateur et la conservation des journaux sur trois ans n'ont pas d'équivalent dans la DSP2. Cartographiez l'union des deux régimes plutôt que de supposer que le plus strict en apparence couvre l'autre.