Warning: Undefined variable $is_shop_page in /srv/data/web/vhosts/www.devlhon-consulting.com/htdocs/wp-content/themes/transera/includes/helpers.php on line 607
KYC

[vc_row][vc_column][vc_column_text]Adoptée le 8 octobre 2015, la seconde Directive européenne sur les services de paiement (DSP 2) est entrée en vigueur en janvier 2018, avec un délai de mise en application jusqu’en novembre 2019. Aujourd’hui, cependant, on est encore loin d’un fonctionnement satisfaisant (voir ici). Et les effets attendus de l’open banking, notamment en termes de mobilité bancaire, n’ont été nulle part significatifs (y compris au Royaume-Uni, pays par excellence des néo-banques, qui était encore membre de l’UE quand la Directive a été publiée). La faute aux banques ? Sans doute. Mais une réaction assez inévitable aux dispositions d’une réglementation absurde.

La principale disposition de la DSP 2 oblige les banques à transférer les données clients dont elles disposent dès lors que de nouveaux acteurs non bancaires leur en font la demande, avec l’accord des clients. Ces nouveaux acteurs sont des opérateurs de paiement et des agrégateurs de compte, autant de « néo-banques » donc, proposant des services financiers aux clients des banques traditionnelles.

La DSP 2 pose ainsi le principe d’un accès ouvert et gratuit aux données bancaires, dans le but de susciter des offres concurrentes aux banques, synonymes de services nouveaux et de tarifs avantageux. A cet effet, les banques doivent donc mettre en place des API permettant ce partage de données.

Ces dispositions se fondent elles-mêmes sur le principe que leurs données appartiennent non aux banques mais aux clients, qui doivent donc pouvoir en disposer librement et gratuitement. Par ailleurs, ces orientations étaient portées par la conviction que les clients des banques n’attendaient que de trouver de meilleures offres et services et qu’ils allaient donc, dans ces conditions, changer massivement d’établissements. En l’occurrence, la DSP 2 se fondait ainsi sur deux illusions.

Que les données appartiennent aux clients auxquels elles se rapportent parait peu contestable sur le principe. Cependant, dans les faits, ces données n’existent pas en soi. De sorte qu’il suffirait de les transférer simplement d’un système à l’autre. Ces données, très dépendantes des systèmes et des institutions qui les produisent, ne sont pas du tout harmonisées. Tout un travail est donc nécessaire pour les rendre universellement utilisables. Un travail que la DSP 2 confie… aux banques. Lesquelles doivent ainsi payer pour organiser leur propre concurrence !

Aujourd’hui, la fintech Tide suggère à la Competition and Markets Authority britannique de mettre en place un système d’achat des données clients aux banques, pour faciliter la mise en œuvre de l’open banking. A rebours des principes de la DSP2 donc. Mais, dans la pratique, des intermédiaires sont apparus qui collectent et harmonisent certaines données bancaires, qu’ils revendent aux nouveaux acteurs.

Que l’on ne dise pas cependant qu’il est facile, avec le recul, de souligner tout ceci aujourd’hui. D’emblée, il était clair que l’on ne pouvait attendre des banques un grand empressement à appliquer les dispositions de la Directive ! On trouvera sur ce blog un billet qui, en 2017, le soulignait, en même temps qu’il présentait des études invitant à prendre avec beaucoup de précautions l’empressement à changer de banque que l’on prêtait au public.

Aux Etats-Unis, où les néo-banques ne se portent pas plus mal qu’en Europe, au contraire, le développement des API bancaires a été précédé par une harmonisation des normes de codification des données menée par la profession bancaire elle-même dans le cadre d’un Financial Data Exchange, sans obligation réglementaire de partage. Tandis qu’en Europe, on accuse plus facilement les banques de l’échec de la DSP2, beaucoup se refusant encore à reconnaitre l’absurdité d’une réglementation bancaire qui n’a d’autre but affiché que de pénaliser les banques et qui compte sur celles-ci pour le faire !

Score Advisor[/vc_column_text][/vc_column][/vc_row]