DSP2 : aller au-delà de la conformité vers de nouvelles opportunités numériques

2

La directive DSP2 représente un double défi pour les banques. Premièrement, le défi technique du respect des RTS (normes techniques réglementaires). Deuxièmement, le défi commercial de passer à un environnement dans lequel les services sont organisés autour des besoins des clients, qui vient remplacer un environnement organisé autour des processus bancaires.

C’est une nouvelle perspective par rapport à l’objectif initial de la DSP2, qui était d’étendre l’écosystème de paiements de l’Espace économique européen. La directive DSP2 couvre tous les types de paiements électroniques autres que les espèces, soit les virements, les prélèvements, les paiements par carte, les paiements en ligne et via les mobiles. Elle vise également à renforcer la sécurité des données et la protection des consommateurs.

En outre, elle annonce l’émergence d’une nouvelle catégorie d’acteurs, les «.prestataires de services de paiement ». Dans le cadre de la DSP2, ces prestataires doivent garantir un service rapide et efficace, apporter l’information aux consommateurs, et indemniser les consommateurs en cas de défaut dans la prestation de services.

Jusqu’à présent, les systèmes de paiement étaient gérés soit par les banques (qui assuraient l’intégralité de la chaîne de valeur de bout en bout), soit par des sous-traitants. Ces systèmes reposaient sur deux acteurs principaux : le PSU (Payment

Service User ou utilisateur de services de paiement) et le ASPSP (Account Servicing

Payment Service Provider ou prestataire de services de paiement gestionnaire de compte).

Cette situation évolue. La directive initiale, DSP1, a créé les établissements de paiement et les établissements de monnaie électronique. Désormais, la DSP2 y ajoute des prestataires tiers spécialisés dans les AIS (Account Information Service Provider ou services d’information sur les comptes) et dans les PIS (Payment Initiation Service ou services d’initiation de paiement). Ces évolutions font émerger un écosystème des paiements entièrement recomposé, dans lequel les nouveaux arrivants bénéficient d’un cadre réglementaire différent de celui des banques en place, et qui permet aux acteurs d’assembler des services de paiement pour offrir de nouvelles expériences à leurs clients.

Dans ce nouvel écosystème, les banques font face à un véritable défi pour se conformer à la DSP2, notamment par le fait que la période de transition devrait commencer dès janvier 2018. Mais les banquiers qui ont une capacité de vision stratégique savent très bien que la conformité n’est qu’une première étape. Ils constatent que la DSP2 crée également de nouvelles pressions concurrentielles en permettant aux acteurs non bancaires d’initier des paiements et de fournir des

D’un point de vue stratégique, la conformité à la directive européenne DSP2 (2e Directive sur les services de paiement) est une première étape. Les banques capables d’innover et de se transformer vont pouvoir tirer bénéfice de ce nouvel écosystème de paiements.

DSP2 : aller au-delà de la conformité vers de nouvelles opportunités numériques Une évolution majeure

Livre blanc

Sommaire

Une évolution majeure 2

Le client est désormais au centre 3

Puissance des API 4

Questions de sécurité 6

DXC peut vous aider... 6

Paiements – Abréviations et définitions

AIS : Account Information

Service (Service d’information

sur les comptes). Génère une

vue consolidée de l’ensemble

des comptes à partir d’une

interface unique.

API : Application Programming

Interface (interface de

programmation). Permet aux

logiciels de communiquer entre eux

et de partager des données (voir

également M2M).

ASPSP : Account Servicing

Payment Service Provider

(prestataire de services assurant la

tenue de comptes courants).

Détient les comptes par l’entremise

desquels les PSU peuvent effectuer

des paiements.

EBA/ABE : European Banking Authority (Autorité bancaire européenne). Autorité indépendante de l’Union européenne (UE) qui s’efforce d’assurer une réglementation et un contrôle efficaces et cohérents dans l’ensemble du secteur bancaire européen.

