Stato e workflow KYC

​

Stato di verifica e workflow

Il percorso KYC visto dalla policy va dalla raccolta di informazioni tramite la revisione fino a una decisione di approvazione o rifiuto. Le risorse API correnti espongono cicli di vita separati per capability, application, task e submission.

​

Concetti di revisione visti dalla policy

Questi concetti di revisione visti dalla policy descrivono il percorso di onboarding. Non sono enum API correnti, valori di webhook o transizioni garantite. Usa queste etichette solo quando discuti il percorso di policy. Non inviarle come valori di status correnti a meno che uno schema generato corrente non richieda esplicitamente lo stesso valore nel proprio contesto.

​

Flusso di revisione KYC Standard

1. Crea il cliente individuale.
2. Scopri e richiedi una capability idonea.
3. Leggi il dettaglio del task corrente.
4. Invia il cliente a una sessione di verifica hosted di prima parte o invia le risposte complete al task richieste dal task.
5. Lascia procedere la revisione mentre le risorse correnti riportano i propri stati di revisione.
6. Rileggi le risorse correnti per determinare se e’ richiesta altra azione o se la capability e’ ready, restricted, rejected o canceled.

Il percorso di policy puo’ descrivere questo come not started, pending verification, under review e poi approved o rejected. Quei termini non definiscono la sequenza di transizione dell’API.

​

Flusso di revisione KYC Enhanced

1. Completa il lavoro di identita’ e liveness standard attualmente richiesto.
2. Leggi l’ultimo task quando la revisione enhanced richiede informazioni aggiuntive.
3. Fornisci le prove di indirizzo, prove dei fondi o altre evidenze richieste tramite la sessione hosted corrente o la task submission.
4. Carica documenti solo quando il task corrente li richiede.
5. Continua a monitorare le risorse correnti durante la revisione manuale.
6. Fermati o prosegui in base agli stati correnti di capability, application, task e submission.

Il team compliance puo’ anche coordinare una revisione enhanced tramite l’indirizzo email registrato del cliente.

​

Motivi comuni di rifiuto

​

Tempistica di verifica

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

​

Vocabolari degli stati API correnti

Le risorse correnti usano vocabolari chiusi separati:

• 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

Non collassare questi vocabolari in un unico status di verifica.

​

Eventi e stato corrente

Usa i Webhook documentati attualmente come notifiche di modifica, poi rileggi le risorse correnti di customer, capability, application e task. Gli eventi non sostituiscono le letture autorevoli delle risorse e nessuna etichetta vista dalla policy implica un evento particolare. Consulta Capability e task per il loop di azione corrente.

​

Supporto

Per domande sulla policy KYC, contatta compliance@swipelux.com. Per problemi API, contatta support@swipelux.com.