Règles du PBOC et de la NFRA : évaluez votre application bancaire mobile avant chaque version.

1. 01

   Circulaire PBOC 银发〔2019〕237号 ; JR/T 0092-2019, chapitres 4 à 6 (texte chinois)

   Respecter le socle de sécurité des applications mobiles

   Ce que dit le texte

   La norme s'applique aux logiciels clients d'applications financières mobiles et couvre les exigences de sécurité ainsi que la gestion de la conception, du développement, de la maintenance et de la publication. Elle classe les applications en trois catégories : transactions financières, collecte d'informations et consultation d'informations. Les applications de transaction doivent satisfaire à toutes les exigences techniques et de gestion, et les applications de collecte doivent se concentrer sur la protection des informations. Chaque exigence est marquée comme de base ou renforcée : les exigences de base sont les protections minimales, les exigences renforcées sont recommandées. La circulaire 237 impose une évaluation externe des applications de transaction du point de vue de la sécurité des fonds et de la protection des informations, et des applications de collecte du point de vue de la protection des informations, au moins une fois par an, avec rapport conservé.

   Source :Circulaire PBOC 银发〔2019〕237号 ; JR/T 0092-2019, chapitres 4 à 6 (texte chinois)

   Ce que cela implique pour votre application mobile

   La liste des clauses ressemble à un plan de test pour la version que téléchargent vos clients, de la signature et des contrôles d'intégrité à la protection des saisies, au stockage et à l'effacement des données.

   Comment Ostorlab vous aide

   Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans code source. Un pentest par agents IA teste l'application et ses API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et Mobile Shielding Scan teste les protections à l'exécution.

   Ce qui reste de votre ressort

   L'évaluation externe auprès d'un organisme de certification et de test accrédité, et le calendrier des évaluations annuelles.

2. 02

   Circulaire PBOC 银发〔2019〕237号 ; mesures et avis d'enregistrement de la NIFA (texte chinois)

   Enregistrer l'application auprès de la NIFA et tenir l'évaluation à jour

   Ce que dit le texte

   La circulaire 237 demande aux institutions financières de participer à l'enregistrement nominatif des applications financières mobiles auprès de l'Association nationale de la finance sur internet de Chine (NIFA), qui exploite le système d'enregistrement à l'adresse finapp.nifa.org.cn. L'enregistrement exige un rapport d'évaluation externe pour les applications de transaction et de collecte, l'enregistrement est valable un an, et une modification majeure ou un enregistrement non actualisé dans l'année déclenche une nouvelle évaluation externe. La NIFA contrôle les évaluations annuelles et peut suspendre ou annuler un enregistrement, et elle a conseillé aux magasins d'applications la prudence face aux applications financières non enregistrées. La NIFA a indiqué qu'à fin 2025, 844 institutions avaient enregistré 2 773 applications financières mobiles.

   Source :Circulaire PBOC 银发〔2019〕237号 ; mesures et avis d'enregistrement de la NIFA (texte chinois)

   Ce que cela implique pour votre application mobile

   L'enregistrement et l'évaluation annuelle sont des obligations récurrentes, et l'évaluation est la preuve d'un contrôle par un tiers, pas une auto-déclaration.

   Comment Ostorlab vous aide

   Les scans Ostorlab produisent des preuves datées par version que votre équipe peut joindre à l'évaluation externe et à la mise à jour de l'enregistrement, et les scans sont rejouables quand une nouvelle version exige une évaluation fraîche.

   Ce qui reste de votre ressort

   L'enregistrement lui-même, la relation avec l'organisme de certification et de test, et la décision sur ce qui constitue une modification majeure.

