KYC returned REVIEW or REJECT? Don't retry — you'll blacklist the applicant
An identity/KYC verification comes back REVIEW, pending_manual_review, or REJECT. An agent that treats these like a transient API error and retries doesn't just fail — it can blacklist the applicant.
Two decisions the model mishandles
- REVIEW / pending_manual_review is a ROUTING decision, not a failure. The provider couldn't auto-decide, so the case is queued for a human. Route it to your review queue and wait for the webhook — don't retry it as an error.
- Re-submitting a REJECT trips fraud/velocity rules. Repeated verification attempts on the same identity look like fraud and can blacklist the applicant. REJECT is terminal for that submission.
The signal isn't in the top-level decision — it's in the reason codes (watchlist hit, document mismatch, fraud score). Read those to decide the next step, and never auto-retry: a KYC decision is a compliance action, always human-gated. (This is distinct from KYT — know-your-transaction — which screens a payment, not an identity.)
Handle it right
REVIEW → manual-review queue, wait for the decision. REJECT → read the reason codes and handle per compliance policy (request a different document, escalate, or decline) — do not re-submit the same identity. Snapback's identity-kyc family returns exactly this routing so an agent doesn't loop on a decision or trip fraud rules.
Machine-readable guide: https://snapback.sh/llms.txt · Tool discovery: https://snapback.sh/.well-known/mcp.json · MCP endpoint: https://api.snapback.sh/mcp. Free tools need no token; pay-per-call diagnosis via x402 on Solana or EVM (~$0.0032 USDC).