The first question a compliance head asks about an AI agent in onboarding is not how clever it is. It is what it can change. We think the honest answer should be: almost nothing, at first.
Banks, NBFCs and insurers are right to be wary of software that acts on its own inside a customer file. A KYC record is not a draft. It decides whether an account opens, whether a customer is flagged and what the institution can show an auditor later. When an AI agent enters that process, the risk is not that it reads a PAN card badly. The risk is that it writes something to the core that nobody intended.
So when we designed AutoKYC, we started from a simple rule: the agent reads by default, and it writes only through the APIs the institution chooses to open.
Most of the value in KYC automation comes from reading. Structuring an ID, address or income document on arrival, matching name, date of birth and address against the application, noticing what is missing and asking the customer for it: none of this changes a system of record. If the agent gets something wrong while reading, the cost is a wrong suggestion that a person can catch.
Writing is different. Opening an account, updating a risk segment or changing customer details has consequences outside the conversation. Those actions deserve a narrower door.
| Action | Risk if wrong | Our default |
|---|---|---|
| Read and structure a document | A wrong suggestion | Allowed |
| Ask the customer for a missing item | A redundant question | Allowed |
| Check registries such as PAN or CKYC | Depends on your policy | Only where you allow it |
| Decide inside your policy bands | A wrong outcome on a clean file | Rules you write; outside the band, a person decides |
| Write to the core | A wrong record | Only through APIs you open, after maker-checker below threshold |
We think write access should be widened the way a new employee’s authority is: after a period of watching what they do. In practice that means going live on one product journey with read-only defaults, letting operations and compliance see every suggestion against what a person actually decided, and only then opening a specific API for a specific action. Even then, below a threshold you set, a second person approves before anything is written. That is maker-checker applied to software as well as staff.
Our maker-checker playbook goes into how to set those thresholds and who should sit on each side.
None of these is unusual for a regulated institution. What matters is that they are part of the design from day one, not added after the first incident.
A read-only start is slower than a demo that opens accounts end to end. Some exceptions that an agent could probably handle will still go to a person for a while. We think that is the right trade. The goal of automation in KYC is to put people on the files that need them, not to take people out of the process. A system that compliance trusts will be allowed to do more over time; one that surprises them once will be switched off.
For the wider process these controls sit in, see digital KYC onboarding on WhatsApp and the rest of the AutoKYC guides. Your own KYC policy and compliance team remain the authority on what may be automated.
Only through specific APIs the institution chooses to open, after a read-only period, and with maker-checker approval below a threshold. Confirm the boundaries with your compliance team.
No. It is read-only by default and writes only via APIs you open, with maker-checker below threshold, a kill switch per agent and one audit log.
Every read, decision and write, in one place, so a reviewer can reconstruct how and why each file moved.
See it on your own data. AutoKYC — Onboarding in hours, on WhatsApp. Book a 30-minute working session with an engineer.
