Résilience opérationnelle PRA et FCA : évaluez votre application bancaire mobile avant et après chaque version.
Les règles de résilience opérationnelle de la PRA et de la FCA exigent des établissements qu'ils puissent rester dans les tolérances d'impact de leurs services métier importants en cas de perturbation grave mais plausible, et qu'ils identifient et corrigent les vulnérabilités à temps. CBEST ajoute des évaluations menées par le renseignement sur les menaces pour les établissements sélectionnés par les régulateurs. Les règles sur les paiements imposent l'authentification forte du client lors de l'accès en ligne au compte, des paiements et d'autres actions à distance. Ostorlab teste votre application et les API qui la sous-tendent, derrière l'authentification, à chaque version.
- Évalue l'application mobile et les API qu'elle appelle, sur la version que téléchargent vos clients
- Teste l'authentification forte du client, les codes à usage unique, la liaison dynamique et la gestion de session avec vos comptes de test
- Recense les SDK et les bibliothèques natives de chaque version et les associe aux vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou des preuves de requêtes et de réponses
- Qui est concerné
- Banques, sociétés de crédit immobilier, entreprises d'investissement désignées par la PRA, assureurs, entreprises SM&CR à périmètre élargi, et établissements de paiement et de monnaie électronique
- Date clé
- Règles de résilience opérationnelle en vigueur depuis le 31 mars 2022 ; l'échéance pour pouvoir rester dans les tolérances d'impact était le 31 mars 2025
- Objet
- Tolérances d'impact, tests de scénarios, correction des vulnérabilités, évaluation menée par les menaces et authentification forte du client
- Texte de référence
- SYSC 15A du manuel de la FCA et SS1/21 de la PRA, avec PS21/3 de la FCA
Les textes de la PRA et de la FCA derrière votre canal mobile
Les règles de résilience opérationnelle figurent dans le manuel de la FCA et le recueil de règles de la PRA, aux côtés de CBEST et des règles sur les paiements. Les dates ci-dessous concernent les textes cités sur cette page.
- 29 mars 2021
Règles finales de résilience opérationnelle
La FCA publie PS21/3 et la PRA publie SS1/21, avec les règles et attentes sur les services métier importants, les tolérances d'impact, la cartographie et les tests de scénarios.
- 31 mars 2022
Entrée en vigueur des règles
SYSC 15A de la FCA et les parties de la PRA sur la résilience opérationnelle s'appliquent. Les établissements doivent avoir identifié leurs services métier importants, fixé les tolérances d'impact et commencé la cartographie et les tests.
- 31 mars 2025
Échéance des tolérances d'impact
À cette date, les établissements doivent avoir réalisé la cartographie et les tests leur permettant de rester dans les tolérances d'impact de chaque service métier important, et avoir fait les investissements nécessaires.
- 12 novembre 2024
Tiers critiques
La PRA, la Banque d'Angleterre et la FCA publient les règles finales sur les tiers critiques (PRA PS16/24, FCA PS24/16). Le régime entre en vigueur le 1er janvier 2025.
- 20 octobre 2025
Pratiques de réponse et de rétablissement cyber
La Banque, la PRA et la FCA publient les pratiques efficaces observées chez les établissements systémiques en matière de réponse et de rétablissement cyber. La publication n'introduit aucune nouvelle exigence.
- 18 mars 2026
Règles de signalement des incidents
La FCA publie PS26/2 sur le signalement des incidents opérationnels et des tiers, avec une définition unique de l'incident opérationnel et des seuils de signalement. Les règles s'appliquent à partir du 18 mars 2027.
- 15 mai 2026
Déclaration sur l'IA de frontière
La Banque d'Angleterre, la FCA et le Trésor britannique demandent aux établissements de trier, prioriser et corriger les vulnérabilités plus vite et à grande échelle, y compris dans les logiciels tiers et open source.
- 13 juillet 2026
Premières désignations de tiers critiques
Le Trésor britannique désigne quatre fournisseurs mondiaux de cloud et de technologie comme tiers critiques : Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited et Oracle Corporation UK Limited.
Les règles de la PRA et de la FCA, 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.
- Manuel de la FCA, SYSC 15A.2 ; PRA SS1/21, mars 2022
Identifier les services métier importants et fixer les tolérances d'impact
Ce que dit le texte
En vertu de SYSC 15A de la FCA et des parties de la PRA sur la résilience opérationnelle, un établissement doit identifier ses services métier importants et fixer pour chacun une tolérance d'impact, la perturbation maximale tolérable. Il doit pouvoir rester dans chaque tolérance d'impact en cas de perturbation grave mais plausible, et réviser ses évaluations au moins une fois par an ou après un changement important. SS1/21 de la PRA précise les attentes derrière les règles.
Source :Manuel de la FCA, SYSC 15A.2 ; PRA SS1/21, mars 2022
Ce que cela implique pour votre application mobile
La banque mobile est presque toujours un service métier important, et l'application est le principal moyen d'y accéder pour les clients. Si l'application ou ses API tombent en panne ou sont compromises, l'établissement doit pouvoir rester dans la tolérance qu'il a fixée.
Comment Ostorlab vous aide
Ostorlab teste l'application et ses API à chaque version, afin que les faiblesses susceptibles de perturber le service soient détectées avant que les clients ne les subissent. Les résultats sont notés et suivis jusqu'à leur clôture.
Ce qui reste de votre ressort
L'identification des services et la fixation des tolérances, ainsi que les dispositifs de réponse et de rétablissement qui les sous-tendent.
- Manuel de la FCA, SYSC 15A.4.1 ; PRA SS1/21, 4.2 et 4.15
Cartographier les ressources et corriger les vulnérabilités à temps
Ce que dit le texte
Les établissements doivent identifier et documenter les personnes, processus, technologies, installations et informations nécessaires à la fourniture de chaque service métier important, avec un niveau de détail suffisant pour identifier les vulnérabilités et y remédier. La PRA attend que la vitesse de correction soit proportionnée à l'impact potentiel d'une perturbation, et que les établissements élaborent et mettent en œuvre des plans de remédiation lorsqu'un service ne pourrait pas rester dans sa tolérance d'impact.
Source :Manuel de la FCA, SYSC 15A.4.1 ; PRA SS1/21, 4.2 et 4.15
Ce que cela implique pour votre application mobile
Le binaire de l'application, ses SDK et les API qui la sous-tendent sont des ressources technologiques de cette cartographie. Une vulnérabilité dans l'une d'elles est une vulnérabilité du service.
Comment Ostorlab vous aide
Le SAST mobile analyse le binaire, y compris les SDK intégrés, le SCA associe les composants aux vulnérabilités connues, et le pentest par agents IA teste l'application en exécution et ses API. Les résultats deviennent des tickets dans la plateforme ou dans Jira et ServiceNow, et sont retestés après correction.
Ce qui reste de votre ressort
La fixation des délais de correction, l'allocation des ressources pour les correctifs et leur suivi jusqu'à clôture.
- Manuel de la FCA, SYSC 15A.5 et 15A.6 ; PRA SS1/21, chapitre 6
Mener des tests de scénarios et en tirer les leçons
Ce que dit le texte
Les établissements doivent élaborer et tenir à jour un plan de tests et mener des tests de scénarios de perturbations graves mais plausibles, notamment l'indisponibilité de services tiers, la perte ou la réduction de la fourniture de technologies, et la corruption ou la suppression de données critiques. Les tests peuvent être sur papier, des simulations ou sur systèmes en production, mais ne doivent pas présenter de risque matériel de créer une perturbation. Après un test ou une perturbation, les établissements doivent mener un retour d'expérience et apporter les améliorations identifiées. Les enregistrements sont conservés au moins six ans.
Source :Manuel de la FCA, SYSC 15A.5 et 15A.6 ; PRA SS1/21, chapitre 6
Ce que cela implique pour votre application mobile
Les tests de scénarios exercent l'ensemble du service, pas seulement l'application. Les résultats sur l'application et les API issus de ces tests ne sont utiles que si les faiblesses sous-jacentes sont corrigées et peuvent être prouvées comme telles.
Comment Ostorlab vous aide
Ostorlab ne réalise pas de tests de scénarios ni d'exercices. Il teste les contrôles de l'application et des API dont dépendent vos scénarios, avant et après l'exercice, afin que les éléments techniques de votre retour d'expérience disposent de preuves.
Ce qui reste de votre ressort
La conception et la conduite des scénarios, les plans de continuité et de rétablissement, et les retours d'expérience.
- CBEST Implementation Guide, édition 2024, Banque d'Angleterre
Se préparer aux évaluations CBEST menées par le renseignement sur les menaces
Ce que dit le texte
CBEST est le cadre d'évaluation mené par le renseignement sur les menaces des régulateurs, utilisé depuis 2014 pour les établissements et les infrastructures de marché financier sélectionnés par la PRA, la Banque d'Angleterre et la FCA. Un CBEST imite les actions d'attaquants réels contre les systèmes et services qui sous-tendent les services métier importants, se déroule en quatre phases, de l'initiation à un plan de remédiation supervisé par le régulateur, et est mené par des prestataires de renseignement sur les menaces et de tests d'intrusion accrédités CREST. L'édition 2024 du guide de mise en œuvre de CBEST ajoute des indications sur la documentation de la remédiation et sur les tiers liés aux services métier importants.
Source :CBEST Implementation Guide, édition 2024, Banque d'Angleterre
Ce que cela implique pour votre application mobile
CBEST est piloté par le régulateur et cadré autour de vos services métier importants. Il ne remplace pas les tests réguliers de votre application et de vos API entre les évaluations.
Comment Ostorlab vous aide
Ostorlab ne réalise pas de CBEST. Il vous aide à aborder un CBEST avec les problèmes connus de l'application et des API déjà corrigés, et reteste ensuite les éléments applicatifs et API de votre plan de remédiation.
Ce qui reste de votre ressort
Le cadrage et la conduite du CBEST, le choix des prestataires accrédités et le plan de remédiation supervisé par le régulateur.
- PRA SS2/21, version de novembre 2024, chapitres 7 et 8
Gérer l'externalisation et le risque lié aux tiers
Ce que dit le texte
En vertu de SS2/21 de la PRA, les établissements restent responsables des services externalisés, y compris l'externalisation importante. La PRA attend des contrôles robustes pour les données en transit, en mémoire et au repos, notamment le chiffrement et la gestion des clés, la gestion des identités et des accès, la journalisation des accès et activités, et la détection et la réponse aux incidents. Pour l'externalisation importante, les accords écrits doivent prévoir des droits d'accès et d'audit couvrant les résultats des tests d'intrusion de sécurité réalisés sur les applications, données et systèmes du prestataire. Le texte couvre aussi les plans de continuité et de sortie.
Source :PRA SS2/21, version de novembre 2024, chapitres 7 et 8
Ce que cela implique pour votre application mobile
Votre application intègre des SDK tiers qui communiquent avec leurs propres backends, et vos API peuvent tourner sur des services cloud. Leur sécurité fait partie de votre vision de l'externalisation et du risque tiers.
Comment Ostorlab vous aide
Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions, les associe aux vulnérabilités connues et montre ce que l'application et ses SDK échangent avec les backends sur le réseau.
Ce qui reste de votre ressort
La diligence raisonnable, les contrats, les droits d'audit, les plans de sortie et la configuration du cloud.
- FCA, Critical Third Parties: Strengthening UK Financial Services ; PRA PS16/24 et FCA PS24/16
Connaître les tiers critiques derrière vos services
Ce que dit le texte
Le régime des tiers critiques, en vigueur depuis le 1er janvier 2025, permet au Trésor britannique de désigner des tiers dont la défaillance ou la perturbation pourrait menacer la stabilité du système financier britannique ou la confiance en celui-ci, et aux régulateurs de superviser les services fournis par ces tiers. Les premières désignations, portant sur quatre fournisseurs mondiaux de cloud et de technologie, sont entrées en vigueur le 13 juillet 2026. Le régime complète les responsabilités propres des établissements plutôt qu'il ne les remplace : les établissements et leurs conseils restent responsables de la gestion du risque tiers et de la résilience opérationnelle.
Source :FCA, Critical Third Parties: Strengthening UK Financial Services ; PRA PS16/24 et FCA PS24/16
Ce que cela implique pour votre application mobile
Si votre application ou votre backend tourne chez un prestataire désigné, le risque reste le vôtre. Le régime donne un levier supplémentaire aux régulateurs ; il ne transfère pas vos obligations.
Comment Ostorlab vous aide
Ostorlab teste les contrôles de votre application et de ses API où qu'ils s'exécutent, afin que les preuves que vous détenez ne dépendent pas des assurances du prestataire.
Ce qui reste de votre ressort
Les accords contractuels avec les prestataires, et vos propres obligations d'externalisation et de résilience.
- Payment Services Regulations 2017, article 100 ; FCA, Strong Customer Authentication
Appliquer l'authentification forte du client à l'application et à ses paiements
Ce que dit le texte
En vertu de l'article 100 du Payment Services Regulations 2017, un prestataire de services de paiement doit appliquer l'authentification forte du client lorsque le client accède en ligne à son compte de paiement, initie une opération de paiement électronique, ou réalise toute action par un canal à distance pouvant impliquer un risque de fraude au paiement ou d'autres abus. Les paiements à distance doivent utiliser une authentification qui lie dynamiquement l'opération à un montant et à un bénéficiaire précis. Les prestataires doivent aussi maintenir des mesures de sécurité adéquates pour protéger la confidentialité et l'intégrité des données de sécurité personnalisées. La FCA attend des solutions d'authentification qui fonctionnent pour tous les groupes de consommateurs, y compris les clients qui n'utilisent pas de téléphone mobile.
Source :Payment Services Regulations 2017, article 100 ; FCA, Strong Customer Authentication
Ce que cela implique pour votre application mobile
La connexion, les paiements et les modifications sensibles de compte dans l'application relèvent tous de la SCA. Les contrôles doivent être appliqués par le backend, pas seulement présentés par l'application.
Comment Ostorlab vous aide
Ostorlab saisit les codes à usage unique SMS, e-mail ou TOTP avec vos comptes de test et teste l'application de la SCA, la liaison dynamique et les parcours d'authentification renforcée, y compris la manière dont les attaquants tentent de les manipuler, ainsi que les appels d'API sous-jacents.
Ce qui reste de votre ressort
Le choix des méthodes d'authentification et des exemptions, la surveillance des transactions et l'accessibilité des méthodes proposées.
- Payment Services Regulations 2017, articles 98 et 99 ; FCA PS26/2, 18 mars 2026
Gérer les risques opérationnels et de sécurité, et signaler les incidents
Ce que dit le texte
L'article 98 du Payment Services Regulations 2017 impose à chaque prestataire de services de paiement de maintenir un cadre avec des mesures d'atténuation et des contrôles appropriés pour les risques opérationnels et de sécurité de ses services de paiement, y compris une gestion efficace des incidents et la détection et la classification des incidents opérationnels et de sécurité majeurs, avec une évaluation actualisée fournie à la FCA au moins une fois par an. L'article 99 impose de notifier à la FCA sans délai indu tout incident opérationnel ou de sécurité majeur, et d'informer les utilisateurs de services de paiement lorsque leurs intérêts financiers sont affectés. À partir du 18 mars 2027, les règles PS26/2 de la FCA créent un régime unique FCA, PRA et Banque d'Angleterre pour le signalement des incidents opérationnels, avec une définition unique de l'incident opérationnel, des seuils de signalement et des rapports standard ou renforcés.
Source :Payment Services Regulations 2017, articles 98 et 99 ; FCA PS26/2, 18 mars 2026
Ce que cela implique pour votre application mobile
Les incidents qui commencent dans l'application ou une API sont des incidents opérationnels et de sécurité. Les preuves que vous conservez pendant les tests sont ce qui vous permet de les classer et de les signaler rapidement.
Comment Ostorlab vous aide
Ostorlab ne signale pas d'incidents aux régulateurs. Il conserve pour chaque résultat les preuves, la gravité et l'historique des retests que vos équipes incidents et reporting peuvent utiliser.
Ce qui reste de votre ressort
La gestion des incidents, leur classification, la notification à la FCA et la communication avec les clients.
- UK GDPR, article 32 ; ICO, A guide to data security
Protéger les données personnelles et tester vos mesures de sécurité
Ce que dit le texte
L'article 32 du RGPD britannique impose aux responsables du traitement et aux sous-traitants de mettre en œuvre des mesures techniques et organisationnelles adaptées au risque, notamment le chiffrement ou la pseudonymisation, la capacité à garantir en permanence la confidentialité, l'intégrité, la disponibilité et la résilience, et un processus pour tester, évaluer et apprécier régulièrement l'efficacité de ces mesures. L'ICO indique que ces tests peuvent être réalisés par des techniques telles que l'analyse de vulnérabilités et les tests d'intrusion, et que les organisations doivent documenter les résultats et donner suite aux recommandations, ou avoir une raison valable de ne pas le faire.
Ce que cela implique pour votre application mobile
L'application est le lieu où les données clients sont collectées, affichées et stockées sur un appareil que la banque ne contrôle pas. Les mesures qui les protègent doivent être testées régulièrement et de manière documentée.
Comment Ostorlab vous aide
Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, vérifie les protections du transport et trouve les clés d'API et les identifiants dans le paquet de l'application, avec des preuves de système de fichiers sur ce qui a été écrit, où et quand.
Ce qui reste de votre ressort
L'analyse de risque, les mesures elles-mêmes, les analyses d'impact relatives à la protection des données et la notification des violations.
- Déclaration commune de la Banque d'Angleterre, de la FCA et du Trésor britannique sur les modèles d'IA de frontière et la résilience cyber, 15 mai 2026
Surveiller et corriger les vulnérabilités plus vite
Ce que dit le texte
Dans une déclaration commune du 15 mai 2026, la Banque d'Angleterre, la FCA et le Trésor britannique ont indiqué que les modèles d'IA de frontière peuvent identifier rapidement et faciliter l'exploitation d'un nombre potentiellement élevé de vulnérabilités dans les parcs technologiques des établissements, et que ceux-ci doivent pouvoir trier, prioriser, évaluer les risques et corriger les vulnérabilités plus rapidement, plus souvent et à grande échelle, y compris par l'automatisation lorsque c'est approprié. La déclaration pointe aussi les risques liés aux tiers, aux chaînes d'approvisionnement et aux logiciels open source, ainsi que les pratiques efficaces de réponse et de rétablissement cyber publiées par la Banque, la PRA et la FCA en octobre 2025.
Ce que cela implique pour votre application mobile
Une version publiée peut être vulnérable le lendemain de sa mise en ligne. La découverte des vulnérabilités et l'application des correctifs doivent suivre un rythme que la chaîne de publication peut tenir.
Comment Ostorlab vous aide
Ostorlab exécute des scans depuis votre pipeline CI/CD à chaque build et surveille les versions publiées sur les stores sans déclenchement manuel, afin que les nouveaux résultats apparaissent sur la version concernée et que les correctifs soient retestés dès leur publication.
Ce qui reste de votre ressort
Les décisions de correctifs, la gestion du changement et le risque opérationnel d'une remédiation à grande échelle.
Synthèse de textes publics de la PRA, de la FCA, de la Banque d'Angleterre, de l'ICO et de la législation britannique, vérifiés le 27 septembre 2026. Cette page ne constitue pas un avis juridique.
Les règles de la PRA et de la FCA, contrôle par contrôle
Les contrôles visés par les textes de la PRA et de la FCA, 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 |
|---|---|---|
| Services métier importants et tolérances d'impactSYSC 15A.2 ; SS1/21 | Pentest par agents IA de l'application et de ses API, derrière l'authentification, sur la version que vous publiez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une carte de couverture |
| Cartographie, vulnérabilités et délais de correctionSYSC 15A.4 ; SS1/21 4.15 | Résultats notés de critique à faible, suivis en tickets et retestés après correction. Détails | Historique des tickets et résultat du retest pour chaque résultat |
| Préparation aux tests de scénariosSYSC 15A.5 | Teste les contrôles de l'application et des API dont dépendent vos scénarios, avant et après l'exercice. Détails | Résultats de scan par build, avec étapes de reproduction |
| Préparation et remédiation CBESTCBEST Implementation Guide 2024 | Reteste les éléments applicatifs et API d'un plan de remédiation CBEST. Détails | Résultats des retests pour les éléments de remédiation que vous définissez |
| Composants tiers et open sourceSS2/21 chapitre 7 ; déclaration sur l'IA de frontière | Empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, version après version. Détails | Vulnérabilités associées avec recommandations de mise à jour ou de remplacement, et clôture suivie entre les versions |
| Tests de sécurité des services externalisésSS2/21 8.4 | Teste l'application et les API qu'elle appelle où qu'elles soient hébergées, avec des preuves de requêtes et de réponses. Détails | Preuves de requêtes et de réponses pour chaque résultat d'API |
| Authentification forte du client et liaison dynamiquePSRs 2017 art. 100 | Se connecte avec des codes à usage unique et teste l'application de la SCA, la liaison dynamique et les parcours renforcés. Détails | Résultats sur les parcours de connexion, de paiement et d'authentification renforcée, avec étapes de reproduction |
| Données de sécurité personnaliséesPSRs 2017 art. 100(3) ; normes techniques SCA | Trouve les clés d'API, jetons et identifiants dans le paquet de l'application et vérifie s'ils fonctionnent. Détails | Secrets validés, avec les permissions et services qu'ils exposent |
| Protection des données sur l'appareil et en transitUK GDPR article 32 ; orientations de l'ICO | Recherche les jetons et données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie les protections du transport. Détails | Preuves de système de fichiers montrant ce qui a été écrit, où et quand |
| Preuves d'incident et signalementPSRs 2017 art. 99 ; FCA PS26/2 | Conserve pour chaque résultat les preuves, la gravité et l'historique des retests qui appuient la classification des incidents. | Preuves des résultats, notations de gravité et historique des retests |
Ostorlab teste les contrôles de l'application et de ses API. Les tests de scénarios, CBEST, la surveillance SOC, la réponse aux incidents et leur signalement, la continuité et le rétablissement, la gouvernance et la sécurité physique restent du ressort de vos équipes.
Les contrôles de la PRA et de la FCA à tester dans votre application mobile
Une liste pratique pour les équipes sécurité, résilience et risque technologique, fondée sur les règles de résilience opérationnelle, les règles d'externalisation et les règles sur les paiements et les données.
Services métier importants
Vérifiez si l'application mobile et ses API relèvent d'un service métier important, et que leurs tests sont bien dans le périmètre de vos travaux sur les tolérances d'impact.
Délais de correction
Notez les résultats, fixez des délais par gravité et conservez les preuves de retest qui prouvent que chaque correctif a été appliqué.
Avant et après la publication
Exécutez SAST, DAST et SCA automatisés à chaque build, et scannez chaque version publiée sur les stores, pas seulement celle testée le trimestre dernier.
Composants et SBOM
Tenez une liste versionnée des SDK et bibliothèques natives de chaque version, et confrontez-la aux vulnérabilités connues.
Authentification forte du client
Vérifiez que la connexion, les paiements et les modifications sensibles exigent la SCA côté serveur, que les paiements à distance lient dynamiquement montant et bénéficiaire, et que les méthodes de repli sont suivies.
Secrets dans l'application
Vérifiez la présence de clés d'API, jetons et identifiants dans le paquet de l'application, et renouvelez ceux qui fonctionnent.
Données sur l'appareil
Recherchez les jetons et données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et testez les protections du transport.
Préparation à CBEST et aux incidents
Abordez CBEST avec les problèmes connus de l'application et des API corrigés, et gardez les preuves de scan prêtes pour la classification et le signalement des incidents.
Une liste indicative, et non un modèle de la FCA ou de la PRA. 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.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.
- SS1/21 Operational resilience: Impact tolerances for important business servicesPRA, version de mars 2022, publiée le 11 mars 2022 et effective depuis le 31 mars 2022. Publiée initialement le 29 mars 2021 avec PS6/21. Tolérances d'impact, cartographie, tests de scénarios et remédiation, avec le 31 mars 2025 comme échéance pour que les établissements puissent rester dans leurs tolérances d'impact
- PS21/3 Building operational resilienceFCA, publiée le 29 mars 2021, règles et orientations en vigueur depuis le 31 mars 2022. Fixe les exigences de résilience opérationnelle figurant dans le manuel de la FCA, y compris l'échéance du 31 mars 2025
- FCA Handbook SYSC 15A Operational resilienceFCA, dernière mise à jour le 5 avril 2024. Services métier importants, tolérances d'impact, cartographie, tests de scénarios, retours d'expérience, enregistrements conservés au moins six ans et révision annuelle
- CBEST Implementation GuideBanque d'Angleterre, édition 2024. Le cadre d'évaluation mené par le renseignement sur les menaces utilisé depuis 2014 par la Banque, la PRA et la FCA, avec des prestataires accrédités CREST, quatre phases d'évaluation et un plan de remédiation supervisé
- SS2/21 Outsourcing and third party risk managementPRA, version de novembre 2024, publiée le 15 novembre 2024 et effective depuis le 31 décembre 2024. Chapitres 7 (sécurité des données), 8 (droits d'accès, d'audit et d'information) et 10 (continuité et plans de sortie). Une mise à jour de mars 2026, issue de PS7/26, s'applique à partir du 18 mars 2027
- Critical Third Parties: Strengthening UK Financial ServicesFCA, avec la PRA et la Banque d'Angleterre. Règles finales publiées le 12 novembre 2024 (PRA PS16/24, FCA PS24/16), régime en vigueur depuis le 1er janvier 2025. Premières désignations entrées en vigueur le 13 juillet 2026 pour Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited et Oracle Corporation UK Limited
- The Payment Services Regulations 2017Instrument statutaire britannique 2017 n° 752, articles 98 à 100. Gestion des risques opérationnels et de sécurité, signalement des incidents et authentification forte du client, avec les normes techniques associées telles qu'intégrées au droit britannique
- A guide to data securityOrientations de l'ICO sur le principe de sécurité du RGPD britannique et l'article 32, y compris l'exigence d'un processus de test, d'évaluation et d'appréciation réguliers de l'efficacité des mesures de sécurité, et l'analyse de vulnérabilités et les tests d'intrusion comme techniques
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.
Évaluez votre application bancaire mobile comme le décrivent la PRA et la FCA
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.