Règles du BDDK et de la CBRT : testez votre application bancaire mobile avant et après chaque mise en production.

1. 01

   BSEBY, article 18(7) ; circulaire BSD.2012/1 du BDDK, périmètre et méthodologie (texte turc)

   Réalisez chaque année un test d'intrusion incluant les applications mobiles

   Ce que dit le texte

   Les banques doivent faire réaliser un test d'intrusion au moins une fois par an par des équipes qui ne participent ni à la conception, ni au développement, ni à la mise en œuvre, ni à l'exploitation des services offerts par les systèmes testés. La circulaire du BDDK sur les tests d'intrusion en fixe le cadre : tests de base puis tests détaillés, menés au minimum depuis Internet, le réseau interne de la banque et un réseau d'agence, et couvrant un périmètre minimal qui inclut les applications web et les applications mobiles. Les résultats sont notés selon les niveaux de gravité de la circulaire et présentés dans son format de constat, la hiérarchisation des actifs restant à la charge de la banque.

   Source :BSEBY, article 18(7) ; circulaire BSD.2012/1 du BDDK, périmètre et méthodologie (texte turc)

   Ce que cela implique pour votre application mobile

   Les applications mobiles figurent parmi les domaines de test nommés. L'application et les API qu'elle appelle relèvent de la partie exposée à Internet du test annuel, aux côtés des applications web et des systèmes ATM.

   Comment Ostorlab vous aide

   Le pentest par agents IA teste la version publiée en store et les API derrière la connexion, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA et une carte de couverture. Il ne remplace pas les volets réseau, réseau d'agence, ATM et ingénierie sociale de la circulaire.

   Ce qui reste de votre ressort

   La réalisation du test annuel complet, les volets réseau interne et réseau d'agence, la hiérarchisation des actifs et le rattachement des résultats à votre processus.

2. 02

   BSEBY, articles 22(4)-(5) et 24

   Testez les applications exposées à Internet avant leur mise en service et après chaque mise à jour

   Ce que dit le texte

   Les applications ouvertes à Internet, qu'elles soient développées par la banque ou acquises auprès de fournisseurs, doivent être scannées et contrôlées pour leurs vulnérabilités de sécurité avant leur installation, puis à nouveau après chaque mise à jour. Les exigences de sécurité, comme l'autorisation et les accès, la vérification d'identité, l'intégrité des données, la journalisation et la gestion des cas exceptionnels, sont définies dès le début du développement ou de l'acquisition, et les changements passent par la gestion des demandes, l'analyse de risque, les tests et l'approbation avant la production.

   Source :BSEBY, articles 22(4)-(5) et 24

   Ce que cela implique pour votre application mobile

   Chaque nouvelle version de l'application mobile est une mise à jour d'une application exposée à Internet. Un contrôle avant diffusion et un contrôle après diffusion sont le minimum, et les versions publiées entre-temps doivent être surveillées.

   Comment Ostorlab vous aide

   Mobile SAST analyse l'APK, l'AAB ou l'IPA sans code source ; Mobile DAST exécute l'application ; les deux s'intègrent à une chaîne CI/CD. Les versions publiées en store sont surveillées sans déclenchement manuel, pour ne pas manquer les mises à jour sorties entre deux sprints.

   Ce qui reste de votre ressort

   Les standards de codage sécurisé, la revue de code, l'approbation de mise en production et les clauses fournisseurs qui imposent les mêmes tests.

