Wavestone - Séminaire à Paris sur la psd 2 et l'éconmie de l'api

MATINÉE PSD 2
QUELS ENJEUX ET QUELS IMPACTS ?
L’économie de l’API, Open Banking & PSD 2
Jean DIEDERICH, Partner, WAVESTONE – 25.04.2017 - Paris

confidentiel | © WAVESTONE 2
Chronologie de la DSP vers la DSP 2
SOYEZ PRÊTS POUR LA DSP 2
Adoption de la
DSP
Echéance de la
transposition : la DSP
doit être transposée
en loi nationale par
tous les Etats
Membres.
Le parlement
européen adopte la
DSP 2
2007 2009 2013 03/2014 07/2014 10/2015
Le Comité
Economique et
Monétaire du
Parlement Européen
s’accorde sur une
version de la DSP 2
La Commission
Européenne publie sa
proposition pour une
révision de la DSP
La Présidence du
Conseil Européen
propose une nouvelle
version (“Presidency
Compromises”)
12/2015
Publication de la
directive 2015/2366
sur les services liés
au paiement dans les
marchés intérieurs
(DSP 2)
01/2018
Entrée en vigueur de
la DSP 2
Echéance de la
transposition : la
Directive doit être
transposée en loi
nationale par tous
les Etats Membres
(RTS fin 2018 /
début 2019)
13/01/2018

Définitions de la DSP et nouvelles définitions introduites par la DSP 2
Payment Service Provider
(“PSP”)
› Un organisme fournissant des services permettant de placer ou de retirer de l’argent depuis un compte
de paiement mais aussi d’effectuer les opérations requises pour utiliser un compte de paiement
› Une personne physique ou morale faisant usage d’un service de paiement en tant que payeur ou
bénéficiaire
Payment Service User
(“PSU”)
Account Servicing
Payment Service Provider
(“AS PSP”)
› Institution de paiement traditionnel avec laquelle un PSU détient un ou plusieurs comptes et depuis ou
vers laquelle le PSU effectue des paiements. Chaque AS PSP doit s’enregistrer en tant qu’Institution de
Paiement (PI) pour se conformer à la DSP 2
Account Information
Service Provider (“AISP”)
› Une des deux nouvelles catégories de prestataire de paiement tiers introduit par la DSP 2. Un AISP agit
comme un agrégateur de données relatives aux comptes d’un PSU tenus chez un ou
plusieurs PSPs.
› Un TPP est un prestataire de services de paiement tiers qui n’est pas l’AS PSP. Il fournit les services liés
au déclenchement du paiement ainsi que les services d’informations concernant les comptes
Third Party Provider
(“TPP”)
› Un service de paiement permettant d’accéder à un compte de paiement fourni par un prestataire de
service de paiement tiers, où le payeur peut être activement impliqué dans l’initiation du
paiement. Il peut aussi utiliser un logiciel détenu par le prestataire de services de paiement tiers, ou
des instruments de paiement peuvent être utilisés par le payeur ou le bénéficiaire afin de transmettre
les identifiants du payeur vers le prestataire de service en charge du traitement des comptes
Payment Initiation Service
Provider (“PISP”)

Extension du périmètre
DSP 2 s’applique dès que
l’un des deux PSP est établi
dans l’UE
“One leg transactions”
La DSP 2 s’applique aux
transactions de paiement
effectuées au sein de
l’UE, indépendamment de
la devise
Transactions en
monnaie non-UE
Les TPPs, qui sont
maintenant couverts par la
DSP 2, sont les “nouveaux”
acteurs sur le marché des
services de paiement
TPPs
L’achat de biens physiques et
de services via un opérateur
télécom entre dans le
périmètre de la DSP 2
Paiements via les
opérateurs de télécom
› La DSP s’appliquait à tous les types de services de paiement en lien avec n’importe quelle transaction effectuée avec
la devise de l’UE et en son sein, dans la mesure où le PSP du payeur et le PSP du bénéficiaire (ou bien le seul PSP
impliqué dans la transaction financière) étaient localisés en UE (“Both legs in the EU”).
Avec la DSP 2, le
périmètre des
applications est
aussi étendu

