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

# Flujo de trabajo KYB

> Sigue la secuencia actual de onboarding de empresas junto con la revisión KYB, la EDD, los tiempos y la política de rechazo.

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

<Warning>
  Los resultados y los plazos del KYB son estimaciones de política. No garantizan
  transiciones de la API, aprobación o disponibilidad.
</Warning>

## Secuencia actual del flujo de trabajo

### 1. Crea el cliente empresa

Crea el cliente empresa con [`POST /v3/customers`](/api-reference/customers/post-v3-customers). Lee el cliente actual con [`GET /v3/customers/{customerId}`](/api-reference/customers/get-v3-customers-by-customer-id).

### 2. Mantén las partes relacionadas

Utiliza [`GET /v3/customers/{customerId}/related-parties`](/api-reference/customers/get-v3-customers-by-customer-id-related-parties) para revisar las partes actuales, [`POST /v3/customers/{customerId}/related-parties`](/api-reference/customers/post-v3-customers-by-customer-id-related-parties) para crear una y [`PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId}`](/api-reference/customers/patch-v3-customers-by-customer-id-related-parties-by-related-party-id) 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`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-supported). Solicita una capacidad disponible o en beta únicamente cuando el cliente sea elegible, utilizando [`POST /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id).

### 4. Lee las tareas actuales

Lista el trabajo actual con [`GET /v3/customers/{customerId}/tasks`](/api-reference/tasks/list-customer-tasks). Obtén cada tarea accionable mediante [`GET /v3/customers/{customerId}/tasks/{taskId}`](/api-reference/tasks/get-customer-task) 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`](/api-reference/documents/post-v3-customers-by-customer-id-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`](/api-reference/task-submissions/create-customer-task-submission). 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}`](/api-reference/customers/get-v3-customers-by-customer-id), la capacidad con [`GET /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id), sus aplicaciones con [`GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-applications) y cualquier tarea actual.

Para la mecánica completa, consulta [onboarding de empresas](/es/integration/onboarding/customers#business-customers), [Capacidades y tareas](/es/integration/onboarding/capabilities-and-requirements#complete-current-tasks) y la [guía de Documentos de la integración](/es/integration/onboarding/capabilities-and-requirements#upload-documents).

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

| Etapa                | Duración típica   |
| -------------------- | ----------------- |
| Subida de documentos | Inmediata         |
| Revisión inicial     | 1-2 días hábiles  |
| KYB estándar         | 2-5 días hábiles  |
| EDD, si se dispara   | 5-10 días hábiles |

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

## Motivos comunes de rechazo

| Motivo                             | Resolución                                                                     |
| ---------------------------------- | ------------------------------------------------------------------------------ |
| Documentos faltantes               | Proporciona cada tipo de documento solicitado por la tarea actual              |
| Documentos poco claros o borrosos  | Proporciona escaneos o imágenes de mayor calidad                               |
| Información no coincidente         | Asegúrate de que el nombre de la entidad coincida en toda la evidencia enviada |
| Estructura de propiedad incompleta | Proporciona evidencia que dé cuenta del 100 % de la propiedad                  |
| Documentos expirados               | Proporciona documentos vigentes y válidos                                      |

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


## Related topics

- [Estado y flujo del KYC](/es/knowledge-base/individual-onboarding/status-and-workflow.md)
- [Recibir fondos](/es/integration/receive-funds.md)
- [Referencia de la API](/es/api-reference/introduction.md)
- [Emitir una cuenta bancaria](/es/integration/issue-bank-account.md)
- [Flujos comunes](/es/integration/common-flows.md)