DSP3 – De la DSP2 au Règlement sur les services de paiement (RSP) : analyse comparative (Partie 2)

1. Service de rapprochement (matching) entre le nom et l’identifiant unique du bénéficiaire (art. 50)

• Contexte : 

– Le législateur européen relève que les payeurs ayant l’intention d’envoyer un virement à un bénéficiaire donné peuvent, à la suite d’une fraude ou d’une erreur, fournir un identifiant unique qui ne correspond pas à un compte détenu par ce bénéficiaire (considérant 70) ; 

– En effet, certaines caractéristiques du nom du bénéficiaire peuvent accroître la probabilité qu’une divergence soit détectée par le PSP, notamment la présence de signes diacritiques (accents aigu, grave et circonflexe, tréma et cédille) ou de différentes translittérations possibles des noms dans différents alphabets, les différences entre les noms habituellement utilisés et les noms indiqués sur les documents d’identification officiels (personnes physiques) ou les différences entre les noms commerciaux et juridiques (personnes morales) (considérant 72) ; 

– Afin de contribuer à la réduction des fraudes et des erreurs, les utilisateurs de services de paiement devraient bénéficier d’un service qui vérifierait s’il existe une divergence entre l’identifiant unique du bénéficiaire et le nom du bénéficiaire fourni par le payeur et, si de telles divergences devaient être détecté, informer le payeur (considérant 70). 

– Ce service de concordance entre le nom d’un bénéficiaire et l’IBAN est déjà fourni dans certains pays, à l’instar des Pays-Bas ou du Royaume-Uni (service de Confirmation of Payee) qui garantit qu’avant d’autoriser un paiement, les payeurs sont informés du degré de concordance entre le nom et l’IBAN du bénéficiaire. Le payeur décide, sur la base des commentaires reçus (divergence ou concordance étroite ; en cas de concordance totale, il n’y a normalement pas de notification), s’il faut procéder au virement. La Commission Européenne relève que ces services, dans les pays où ils existent, ont eu un impact positif substantiel sur le niveau de fraude et d’erreurs.

• Définition : dans un objectif de protection du payeur, une exigence d’un système de « confirmation du bénéficiaire » appelé « service de rapprochement » (matching) est introduite à l’art. 50 du RSP pour les virements non-instantanés où le payeur saisit lui-même l’identifiant unique et le nom du bénéficiaire. Cette exigence vise à détecter les écarts entre le nom et l’identifiant unique d’un bénéficiaire en cas de virement. Ce service est fourni pour les ordres de paiement passés via des canaux électroniques d’initiation de paiement et via des ordres de paiement non électroniques impliquant une interaction en temps réel entre le payeur et le PSP du payeur. 

• Fonctionnement : 

– Gratuité du service : ce service doit être fourni gratuitement par le PSP du bénéficiaire. Celui-ci, à la demande du PSP du donneur d’ordre, devra vérifier si l’identifiant unique et le nom du bénéficiaire fournis par le donneur d’ordre correspondent ou non, et communiquer le résultat de cette vérification au PSP du donneur d’ordre. Si l’identifiant unique et le nom du bénéficiaire ne concordent pas (absence de match), le PSP du payeur doit notifier au payeur tout écart constaté et informe le payeur de l’ampleur de cet écart ;

– Moment de fourniture de ce service : Les PSP devront fournir ce service immédiatement après que le payeur a fourni à son PSP l’identifiant unique et le nom du bénéficiaire, et avant que le payeur ne se voie offrir la possibilité d’autoriser le virement.

– Détection et notification d’une anomalie : la détection et la notification d’une anomalie ne devront pas empêcher les payeurs d’autoriser le virement concerné. Si le payeur autorise le virement, après avoir été informé d’une anomalie, et que la transaction est exécutée conformément à l’identifiant unique fourni par le payeur, cette transaction est réputée avoir été exécutée correctement ;

– Information de l’utilisateur : le PSP devra informer l’utilisateur que l’autorisation d’une transaction nonobstant la détection d’une anomalie, ou que le refus de ce service (opt-out), peut entraîner le transfert des fonds vers un compte de paiement non détenu par le bénéficiaire indiqué par le payeur ; 