3. 03

   BSEBY, article 34(14)-(15) ; circulaire 2023/1 du BDDK, annexe, section 1 (texte turc)

   Durcissez l'application et détectez les appareils compromis

   Ce que dit le texte

   Les logiciels et applications mobiles proposés aux clients pour la banque électronique doivent provenir de manière vérifiable de la banque, ne pas contenir de code menaçant la sécurité des clients et recevoir les correctifs et mises à jour nécessaires pour fermer leurs vulnérabilités. Les données critiques utilisées par les applications bancaires sur téléphone doivent être inaccessibles aux autres applications et processus du même appareil, protégées en cas de perte ou de vol, et des contrôles adaptés à la technologie actuelle doivent réduire les risques liés à la capture d'un appareil, à la dégradation de sa fiabilité ou au contournement ou au remplacement de son système d'exploitation. La circulaire 2023/1 détaille ces contrôles : intégrité de l'application et du SDK, anti-keylogging, anti-injection, anti-débogage, anti-émulation, liaison à l'appareil, anti-malware et détection de jailbreak, remontés à un serveur de sécurité dédié par un canal sécurisé distinct.

   Source :BSEBY, article 34(14)-(15) ; circulaire 2023/1 du BDDK, annexe, section 1 (texte turc)

   Ce que cela implique pour votre application mobile

   C'est le terrain du root, du jailbreak et de la falsification. La détection n'est qu'un début : l'application doit agir sur ce qu'elle détecte, et le contrôle ne doit pas être trivial à désactiver.

   Comment Ostorlab vous aide

   Mobile Shielding Scan exécute l'application dans des environnements rootés, jailbreakés et instrumentés et tente de contourner chaque protection, puis montre si l'application bloque le parcours, refuse de démarrer ou continue de fonctionner, avec un score de durcissement et les preuves de contournement.

   Ce qui reste de votre ressort

   Le choix et la configuration du SDK de protection, la politique pour les appareils compromis et le serveur de sécurité.

4. 04

   BSEBY, articles 34(1), (6), (9) et 38(1)

   Imposez deux facteurs indépendants, vérifiés en ligne

   Ce que dit le texte

   Les services de banque électronique, y compris les transactions sans résultat financier comme l'affichage de données client, exigent un mécanisme d'authentification d'au moins deux facteurs appartenant à des classes différentes : ce que le client sait, ce qu'il possède ou une caractéristique biométrique. Les facteurs doivent être indépendants, et le facteur possédé doit être propre au client et non imitable. Un facteur connu du client doit être saisi par le client et vérifié en ligne par la banque, et non mémorisé par l'application ou le navigateur ni lié à des méthodes d'authentification locales. Au-delà d'un certain nombre d'échecs, l'accès de l'utilisateur doit être bloqué, et les mots de passe à usage unique doivent être assez longs pour résister aux tentatives, générés aléatoirement et valides seulement pour une durée limitée.

   Source :BSEBY, articles 34(1), (6), (9) et 38(1)

   Ce que cela implique pour votre application mobile

   Le MFA est appliqué par le serveur, pas dessiné à l'écran par l'application. Les seuils de blocage, la durée de vie des OTP et le comportement lorsque l'application saute une étape sont des comportements testables.

   Comment Ostorlab vous aide

   Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement de jeton, l'expiration de session et l'application du MFA, y compris les parcours d'authentification renforcée et les tentatives de contournement, avec vos comptes de test et les appels d'API correspondants.

   Ce qui reste de votre ressort

   Le choix des méthodes d'authentification, des seuils de blocage et de la durée de validité des OTP.

5. 05

   BSEBY, article 34(7)-(8)

   Gardez les codes à usage unique par SMS hors du canal applicatif

   Ce que dit le texte

   Pour les clients ayant installé et activé l'application de banque mobile, la banque ne peut pas envoyer de mot de passe à usage unique ni de code de vérification par SMS pour la connexion ou la vérification d'une transaction pendant une session, ni utiliser le SMS comme facteur d'authentification. Les codes SMS ne sont admis qu'à la première installation, à l'activation ou à la réactivation de l'application, ou lorsque l'application est devenue inutilisable. Si un client a changé de carte SIM ou porté son numéro chez un autre opérateur, la banque doit le détecter via une intégration avec les opérateurs mobiles, et un facteur reposant sur la carte SIM ne peut pas être utilisé pendant 90 jours après le changement, sauf confirmation explicite du client.

   Source :BSEBY, article 34(7)-(8)

   Ce que cela implique pour votre application mobile

   L'application a besoin d'un second canal qui n'est pas le SMS. Les tests doivent couvrir ce qui se passe si le SMS est utilisé malgré tout, et la manière dont les changements de SIM et les réactivations sont traités.

   Comment Ostorlab vous aide

   Ostorlab complète les codes SMS, e-mail ou TOTP avec vos comptes de test, vérifie si le serveur envoie ou accepte encore des codes SMS pour les clients ayant activé l'application, et teste les appels d'API derrière l'activation, les changements de numéro et l'authentification renforcée.

   Ce qui reste de votre ressort

   Les intégrations opérateurs, les parcours de confirmation des changements de SIM et la communication client.

