EP3864608A1 - Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs - Google Patents

Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs

Info

Publication number
EP3864608A1
EP3864608A1 EP19824200.0A EP19824200A EP3864608A1 EP 3864608 A1 EP3864608 A1 EP 3864608A1 EP 19824200 A EP19824200 A EP 19824200A EP 3864608 A1 EP3864608 A1 EP 3864608A1
Authority
EP
European Patent Office
Prior art keywords
request
responses
party
requests
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.)
Pending
Application number
EP19824200.0A
Other languages
German (de)
English (en)
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.)
Shoyo
Original Assignee
Shoyo
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 Shoyo filed Critical Shoyo
Publication of EP3864608A1 publication Critical patent/EP3864608A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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
    • 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/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

Definitions

  • the present invention belongs to the general field of collecting and sharing information, more specifically, the provision of identity information and the like for online account applications.
  • the invention relates more particularly to a system and method for identifying customers for financial accounts.
  • the present invention also relates to blockchain and smart-contract technologies. STATE OF THE ART
  • KYC Know Your Customer
  • KYC generally designates customer due diligence (or due diligence) activities carried out by financial institutions and other regulated companies with a view to identifying their customers and verifying the relevant information to be able to carry out financial transactions with them, as well as the banking regulations governing these activities.
  • the figure of the prior art illustrates such a situation in which a person is forced to provide for each financial organization a number of "answers", or information, equal to the number of questions submitted to him by the organization in question.
  • the person can therefore probably answer the same question several times, in particular to questions relating to the identity of the person and his marital status systematically asked by the various financial organizations and more generally by any administrative body.
  • financial organizations can be partners, grouped or dependent on the same entity, and consequently share the customer data.
  • financial organizations can be partners, grouped or dependent on the same entity, and consequently share the customer data.
  • Blockchains offer reliable and secure storage for this purpose and are increasingly used in the financial sector.
  • the present invention aims to overcome the drawbacks of the prior art.
  • the present invention relates to a method of electronic identification on the network of a first party with at least a second party by the establishment of a certified document time-stamped with data relating to the first party in response to a request from the second party, the request being sent to an application programming interface and comprising a plurality of requests to which the first party at least partially responds by sending responses via said application programming interface.
  • This process advantageously comprises:
  • the first party responds only to requests to which it had never answered before or to those for which the answers have changed.
  • the creation of the certified document is therefore based on both “current” responses and “old” responses recorded during the processing of an old request.
  • the responses given by the first party correspond to a part of the requests in the request, the other part of said requests corresponding to other responses previously stored in the blockchain and given by said first party in response to requests from another request.
  • the first part no longer provides repetitive answers as is the case with state-of-the-art solutions.
  • At least one certified document of data relating to the first party in response to a request from a second party is created from said request, from responses to requests from said request, and from responses to requests for requests. from other second parts.
  • the identification method comprises:
  • the penultimate four stages are each controlled by a smart contract type program.
  • the application programming interface sends a list of requests from which each second party selects a set of requests to define its request.
  • the first part, each second part, the request and the certified document are respectively a financing applicant or an investor, a financial organization, a customer knowledge questionnaire and an account. Know Your Customer (KYC) customer knowledge reporting.
  • KYC Know Your Customer
  • the present invention also relates to an electronic identification system on a network, for the implementation of a method as described, comprising an application programming interface and a block chain.
  • the block chain is a consortium block chain in which each node is governed by a second party.
  • the application programming interface is accessible from a web page type consultation unit.
  • - Figure 0 a block diagram of the prior art
  • - Figure 1 a block diagram of the present invention
  • FIG. 2 a schematic representation of the multiple identification system according to the invention and the main interactions between its elements;
  • the invention will allow anyone in need to answer a multitude of questions from different parties to provide a minimized number of answers so as to answer all the questions asked without ever giving the same answer several times.
  • the advantage provided by the invention is shown diagrammatically in FIG. 1 which must be considered in comparison with the figure of the prior art.
  • FIG. 2 schematically represents an identification system 10 according to the invention operating between a supplier 20 and a consumer 30, the terms “supplier” and “consumer” will be used only initially to better distinguish the roles of these two parties .
  • the identification system 10 mainly comprises an application programming interface 1 1 and a block chain 12 which will be designated respectively by API and blockchain in the following description.
  • API application programming interface
  • block chain 12 which will be designated respectively by API and blockchain in the following description.
  • a blockchain is a distributed database that manages a list of data protected against forgery or modification. Transactions represent exchanges between network users, and are stored within the blocks of the blockchain. The different transactions recorded are grouped in blocks. After recording recent transactions, a new block is generated and analyzed. If the block is valid, the block can be time stamped and added to the blockchain. The transactions are then visible throughout the network. When added to the blockchain, a block can no longer be modified or deleted, which guarantees the authenticity and security of the network.
  • the supplier 20 is a financial organization among banks, wealth management companies, trust companies, securities brokerage companies, insurance companies , leasing companies, institutional investors, crowdfunding platforms, ... etc.
  • the consumer 30 is an investor.
  • the consumer can also correspond to a person looking for investment for a business creation or a launch of a project with economic potential, for example the consumer is an entrepreneur looking for a fundraiser for the launch of an innovative startup-type company.
  • Blockchain 12 is a consortium blockchain shared between a set of financial actors 20 independent of each other, in which each of said financial actors constitutes a validation node.
  • each of said financial actors constitutes a validation node.
  • the multiple identification system will be described through its overall operation, then, the steps of the identification process implemented by said system will be described in more detail.
  • the overall functioning of the identification system can be divided into two levels, an external level and an internal level.
  • the external level corresponds to the interactions between the consumer, the financial institution and the identification system considered to be a black box.
  • the internal level concerns the operations carried out inside the system between these different elements.
  • the financial actor 20 needs to know certain information and to have supporting documents relating to the consumer 30 within the framework of a KYC approach. To do this, the financial actor 20 sends a questionnaire template 40 which he wishes the consumer to fill in. Step 510 therefore corresponds to a transmission by the financial actor 20 of a questionnaire template 40 to the system. identification 10.
  • the financial actor 20 sends 520 a notification to the consumer 30 to request the filling of the questionnaire 40.
  • the system 10 sends to the consumer 30 a suitable questionnaire 41 which contains only questions whose answers are not stored in said system.
  • the system stores all the answers given by the consumer and filters the questions from the questionnaire template sent by the financial actor to transmit to the consumer only the questions that have no stored answers. in said system.
  • the user fills in the adapted questionnaire 41 by providing responses 50.
  • the responses 50 are sent 530 to the system 10.
  • the identification system 10 ultimately establishes a KYC 60 and transmits it 541 to the financial actor 20 when the consumer 30 gives his authorization 540.
  • the definition of the model of questionnaire 40 by the financial actor can be carried out either freely by said financial actor, or in a directed way, in which case the system sends a set of possible questions to the financial actor who retains only the questions interested in establishing their own questionnaire template.
  • the system sends all the questions that exist, the financial actor by defining his model of questionnaire, will have the possibility of customize labels.
  • the questionnaire template obtained consists of the identifiers of the questions selected as well as the labels selected by the financial actor.
  • the system matches its own questions with the questions in the questionnaire. This correspondence can be achieved in different ways.
  • the system 10 Before sending the questionnaire 40 defined by the financial actor 20 to the consumer 30, the system 10 performs a sorting in the questions of the questionnaire 40 to establish a suitable questionnaire 41 which contains only the questions for which it was not found of responses previously stored in the blockchain 12. To do this, ARI 11 interacts 550 with the blockchain 12 to find all the possible answers to the questions of the questionnaire 40 corresponding to the consumer to whom the questionnaire is addressed. Each consumer 30 must for this purpose be registered on the system via a profile to allow said system to find the answers corresponding to a given consumer.
  • ARI For questions that remain unanswered, ARI generates an adapted questionnaire 41 which it sends to consumer 30 for requests for answers.
  • the adapted questionnaire 41 includes the questions for which the answers were found in the blockchain, and mentions the said questions and answers, in order to allow the consumer to have an overview of all the questions addressed by the financial actor. and possibly update certain information.
  • the responses 50 thus given by the consumer 30 are collected by ARI and transmitted to the blockchain.
  • the blockchain systematically stores all the responses given by the consumer and thus makes it possible to keep up-to-date consumer profiles in the form of registers.
  • ARI completes the questionnaire 40 of the financial actor with responses 50 from the blockchain and responses directly given by the consumer, and establishes a time-stamped KYC 60
  • said KYC is then stored in the blockchain which contains all time-stamped KYCs established between financial actors and consumers who have used the identification system.
  • the stored KYCs can constitute material evidence in the event of a dispute.
  • the KYCs according to the invention cannot be destroyed and their multiple validation by independent financial actors united in a consortium increases their degree of reliability and authenticity.
  • the time stamped KYC corresponding to the identification of the consumer 30 vis-à-vis the financial actor 20 is transmitted to said financial actor subject to the authorization of said consumer.
  • the identification system has a considerable advantage for the processing by consumers of questionnaires issued by financial actors as part of the KYC approach by allowing each consumer to answer only one only once to any question asked several times by different financial actors.
  • the identification questionnaires are generally similar, the consumer can, thanks to the identification system according to the invention, find themselves in a situation where all the questionnaires which submitted to it are pre-filled with responses previously given and stored in the blockchain, in which case it will simply need to validate these responses with or without modification.
  • the multiple identification method according to the invention comprises, in order:
  • step 130 of transmission by ARI of the questionnaire template to the user
  • step 140 of sending all or part of the responses by the user to the API
  • the step 100 of sending the list of questions, among which the financial actors must choose to define their models makes it possible to simplify the treatment of the models of questionnaires defined by the financial actors by standardizing the questions constituting said models. This prevents ARI from matching questions between questions to properly affect the answers to questions, and thereby limits the risk of error. Indeed, with the standardization of questions, ARI easily affects the answers to the corresponding questions.
  • the method according to the invention can operate without sending lists of pre-established questions.
  • an additional step of matching the models defined by the financial actors with questions previously defined in ARI must be taken into account.
  • step 100 of sending the list of questions is not systematic, it may be that a financial actor keeps this list for future uses.
  • the list of questions sent by the API to financial actors contains multiple choice questions such as:
  • Step 1 10 of definition of a questionnaire model by the financial actor allows the financial actor to fulfill its legal obligations in terms of identification and customer knowledge, and to define for each case a model adapted, or simply to define a single, global model, applied to all users, whatever their economic profiles.
  • step 1 10 of defining the questionnaire template can be carried out only once by the financial actor for a given user and omitted for the following users.
  • the definition of a questionnaire model by a financial actor according to step 110 can consist of a choice of question identifiers and question labels.
  • the identifiers can be serial numbers, alphanumeric references or various codes, and the labels are, for example, section names, themes, or keywords.
  • the financial actor request step 120 of a KYC is accompanied by the sending to the API of an identifier of the defined questionnaire model.
  • a financial actor When a financial actor requests a KYC from a user via ARI, said financial actor must be able to identify the questionnaire model that will serve as the basis for the development of the KYC among, possibly, several models that he has previously defined. The financial actor then has an identifier for each model of questionnaire defined, thus allowing ARI to find the model for which a KYC is requested.
  • the step 130 of transmission by ARI of the questionnaire model to the user is characterized by the sending either, of a truncated questionnaire model in which only appear the questions which have no answers stored in the blockchain , or of a model as defined by the financial actor with in addition all the answers corresponding to questions of the model and having been found in the blockchain.
  • these default responses can be updated at any time by the user.
  • Step 140 of sending user responses to the API allows ARI to collect new information and responses that the blockchain does not yet have in order to complete the user's profile in the blockchain.
  • the API adds, in step 150, the responses given by the user to the blockchain.
  • This step concerns the sharing of user data, in particular personal data, in the blockchain and requires a contractual agreement. To this end, the execution of this step is governed by a smart contract.
  • the Smart-contract controlling this step is executed, for example, when the following two conditions are met: the user sends responses to ARI (step 140) and ARI verifies that said responses are not stored in the blockchain.
  • Step 160 corresponds to an authorization that the user grants to the financial actor so that the latter can access the information given in response to the defined questionnaire template.
  • This authorization then triggers the following steps described below.
  • This step also allows the user to fill his KYC in several times and not to carry out his transmission only when the information is completed in full in the questionnaire template defined by the financial actor.
  • the authorization of the user is of a contractual nature required by regulations.
  • this authorization corresponds to the validation by the user of the veracity of the information compiled on a screen before its transmission to the financial actor.
  • Step 170 allows the API to send the questionnaire template defined by the financial actor to the blockchain and record the authorization given by the user on the blockchain, to then allow the blockchain to apply responses added to the added template. This step is controlled by a Smart-contract.
  • Step 180 leads to the blockchain creation of a KYC from the model and the recorded responses.
  • This KYC is time stamped and then stored in the blockchain.
  • the storage of the different KYCs created is necessary for the constitution of evidence by one of the parties in the event of a dispute, these files being characterized by high reliability by virtue of their multiple validations by the different nodes of the blockchain before their time stamps and backups .
  • Step 180 is also controlled by a Smart-contract.
  • step 190 allows the blockchain to send the time-stamped KYC to ARI, this step being controlled by a Smart-contract, and step 200 corresponds to the transmission of the time-stamped KYC to the financial actor. having requested, this transmission is also controlled by a Smart-contract.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Educational Administration (AREA)
  • Quality & Reliability (AREA)
  • Accounting & Taxation (AREA)
  • Game Theory and Decision Science (AREA)
  • Tourism & Hospitality (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (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) horodaté 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é horodaté 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 oeuvre 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 1 1 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, ARI 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, ARI 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 ARI 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, ARI 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 1 10 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 à ARI ;
- Une étape 120 de requête d’un KYC par l’acteur financier auprès de l’API ;
- Une étape 130 de transmission par ARI 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 ARI 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 ARI de l’autorisation utilisateur sur la blockchain, et d’envoi par ARI 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 ARI 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 à ARI 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, ARI 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 ARI 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 l’API 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 ,
L’étape 1 10 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 1 10 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 à l’API d’un identifiant du modèle de questionnaire défini.
Lorsqu’un acteur financier sollicite un KYC auprès d’un utilisateur via ARI, 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 à ARI de retrouver le modèle pour lequel un KYC est sollicité.
L’étape 130 de transmission par ARI 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 à ARI 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 smart- contract). 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 à ARI (étape 140) et ARI 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 Smart- contracts 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 à l’API 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 Smart- contract.
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 noeuds 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é à ARI, 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

