Règles de la CBE : testez votre application bancaire mobile derrière la connexion et avant chaque version.

1. 01

   Règles de la CBE sur la banque en ligne, 3-8-1 à 3-8-3 ; règles de la CBE sur les services de paiement mobile, 3-11-1 à 3-11-4 (texte arabe)

   Évaluer les systèmes de banque en ligne et de paiement mobile selon un cycle fixe

   Ce que dit le texte

   Les règles de la CBE exigent une évaluation périodique de la sécurité de chaque système lié aux services de banque en ligne et de paiement mobile, au site principal comme au site de secours. Les activités minimales sont une évaluation de vulnérabilité au moins tous les trois mois, ou après un changement fondamental de l'environnement d'exploitation, et un test d'intrusion au moins une fois par an ou avant le lancement de tout nouveau service vital. L'évaluation de vulnérabilité doit couvrir les faiblesses courantes comme l'injection SQL, le contournement de l'authentification et le stockage non sécurisé ; les problèmes doivent être corrigés et la correction validée par un nouveau test. Le périmètre des activités d'évaluation doit inclure chaque version de l'application de paiement mobile mise à disposition des clients de la banque.

   Source :Règles de la CBE sur la banque en ligne, 3-8-1 à 3-8-3 ; règles de la CBE sur les services de paiement mobile, 3-11-1 à 3-11-4 (texte arabe)

   Ce que cela implique pour votre application mobile

   L'application est explicitement dans le périmètre, et pas seulement la version testée il y a un an : les règles visent chaque version mise à disposition des clients. Une évaluation trimestrielle et un test d'intrusion annuel constituent le minimum.

   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. Mobile SAST, Mobile DAST et SCA s'exécutent depuis votre pipeline CI/CD à chaque build, de sorte que chaque version publiée sur les stores est évaluée entre les campagnes formelles.

   Ce qui reste de votre ressort

   Le cadrage des évaluations, les tests des serveurs, des équipements réseau et du site de secours, et le reporting interne des résultats.

2. 02

   Règles de la CBE sur l'IPN, 7-3-3 et 7-3-4 ; règles de la CBE sur la banque en ligne, 4-5-1 (texte arabe)

   Envoyer à la CBE le rapport de test d'intrusion d'avant lancement

   Ce que dit le texte

   Un nouveau service ne doit pas être lancé avant que la CBE ait reçu le rapport de test d'intrusion sur l'environnement de production, montrant l'absence de faiblesses de risque élevé ou moyen. La banque doit obtenir l'accord de la CBE pour activer le service, et le rapport doit être soumis dans les trois mois suivant son émission. Le test d'intrusion doit être réalisé par un prestataire tiers indépendant sous accord de confidentialité, avec un rapport initial et un plan de remédiation signés, la validation des corrections sur les systèmes principaux et de secours, et un rapport final signé transmis à la CBE. Le même prestataire ne doit pas réaliser plus de deux tests d'intrusion consécutifs.

   Source :Règles de la CBE sur l'IPN, 7-3-3 et 7-3-4 ; règles de la CBE sur la banque en ligne, 4-5-1 (texte arabe)

   Ce que cela implique pour votre application mobile

   Il s'agit d'un point de passage avant mise en service, pas d'un rituel annuel. Les preuves ont un destinataire extérieur à votre institution : les résultats et les retests doivent être documentés et reproductibles.

   Comment Ostorlab vous aide

   Ostorlab produit des preuves par résultat que vous pouvez joindre au dossier : un exploit rejouable pour chaque résultat d'un agent IA et les requêtes et réponses à l'appui de chaque résultat d'API, avec les résultats de retest après correction.

   Ce qui reste de votre ressort

   Le choix et la contractualisation du prestataire indépendant, la signature des rapports, le test du site de secours et la soumission à la CBE.