6. 06

   BSEBY, articles 35 et 38(3) ; circulaire 2023/1 du BDDK, annexe, sections 1 et 2 (texte turc)

   Signez les transactions pour que le client approuve ce qui est affiché

   Ce que dit le texte

   Les transactions de banque électronique doivent permettre la non-répudiation et l'attribution des responsabilités. Un code de vérification à usage unique est généré et signé avec une clé privée attribuée au client ; le code ne doit révéler aucun facteur d'authentification, ne doit pas pouvoir être dérivé d'un code connu ni être imitable, et pour les transactions à résultat financier il doit être spécifique au montant et au bénéficiaire approuvés par le client, en devenant invalide si l'un ou l'autre change. La circulaire 2023/1 décrit la construction attendue : un SDK dédié et un serveur de sécurité de la banque, la clé du client créée et conservée dans le matériel cryptographique du téléphone (Secure Enclave, keystore adossé au matériel ou Strong Box), du TLS mutuel sur un canal distinct du trafic backend habituel de l'application, et des contrôles de sécurité avant chaque demande de signature.

   Source :BSEBY, articles 35 et 38(3) ; circulaire 2023/1 du BDDK, annexe, sections 1 et 2 (texte turc)

   Ce que cela implique pour votre application mobile

   Le principe what-you-see-is-what-you-sign relève du backend, mais il peut échouer dans l'application : une surcouche, du code injecté ou un écran manipulé peuvent modifier ce que le client croit approuver.

   Comment Ostorlab vous aide

   Ostorlab teste la manière dont l'application affiche et signe les transactions, y compris ce qui se passe si le montant ou le bénéficiaire change après l'affichage du code, si un code peut être rejoué ou dérivé, et les appels d'API autour du parcours de signature.

   Ce qui reste de votre ressort

   Le serveur de sécurité, le cycle de vie des clés, les modèles de transaction et les enregistrements de non-répudiation.