Discussions autour de “L’accès aux systèmes de paiement”
› Forte demande pour l’ouverture du secteur financier
− Les APIs des FinTech sont en train de générer de plus en plus de business et de transactions du fait de la
forte popularité des smartphones et des business associés : Airbnb, Uber, Trip advisor, Apple Pay;
− Les clients sont demandeurs de services d’API qui soient ouverts concernant leurs institutions financières
étant donné l’usage des applications qui se démocratise fortement;
− Comme le paiement n’est plus une partie importante du processus, il doit devenir plus rapide et facile (Ex :
Plug and pay codes)
− Une telle solution crée de nouvelles opportunités basées sur la connaissance par la banque de chaque
point de vente (optimisation du niveau d’affluence, gestion des entrées pour un évènement…)
› L’aversion des banques pour ce genre de solutions
− Les banques traditionnelles sont peu positionnées sur ces solutions d’Open Banking : peur d’être
banalisées ou désintermédiées
− Le manque d’évolution de la part des acteurs actuels a poussé certains compétiteurs à lancer des API
(comme PayPal en 2011) et à prendre des parts de marchés
− Quelques acteurs mineurs du marché bancaire prennent avantage de la situation : Privat Bank (en Ukraine)
offre 100 APIs issues des FinTech depuis sa page principale, Fidor, BBVA…

DSP2 autorise des tiers à accéder aux données et aux paiements via des APIs
Les nouveaux prestataires de services de paiement (PSPs) permettront aux entreprises
d’adopter une approche modulaire afin de créer et développer de nouvelles activités
rapidement et à moindre coût.
Banque du
client A (PSP)
Account
Information
Service
Provider
(AISP)
Payment
Initiation
Service
Provider
(PISP)
Banque du
client B (PSP)
APIAPI
Vérifie la balance
globale de ses
comptes
Commande un
produit venant du
client A via un
prestataire de
paiement
Initie le
paiement
Obtient des
informations
sur les
comptes
Transfert de fonds (via
le réseau bancaire)
Client A Client B

Définir les APIs (Application Programing Interfaces)
API Provider › Une organisation, département ou équipe créant des APIs pour un usage interne ou externe
› L’utilisateur final faisant usage de l’API. Il peut être utilisé par une entité interne différente au sein de
l’organisation du fournisseur ou bien par une organisation tierce
API Consumer
Public APIs
› API disponible pour le public en visualisation et en abonnement, soit à travers un paiement ou bien
gratuitement
Partner APIs › API disponible pour les partenaires stratégiques de confiance
› API destinée à un usage interne uniquement au sein de l’organisation du fournisseur d’APIsInternal APIs
Une API est un ensemble de commandes, fonctions, protocoles et d’objets que
les programmeurs peuvent utiliser pour créer un logiciel ou interagir avec une
organisation tierce
Les portails d’API font le lien entre les consommateurs et les fournisseurs d’APIs

L’évolution des APIs vers des plateformes publiques
1960 – 1980
L’interopérabilité basique
des ordinateurs permet
les premiers échanges
d’information.
Interconnexion simple
entre des protocoles
réseaux.
Établissement de sessions
pour échanger de
l’information.
Techniques:
ARPANET, sessions TCP…
1980 – 1990
Création d’interfaces
contenant des fonctions
et de la logique.
L’information est
partagée de diverses
manières. Les courtiers
d’objets, appels de
procédure et appels
programme permettent
des interactions distantes
à travers le réseau.
Techniques:
Interfaces point-à-point,
captures de données
d’écran, RFCs, EDI …
1990 – 2000
De nouvelles plateformes
améliorent les échanges à
travers un middleware
logiciel. Les interfaces
commencent à être définies
en tant que services. Les
outils logiciels gèrent la
complexité et la fiabilité des
messages.
Techniques:
Message-oriented middleware
(MOM), enterprise service
bus (ESB) & service-oriented
architecture (SOA).
2000 – aujourd’hui
Les entreprises du digital
construisent des APIs
pour permettre et
accélérer le
développement de
nouveaux services et de
nouvelles offres. Les
couches de l’API gèrent
l’intégration de l’OSS/BSS
Techniques:
Integration as a service,
services RESTful, API
management and cloud
orchestration
Public APIs