GDPR/RGPD : General Data Protection Regulation (Règlement général sur la protection des données). Règles édictées par l’UE pour protéger les données des consommateurs (entrée en vigueur mai 2018).

IAM : Identity Access Management

(gestion des identités et des accès).

Logiciel qui garantit que seules les

bonnes personnes puissent accéder

aux bonnes données, au bon

moment et pour les bonnes raisons.

3

Livre blanc

IoT : Internet of Things (Internet

des objets). Interconnexion

d’équipements physiques, de

bâtiments, de véhicules et

autres pour collecte et échanges

de données.

M2M : Machine-to-Machine (de

machine à machine). Interactions

entre deux applications (ou plus),

exécutées via des API et sans

intervention humaine.

PFM : Personal Financial

Management (gestion des

finances personnelles). Logiciel

qui aide les utilisateurs à gérer

leur argent.

PSD2/DSP2 : Payment Services

Directive 2 (Directive sur les

services de paiement 2). Directive

révisée pour les paiements autres

qu’en espèces dans l’Union

européenne, en Islande, en

Norvège et au Liechtenstein.

PIS : Payment Initiation

Service (service d’initiation des

paiements). Permet aux clients

de demander à un tiers

d’effectuer des opérations de

paiement en leur nom.

PSP : Payment Service Provider

(prestataire de services de

paiement). Entreprise qui

propose des services en ligne

aux commerçants qui

souhaitent accepter les

paiements électroniques.

PSU : Payment Service User (utilisateur d’un service de paiement).

RTS : Regulatory Technical

Standard (norme technique

réglementaire).

SCA : Strong Customer

Authentication (authentification

client forte). Couverte par les

normes RTS dans la DSP2.

TPP : Third Party Provider

(prestataire tiers). Initie les

paiements et fournit une vue

consolidée des utilisateurs du service

de paiement, mais sans détenir de

fonds ou de comptes gérés.

services sur la base de données de transactions agrégées. Par ailleurs, la directive crée un environnement dans lequel, de plus en plus souvent, les clients ne se limitent plus aux services d’une seule banque, mais de plusieurs.

Heureusement, la directive DSP2 fait également apparaître de nouvelles opportunités : elle ouvre la voie à de nouveaux produits et services, de nouveaux clients et partenaires, de nouvelles technologies et de nouvelles sources de revenus potentiels.

Le client désormais au centre

La DSP2 fait également entrevoir un autre changement dans l’environnement bancaire, celui de la relation entre le client et la banque. Dans le passé, il s’agissait d’une relation individuelle : le client traitait avec une seule banque qui lui proposait une gamme complète de produits et de services bancaires. Aujourd’hui, en revanche, la relation est d’un à plusieurs : les clients n’interagissent plus avec une seule banque, mais avec plusieurs. Et les banques deviennent des fournisseurs multiples dans un modèle en étoile où c’est le client – et non, comme par le passé, la banque – qui est au centre.

En outre, des acteurs émergents ont la capacité de combiner et d’agréger plusieurs services bancaires pour créer des offres innovantes. Ces intermédiaires modifient ainsi la relation entre les clients et les banques. Dans le passé, un client se fournissait généralement en produits et en services directement auprès d’une seule banque. Aujourd’hui et à l’avenir, il ira chercher de plus en plus les nouveaux produits et services bancaires auprès de ces intermédiaires agrégateurs. Il profitera également de nouvelles expériences client, comme des paiements optimisés intégrés dans son parcours d’utilisateur. D’autres services pourront être axés sur des besoins spécifiques des clients, comme l’arrondi des paiements à l’euro près pour se constituer une épargne, ou de nouveaux outils de personnalisation, tels que des limites de paiement à la demande et le contrôle des paiements hors ligne à l’aide d’un commutateur Marche/Arrêt. Toutes ces perspectives font apparaître un univers passionnant fait de nouveaux services centrés sur des segments de clientèle spécifiques.

