Règles de cybersécurité de la SBS : évaluez votre application bancaire mobile avant et après chaque version.
La résolution SBS n° 504-2021 a approuvé le Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, un système de gestion de la sécurité de l'information et de la cybersécurité pour les entités supervisées par la SBS. Il impose des tests périodiques, une authentification renforcée à deux facteurs indépendants pour les paiements et les virements, la surveillance des transactions et des mesures de sécurité spécifiques pour les API. La réglementation des cartes ajoute deux facteurs d'authentification pour les opérations par carte, et la loi 29733 et son règlement de 2024 fixent des mesures de sécurité pour les applications mobiles qui traitent des données personnelles. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Évalue l'application mobile et les API qu'elle appelle, sur le build que téléchargent vos clients
- Teste la connexion, les codes à usage unique et les vérifications d'authentification renforcée avec vos comptes de test, y compris les appels derrière les virements et les modifications de bénéficiaires
- Recense les SDK et bibliothèques natives de chaque version et les rapproche des vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les banques, les sociétés financières, les CMAC, les AFP et les autres entités supervisées par la SBS ; la réglementation des cartes s'applique aux émetteurs de cartes, et la loi 29733 à toute personne qui traite des données personnelles au Pérou
- Date clé
- Le règlement SGSI-C est en vigueur depuis le 1er juillet 2021, le sous-chapitre sur l'authentification s'appliquant depuis le 1er juillet 2022 ; les échéances du double facteur sur les cartes se sont étalées de 2025 à 2026
- Objet
- Tests périodiques, authentification renforcée des opérations numériques, sécurité des API et protection des données personnelles
- Texte de référence
- Resolución SBS N° 504-2021, Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad
Les textes de la SBS qui encadrent votre canal mobile
Le règlement de cybersécurité, les règles sur les cartes et le cadre de protection des données s'appliquent à la même application et à ses API. Les dates ci-dessous concernent les textes cités sur cette page.
- 1er juillet 2021
Règlement de cybersécurité
La résolution SBS n° 504-2021, datée du 19 février 2021, applique le Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad. Le sous-chapitre sur l'authentification des canaux numériques avait un délai de mise en conformité au 1er juillet 2022.
- Octobre et novembre 2023
Modifications sur l'authentification
Les résolutions SBS n° 3240-2023 du 3 octobre 2023 et n° 03797-2023 du 17 novembre 2023 ajustent les exemptions de l'authentification renforcée et les règles d'enrôlement et de code à usage unique pour les opérations numériques.
- 28 juin 2024
Opérations par carte, deux facteurs
La résolution SBS n° 2286-2024 modifie le règlement des cartes : deux facteurs d'authentification pour les opérations par carte présente et non présente, EMV 3DS et tokenisation pour les portefeuilles, et responsabilité de l'entreprise pour les opérations non reconnues traitées sans second facteur.
- 30 novembre 2024
Nouveau règlement sur les données personnelles
Le Decreto Supremo n° 016-2024-JUS approuve le nouveau règlement de la loi 29733, en vigueur 120 jours calendaires plus tard, en mars 2025. Il ajoute des mesures de sécurité pour les applications mobiles et les plateformes numériques, un document de sécurité, un officier de protection des données et une notification des violations sous 48 heures.
- 10 mars 2025
Résilience des canaux numériques
La résolution SBS n° 814-2025 modifie le Reglamento para la Gestión de la Continuidad del Negocio, approuvé par la résolution SBS n° 877-2020. Elle ajoute des délais de rétablissement pour les canaux mobile et internet, des tests annuels de continuité, un registre des interruptions et des délais de déclaration à la SBS, en vigueur par étapes à partir du 1er juin 2025 et du 1er janvier 2026.
- 19 septembre 2025
Règles de surveillance des cartes
La résolution SBS n° 3289-2025 réécrit l'article 17 du règlement des cartes : les systèmes de surveillance doivent être distincts du processus d'authentification, avec des procédures d'alerte, des schémas de fraude et des limites par canal.
- 1er juin 2026
Cartes de crédit anciennes, dernière échéance
La résolution SBS n° 771-2026 du 13 mars 2026 reporte au 1er juin 2026 le double facteur pour les cartes de crédit émises avant le 1er juillet 2025, après un premier report au 1er avril 2026 par la résolution SBS n° 2220-2025.
Les règles de la SBS, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe. Les textes sont en espagnol et sont résumés ici.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 13(b) et 21.1(a), (f) et (j) (texte espagnol)
Tester régulièrement le système de gestion et votre application
Ce que dit le texte
Maintenez des activités planifiées qui comprennent des évaluations, des revues et des tests périodiques du système de gestion de la sécurité de l'information et de la cybersécurité, par des services internes et externes, selon la complexité de l'entité et les menaces pesant sur ses actifs informationnels. Pour les API utilisées pour fournir des services, réalisez une analyse de risques, une analyse de vulnérabilités et des tests d'intrusion, et surveillez leurs événements de sécurité. Prenez les normes et référentiels internationaux comme référence.
Ce que cela implique pour votre application mobile
Le règlement attend des tests, pas seulement des politiques. Les tests doivent couvrir les systèmes derrière l'application, et les API que l'application utilise sont des systèmes qui exigent une analyse de vulnérabilités et des tests d'intrusion.
Comment Ostorlab vous aide
Un pentest par agents IA teste l'application et ses API derrière la connexion, sur la version que vous livrez, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA. Mobile SAST et Mobile DAST s'exécutent dans la CI/CD, et les résultats sont suivis sous forme de tickets avec retest après correction.
Ce qui reste de votre ressort
Fixer la fréquence et le périmètre des tests, choisir les prestataires externes, et tout test que votre institution mène au-delà de l'application et de ses API.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 12.5(b), (c), (d), (e) et (f) (texte espagnol)
Intégrer la sécurité et tester avant la mise en production
Ce que dit le texte
Intégrez des pratiques de sécurité de l'information dans la planification, le développement, la mise en œuvre, l'exploitation, le support et le retrait des applications et des systèmes. Gardez un contrôle strict des modifications des bibliothèques de code source, revoyez et testez les applications critiques lorsque la plateforme d'exploitation change, et réalisez des tests techniques, fonctionnels et de sécurité de l'information avant la mise en production. Mettez en œuvre et vérifiez des procédures de développement sécurisé.
Ce que cela implique pour votre application mobile
Chaque version de l'application modifie un système exposé aux clients. Les tests de sécurité avant la mise en production, sur le binaire et sur l'application en exécution, font partie des mesures minimales.
Comment Ostorlab vous aide
Ostorlab lance des scans automatisés depuis votre pipeline CI/CD à chaque build et surveille les versions publiées sur les stores sans déclenchement manuel. Mobile SAST fonctionne sur l'APK, l'AAB ou l'IPA, sans besoin du code source, et Mobile DAST exécute l'application.
Ce qui reste de votre ressort
Les normes de développement sécurisé, le contrôle des changements, la revue manuelle et l'approbation des mises en production.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 21.1 et 21.3 (texte espagnol)
Sécuriser les API utilisées pour fournir des services
Ce que dit le texte
Les entreprises qui utilisent des API pour fournir des services par l'intermédiaire de tiers doivent mettre en œuvre une analyse et une atténuation des risques, l'authentification mutuelle des systèmes et l'authentification des utilisateurs, l'autorisation des opérations par les utilisateurs, le chiffrement des données au stockage et en transit, des pratiques de développement sécurisé des API et une revue du code, l'analyse de vulnérabilités et les tests d'intrusion, la sécurité de l'infrastructure de support, la tolérance aux pannes et les mécanismes de contingence, le contrôle des accès et la surveillance des événements de sécurité. Les spécifications techniques des API doivent être documentées pour permettre leur audit.
Ce que cela implique pour votre application mobile
L'autorisation doit tenir au niveau de l'API, pour chaque appel, quoi que l'application envoie. La documentation des spécifications et les tests d'autorisation sont tous deux exigés.
Comment Ostorlab vous aide
Ostorlab intercepte le trafic de l'application, même avec TLS pinning, et teste les API à 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, le rejeu et l'automatisation, avec les requêtes et réponses à l'appui pour chaque résultat.
Ce qui reste de votre ressort
La conception et la documentation des API, la configuration de la passerelle, la sécurité de l'infrastructure et l'ingénierie de contingence.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 18 (texte espagnol)
Enrôler les utilisateurs avec deux facteurs indépendants
Ce que dit le texte
L'enrôlement d'un utilisateur dans un canal numérique exige de vérifier son identité et de prendre des mesures pour réduire le risque d'usurpation, ce qui comprend deux facteurs biométriques, ou deux facteurs de catégories différentes et indépendantes. Les identifiants générés pour les utilisateurs doivent être gérés tout au long de leur cycle de vie : activation, suspension, remplacement, renouvellement et révocation, en assurant leur confidentialité et leur intégrité le cas échéant.
Ce que cela implique pour votre application mobile
L'onboarding à distance et le ré-enrôlement sont des parcours à forte valeur. La vérification d'identité et le cycle de vie des identifiants impliquent l'application et les appels backend derrière elle.
Comment Ostorlab vous aide
Les tests authentifiés couvrent les parcours d'onboarding et de connexion avec vos comptes de test et testent les appels d'API derrière eux, y compris les tentatives de sauter une étape ou de rejouer une vérification d'identité. Le scan de secrets vérifie les identifiants et clés exposés par le package de l'application.
Ce qui reste de votre ressort
Le processus de vérification d'identité lui-même, y compris les contrôles auprès des registres d'identité, et la politique d'identifiants.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 19 (texte espagnol)
Utiliser l'authentification renforcée pour les paiements et les virements
Ce que dit le texte
L'authentification renforcée est requise pour les actions qui peuvent donner lieu à des opérations frauduleuses ou à d'autres abus : paiements ou virements vers des tiers, enregistrement d'un bénéficiaire de confiance, modifications des produits d'assurance épargne ou investissement, souscription d'un produit ou service, et modification des limites et conditions. Elle signifie une combinaison de facteurs d'authentification d'au moins deux catégories différentes et indépendantes, un contrôle contre les attaques de l'homme du milieu, comprenant un code unique généré par des méthodes cryptographiques à partir des données spécifiques de chaque opération et utilisé une seule fois, et une notification à l'utilisateur lorsque l'opération réussit.
Ce que cela implique pour votre application mobile
Le second facteur et le code par opération doivent être imposés par le serveur pour chaque action listée, y compris lorsque l'application ou un attaquant saute une étape.
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 et testent l'application effective de la MFA et les parcours d'authentification renforcée, y compris les tentatives de manipulation par un attaquant, ainsi que les appels d'API derrière les virements, les changements de bénéficiaire et de limites.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification et des opérations concernées, et l'envoi des notifications de réussite.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 20, modifié en 2023 et par la résolution SBS n° 2286-2024 (texte espagnol)
Maîtriser les exemptions et leurs conditions
Ce que dit le texte
Les bénéficiaires de confiance préalablement enregistrés par l'utilisateur, et les virements entre comptes détenus par le même client dans la même entreprise, sont exemptés de l'authentification renforcée, sauf pour la notification. Les paiements à faible risque de fraude issus d'une analyse de risque en ligne ne sont exemptés que si l'entreprise utilise des normes du secteur comme EMV 3DS et la tokenisation des paiements EMV dans leurs versions les plus récentes, définit un montant seuil, mesure le ratio de fraude par type d'opération et met à jour les règles de risque. Les opérations exécutées sous cette exemption, ou après que l'utilisateur a signalé le vol de ses identifiants, relèvent de la responsabilité de l'entreprise.
Ce que cela implique pour votre application mobile
Les exemptions sont de la logique métier dans l'application et ses API. Si un parcours peut être manipulé pour ressembler à un paiement vers un bénéficiaire de confiance ou à faible risque, la perte incombe à la banque.
Comment Ostorlab vous aide
Ostorlab teste la logique métier des parcours de paiement et de bénéficiaires et les appels d'API derrière eux, y compris les tentatives de manipuler les montants, les seuils et les cases à cocher, et de rejouer des validations.
Ce qui reste de votre ressort
Les règles d'analyse de risque, les montants seuils, la mesure du ratio de fraude et les décisions de responsabilité.
- Reglamento para la Gestión de la Seguridad de la Información y la Ciberseguridad, art. 17 (texte espagnol)
Définir la base d'authentification et surveiller les transactions
Ce que dit le texte
Les processus d'authentification des canaux numériques doivent définir les facteurs requis, les normes cryptographiques en vigueur, les délais et conditions de ré-authentification, notamment l'inactivité et les sessions longues, une base de contrôles contre les menaces comprenant une limite des tentatives d'authentification échouées et la prévention de l'interception et de la manipulation des messages, et des règles de conservation des journaux d'audit. Réévaluez les processus lorsque la technologie perd le support du fournisseur ou que de nouvelles vulnérabilités apparaissent, conservez des enregistrements détaillés des enrôlements et des événements d'authentification, et maintenez des outils de surveillance des transactions pour les schémas de fraude connus et les éléments d'authentification compromis.
Ce que cela implique pour votre application mobile
Les limites de tentatives, les délais d'inactivité, la conservation des journaux et la protection contre l'interception sont des comportements concrets de l'application et de son backend, et ils peuvent être testés.
Comment Ostorlab vous aide
Ostorlab teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions, le verrouillage après des échecs répétés et l'application effective de la MFA, et analyse le parcours des identifiants et des messages entre l'application et le backend.
Ce qui reste de votre ressort
Définir les règles de conservation des journaux, exploiter la surveillance des transactions et l'organisation de sécurité autour.
- Reglamento de Tarjetas de Crédito y Débito, art. 16.7 et art. 23.10, ajoutés par la résolution SBS n° 2286-2024 ; échéances reportées par la résolution SBS n° 771-2026 (texte espagnol)
Respecter la règle des deux facteurs pour les opérations par carte
Ce que dit le texte
L'authentification des opérations par carte suit le règlement de cybersécurité avec les normes techniques EMVCo : les opérations par carte présente exigent la puce ou sa représentation numérique plus un mot de passe (PIN) ou un autre facteur ; les opérations par carte non présente exigent les données de la carte plus un code de vérification dynamique ou un autre facteur vérifié en ligne sous EMV 3DS, sauf exemptions ; les portefeuilles mobiles tiers fondés sur la tokenisation de la carte exigent le jeton plus un second facteur de nature différente. EMV 3DS et EMV Tokenization satisfont le contrôle contre l'homme du milieu pour ces cas. L'entreprise est responsable des pertes liées aux opérations traitées sans second facteur. La dernière échéance, pour le double facteur sur les cartes de crédit émises avant le 1er juillet 2025, a été reportée au 1er juin 2026.
Ce que cela implique pour votre application mobile
Les paiements par carte non présente commencent souvent dans l'application bancaire. Le second facteur, la tokenisation et les règles d'acceptation ou de rejet en cas de facteur manquant font partie de l'application et de ses API.
Comment Ostorlab vous aide
Ostorlab teste les parcours de carte et de paiement dans l'application derrière la connexion, les appels à l'émetteur et aux services 3DS, et la manière dont un second facteur manquant ou échoué est traité, avec les requêtes et réponses à l'appui.
Ce qui reste de votre ressort
La certification EMV et 3DS avec votre processeur, les règles d'acceptation et le programme de renouvellement des cartes.
- Reglamento para la Gestión de la Continuidad del Negocio, art. 18 et 19, ajoutés par la résolution SBS n° 814-2025 (texte espagnol)
Maintenir la résilience du canal mobile
Ce que dit le texte
Le règlement de gestion de la continuité d'activité, modifié en 2025, exige des entreprises ayant des canaux numériques qu'elles identifient les produits et services prioritaires proposés par ces canaux et fixent des objectifs de délai de rétablissement, gèrent les risques des composants technologiques qui les sous-tendent, surveillent les canaux par rapport à leurs conditions normales, prévoient des canaux alternatifs, testent annuellement les stratégies de continuité et tiennent un registre centralisé des interruptions de plus de 30 minutes. Les virements, paiements interopérables, paiements de paie et de fournisseurs via l'application mobile ne peuvent pas être interrompus plus de cinq heures entre 6h00 et 22h00, ou trois heures pour les entreprises à concentration de marché. Les événements d'interruption doivent être déclarés à la SBS en quelques heures.
Ce que cela implique pour votre application mobile
La résilience concerne la disponibilité, mais les défaillances de sécurité en sont une des causes. L'application, ses API et leurs dépendances sont des composants nommés du canal mobile.
Comment Ostorlab vous aide
Ostorlab teste l'application et les API avant la mise en production et reteste les corrections, pour que des problèmes exploitables connus ne deviennent pas des pannes. Il n'exécute ni la surveillance, ni les canaux alternatifs, ni les exercices de continuité.
Ce qui reste de votre ressort
La surveillance des canaux, les canaux alternatifs, les tests de continuité, le registre des interruptions et les déclarations à la SBS.
- Ley N° 29733, art. 16 ; Decreto Supremo N° 016-2024-JUS, art. 34, 46 et 47 (texte espagnol)
Protéger les données personnelles et notifier les violations sous 48 heures
Ce que dit le texte
Les données personnelles doivent être traitées avec les mesures techniques, organisationnelles et légales nécessaires pour garantir leur sécurité et éviter leur altération, leur perte, leur traitement ou leur accès non autorisés. Le règlement de 2024 précise ce que cela signifie pour les plateformes et les applications mobiles : un contrôle d'accès documenté avec des procédures d'identification et d'authentification, des revues des privilèges au moins tous les six mois, une surveillance périodique des mesures et une formation du personnel, des journaux d'interaction conservés au minimum deux ans, et des contrôles contre les copies non autorisées de documents numériques. Un document de sécurité et un inventaire des données personnelles et des systèmes sont obligatoires. Les incidents de sécurité qui touchent de grands volumes de données ou des données sensibles doivent être notifiés à l'autorité nationale de protection des données dans les 48 heures, et aux personnes concernées dans les 48 heures ; les incidents numériques vont aussi au Centre national de sécurité numérique.
Source :Ley N° 29733, art. 16 ; Decreto Supremo N° 016-2024-JUS, art. 34, 46 et 47 (texte espagnol)
Ce que cela implique pour votre application mobile
L'application sur le téléphone et le backend derrière elle traitent tous deux des données personnelles. Contrôle d'accès, journaux, conservation et délais de notification s'appliquent au canal mobile.
Comment Ostorlab vous aide
Ostorlab recherche les jetons et les 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 identifiants et clés qui ne devraient pas être livrés dans l'application.
Ce qui reste de votre ressort
Le document de sécurité, l'inventaire des données, l'officier de protection des données, les systèmes de conservation des journaux et les notifications de violation.
Synthèse des textes publics de la SBS et du cadre péruvien de protection des données, vérifiés le 27 septembre 2026. Tous les textes sont en espagnol et sont résumés ici. Cette page ne constitue pas un avis juridique.
Les règles de la SBS, contrôle par contrôle
Les contrôles visés par les textes de la SBS et le cadre péruvien de protection des données, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Tests périodiques du système de gestion504-2021 art. 13(b), 21.1(f) | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Développement sécurisé et tests avant la mise en production504-2021 art. 12.5 | Mobile SAST et DAST dans la CI/CD à chaque build, et surveillance des versions publiées sur les stores. Détails | Résultats de scan par build et par version publiée sur les stores |
| Inventaire des logiciels et des composants504-2021 art. 12.9, 22 | Recense les SDK et bibliothèques natives de chaque version avec leurs versions, et associe les composants vulnérables aux vulnérabilités connues. Détails | Identité, version et emplacement de chaque composant dans le bundle de l'application, par version |
| Identifiants et clés dans l'application504-2021 art. 12.2(c), 18.2 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
| Mesures de sécurité des API504-2021 art. 21 | Intercepte le trafic même avec TLS pinning et teste les autorisations, les usages abusifs des jetons et les abus comme l'énumération et le rejeu. Détails | Requêtes et réponses à l'appui de chaque résultat d'API |
| Authentification renforcée, exemptions comprises504-2021 art. 19, 20 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les virements, les changements de bénéficiaire et de limites, avec étapes de reproduction |
| Limites de tentatives, sessions et interception504-2021 art. 17 | Teste les limites de tentatives échouées, le renouvellement des jetons, les délais d'inactivité et l'invalidation des sessions. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Deux facteurs pour les opérations par carteRèglement cartes art. 16.7, 23.10 | Teste les parcours de carte et de portefeuille dans l'application et les appels à l'émetteur et aux services 3DS. Détails | Preuves de parcours pour les seconds facteurs manquants ou échoués, avec journaux des requêtes et réponses |
| Données personnelles sur l'appareil et en transitLoi 29733 art. 16 ; DS 016-2024-JUS art. 46 | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| Résilience des canaux numériquesRèglement continuité art. 18, 19 ; 814-2025 | Ostorlab teste l'application et ses API avant la mise en production et reteste les corrections ; il n'exécute ni la surveillance ni les exercices de continuité. | Résultats de test et de retest par version, conservés dans vos preuves de canal |
Ostorlab teste les contrôles de l'application et de ses API. La surveillance SOC, la surveillance des transactions et de la fraude, la notification des incidents à la SBS et à l'ANPD, l'ingénierie de continuité et de reprise, les canaux alternatifs et le reporting au conseil restent du ressort de vos équipes.
Les contrôles de la SBS à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque technologique, fondée sur le règlement SGSI-C, les règles sur les cartes et le cadre péruvien de protection des données.
Rythme des tests
Intégrez l'application mobile et ses API aux tests planifiés du SGSI-C, avec des prestataires internes ou externes selon votre risque.
Avant chaque version
Lancez des tests SAST et DAST automatisés à chaque build et scannez chaque version publiée sur les stores, pas seulement celle testée le trimestre dernier.
API
Vérifiez l'authentification mutuelle, l'autorisation des utilisateurs, le chiffrement et le contrôle d'accès sur chaque API appelée par l'application, et gardez les spécifications auditables.
Authentification renforcée
Vérifiez que les virements, paiements, bénéficiaires de confiance et changements de limites exigent deux facteurs indépendants et un code par opération, imposés par le serveur.
Exemptions
Testez les exemptions de bénéficiaire de confiance et de faible risque, les seuils derrière elles, et confirmez que les opérations sans second facteur sont traitées comme la responsabilité de l'entreprise.
Sessions et tentatives
Testez les limites de tentatives échouées, la ré-authentification après inactivité, la conservation des journaux et les protections contre l'interception et le rejeu des messages.
Cartes
Vérifiez les deux facteurs pour les opérations par carte présente et non présente, le code de vérification dynamique, les portefeuilles tokenisés et les règles de surveillance, et suivez les échéances de renouvellement.
Données personnelles et déclarations
Recherchez les données personnelles dans le stockage et les journaux, tenez le document de sécurité et deux ans de journaux, et répétez la notification de violation sous 48 heures à l'autorité et aux clients.
Une liste indicative, et non un modèle de la SBS. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Tests authentifiésTestez la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test, y compris les appels derrière les virements et les changements de bénéficiaire.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes et les paiements.En savoir plus
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- Resolución SBS N° 504-2021: Reglamento para la Gestión de la Seguridad de la Información y la CiberseguridadSBS, datée du 19 février 2021, en vigueur depuis le 1er juillet 2021, le sous-chapitre sur l'authentification s'appliquant depuis le 1er juillet 2022. Modifiée par les résolutions SBS n° 1515-2021, 3240-2023, 03797-2023 et 2286-2024. Le texte espagnol est l'original
- Resolución SBS N° 6523-2013: Reglamento de Tarjetas de Crédito y DébitoSBS, 30 octobre 2013. Règles générales des cartes de crédit et de débit, y compris les mesures de sécurité pour les utilisateurs, la surveillance et la responsabilité des opérations non reconnues (art. 16 à 18 et 23). Texte espagnol consolidé
- Resolución SBS N° 2286-2024SBS, datée du 26 juin 2024, publiée le 28 juin 2024. Ajoute deux facteurs d'authentification pour les opérations par carte, les contrôles EMV 3DS et de tokenisation et la responsabilité des pertes sans second facteur, avec des échéances de mise en œuvre en 2024, 2025 et 2026
- Resolución SBS N° 3289-2025SBS, datée du 17 septembre 2025 et publiée le 19 septembre 2025. Réécrit l'article 17 du règlement des cartes : des systèmes de surveillance distincts de l'authentification, la gestion des alertes, les schémas de fraude et les limites par canal. Décrite par le Diario Oficial El Peruano
- Resolución SBS N° 771-2026SBS, 13 mars 2026, publiée au Journal officiel El Peruano le 18 mars 2026. Reporte au 1er juin 2026 le double facteur pour les cartes de crédit émises avant le 1er juillet 2025, second report après la résolution SBS n° 2220-2025
- Reglamento para la Gestión de la Continuidad del Negocio (Resolución SBS N° 877-2020) modifié par la Resolución SBS N° 814-2025SBS. La résolution 877-2020 a approuvé le règlement ; la résolution 814-2025, publiée le 10 mars 2025, ajoute la résilience opérationnelle des canaux numériques : objectifs de délai de rétablissement, tests annuels, registre des interruptions et déclarations, en vigueur par étapes
- Ley N° 29733, Ley de Protección de Datos PersonalesPubliée le 3 juillet 2011. Les articles 9 et 16 fixent le principe de sécurité et le devoir d'adopter des mesures techniques, organisationnelles et légales pour protéger les données personnelles. Texte espagnol
- Decreto Supremo N° 016-2024-JUS: Reglamento de la Ley N° 29733Publié le 30 novembre 2024, en vigueur 120 jours calendaires plus tard. L'article 46 couvre la sécurité des données personnelles traitées via les applications mobiles, l'article 47 exige un document de sécurité et l'article 34 impose une notification des incidents sous 48 heures. Texte espagnol
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Testez votre application bancaire mobile face aux règles de la SBS
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests authentifiés de votre application et de vos API avec notre équipe.