SFC Colombie : évaluez votre application bancaire mobile deux fois par an et à chaque version.

1. 01

   Circular Básica Jurídica, partie I, titre IV, chapitre V, numéro 3 (chapitre ajouté par la Circular Externa 007 de 2018 ; texte espagnol)

   Gouverner le risque de cybersécurité et rendre compte au conseil

   Ce que dit le texte

   Les entités surveillées doivent disposer de politiques, de procédures et de ressources techniques et humaines pour gérer le risque de cybersécurité. La politique doit être approuvée par le conseil, et une unité de sécurité de l'information et de cybersécurité doit rendre compte au conseil et à la direction générale au moins tous les six mois de la confidentialité, de l'intégrité et de la disponibilité, des cybermenaces, de l'efficacité du programme et des incidents. Les budgets de sécurité doivent être gérés séparément de ceux des opérations et de la technologie. Dans la phase de prévention, les entités doivent gérer les contrôles d'accès et les identités, prévenir les fuites de données, mesurer les cyberrisques émergents et envisager un centre d'opérations de sécurité (SOC).

   Source :Circular Básica Jurídica, partie I, titre IV, chapitre V, numéro 3 (chapitre ajouté par la Circular Externa 007 de 2018 ; texte espagnol)

   Ce que cela implique pour votre application mobile

   Une application de banque mobile est l'un des services que votre unité de sécurité doit surveiller, et le rapport au conseil a besoin de preuves à jour sur l'application et ses API, pas seulement sur les serveurs.

   Comment Ostorlab vous aide

   Ostorlab fournit des résultats continus, version par version, pour l'application et ses API, classés par gravité et suivis jusqu'à leur clôture, afin que les chiffres que votre unité présente s'appuient sur des preuves de scan.

   Ce qui reste de votre ressort

   La politique, l'unité de sécurité, le reporting au conseil, les décisions budgétaires et le choix de contracter ou non un SOC.

2. 02

   Circular Básica Jurídica, partie I, titre IV, chapitre V, numéro 3.8 (texte espagnol)

   Intégrer la sécurité au cycle de vie logiciel des applications et services web

   Ce que dit le texte

   Le chapitre sur la cybersécurité exige que les entités prennent en compte la sécurité de l'information tout au long du cycle de développement logiciel, y compris les services web et les applications qui traitent des informations confidentielles de l'entité ou des consommateurs financiers, depuis l'expression initiale des besoins jusqu'aux tests de sécurité et à la production.

   Source :Circular Básica Jurídica, partie I, titre IV, chapitre V, numéro 3.8 (texte espagnol)

   Ce que cela implique pour votre application mobile

   L'application et ses backends sont explicitement cités. Les tests de sécurité doivent faire partie du cycle de vie, et non d'un exercice ponctuel avant un audit.

   Comment Ostorlab vous aide

   Mobile SAST analyse l'APK, l'AAB ou l'IPA sans besoin du code source, et le pentest par agents IA teste l'application en cours d'exécution et ses API ; les deux peuvent s'exécuter dans la CI/CD à chaque build.

   Ce qui reste de votre ressort

   Les exigences de sécurité, les normes de développement sécurisé, les revues de code et l'approbation des mises en production.

3. 03

   Circular Básica Jurídica, partie I, titre IV, chapitre V, numéros 4.1.4 et 4.2.2 (texte espagnol)

   Gérer les vulnérabilités des systèmes exposés à internet

   Ce que dit le texte

   Les entités doivent identifier et mesurer les cyberrisques émergents et mettre en place des contrôles pour les atténuer, et elles doivent gérer les vulnérabilités des plateformes qui soutiennent des actifs d'information critiques et sont exposées dans le cyberespace. Les phases de prévention, de protection et de détection comprennent la gestion des contrôles d'accès et des identités, la prévention des fuites de données, la surveillance continue et des outils tels qu'un SIEM pour corréler les événements.

   Source :Circular Básica Jurídica, partie I, titre IV, chapitre V, numéros 4.1.4 et 4.2.2 (texte espagnol)

   Ce que cela implique pour votre application mobile

   Le backend mobile, et l'application elle-même en tant que composant que vous distribuez, sont des plateformes exposées. Chaque vulnérabilité a besoin d'un responsable, d'une gravité et d'un délai de correction, version après version.

   Comment Ostorlab vous aide

   SCA identifie par empreinte les bibliothèques compilées statiquement dans l'application et les associe aux vulnérabilités connues ; les résultats sont classés et suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, puis retestés après correction.

   Ce qui reste de votre ressort

   L'application des correctifs sur les serveurs et l'infrastructure, le SIEM, la surveillance et l'acceptation ou le refus du risque résiduel.

