Skip to main content

​
Statut de vérification et workflow

Le parcours KYC orienté politique passe de la collecte d’informations à l’examen puis à une décision d’approbation ou de rejet. Les ressources API actuelles exposent des cycles de vie de capacité, application, tâche et soumission séparés.
Les étiquettes d’examen politique et les estimations de délais ne définissent pas le comportement API. N’implémentez pas une machine à états à partir des étiquettes ci-dessous.

​
Concepts d’examen orientés politique

Ces concepts d’examen orientés politique décrivent le parcours d’onboarding. Ce ne sont pas des énumérations API actuelles, des valeurs de webhook ou des transitions garanties. Utilisez ces étiquettes uniquement lorsque vous discutez du parcours politique. Ne les envoyez pas comme valeurs de statut actuelles à moins qu’un schéma généré actuel ne demande explicitement la même valeur dans son propre contexte.

​
Flux d’examen KYC standard

  1. Créez le client individuel.
  2. Découvrez et demandez une capacité éligible.
  3. Lisez le détail de la tâche actuelle.
  4. Envoyez le client à une session de vérification hébergée de première partie ou soumettez les réponses complètes à la tâche demandée.
  5. Laissez l’examen s’exécuter tandis que les ressources actuelles rapportent leurs propres états d’examen.
  6. Récupérez à nouveau les ressources actuelles pour déterminer si plus d’action est requise ou si la capacité est ready, restricted, rejected ou canceled.
Le parcours politique peut décrire cela comme non commencé, en attente de vérification, en cours d’examen, puis approuvé ou rejeté. Ces termes ne définissent pas la séquence de transition API.

​
Flux d’examen KYC renforcé

  1. Terminez le travail actuel d’identité et de vivacité standard demandé.
  2. Lisez la dernière tâche lorsque l’examen renforcé demande des informations supplémentaires.
  3. Fournissez le justificatif de domicile, la preuve de fonds ou d’autres preuves demandés via la session hébergée actuelle ou la soumission de tâche.
  4. Téléversez des documents uniquement lorsque la tâche actuelle les demande.
  5. Continuez à surveiller les ressources actuelles pendant l’examen manuel.
  6. Arrêtez ou continuez en fonction des états actuels de capacité, d’application, de tâche et de soumission.
L’équipe de conformité peut également coordonner un examen renforcé via l’adresse e-mail enregistrée du client.

​
Raisons courantes de rejet

​
Calendrier de vérification

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

​
Vocabulaires d’état API actuels

Les ressources actuelles utilisent des vocabulaires fermés séparés :
  • 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
Ne fusionnez pas ces vocabulaires en un seul statut de vérification.

​
Événements et état actuel

Utilisez les Webhooks actuellement documentés comme notifications de changement, puis récupérez à nouveau les ressources actuelles de client, capacité, application et tâche. Les événements ne remplacent pas les lectures de ressource faisant autorité, et aucune étiquette orientée politique n’implique un événement particulier. Consultez Capacités et tâches pour la boucle d’action actuelle.

​
Support

Pour les questions de politique KYC, contactez compliance@swipelux.com. Pour les problèmes API, contactez support@swipelux.com.

Sujets connexes

Workflow KYBWorkflow API d'onboarding individuelCapacités et tâchesMigrer vers v3Destinataires et destinations