> ## Documentation Index
> Fetch the complete documentation index at: https://docs.swipelux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow KYB

> Suivez la séquence actuelle d'onboarding professionnel avec l'examen KYB, l'EDD, les délais et la politique de rejet.

## 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é.

<Warning>
  Les résultats et les délais KYB sont des estimations politiques. Ils ne garantissent pas les transitions
  API, l'approbation ou la disponibilité.
</Warning>

## Séquence actuelle du workflow

### 1. Créer le client professionnel

Créez le client professionnel avec [`POST /v3/customers`](/api-reference/customers/post-v3-customers). Lisez le client actuel avec [`GET /v3/customers/{customerId}`](/api-reference/customers/get-v3-customers-by-customer-id).

### 2. Maintenir les parties liées

Utilisez [`GET /v3/customers/{customerId}/related-parties`](/api-reference/customers/get-v3-customers-by-customer-id-related-parties) pour examiner les parties actuelles, [`POST /v3/customers/{customerId}/related-parties`](/api-reference/customers/post-v3-customers-by-customer-id-related-parties) pour en créer une, et [`PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId}`](/api-reference/customers/patch-v3-customers-by-customer-id-related-parties-by-related-party-id) 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`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-supported). Demandez une capacité `available` ou `beta` uniquement lorsque le client est éligible, en utilisant [`POST /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id).

### 4. Lire les tâches actuelles

Listez le travail actuel avec [`GET /v3/customers/{customerId}/tasks`](/api-reference/tasks/list-customer-tasks). Récupérez chaque tâche actionnable via [`GET /v3/customers/{customerId}/tasks/{taskId}`](/api-reference/tasks/get-customer-task), 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`](/api-reference/documents/post-v3-customers-by-customer-id-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`](/api-reference/task-submissions/create-customer-task-submission). 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}`](/api-reference/customers/get-v3-customers-by-customer-id), la capacité avec [`GET /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id), ses applications avec [`GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-applications), et toutes les tâches actuelles.

Pour la mécanique complète, consultez [onboarding professionnel](/fr/integration/onboarding/customers#business-customers), [Capacités et tâches](/fr/integration/onboarding/capabilities-and-requirements#complete-current-tasks), et le [guide des documents d'intégration](/fr/integration/onboarding/capabilities-and-requirements#upload-documents).

## 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

| Étape                      | Durée typique          |
| -------------------------- | ---------------------- |
| Téléversement de documents | Immédiat               |
| Examen initial             | 1 à 2 jours ouvrables  |
| KYB standard               | 2 à 5 jours ouvrables  |
| EDD, si déclenchée         | 5 à 10 jours ouvrables |

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

## Raisons courantes de rejet

| Raison                            | Résolution                                                                   |
| --------------------------------- | ---------------------------------------------------------------------------- |
| Documents manquants               | Fournir chaque type de document demandé par la tâche actuelle                |
| Documents flous ou peu clairs     | Fournir des scans ou des images de meilleure qualité                         |
| Informations incompatibles        | S'assurer que le nom de l'entité correspond dans toutes les preuves soumises |
| Structure de propriété incomplète | Fournir des preuves qui rendent compte de 100 % de la propriété              |
| Documents expirés                 | Fournir des documents actuels et valides                                     |

## 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.


## Related topics

- [Vue d'ensemble](/fr/knowledge-base/compliance/overview.md)
- [Gouvernance et rôles](/fr/knowledge-base/compliance/governance-retention-and-privacy.md)
- [Statut et workflow KYC](/fr/knowledge-base/individual-onboarding/status-and-workflow.md)
- [Workflow API d'onboarding individuel](/fr/knowledge-base/individual-onboarding/api-workflow.md)
- [Migrer vers v3](/fr/api-reference/versioning/migrate-to-v3.md)