KYB workflow

​

KYB workflow

The KYB workflow combines current customer, related-party, capability, task, submission, and document resources with a policy review of the business and its ownership.

​

Current workflow sequence

​

1. Create the business customer

Create the business customer with POST /v3/customers. Read the current customer with GET /v3/customers/{customerId}.

​

2. Maintain related parties

Use GET /v3/customers/{customerId}/related-parties to review current parties, POST /v3/customers/{customerId}/related-parties to create one, and PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} to update supplied facts. Maintain the direct owners, parent entities, UBOs, control persons, directors, officers, and signers requested by current tasks. Their roles are distinct.

​

3. Discover and request an eligible capability

Read GET /v3/customers/{customerId}/capabilities/supported. Request an available or beta capability only when the customer is eligible, using POST /v3/customers/{customerId}/capabilities/{capabilityId}.

​

4. Read current tasks

List current work with GET /v3/customers/{customerId}/tasks. Fetch each actionable task through GET /v3/customers/{customerId}/tasks/{taskId}, then derive the next action from its current revision, requirements, and sessions.

​

5. Upload documents requested by the current task

Upload a requested file with POST /v3/customers/{customerId}/documents. The current task determines whether a document is required and can narrow its accepted type, count, or format.

​

6. Submit complete task answers

Submit one complete answer set for the current task revision with POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Use current requirement ids and reference uploaded document ids only where the task asks for them.

​

7. Monitor current resources

After every action or event, refetch the customer with GET /v3/customers/{customerId}, the capability with GET /v3/customers/{customerId}/capabilities/{capabilityId}, its applications with GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications, and any current tasks. For the complete mechanics, see business onboarding, Capabilities and tasks, and the Integration Documents guide.

​

Enhanced due diligence (EDD) triggers

EDD may be required for:

• High-risk jurisdictions
• High-risk verticals, including gaming, trading, and crypto exchanges
• Complex ownership structures
• Expected monthly volume exceeding applicable thresholds
• Operations involving sanctioned countries

​

Policy review outcomes

Outcome: KYB approval, conditional approval with caps, or rejection. These are policy review outcomes, not current API status values. A conditional policy decision can be reflected through current resources without creating a status named “conditional approval.”

​

Verification timeline

These durations are typical policy estimates, not guaranteed API behavior.

​

Common rejection reasons

​

Policy terms and API states

Keep policy decisions separate from current 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

Read the latest resource rather than translating a policy outcome into an API value.