Start KYC automation with one journey and one metric, not a platform
KYC programmes often stall because they try to fix every product, every document and every channel at once. We think the better first step is much smaller and much more specific.
Ask an onboarding team what is wrong with KYC and you will get a long list: documents arriving by email in pieces, every file reviewed by hand, re-KYC season filling branches, and an audit trail spread across systems. All of it is real. The mistake is trying to fix the whole list in one programme. Large KYC projects tend to spend months on scope and integration before a single customer feels a difference, and by then the sponsor has moved on.
Our view: pick one product journey, agree one metric, and go live on that within weeks. Everything else follows on the same foundation.
Why one journey
A savings account, a loan, a card and an insurance proposal look similar from a distance. Up close, each has its own documents, policy rules, exceptions and systems of record. Trying to design for all of them at once produces either a lowest-common-denominator flow or an endless requirements document. Choosing one journey makes every decision concrete: these documents, these rules, this core API, this team.
Good first candidates share three traits:
Enough volume that a change is visible within weeks.
A clear, written policy, so rules can be encoded rather than guessed.
A known pain, such as drop-off while documents wait or clean files waiting behind complex ones.
Why one metric
A pilot with five success measures has none. One number keeps everyone honest about whether the change worked. The right metric depends on the pain you chose:
If the pain is…
A sensible single metric
Customers dropping off
Share of started applications that complete
Slow onboarding
Time from first message to account opened
People on the wrong files
Share of files that reach a person, and why
Re-KYC backlogs
Share of a risk segment completed without a branch visit
You choose the metric; we measure against it. We deliberately do not promise a number before seeing your journey, because the baseline differs widely between institutions. The AutoKYC page states an onboarding target of under 24 hours, typically from three to five days today, but your own baseline is what matters.
What the first weeks look like
The way we deliver AutoKYC follows this shape. In weeks one and two the journey, your policy and the systems in scope are mapped and the metric agreed. From weeks two to six we build the WhatsApp journey, document reading, rules and maker-checker on your stack. Between weeks six and eight it goes live on one product, with read-only defaults. After that, re-KYC and other products are added on the same spine rather than as new projects.
The second journey is where the payoff is
The first journey carries most of the setup cost: the WhatsApp channel, the document reading, the audit log, the maker-checker controls and the connection to your core. The second journey reuses all of it. Only the documents, rules and exceptions that are specific to the new product need attention. That is why we would rather prove one journey well than half-build four.
How to pick yours this week
List your product journeys and roughly how many applications each sees.
Mark the one where customers or staff complain most.
Check the policy for that journey is written down and current.
Name the single number that would tell you it worked.
Name the one person in compliance who must be comfortable with it.
What is the best first project for KYC automation?
One product journey with real volume, a written policy and a known pain, measured against one agreed metric such as completion rate or time to account opened.
How long does a first AutoKYC journey take to go live?
AutoKYC is delivered over six to eight weeks for the first product journey: mapping, building on your stack, then going live with read-only defaults.
Why not automate every KYC journey at once?
Each journey has its own documents, rules and exceptions. Proving one well builds the shared foundation that later journeys reuse.