Pour les banques, cette transformation présente également de nouveaux défis, le principal étant de savoir comment maintenir la relation avec l’utilisateur final compte tenu de l’irruption de nouveaux acteurs. Par exemple, une banque pourra décider d’intégrer l’offre d’une FinTech qu’elle vient d’acquérir, développer des partenariats avec d’autres prestataires de services de paiement ou fournir ses services en marque blanche.

Un second (mais néanmoins important) objectif est celui de devenir fournisseur privilégié de ces nouveaux acteurs d’intermédiation bancaires. Une préoccupation à ne pas négliger est alors celle de la monétisation, qui vise à trouver le niveau de frais qu’une banque peut obtenir de ses intermédiaires pour les services non réglementés qu’elle leur offre.

La sécurité et la confidentialité sont également importantes pour les clients. Ceci est particulièrement vrai à la suite de plusieurs compromissions de données de grande ampleur survenues récemment dans des organisations financières internationales et des agences de notation. Par ailleurs, les banques doivent se préparer dès maintenant à se conformer au règlement général sur la protection des données de l’Union européenne (RGPD), qui doit entrer en vigueur en mai 2018.

Encore une autre préoccupation : certaines banques devront numériser l’intégralité de leurs opérations. L’automatisation de la relation client n’est que le début. De nouveaux

4

Figure 1 - Introduction aux API. Une API « Application

Programming Interface » est une

interface qui permet à une

application d’offrir des services

à une autre application via un

standard d’échange de données.

La transmission de données

• Une API est caractérisée par la façon dont l’information est transmisede façon sécurisée

• La plupart des API utilisentles protocoles HTTP et HTTPS pour le transport des information

Le format d’échange

• Une API est caractérisée par le format d’échangedes données.

• Le format le plus courantest XML ou JSON . XML a plus de fonctionnalités,mais JSON permet des échanges plus rapides

La gestion d’accès

• Une API est caractériséepar la façon de s’authentifier pour accéder aux données

• Les standards les plus populaires sont le SAML etl’OAuth 2.0.

L’architecture

• L’architecture d’une API peut être REST (Representational State Transfer) ou SOAP (SimpleObject Access Protocol).

• SOAP est plus complexe mais plus populaire , REST est plus orienté performance et scalabilité

Les caractéristiques techniques des API

outils internes devraient également jouer un rôle crucial, sur fond d’interactions de M2M (Machine-to-Machine - machine à machine). On peut notamment citer :

• Commerce contextuel : les paiements sont intégrés dans le parcours utilisateur, etfinalisent l’achat de produits et services en fonction du comportement et du contextedu client. Finalement, le client n’est pas à la recherche d’un moyen de paiement pourun produit ou un service, mais bien de la possibilité d’utiliser ce produit ou ce service.

• Plateformes : alors que Google, Apple, Facebook, Amazon et d’autres acteurss’installent de plus en plus sur le devant de la scène numérique, les banques doivents’interroger sur leur présence dans ce paysage. Certains établissements nonbancaires pourront également initier des paiements dans le cadre de la DSP2, ce quiexercera une pression concurrentielle supplémentaire sur les banques traditionnelles.

• Agents intelligents : les assistants activés par la voix comme Alexa d’Amazon et Sirid’Apple, ainsi que les chatbots (programmes logiciels qui simulent une conversationhumaine), pourraient bien devenir les nouvelles interfaces de base des plateformesde paiement. Dans cette perspective, les banques devront intégrer des agentsintelligents dans leurs produits et services de paiement, permettant d’offrir auxclients de nouveaux types d’interfaces. Certains projets de ce type sont déjà en coursde réalisation. Par exemple, Bank of America a déployé un chatbot mobile appeléErica, conçu pour aider les clients à mieux gérer leur argent.

Puissance des API ouvertes

