Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SYSTEM AND METHOD FOR MULTIPLE IDENTIFICATION USING SMART CONTRACTS ON BLOCKCHAINS
Document Type and Number:
WIPO Patent Application WO/2020/075153
Kind Code:
A1
Abstract:
The present invention relates to a method for electronic identification, on a network, of a first party (30) in respect of at least a second party (20) comprising the establishment of a time-stamped certified document (60) containing data relating to the first party in response to a request (40) from the second party, said request being sent over an application programming interface (11) and comprising a plurality of demands to which the first party responds at least partially by sending responses (50) via said application programming interface, the method comprising: a step of storing responses (50) in a blockchain (12); a step of creating the certified document (60) based on the request from the second party, responses from the first party and responses previously stored in the blockchain.

Inventors:
GABORIEAU PHILIPPE (FR)
Application Number:
PCT/IB2019/060513
Publication Date:
April 16, 2020
Filing Date:
December 06, 2019
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
SHOYO (FR)
International Classes:
G06Q40/00; G06F21/64
Foreign References:
US20170366348A12017-12-21
US20180287800A12018-10-04
US20180005239A12018-01-04
Attorney, Agent or Firm:
DESCHAMPS, Samuel (FR)
Download PDF:
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.

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.




 
Previous Patent: A COMPOSITION AND USES THEREOF

Next Patent: ASSEMBLABLE MAT