Pour une simplification des systèmes numériques avec une blockchain, ou une remise en cause du modèle “4 coins ++”

La dénomination “4 coins” est souvent utilisée en monétique pour décrire l’architecture entre le consommateur (porteur de carte), sa banque, le commerçant et la banque du commerçant.

La vue “carrée” en est la représentation traditionnelle mais nous lui substituons une vue en colonne plus explicite pour la suite du propos car elle ajoute une dimension temporelle dans les échanges :

Pourquoi “+” ? Car il existe toujours au milieu un opérateur juridique et/ou technique pour relier la banque du porteur et celle du commerçant : VISA, MasterCard, … Il existe aussi un lien entre consommateur et commerçant, ne serait-ce que par l’interopérabilité nécessaire des outils de chacun (carte et terminaux de paiement).

Pourquoi “++” ? Car depuis quelques années (DSP2), le législateur a inventé une couche supplémentaire entre le porteur de carte et sa banque sous le nom générique de “merchant / consumer service providers”, idem pour le commerçant ce qui porte à 7 le nombre de (re)coins. Cette couche a pour objectifs de renforcer l’innovation par plus de concurrence. Elle apporte cependant une lourdeur car chaque nouvel acteur voit passer les flux.

Pour illustrer cette dérive, et pouvoir ainsi introduire une amorce de nouvelle proposition, je joins le schéma issu d’une publication de l’European Payment Council (EPC) sur l’utilisation des QR code (code à barre carré !) entre un possesseur de smartphone et un commerçant :

ASPSP (Account Servicing Payment Service Provider) : banque du consommateur ou du commerçant.

MCTSP (Mobile Credit Transfer Payment Service Provider) : opérateur assurant la coordination des différents systèmes utilisés pour effectuer des paiements via mobiles.

HUB : plateforme de routage et de traitement des transactions acheminant les demandes de paiements, autorisations et confirmations entre les différents MCTSP.

 © Copyright European Payments Council (EPC) AISBL

Nous avons nos 7 coins et vous pouvez facilement faire le lien avec la description simpliste initiale, l’EPC par sa norme, garantit l'interopérabilité c'est-à-dire dans ce cas la lecture du QR code par le consommateur.

A quoi servent tous ces échanges ? A afficher le QR code sur l’écran du consommateur avec sécurité : tout ça pour ça !

Voyons un peu la sécurité du dispositif ? Le consommateur doit faire confiance à son “service provider” (passe encore), qui lui-même fait confiance au “hub” qui lui-même fait confiance au “Merchant Service Provider” qui lui-même fait confiance, ou bien apporte sa confiance (ce n’est pas très clair) au commerçant.

Tout cela pour afficher un QR code, ce qui prend quelques lignes de code informatique sur un smartphone.

Cela permet de :

-        rendre le commerçant dépendant,

-        rendre le consommateur dépendant,

-        augmenter le coût global de la transaction de paiement (qui elle va arriver plus tard),

-        rendre impossible la maîtrise de la chaîne de confiance pour le consommateur : Qui est le hub ? Qui est le “Merchant Service Provider”? Quels sont mes recours si le QR code est frauduleux ou abusif ?

Bien évidemment, il aura fallu au préalable signer des contrats, impossibles à lire et à comprendre pour le consommateur, exonérant chaque acteur de toute responsabilité en cas de problème (hormis celle du  consommateur; j'exagère à peine).

La simplification c’est bon pour la planète

© Copyright European Payments Council (EPC) AISBL (pour le schéma original sans les ajouts crayonnés)

La plupart des flux sont supprimés et 2 étapes sont ajoutées:

-        Le QR code est signé cryptographiquement par le commerçant.

-        Le consommateur va vérifier la signature du commerçant sur le Hub.

Mais comment créer et vérifier ces signatures ? Ceci est relativement simple dès lors que le hub est une blockchain publique car elle est le bien commun sécurisé entre les acteurs.

En effet, dans la plupart des pays, les commerçants sont enregistrés numériquement dans des bases légales telles que le registre du commerce en France. A partir de là, il est possible de créer et de lier une représentation numérique (en format blockchain) de ce commerçant lui permettant de signer des QR codes, mais aussi des transactions, … c’est-à-dire toutes sortes de données qui faciliteront les tâches du commerçant. Cette représentation sur la blockchain, que nous nommerons par facilité “identité cryptographique” permet la signature mais aussi et surtout la vérification de ces signatures par tous les autres acteurs.

Ainsi nous pouvons supprimer des intermédiaires et mutualiser des besoins de signatures numériques entre différents domaines.

De plus, en utilisant une blockchain publique, la transparence des liens entre la base légale et la signature renforce la capacité de contrôle par le consommateur et la communauté des acteurs. Il est ainsi possible d’avoir une vérification de l’ensemble de la chaîne de confiance : greffe de tribunal de commerce, opérateurs existants, mais aussi et surtout la possibilité de vérifier la banque du commerçant. En effet, celle-ci est enregistrée sur la blockchain, donc sa signature est vérifiable par tous les intervenants.

Et ça c’est bon pour la confiance !

Attaquons nous au paiement

La première étape est la vérification du QR code du commerçant signé par ce dernier. Nous supposerons que la banque a mis en place les moyens de vérifier cette signature dans ses systèmes.

Nous avons deux options :

1. Le consommateur utilise l’application de sa banque : l’authentification réciproque entre lui-même et sa banque est directe. Le consommateur fait donc uniquement transiter les données du QR code.
2. Le consommateur utilise une application tierce. Dans ce cas, il signe son accord en incluant les données du QR code et transmet le tout (signature et données) à sa banque.

© Copyright European Payments Council (EPC) AISBL (pour le schéma original sans les ajouts crayonnés)

La banque du consommateur lit la blockchain-Hub pour vérifier la signature du commerçant (contenue dans les données du QR code) et la signature du message par le consommateur puis, une fois le virement instantané réalisé, écrit la notification sur le Hub. Charge au consommateur et au commerçant de lire quelques secondes plus tard la blockchain-hub pour avoir la confirmation infalsifiable du virement.

Au préalable, la banque du consommateur possède également une identité cryptographique sur le hub (c.a.d. la capacité de signer et d’être vérifié sur la blockchain). Dans le cas où le consommateur possède une application tierce,  l’identité cryptographique du consommateur peut être liée à des identités numériques e-IDAS.

Cerise sur le gâteau :

-        A part la déclaration initiale permettant le contrôle des signatures, les autres transactions ne sont que des lectures donc sans coût d’utilisation de la blockchain.

-        Le hub peut aussi servir de référentiel pour toutes les URL d’accès aux différents serveurs informatiques évitant ainsi les faux liens et un paramétrage en dur dans les applications.

-        Les “service providers”, côté consommateurs ou commerçants, n’interviennent plus dans les flux mais peuvent proposer des services complémentaires utiles comme des applications de facilitation des achats et pas uniquement une accaparation de zone de chalandise qui ne se justifiait que par leur intervention dans les flux.

-        L’échange de signatures contrôlables sur une blockchain publique permet surtout de revenir aux fondamentaux de l’acte initial de tout commerce : l'authentification réciproque préalable du consommateur et du vendeur.

Cyril Vignet, Jose Luu, et Vincent Griffault