La technologie à base d’API ouvertes facilite la mise en conformité à la DSP2 dans un cadre structuré et facile à gérer. Des réflexions sont en cours pour étudier dans quelle mesure la mise en œuvre d’API ouvertes pour la DSP2 peuvent s’accompagner d’une interdiction du web scraping.

Les interfaces API permettent à une application d’offrir des services (des fonctionnalités) à d’autres applications selon un format et un protocole d’échange défini. La puissance de ces interfaces réside en partie dans leur capacité à exécuter des opérations sur base des données échangées, à associer des formats à ces échanges, à superviser les accès et à définir une architecture (Figure 1).

4

Livre blanc

Figure 2. Types d’API

API Privée

• Conçue pour des échanges entre deux applications au sein d’unmême établissement

API Partenaire

Ouverte à des partenaires de confiance sélectionnés, suite à des accords bilatéraux.

API Communautaire Règlementé

• Accessible à tous les tiersen conformité à certainscritères prérequis

• Les conditions et lestermes d’utilisationsdoivent être acceptés parles utilisateurs tiers

• Garantit la sécurité desdonnées

API Publique

• Ouverte à tout le monde

• Les utilisateurs peuvent nepas s’enregistrer pour les utiliser

Utilisée par les banques au sein de leur SI

Utilisé par les banques pour l’OpenData

Utilisée par les banques (cas des ERP, CRM..)

Satisfait les conditions et les critères de la DSP2

Niveau d’ouverture

Les API sont essentielles pour le nouvel environnement de paiement. Les banques vont devoir exposer des services aux prestataires tiers (TPP) à destination des utilisateurs des services de paiement, et certaines banques pourraient elles-mêmes devenir des prestataires tiers. Les API ouvertes permettent à des tiers agréés, extérieurs à une banque, de créer des applications qui exploitent les données et les services de cette banque. L’API peut également permettre de transmettre des messages marketing en mode push, fournir des informations sur les transactions d’un client, initier un paiement ou effectuer une transaction, ou encore renvoyer un message au système central d’une banque.

Les API ouvertes ont un vrai potentiel de transformation des paiements. Elles permettent d’exposer les données bancaires et les architectures système sous un jour entièrement nouveau en créant un « écosystème ouvert » qui expose à des tiers les données internes et les services disponibles. Il existe quatre grands types d’API (Figure 2). De la moins ouverte à la plus ouverte, les niveaux de confidentialité de ces API sont les suivants : privé, partenaire, communautaire réglementé et public. Chacune de ces API correspond à des besoins spécifiques avec ses propres avantages et inconvénients.

Ceci génère de nouvelles opportunités. De nouveaux modèles commerciaux peuvent être créés comme par exemple des API de paiement intégrées aux objets IoT (Internet des objets), des services bancaires à la carte, le paiement à l’usage, et des services bancaires personnalisés sur mobiles. Les API peuvent également ouvrir de nouveaux marchés, par exemple la distribution de produits bancaires par l’intermédiaire de partenaires et de plateformes ou l’intégration avec des agents logiciels et avec les médias sociaux. De nouveaux usages des données deviennent possibles, par exemple une vue complète en temps réel de la situation financière d’un client dans toutes ses banques et tous ses fournisseurs. Des applications pourront être trouvées pour le crédit, le risque, des ventes croisées et des offres ciblées. Enfin, les API ouvertes peuvent favoriser le développement de nouveaux produits, avec par exemple des solutions de paiement à la livraison, ou PFM (Personal Financial Management ou gestion des finances personnelles).

5

Livre blanc