3. 03

   Règles de la CBE sur les services de paiement mobile, 3-4 et 3-5 (texte arabe)

   Utiliser deux facteurs et réauthentifier les opérations à risque élevé

   Ce que dit le texte

   L'authentification des services de paiement mobile doit combiner deux des trois éléments suivants : ce que l'utilisateur sait, ce qu'il possède, comme une signature numérique ou des mots de passe à usage unique issus d'appareils ou d'applications de jetons de sécurité, ou ce qu'il est, comme les données biométriques. Les activités à risque élevé, notamment les ordres de paiement vers plusieurs bénéficiaires, les virements dépassant le plafond et la modification des coordonnées du client, doivent être réauthentifiées avec deux moyens, et les mots de passe à usage unique destinés aux particuliers ne doivent pas être délivrés automatiquement par SMS ou e-mail pour ces opérations. Les mots de passe à usage unique doivent comporter au moins six caractères et être valides au maximum 90 secondes ; les codes PIN doivent comporter au moins six chiffres, de préférence huit, sans valeur facile ; et le service doit bloquer l'accès après un nombre défini de tentatives échouées, sans révéler si le nom d'utilisateur ou le mot de passe était incorrect.

   Source :Règles de la CBE sur les services de paiement mobile, 3-4 et 3-5 (texte arabe)

   Ce que cela implique pour votre application mobile

   Les contrôles sont assez précis pour être testés : quels parcours exigent le second facteur, d'où vient le code à usage unique, combien de temps il vit et ce qui se passe après des tentatives échouées.

   Comment Ostorlab vous aide

   Les tests authentifiés saisissent les codes à usage unique reçus par SMS, e-mail ou TOTP avec vos comptes de test, testent l'application effective de la MFA et les parcours d'authentification renforcée pour les actions à risque élevé, et vérifient le verrouillage, l'énumération des utilisateurs et la réutilisation des codes à usage unique sur l'application et les API qui la sous-tendent.

   Ce qui reste de votre ressort

   Le choix des méthodes d'authentification, le calibrage biométrique et la classification des risques de chaque type de transaction.

4. 04

   Règles de la CBE sur les services de paiement mobile, 3-9 ; règles de la CBE sur l'IPN, 7-1-9 et 7-1-10

   Durcir l'application face aux appareils compromis et à la manipulation

   Ce que dit le texte

   Les règles de paiement mobile attendent de l'application qu'elle détecte les appareils à risque et résiste à la manipulation. Les mesures comprennent une détection suffisante que le téléphone n'est pas rooté ou jailbreaké, une protection contre l'ingénierie inverse comme l'obfuscation du code, une protection contre les captures d'écran automatiques effectuées par des logiciels espions sur le même appareil, l'interdiction pour l'application de stocker ou d'afficher les mots de passe déjà saisis, et la déconnexion automatique après une période d'inactivité. Lorsqu'une nouvelle version corrige un problème de sécurité, la banque doit exiger des clients qu'ils l'installent avant de pouvoir utiliser l'application. L'application doit être publiée depuis le compte officiel de la banque sur les stores, avec la bonne marque, et les banques doivent rechercher dans les stores les copies frauduleuses afin de limiter les logiciels malveillants qui visent les identifiants des clients.

   Source :Règles de la CBE sur les services de paiement mobile, 3-9 ; règles de la CBE sur l'IPN, 7-1-9 et 7-1-10

   Ce que cela implique pour votre application mobile

   Chacun de ces points est un comportement testable du build que vos clients installent, et non une déclaration de politique : l'application s'arrête-t-elle ou avertit-elle, la vérification peut-elle être contournée, et une ancienne version continue-t-elle de fonctionner ?

   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 du root et du jailbreak, l'anti-altération et l'anti-instrumentation, et montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner.

   Ce qui reste de votre ressort

   Le choix du produit de bouclier, la rédaction de la politique de mise à jour forcée et le processus de surveillance des fausses applications.