• No match ou close match : afin d’éviter des frictions dans le traitement des virements et de faciliter la décision du payeur de procéder ou non à l’opération envisagée, les PSP devraient indiquer le degré de cet écart en indiquant dans la notification s’il y a un “no match” ou un “close match”.

• Opt-in et opt-out (art.50.4) : l’utilisateur de services de paiement a le droit de refuser ce service (opt-out) et le PSP doit informer l’utilisateur de ce droit. Mais l’utilisateur qui a initialement choisi de ne pas recevoir ce service doit avoir la possibilité de choisir de recevoir ce service (opt-in). 

2. Limites de dépenses convenues (art. 61.2 et 61.3) : 

S’agissant des paiements dont le montant de la transaction n’est pas connu à l’avance , le RSP ajoute deux nouvelles dispositions à celles prévues dans la DSP2 (art. 75). Ainsi est-il prévu que le montant des fonds bloqués par le PSP du payeur doit être proportionnel au montant de l’opération de paiement auquel le payeur peut raisonnablement s’attendre, et que le bénéficiaire doit informer son PSP du montant exact de l’opération de paiement immédiatement après la livraison du service ou du bien au payeur. 

3. Responsabilité du PSP : 

Les dispositions relatives à la notification et à la rectification des opérations de paiement non autorisées ou mal exécutées, aux exigences en matière d’information et au droit de recours sont mises à jour afin de refléter la nouvelle disposition relative à la responsabilité en cas d’application incorrecte du service de service de rapprochement (matching) : 

• Opérations de paiement non autorisées : une nouvelle disposition est introduite à l’art. 56.2 du RSP en cas de fraude commise par le payeur. Lorsque le PSP du payeur avait des motifs raisonnables de soupçonner une fraude commise par le payeur, alors celui-ci doit dans les 10 jours ouvrables suivant la constatation ou la notification de l’opération:

– Rembourser au payeur le montant de l’opération de paiement non autorisée (si le PSP du payeur conclut, après une enquête approfondie, qu’aucune fraude n’a été commise par le payeur) ; 

– Justifier le refus du remboursement. Si le payeur n’accepte pas les motifs invoqués, alors le PSP devra  indiquer les instances que le payeur peut saisir.

• Responsabilité du PSP en cas d’application incorrecte du service de rapprochement (matching) (art. 57): le payeur ne doit subir aucune perte financière pour tout virement autorisé lorsque le PSP du payeur a omis de notifier au payeur une divergence détectée entre l’identifiant unique et le nom du bénéficiaire fournies par le payeur. De plus, le PSP du payeur doit rembourser l’intégralité du montant du virement autorisé dans les 10 jours, ou fournir des justificatifs du refus (et indiquer les instances que le payeur peut saisir si ce dernier n’accepte pas les motifs du PSP). En revanche, si cette non-conformité est imputable au PSP du bénéficiaire, alors celui-ci doit rembourser le préjudice financier subi par le PSP du payeur (art. 57.3). Naturellement, le payeur ne bénéficie pas du remboursement en cas de fraude de sa part ou en cas d’opt-out (art. 57-4). L’articulation de ces règles de responsabilité entre les PSP des payeurs et des bénéficiaires fera probablement l’objet de contentieux à l’avenir. 

• Fraude par usurpation d’identité (spoofing) (art. 59) – un nouveau cas de responsabilité de PSP en cas de spoofing est introduit dans le RSP : 

– Remboursement : en cas manipulation d’un utilisateur de service de paiement (qui doit être un consommateur en l’espèce) par un tiers se faisant passer pour un employé du PSP qui autorise l’exécution d’une opération de paiement, alors le PSP devra rembourser le montant correspondant. Mais sous réserve que le consommateur effectue un signalement, sans délai, aux services de police et notifie le PSP (art. 59.1) ;

– Délai de remboursement ou refus de remboursement : dans les 10 jours ouvrables suivant la constatation ou la notification de l’opération de paiement autorisée frauduleuse, le PSP devra soit rembourser le consommateur du montant de l’opération de paiement autorisée frauduleuse, soit refuser le remboursement s’il a des motifs raisonnables de soupçonner une fraude ou une négligence grave du consommateur. Dans ce cas, le PSP devra justifier son refus et indiquer au consommateur les instances qu’il pourra saisir (si le consommateur n’accepte pas les motifs du PSP) ; 

