Onboarding's long tail — name mismatches, transliteration variance, document-quality re-work — is where most KYC cost and most KYC risk lives. This template structures that tail as governed agent work: a deterministic gate on every clean pass, an evidence-backed recommendation on every exception, and a human decision on anything the gate cannot decide.
Below is the heart of the template, shown the way every ProcessSkill exists: one spine, two skins. The left column is what your compliance head and your auditor read. The right column is what the harness executes. They are not two files kept in sync — they are the same artifact.
2.1 — Identity corroboration on mismatch
Where the applicant's name or address does not match across submitted documents, transliteration variance across scripts shall be treated as an expected condition, not a rejection trigger. The reviewing agent must corroborate identity through at least two independent documents before classifying the case.
2.2 — Exception classification
- Resolvable: variance explained and corroborated — proceed with rationale recorded.
- Curable: a specific document would resolve it — generate a single, precise customer ask.
- Escalation: corroboration not achievable — route to the KYC officer with the full evidence trail.
3.0 — Officer decision CONTROL POINT
Every escalated exception is decided by a human officer. This control cannot be waived; onboarding stays blocked until it closes. The officer decides on the case file first — the agent's classification is revealed only after the decision is logged.
node "2.1-identity-corroboration": kind: agent expected_conditions: - transliteration_variance evidence_min: 2 independent_docs output: cited_rationale node "2.2-exception-classify": kind: agent classes: [resolvable, curable, escalation] on: curable → one_precise_ask node "3.0-officer-decision": kind: human_control_point waivable: false mode: decide_then_reveal blocks: [4.0-onboard] divergence_sink: third_line # full file: 14 nodes · 3 control # points · validator-spec stub · # policy pins · evidence schema
What the full template includes
- The complete 14-node spine — intake, deterministic verification, the exception path above, customer-communication nodes, and the onboarding gate.
- Policy pin stubs for the RBI KYC Master Direction, PMLA record-keeping schedules and DPDP consent artifacts, ready to point at your clause IDs.
- A validator-spec stub — deliberately separate, with guidance on why your control function must author it independently of whoever adapts the executor side.
- Checker-class declarations and independence constraints for every agent node.
- An adaptation worksheet: the eight questions to answer from your own mined event logs before deploying anything.
The Process skin is open — read it, share it, argue with it. The full ProcessSkill, Skill skin included, is sent by email so we know who is running our methods and can send corrections when the template revises.
The honest fine print: a template is a starting point, not a compliance opinion. Every deployment must be adapted against your own policies, validated by your own second line, and approved through your own change governance. We publish templates to raise the floor of the conversation — not to shortcut it.