Pour être sécurisées, les API ouvertes vont confronter les banques à de nouveaux domaines de responsabilité. Les API permettent les méthodes d’authentification forte exigées par la DSP2 pour donner la possibilité de gérer les relations avec les utilisateurs finaux par l’intermédiaire de prestataires tiers. Leur mise en œuvre devra s’accompagner d’une réflexion sur l’harmonisation des méthodes d’authentification forte selon les différents canaux ouverts par les API. Parmi les nouvelles responsabilités, on pourra s’attendre, par exemple, à des exigences accrues en matière de pistes d’audit, de traçabilité des transactions et de paiements instantanés. Les banques voudront probablement intégrer ces nouvelles API dans leurs patrimoines applicatifs vieillissants, ce qui est à la fois un défi de taille et un objectif important. Une gestion efficace des API peut faire apparaître de nouveaux modèles opérationnels pour les systèmes d’informations et améliorer sensiblement leur niveau d’agilité.

Questions de sécurité

Dans ce nouvel environnement de paiement, la sécurisation des données et la prévention de la fraude deviennent également plus complexes. Par exemple, si un prestataire tiers accède aux données d’une banque et qu’une violation de ces données est constatée, qui sera finalement responsable ? De même, quels intermédiaires sont vraiment des tierces parties de confiance ? Comment les banques peuvent-elles s’assurer que seules des tierces parties de confiance ont accès à leurs données ? Et lorsque les intermédiaires ont accès aux données des clients, comment les banques peuvent-elles s’assurer que ces données sont utilisées uniquement dans le cadre des traitements prévus ?

En matière de paiement, l’authentification va être l’un des nouveaux défis à relever par les banques. Une authentification forte augmente la sécurité des données, mais limite également l’accès à ces dernières. Fait significatif, la DSP2 inclut une norme RTS qui spécifie le déroulement d’une authentification forte entre les différentes parties prenantes des processus API. En outre, la gestion des API donne aux banques la capacité de superviser les accès accordés aux tierces parties de confiance, un aspect important de la protection des données des clients.

La protection des données personnelles des clients sera également importante. Et ce défi sera complexifié par la nécessité de coordonner les exigences de conformité de différents règlements, dont le RGPD, la réglementation bancaire locale (par exemple, le Code monétaire et financier en France) et les règles de secret bancaire de différents pays. Par exemple l’authentification des accès aux API devra être harmonisée en lien avec RGPD pour la gestion des consentements et de la finalité des traitements.

DXC peut vous aider...

La directive DSP2 est technologiquement neutre. Pour cette raison, la version finale du projet ne décrit pas et ne standardise pas les interfaces ouvertes qui peuvent être utilisées pour l’accès aux informations des comptes. Par conséquent, aucun standard spécifique n’est défini. Pour définir leurs interfaces ouvertes, les entreprises devront donc s’adresser à des partenaires disposant d’une expérience suffisante en matière de conformité et de standards de sécurité.

Forte de son expertise des métiers bancaires et de sa capacité à épauler les banques dans leurs transformations règlementaires, DXC Technology a développé une méthodologie claire et efficace pour accompagner ses clients dans l’étude et le cadrage des projets règlementaires. En effet, DXC accompagne aujourd’hui un de ses clients dans la mise en œuvre d’un programme de mise en conformité à la DSP2. DXC intervient sur la phase de cadrage des différents projets relatifs à la réglementation. DXC a développé un environnement bac à sable d’API « Open Banking API Accelerator » pour accompagner ses clients dans leur transformation numérique. Cet accélérateur permet d’expérimenter et de mettre en œuvre de nouveaux parcours client rendus possibles par la DSP2. Il s’appuie sur une passerelle d’API (API Gateway) gérant la sécurité et le cycle de développement des API (création et API Management), et des solutions d’authentification

6

Livre blanc

Figure 3. Les 7 phases clés d’un projet d’implémentation d’une architecture API

forte des clients. Cet accélérateur est créé à partir de solutions technologiques de DXC, de CA Technologies et d’autres partenaires. Il peut être répliqué pour permettre le démarrage rapide de projets DSP2. Il favorise également l’innovation en agissant comme un bac à sable pour intégrer des technologies de FinTech et de partenaires, éléments clés du modèle plus ouvert et plus collaboratif d’un écosystème à base d’API ouvertes.

