KYC, AML and compliance engineering in Indian fintech

Onboarding: what the system has to do

A compliant onboarding flow in India is a sequence of independently failing steps, each with a regulatory basis and an operational reality.

Identity verification. Officially Valid Documents, Aadhaar-based verification through OTP or biometric e-KYC where the entity is permitted to use it, offline Aadhaar XML or QR, PAN verification against the income tax database, and document-based fallback. Each path has a different assurance level and a different set of permissible use cases, which means the flow is a decision tree rather than a pipeline.

Video-based Customer Identification Process. V-CIP replaced the physical in-person verification requirement for many entities and is now the default for high-assurance digital onboarding. Engineering-wise it is a live video session with liveness detection, geotagging within India, face match against the identity document, random question capability for the official conducting it, recording retained for audit, and an audit trail of who performed the verification. It is a real-time media problem bolted onto a compliance workflow, and teams routinely underestimate it.

Risk categorisation. Every customer is assigned low, medium or high risk based on a documented methodology, and the category drives the depth of diligence and the frequency of re-verification. The methodology has to be implemented consistently and be explainable, because it will be asked about.

Central KYC Records Registry. Records are uploaded to CKYCR and a KYC Identifier is returned. Where an identifier already exists, the record can be downloaded rather than collected afresh. In practice the download path is underused, which means customers are asked for documents they have already provided to the system, with a measurable conversion cost.

Periodic updation. The 12 June 2025 amendment to the KYC Master Direction allowed low-risk individual customers to complete periodic KYC up to one year after the due date or until 30 June 2026, whichever is later, applying retrospectively to those already overdue. It also permitted banks to use business correspondents to collect self-declarations where particulars are unchanged or only the address has changed, with the bank retaining responsibility. And it set a notification regime, three advance notices before the due date and three reminders after, at least one of each by letter, with systematic recording of all communications, to be implemented by 1 January 2026.

That last requirement is a straightforward engineering obligation that several institutions discovered late: a scheduled, multi-channel, auditable notification pipeline tied to each customer's due date, including a physical letter path.

Screening: the matching problem

Sanctions and PEP screening looks like a database lookup and is not. It is a fuzzy matching problem with an asymmetric cost function, and India adds a specific difficulty.

The lists. The UNSC consolidated list, the domestic lists maintained under the Unlawful Activities (Prevention) Act, and for entities with international exposure, OFAC and others. These update on their own schedule, and a screening system that refreshes weekly has a week of exposure.

Transliteration. An Arabic, Cyrillic or Chinese name rendered into Latin script has many valid spellings, and an Indian name rendered from Devanagari, Tamil, Bengali or Gujarati has many more. A matching engine tuned on Western name distributions performs badly on Indian name data, generating both missed matches and a very high false positive rate on common names. This is the single biggest practical driver of screening alert volume in Indian institutions and it is rarely addressed properly, because the vendor default is accepted as given.

Threshold calibration. Set the match threshold loose and the operations team drowns. Set it tight and you miss. The threshold is a risk decision that needs evidencing, and the evidence is a tested sample, not an intuition.

Ongoing screening. Customers screened at onboarding must be rescreened when the lists change, not only at onboarding. The engineering implication is a periodic full-base rescreen, which at scale is a batch job with a cost and a runtime that need planning.

Beneficial ownership. For corporate customers, screening has to reach through to the beneficial owners, which requires holding the ownership graph and keeping it current. Most systems hold it as a flat list captured once.

Transaction monitoring

Transaction monitoring is where the RBI and the Financial Intelligence Unit look hardest, and where fintechs are most often found wanting.

The system watches transaction flows against scenarios: structuring below reporting thresholds, rapid movement in and out, transactions inconsistent with the customer's declared profile, dormant accounts suddenly active, round-tripping between related parties, mule patterns. Each scenario generates alerts; alerts are triaged; some become cases; some cases become Suspicious Transaction Reports filed with FIU-IND.

The engineering realities:

Alerts are useless without disposition data. The whole system improves only if the outcome of each alert is captured and fed back. Institutions that triage alerts in a spreadsheet lose the one dataset that would let them tune anything.

Thresholds go stale and this is the classic finding. A threshold set at launch, when average transaction values were a fraction of today's, generates either a flood or a silence. "When did you last review monitoring thresholds and on what basis?" is a question with a predictable answer in most Indian fintechs, and it is a question that gets asked. This is the operational problem that, as the Chief Compliance Officer page notes, usually signals that the MLRO function has been crowded out.

The customer profile is the weak link. Monitoring that compares behaviour to an expected profile is only as good as the profile, and the profile is usually a declaration captured at onboarding and never updated. A customer whose income has tripled looks suspicious to a system still holding their first-job declaration.

Scenario coverage is easier to add than to evidence. Adding a scenario is a day of work. Demonstrating that the scenario set covers the institution's actual risk exposure, with a documented rationale, is the obligation, and it is a different kind of work.

The STR deadline is a system requirement. Filing windows are not negotiable, and a case management system without deadline tracking will miss them.

Where compliance engineering breaks

Vendor sprawl with no system of record. A typical Indian fintech runs three to six compliance vendors: an identity provider, a document verification service, a screening vendor, a monitoring platform, perhaps a separate V-CIP provider. Each holds part of the picture. Nobody holds all of it, and the inspection question "show me everything you hold on this customer and every check you ran" takes three weeks to answer. A compliance data layer that aggregates vendor outputs into one record is the fix, and it is almost always built late.

Onboarding conversion treated as a product problem only. Every verification step loses customers. The compliant minimum is usually shorter than what has been built, because steps accumulate and nobody removes them. Measuring drop-off per step against its regulatory necessity is a joint product and compliance exercise that few teams run.

Audit trail gaps at the vendor boundary. The check ran at the vendor; the result came back; the evidence of what exactly was checked stayed with the vendor and is retained for ninety days. Two years later, the regulator asks.

Re-KYC as a batch nobody owns. Periodic updation is a continuous obligation modelled by most systems as an annual campaign. The 2025 amendment's notification regime makes the continuous model mandatory in practice.

Data residency on compliance data. KYC data is payment and personal data under multiple overlapping regimes, which constrains where verification and screening can run. Covered in regulated engineering.

The fraud and AML seam. Mule accounts are both a fraud problem and an AML problem, and in most organisations they sit in two teams with two systems and two sets of signals. See real-time fraud and risk decisioning.

Who owns this

The honest market picture: identity and onboarding engineers are reasonably available, because every fintech has built an onboarding flow. Screening and monitoring engineers with genuine tuning experience are scarce, because most institutions run vendor defaults and nobody acquires the skill. The rarest profile is a compliance engineering leader who has built the consolidated compliance data layer and been through an inspection with it, and that person is usually in a bank or one of the larger payment companies.

How to assess

Ask what they would show a regulator. "An inspector asks for everything you hold on one customer and every check ever run. Walk me through it." The answer separates people who have built a system from people who have integrated vendors.

Ask about threshold tuning. "When did you last change a monitoring threshold, and what evidence did you use?" If there is no answer, there is no tuning discipline, which is the most common gap in the market.

Probe the matching problem. Ask how they handled false positives on common Indian names. Candidates who have worked on screening properly have strong views here. Candidates who accepted the vendor default have none.

Test the conversion conversation. "Which onboarding step would you remove, and what would you tell compliance?" Good candidates know which steps are regulatory and which are habit, and can argue the distinction.

Ask about an audit finding. What was found, what was the root cause, what changed. Everyone who has operated a compliance system at scale has one, and the ones who describe it without defensiveness are usually the ones who fixed it.