Flujo de trabajo KYB

​

Flujo de trabajo KYB

El flujo de trabajo KYB combina los recursos actuales de cliente, partes relacionadas, capacidad, tarea, envío y documento con una revisión de política de la empresa y su propiedad.

​

Secuencia actual del flujo de trabajo

​

1. Crea el cliente empresa

Crea el cliente empresa con POST /v3/customers. Lee el cliente actual con GET /v3/customers/{customerId}.

​

2. Mantén las partes relacionadas

Utiliza GET /v3/customers/{customerId}/related-parties para revisar las partes actuales, POST /v3/customers/{customerId}/related-parties para crear una y PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} para actualizar los hechos proporcionados. Mantén a los propietarios directos, entidades matrices, UBOs, personas de control, directores, funcionarios y firmantes solicitados por las tareas actuales. Sus roles son distintos.

​

3. Descubre y solicita una capacidad elegible

Lee GET /v3/customers/{customerId}/capabilities/supported. Solicita una capacidad disponible o en beta únicamente cuando el cliente sea elegible, utilizando POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Lee las tareas actuales

Lista el trabajo actual con GET /v3/customers/{customerId}/tasks. Obtén cada tarea accionable mediante GET /v3/customers/{customerId}/tasks/{taskId} y luego deriva la siguiente acción de su revisión, requisitos y sesiones actuales.

​

5. Sube los documentos solicitados por la tarea actual

Sube un archivo solicitado con POST /v3/customers/{customerId}/documents. La tarea actual determina si se requiere un documento y puede restringir su tipo, cantidad o formato aceptado.

​

6. Envía respuestas completas de la tarea

Envía un conjunto completo de respuestas para la revisión de la tarea actual con POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Utiliza los ids de requisitos actuales y referencia los ids de documentos subidos solo donde la tarea lo solicite.

​

7. Monitorea los recursos actuales

Después de cada acción o evento, vuelve a obtener el cliente con GET /v3/customers/{customerId}, la capacidad con GET /v3/customers/{customerId}/capabilities/{capabilityId}, sus aplicaciones con GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications y cualquier tarea actual. Para la mecánica completa, consulta onboarding de empresas, Capacidades y tareas y la guía de Documentos de la integración.

​

Disparadores de Enhanced Due Diligence (EDD)

La EDD puede requerirse por:

• Jurisdicciones de alto riesgo
• Verticales de alto riesgo, incluidos gaming, trading e intercambios de cripto
• Estructuras de propiedad complejas
• Volumen mensual esperado que supere los umbrales aplicables
• Operaciones que impliquen países sancionados

​

Resultados de la revisión de política

Resultado: aprobación KYB, aprobación condicional con caps o rechazo. Estos son resultados de revisión de política, no valores actuales de estado de la API. Una decisión condicional de política puede reflejarse a través de los recursos actuales sin crear un estado llamado “aprobación condicional”.

​

Plazos de verificación

Estas duraciones son estimaciones típicas de política, no comportamiento garantizado de la API.

​

Motivos comunes de rechazo

​

Términos de política y estados de la API

Mantén las decisiones de política separadas de los vocabularios de recursos actuales:

• Estado de la capacidad: pending, ready, restricted, rejected, canceled
• Estado de la aplicación: requested, in_review, action_required, ready, rejected, disabled, canceled
• Estado de la tarea: action_required, in_review, satisfied, rejected, canceled
• Resultado del envío: in_review, accepted, changes_requested, rejected

Lee el último recurso en lugar de traducir un resultado de política a un valor de API.