Flux de treball KYB

​

Flux de treball KYB

El flux de treball KYB combina els recursos actuals de client, part relacionada, capacitat, tasca, enviament i document amb una revisió de política del negoci i la seva propietat.

​

Seqüència actual del flux de treball

​

1. Crea el client de negoci

Crea el client de negoci amb POST /v3/customers. Llegeix el client actual amb GET /v3/customers/{customerId}.

​

2. Manté les parts relacionades

Utilitza GET /v3/customers/{customerId}/related-parties per revisar les parts actuals, POST /v3/customers/{customerId}/related-parties per crear-ne una, i PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} per actualitzar els fets proporcionats. Manté els propietaris directes, les entitats matrius, els UBOs, les persones de control, els directors, els càrrecs i els signants sol·licitats per les tasques actuals. Els seus rols són diferenciats.

​

3. Descobreix i sol·licita una capacitat elegible

Llegeix GET /v3/customers/{customerId}/capabilities/supported. Sol·licita una capacitat disponible o beta només quan el client sigui elegible, utilitzant POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Llegeix les tasques actuals

Llista el treball actual amb GET /v3/customers/{customerId}/tasks. Obté cada tasca accionable mitjançant GET /v3/customers/{customerId}/tasks/{taskId}, i després deriva la següent acció de la seva revisió, requisits i sessions actuals.

​

5. Puja els documents sol·licitats per la tasca actual

Puja un fitxer sol·licitat amb POST /v3/customers/{customerId}/documents. La tasca actual determina si es requereix un document i pot restringir el seu tipus, nombre o format acceptats.

​

6. Envia respostes de tasca completes

Envia un conjunt complet de respostes per a la revisió actual de la tasca amb POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Utilitza els ids de requisit actuals i referencia els ids de document pujats només quan la tasca ho demani.

​

7. Monitoritza els recursos actuals

Després de cada acció o esdeveniment, torna a obtenir el client amb GET /v3/customers/{customerId}, la capacitat amb GET /v3/customers/{customerId}/capabilities/{capabilityId}, les seves aplicacions amb GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications i qualsevol tasca actual. Per a la mecànica completa, consulta incorporació de negocis, Capacitats i tasques i la guia de documents de la integració.

​

Activadors de deguda diligència reforçada (EDD)

L’EDD pot ser requerida per:

• Jurisdiccions d’alt risc
• Verticals d’alt risc, incloent joc, trading i intercanvis cripto
• Estructures de propietat complexes
• Volum mensual previst que superi els llindars aplicables
• Operacions que involucrin països sancionats

​

Resultats de la revisió de política

Resultat: Aprovació KYB, aprovació condicional amb topalls o rebuig. Aquests són resultats de revisió de política, no valors d’estat actuals de l’API. Una decisió de política condicional es pot reflectir mitjançant els recursos actuals sense crear un estat anomenat “aprovació condicional”.

​

Calendari de verificació

Aquestes durades són estimacions típiques de política, no un comportament garantit de l’API.

​

Motius comuns de rebuig

​

Termes de política i estats de l’API

Manté les decisions de política separades dels vocabularis de recursos actuals:

• Estat de capacitat: pending, ready, restricted, rejected, canceled
• Estat d’aplicació: requested, in_review, action_required, ready, rejected, disabled, canceled
• Estat de tasca: action_required, in_review, satisfied, rejected, canceled
• Resultat d’enviament: in_review, accepted, changes_requested, rejected

Llegeix el recurs més recent en lloc de traduir un resultat de política a un valor d’API.