Intégration d’un portail d’APIs publics
Synchrone Middleware
API Console &
Smartdocs
Authentification
Communauté
Dev Dashboard
Dev Onboarding
Docs
Manager
Dev
Manager
Key
Manager
Forum Blog
Api
Dashboard
Portail
d’APIs
publiques
Développeurs
internes
Équipes des
TPPs
Plateforme
APIs
Plateforme
bancaire (Legacy)
Plateforme
SWIFT
Asynchrone Files

6 caractéristiques d’un Portail d’APIs de qualité
APIs
Décrire son cycle de vie
Communiquer les plannings,
processus de migration, derniers
résultats des tests, la politique de
dépréciation
Application des règlements
Articuler les critères d’éligibilité à
travers les termes et conditions
Listé dans les catalogues d’API
Fournir une description précise des
fonctionnalités de l’API
Information sur les prix
Etre transparent sur les coûts et
décrire chaque package ou option
de souscription
Matériels de formation
Fournir des tutoriels sous plusieurs
formats (vidéos, guides écrits) et
une sandbox pour la formation
Utiliser des KPIs
Utiliser la surveillance en temps
reel pour fournir une information
transparente
1
2
3 6
5
4

P.ex. Fidor Bank (BPCE Groupe) – Virement SEPA

P.ex. Fidor Bank (BPCE Groupe) - Transactions

Une plateforme partagée DSP 2, « accès contrôlés aux services de paiement » (CAPS)
⁄ Un service et un réseau contrôlés pour assurer de la cohérence et une structure pour les nouveaux services
⁄ Une authentification robuste et une approche par les identifiants, intégrées avec des habilitations adaptées et une QoS
différente pour chaque acteur
⁄ La solution doit être à la fois flexible et avoir un niveau de sécurité approprié. Le paiement et les informations sur un
compte doivent être différenciés par exemple.
⁄ Un processus de gestion lié à la responsabilité des litiges doit être standardisé. Comme les risques et les responsabilités
ne sont pas supportés de la même manière par les banques et les tiers, CAPS doit viser un coût faible, définir et
s’accorder sur un processus de résolution des litiges, ce qui peut entraîner un changement des règles pour refléter de
nouveaux scenarios de litiges au bénéfice de tous les participants
⁄ Est capable de supporter des tiers en cas de demandes déraisonnées pour des remboursements par les banques
⁄ Inclus une méthode pour les banques et un tiers pour échanger des fonds en cas d’entente financière
⁄ Coopérer avec les autorités locales compétentes dans la suspension des accès aux participants pour lesquels les
réglementations ont été enfreintes
d
Mobilité des tiers entre les services :
AS-PSPs / BANKs APIs (CAPS) TPPs
Risque Risque
Responsabilités Responsabilités
Protection de
l’utilisateur
final
Confort de
l’utilisateur
final
Informations Informations
CAPS est le framework requis pour que la réglementation DSP 2 soit viable. Développer une solution commune
pour interfacer les banques et un prestataire de solutions de paiement tiers génère des enjeux complexes sur
plusieurs niveaux. Une politique forte est donc requise.
XS2A
SOURCE:: Y EQUENS SE, NETS AND VOCALINK
Surveillance continue Structurer l’information
en temps réel
Cas litigieux/
répétition/
authentification
Surveillance continue

EBA: Brouillon final des RTS (Regulatory Technical Standards)

