Workflow KYB

​

Workflow KYB

Le workflow KYB combine les ressources actuelles de client, partie liée, capacité, tâche, soumission et document avec un examen politique de l’entreprise et de sa propriété.

​

Séquence actuelle du workflow

​

1. Créer le client professionnel

Créez le client professionnel avec POST /v3/customers. Lisez le client actuel avec GET /v3/customers/{customerId}.

​

2. Maintenir les parties liées

Utilisez GET /v3/customers/{customerId}/related-parties pour examiner les parties actuelles, POST /v3/customers/{customerId}/related-parties pour en créer une, et PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} pour mettre à jour les faits fournis. Maintenez les propriétaires directs, les entités mères, les UBO, les personnes ayant le contrôle, les administrateurs, les dirigeants et les signataires demandés par les tâches actuelles. Leurs rôles sont distincts.

​

3. Découvrir et demander une capacité éligible

Lisez GET /v3/customers/{customerId}/capabilities/supported. Demandez une capacité available ou beta uniquement lorsque le client est éligible, en utilisant POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Lire les tâches actuelles

Listez le travail actuel avec GET /v3/customers/{customerId}/tasks. Récupérez chaque tâche actionnable via GET /v3/customers/{customerId}/tasks/{taskId}, puis dérivez l’action suivante de sa révision, ses exigences et ses sessions actuelles.

​

5. Téléverser les documents demandés par la tâche actuelle

Téléversez un fichier demandé avec POST /v3/customers/{customerId}/documents. La tâche actuelle détermine si un document est requis et peut restreindre son type, son nombre ou son format acceptés.

​

6. Soumettre des réponses de tâche complètes

Soumettez un ensemble complet de réponses pour la révision de tâche actuelle avec POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Utilisez les ids d’exigence actuels et référencez les ids de document téléversés uniquement là où la tâche les demande.

​

7. Surveiller les ressources actuelles

Après chaque action ou événement, récupérez à nouveau le client avec GET /v3/customers/{customerId}, la capacité avec GET /v3/customers/{customerId}/capabilities/{capabilityId}, ses applications avec GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications, et toutes les tâches actuelles. Pour la mécanique complète, consultez onboarding professionnel, Capacités et tâches, et le guide des documents d’intégration.

​

Déclencheurs de due diligence renforcée (EDD)

L’EDD peut être requise pour :

• Les juridictions à haut risque
• Les verticaux à haut risque, y compris le gaming, le trading et les échanges crypto
• Les structures de propriété complexes
• Un volume mensuel prévu dépassant les seuils applicables
• Les opérations impliquant des pays sanctionnés

​

Résultats de l’examen politique

Résultat : Approbation KYB, approbation conditionnelle avec plafonds ou rejet. Ce sont des résultats d’examen politique, non des valeurs de statut API actuelles. Une décision politique conditionnelle peut être reflétée à travers les ressources actuelles sans créer un statut nommé « approbation conditionnelle ».

​

Calendrier de vérification

Ces durées sont des estimations politiques typiques, non un comportement API garanti.

​

Raisons courantes de rejet

​

Termes politiques et états API

Gardez les décisions politiques séparées des vocabulaires de ressources actuels :

• Statut de capacité : pending, ready, restricted, rejected, canceled
• Statut d’application : requested, in_review, action_required, ready, rejected, disabled, canceled
• Statut de tâche : action_required, in_review, satisfied, rejected, canceled
• Résultat de soumission : in_review, accepted, changes_requested, rejected

Lisez la dernière ressource plutôt que de traduire un résultat politique en valeur API.