5. 05

   Règles de la CBE sur les services de paiement mobile, 3-5, 3-8 et 3-9-8 ; règles de la CBE sur l'IPN, 7-1-2, 7-1-6 et 7-1-8

   Chiffrer les données en transit et en garder peu sur l'appareil

   Ce que dit le texte

   Les données stockées dans la mémoire interne du téléphone doivent être limitées, et tout ce qui est conservé pour un besoin réel doit être protégé. Les données envoyées sur le réseau mobile doivent être chiffrées au niveau de la couche applicative, afin que les codes PIN et les mots de passe ne soient exposés à aucune étape intermédiaire entre l'application et le serveur hôte, où ils sont vérifiés. Les mots de passe ne doivent jamais être traités, envoyés ou stockés en clair, et le chiffrement doit utiliser des méthodes fortes ou une longueur de clé adéquate, les clés étant protégées tout au long de leur cycle de vie. Les règles de l'IPN ajoutent que le processus doit être chiffré depuis le canal de paiement jusqu'aux serveurs qui exécutent l'ordre de paiement, et qu'il convient d'utiliser un chiffrement internationalement reconnu.

   Source :Règles de la CBE sur les services de paiement mobile, 3-5, 3-8 et 3-9-8 ; règles de la CBE sur l'IPN, 7-1-2, 7-1-6 et 7-1-8

   Ce que cela implique pour votre application mobile

   Ce que l'application écrit dans les fichiers, les caches, les journaux et les captures d'écran, et la manière dont le trafic est protégé de bout en bout, sont des éléments qu'un testeur peut démontrer au lieu de les supposer.

   Comment Ostorlab vous aide

   Ostorlab recherche les jetons, mots de passe et données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, vérifie la protection du transport, et détecte les clés, jetons et identifiants laissés dans le package de l'application.

   Ce qui reste de votre ressort

   La classification des données, la gestion des clés, et le choix et la configuration de la pile de chiffrement.

6. 06

   Règles de la CBE sur la banque en ligne, 3-6-13 à 3-6-15 ; règles de la CBE sur les services de paiement mobile, 3-8-6, 3-9-2, 3-9-3 et 3-9-4 (texte arabe)

   Tester que l'authentification ne peut pas être contournée et appliquer les règles côté serveur

   Ce que dit le texte

   Les règles de banque en ligne exigent des banques qu'elles testent que l'authentification ne peut pas être contournée ou omise pour entrer dans le système, qu'elles définissent des procédures strictes d'identité et d'autorisation pour les systèmes et les bases de données, qu'elles conçoivent les processus système de manière sûre et qu'elles tiennent des pistes d'audit. Les règles de paiement mobile ajoutent une validation complète des entrées, y compris les données saisies par l'utilisateur et les requêtes de base de données que l'utilisateur peut tenter d'exécuter, effectuée sur les serveurs réseau, et exigent que les contrôles d'autorisation des utilisateurs et les règles de virement s'exécutent sur le serveur, dans les systèmes back-end de la banque, avant que l'opération ne s'achève. Les systèmes doivent fonctionner avec le minimum de privilèges nécessaires, ne doivent pas utiliser de mots de passe connus ou par défaut, et les messages d'erreur affichés aux clients ne doivent pas révéler de détails sur le système.

   Source :Règles de la CBE sur la banque en ligne, 3-6-13 à 3-6-15 ; règles de la CBE sur les services de paiement mobile, 3-8-6, 3-9-2, 3-9-3 et 3-9-4 (texte arabe)

   Ce que cela implique pour votre application mobile

   Une vérification côté client n'est pas un contrôle. L'application peut être modifiée, donc le serveur doit imposer l'authentification, l'autorisation et les règles métier d'un virement.

   Comment Ostorlab vous aide

   Ostorlab modifie l'application et rejoue les appels pour tester si l'authentification peut être contournée et si l'autorisation est appliquée côté serveur, en recherchant les contrôles d'autorisation défaillants au niveau des objets et des fonctions (BOLA, BFLA, IDOR), les paramètres altérés et les abus de logique métier.

   Ce qui reste de votre ressort

   Les normes de conception et de développement sécurisés, la revue de code, et votre plateforme de journalisation et de pistes d'audit.

