Workflow KYB

​

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.

​

Sequenza corrente del workflow

​

1. Crea il customer business

Crea il customer business con POST /v3/customers. Leggi il customer corrente con GET /v3/customers/{customerId}.

​

2. Mantieni i related party

Usa GET /v3/customers/{customerId}/related-parties per esaminare i party correnti, POST /v3/customers/{customerId}/related-parties per crearne uno e PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} 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. Richiedi una capability available o beta solo quando il customer e’ eleggibile, usando POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Leggi i task correnti

Elenca il lavoro corrente con GET /v3/customers/{customerId}/tasks. Recupera ogni task azionabile tramite GET /v3/customers/{customerId}/tasks/{taskId}, 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. 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. 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}, la capability con GET /v3/customers/{customerId}/capabilities/{capabilityId}, le sue application con GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications e ogni task corrente. Per la meccanica completa, consulta onboarding business, Capability e task e la guida ai documenti di integrazione.

​

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

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

​

Motivi comuni di rifiuto

​

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.