3. 03

   Circulaire MIIT 工信部信管〔2023〕105号 ; loi sur la cybersécurité modifiée le 28 octobre 2025 (texte chinois)

   Enregistrer l'application auprès du MIIT avant sa mise en service

   Ce que dit le texte

   Le ministère de l'Industrie et des Technologies de l'information impose aux fournisseurs d'applications de services d'information en ligne en Chine continentale de s'enregistrer via leur fournisseur d'accès réseau ou leur plateforme de distribution. Les nouvelles applications doivent s'enregistrer avant le début du service, et les applications existantes devaient le faire entre septembre 2023 et le 31 mars 2024. Les administrations des télécommunications contrôlent les enregistrements en continu, et les fournisseurs qui ne s'enregistrent pas ne peuvent pas fournir de services d'information par application. La modification de 2025 de la loi sur la cybersécurité impose aussi des obligations de sécurité aux fournisseurs de services de téléchargement d'applications, avec des sanctions pouvant inclure la suspension d'activité ou la fermeture de l'application.

   Source :Circulaire MIIT 工信部信管〔2023〕105号 ; loi sur la cybersécurité modifiée le 28 octobre 2025 (texte chinois)

   Ce que cela implique pour votre application mobile

   Une application bancaire est à la fois une application financière pour le PBOC et la NIFA et une application de services d'information en ligne pour le MIIT. Les deux enregistrements sont distincts.

   Comment Ostorlab vous aide

   Ostorlab n'enregistre pas les applications. Il fournit des preuves de sécurité datées qui appuient vos dossiers d'enregistrement et les déclarations de sécurité qui les accompagnent, version après version.

   Ce qui reste de votre ressort

   Les enregistrements eux-mêmes, les fiches des magasins d'applications et les réponses à l'administration des télécommunications.

4. 04

   JR/T 0068-2020, 6.2.1 ; JR/T 0092-2019, 5.3.3 et 5.3.4 (texte chinois)

   Sécuriser le programme client lui-même

   Ce que dit le texte

   Les programmes clients doivent éviter les risques liés aux composants système, aux composants tiers et aux SDK, avec des tests de sélection si nécessaire. Ils doivent porter un identifiant d'application et un numéro de version clairs, être signés par le propriétaire de l'application pour indiquer l'origine et l'éditeur, et vérifier leur authenticité et leur intégrité au démarrage et lors des mises à jour pour résister à l'altération, au remplacement ou au détournement. Ils doivent utiliser l'obfuscation et le packing, se protéger contre l'injection de code, l'élévation de privilèges et l'accès au processus, protéger la saisie et la mémoire des données de paiement sensibles, refuser de stocker localement des informations de paiement sensibles, masquer les mots de passe, se déconnecter après une période d'inactivité, appliquer le principe du moindre privilège et effacer les données non essentielles à la fermeture. L'application doit aussi détecter son environnement d'exécution, notamment les droits d'administrateur non autorisés et les émulateurs ou machines virtuelles, le remonter au backend et avertir l'utilisateur ou refuser la transaction si l'environnement est risqué.

   Source :JR/T 0068-2020, 6.2.1 ; JR/T 0092-2019, 5.3.3 et 5.3.4 (texte chinois)

   Ce que cela implique pour votre application mobile

   Chacun de ces comportements peut être testé sur la version publiée, pas seulement relu dans le code source.

   Comment Ostorlab vous aide

   Mobile Shielding Scan exécute l'application dans des environnements rootés et instrumentés, tente de contourner la détection du root, des émulateurs et de l'altération ainsi que le TLS pinning, et montre ce que fait l'application quand une protection cède. Mobile SAST couvre le code et les SDK.

   Ce qui reste de votre ressort

   Le choix et la configuration de votre produit de shielding, le processus de signature des versions et la politique de risque pour les appareils compromis.

