Passer au contenu principal
Personnes clés est le modèle unifié de Didit pour chaque personne physique et chaque entité morale liée à l’entreprise que vous vérifiez : bénéficiaires effectifs (UBO), actionnaires (personnes physiques et morales), dirigeants, représentants et autres fonctions de direction. Un seul parcours Personnes clés couvre l’ensemble, avec un routage de la vérification adapté au rôle et une comparaison complète, côte à côte, entre les parties issues du registre et celles soumises par l’utilisateur.
Pour la vue Entreprises des personnes clés (comment les dirigeants et les UBO sont agrégés d’une session à l’autre), voir Entreprises → Personnes clés.

​
Fonctionnement

1

Préremplissage depuis le registre (facultatif)

Si le workflow active le préremplissage depuis le registre, l’écran Personnes clés est prérempli avec les bénéficiaires effectifs, actionnaires et dirigeants disponibles, extraits de la vérification du registre. L’utilisateur final peut modifier, ajouter ou supprimer des parties avant de soumettre, même lorsque les informations d’actionnariat sont encore en attente. Les dirigeants déjà reçus restent disponibles pendant la collecte du rapport d’actionnariat. Avant la soumission, les résultats tardifs remplissent les champs non modifiés et ajoutent les personnes manquantes, sans remplacer les modifications ni rétablir les parties supprimées. Une fenêtre d’édition ouverte reste inchangée ; le préremplissage complémentaire est appliqué après que le demandeur l’a fermée. Lorsque le préremplissage depuis le registre est désactivé, les demandeurs saisissent eux-mêmes les personnes, et les résultats tardifs ne remplissent pas ce formulaire. Les données du registre reçues après la soumission restent intégrées aux preuves du registre, mais ne modifient pas la liste des personnes soumise et ne créent pas automatiquement de sessions enfants de vérification supplémentaires.
2

Soumission depuis le parcours hébergé

L’utilisateur final soumet la liste définitive des personnes clés via le parcours de vérification hébergé. Par défaut, vous n’avez pas à appeler cette étape vous-même : elle se déroule dans le parcours KYB dont vous avez transmis l’URL à partir de Créer une session. Pour conserver votre propre interface, utilisez les endpoints brouillon de partie et soumettre les parties.
3

Routage de la vérification selon le rôle

Pour chaque partie soumise, Didit vérifie les paramètres de vérification configurés pour le rôle :
  • Applique le seuil d’actionnariat du workflow : les UBO et actionnaires en dessous du pourcentage configuré ne nécessitent pas de vérification individuelle.
  • Tient compte du drapeau « ignorer la vérification » défini par l’utilisateur final, si le rôle autorise cette option.
  • Crée une session enfant de vérification des utilisateurs (KYC) pour les parties personnes physiques qui nécessitent un KYC.
  • Crée une sous-session KYB enfant pour les UBO personnes morales lorsque le KYB imbriqué est activé sur le workflow.
4

Progression du statut

Le statut de la fonctionnalité Personnes clés passe à Awaiting User tant qu’une session enfant requise est en cours. Lorsque toutes les sessions enfants sont terminées, le statut se consolide en Approved, Declined ou In Review selon les résultats.

​
Rôles collectés

Les personnes clés peuvent porter un ou plusieurs des rôles suivants : une même personne peut en cumuler plusieurs (par exemple, dirigeant et actionnaire). Voici la taxonomie complète : Chaque rôle peut être configuré individuellement dans le workflow : activé ou désactivé, requis ou facultatif pour le KYC, associé à un workflow KYC spécifique et, si besoin, ignorable. Voir Actionnariat pour le détail de la répartition des vérifications.

​
Données collectées pour chaque personne clé

Le parcours hébergé demande un ensemble de champs par défaut ainsi que des champs personnalisés configurés dans le workflow. Voir Actionnariat → Champs collectés pour la liste complète.

​
Confirmation du registre

Avant l’étape Personnes clés, l’utilisateur final examine les données de l’entreprise extraites de la vérification du registre et peut éventuellement modifier n’importe quel champ. Le parcours hébergé stocke ensuite :
  • Le détail du registre que Didit a normalisé à partir de la vérification du registre (registry_data).
  • Les données confirmées par l’utilisateur (user_provided_data), avec un horodatage qui indique le moment de la confirmation.
  • Une vue canonique fusionnée sur les champs de premier niveau de l’entreprise : données confirmées par l’utilisateur lorsqu’elles existent, données du registre à défaut.
Voir Données de l’entreprise → Registre et données fournies par l’utilisateur pour le modèle complet.

​
Structure dans la réponse de décision

Après la soumission, les personnes clés collectées apparaissent dans la décision KYB sous key_people_checks[], réparties en deux groupes : registre (ce que le fournisseur a communiqué) et soumises (ce que l’administrateur de l’entreprise a confirmé via le parcours), ainsi qu’un ubo_kyc_summary qui récapitule la progression du KYC des UBO. Voir la référence complète de key_people_checks.

