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 2SOYEZ 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 comptede 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 oubé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 ouvers laquelle le PSU effectue des paiements. Chaque AS PSP doit s’enregistrer en tant qu’Institution dePaiement (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 agitcomme un agrégateur de données relatives aux comptes d’un PSU tenus chez un ouplusieurs PSPs.

› Un TPP est un prestataire de services de paiement tiers qui n’est pas l’AS PSP. Il fournit les services liésau 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 deservice de paiement tiers, où le payeur peut être activement impliqué dans l’initiation dupaiement. Il peut aussi utiliser un logiciel détenu par le prestataire de services de paiement tiers, oudes instruments de paiement peuvent être utilisés par le payeur ou le bénéficiaire afin de transmettreles identifiants du payeur vers le prestataire de service en charge du traitement des comptes

Payment Initiation Service Provider (“PISP”)

SOYEZ PRÊTS POUR LA DSP 2


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 avecla 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 PSPimpliqué 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 laforte 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 chaquepoint 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’êtrebanalisé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 entreprisesd’adopter une approche modulaire afin de créer et développer de nouvelles activitésrapidement et à moindre coût.

Banque du client A (PSP)

AccountInformation

Service Provider (AISP)

PaymentInitiationService 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 del’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-orientedarchitecture (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

Portaild’APIs

publiquesDéveloppeursinternes

Équipes desTPPs

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 QoSdiffé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 uncompte 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ésne 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 ets’accorder sur un processus de résolution des litiges, ce qui peut entraîner un changement des règles pour refléter denouveaux 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 lesré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

finalInformations 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

Metadatabrutes : Tags,

Commentaires, GeoTags,

URLs

Données, Vues,

Permissions, Utilisateurs

invités

Développeurs & 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

ètr

edes

serv

ices

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 DIEDERICHPartner

M+352 661 322 351

[email protected]

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

Presentations & Public Speaking