– Collaboration avec les opérateurs de communication électroniques : lorsqu’un PSP informe un opérateur de communications électroniques de la survenance d’un spoofing, ce dernier doit coopérer avec le PSP et agir rapidement pour s’assurer que des mesures organisationnelles et techniques appropriées sont mises en place pour préserver la sécurité et la confidentialité des communications (art. 59.5).

4. Authentification forte (SCA – Strong Customer Authentication)

Il convient de relever que les dispositions des RTS sur l’authentification forte (RTS SCA) ont été intégrées dans le RSP. La clarification des règles en matière de SCA ainsi que la suppression des divergences résultant de la transposition nationale d’une directive contribueront à la simplification de ces exigences. 

• Définition précisée (art. 85.12) : les facteurs sur lesquels se fonde l’authentification forte (SCA) du client (au moins 2 facteurs parmi les 3 suivants : possession, connaissance, inhérence) ne doivent pas nécessairement appartenir à des catégories différentes, pour autant que leur indépendance soit pleinement préservée. En cela, le RSP prend le contrepied exact de l’ABE (Q&A 2020_5619) pour qui les deux éléments d’authentification « doivent appartenir à deux catégories différentes » et, toujours selon l’ABE, “les PSP devraient appliquer le SCA en utilisant au moins deux éléments indépendants de catégories différentes. Toutefois, PSD2 et le règlement délégué n’empêchent pas les PSP d’appliquer un élément supplémentaire des mêmes catégories à l’un des éléments déjà appliqués en tant que mesure de sécurité supplémentaire ».

• Responsabilité des prestataires de services techniques & schemes de paiement

– Les prestataires de services techniques et les opérateurs de schemes de paiement qui fournissent des services au bénéficiaire, au PSP du bénéficiaire ou au payeur, peuvent désormais être tenus pour responsables en cas de manquement (dans leur relation contractuelle) à fournir les services nécessaires pour permettre le SCA du client (art. 58). Cette disposition vise sans doute à adresser un pain-point pratique de la DSP2, à savoir le retard pris dans l’application du SCA pour les transactions par carte à distance (dû au fait que ces entités n’étaient pas agrées en tant que PSP et n’avaient donc pas l’obligation de réaliser un SCA).

• Cas dans lesquels le SCA doit être appliqué : le RTS prévoit l’application du SCA dans 4 cas, contre 3 dans la DSP2, avec une reformulation dans un cas : 

• Précisions des cas dans lesquels le SCA n’est pas applicable : 

– Transactions initiées par le bénéficiaire (art. 85.2) : le SCA n’est pas applicable  aux transactions initiées par le bénéficiaire dans la mesure où ces opérations sont initiées sans aucune interaction ou implication du payeur ; 

– SCA & mandat : le RSP (art. 85.3) rappelle que lorsque le payeur donne mandat au bénéficiaire pour une opération ou une série d’opérations de paiement, les opérations de paiement initiées ultérieurement par le bénéficiaire sur la base d’un tel mandat peuvent être qualifiées d’opérations initiées par le bénéficiaire, à condition que ces opérations ne soient précédées d’une action spécifique du donneur d’ordre pour déclencher leur initiation par le bénéficiaire. En revanche, lorsque le mandat du donneur d’ordre au bénéficiaire est fourni via un canal à distance avec la participation du PSP, la mise en place d’un tel mandat est soumise au SCA (art. 85.5). Le même principe s’applique spécifiquement aux prélèvements (art. 85.6). En cela, le RSP confirme l’approche de l’ABE (Q&A 2019_4664) ; 

– SCA & MOTO (mail orders or telephone orders) : le SCA ne s’applique pas pour les ordres de paiement sur support papier, les opérations par correspondance ou par téléphone, à condition que les exigences de sécurités et des contrôles soit mis en place par le PSP du payeur permettant une forme d’authentification de la transaction (art. 85.7) ; 