4. 04

   Circular Básica Jurídica, partie I, titre II, chapitre I, numéros 2.3.4.9.2 et 2.3.4.11.6 (texte espagnol)

   Tester le canal internet au moins deux fois par an

   Ce que dit le texte

   Les entités qui proposent des opérations par internet doivent réaliser des tests de vulnérabilité et d'intrusion sur les équipements, dispositifs et moyens de communication utilisés pour les opérations monétaires au moins deux fois par an, et un test supplémentaire à chaque changement de la plateforme affectant la sécurité du canal. Les sessions ouvertes depuis un appareil mobile et utilisant internet doivent respecter les mêmes exigences, et les services fournis via un navigateur mobile sont traités comme de la banque en ligne.

   Source :Circular Básica Jurídica, partie I, titre II, chapitre I, numéros 2.3.4.9.2 et 2.3.4.11.6 (texte espagnol)

   Ce que cela implique pour votre application mobile

   Deux tests par an est un minimum, pas un maximum : chaque version modifie l'application, et les changements de plateforme déclenchent un test supplémentaire. Les versions publiées sur les stores font partie du canal exposé à internet.

   Comment Ostorlab vous aide

   Ostorlab lance des scans automatisés à chaque build depuis votre pipeline CI/CD et surveille les versions publiées sur les stores sans déclenchement manuel, afin que les résultats sur l'application et les API arrivent entre les tests planifiés. Il ne remplace pas un test d'intrusion manuel lorsqu'il est requis.

   Ce qui reste de votre ressort

   Le cadrage et la commande du test semestriel, l'analyse des changements qui décide quand un test supplémentaire est nécessaire, et le rapport au conseil.

5. 05

   Circular Básica Jurídica, partie I, titre II, chapitre I, numéros 2.3.4.11.1, 2.3.4.9.8 et 1.2.2.1.2.16 (texte espagnol)

   Exiger deux facteurs pour chaque opération de banque mobile

   Ce que dit le texte

   La banque mobile est le canal dans lequel le téléphone sert à réaliser des opérations, que la ligne soit associée au service ou qu'une application soit utilisée. Les entités doivent disposer de mécanismes d'authentification à deux facteurs pour les opérations monétaires et non monétaires, et les opérations par internet doivent offrir aux clients des mécanismes d'authentification forts. Pour les opérations réalisées depuis la banque mobile, le mécanisme d'authentification fort doit se produire à l'origine de la transaction.

   Source :Circular Básica Jurídica, partie I, titre II, chapitre I, numéros 2.3.4.11.1, 2.3.4.9.8 et 1.2.2.1.2.16 (texte espagnol)

   Ce que cela implique pour votre application mobile

   Le second facteur doit être imposé par le serveur pour les opérations monétaires et non monétaires, y compris les consultations de solde et les modifications de profil, pas seulement à la connexion.

   Comment Ostorlab vous aide

   Les tests authentifiés complètent la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test, et vérifient que les appels d'API derrière chaque opération imposent le second facteur.

   Ce qui reste de votre ressort

   Le choix et le déploiement des méthodes d'authentification, et le processus de support client lorsque le second facteur échoue.

