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

> Segui la sequenza corrente di onboarding business insieme a revisione KYB, EDD, tempistiche e policy di rifiuto.

## Workflow KYB

Il workflow KYB combina risorse correnti di customer, related-party, capability, task, submission e document con una revisione di policy del business e della sua ownership.

<Warning>
  Gli esiti e le tempistiche del KYB sono stime di policy. Non garantiscono transizioni API, approvazione o disponibilita'.
</Warning>

## Sequenza corrente del workflow

### 1. Crea il customer business

Crea il customer business con [`POST /v3/customers`](/api-reference/customers/post-v3-customers). Leggi il customer corrente con [`GET /v3/customers/{customerId}`](/api-reference/customers/get-v3-customers-by-customer-id).

### 2. Mantieni i related party

Usa [`GET /v3/customers/{customerId}/related-parties`](/api-reference/customers/get-v3-customers-by-customer-id-related-parties) per esaminare i party correnti, [`POST /v3/customers/{customerId}/related-parties`](/api-reference/customers/post-v3-customers-by-customer-id-related-parties) per crearne uno e [`PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId}`](/api-reference/customers/patch-v3-customers-by-customer-id-related-parties-by-related-party-id) per aggiornare i fatti forniti.

Mantieni proprietari diretti, entita' capogruppo, UBO, control person, director, officer e firmatari richiesti dai task correnti. I loro ruoli sono distinti.

### 3. Scopri e richiedi una capability idonea

Leggi [`GET /v3/customers/{customerId}/capabilities/supported`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-supported). Richiedi una capability available o beta solo quando il customer e' eleggibile, usando [`POST /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/post-v3-customers-by-customer-id-capabilities-by-capability-id).

### 4. Leggi i task correnti

Elenca il lavoro corrente con [`GET /v3/customers/{customerId}/tasks`](/api-reference/tasks/list-customer-tasks). Recupera ogni task azionabile tramite [`GET /v3/customers/{customerId}/tasks/{taskId}`](/api-reference/tasks/get-customer-task), quindi ricava l'azione successiva dalla sua revisione, requisiti e sessioni correnti.

### 5. Carica i documenti richiesti dal task corrente

Carica un file richiesto con [`POST /v3/customers/{customerId}/documents`](/api-reference/documents/post-v3-customers-by-customer-id-documents). Il task corrente determina se un documento e' richiesto e puo' restringerne il tipo accettato, il numero o il formato.

### 6. Invia risposte complete ai task

Invia un set completo di risposte per la revisione del task corrente con [`POST /v3/customers/{customerId}/tasks/{taskId}/submissions`](/api-reference/task-submissions/create-customer-task-submission). Usa gli id di requisito correnti e referenzia gli id dei documenti caricati solo dove il task lo richiede.

### 7. Monitora le risorse correnti

Dopo ogni azione o evento, rileggi il customer con [`GET /v3/customers/{customerId}`](/api-reference/customers/get-v3-customers-by-customer-id), la capability con [`GET /v3/customers/{customerId}/capabilities/{capabilityId}`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id), le sue application con [`GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications`](/api-reference/capabilities/get-v3-customers-by-customer-id-capabilities-by-capability-id-applications) e ogni task corrente.

Per la meccanica completa, consulta [onboarding business](/it/integration/onboarding/customers#business-customers), [Capability e task](/it/integration/onboarding/capabilities-and-requirements#complete-current-tasks) e la [guida ai documenti di integrazione](/it/integration/onboarding/capabilities-and-requirements#upload-documents).

## Trigger dell'Enhanced Due Diligence (EDD)

L'EDD puo' essere richiesta per:

* Giurisdizioni ad alto rischio
* Verticali ad alto rischio, inclusi gaming, trading e crypto exchange
* Strutture di ownership complesse
* Volume mensile atteso superiore alle soglie applicabili
* Operazioni che coinvolgono Paesi sanzionati

## Esiti della revisione di policy

**Esito:** approvazione KYB, approvazione condizionata con limiti o rifiuto.

Questi sono esiti di revisione di policy, non valori di stato API correnti. Una decisione di policy condizionata puo' essere riflessa tramite risorse correnti senza creare uno stato chiamato "conditional approval".

## Tempistica di verifica

| Fase               | Durata tipica          |
| ------------------ | ---------------------- |
| Upload documenti   | Immediato              |
| Revisione iniziale | 1-2 giorni lavorativi  |
| KYB standard       | 2-5 giorni lavorativi  |
| EDD, se attivata   | 5-10 giorni lavorativi |

Queste durate sono stime tipiche di policy, non comportamento API garantito.

## Motivi comuni di rifiuto

| Motivo                            | Risoluzione                                                                      |
| --------------------------------- | -------------------------------------------------------------------------------- |
| Documenti mancanti                | Fornisci ogni tipo di documento richiesto dal task corrente                      |
| Documenti poco chiari o sfocati   | Fornisci scansioni o immagini di qualita' superiore                              |
| Informazioni non corrispondenti   | Assicurati che la denominazione dell'entita' corrisponda tra le evidenze inviate |
| Struttura di ownership incompleta | Fornisci evidenze che rendano conto del 100% dell'ownership                      |
| Documenti scaduti                 | Fornisci documenti correnti e validi                                             |

## Termini di policy e stati API

Tieni separate le decisioni di policy dai vocabolari delle risorse correnti:

* **Status della capability:** `pending`, `ready`, `restricted`, `rejected`, `canceled`
* **Status dell'application:** `requested`, `in_review`, `action_required`, `ready`, `rejected`, `disabled`, `canceled`
* **Status del task:** `action_required`, `in_review`, `satisfied`, `rejected`, `canceled`
* **Outcome della submission:** `in_review`, `accepted`, `changes_requested`, `rejected`

Leggi l'ultima risorsa invece di tradurre un esito di policy in un valore API.


## Related topics

- [Panoramica](/it/knowledge-base/compliance/overview.md)
- [Stato e workflow KYC](/it/knowledge-base/individual-onboarding/status-and-workflow.md)
- [Governance e ruoli](/it/knowledge-base/compliance/governance-retention-and-privacy.md)
- [Workflow API di onboarding individuale](/it/knowledge-base/individual-onboarding/api-workflow.md)
- [Migrare a v3](/it/api-reference/versioning/migrate-to-v3.md)