Complete business verification (KYB)
When to use
Use when the account owner or payout beneficiary is a legal entity. Public gap: the published @keetanetwork/anchor package exposes KYC.Client but no KYB.Client, and current Keeta public docs do not specify a stable Footprint, Signzy, or other KYB HTTP contract. Business-shaped bank-recipient fields are not proof of KYB.
This skill is therefore a discovery and safety gate, not a fabricated executable integration.
SDK steps
- Confirm that entity verification—not individual KYC—is required. Collect only the minimum non-secret routing facts needed for discovery: environment, jurisdiction, entity type, intended anchor operation, and provider preference.
- Use discover-resolve-anchors to inspect current signed metadata for the target asset-movement provider and call its documented
getAccountStatus(...) when available.
- Record the returned typed actions. If the provider requests individual KYC sharing or additional KYC, route only that portion through complete-kyc; do not relabel it KYB.
- Continue only if the resolved provider publishes a KYB operation schema or links to provider-owned documentation that specifies:
- authenticated endpoint and environment,
- request/response schema,
- supported jurisdictions and entity types,
- status polling and evidence returned,
- data handling and terms.
- Ask a human to approve the provider and disclosure set. Use the provider's published client or HTTP contract exactly. Keep the integration provider-specific and do not claim it is a Keeta SDK method.
- Confirm completion using the provider's documented status response plus a fresh anchor
getAccountStatus(...) check.
Confirmations
- Require human approval before sending incorporation records, beneficial-owner data, tax identifiers, or banking information.
- Show the provider, endpoint origin, environment, jurisdiction, requested documents/fields, data recipients, and retention terms.
- Require a separate transaction confirmation after KYB; verification does not authorize a payout.
Failures
- If no stable public KYB contract is discoverable, stop and report the missing provider schema. Do not call guessed
/kyb, /businessVerification, Footprint, or Signzy endpoints.
- If a provider exposes only KYC methods, do not force business data into individual KYC fields.
- Treat pending/manual review as incomplete.
- Never put KYB documents or sensitive identifiers on-chain unless an explicit, reviewed protocol requires it.
Related skills
Sources
1---2name: complete-kyb3description: Safely scope business verification for a Keeta anchor, discover provider requirements, and stop when no public KYB contract is available. Use when an organization—not an individual—must be verified.4---56# Complete business verification (KYB)78## When to use910Use when the account owner or payout beneficiary is a legal entity. **Public gap:** the published `@keetanetwork/anchor` package exposes `KYC.Client` but no `KYB.Client`, and current Keeta public docs do not specify a stable Footprint, Signzy, or other KYB HTTP contract. Business-shaped bank-recipient fields are not proof of KYB.1112This skill is therefore a discovery and safety gate, not a fabricated executable integration.1314## SDK steps15161. Confirm that entity verification—not individual KYC—is required. Collect only the minimum non-secret routing facts needed for discovery: environment, jurisdiction, entity type, intended anchor operation, and provider preference.172. Use [discover-resolve-anchors](../discover-resolve-anchors/SKILL.md) to inspect current signed metadata for the target asset-movement provider and call its documented `getAccountStatus(...)` when available.183. Record the returned typed actions. If the provider requests individual KYC sharing or additional KYC, route only that portion through [complete-kyc](../complete-kyc/SKILL.md); do not relabel it KYB.194. Continue only if the resolved provider publishes a KYB operation schema or links to provider-owned documentation that specifies:20 - authenticated endpoint and environment,21 - request/response schema,22 - supported jurisdictions and entity types,23 - status polling and evidence returned,24 - data handling and terms.255. Ask a human to approve the provider and disclosure set. Use the provider's published client or HTTP contract exactly. Keep the integration provider-specific and do not claim it is a Keeta SDK method.266. Confirm completion using the provider's documented status response plus a fresh anchor `getAccountStatus(...)` check.2728## Confirmations2930- Require human approval before sending incorporation records, beneficial-owner data, tax identifiers, or banking information.31- Show the provider, endpoint origin, environment, jurisdiction, requested documents/fields, data recipients, and retention terms.32- Require a separate transaction confirmation after KYB; verification does not authorize a payout.3334## Failures3536- If no stable public KYB contract is discoverable, stop and report the missing provider schema. Do not call guessed `/kyb`, `/businessVerification`, Footprint, or Signzy endpoints.37- If a provider exposes only KYC methods, do not force business data into individual KYC fields.38- Treat pending/manual review as incomplete.39- Never put KYB documents or sensitive identifiers on-chain unless an explicit, reviewed protocol requires it.4041## Related skills4243- Use [complete-kyc](../complete-kyc/SKILL.md) for natural persons and beneficial owners.44- Use [discover-resolve-anchors](../discover-resolve-anchors/SKILL.md) to re-check capabilities at runtime.45- Use [pay-out](../pay-out/SKILL.md) only after provider readiness is confirmed.4647## Sources4849- [`@keetanetwork/anchor` KYC client](https://github.com/KeetaNetwork/anchor/blob/main/src/services/kyc/client.ts)50- [Asset Movement client and `getAccountStatus`](https://github.com/KeetaNetwork/anchor/blob/main/src/services/asset-movement/client.ts)51- [Anchor Resolver](https://docs.keeta.com/anchors/overview/anchor-resolver)