KYC is not a checkbox at signup. It's a long-lived state machine you have to keep running.
Most systems I've picked up model it as a boolean on the user row: verified, true or false. That holds until the first real case.
A provider returns "pending manual review" while the user is already mid-deposit. A document expires while the account stays open. A re-check months later comes back with a different risk decision. A compliance officer overturns an automated pass.
Each of those is a transition. If your schema stores only the last answer, you lose the reason and the ordering — the exact two things you get asked about later.
When I built a fiat-to-crypto onramp with real-time moderation, the hard part was never the provider integration. It was this: every decision written as an immutable event with its source recorded (provider, internal rule, or human), the user's status derived from that history rather than overwritten in place, and permissions gated per action instead of globally. Deposit, withdraw, and raising a limit are not the same bar.
The payoff shows up on the day a case is disputed. You replay the history instead of reconstructing it from application logs.
If you run verification in production: does your system store the decisions, or only the current verdict?