5. 05

   JR/T 0171-2020, 6.1 et 7.4.2 (texte chinois)

   Protéger les informations financières personnelles par catégorie

   Ce que dit le texte

   La spécification classe les informations financières personnelles en C3, C2 et C1 selon le préjudice qu'une consultation ou une modification non autorisée causerait. La catégorie C3 couvre les informations d'authentification de l'utilisateur, dont les données de piste de carte bancaire, les cryptogrammes de carte, les mots de passe de carte et de transaction, et les données biométriques utilisées pour l'authentification. Les informations C3 doivent être chiffrées au repos, et les informations C2 et C3 doivent utiliser des canaux chiffrés ou un chiffrement des données lorsqu'elles transitent sur des réseaux publics. Les applications clientes et les appareils personnels ne doivent pas stocker d'informations de paiement sensibles ni d'échantillons et gabarits biométriques, et ne peuvent conserver que les éléments de base nécessaires à la transaction en cours, effacés juste après. Les informations financières personnelles affichées doivent être masquées, et les environnements de développement et de test doivent être isolés de la production et ne pas utiliser de vraies informations financières personnelles. Les systèmes qui collectent, stockent, transmettent ou utilisent des informations financières personnelles doivent faire l'objet d'un contrôle ou d'une évaluation de sécurité au moins une fois par an, incluant évaluation de sécurité, analyse de vulnérabilités et tests d'intrusion, avec une nouvelle évaluation en cas de modification majeure ou de menace nouvelle à haut risque.

   Source :JR/T 0171-2020, 6.1 et 7.4.2 (texte chinois)

   Ce que cela implique pour votre application mobile

   Le paquet de l'application, ses caches, ses journaux, ses captures d'écran et le processus de test sont tous concernés, et l'évaluation annuelle attend de vrais tests, pas une liste de contrôle.

   Comment Ostorlab vous aide

   Ostorlab recherche les données de paiement, les jetons et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, contrôle les protections de transport, et note et suit chaque constat. Chaque scan est daté, les preuves pour l'évaluation annuelle s'accumulent donc version après version.

   Ce qui reste de votre ressort

   La catégorisation de vos données, la conception du chiffrement et l'évaluation d'impact exigée pour le partage, le transfert ou le traitement confié à des tiers.

6. 06

   JR/T 0068-2020, 6.2.3 et 6.4.2 ; JR/T 0092-2019, 5.1.1 et 5.5.6.3 (texte chinois)

   Vérifier les transactions à risque et terminer proprement les sessions

   Ce que dit le texte

   Pour les transactions à risque, la norme sur la banque en ligne exige une combinaison d'au moins deux des trois familles de facteurs : un élément que le client connaît, un élément qu'il est seul à détenir comme un certificat authentifié, une signature électronique ou un mot de passe à usage unique, et un facteur biométrique. Les facteurs doivent être indépendants, et la perte ou la compromission de l'un ne doit pas compromettre l'autre. Les mots de passe à usage unique doivent avoir la validité la plus courte possible. Après au plus 10 échecs d'authentification consécutifs, l'accès à la connexion ou à la transaction doit être verrouillé rapidement, avec une procédure documentée de déverrouillage. Le changement du numéro de mobile enregistré, utilisé pour les avis de transaction et les codes à usage unique, exige un passage en agence ou une authentification à deux facteurs sur le numéro d'origine. La communication entre client et serveur utilise une authentification mutuelle par clés ou certificats, et le client valide le certificat du serveur. Les programmes clients se déconnectent automatiquement après inactivité, et une déconnexion normale demande au serveur de terminer la session.

   Source :JR/T 0068-2020, 6.2.3 et 6.4.2 ; JR/T 0092-2019, 5.1.1 et 5.5.6.3 (texte chinois)

   Ce que cela implique pour votre application mobile

   L'indépendance des facteurs, la durée de vie des codes à usage unique, les seuils de verrouillage et l'invalidation de session côté serveur se testent tous avec vos propres comptes de test.

   Comment Ostorlab vous aide

   Les tests authentifiés complètent les codes à usage unique SMS, e-mail ou TOTP avec vos comptes de test, testent l'application de la MFA, les parcours d'authentification renforcée et le verrouillage, et contrôlent le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions via les appels API sous-jacents.

   Ce qui reste de votre ressort

   Le choix des facteurs et la conception des canaux, la procédure de déverrouillage et les canaux de notification des clients.

