FR3087308A1 - Systeme et procede d’identification multiple par contrats intelligents sur chaine de blocs - Google Patents

Systeme et procede d’identification multiple par contrats intelligents sur chaine de blocs Download PDF

Info

Publication number
FR3087308A1
FR3087308A1 FR1859389A FR1859389A FR3087308A1 FR 3087308 A1 FR3087308 A1 FR 3087308A1 FR 1859389 A FR1859389 A FR 1859389A FR 1859389 A FR1859389 A FR 1859389A FR 3087308 A1 FR3087308 A1 FR 3087308A1
Authority
FR
France
Prior art keywords
request
responses
requests
application programming
programming interface
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1859389A
Other languages
English (en)
Other versions
FR3087308B1 (fr
Inventor
Philippe Gaborieau
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Happy Ledger
Original Assignee
Happy Ledger
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Happy Ledger filed Critical Happy Ledger
Priority to FR1859389A priority Critical patent/FR3087308B1/fr
Priority to PCT/IB2019/060513 priority patent/WO2020075153A1/fr
Priority to CN201980079461.3A priority patent/CN113302643A/zh
Priority to EP19824200.0A priority patent/EP3864608A1/fr
Priority to US17/284,421 priority patent/US20210390489A1/en
Publication of FR3087308A1 publication Critical patent/FR3087308A1/fr
Application granted granted Critical
Publication of FR3087308B1 publication Critical patent/FR3087308B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06393—Score-carding, benchmarking or key performance indicator [KPI] analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Educational Administration (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • Technology Law (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé d'identification électronique sur réseau d'une première partie (30) auprès d'au moins une deuxième partie (20) par l'établissement d'un document certifié (60) de données relatives à la première partie en réponse à une requête (40) de la deuxième partie, la requête étant envoyée sur une interface de programmation applicative (11) et comprenant une pluralité de demandes auxquelles la première partie répond au moins partiellement par l'envoi de réponses (50) via ladite interface de programmation applicative, le procédé comprenant : - une étape de stockage des réponses (50) dans une chaîne de blocs (12); - une étape de création du document certifié (60) à partir de la requête de la deuxième partie, des réponses de la première partie et de réponses préalablement stockées dans la chaîne de blocs.

Description

Système et procédé d’identification multiple par contrats intelligents sur chaîne de blocs
DOMAINE TECHNIQUE
La présente invention appartient au domaine général de la collecte et du partage d’informations, plus spécifiquement, de la mise à disposition d’informations d’identité et assimilées pour des applications de comptes en ligne. L’invention concerne plus particulièrement encore un système et un procédé d’identification client pour des comptes financiers.
La présente invention a également trait aux technologies de chaîne de blocs (blockchain) et de contrats intelligents (smart-contracts).
ÉTAT DE L’ART
D’ordinaire, les activités d’organismes financiers, tels que les banques et les assurances, sont réglementées et régulées. Parfois, certaines règles s’avèrent complexes, pour des raisons évidentes de sécurité, et nécessitent pour leur application la mise en place de processus longs, comprenant des opérations redondantes, pouvant présenter un côté fastidieux tant pour les clients des organismes financiers que pour les organismes financiers eux-mêmes.
Parmi les activités réglementées des organismes financiers, les procédures d’identification et de connaissance de clients regroupées sous l’acronyme KYC (pour Know Your Customer) sont soumises à des exigences légales particulièrement strictes, qui varient selon les pays, dans le cadre de la protection des consommateurs, de la lutte contre le blanchiment de capitaux et de la protection des données.
KYC désigne généralement les activités de diligence raisonnable (ou due diligence) relatives à la clientèle, menées par les organismes financiers et autres sociétés réglementées en vue d’identifier leurs clients et de vérifier les informations pertinentes pour pouvoir effectuer des transactions financières avec eux, ainsi que la réglementation bancaire régissant ces activités.
Bien que le processus KYC soit présenté ici sous son aspect légal et réglementaire, il peut, dans le cadre de la technologie numérique actuelle, être appliqué en dehors des conditions réglementaires.
Afin d’exécuter une démarche KYC vis-à-vis d’un client, d’un fournisseur ou d’un partenaire, les organismes financiers demandent un certain nombre d’informations et requièrent l’établissement de pièces justificatives. Fournir tous ces éléments est à priori une simple formalité que les clients daignent accomplir lorsqu’il s’agit d’une seule demande financière voire d’un nombre restreint de demandes. Cependant, dès lors que le nombre d’organismes financiers entrant en jeu devient conséquent, fournir les informations et les pièces requises pour le KYC imposé par chacun desdits organismes peut rapidement se révéler être une tâche particulièrement chronophage et décourageante. Cette situation correspond par exemple au cas des demandeurs d’investissement pour la création d’entreprise ou le lancement de projets économiques divers (startups, autoentrepreneurs, levée de fonds, ...etc.). Dans le cas du financement participatif, pour ne citer que ce mode de financement d’habitude présenté comme efficace et simple d’accès, il est vivement recommandé aux lanceurs de projets de multiplier les demandes en s’inscrivant sur un maximum de plateformes dédiées dans une logique d’augmentation des chances de levée de fonds. Ces inscriptions multiples nécessitent donc la création de comptes, ou de profils, multiples en fournissant quasiment à chaque fois les mêmes informations.
La figure de l’art antérieur illustre une telle situation dans laquelle une personne se trouve contrainte de fournir pour chaque organisme financier un nombre de « réponses », ou informations, égal au nombre de questions qui lui sont soumises par l’organisme en question. La personne peut donc vraisemblablement répondre plusieurs fois à une même question, en particulier aux questions relevant de l’identité de la personne et de son état civil posées systématiquement par les différents organismes financiers et plus généralement par toute instance administrative.
Dans certains cas, les organismes financiers peuvent être partenaires, regroupés ou dépendants d’une même entité, et partager par conséquent les données clients. Toutefois, il n’existe à ce jour aucune solution de partage des données entre des organismes complètement indépendants les uns des autres.
Il existe néanmoins des solutions de sauvegarde interne permettant à un organisme financier de sauvegarder les données de ses clients pour une éventuelle utilisation ultérieure de ces données. Les chaînes de blocs offrent à cet effet des moyens de stockage fiables et sécurisés et sont de plus en plus utilisées dans le secteur financier.
D’un autre côté, à cause du coût des processus KYC qui ne cesse de croître, les développements en matière de simplification de ces processus KYC sont de plus en plus nombreux. Cependant, ces développements cherchent avant tout à simplifier la tâche KYC du côté des banques et des acteurs financiers et considèrent dans une bien moindre mesure la problématique du point de vue client.
La plupart de ces développements concernent des technologies de régulation qui cherchent à automatiser des tâches administratives du KYC en incorporant l’intelligence artificielle dans l’organisation des données et la détection d’anomalies.
PRÉSENTATION DE L’INVENTION
La présente invention vise à pallier les inconvénients de l’art antérieur.
À cet effet, la présente invention concerne un procédé d’identification électronique sur réseau d’une première partie auprès d’au moins une deuxième partie par l’établissement d’un document certifié de données relatives à la première partie en réponse à une requête de la deuxième partie, la requête étant envoyée sur une interface de programmation applicative et comprenant une pluralité de demandes auxquelles la première partie répond au moins partiellement par l’envoi de réponses via ladite interface de programmation applicative. Ce procédé comprend avantageusement :
- une étape de stockage des réponses dans une chaîne de blocs ;
- une étape de création du document certifié à partir de la requête de la deuxième partie, des réponses de la première partie et de réponses préalablement stockées dans la chaîne de blocs.
Ainsi, la première partie répond uniquement aux demandes auxquelles elle n’avait jamais répondu auparavant ou à celles pour lesquelles les réponses ont changé. La création du document certifié est donc basée à la fois sur des réponses « actuelles >> et des réponses « anciennes >> enregistrées lors du traitement d’une ancienne requête.
De façon avantageuse, les réponses données par la première partie correspondent à une partie des demandes de la requête, l’autre partie desdites demandes correspondant à d’autres réponses préalablement stockées dans la chaîne de blocs et données par ladite première partie en réponse à des demandes d’une autre requête.
De ce fait, la première partie ne fournit plus des réponses répétitives comme c’est le cas des solutions de l’état de l’art.
Plus particulièrement, au moins un document certifié de données relatives à la première partie en réponse à une requête d’une deuxième partie est créé à partir de ladite requête, de réponses à des demandes de ladite requête, et de réponses à des demandes de requêtes issues d’autres deuxièmes parties.
Selon un mode de réalisation, le procédé d’identification comprend :
- une étape d’envoi par une deuxième partie d’une requête sur l’interface de programmation applicative ;
- une étape de transmission par l’interface de programmation applicative de la requête à la première partie ;
- une étape d’envoi par la première partie de réponses à une partie, au moins, des demandes de ladite requête ;
- une étape d’ajout par l’interface de programmation applicative desdites réponses à la chaîne de blocs ;
- une étape d’envoi par l’interface de programmation applicative de la requête à ladite chaîne de blocs ;
- une étape de création et de stockage par la chaîne de blocs d’un document certifié, correspondant à la réponse de la première partie à toutes les demandes de la requête, à partir de ladite requête et de toutes les réponses stockées dans la chaîne de blocs ;
- une étape d’envoi par la chaîne de blocs du document certifié à l’interface de programmation applicative ; et
- une étape de transmission par l’interface de programmation applicative du document certifié à la deuxième partie.
Avantageusement, les quatre avant dernières étapes sont contrôlées chacune par un programme de type contrat intelligent.
Selon un mode de réalisation, l’interface de programmation applicative envoie une liste de demandes parmi lesquelles chaque deuxième partie sélectionne un ensemble de demandes pour définir sa requête.
Par exemple, dans une application de l’invention au secteur financier, la première partie, chaque deuxième partie, la requête et le document certifié sont respectivement un demandeur de financement ou un investisseur, un organisme financier, un questionnaire de connaissance client et un compte rendu de connaissance client de type Know Your Customer (KYC).
La présente invention porte également sur un système d’identification électronique sur réseau, pour la mise en œuvre d’un procédé tel que décrit, comportant une interface de programmation applicative et une chaîne de blocs.
De façon avantageuse, la chaîne de blocs est une chaîne de blocs de consortium dans laquelle chaque nœud est régi par une deuxième partie.
Plus particulièrement, l’interface de programmation applicative est accessible depuis une unité de consultation de type page web.
Les concepts fondamentaux de l’invention venant d’être exposés ci-dessus dans leur forme la plus élémentaire, d’autres détails et caractéristiques ressortiront plus clairement à la lecture de la description qui suit et en regard des dessins annexés, donnant à titre d’exemple non limitatif un mode de réalisation d’un procédé d’identification conforme aux principes de l’invention et d’un système pour la mise en œuvre dudit procédé.
BRÈVE DESCRIPTION DES FIGURES
Les éléments d’une même figure, ainsi que les figures elles-mêmes, ne sont pas nécessairement représentés à la même échelle. Sur l’ensemble des figures, les éléments identiques ou équivalents portent le même repère numérique.
Il est ainsi illustré en :
- Figure 0 : un schéma de principe de l’art antérieur ;
- Figure 1 : un schéma de principe de la présente invention ;
- Figure 2 : une représentation schématique du système d’identification multiple selon l’invention et des principales interactions entre ses éléments ;
- Figure 3 : les principales étapes d’un procédé d’identification multiple selon l’invention.
DESCRIPTION DÉTAILLÉE DE MODES DE RÉALISATION
Dans le mode de réalisation décrit ci-après, on fait référence à un système et un procédé d’identification multiple destinés principalement à une application dans le domaine du financement des entreprises. Cet exemple non limitatif est donné pour une meilleure compréhension de l’invention et n’exclut pas l’adaptation du système et du procédé à d’autres applications dans d’autres activités humaines. Par exemple, l’invention peut être appliquée à la problématique des candidatures académiques ou professionnelles multiples nécessitant la fourniture d’une grande partie d’informations communes.
De manière générale, l’invention permettra à toute personne dans le besoin de répondre à une multitude de questions issues de différentes parties de fournir un nombre minimisé de réponses de sorte à répondre à toutes les questions posées sans jamais donner plusieurs fois une même réponse. L’avantage que procure l’invention est schématisé sur la figure 1 qu’il faut considérer en comparaison avec la figure de l’art antérieur.
La figure 2 représente schématiquement un système d’identification 10 selon l’invention opérant entre un fournisseur 20 et un consommateur 30, les termes « fournisseur » et « consommateur » seront employés seulement dans un premier temps pour mieux distinguer les rôles de ces deux parties.
Pour des raisons évidentes de clarté, un seul fournisseur est représenté sur les figures. Il est toutefois fondamental de noter que l’invention s’applique, et trouve toute son utilité, dans le cas d’une pluralité de fournisseurs et permet de faciliter la tâche d’un consommateur qui se trouve confronté à plusieurs fournisseurs.
Le système d’identification 10 comporte principalement une interface de programmation applicative 11 et une chaîne de blocs 12 qu’on désignera respectivement par API et blockchain dans la suite de la description.
Dans le paragraphe qui suit, il est fait rappel des principales caractéristiques d’une blockchain sur lesquelles repose l’invention.
Une blockchain est une base de données distribuée qui gère une liste de données protégées contre la falsification ou la modification. Les transactions représentent les échanges entre utilisateurs du réseau, et sont stockées au sein des blocs de la blockchain. Les différentes transactions enregistrées sont regroupées dans des blocs. Après avoir enregistré les transactions récentes, un nouveau bloc est généré et analysé. Si le bloc est valide, le bloc peut être horodaté et ajouté à la blockchain. Les transactions sont alors visibles dans l’ensemble du réseau. Lorsqu’il est ajouté à la blockchain, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l’authenticité et la sécurité du réseau.
Pour la suite de la description, on se place dans le cas suivant : le fournisseur 20 est un organisme financier parmi les banques, les sociétés de gestion du patrimoine, les sociétés de fiducie, les sociétés de courtage de valeurs, les compagnies d’assurance, les sociétés de crédit-bail, les investisseurs institutionnels, les plateformes de financement participatif, ...etc. ; et le consommateur 30 est un investisseur. Le consommateur peut également correspondre à une personne à la recherche d’investissement pour une création d’entreprise ou un lancement de projet à potentiel économique, par exemple le consommateur est un entrepreneur à la recherche d’une levée de fonds pour le lancement d’une entreprise innovante de type startup.
La blockchain 12 est une blockchain de consortium partagée entre un ensemble d’acteurs financiers 20 indépendants les uns des autres, dans laquelle chacun desdits acteurs financiers constitue un nœud de validation. De ce fait, les éléments qui seront stockés dans cette blockchain seront caractérisés par une authenticité difficilement contestable en raison de l’implication de différents acteurs financiers, soumis à des réglementations strictes, dans la validation desdits éléments.
Cette condition n’est pas obligatoire et la blockchain peut être publique ou privée suivant l’application de l’invention.
Dans un premier temps, le système d’identification multiple sera décrit au travers de son fonctionnement global, ensuite, les étapes du procédé d’identification mis en œuvre par ledit système seront décrites plus en détail.
Le fonctionnement global du système d’identification peut être divisé en deux niveaux, un niveau externe et un niveau interne.
Le niveau externe correspond aux interactions entre le consommateur, l’organisme financier et le système d’identification considéré comme une boîte noire. Le niveau interne concerne quant à lui les opérations effectuées à l’intérieur du système entre ces différents éléments.
Niveau externe
L’acteur financier 20 a besoin de connaître certaines informations et de disposer de pièces justificatives relatives au consommateur 30 dans le cadre d’une démarche KYC. Pour ce faire, l’acteur financier 20 émet un modèle de questionnaire 40 qu’il souhaite faire remplir par le consommateur 30. L’étape 510 correspond donc à une transmission par l’acteur financier 20 d’un modèle de questionnaire 40 au système d’identification 10.
L’acteur financier 20 envoie 520 une notification au consommateur 30 pour requérir le remplissage du questionnaire 40. Parallèlement, le système 10 envoie au consommateur 30 un questionnaire adapté 41 qui ne contient que des questions dont les réponses ne sont pas stockées dans ledit système.
En effet, comme il sera décrit plus loin, le système stocke toutes les réponses données par le consommateur et filtre les questions du modèle de questionnaire envoyé par l’acteur financier pour ne transmettre au consommateur que les questions qui n’ont pas de réponses stockées dans ledit système.
L’utilisateur remplit le questionnaire adapté 41 en fournissant des réponses 50. Les réponses 50 sont envoyées 530 au système 10.
Le système d’identification 10 établit in fine un KYC 60 et le transmet 541 à l’acteur financier 20 lorsque le consommateur 30 donne son autorisation 540.
Niveau interne
La définition du modèle de questionnaire 40 par l’acteur financier peut être réalisée soit de manière libre par ledit acteur financier, soit de manière orientée, auquel cas le système envoie un ensemble de questions possibles à l’acteur financier qui ne retient que les questions qui l’intéressent pour établir son propre modèle de questionnaire.
En effet, le système envoie l'ensemble des questions qui existent, l'acteur financier en définissant son modèle de questionnaire, va avoir la possibilité de personnaliser des labels. Ainsi, le modèle de questionnaire obtenu est composé des identifiants des questions retenues ainsi que des labels sélectionnés par l'acteur financier.
Lorsque le modèle de questionnaire est établi de manière libre, le système opère une correspondance entre ses propres questions et les questions dudit questionnaire. Cette correspondance peut être réalisée de différentes manières.
Avant d’adresser le questionnaire 40 défini par l’acteur financier 20 au consommateur 30, le système 10 effectue un tri dans les questions du questionnaire 40 pour établir un questionnaire adapté 41 qui ne contient que les questions auxquelles il n’a pas été trouvé de réponses préalablement stockées dans la blockchain 12. Pour ce faire, l’API 11 interagit 550 avec la blockchain 12 pour rechercher toutes les réponses possibles aux questions du questionnaire 40 correspondant au consommateur auquel le questionnaire est adressé. Chaque consommateur 30 doit à cet effet être enregistré sur le système via un profil pour permettre audit système de trouver les réponses correspondant à un consommateur donné.
Pour les questions restées sans réponses, l’API génère un questionnaire adapté 41 qu’elle transmet au consommateur 30 pour demande de réponses.
Préférablement, le questionnaire adapté 41 comporte les questions pour lesquelles les réponses ont été trouvées dans la blockchain, et mentionne lesdites questions et réponses, afin de permettre au consommateur d’avoir une vue d’ensemble sur toutes les questions adressées par l’acteur financier et de mettre à jour éventuellement certaines informations.
Les réponses 50 ainsi données par le consommateur 30 sont récupérées par l’API et transmises à la blockchain. La blockchain stocke systématiquement toutes les réponses données par le consommateur et permet ainsi de tenir à jour les profils des consommateurs sous forme de registres.
Ensuite, l’API complète le questionnaire 40 de l’acteur financier avec des réponses 50 provenant de la blockchain et des réponses directement données par le consommateur, et établit un KYC 60 horodaté, ledit KYC est alors stocké dans la blockchain qui contient tous les KYC horodatés établis entre les acteurs financiers et les consommateurs ayant utilisé le système d’identification.
Les KYC stockés peuvent constituer des preuves matérielles en cas de litige. Contrairement aux KYC existants, et qui ne sont pas stockés en blockchain, les KYC selon l’invention ne peuvent pas être détruits et leur validation multiple par des acteurs financiers indépendants réunis en consortium augmente leur degré de fiabilité et d’authenticité.
Le KYC horodaté correspondant à l’identification du consommateur 30 visà-vis de l’acteur financier 20 est transmis audit acteur financier sous réserve d’autorisation dudit consommateur.
Compte tenu de ce qui précède, il apparaît clairement que le système d’identification présente un avantage considérable pour le traitement par les consommateurs des questionnaires émis par les acteurs financiers dans le cadre des démarche KYC en permettant à chaque consommateur de ne répondre qu’une seule fois à toute question posée plusieurs fois par différents acteurs financiers. Etant donné que pour des acteurs financiers de même nature, par exemple les banques, les questionnaires d’identification sont généralement similaires, le consommateur peut, grâce au système d’identification selon l’invention, se retrouver dans une situation où tous les questionnaires qui lui sont soumis sont préremplis avec des réponses préalablement données et stockées dans la blockchain, auquel cas il aura simplement besoin de valider ces réponses avec ou sans modification.
Le procédé venant d’être décrit de manière générale, la suite de la description s’articulera plus en détail autour des différentes étapes dudit procédé.
En référence à la figure 3, le procédé d’identification multiple selon l’invention comprend dans l’ordre :
- Une étape 100 d’envoi d’une liste de questions par l’API à au moins un acteur financier ;
- Une étape 110 de définition par l’acteur financier d’un modèle de questionnaire sur la base de la liste de questions, et d’envoi dudit modèle de questionnaire à l’API ;
- Une étape 120 de requête d’un KYC par l’acteur financier auprès de l’API ;
- Une étape 130 de transmission par l’API du modèle de questionnaire à l’utilisateur ;
- Une étape 140 d’envoi de tout ou partie des réponses par l’utilisateur à l’API ;
- Une étape 150 d’ajout par ΓΑΡΙ des nouvelles réponses à la blockchain ;
- Une étape 160 d’autorisation par l’utilisateur de l’accès de l’acteur financier aux réponses données ;
- Une étape 170 d’enregistrement par l’API de l’autorisation utilisateur sur la blockchain, et d’envoi par l’API du modèle de questionnaire à la blockchain ;
- Une étape 180 de création et de stockage par la blockchain d’un KYC horodaté à partir du modèle de questionnaire et des réponses enregistrées ;
- Une étape 190 de transmission par la blockchain du KYC horodaté à l’API ; et
- Une étape 200 finale d’envoi du KYC horodaté à l’acteur financier qui l’a sollicité.
Il est important de noter que la communication des utilisateurs et des acteurs financiers avec l’API est effectuée par le biais d’une plateforme dédiée implémentant ladite API et interagissant avec la blockchain. Une telle plateforme est par exemple un site web.
L’étape 100 d’envoi de la liste des questions, parmi lesquelles les acteurs financiers doivent choisir pour définir leurs modèles, permet de simplifier le traitement des modèles de questionnaires définis par les acteurs financiers en normalisant les questions constitutives desdits modèles. Ceci évite à l’API de faire des correspondances entre questions afin d’affecter correctement les réponses aux questions, et limite par là même le risque d’erreur. En effet, avec la normalisation des questions, l’API affecte sans difficultés les réponses aux questions correspondantes.
Toutefois, le procédé selon l’invention peut fonctionner sans envoi de listes de questions préétablies. Dans ce cas, une étape supplémentaire de mise en correspondance des modèles définis par les acteurs financiers avec des questions préalablement définies dans l’API doit être prise en compte.
De plus, l’étape 100 d’envoi de la liste de questions n’est pas systématique, il se peut qu’un acteur financier garde cette liste pour des utilisations ultérieures.
Par exemple, la liste des questions envoyées par ΓΑΡΙ aux acteurs financiers contient des questions à choix multiples du type :
Question : Quelle est votre situation familiale ?
Réponses possibles : célibataire, marié(e), pacsé(e), séparé(e), veuf(ve), vie maritale ;
Question : Quel est le montant global des revenus de votre foyer ?
Réponses possibles : inférieur à 30 000 €, de 30 000 € à 50 000 €, de 50 000 € à 100 000 €, de 100 000 € à 150 000 €, de 150 000 € à 250 000 €, de 250 000 € à 500 000 €, supérieur à 500 000 € ;
Question : Quel est le montant du capital de vos crédits restants dus à titre personnel ?
Réponses possibles : absence de crédit, inférieur à 50 000 €, compris entre 50 000 € et 200 000 €, compris entre 200 000 € et 500 000 €, supérieur à 500 000 € ;
Question : Avez-vous subi une perte sur vos placements financiers ?
Réponses possibles : non, je n'ai jamais subi de perte sur mes placements financiers, oui, de 10 % maximum, oui, de 20 % maximum, oui, plus de 20 O/ .
/o ,
L’étape 110 de définition d’un modèle de questionnaire par l’acteur financier permet à l’acteur financier de remplir ses obligations légales en matière d’identification et de connaissance client, et de définir pour chaque cas d’espèce un modèle adapté, ou simplement de définir un modèle unique, et global, appliqué à tous les utilisateurs, quels que soient leurs profils économiques. Dans ce dernier cas, l’étape 110 de définition du modèle de questionnaire peut être réalisée une unique fois par l’acteur financier pour un utilisateur donné et omise pour les utilisateurs suivants.
La définition d’un modèle de questionnaire par un acteur financier selon l’étape 110 peut consister en un choix d’identifiants de questions et de labels de questions. Les identifiants peuvent être des numéros d’ordre, des références alphanumériques ou des codes divers, et les labels sont par exemple des noms de sections, des thèmes, ou des mots-clés.
L’étape 120 de requête d’un KYC par l’acteur financier s’accompagne de l’envoi à ΓΑΡΙ d’un identifiant du modèle de questionnaire défini.
Lorsqu’un acteur financier sollicite un KYC auprès d’un utilisateur via l’API, ledit acteur financier doit pouvoir identifier le modèle de questionnaire qui servira de base à l’élaboration du KYC parmi, éventuellement, plusieurs modèles qu’il a auparavant définis. L’acteur financier dispose alors d’un identifiant pour chaque modèle de questionnaire défini, permettant ainsi à l’API de retrouver le modèle pour lequel un KYC est sollicité.
L’étape 130 de transmission par l’API du modèle de questionnaire à l’utilisateur est caractérisée par l’envoi soit, d’un modèle de questionnaire tronqué dans lequel n’apparaissent que les questions qui n’ont pas de réponses stockées dans la blockchain, soit d’un modèle tel que défini par l’acteur financier avec en plus toutes les réponses correspondant à des questions du modèle et ayant été trouvées dans la blockchain. Ainsi, ces réponses par défaut peuvent être mises à jour à tout moment par l’utilisateur.
L’étape 140 d’envoi des réponses par l’utilisateur à l’API permet à l’API de collecter les informations et réponses nouvelles dont la blockchain ne dispose pas encore afin de compléter le profil de l’utilisateur dans la blockchain.
L’API ajoute, lors de l’étape 150, les réponses données par l’utilisateur à la blockchain. Cette étape concerne un partage de données, en particulier personnelles, de l’utilisateur dans la blockchain et nécessite un accord contractuel. A cet effet, l’exécution de cette étape est régie par un contrat intelligent (ou smartcontract). Le Smart-contract contrôlant cette étape s’exécute par exemple à la réunion des deux conditions suivantes : l’utilisateur envoie des réponses à l’API (étape 140) et l’API vérifie que lesdites réponses ne sont pas stockées dans la blockchain.
D’autres étapes du procédé selon l’invention sont contrôlées par des Smartcontracts comme on le verra dans la suite.
L’étape 160 correspond à une autorisation que l’utilisateur accorde à l’acteur financier pour que ce dernier puisse accéder aux informations données en réponse au modèle de questionnaire défini. Cette autorisation permet ensuite de déclencher les étapes suivantes décrites ci-dessous. Cette étape permet en outre à l’utilisateur de remplir son KYC en plusieurs fois et de ne procéder à sa transmission que lorsque les informations sont remplies intégralement dans le modèle de questionnaire défini par l’acteur financier. De plus, l’autorisation de l’utilisateur revêt un caractère contractuel exigé par les réglementations.
Par exemple, cette autorisation correspond à la validation par l’utilisateur de la véracité des informations compilées sur un écran avant leur transmission à l’acteur financier.
L’étape 170 permet à ΙΆΡΙ d’envoyer le modèle de questionnaire défini par l’acteur financier à la blockchain et d’enregistrer l’autorisation donnée par l’utilisateur sur la blockchain, pour permettre ensuite à la blockchain d’appliquer les réponses ajoutées au modèle ajouté. Cette étape est contrôlée par un Smartcontract.
L’étape 180 aboutit à la création par la blockchain d’un KYC à partir du modèle et des réponses enregistrés. Ce KYC est horodaté puis stocké dans la blockchain. Le stockage des différents KYC créés est nécessaire à la constitution de preuves par l’une des parties en cas de litige, ces fichiers étant caractérisés par une grande fiabilité en vertu de leurs multiples validations par les différents nœuds de la blockchain avant leurs horodatages et sauvegardes. L’étape 180 est également contrôlée par un Smart-contract.
En dernier lieu, l’étape 190 permet à la blockchain d’envoyer le KYC horodaté à ΙΆΡΙ, cette étape étant contrôlée par un Smart-contract, et l’étape 200 correspond à la transmission du KYC horodaté à l’acteur financier l’ayant sollicité, cette transmission est également contrôlée par un Smart-contract.
Pour conclure, le secteur bancaire est le plus concerné par la notion de KYC et donc, à fortiori, par la présente invention. Toutefois, pour chaque entreprise, dans chaque secteur d’activité, la connaissance client est primordiale et se trouve parfois au cœur de la stratégie. Il est évident que le procédé d’identification tel que décrit peut être adapté et modifié sans pour autant sortir du cadre de l’invention.

Claims (10)

  1. REVENDICATIONS
    1. Procédé d’identification électronique sur réseau d’une première partie (30) auprès d’au moins une deuxième partie (20) par l’établissement d’un document certifié (60) de données relatives à la première partie en réponse à une requête (40) de la deuxième partie, la requête étant envoyée sur une interface de programmation applicative (11) et comprenant une pluralité de demandes auxquelles la première partie répond au moins partiellement par l’envoi de réponses (50) via ladite interface de programmation applicative, caractérisé en ce qu’il comprend :
    - une étape de stockage des réponses (50) dans une chaîne de blocs (12);
    - une étape de création du document certifié (60) à partir de la requête de la deuxième partie, des réponses de la première partie et de réponses préalablement stockées dans la chaîne de blocs.
  2. 2. Procédé selon la revendication 1, dans lequel les réponses (50) données par la première partie (30) correspondent à une partie des demandes de la requête (40), l’autre partie desdites demandes correspondant à d’autres réponses préalablement stockées dans la chaîne de blocs (12) et données par ladite première partie en réponse à des demandes d’une autre requête.
  3. 3. Procédé selon la revendication 1 ou la revendication 2, dans lequel au moins un document certifié (60) de données relatives à la première partie (30) en réponse à une requête (40) d’une deuxième partie est créé à partir de ladite requête, de réponses (50) à des demandes de ladite requête, et de réponses à des demandes de requêtes d’autres deuxièmes parties.
  4. 4. Procédé selon l’une quelconque des revendications précédentes, caractérisé en ce qu’il comprend :
    - une étape d’envoi par une deuxième partie (20) d’une requête (40) sur l’interface de programmation applicative (11) ;
    - une étape de transmission par l’interface de programmation applicative de la requête à la première partie (30) ;
    - une étape d’envoi par la première partie de réponses (50) à une partie, au moins, des demandes de ladite requête ;
    - une étape d’ajout par l’interface de programmation applicative desdites réponses à la chaîne de blocs (12) ;
    - une étape d’envoi par l’interface de programmation applicative de la requête à ladite chaîne de blocs ;
    - une étape de création et de stockage par la chaîne de blocs d’un document certifié (60), correspondant à la réponse de la première partie à toutes les demandes de la requête, à partir de ladite requête et de toutes les réponses stockées dans la chaîne de blocs ;
    - une étape d’envoi par la chaîne de blocs du document certifié à l’interface de programmation applicative ; et
    - une étape de transmission par l’interface de programmation applicative du document certifié à la deuxième partie.
  5. 5. Procédé selon la revendication 4, dans lequel les quatre avant dernières étapes sont contrôlées chacune par un programme de type contrat intelligent.
  6. 6. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’interface de programmation applicative envoie une liste de demandes parmi lesquelles chaque deuxième partie sélectionne un ensemble de demandes pour définir sa requête.
  7. 7. Procédé selon l’une quelconque des revendications précédentes, dans lequel la première partie (30), chaque deuxième partie (20), la requête (40) et le document certifié (60) sont respectivement un investisseur, un organisme financier, un questionnaire de connaissance client et un compte rendu de connaissance client de type Know Your Customer (KYC).
  8. 8. Système (10) d’identification électronique sur réseau, pour la mise en oeuvre d’un procédé selon l’une des revendications précédentes, comportant une interface de programmation applicative (11) et une chaîne de blocs (12).
  9. 9. Système selon la revendication 8, dans lequel la chaîne de blocs (12) est une chaîne de blocs de consortium dans laquelle chaque nœud est régi par une deuxième partie.
  10. 10. Système selon la revendication 8 ou la revendication 9, dans lequel l’interface de programmation applicative est accessible depuis une unité de consultation de type page web.
FR1859389A 2018-10-10 2018-10-10 Systeme et procede d’identification multiple par contrats intelligents sur chaine de blocs Active FR3087308B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1859389A FR3087308B1 (fr) 2018-10-10 2018-10-10 Systeme et procede d’identification multiple par contrats intelligents sur chaine de blocs
PCT/IB2019/060513 WO2020075153A1 (fr) 2018-10-10 2019-12-06 Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs
CN201980079461.3A CN113302643A (zh) 2018-10-10 2019-12-06 用于在区块链上使用智能合约进行多重识别的系统和方法
EP19824200.0A EP3864608A1 (fr) 2018-10-10 2019-12-06 Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs
US17/284,421 US20210390489A1 (en) 2018-10-10 2019-12-06 System and method for multiple identification using smart contracts on blockchains

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1859389A FR3087308B1 (fr) 2018-10-10 2018-10-10 Systeme et procede d’identification multiple par contrats intelligents sur chaine de blocs

Publications (2)

Publication Number Publication Date
FR3087308A1 true FR3087308A1 (fr) 2020-04-17
FR3087308B1 FR3087308B1 (fr) 2021-09-10

Family

ID=65685561

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1859389A Active FR3087308B1 (fr) 2018-10-10 2018-10-10 Systeme et procede d’identification multiple par contrats intelligents sur chaine de blocs

Country Status (5)

Country Link
US (1) US20210390489A1 (fr)
EP (1) EP3864608A1 (fr)
CN (1) CN113302643A (fr)
FR (1) FR3087308B1 (fr)
WO (1) WO2020075153A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112364121B (zh) * 2020-11-09 2024-03-01 中国平安人寿保险股份有限公司 问卷pdf的自动创建方法、装置、存储介质及计算机设备
GB2607589B (en) * 2021-06-04 2023-12-20 Taal Dit Gmbh Blockchain based device certification
CN115082076A (zh) * 2022-07-04 2022-09-20 北京天德科技有限公司 一种基于区块链的三阶段金融违规多重裁判方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170366348A1 (en) * 2016-06-17 2017-12-21 Capital One Services, Llc Blockchain systems and methods for user authentication
US20180005239A1 (en) * 2016-06-29 2018-01-04 Paypal, Inc. Mobile devices enabling customer identity validation via central depository
US20180287800A1 (en) * 2017-02-06 2018-10-04 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020169631A1 (en) * 2001-04-23 2002-11-14 Lewis David M. System and method for providing employers with virtual interviews of potential job candidates
US9967334B2 (en) * 2015-03-02 2018-05-08 Dell Products Lp Computing device configuration and management using a secure decentralized transaction ledger
CN105630938A (zh) * 2015-12-23 2016-06-01 深圳市智客网络科技有限公司 一种智能问答系统
CN117151853A (zh) * 2016-04-11 2023-12-01 区块链控股有限公司 用于区块链上的安全点对点通信的方法
US10282558B2 (en) * 2016-09-02 2019-05-07 The Toronto-Dominion Bank System and method for maintaining a segregated database in a multiple distributed ledger system
US10832247B2 (en) * 2016-09-15 2020-11-10 American Express Travel Related Services Company, Inc. Systems and methods for blockchain based payment networks
US20180165586A1 (en) * 2016-12-09 2018-06-14 Cognitive Scale, Inc. Providing Procurement Related Cognitive Insights Using Blockchains
US10911441B2 (en) * 2017-01-18 2021-02-02 CertifID LLC Verifying party identities for secure transactions
WO2018165247A1 (fr) * 2017-03-07 2018-09-13 Mastercard International Incorporated Procédé et système d'enregistrement de traitement de transaction point à point
CN109922039B (zh) * 2019-01-14 2021-05-07 湘潭大学 一种基于区块链技术的半中心化的身份管理方法
CN109871441A (zh) * 2019-03-13 2019-06-11 北京航空航天大学 一种基于神经网络的导学问答系统及方法
KR102038088B1 (ko) * 2019-04-03 2019-11-26 주식회사 한국정보보호경영연구소 디지털 인감을 제공하는 블록체인 기반의 전자문서 관리 시스템

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170366348A1 (en) * 2016-06-17 2017-12-21 Capital One Services, Llc Blockchain systems and methods for user authentication
US20180005239A1 (en) * 2016-06-29 2018-01-04 Paypal, Inc. Mobile devices enabling customer identity validation via central depository
US20180287800A1 (en) * 2017-02-06 2018-10-04 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes

Also Published As

Publication number Publication date
WO2020075153A8 (fr) 2020-06-25
US20210390489A1 (en) 2021-12-16
FR3087308B1 (fr) 2021-09-10
CN113302643A (zh) 2021-08-24
WO2020075153A1 (fr) 2020-04-16
EP3864608A1 (fr) 2021-08-18

Similar Documents

Publication Publication Date Title
Hornuf et al. Equity crowdfunding in Germany and the United Kingdom: Follow‐up funding and firm failure
Zachariadis et al. Governance and control in distributed ledgers: Understanding the challenges facing blockchain technology in financial services
Turilli et al. The ethics of information transparency
US20150332283A1 (en) Healthcare transaction validation via blockchain proof-of-work, systems and methods
US20130179955A1 (en) Identity Management System And Method Including Architecture For The Same
EP3251046A2 (fr) Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
EP3864608A1 (fr) Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs
US20160217419A1 (en) Data analysis system and method to enable integrated view of customer information
US11488271B2 (en) System and method for supplier information management
Sayegh et al. Blockchain application in insurance and reinsurance
CA2801659A1 (fr) Systeme et procede de gestion d'identite et architecture connexe
AU2017349457A2 (en) Regulatory compliance system and method
Didenko et al. Central bank digital currencies as a potential response to some particularly Pacific problems
Putri et al. E-Finance transformation: a study of M-wallet adoption in Indonesia
Gupta et al. Overview of technology solutions
EP1164529A1 (fr) Système et procédé de couponnage électronique
Khudnev Blockchain: foundational technology to change the world
WO2008134741A2 (fr) Gestion de relation de crédit
EP3909216A1 (fr) Plateforme de transmission securisée de données personnelles perfectionnée
Strebinger et al. Privacy concerns and consumer acceptance of blockchain-enabled services
Al Hadad et al. A Comprehensive Review of COBIT and ISO 27001: Approaches to Auditing Credit Bureau Automation System (CBAS) at PT XYZ
McKechnie et al. Proposed Modifications to Spur Consumer Adoption of Blockchain
Shafee Governance of cloud storage-A secure cloud storage strategy to maximize data sovereignty
Zulkarnain et al. THE ROLE OF MANAGEMENT INFORMATION SYSTEMS IN INDUSTRY TRAVELOKA STARTUP
Aghili et al. Ethereum, Hyperledger and Corda: A side-by-side comparison of capabilities and constraints for developing various business case uses

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200417

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6