7. 07

   UKTY (règlement sur les méthodes d'identification à distance à utiliser par les banques), articles 4, 6, 7, 8, 10 et 11

   Encadrez l'onboarding à distance comme un processus contrôlé

   Ce que dit le texte

   L'identification à distance se fait lors d'un appel vidéo en temps réel et sans interruption entre un conseiller formé et la personne. Le document d'identité est vérifié par NFC lorsque c'est possible, ses éléments de sécurité, sa photographie et sa signature sont contrôlés en lumière blanche, et toute la session est enregistrée pour être auditable. Une détection de vivacité est utilisée et des mesures supplémentaires sont prises contre les visages synthétiques, le visage de la personne est comparé à la photographie du document, et le processus est arrêté en cas de doute. Seules les données biométriques, catégorie particulière de données personnelles, peuvent servir à l'identification, avec le consentement explicite de la personne enregistré électroniquement. Le processus est testé avant sa mise en service et réexaminé au moins deux fois par an, la responsabilité reste celle de la banque, et des mesures de sécurité supplémentaires s'appliquent aux clients ainsi acquis.

   Source :UKTY (règlement sur les méthodes d'identification à distance à utiliser par les banques), articles 4, 6, 7, 8, 10 et 11

   Ce que cela implique pour votre application mobile

   Le parcours d'onboarding est à haut risque : caméra, NFC, biométrie et backend en direct. C'est aussi le parcours que les attaquants essaient en premier, avec des visages falsifiés, des émulateurs et de l'interception.

   Comment Ostorlab vous aide

   Ostorlab teste les API d'onboarding et les contrôles de l'application : comportement sur appareil émulé ou rooté, possibilité de tromper la vivacité avec un visage enregistré ou synthétique, protection de la session et stockage des éléments d'identité côté client.

   Ce qui reste de votre ressort

   Le processus des conseillers, la plateforme vidéo, les décisions de vérification des documents, la conservation et les déclarations réglementaires.

8. 08

   Loi n° 6698 (KVKK), articles 4 et 12 ; KVKK, Recommandations pour la protection de la vie privée dans les applications mobiles, mars 2025 (texte turc)

   Respectez les obligations de sécurité du KVKK sur le téléphone

   Ce que dit le texte

   En vertu de la loi n° 6698 sur la protection des données personnelles, le responsable du traitement doit prendre toutes les mesures techniques et organisationnelles nécessaires pour empêcher le traitement illicite des données personnelles et tout accès illicite à celles-ci, et doit réaliser les audits nécessaires. Lorsque des données personnelles sont obtenues illicitement par des tiers, le responsable doit en informer la personne concernée et notifier le Conseil dans les meilleurs délais. Dans ses recommandations pour les applications mobiles, actualisées en 2025, le KVKK demande la protection dès la conception et par défaut, le chiffrement des données personnelles en transit et au repos, le hachage des mots de passe, une gestion régulière des correctifs et des mises à jour, des tests logiciels avant publication, une limitation des connexions échouées et le contrôle par l'utilisateur des autorisations, des notifications et des réglages de confidentialité.

   Source :Loi n° 6698 (KVKK), articles 4 et 12 ; KVKK, Recommandations pour la protection de la vie privée dans les applications mobiles, mars 2025 (texte turc)

   Ce que cela implique pour votre application mobile

   Les obligations du KVKK portent sur ce que l'application collecte et sur la manière dont c'est protégé. Les autorisations, les flux de données des SDK, le stockage local, les journaux et les captures d'écran sont les points testés.

   Comment Ostorlab vous aide

   Ostorlab inventorie les SDK présents dans le build, cartographie ce à quoi ils peuvent accéder et recherche les données personnelles et les jetons dans le stockage, les caches, les journaux et les captures d'écran. Il vérifie les protections du transport et indique ce qui est exposé et où.

   Ce qui reste de votre ressort

   La classification des données, les bases légales, les registres de consentement, les durées de conservation et la notification des violations.

9. 09

   BSEBY, article 16 ; Tebliğ de la CBRT sur les systèmes d'information des établissements de paiement et de monnaie électronique, article 12 (texte turc)

   Gérez les vulnérabilités avec des délais

   Ce que dit le texte

   Les banques doivent mettre en place un processus de gestion des vulnérabilités et des correctifs : suivre les informations sur les vulnérabilités, évaluer l'impact, définir les méthodes de correction et les délais, conserver les enregistrements et mettre en place des mesures compensatoires lorsqu'un correctif ne peut pas être appliqué. Des outils automatiques de scan rapportent les constats les plus critiques en priorité au responsable de la sécurité et au responsable du système concerné. Pour les établissements de paiement et de monnaie électronique, le Tebliğ de la CBRT est plus prescriptif : les serveurs et le réseau de communication sont scannés au moins six fois par an et avant leur première mise en service, et testés en intrusion au moins une fois par an par des personnes ou sociétés titulaires d'une certification nationale ou internationale de test d'intrusion, non impliquées dans la sécurité des systèmes testés. Les constats sont corrigés dès que possible dans le cadre d'un plan d'action approuvé par le conseil, et un rapport couvrant les violations, les résultats de tests et les vulnérabilités critiques est transmis à la CBRT au moins une fois par an.

   Source :BSEBY, article 16 ; Tebliğ de la CBRT sur les systèmes d'information des établissements de paiement et de monnaie électronique, article 12 (texte turc)

   Ce que cela implique pour votre application mobile

   Deux cultures de délais se rencontrent : les délais de correctifs de la banque au titre du BSEBY, et les six scans et le test annuel de la CBRT pour les établissements de paiement. Les deux exigent une boucle traçable de correction et de retest.

   Comment Ostorlab vous aide

   Les constats sont notés critique, élevé, moyen ou faible, regroupés en tickets dans la plateforme ou dans Jira et ServiceNow, associés au composant et à la version concernés, et retestés après la correction. L'historique reste disponible pour le plan d'action et le rapport annuel.

   Ce qui reste de votre ressort

   La mise à jour des serveurs et des équipements réseau, le plan approuvé par le conseil et les déclarations à la CBRT.

Synthèse des textes publics du BDDK, de la CBRT et du KVKK, vérifiés le 27 septembre 2026. Les articles du BSEBY sont cités d'après la traduction anglaise du BDDK sauf mention « texte turc » ; la circulaire 2023/1, la circulaire de 2012 sur les tests d'intrusion et le Tebliğ de la CBRT sont résumés d'après les textes turcs. Cette page ne constitue pas un avis juridique.