7. 07

   Ordonnance PBOC n° 3 [2025], articles 35 et 36 ; NFRA 金规〔2024〕24号, articles 48 et 53 (texte chinois)

   Tester les API avant chaque mise en production

   Ce que dit le texte

   Le PBOC exige un inventaire dynamique des passerelles et interfaces de programmation qui fournissent les données d'activité, et des tests de sécurité avant la mise en production d'une modification de passerelle ou d'API, avec remédiation immédiate de tout risque détecté. Les éléments à haute sensibilité doivent en principe être chiffrés lorsqu'ils sont transmis à d'autres responsables de traitement, d'autres centres de données ou sur internet, et les lignes dédiées ou VPN sont à privilégier. La NFRA exige que les échanges de données avec l'extérieur passent par une plateforme externe ou des API gérées de façon centralisée, conçues, développées, exploitées et opérées sous gestion de sécurité centralisée, selon les principes du besoin d'en connaître et du moindre privilège. Les systèmes doivent passer des tests de sécurité avant leur mise en service, et les environnements de test doivent être séparés de la production, sans données sensibles non masquées.

   Source :Ordonnance PBOC n° 3 [2025], articles 35 et 36 ; NFRA 金规〔2024〕24号, articles 48 et 53 (texte chinois)

   Ce que cela implique pour votre application mobile

   Chaque version qui touche une API est une modification à tester avant la production, et l'inventaire des API fait partie des preuves.

   Comment Ostorlab vous aide

   Ostorlab intercepte le trafic de l'application même avec TLS pinning et teste les API contre les autorisations défaillantes (BOLA, BFLA, IDOR), le mauvais usage des jetons et des sessions, et les abus comme l'énumération, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui pour chaque constat.

   Ce qui reste de votre ressort

   L'inventaire des API, l'architecture des passerelles, les choix de chiffrement réseau et la surveillance en production.

8. 08

   Ordonnance PBOC n° 3 [2025], articles 16, 17, 20 et 33 ; NFRA 金规〔2024〕24号, articles 43, 45 et 46 (texte chinois)

   Garder les données sensibles hors des appareils et du texte en clair

   Ce que dit le texte

   Les éléments de données à haute sensibilité ne doivent en principe pas être stockés sur les terminaux et supports amovibles, et lorsque le besoin métier l'exige, ces cas sont listés et encadrés de façon centralisée. Les données servant à la vérification d'identité devraient en principe être vérifiées plutôt qu'exportées, et les éléments à haute sensibilité devraient être masqués à l'affichage. Ils ne doivent en principe pas circuler par e-mail, messagerie instantanée, stockage de fichiers en ligne ou support amovible. La NFRA est précise sur les données d'authentification : les données d'authentification d'identité personnelle ne doivent pas être stockées, transmises ou affichées en clair, et les données sensibles et de niveau supérieur doivent être supprimées ou détruites de façon irrécupérable à la fin de leur durée de conservation, y compris sur les terminaux et supports. Les journaux d'exploitation des données essentielles sont conservés au moins trois ans, ceux des données importantes et sensibles au moins un an, et les accès sont audités au moins tous les six mois.

   Source :Ordonnance PBOC n° 3 [2025], articles 16, 17, 20 et 33 ; NFRA 金规〔2024〕24号, articles 43, 45 et 46 (texte chinois)

   Ce que cela implique pour votre application mobile

   Les données d'identité en clair sont une violation explicite, pas une préférence de durcissement, et c'est l'une des choses les plus faciles à prouver par un test mobile.

   Comment Ostorlab vous aide

   Ostorlab trouve les données d'identité et les identifiants dans le stockage, les caches, les journaux, les captures d'écran et le paquet de l'application, vérifie quels secrets fonctionnent et montre comment l'application et ses SDK échangent des données avec les backends sur le réseau.

   Ce qui reste de votre ressort

   La classification des données, les politiques de gestion des appareils et le processus de suppression ou de destruction.