7. 07

   Règles de la CBE sur les services de paiement mobile, 3-9-10 à 3-9-12 ; règles de la CBE sur l'IPN, 2-2-2-5, 2-2-2-8, 7-1-11 et 7-2-1

   Gérer les composants tiers et le canal des stores

   Ce que dit le texte

   Les règles de paiement mobile exigent des contrôles de sécurité adéquats lorsque des bibliothèques tierces ou des composants applicatifs prêts à l'emploi servent à construire l'application de paiement, et précisent que l'application ne doit exposer aucun service d'une application tierce exécutée sur le même appareil, ni d'aucune autre source externe, en dehors des systèmes back-end de la banque. Les règles de l'IPN exigent que la banque connaisse les tiers sur lesquels elle s'appuie et obtienne l'accord de la CBE avant d'externaliser des services. Les applications de l'Instant Payment Network doivent être soumises à de multiples tests avant leur mise en service, et les systèmes de la banque doivent être protégés par une infrastructure adaptée, incluant les systèmes de détection et de prévention des intrusions et les pare-feu.

   Source :Règles de la CBE sur les services de paiement mobile, 3-9-10 à 3-9-12 ; règles de la CBE sur l'IPN, 2-2-2-5, 2-2-2-8, 7-1-11 et 7-2-1

   Ce que cela implique pour votre application mobile

   Chaque SDK embarqué dans l'application est du code tiers avec un accès réseau, et un nouveau service ne part en production qu'après avoir été testé et, lorsque c'est requis, approuvé par la CBE.

   Comment Ostorlab vous aide

   SCA et SBOM recensent les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle, et les rapprochent des vulnérabilités connues, version après version. Ostorlab surveille les versions publiées sur les stores sans déclenchement manuel.

   Ce qui reste de votre ressort

   Les vérifications préalables sur les tiers, les contrats, les approbations de la CBE pour l'externalisation et l'inventaire des actifs.

8. 08

   Règles de la CBE sur les services de paiement mobile, 2-2, 2-3, 3-10 et 3-12 (texte arabe) ; règles de la CBE sur l'identité financière numérique, 23 août 2026 ; pages cybersécurité de la CBE

   Assurer la gouvernance cyber et signaler les incidents à la CBE

   Ce que dit le texte

   Le conseil et la direction générale sont responsables d'une stratégie de sécurité claire, d'une politique de sécurité de l'information approuvée, d'une classification des risques des services de paiement mobile et d'une revue continue. Les banques doivent surveiller les systèmes et l'infrastructure de manière proactive, 24 heures sur 24 et 7 jours sur 7, enregistrer les violations de sécurité, les intrusions et les faiblesses suspectées, protéger les pistes d'audit contre la manipulation et examiner les alertes de sécurité. Les procédures d'incident doivent couvrir le signalement et le traitement immédiats, le confinement, la collecte de preuves et l'escalade. Le responsable de la conformité doit informer la CBE des incidents, notamment l'hameçonnage et le vol d'identifiants, les accès non autorisés aux systèmes, les opérations destructrices sur les données, l'arrêt prolongé ou délibéré du service et la fraude interne. La CBE a diffusé le cadre de cybersécurité financière (EG-FinCSF) et anime EG-FinCIRT, l'équipe de réponse aux incidents du secteur, comme canal de signalement des incidents cyber. Pour les services de KYC électronique, les banques doivent revoir périodiquement les tests d'infrastructure et de cybersécurité, évaluer la maturité et la préparation cyber, réaliser une auto-évaluation de cybersécurité alignée sur le cadre de la CBE, la faire vérifier par une partie indépendante et envoyer les résultats à la CBE.

   Source :Règles de la CBE sur les services de paiement mobile, 2-2, 2-3, 3-10 et 3-12 (texte arabe) ; règles de la CBE sur l'identité financière numérique, 23 août 2026 ; pages cybersécurité de la CBE

   Ce que cela implique pour votre application mobile

   La gouvernance et la surveillance restent à la banque, mais l'application fait partie du patrimoine surveillé, et c'est là que les signaux de risque liés à l'appareil et les connexions suspectes deviennent visibles.

   Comment Ostorlab vous aide

   Ostorlab teste les contrôles de l'application et de ses API et fournit des preuves par résultat, qui alimentent le travail d'assurance et d'auto-évaluation. Il ne réalise pas la surveillance SOC, la réponse aux incidents ni les signalements à la CBE et à EG-FinCIRT.

   Ce qui reste de votre ressort

   Le programme de sécurité, la surveillance 24x7, la réponse aux incidents, les signalements à la CBE et à EG-FinCIRT, et l'auto-évaluation eKYC.

