Quelles sont les sanctions si les PSP ne se conforment pas à la nouvelle réglementation RTS d'ici novembre 2018 ?
PSD2 est une directive européenne que tous les États membres de l'UE doivent adopter. Les prestataires de services de paiement doivent se conformer aux exigences PSD2 afin d'être légalement reconnus en tant que prestataire de services de paiement ayant le droit de fournir des services dans l'UE.
L'ABE publiera-t-elle un guide d'évaluation des RTS sur SCA et CSC similaire au guide BCE publié en 2014 ?
Nous n'avons pas d'informations qui confirment ou infirment que l'EBA publierait un guide d'évaluation similaire.
Le SMS est-il conforme à PSD2 ?
L'un des objectifs d'EBA dans son RTS était de rester technologiquement neutre pour laisser autant de place que possible à l'innovation. Le défi était de ne pas être très normatif lors de la spécification des exigences. En fin de compte, aucune technologie spécifique n'est interdite par RTS, cependant, certaines des pratiques existantes ne seront plus entièrement conformes aux exigences SCA. On peut dire que le SMS peut être considéré comme un élément de possession, car il ne peut normalement être lu que par le destinataire prévu du message SMS. Donc, en théorie, SMS remplit l'exigence d'élément de possession, et il peut donc être utilisé comme bloc de construction d'une solution de signature de transaction.
Afin de répondre aux exigences de Dynamic Linking, le message SMS doit inclure les informations de paiement, c'est-à-dire le montant d'argent et des informations sur le bénéficiaire, en plus du code d'authentification. Les exigences relatives au lien dynamique indiquent également que la confidentialité et l'intégrité des informations de paiement doivent être protégées. Cela pourrait impliquer que les informations de paiement doivent être cryptées. Cependant, décrypter le contenu d'un SMS nécessiterait une application sur la carte SIM du téléphone mobile ou sur le téléphone lui-même, ce qui n'est pas pratique.
Au final, l'utilisation du SMS implique d'avoir un haut niveau de sécurité pour l'appareil de l'utilisateur, une protection contre la fraude par échange de carte SIM, une protection contre d'éventuelles interceptions et abus de SMS. En réalité, aujourd'hui, ce sont des défis très difficiles. Différentes autorités compétentes ont actuellement des opinions différentes sur l'utilisation des SMS. Plusieurs autorités découragent l'utilisation des SMS, tandis que d'autres l'autorisent. Nous surveillons ces avis et mettrons à jour cette FAQ lorsqu'il y aura une décision claire.
Le mobile et le token peuvent-ils être comptés comme deux canaux et être conformes à PSD2 ?
Selon PSD2, le mécanisme d'authentification doit être construit à partir de deux des trois éléments d'authentification possibles, c'est-à-dire quelque chose que seul l'utilisateur possède, quelque chose que seul l'utilisateur connaît et ce que seul l'utilisateur est.
Quand utiliseriez-vous le code d'authentification ? Considérez-vous cela comme un deuxième facteur?
Le code d'authentification doit toujours être utilisé pour authentifier un utilisateur. Le code d'authentification doit être généré par un mécanisme d'authentification qui est construit à partir de deux des trois éléments d'authentification possibles, c'est-à-dire quelque chose que seul l'utilisateur possède, quelque chose que seul l'utilisateur connaît et ce que seul l'utilisateur est.
Le protocole 3D Secure pour cartes est-il suffisant pour SCA ou est-il obligatoire ?
3D Secure est en effet un protocole qui peut être utilisé par les PSP pour construire une solution conforme aux exigences SCA pour les paiements par carte.
Quelle catégorie des trois éléments de SCA pouvez-vous donner à OTP par SMS ? S'agit-il d'un savoir ou d'une possession ?
L'utilisateur reçoit le message SMS normalement sur un téléphone personnel, il s'agirait donc d'un élément de possession.
Pourriez-vous clarifier la portée de PSD2? S'agit-il uniquement de paiements sur Internet (en ligne via un navigateur) ? Si non, quoi d'autre ?
PSD2 couvre les paiements par navigateur et mobiles.
Pouvez-vous nous en dire plus sur la manière dont vous implémentez l'analyse comportementale ? Est-ce une extension du SDK DP4APPS ?
L'authentification comportementale de OneSpan est une extension de OneSpan Mobile Security Suite. L'authentification comportementale permet non seulement de prouver de manière précise et transparente l'identité de l'utilisateur, mais également de détecter des comportements spécifiques, par exemple les attaques de bots. Plus d'informations sont disponibles ici.
Les clients de OneSpan Mobile Security Suite peuvent tirer parti de leur implémentation existante en ajoutant uniquement les nouveaux composants nécessaires de la solution. Pour obtenir la meilleure combinaison de sécurité et de convivialité, il est important aujourd'hui de combiner les trois éléments :
- Sécurité des applications mobiles avec collecte de données sur les appareils clients
- Cadre d'authentification multifacteur et biométrique et canal sécurisé pour une communication sécurisée
- Logiciel d'analyse de fraude et de risque pour analyser les entrées des utilisateurs, les appareils, le comportement et appliquer la prise de décision en temps réel sur plusieurs canaux. La suite de solutions OneSpan couvre tous ces domaines.
Plus d'infos sur Conformité PSD2 .
Existe-t-il des indications sur la question de savoir si la validation lors de l'utilisation de la biométrie doit avoir lieu côté serveur ou côté client ?
Les normes techniques réglementaires (RTS) sur l'authentification forte du client ne précisent pas si la vérification biométrique doit être effectuée côté client ou côté serveur. Les deux options sont donc autorisées.
OneSpan a-t-il reçu des assurances formelles de la BCE concernant la conformité de ses jetons avec PSD2 RTS ?
À l'heure actuelle, il n'existe pas de programme de certification formel pour des produits spécifiques dans le cadre de la PSD2. En tant que tel, il n'est pas possible pour OneSpan d'obtenir une assurance formelle. Cependant, OneSpan discute de la conformité de ses produits de manière informelle avec les autorités compétentes afin de s'assurer que nous interprétons correctement le RTS et que nos produits sont conformes.
Avez-vous l'intention d'étiqueter chaque modèle de jeton (par exemple DP310) avec une indication de conformité PSD2 ?
OneSpan ne prévoit pas actuellement de le faire. De plus, il n'existe pas de programme de certification formel pour les solutions d'authentification forte sous PSD2.
Les périphériques matériels d'authentification par clavier PIN OneSpan sont-ils conformes ?
Les exigences de liaison dynamique dans le RTS stipulent que le code d'authentification doit être calculé sur certaines informations de transaction, y compris le montant d'argent et des informations sur le bénéficiaire (par exemple, le numéro de compte bancaire du bénéficiaire).
De plus, le payeur doit être informé de ces informations de transaction. Enfin, la confidentialité, l'intégrité et l'authenticité des informations de transaction doivent être protégées à tout moment. Sur la base de ces exigences, nous pouvons dire ce qui suit à propos de l'utilisation de périphériques matériels d'authentification par clavier PIN :
- Cet appareil offre un très haut niveau de sécurité des éléments de possession et de connaissance
- Cet appareil permet à l'utilisateur final de saisir le montant et les détails du bénéficiaire et de les inclure dans la génération d'un code d'authentification unique
- L'utilisateur est au courant des actions avec un tel appareil. Ainsi, le Digipass matériel avec PIN-pad, s'il est utilisé avec le mode de signature des données de transaction, est conforme aux exigences de liaison dynamique.
La liaison dynamique est-elle identique à la signature de transaction ?
Oui c'est le cas. Le terme « liaison dynamique » est utilisé par PSD2 et le RTS sur SCA.
Cela signifie-t-il que OneSpan fournit la liaison dynamique, plutôt qu'une entité distincte, telle que la PSP ?
Il est de la responsabilité du PSP d'effectuer une authentification forte de ses utilisateurs. OneSpan peut fournir aux PSP des produits et services pour effectuer une authentification forte.
Le RTS nécessite une séparation des canaux entre l'application qui utilisera l'OTP et la transmission OTP. Comment voyez-vous la conformité 1AA ?
La version finale du RTS n'exige plus la ségrégation des canaux. Comme indiqué dans les commentaires du projet final de RTS, ce langage a été supprimé du projet de RTS, car il prêtait à confusion.
Comment vous conformez-vous à l'exigence de l'article 2(2) A) lorsqu'un client effectue plusieurs paiements en même temps à différents bénéficiaires ?
Pour les paiements groupés, le code d'authentification doit être calculé sur la base du montant total de tous les paiements combinés et sur la base des numéros de compte de tous les bénéficiaires.
OneSpan a-t-il des solutions pour générer des liens dynamiques dans les cas où les clients ne souhaitent pas utiliser les smartphones ?
Aujourd'hui, OneSpan fournit des solutions d'authentification à plus de 2 000 banques dans le monde, avec divers cas d'utilisation, besoins commerciaux, groupes d'utilisateurs et exigences réglementaires. C'est possible, car OneSpan propose une très large gamme de solutions pouvant couvrir tous les besoins possibles. Par exemple, OneSpan fournit des appareils compatibles PSD2 très simples à utiliser avec de grands écrans, des boutons et même des commandes vocales pour les utilisateurs âgés : Digipass 301
En option, dans l'espace SWYS, une option populaire consiste à utiliser l'un des appareils haut de gamme avec un clavier en caoutchouc robuste : Digipass 770
Cet appareil n'a pas besoin de saisie approfondie de l'utilisateur, ne nécessite que l'approbation du client et une courte saisie du code PIN. Les études d'acceptation des utilisateurs menées par les clients OneSpan montrent un taux d'adoption très élevé et une baisse essentielle des appels au service d'assistance des utilisateurs lors du passage à cette technologie.
Pour l'authentification par SMS à l'aide d'un processus 3DS, devons-nous toujours inclure les détails de paiement lorsqu'un ACS génère l'OTP et le distribue au numéro de mobile enregistré ?
Notre interprétation des exigences de liaison dynamique dans le projet final de RTS est en effet que les informations de paiement doivent être incluses dans le message SMS pour l'authentification du paiement.
Nous avons un Digipass 275 matériel avec 5 chiffres qui peut être utilisé comme challenge réponse pour la liaison dynamique. Est-ce conforme pour la liaison dynamique ?
Ceci est très probablement conforme à la version finale du RTS.
Le OneSpan Go 6 Digipass est-il conforme à la RTS en ce qui concerne l'exigence de liaison dynamique pour les paiements de grande valeur ?
En général, les Go-tokens ne génèrent pas de codes d'authentification sur les informations de paiement (telles que le montant d'argent). Pour cette raison, il ne peut pas être utilisé pour le Dynamic Linking, qui est toujours requis pour les paiements supérieurs à 500 euros.
Comment les solutions matérielles, telles que les jetons OTP, fournissent-elles une liaison dynamique avec des transactions uniques ?
En général, les utilisateurs peuvent saisir des informations de paiement, telles que le montant d'argent et le numéro de compte du bénéficiaire, dans des jetons matériels. Cela peut se faire via le clavier du token, via un câble USB ou en scannant un code visuel. Le jeton matériel peut ensuite utiliser les informations de paiement pour calculer un code d'authentification en fonction des exigences de liaison dynamique.
Le PSU doit-il voir les détails du paiement (montant et compte) sur le token ? Ce que vous voyez est ce que vous signez ?
« Voir ce que vous signez » sur les jetons matériels peut être utilisé pour se conformer à l'exigence de liaison dynamique, mais ce n'est pas la seule option. L'affichage des données dans une application mobile est également très probablement acceptable.
Pourriez-vous être plus précis sur les possibilités de signature/autorisation de transactions multiples ? La liaison dynamique permet-elle plusieurs transactions/bénéficiaires ?
Le projet final de RTS précise qu'en cas de paiements groupés, le code d'authentification doit être calculé sur le montant total des paiements, ainsi que des informations sur les bénéficiaires des différents paiements.
Le couplage dynamique est-il toujours nécessaire pour les paiements inférieurs à 30 euros en cas de mise en place d'une solution de suivi des transactions ?
Non, le couplage dynamique n'est pas requis pour les paiements inférieurs à 30 EUR, tant que le montant cumulé ou le nombre d'opérations de télépaiement antérieures initiées par le payeur depuis la dernière demande d'authentification forte du client n'excède pas respectivement 100 ou 5 EUR transactions individuelles consécutives de paiement électronique à distance.
Si des exemptions sont utilisées, est-il exact que la SCA au total peut être ignorée et pas seulement la liaison dynamique ?
C'est aussi notre compréhension.
Quelle est l'opinion de OneSpan sur le RTS pour les services bancaires aux entreprises ?
Le RTS sur SCA fournit des exigences de sécurité minimales pour l'authentification des utilisateurs. Dans le cas des services bancaires aux entreprises, les utilisateurs effectuent généralement des paiements de montants relativement élevés. Par conséquent, nous attendons des banques qu'elles protègent leurs applications bancaires d'entreprise avec des mécanismes d'authentification plus stricts que ceux requis par le RTS sur SCA.
Quelles sont les exigences si le client a déjà une liste de bénéficiaires certifiés avec SA mais doit effectuer un transfert d'argent avec une valeur différente ?
Comme indiqué à l'article 13 du projet final de RTS, la SCA n'est pas requise pour les paiements aux bénéficiaires de confiance. Pour les conditions précises, veuillez consulter l'article lui-même.
Le RTS permet l'authentification à un seul facteur uniquement après la première tentative. Le 2FA doit ensuite être utilisé tous les 9 jours. C'est différent de ce que vous avez recommandé dans le passé. S'il vous plaît, expliquez?
L'article 10 du projet final de RTS précise que les prestataires de services de paiement ne sont pas dispensés de l'application de l'authentification forte du client aux payeurs qui souhaitent s'informer sur leur solde ou consulter leur historique de paiement des 90 derniers jours si l'une des conditions suivantes est remplie :
- L'utilisateur de services de paiement accède pour la première fois en ligne au solde de son compte ou à l'historique des paiements des 90 premiers jours du paragraphe 1
- La dernière fois que l'utilisateur de services de paiement a accédé en ligne à son historique de paiement des 90 derniers jours du paragraphe 1 et l'authentification forte du client a été appliquée il y a plus de 90 jours.
Les paiements peuvent-ils être ajoutés à la liste blanche ? Si nous validons la destination pour la liste blanche et que nous autorisons ensuite les paiements sans DL vers cette destination, cela devrait-il être suffisant ?
L'article 13 du projet final de RTS permet au prestataire de services de paiement de ne pas procéder à une authentification forte du client si le payeur initie une opération de paiement où le bénéficiaire est inscrit sur une liste de bénéficiaires de confiance préalablement créée. Voir l'article 13 pour les détails.
OneSpan Mobile App Shielding doit-il être reconditionné avec l'application bancaire mobile chaque fois qu'il y a une mise à niveau de version ?
Il y a deux parties de cette question :
- Chaque fois que la PSP est sur le point de publier son application mobile sur le marché des applications, un blindage d'application doit être appliqué pour que l'application soit protégée. La bonne nouvelle est que le wrapping du blindage de l'application prend plusieurs secondes et n'affecte donc pas les cycles de publication des applications de la PSP.
- Étant donné que la solution OneSpan Mobile App Shielding est régulièrement mise à jour pour se défendre contre l'évolution des menaces mobiles, il est également recommandé aux PSP de protéger leurs applications avec la dernière version afin d'assurer le niveau de protection le plus élevé possible.
Le blindage des applications couvre-t-il la protection contre le clonage ?
OneSpan Mobile Security Suite fournit une fonction de liaison de périphérique qui offre une protection contre le clonage pour les applications mobiles.
Avez-vous besoin d'un blindage d'applications mobiles lorsque vous utilisez une solution SMS ? Application SIM ?
L'appareil mobile sur lequel le SMS arrive peut également contenir une application d'authentification (dans le scénario 1aa ou 2aa), où le SMS doit être saisi. Cette application devrait être protégée à l'aide d'un blindage d'application mobile.
Y a-t-il un problème de sécurité supplémentaire avec la mise en œuvre d'APP2APP par rapport au push ?
À notre avis, ce sont deux approches tout aussi sûres qui reposent en fin de compte sur la même technologie sous-jacente de canal de communication sécurisé. Nous les voyons être optimales avec différents modèles d'utilisation. De nombreuses banques mettront en œuvre l'application d'authentification qui fonctionnerait dans la configuration suivante :
Lorsque la transaction est initiée dans l'application bancaire mobile, le lien de communication App2App sera établi vers l'application d'authentification installée sur le même appareil. Cela offre la possibilité de basculer automatiquement entre deux applications, ce qui améliore l'expérience utilisateur.
Lorsque la transaction est initiée sur le navigateur web depuis un autre appareil (PC ou tablette), la notification PUSH sera envoyée vers l'application d'authentification installée sur l'appareil mobile de l'utilisateur. Alternativement, avec presque la même expérience utilisateur, le processus de numérisation et de signature optique peut être utilisé.
Vous pouvez trouver plus d'informations sur les solutions Cronto ici : Signe Cronto
Pour App2App avec canal de communication sécurisé, l'échange de données entre les applications se fait via le backend dans un format crypté.
La plate-forme Windows universelle (UWP) et les tablettes Windows sont-elles une plate-forme de solution viable pour SCA dans une configuration 2AA ou 1AA ? Le sandboxing est-il différent entre iOS et Android ?
Les techniques de sandboxing de la plate-forme Windows universelle (UWP) sont similaires à celles d'Android et d'iOS. UWP a adopté de nombreux concepts d'Android et d'iOS. Windows 10 Mobile n'autorise que l'exécution d'applications UWP, de sorte que les mécanismes de sandboxing sont d'une force comparable à celle d'Android et iOS ici. Windows 10 standard permet d'exécuter à la fois des applications UWP et Windows standard, de sorte que le sandboxing est moins puissant qu'Android ou iOS.
Lorsque la transaction est initiée à partir de TPP APP, lequel des cas d'utilisation présentés semble le plus susceptible d'être utilisé ?
Lorsque l'utilisateur utilise une application TPP, nous voyons très probablement l'un des trois cas d'utilisation suivants :
- Notification PUSH de la banque à l'application d'authentification fournie par l'institution financière. Cela ne nécessite pas d'intégration spécifique entre les parties.
- Communication App2App entre une application TPP et une application d'authentification fournie par l'institution financière. Cela nécessite une intégration minimale du service d'authentification entre le TPP et l'institution financière.
- Cadre de sécurité mobile intégré dans l'application TPP. Cela implique que le TPP ne s'appuiera pas sur la mise en œuvre de l'authentification par l'institution financière mais fournira la sienne.
Dans les trois options, les TPP et les institutions financières devront collecter les données d'entrée des appareils des utilisateurs et effectuer une analyse approfondie sur plusieurs applications, canaux et points de terminaison pour une évaluation complète des risques. La meilleure option consiste à mettre en œuvre un logiciel de gestion des risques dédié, tel que OneSpan Risk Analytics, qui fournit :
- Détection en temps réel des fraudes sophistiquées
- Traitement de grandes quantités de points de données pour détecter les comportements anormaux des utilisateurs, les transactions suspectes et la navigation atypique dans l'application de paiement
- Notation précise des risques et atténuation des menaces sur tous les appareils mobiles courants (par exemple, téléphones mobiles et tablettes)
- Opérations invisibles pour les utilisateurs finaux, limitant la fraude tout en offrant la meilleure expérience utilisateur possible
Si l'authentification à deux applications est utilisée, les deux applications mobiles doivent-elles utiliser le système d'exploitation sandbox et le blindage des applications mobiles ?
Le sandboxing est appliqué par le système d'exploitation (par exemple Android ou iOS) de l'appareil mobile à chaque application exécutée sur l'appareil. Le blindage des applications mobiles doit être appliqué à l'application d'authentification.
Le SDK digipass est-il disponible/compatible avec nativescript ?
Oui, c'est le cas.
Pourriez-vous développer la communication sécurisée offerte par OneSpan Mobile Security Suite ? Qu'est-ce qui est utilisé pour le sécuriser? Qu'est-ce qui est requis sur le serveur ?
La fonctionnalité de communications sécurisées de OneSpan Mobile Security Suite offre la possibilité de créer un canal de communication sécurisé entre l'application et le serveur, protégeant la confidentialité, l'intégrité et l'authenticité de toutes les informations de paiement. OneSpan Mobile Security Suite est fourni avec des SDK côté client et côté serveur pour établir le canal sécurisé. De cette façon, les PSP peuvent facilement configurer un canal sécurisé sans avoir à gérer eux-mêmes la complexité du canal sécurisé.
Si l'identifiant matériel, l'empreinte digitale et le code PIN doivent être combinés pour une application, existe-t-il une recommandation pour un algorithme HMAC ?
Nous vous recommandons d'utiliser des algorithmes HMAC standard, tels que HMAC-SHA256 ou HMAC-SHA3.
Pour être conforme à la situation 2AA, les deux applications doivent-elles être protégées par un blindage d'application mobile ? Ou seulement l'application d'authentification ?
L'application d'authentification doit être protégée par un blindage d'application mobile. L'application bancaire peut être protégée, mais elle n'est pas requise dans le projet final de RTS.
Comment voyez-vous l'utilisation des paramètres comportementaux comme facteurs d'authentification ?
Oui, nous voyons cela comme un élément d'inhérence possible. Les commentaires de l'ABE sur le projet final de RTS indiquent également que cela est possible.
OneSpan a-t-il une solution pour utiliser le facteur « inhérence » (biométrie) comme élément d'authentification ?
Oui, OneSpan Mobile Security Suite prend en charge l'authentification biométrique basée sur les empreintes digitales, le scan du visage et le comportement de l'utilisateur.
Pouvez-vous discuter de TRA pour les paiements groupés ?
En cas de paiements groupés, le code d'authentification pour SCA doit être calculé sur la base du montant total de tous les paiements combinés et sur la base des numéros de compte de tous les bénéficiaires. Il n'y a pas de dispositions spécifiques concernant la TRA pour les paiements groupés.
Une solution de prévention OneSpan peut-elle regrouper tous types de transactions, notamment : e-banking, carte, pos, mobile banking, wallets etc. ?
Oui, OneSpan Risk Analytics peut être utilisé pour analyser les transactions pour différents types de canaux de paiement.
La solution OneSpan est-elle une solution basée sur le cloud ? Et si oui, privé ou public ?
OneSpan Risk Analytics est disponible sur site ainsi que dans le cloud. La version cloud est hébergée par OneSpan.
OneSpan Risk Analytics est-il conforme aux exigences RTS ?
Oui, OneSpan Risk Analytics peut effectuer une analyse des risques de transaction conformément aux exigences de la version finale du RTS.
Tous les PSP nécessitent-ils une TRA, même s'ils prévoient d'utiliser SCA pour toutes les transactions ? Si oui, quelle est la justification de cette exigence?
En effet, les PSP doivent toujours utiliser TRA même s'ils utilisent SCA. TRA fournit une deuxième couche de sécurité à côté de SCA. TRA est utile pour se protéger contre les attaques d'ingénierie sociale, par lesquelles un adversaire essaie de convaincre l'utilisateur réel de confirmer un paiement à l'aide de SCA lorsque le paiement est réellement frauduleux.
Les directives ou lignes directrices définissent-elles certains mandats pour les solutions 2AA et 1AA en cas de perte ou de vol du support physique ?
Le projet final de RTS indique que la procédure d'authentification devrait inclure, en général, des mécanismes de surveillance des transactions pour détecter les tentatives d'utilisation des informations d'identification de sécurité personnalisées d'un utilisateur de services de paiement qui ont été perdues, volées ou détournées. Cela s'applique à toutes les solutions d'authentification, pas seulement à celles de la catégorie 2aa ou 1aa.