9. 09

   GB/T 22239-2019 ; ordonnance PBOC n° 3 [2025], article 32 ; NFRA 金规〔2024〕24号, article 41 (texte chinois)

   Répondre aux obligations de protection par niveaux

   Ce que dit le texte

   La protection par niveaux de la cybersécurité est le régime de base des systèmes d'information en Chine. La norme GB/T 22239-2019 fixe les exigences générales de sécurité pour les niveaux 1 à 4 et les exigences étendues pour le cloud, l'internet mobile, l'internet des objets et les systèmes de contrôle industriel. Le PBOC exige que les systèmes stockant des données importantes atteignent le niveau 3 et ceux stockant des données essentielles le niveau 4 ou la protection des infrastructures d'information critiques. La NFRA exige que les banques intègrent les données à la protection par niveaux, divisent des domaines logiques de sécurité selon le niveau des données et protègent les salles et réseaux qui détiennent ou transmettent des données sensibles et supérieures. La norme JR/T 0068 oriente les systèmes de banque en ligne vers le guide sectoriel de mise en œuvre JR/T 0071, y compris l'extension internet mobile.

   Source :GB/T 22239-2019 ; ordonnance PBOC n° 3 [2025], article 32 ; NFRA 金规〔2024〕24号, article 41 (texte chinois)

   Ce que cela implique pour votre application mobile

   Le niveau du système derrière l'application fixe le socle de protection, et l'application mobile fait partie de son périmètre.

   Comment Ostorlab vous aide

   Ostorlab teste les contrôles de l'application et de ses API et fournit des constats datés et des retests pour les éléments techniques de l'évaluation de protection par niveaux, afin que les problèmes connus de l'application ne surprennent pas l'évaluation formelle.

   Ce qui reste de votre ressort

   Le classement et l'enregistrement des systèmes, l'évaluation formelle MLPS auprès d'un organisme agréé, et les contrôles physiques et réseau.

10. 10

    Mesures NFRA sur l'externalisation informatique 银保监办发〔2021〕141号, articles 5, 11, 17, 21, 32, 34 à 36 et 38 ; mesures NFRA sur le risque opérationnel, ordonnance n° 5 de 2023, articles 29 à 31 (texte chinois)

    Gérer l'externalisation et le risque opérationnel

    Ce que dit le texte

    Les mesures de la NFRA sur l'externalisation informatique indiquent que l'institution ne peut pas externaliser la responsabilité de gestion informatique ni la responsabilité de cybersécurité. La gestion de la stratégie informatique, la gestion du risque informatique, l'audit interne informatique et les autres fonctions de compétitivité essentielle ne peuvent pas être externalisés. L'externalisation importante exige une due diligence avant le contrat, des clauses couvrant la conformité, la continuité de service, les droits d'audit, la sécurité et la confidentialité et le signalement des incidents, ainsi que l'analyse de sécurité des livrables de développement, code source compris. Les mesures de sécurité prévoient un accès des prestataires selon le besoin d'en connaître et le moindre privilège, un contrôle strict de la maintenance à distance, une surveillance continue des fuites de données sensibles et des évaluations régulières de sécurité de l'externalisation. Les institutions doivent contrôler sur site l'externalisation importante hors site au moins tous les trois ans, réaliser au moins une fois par an une évaluation complète du risque d'externalisation et auditer l'externalisation importante au moins tous les trois ans. Les événements majeurs, dont les fuites de données personnelles de clients, doivent être signalés, et à défaut d'un autre délai, dans les 24 heures. Les mesures sur le risque opérationnel exigent des dispositifs pour la cybersécurité, la sécurité des données et le risque d'externalisation, reliés à la continuité d'activité.

    Source :Mesures NFRA sur l'externalisation informatique 银保监办发〔2021〕141号, articles 5, 11, 17, 21, 32, 34 à 36 et 38 ; mesures NFRA sur le risque opérationnel, ordonnance n° 5 de 2023, articles 29 à 31 (texte chinois)

    Ce que cela implique pour votre application mobile

    Chaque SDK, prestataire de test et service cloud dont dépend votre application entre dans ce cadre, et les preuves de test sont le moyen de surveiller l'obligation de sécurité.

    Comment Ostorlab vous aide

    Ostorlab teste l'application et les composants qu'elle contient, recense les SDK et bibliothèques natives de chaque version avec leurs versions, et les rapproche des vulnérabilités connues en suivant leur résolution version après version, pour que les composants tiers aient leurs propres preuves.

    Ce qui reste de votre ressort

    La due diligence, les contrats, le contrôle des accès des prestataires, les contrôles sur site, les évaluations annuelles et le signalement des incidents.

Synthèse de textes publics du PBOC, de la NFRA, du MIIT, de la NIFA et de l'APN, vérifiés le 27 septembre 2026. Les textes publiés uniquement en chinois sont résumés et signalés (texte chinois). Cette page ne constitue pas un avis juridique.