KYB-workflow

​

KYB-workflow

KYB-workflow-en kombinerer gjeldende kunde-, nærstående-, capability-, oppgave-, innsendings- og dokumentressurser med en policygjennomgang av virksomheten og dens eierskap.

​

Gjeldende workflow-sekvens

​

1. Opprett virksomhetskunden

Opprett virksomhetskunden med POST /v3/customers. Les den gjeldende kunden med GET /v3/customers/{customerId}.

​

2. Vedlikehold nærstående parter

Bruk GET /v3/customers/{customerId}/related-parties for å gjennomgå gjeldende parter, POST /v3/customers/{customerId}/related-parties for å opprette én, og PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} for å oppdatere angitte fakta. Vedlikehold direkte eiere, morselskaper, UBO-er, kontrollpersoner, styremedlemmer, ledere og signaturer forespurt av gjeldende oppgaver. Rollene deres er distinkte.

​

3. Oppdag og be om en kvalifisert capability

Les GET /v3/customers/{customerId}/capabilities/supported. Be om en available eller beta-capability kun når kunden er kvalifisert, med POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Les gjeldende oppgaver

List gjeldende arbeid med GET /v3/customers/{customerId}/tasks. Hent hver handlingsklar oppgave via GET /v3/customers/{customerId}/tasks/{taskId}, og utled så neste handling fra dens gjeldende revisjon, krav og sesjoner.

​

5. Last opp dokumenter forespurt av den gjeldende oppgaven

Last opp en forespurt fil med POST /v3/customers/{customerId}/documents. Den gjeldende oppgaven bestemmer om et dokument er påkrevd og kan snevre inn akseptert type, antall eller format.

​

6. Send inn komplette oppgavesvar

Send inn ett komplett svarsett for den gjeldende oppgaverevisjonen med POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Bruk gjeldende krav-ID-er og refererer opplastede dokument-ID-er kun der oppgaven ber om dem.

​

7. Overvåk gjeldende ressurser

Etter hver handling eller hendelse, hent kunden på nytt med GET /v3/customers/{customerId}, capability-en med GET /v3/customers/{customerId}/capabilities/{capabilityId}, dens applications med GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications, og alle gjeldende oppgaver. For fullstendig mekanikk, se virksomhets-onboarding, Capabilities og oppgaver og Integrasjonsdokumenter-veiledningen.

​

Triggere for Enhanced Due Diligence (EDD)

EDD kan være påkrevd for:

• Høyrisiko-jurisdiksjoner
• Høyrisiko-vertikaler, inkludert gaming, trading og kryptobørser
• Komplekse eierskapsstrukturer
• Forventet månedlig volum som overstiger gjeldende terskler
• Operasjoner som involverer sanksjonerte land

​

Policy-gjennomgangsutfall

Utfall: KYB-godkjenning, betinget godkjenning med tak, eller avvisning. Dette er utfall av policygjennomgang, ikke gjeldende API-statusverdier. En betinget policybeslutning kan reflekteres via gjeldende ressurser uten å opprette en status kalt “conditional approval”.

​

Verifiseringstidslinje

Disse varighetene er typiske policy-estimater, ikke garantert API-atferd.

​

Vanlige avvisningsgrunner

​

Policybegreper og API-tilstander

Hold policybeslutninger atskilt fra gjeldende ressursordforråd:

• Capability-status: pending, ready, restricted, rejected, canceled
• Application-status: requested, in_review, action_required, ready, rejected, disabled, canceled
• Oppgavestatus: action_required, in_review, satisfied, rejected, canceled
• Innsendingsutfall: in_review, accepted, changes_requested, rejected

Les den siste ressursen i stedet for å oversette et policyutfall til en API-verdi.