6. 06

   Circular Básica Jurídica, partie I, titre II, chapitre I, numéros 2.3.4.11.2, 2.3.4.11.4 et 2.3.3.1.6 ; partie I, titre IV, chapitre V, numéro 3.4 (texte espagnol)

   Chiffrer de bout en bout les données confidentielles des opérations

   Ce que dit le texte

   Pour les opérations monétaires individuelles, ou celles qui dépassent au cumul mensuel 2 salaires minimaux légaux par client, les entités doivent utiliser un chiffrement fort de bout en bout pour envoyer et recevoir les données confidentielles de l'opération, telles que les mots de passe, les numéros de compte et les numéros de carte ; ces données ne doivent être connues ni des fournisseurs de réseaux de télécommunications ni d'aucune autre partie que l'entité financière. En dessous de ce seuil, les entités doivent adopter des mesures pour atténuer le risque, en tenant compte de la sécurité des endroits où l'information n'est pas chiffrée, et la SFC peut suspendre le canal si elle constate des défaillances affectant la sécurité de l'information. Les informations confidentielles doivent aussi être protégées au repos et en transit, et les clés d'accès protégées : les clés partagées, génériques ou de groupe sont interdites.

   Source :Circular Básica Jurídica, partie I, titre II, chapitre I, numéros 2.3.4.11.2, 2.3.4.11.4 et 2.3.3.1.6 ; partie I, titre IV, chapitre V, numéro 3.4 (texte espagnol)

   Ce que cela implique pour votre application mobile

   Le seuil figure dans la réglementation : au-dessus de 2 SMMLV, le chiffrement de bout en bout est exigé ; en dessous, l'application a toujours besoin de mesures d'atténuation. Les clés et jetons ne doivent pas être partagés entre utilisateurs ni rester en clair.

   Comment Ostorlab vous aide

   Ostorlab inspecte le stockage local, les caches, les journaux et les captures d'écran à la recherche de données confidentielles en clair, détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels, et intercepte le trafic même avec TLS pinning pour contrôler les protections du transport.

   Ce qui reste de votre ressort

   Le choix du schéma de chiffrement et de la gestion des clés, les clauses contractuelles avec les opérateurs télécoms et la décision de risque pour les opérations de faible montant.

7. 07

   Circular Básica Jurídica, partie I, titre IV, chapitre V, numéros 3.9 et 3.10 ; partie I, titre I, chapitre IX, numéro 2 (texte espagnol)

   Encadrer les tiers critiques et les composants que vous livrez

   Ce que dit le texte

   Les contrats avec les tiers critiques doivent inclure les mesures et obligations nécessaires pour adopter et respecter les politiques de sécurité de l'information et de cybersécurité, et les entités doivent vérifier périodiquement que ces obligations sont remplies. Pour la finance ouverte, la CBJ énumère ce que doivent avoir les tiers receveurs de données : inscription au registre national des bases de données ou politiques de données personnelles, gestion des risques de sécurité et de vie privée selon des référentiels tels qu'ISO 27001, le NIST Cybersecurity Framework ou OWASP ASVS, chiffrement au moins équivalent à AES ou RSA, systèmes de surveillance, gestion des vulnérabilités, attestation PCI-DSS lorsque des données de carte sont traitées, et notification rapide des événements de sécurité. Les entités doivent vérifier ces exigences périodiquement et conserver les preuves pour la SFC.

   Source :Circular Básica Jurídica, partie I, titre IV, chapitre V, numéros 3.9 et 3.10 ; partie I, titre I, chapitre IX, numéro 2 (texte espagnol)

   Ce que cela implique pour votre application mobile

   Les SDK tiers intégrés à l'application et les backends qu'ils appellent font partie de la chaîne d'approvisionnement, et en finance ouverte chaque receveur de données est un tiers à évaluer et à surveiller.

   Comment Ostorlab vous aide

   Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, et montre ce que l'application et ses SDK échangent avec les backends sur le réseau.

   Ce qui reste de votre ressort

   Les vérifications préalables, les contrats, le registre des receveurs, les attestations PCI-DSS et le dossier de vérification périodique.

