What is fintech compliance in India?
Compliance, in an Indian fintech, isn't a single function — it's the running cost of being allowed to move money. Every regulated entity owes the same broad obligations: verify who the customer is at onboarding, keep verifying that the customer is still who they were at refresh cycles, screen against sanctions and politically-exposed-person lists, monitor transactions for patterns that look like money laundering, file Suspicious Transaction Reports when something stands out, mask Aadhaar before storage, retain the right records for the right number of years, and produce an audit trail any regulator can sample on demand.
The hard part isn't knowing the rules. They're written down — most of them in the RBI Master Direction on KYC, the PMLA rules, the FATF recommendations, the MeitY masking notification, and the DPDP Act. The hard part is shipping all of them at scale, on a customer journey that still completes in seconds, without bouncing the customers you actually want.
This guide walks the compliance surface in the order an Indian fintech actually meets it: regulators first (so you know who binds you), the six obligations every regulated entity carries, how AML and KYC and risk relate to each other (auditors care, engineers don't, and that's where the gaps appear), and the five implementation pitfalls every team trips on at least once before they ship it right.
India regulatory map
Five regulators set the rules; one international body (FATF) sets the meta-rules the five translate into Indian law. Knowing which one binds your product matters more than the rules themselves — the same act of "monitoring a customer" is governed by different bodies depending on whether you take deposits, give loans, route payments, or sell securities.
The Reserve Bank of India is the primary regulator for banks, NBFCs, payment-system operators, and the bulk of fintechs. The RBI Master Direction on KYC, 2016 (last amended 2024) is the load-bearing document — risk categorisation, periodic update cycles, V-CIP procedure, and penalties all live there. The Securities and Exchange Board of India (SEBI) regulates anything that touches capital markets — brokers, mutual funds, AMC platforms. SEBI mirrors most of RBI's KYC obligations but adds market-conduct rules layered on top.
The Financial Intelligence Unit India (FIU-IND) owns the Prevention of Money Laundering Act (PMLA) execution layer — Suspicious Transaction Reports, Cash Transaction Reports, and the consolidated returns under PMLA flow to FIU-IND through the FINNet portal. The Financial Action Task Force (FATF) is the international standard-setter; FATF's 2024 Mutual Evaluation of India set new expectations on beneficial-ownership transparency and ongoing-monitoring effectiveness that will land as PMLA-rule amendments and RBI circulars through 2026–27.
Two further bodies shape the surface area. The Ministry of Electronics & IT (MeitY) issued the 2023 Aadhaar-masking notification — the 12-digit number must be redacted at the storage layer for most use cases. And the Digital Personal Data Protection Act, 2023 (DPDP) layered a consent + retention + breach-notification regime on top of the existing AML/CDD stack. DPDP rules continue to phase in through 2026.
The practical takeaway: build to the strictest regulator that touches your product. A neo-bank serving deposits and loans answers to RBI, SEBI, FIU, and the DPDP Board simultaneously. A pure payments app can scope to RBI Master Direction + PMLA + DPDP. Get the regulator map wrong on day one and the audit catches it on day 365.
The 6 obligations every regulated entity carries
Every regulated entity in India — bank, NBFC, fintech, brokerage, payment app, PPI wallet — owes the same six obligations. They're framed slightly differently across the rule books, but the audit checks them all.
1. Customer Due Diligence (CDD) at onboarding
Verify identity using an Officially Valid Document, verify address, screen against sanctions and PEP lists, risk-categorise the customer. Four steps, all four mandatory, all four documented in the customer record. CDD failures are the leading cause of compliance-audit findings in fintech.
2. Enhanced Due Diligence (EDD) for higher-risk customers
EDD triggers when CDD surfaces a politically-exposed person, a sanctions hit, a high-risk geography, a high-value transaction, or a complex ownership structure. The depth increases: source of wealth, source of funds, expected transaction profile, beneficial-ownership chain, and senior-management approval to retain. EDD customers are placed on an enhanced-monitoring tier — lower thresholds for AML alerts, shorter periodic-review cycles.
3. Ongoing AML transaction monitoring
Every transaction the customer makes is screened against the rules and behavioural models you've registered with your AML platform. Velocity, anomalies, structuring, smurfing, large-cash patterns, geographic exposure, watchlist hits. Most teams underbuild this layer — they put it in at minimal threshold to clear the audit, then get burned the first time a real laundering ring uses their rails. The 2024 FATF Mutual Evaluation set elevated expectations on monitoring effectiveness, not just coverage; build for the outcome.
4. Periodic re-KYC at RBI-set cadences
High-risk customers refresh every 2 years, medium every 8, low every 10. The clock starts at last successful KYC, not at account opening. The pattern that ships well: trigger the refresh inside an existing journey (large transaction, product upgrade, support contact), not as a dormancy email blast. Run MNRL at every refresh as a hard gate on the registered mobile.
5. Aadhaar masking + data protection
MeitY 2023 mandates redaction of the 12-digit Aadhaar before storage. Authentication still flows through UIDAI (Aadhaar OTP, DigiLocker), but the raw value never sits in your warehouse. DPDP layers on top: consent must be specific, informed, and unambiguous; retention must be tied to a stated purpose; data principals have rights to access, correction, and erasure; breach notification has hard timelines.
6. Audit trail + record retention
Every CDD pass, every PEP hit, every override, every refresh, every STR — logged per-customer, per-event, with the rationale captured at the moment of decision. PMLA requires retention for 5 years after the customer relationship ends. RBI Master Direction adds its own retention obligations. Build this as infrastructure, not as a bolt-on log file. The first time you're subpoenaed by FIU-IND, you'll thank yourself.
AML vs KYC vs risk — not the same thing
Engineers conflate the three; auditors don't. They feed each other, but they're separate obligations with separate owners and separate audit trails.
| Dimension | KYC / CDD | AML monitoring | Risk management |
|---|---|---|---|
| Question it answers | Who is this customer? | What is this customer doing? | What might go wrong, and what does that cost? |
| Primary mandate | RBI Master Direction on KYC, 2016 | PMLA, 2002 + FIU-IND notifications | RBI Master Direction on Risk Management |
| Cadence | Onboarding + 2/8/10-year refresh | Continuous — every transaction | Continuous + quarterly board review |
| Signals used | OVDs, face match, liveness, address | Velocity, network, geography, watchlists | Portfolio concentration, market, ops |
| Owner team | Onboarding / compliance ops | FRM / FIU reporting | CRO / risk committee |
| Failure cost | Customer drops off, audit observation | Regulatory penalty, license risk | Capital adequacy hit, board exposure |
Build them as one stack, not three teams — identity signals collected at CDD feed AML scoring later. The same Aadhaar, the same device, the same mobile that cleared onboarding becomes the baseline every transaction is compared against, and the risk tiering drives both how strict CDD/EDD is and how sensitive AML monitoring runs. One decisioning layer underneath, three audit trails on top.
Risk-based approach — the framework auditors use
RBI Master Direction (and PMLA, and the FATF recommendations India translates) explicitly adopt a risk-based approach. You're not expected to run the maximum check on every customer — you're expected to run a check proportionate to the customer's risk. The trick is operationalising "proportionate" in a way an auditor can defend.
Three tiers cover most fintech onboarding flows.
Tier-0 (low value, low risk): PPI wallets at small limits, sandbox accounts, watchlist viewing accounts. CDD is light — PAN cross-check + Aadhaar OTP or OVD upload. AML monitoring runs minimal velocity rules. Refresh on the 10-year cadence. Outcome: customer onboarded in sub-30 seconds.
Tier-1 (standard deposit and lending, under ₹5L): Full CDD — Aadhaar eKYC OTP + PAN cross-check + face match + liveness + address. AML runs the standard rule set plus name screening against sanctions and PEP at onboarding. Refresh on the 8-year (medium-risk) cadence by default, dropped to 10 years for clean behavioural histories at year 4. Outcome: customer onboarded inside 5 minutes.
Tier-2 (high value, high risk, regulated products): Tier-1 plus EDD — source of wealth, source of funds, V-CIP, beneficial-ownership chain, senior approval to onboard. AML runs enhanced monitoring with lower thresholds. Refresh on the 2-year cadence. STR thresholds drop. The video step is load-bearing for audit defensibility.
The framework that holds: every tier you skip costs you defensibility; every check you add to a lower tier costs you completion rate. The point of decisioning infrastructure is to let the same stack serve all three tiers without three integrations.
STR filing — the FIU-IND obligation everyone forgets to design for
PMLA requires regulated entities to file Suspicious Transaction Reports (STRs) with FIU-IND within 7 working days of forming a suspicion. "Forming a suspicion" is the subjective bar — the activity has no apparent economic or lawful purpose, or it's inconsistent with the customer's known profile, or the pattern matches a known laundering typology.
The STR pipeline looks straightforward on paper:
Detect → AML alert triggers in the monitoring layer. Investigate → analyst pulls the customer's full history into a case-management tool, examines the pattern against typologies, applies the suspicious-activity test. Decide → either close the case (with documented rationale, retained 5 years) or escalate to STR. File → submit through FIU-IND's FINNet portal in the prescribed format, within 7 working days. Don't tip off → PMLA forbids alerting the customer; service continues normally unless FIU-IND directs otherwise.
What breaks in practice: the case-management layer. Teams ship AML monitoring without the investigation tool, which means analysts pull data manually from 3–5 systems for every alert, the 7-day window slips, the audit observation lands, and the regulatory observation follows. Build case management at the same time as monitoring — they're half a product, not two.
What also breaks: rationale capture on closed cases. If an analyst closes 90% of alerts as false positives without writing down why, the audit cannot tell whether the monitoring is calibrated or just being ignored. The rationale field is non-optional.
Implementation pitfalls — the 5 that bite
Every compliance team hits the same five.
1. Storing the unmasked Aadhaar. MeitY's 2023 notification requires the 12-digit number to be redacted before storage for most use cases. Teams that pull Aadhaar via OCR or DigiLocker and skip the masking step fail the next compliance audit. Mask at upload, run a periodic audit on storage to confirm no drift.
2. Treating "no hit" on sanctions screening as a one-time event. Sanctions and PEP lists update constantly — daily, sometimes hourly. A customer who was clean at onboarding can become a PEP three months later. Run screening at onboarding and on a daily cron against the live list. The audit asks for both.
3. Underbuilding AML for "effectiveness". FATF's 2024 evaluation flagged India on monitoring effectiveness, not coverage. A team that turned on AML to clear the audit, with 95% false-positive rates and no rationale on closed alerts, will fail the next evaluation. Build for outcomes — what laundering would you actually catch?
4. Skipping MNRL on re-KYC. The Mobile Number Revocation List catches numbers that have been ported, surrendered, or reissued. A re-KYC that re-validates the document but not the mobile attached to the account misses the most common takeover vector. Run MNRL as a hard gate at every refresh.
5. Treating audit log as a side-effect, not a product. The first time you're subpoenaed by FIU-IND or asked for a sample by the RBI inspector, you'll need per-customer, per-event logs with the rationale captured at the moment of decision — for the past 5 years. Bolting this on retroactively is impossible. Build the audit log as a first-class compliance primitive.
How Deepvue ships compliance
Every API in the catalog below sits on the same auth, the same SLA, the same decisioning layer underneath. CDD, EDD, AML signal collection, sanctions/PEP screening, Aadhaar masking, MNRL refresh, court/FIR adverse-record — one contract, one audit log. Risk tiering and refresh triggers come built in.
The audit trail is the load-bearing layer. Every check, every override, every alert, every closure — logged per-customer with rationale captured at decision time. Retention policies run as infrastructure, not as a quarterly project.
Sub-200ms latency on the verify-only path. RBI Master Direction-aligned, FIU-ready, DPDP-compliant out of the box. Live across 60+ businesses processing 15M+ identity and compliance decisions.