Comment construire une API lucrative
API
Monétiser votre API
Définir votre modèle de
monétisation en ligne avec votre
approche stratégique
Embarquer les spécialistes de la
communication
S’engager avec les partenaires
Collecter et analyser les retours
utilisateurs
Focus sur l’approche
stratégique
Gérer les partenaires et le traffic
Intégrer les fonctions de l’API dans
vos produits et services
Au coeur de la transformation
digitale
Communiquer sur la valeur ajoutée
que l’API peut apporter à l’entreprise
Analyser votre infrastructure IT
actuelle
Impliquer vos ingénieurs et l’équipe
IT
Maintenir la documentation
Une documentation transparente est
fondamentale
1
2
3 6
5
4

Open Banking pour les banques, APIs dans le Cloud/PSF-S
FERME
OUVERT
Banque1
Client
Distribution
Produits (Services, Fonctionnalités
et Données)
API API API
Producteur2
Client
Produits (Services, Fonctionnalités
et Données)
API API API
Distribution
Distributeur3
Client
Distribution
API API API
Produits (Services,
Fonctionnalités et Données)
Plateforme4
Client
API API API
Distribution
Qui est en
train de
distribuer les
produits ?
Qui est en
train de créer
le produit ?
Tierces-
parties
Moi
même
Moi même Tierces-parties
Banque
Tierces-parties
Produits (Services,
Fonctionnalités et Données)

L’architecture de l’Open Banking (UK)
SOYEZ PRÊTS POUR LA DSP 2 Web, Mobile,
Desktop Apps
Firewall/WAF
Gestion optionnelle de l’API : Rate limiting, protection contre les
menaces, surveillance
OBP API: Scala dans un serveur Java (Websphere/Jetty/Tomcat)
API (Data & Oauth)
Ressources bancaires centrales modérées + Metadata
Développeur tiers & accès à l’application, Documentation, Métrique
Visualisation des données et Autorisation
Ressources
bancaires
centrales
brutes:
Clients,
Comptes,
Transactions
Metadata
brutes :
Tags,
Commentair
es, GeoTags,
URLs
Données,
Vues,
Permissions,
Utilisateurs
invités
Développeur
s & Apps,
Oauth, Logs
Connecteurs
File de
message
JDBC, REST, SOAP
API management
Presentation
Moderated models
Data filtering
Data models
Resource access
Data and Services
Ressources de la
banque : Comptes,
Transactions,
Paiements, Filiales…
Données OBP (RDBMS,
NoSQL)
Authentification
bancaire
Bank Login
OAuth
Connecteur
d’authentification
Gestion de l’API
Présentation
Modèles modérés
Filtrage des données
Modèles de données
Accès aux ressources
Données et Services
Série de tests
OBP
API
Explorer

Open Banking APIs layer, FinTechs & Banking as a Service in the Cloud

Les banques se trouvent face à un tournant et doivent prendre des choix stratégiques!
Activités des banques
Périmètredesservices
Placeholder
This text can be
replaced with your
own text
Conformité Compétition
Expansion Transformation
Limite les banques à un
rôle de prestataire de
services d’accès aux
comptes (AS-PSP)
+ Banque comme
prestataire tiers (TPP)
Limité pour
donner l’accès
au paiement et
aux services
liés à
l’information
(AS-PSP)
+ Paiements et
Services
d’information
innovants
(NEW)

wavestone.com
@wavestone_
Jean DIEDERICH
Partner
M+352 661 322 351
jean.diederich@wavestone.com

PARIS
LONDON
NEW YORK
HONG KONG
SINGAPORE *
DUBAI *
LUXEMBOURG
BRUSSELS
GENEVA
CASABLANCA
LYON
MARSEILLE
NANTES
* Partners

Wavestone - Séminaire à Paris sur la psd 2 et l'éconmie de l'api

Contenu connexe

Tendances

Similaire à Wavestone - Séminaire à Paris sur la psd 2 et l'éconmie de l'api

Plus de Bertrand Carlier

Wavestone - Séminaire à Paris sur la psd 2 et l'éconmie de l'api