8. 08

   Circular Básica Jurídica, partie I, titre I, chapitre IX, numéros 3, 4 et 5 ; Decreto 368 de 2026, 7 avril 2026 (texte espagnol)

   Respecter les normes d'API de la finance ouverte

   Ce que dit le texte

   En finance ouverte, les entités doivent mettre en œuvre des protocoles d'échange automatique d'informations via des API REST en JSON, l'ISO 20022 pour les champs de données financières, les profils de sécurité FAPI 2.0, l'autorisation OAuth 2.0 (client credentials, authorization code, PKCE ou refresh token), des jetons d'accès en JWT signés avec des algorithmes tels que PS256 ou supérieurs et la méthode d'authentification private_key_jwt, et TLS avec authentification mutuelle à l'aide des suites de chiffrement spécifiées. Les systèmes liés à la finance ouverte doivent se trouver dans un réseau interne logiquement séparé, les référentiels ne doivent pas être exposés publiquement, et les journaux d'audit de chaque demande de données doivent être conservés cinq ans, masqués ou chiffrés selon la criticité. Le consentement doit pouvoir être accordé, mis à jour et révoqué par le client avec une authentification forte. Le Decreto 368 de 2026 a rendu le système obligatoire et demande à la SFC de publier un calendrier pour les normes communes.

   Source :Circular Básica Jurídica, partie I, titre I, chapitre IX, numéros 3, 4 et 5 ; Decreto 368 de 2026, 7 avril 2026 (texte espagnol)

   Ce que cela implique pour votre application mobile

   Si votre banque partage ou consomme des données de consommateurs, la couche d'API qui les transporte a ses propres exigences d'authentification, d'autorisation et de transport, et le consentement du client doit pouvoir être appliqué depuis l'application.

   Comment Ostorlab vous aide

   Ostorlab teste les API derrière la connexion à 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 et le rejeu, avec les requêtes et réponses à l'appui. Il ne met pas en œuvre FAPI, OAuth ni les certificats : il teste votre implémentation.

   Ce qui reste de votre ressort

   La mise en œuvre de FAPI 2.0, d'OAuth 2.0 et du TLS mutuel, l'émission des certificats, l'enregistrement des participants, les écrans de consentement et le journal d'audit de cinq ans.

9. 09

   Circular Básica Jurídica, partie I, titre IV, chapitre V, numéros 4.3 et 5 ; Circular Externa 033 de 2020, 17 novembre 2020 (texte espagnol)

   Déclarer les incidents avec la TUIC et le TLP

   Ce que dit le texte

   Les incidents significatifs affectant la confidentialité, l'intégrité ou la disponibilité de l'information doivent être déclarés à la SFC à l'aide de la taxonomie unique des incidents cybernétiques (TUIC), et aux autorités du modèle national de gestion des incidents cybernétiques. Toutes les communications, déclarations d'incidents, alertes précoces et bulletins liés à la sécurité de l'information et à la cybersécurité doivent être étiquetés avec le Traffic Light Protocol (TLP). Les entités doivent aussi établir des procédures de réponse aux incidents, notamment la déconnexion d'équipements, le changement de mots de passe, le blocage d'adresses IP, la restauration des systèmes et la préservation des preuves numériques.

   Source :Circular Básica Jurídica, partie I, titre IV, chapitre V, numéros 4.3 et 5 ; Circular Externa 033 de 2020, 17 novembre 2020 (texte espagnol)

   Ce que cela implique pour votre application mobile

   L'obligation de déclaration reste à la charge de la banque, selon une taxonomie et un protocole d'étiquetage définis, et la réponse aux incidents a besoin de preuves sur ce qui s'est passé dans l'application et les API.

   Comment Ostorlab vous aide

   Ostorlab ne surveille pas et ne déclare pas les incidents. Ses résultats, exploits rejouables et historiques de scan aident votre équipe à reconstituer ce qui s'est passé et à montrer l'état de l'application avant et après l'incident.

   Ce qui reste de votre ressort

   Le CSIRT, la surveillance SOC, les déclarations TUIC et TLP à la SFC et au ColCERT, et la préservation des preuves numériques.

Synthèse des textes publics de la SFC, vérifiés le 27 septembre 2026. Les éléments de la Circular Básica Jurídica sont résumés d'après le texte espagnol de la CBJ consolidée rééditée par la Circular Externa 006 de 2025. Cette page ne constitue pas un avis juridique.