9. 09

   Loi n° 194 de 2020 sur la Banque centrale et le système bancaire, articles 140, 142, 197, 198 et 231 (texte arabe)

   Préserver la confidentialité des données clients au titre de la loi bancaire

   Ce que dit le texte

   La loi sur la Banque centrale et le système bancaire rend strictement confidentielles toutes les données des clients, y compris les comptes, les dépôts, les objets conservés en coffre et les transactions. Elles ne peuvent être divulguées sans le consentement écrit du client ou une décision judiciaire ou arbitrale, et l'obligation se poursuit après la fin de la relation bancaire et après le départ d'un employé de son poste. Les opérateurs et prestataires de systèmes de paiement doivent garantir une protection adéquate de leurs systèmes électroniques contre le piratage, les accès non autorisés, la manipulation des données et les atteintes à la confidentialité ou à la vie privée, et doivent notifier à la CBE tout incident affectant la continuité du service ou le fonctionnement du système. Les violations des articles sur la confidentialité sont punies d'une peine d'emprisonnement d'au moins un an et d'une amende, ou de l'une de ces peines.

   Source :Loi n° 194 de 2020 sur la Banque centrale et le système bancaire, articles 140, 142, 197, 198 et 231 (texte arabe)

   Ce que cela implique pour votre application mobile

   La confidentialité est une obligation légale assortie de sanctions pénales, et l'application mobile est l'un des endroits où les données clients sont les plus exposées.

   Comment Ostorlab vous aide

   Ostorlab détecte les données personnelles et les identifiants que l'application laisse sur l'appareil ou envoie en clair, et teste si les API derrière l'application permettent à un client d'atteindre les données d'un autre client.

   Ce qui reste de votre ressort

   L'interprétation juridique, les procédures de consentement et de divulgation, et la prévention des fuites de données.

10. 10

    Loi n° 151 de 2020 sur la protection des données personnelles, articles 4, 7, 8, 14, 15, 16, 17 et 38 ; règlement d'application, décret n° 816 de 2025 (texte arabe)

    Respecter la loi sur la protection des données personnelles et son règlement d'application

    Ce que dit le texte

    La loi sur la protection des données personnelles exige des responsables du traitement qu'ils obtiennent le consentement ou une autre base légale, vérifient que les données sont exactes et pertinentes, mettent en œuvre les mesures techniques et organisationnelles nécessaires pour les protéger, tiennent un registre des traitements et effacent les données lorsque la finalité prend fin. Les responsables et les sous-traitants doivent nommer et enregistrer un délégué à la protection des données, notifier au Centre de protection des données personnelles toute violation de données personnelles dans les 72 heures, et informer les personnes concernées dans les trois jours ouvrables. Le transfert de données personnelles à l'étranger est interdit sauf si le pays de destination offre un niveau de protection au moins équivalent à celui de la loi et si le transfert est autorisé ou agréé par le Centre. Le marketing électronique direct nécessite un consentement préalable et un mécanisme de retrait. Le règlement d'application, décret n° 816 de 2025, précise les catégories de licences et d'autorisations, les mesures de sécurité pendant le traitement et les procédures de notification des violations. Une période de grâce d'un an s'achève le 31 octobre 2026, après laquelle l'application pleine et entière et les sanctions prévues par la loi s'appliquent.

    Source :Loi n° 151 de 2020 sur la protection des données personnelles, articles 4, 7, 8, 14, 15, 16, 17 et 38 ; règlement d'application, décret n° 816 de 2025 (texte arabe)

    Ce que cela implique pour votre application mobile

    L'application collecte, stocke et transmet des données personnelles : les parcours de consentement, la minimisation, la conservation, le signalement des violations et le choix de la région d'hébergement font donc partie de sa conception.

    Comment Ostorlab vous aide

    Ostorlab montre quelles données personnelles quittent l'application, où elles sont stockées ou mises en cache sur l'appareil et comment elles circulent vers le backend, de sorte que les mesures techniques et la réponse aux violations peuvent être vérifiées plutôt que supposées.

    Ce qui reste de votre ressort

    Les licences et autorisations du Centre, l'enregistrement du délégué à la protection des données, les mentions de consentement, les approbations de transfert transfrontalier et la procédure de notification des violations.

Synthèse de textes publics de la CBE et de textes égyptiens, vérifiés le 27 septembre 2026. Les textes sur la banque en ligne, le paiement mobile et l'identité numérique sont en arabe et sont résumés ici ; les règles de l'IPN sont en anglais. Le cadre de cybersécurité financière est diffusé aux institutions et non publié comme document public autonome : il n'est décrit qu'à partir des informations publiques de la CBE. Cette page ne constitue pas un avis juridique.