R E V E N D I C A T I O N S
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) horodaté 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 (1 1 ) 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. 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. 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. 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 (1 1 ) ; - 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. 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. 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. 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. 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. 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. 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.
EP19824200.0A 2018-10-10 2019-12-06 Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs Pending EP3864608A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP3864608A1 true EP3864608A1 (fr) 2021-08-18

Family

ID=65685561

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19824200.0A Pending EP3864608A1 (fr) 2018-10-10 2019-12-06 Système et procédé d'identification multiple par contrats intelligents sur chaîne 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 北京天德科技有限公司 一种基于区块链的三阶段金融违规多重裁判方法

Family Cites Families (15)

* 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 区块链控股有限公司 用于区块链上的安全点对点通信的方法
CA3027741C (fr) * 2016-06-17 2020-07-21 Jonathan WEIMER Systemes de chaines de blocs et procedes d'authentification d'utilisateur
US10467624B2 (en) * 2016-06-29 2019-11-05 Paypal, Inc. Mobile devices enabling customer identity validation via central depository
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
US9992022B1 (en) * 2017-02-06 2018-06-05 Northern Trust Corporation Systems and methods for digital identity management and permission controls within distributed network nodes
EP3593313A1 (fr) * 2017-03-07 2020-01-15 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 주식회사 한국정보보호경영연구소 디지털 인감을 제공하는 블록체인 기반의 전자문서 관리 시스템

