KYB workflow

​

KYB workflow

De KYB workflow combineert huidige customer-, related-party-, capability-, task-, submission- en document-resources met een beleidsreview van het bedrijf en zijn ownership.

​

Huidige workflow-sequence

​

1. Maak de zakelijke klant aan

Maak de zakelijke klant aan met POST /v3/customers. Lees de huidige klant met GET /v3/customers/{customerId}.

​

2. Beheer related parties

Gebruik GET /v3/customers/{customerId}/related-parties om huidige parties te bekijken, POST /v3/customers/{customerId}/related-parties om er een aan te maken en PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} om aangeleverde facts bij te werken. Beheer de directe eigenaren, parent entities, UBO’s, control persons, directors, officers en signers waar huidige taken om vragen. Hun rollen zijn verschillend.

​

3. Ontdek en vraag een eligible capability aan

Lees GET /v3/customers/{customerId}/capabilities/supported. Vraag een available of beta capability alleen aan wanneer de klant eligible is, met POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Lees huidige taken

Bekijk huidig werk met GET /v3/customers/{customerId}/tasks. Haal elke actionable taak op via GET /v3/customers/{customerId}/tasks/{taskId} en leid dan de volgende actie af uit de huidige revisie, requirements en sessies.

​

5. Upload documenten die door de huidige taak worden gevraagd

Upload een aangevraagd bestand met POST /v3/customers/{customerId}/documents. De huidige taak bepaalt of een document vereist is en kan het geaccepteerde type, aantal of formaat versmallen.

​

6. Dien volledige taakantwoorden in

Dien één volledige antwoordset in voor de huidige task-revisie met POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Gebruik huidige requirement-ID’s en refereer alleen aan geüploade document-ID’s waar de taak erom vraagt.

​

7. Monitor huidige resources

Refetch na elke actie of event de klant met GET /v3/customers/{customerId}, de capability met GET /v3/customers/{customerId}/capabilities/{capabilityId}, de applications met GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications en eventuele huidige taken. Voor de volledige mechaniek, zie zakelijke onboarding, Capabilities en tasks en de Integration Documents-gids.

​

Enhanced due diligence (EDD) triggers

EDD kan vereist zijn voor:

• High-risk jurisdicties
• High-risk verticals, waaronder gaming, trading en crypto exchanges
• Complexe eigendomsstructuren
• Verwacht maandelijks volume boven de toepasselijke drempels
• Operations met gesanctioneerde landen

​

Beleidsreview-uitkomsten

Uitkomst: KYB-goedkeuring, voorwaardelijke goedkeuring met caps of afwijzing. Dit zijn beleidsreview-uitkomsten, geen huidige API-statuswaarden. Een voorwaardelijke beleidsbeslissing kan via huidige resources worden weerspiegeld zonder een status genaamd “conditional approval” aan te maken.

​

Verificatietijdlijn

Deze duren zijn typische beleidsschattingen, geen gegarandeerd API-gedrag.

​

Veelvoorkomende afwijsredenen

​

Beleidstermen en API-states

Houd beleidsbeslissingen gescheiden van huidige resource-vocabularies:

• Capability status: pending, ready, restricted, rejected, canceled
• Application status: requested, in_review, action_required, ready, rejected, disabled, canceled
• Task status: action_required, in_review, satisfied, rejected, canceled
• Submission outcome: in_review, accepted, changes_requested, rejected

Lees de nieuwste resource in plaats van een beleidsuitkomst naar een API-waarde te vertalen.