– SCA & NFC (art. 85.9) : Un “ordre de paiement passé  par l’intermédiaire d’un appareil du payeur utilisant une technologie de proximité pour l’échange d’informations avec l’infrastructure du bénéficiaire dont l’authentification nécessite l’utilisation d’internet sur l’appareil du payeur” (en l’espèce, il s’agit du recours à la technologie NFC) requiert l’application d’un SCA par les PSP qui doit comprendre des éléments qui lient dynamiquement la transaction à un montant spécifique et à un bénéficiaire spécifique ou des mesures de sécurité harmonisées d’effet identique, qui garantissent la confidentialité, l’authenticité et l’intégrité du montant de la transaction et du bénéficiaire tout au long toutes les phases de l’initiation. Sous l’empire de la DSP2, les transactions NFC ne devaient pas nécessairement faire l’objet d’un SCA puisqu’elles pouvaient bénéficier de certaines exemptions.

– SCA & PSIC : Pour rappel (cf. partie I de notre analyse, §8), le RSP introduit un important changement comparativement à la DSP2 au sujet de l’application du SCA par les PSIC. En effet, alors que sous la DSP2 le PSPGC était en charge d’effectuer le SCA sur l’utilisateur lorsque ce dernier accédait aux informations du compte de paiement via un PSIC, désormais avec le RSP (art. 86) le PSIC devra effectuer le SCA sur l’utilisateur tous les 180 jours (sauf si le PSPGC soupçonne une fraude). Ce n’est que lors du premier accès aux données du compte de paiement par un PSIC que le PSPGC effectuera une SCA (art. 86.3).

– SCA & Externalisation (art. 87) : Une disposition dans le RSP oblige expressément les PSP et les prestataires techniques à conclure des accords d’externalisation dans les cas où ces derniers fournissent et vérifient les éléments du SCA du client. Des RTS de l’ABE sont prévues au sujet de l’externalisation (art.89.1.d). Il faut relever que ce point n’était pas expressément prévu dans la DSP2. Toutefois, en pratique, de nombreux PSP avaient recours à un tiers pour effectuer le SCA car l’implémentation d’outils/systèmes en interne pour mettre en œuvre le SCA se révélait assez coûteux. Le RSP vient donc entériner une pratique de marché.

– ABE : toute exemption à l’application du SCA doit être fondé par l’ABE sur un ou plusieurs critères suivants : (i) le niveau de risque lié au service fourni, (ii) le montant et/ou la récurrence de la transaction, (iii)  le canal de paiement utilisé pour l’exécution de la transaction (art. 85.11).

• Accessibilité du SCA (art. 88) : on peut saluer une importante nouveauté du RSP dans un objectif d’accessibilité et d’inclusion bancaire : les PSP devront veiller à ce que leurs clients (y compris les personnes handicapées, âgées, ayant de faibles compétences numériques et ceux qui n’ont n’ont pas accès aux chaînes numériques ou instruments de paiement), disposent d’au moins un moyen adapté à leur situation particulière leur permettant d’effectuer un SCA.  De plus, le PSP ne devra pas conditionner la performance du SCA de l’utilisation exclusive d’un seul moyen d’authentification ni (explicitement/implicitement) de la possession d’un smartphone. Il faudra que la PSP développe une diversité de moyens d’application du SCA pour répondre à la situation spécifique de tous les clients. Il faut donc s’attendre soit à des développements en interne par le PSP, soit au recours à un prestataire technique pour effectuer le SCA en vertu d’un contrat d’externalisation.

• SCA & création d’un token (considérant 118) : le législateur européen relève que les acteurs du marché ne comprennent pas de manière cohérente les exigences de la SCA applicables à l’inscription des instruments de paiement, en particulier les cartes de paiement, dans les wallets électroniques. La création d’un token ou son processus de remplacement peut entraîner un risque de fraude au paiement ou d’autres abus. La création ou le remplacement d’un token d’un instrument de paiement  via un canal à distance avec la participation de l’utilisateur de services de paiement devrait donc nécessiter l’application de la SCA par le PSP de l’utilisateur de services de paiement au moment de l’émission ou le remplacement du token. En appliquant la SCA au stade de la création ou du remplacement du token, le PSP doit vérifier à distance que l’utilisateur du service de paiement est l’utilisateur légitime de l’instrument de paiement et associer l’utilisateur et la version numérisée de l’instrument de paiement à l’appareil respectif.