DXC a développé et géré des API pour des banques du monde entier (Europe, Australie, Canada et États-Unis). Nous avons réalisé des prototypes (PoC) et des projets pilotes pour exploiter le potentiel des API dans le domaine de la banque de détail et de la gestion de patrimoine. DXC a également appliqué des modèles API à ses propres opérations en créant des services qui reposent sur les API de ses activités de banque et d’assurance. Pour les services bancaires de base (Hogan) et les systèmes de cartes (CAMS II), notre joint-venture CeleritiFinTech a développé et exposé des API pour les paiements et les transactions, et organisé des hackathons de clients. Dans le domaine de l’assurance, notre activité d’assurance Xchanging propose aux courtiers des devis reposant sur un ensemble d’API. Nous avons développé une méthodologie, des produits et des services pour aider votre entreprise non seulement à se conformer à la DSP2, mais encore à définir des stratégies pour de nouvelles opportunités numériques. Dans le cadre de l’offre paiements de DXC, nous avons les capacités de haut niveau dont les banques ont besoin pour réussir dans le nouvel environnement numérique d’aujourd’hui. Pour cela nous avons créé une gamme complète de services et de solutions de paiement (Figure 3).

• Conseil

• ConseilNotre offre

Définir la stratégie

• Conseil • Cloud• DevOps as a Service

Notre offre

Optimiser son infrastructure

• Conseil • Développement des API• DXC API (suite logicielle Celereti,

Assurance)

Notre offre

Créer des API

• Conseil • Concevoir et construire• Managed API

Notre offre

Gérer plusieurs API

• Conseil • Architecture d’Eentreprise orientée

Sservices• Développement d’applications

Notre offre

Intégrer des systèmes

• Conseil• Security implementation• DXC ConfidentID• DXC Authentication Broker Service• Managed security service

Notre offre

Sécuriser la mise en conformité

Notre offre

Développer son écosystème

1

4

2

5

3

6

7

• Stratégie• Feuille de route• POC, prototypes• Indicateur de performance• Gouvernance et organisation• Ressources

Besoins

• Scalabilité• DevOps

Besoins

• Présentation de l’architecture API• Conception, implémentation et test des API

Besoins

• Exposer et utiliser les APIs• Monitorer et gérer la performance• Monétisation et facturation

Besoins

• Construire des services pour exploiter l’architecture API

• Refondre /faire évoluer les systèmes existants

• Intégrations d’outils et d’applications

Besoins

• Evaluation des contrôles de sécurité (SCA (Strong Customer Authentication)

• Risque & fraude• Gestion des développements et sécurité • Monitoring et reporting• Sécurité physique

Besoins

• Développer la documentation de support• Hackathons• Partenariats commerciaux• Marketing et développement

Besoins

7

Livre blanc

Êtes-vous prêt à transformer la conformité DSP2 en opportunité digitale ?

Pour plus de détails sur les solutions DXC dans le domaine des paiements : dxc.technology/banking.

www.dxc.technology/fr

A propos de DXC Technology

Première société de services informatiques indépendante au monde, DXC Technology ( DXC: NYSE) aide ses clients à capter toute la puissance de l’innovation et à faire du changement un catalyseur de succès. Issue de la fusion de CSC et de la division Enterprise Services de Hewlett Packard Enterprise, DXC accompagne près de 6 000 clients des secteurs privé et public dans 70 pays. Notre indépendance technologique, nos ressources globales et notre vaste réseau d’alliances et de partenariats nous permettent d’offrir des services de bout en bout et des solutions informatiques avancées et performantes. DXC Technology est reconnue parmi les meilleures entreprises citoyennes au monde. Pour plus d’informations, rendez-vous sur www.dxc.technology

© 2017 DXC Technology Company. All rights reserved.