Business Flow Monitoring: KYC and Identity Verification
Verification hands control to a third party for an unpredictable period. A decision webhook that never arrives leaves a customer in limbo indefinitely.
Identity verification is the hardest flow to monitor well, because the longest step is controlled by somebody else and its duration is genuinely variable. An automated check returns in seconds; the same check escalated to manual review can take two days, and both are normal.
That variability is why these flows are so often left uninstrumented, and why applications sit in a pending state for weeks without anyone noticing.
The sequence
| # | Event key | Max gap from previous | Who controls the timing |
|---|---|---|---|
| 1 | application.started | n/a (opens the flow) | Applicant |
| 2 | documents.uploaded | 24 hours | Applicant |
| 3 | provider.submitted | 5 minutes | You: a stall here is your bug |
| 4 | provider.decision.received | 72 hours | The verification provider |
| 5 | decision.applied | 2 minutes | You: verified but not enabled |
| 6 | account.enabled | 5 minutes | You |
Steps 3 and 5 are yours and deserve tight limits. Step 4 belongs to the provider and needs a limit generous enough to cover manual review without being so generous that a lost webhook sits for a week.
Step 5 is the specific failure that damages trust most. The provider approved the applicant, the webhook carrying that decision was dropped, and your system still shows them as pending. They were verified and you told them they were not.
Poll as a backstop for the provider step
This is the flow where waiting for a webhook is not enough, because the consequence of a missed decision is a customer permanently stuck. Add a reconciliation poll for anything sitting at step 3 beyond a threshold.
This single job resolves most real incidents in this flow without anybody being paged, and it turns a customer-facing failure into a log line. It is worth building before the flow monitoring itself.
Distinguish waiting from stuck
An application at step 4 for six hours is normal. The same application at step 4 for four days is not, and the difference is entirely about the elapsed time rather than the state.
Set the alert on age within the step rather than on the state itself, and pick the threshold from your provider's published turnaround plus a wide margin. Ask them for their 95th percentile rather than their average, because the average tells you nothing about the tail you care about.
Resubmission restarts the clock
Verification flows loop. A provider that asks for a clearer photograph sends the applicant back to step 2, and a naive implementation either treats that as a new flow instance or leaves the old one stalled forever.
Handle it explicitly: close the current instance with a resubmission-requested outcome and open a new one, keeping the same applicant ID so you can see how many attempts somebody has made.
The attempt count is worth surfacing. An applicant on their fourth attempt is having a bad experience regardless of whether any step technically stalled, and that is a product problem rather than a monitoring one.
Applications nobody looks at
The failure that persists longest in KYC is the application in a terminal-looking state that was never actually terminal. Review anything older than your longest expected turnaround on a schedule, regardless of what its status field says.
SensaCat tracks each application as its own instance with per-step limits, so one applicant stuck awaiting a decision is an alert rather than a row in a queue. Start free.