​
Comportement en cas de nouvelle soumission

  • Personnes clés et Vérification du Registre ne peuvent pas être soumises à nouveau directement. Pour revérifier une personne précise, soumettez à nouveau sa session KYC enfant.
  • Lorsqu’une session KYC enfant est soumise à nouveau, le statut de la fonctionnalité Personnes clés parente revient automatiquement à Awaiting User.
  • Lorsque la session enfant soumise à nouveau est terminée, le statut parent est recalculé à partir des statuts de toutes les sessions enfants.
  • Une session enfant supprimée, ou expirée avant que la personne ne la démarre, ne peut pas être soumise à nouveau : régénérez la partie pour émettre un nouveau lien sur la même partie.

​
Durée de validité du lien de vérification des personnes clés

La session KYC enfant d’une personne clé suit la durée d’expiration de la session définie dans le workflow KYC configuré pour son rôle, et non celle du workflow KYB. Si vous associez un rôle à un workflow KYC qui autorise quatre semaines, le lien de cette personne reste utilisable pendant quatre semaines, même si la session KYB est configurée pour expirer plus tôt. La valeur est un paramètre propre à chaque workflow, comprise entre 1 heure et 4 semaines (session_expiration_time, en secondes), dans Workflows → [workflow KYC] → Settings. L’expiration change ce que vous pouvez faire avec la partie. Un lien expiré avant que la personne ne commence, comme celui d’une session supprimée, peut être réémis avec Régénérer une session KYC pour les personnes clés. Les sessions supprimées sont éligibles, même si la personne a déjà commencé ou terminé la vérification. Les sessions importées ne sont pas éligibles par expiration : elles doivent avoir été supprimées. Une session qui n’a pas été supprimée et que la personne a déjà commencée n’est pas éligible par expiration.

​
Options de configuration

Tous les paramètres des personnes clés sont configurés par workflow depuis la Business Console : Configurez-les dans Workflows → [workflow KYB] → Key People de la console.

​
Réutilisation des personnes vérifiées entre les contrôles KYB

Lorsque Réutiliser les personnes vérifiées est activé sur un workflow (valeur par défaut), une personne clé n’a pas à refaire un KYC à chaque fois qu’elle apparaît dans un nouveau contrôle KYB. Didit recherche un KYC approuvé existant issu d’un contrôle KYB précédent et le relie à la nouvelle partie, au lieu de créer une nouvelle session KYC enfant.
Ce mécanisme est distinct du KYC réutilisable, qui permet à un utilisateur final de reprendre volontairement une session terminée dans des applications distinctes intégrant Didit, au moyen d’un jeton de partage/importation. Le paramètre de réutilisation KYB décrit sur cette page est automatique, défini dans le workflow et limité aux personnes clés d’une même application : il n’utilise aucun jeton de partage et ne nécessite aucune action de l’utilisateur final.
Correspondance. Une correspondance possible est trouvée en comparant le nom complet fourni pour la personne (sans tenir compte de la casse ni des espaces superflus) avec les personnes clés des autres contrôles KYB de l’application. Il n’existe aucun autre critère de correspondance : un numéro de document, un e-mail ou un numéro de téléphone n’est ni requis ni vérifié. Un nom saisi avec une orthographe différente, un deuxième prénom ou une translittération ne correspondra pas, et, dans de rares cas, deux personnes différentes portant le même nom peuvent correspondre. Gardez cela à l’esprit lorsque vous examinez les résultats des personnes clés. Périmètre. La recherche porte sur tous les autres contrôles KYB appartenant à la même application, et non uniquement sur le contrôle KYB en cours, ni sur les autres applications de votre organisation. Une personne vérifiée en tant qu’UBO de l’entreprise A peut être retrouvée lorsqu’elle apparaît plus tard comme dirigeant de l’entreprise B, à condition que les deux contrôles s’exécutent sous la même application. Statuts éligibles. Seul le KYC Approuvé le plus récent d’une partie peut être réutilisé. Un KYC Refusé pour ce nom bloque entièrement la réutilisation : la partie est signalée et un nouveau KYC est demandé, au lieu de revenir au KYC refusé. Un KYC encore En cours d’examen n’est jamais considéré comme candidat. Conservation. La recherche ne prend en compte que les sessions KYC créées au cours d’environ la dernière année et non supprimées. Si la seule session correspondante est en dehors de cette période, ou si la personne ou l’organisation l’a supprimée, le contrôle ne trouve aucune correspondance éligible et demande silencieusement un nouveau KYC. Il n’échoue jamais et ne bloque jamais la soumission des personnes clés. Facturation. Un KYC réutilisé n’est pas facturé à nouveau. Relier une session déjà approuvée à la nouvelle partie n’entraîne aucun frais supplémentaire : vous n’êtes facturé qu’une seule fois, sur le KYC d’origine.
Example

​
Étapes suivantes

Actionnariat

Champs collectés, données personnalisées et rapprochement entre les données du registre et les données soumises.

Dirigeants et représentants

Rôles de gouvernance au sein du modèle des personnes clés.

Schéma de la réponse

Référence champ par champ de key_people_checks[].
Dernière modification le 7 novembre 2026