Also Published As

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

Similar Documents

Publication Publication Date Title
US20180205546A1 (en) Systems, methods, apparatuses for secure management of legal documents
Turilli et al. The ethics of information transparency
US20130179955A1 (en) Identity Management System And Method Including Architecture For The Same
EP3864608A1 (fr) Système et procédé d'identification multiple par contrats intelligents sur chaîne de blocs
US20160065608A1 (en) Monitoring security risks to enterprise corresponding to access rights and access risk calculation
EP3251046A2 (fr) Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
Sayegh et al. Blockchain application in insurance and reinsurance
US20200118234A1 (en) System and Method for Supplier Information Management
CA2801659A1 (fr) Systeme et procede de gestion d'identite et architecture connexe
AU2017349457A2 (en) Regulatory compliance system and method
US10467632B1 (en) Systems and methods for a multi-tiered fraud alert review
Putri et al. E-Finance transformation: A study of M-Wallet adoption in Indonesia
Didenko et al. Central bank digital currencies as a potential response to some particularly Pacific problems
Gupta et al. Overview of Technology Solutions
Akande Disruptive power of blockchain on the insurance industry
US20080265014A1 (en) Credit Relationship Management
Gupta et al. Towards risk managed cloud adoption: A conceptual framework
Bartolini et al. Cloud providers viability: How to address it from an IT and legal perspective?
EP3909216A1 (fr) Plateforme de transmission securisée de données personnelles perfectionnée
US20180225366A1 (en) Automatically performing funeral related actions
Ferris The ISO PIA standard for financial services
Hanson et al. Distributed Ledgers
McKechnie et al. Proposed Modifications to Spur Consumer Adoption of Blockchain
Strebinger et al. Privacy concerns and consumer acceptance of blockchain-enabled services
Sumathi et al. Data Marts and Data Warehouse

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210507

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20231222