FinTech App Compliance in India: A Practical Primer

FinTech app compliance in India is the topic founders underestimate most when they brief us on a new build. The feature list is clear, the designs are ready—and then someone asks where the payment data will physically live, how KYC will work for a user whose Aadhaar is not linked to their current mobile number, and what an auditor will want to see five years from now. We worked through every one of those questions on Radiant Finance, a personal-finance product our mobile development team shipped recently, and the compliance workstream consumed nearly as much engineering attention as the feature roadmap did. The timing makes this worth writing down now: PCI DSS v4.0's future-dated requirements become mandatory on March 31, 2025—one week from today—and MeitY opened public consultation on the draft Digital Personal Data Protection Rules in January. If a fintech build is on your 2025 roadmap, this is the primer we wish someone had handed us before we started.

## The Regulatory Map: Who Governs What

India does not have a single fintech regulator. Obligations attach to activities, not to the label on your pitch deck—move money and the RBI cares, sell investments and SEBI cares, distribute insurance and IRDAI cares, and the moment you store personal data at all, the Digital Personal Data Protection Act applies. As our CTO Hrishikesh Baidya put it during the Radiant Finance kickoff: "In fintech, compliance is not a checklist you run at the end—it is architecture. Where data lives, how identities are verified, and what gets logged are decisions you make in week one, whether you realize it or not."

Two notes on reading that table. First, PCI-DSS is contractual rather than statutory—your payment partners and the card networks require it, not an Indian law—but in practice it is just as binding. Second, everything here is current as of this writing in March 2025: the DPDP Rules are still in consultation and RBI circulars evolve every year. The durable lesson is to design systems so that a rule change becomes a configuration problem, not a rewrite.

## Three RBI Positions That Shape Your Architecture

### Data Localization (April 2018 Circular)

The RBI's Storage of Payment System Data circular requires end-to-end payment data—customer details, transaction information, credentials—to be stored only in India. Under the RBI's subsequent clarifications, you may process a transaction abroad, but the data must be deleted from foreign systems and brought back to India within 24 hours. Architecturally, that means primary databases, replicas, and backups for payment flows all live in Indian regions (AWS Mumbai, Azure Central India, GCP Mumbai), and your disaster-recovery plan cannot quietly fail over to Singapore.

### Digital Lending Guidelines (September 2022)

If your app facilitates credit, the guidelines dictate the money flow itself: disbursals and repayments must move directly between the borrower's account and the regulated entity's account, with no pass-through accounts owned by the app. Borrowers must see a key fact statement with the all-in cost of credit before accepting, and lending apps may not harvest contacts, call logs, or media files. We have watched more than one lending product get redesigned late because its original architecture parked funds in the startup's own wallet.

### Card-on-File Tokenization (October 2022)

Since October 2022, merchants and payment aggregators may not store actual card numbers. Card-on-file tokenization replaces the card number with a network token—which, conveniently, also shrinks your PCI-DSS scope. More on that below.

## Data Localization in Practice

The 2018 circular is barely two pages long; its engineering consequences are not. Four habits keep you on the right side of it:

- Pin every storage service to Indian regions—including object storage, persistent queues, and managed database backups, several of which default to multi-region replication unless you say otherwise. - Audit your third-party SDKs. Crash reporters, analytics tools, and support-chat widgets routinely ship device and event data to US or EU servers. For Radiant Finance we maintained a data-flow register listing every SDK, what it collects, and where it lands. Our mobile app security guide walks through that audit process in depth. - Treat logs as data. Application logs that capture account numbers or payment payloads are payment data too. Mask at the logging layer, not in the dashboard. - Plan for the DPDP Act now. The Act passed in August 2023, and its draft Rules entered consultation in January 2025. Consent records, purpose limitation, and data-principal rights requests will all need product surfaces—screens and APIs—not just policy PDFs.

## KYC Flows That Convert

KYC is where compliance meets conversion rate, and most teams discover too late that the two pull in opposite directions. The good news is that India gives builders an unusually rich verification toolkit:

- CKYC registry: if your user has completed KYC with any participating institution, you can fetch the existing record instead of re-collecting documents. - Aadhaar OTP e-KYC: the fastest onboarding path, though accounts opened this way carry transaction and balance limits until full KYC is completed. - Video KYC (V-CIP): permitted by the RBI since January 2020 and treated as full KYC—requires liveness checks, geotagging within India, and a trained agent on the call. - DigiLocker: government-issued documents fetched digitally with the user's consent, no photo-of-a-photocopy required.

The design pattern that works is tiered onboarding: admit the user with the lightest permissible verification, unlock higher limits as they complete stronger KYC, and never block the first session on a manual review. Verification itself should run asynchronously—our background jobs and queue architecture guide covers the pattern—so a slow registry lookup never freezes the signup screen. On Radiant Finance, Khushi Kumari designed the onboarding to surface exactly one document request at a time with clear progress states, because nothing erodes trust faster than a wall of upload fields. Design your failure paths too: the single most common KYC failure we see is a user whose Aadhaar-linked mobile number is no longer active, and the apps that handle it gracefully offer Video KYC as an immediate fallback instead of a dead end.

## PCI-DSS Without the Panic

PCI-DSS intimidates founders because the full standard runs to hundreds of requirements. The secret is that scope, not effort, determines your burden. If raw card data never touches your servers—because a licensed payment aggregator's SDK or hosted fields collect it directly—you qualify for the lightest self-assessment questionnaires. Store card numbers yourself and you inherit the heaviest tier, including quarterly scans and on-site assessments. So the first PCI decision is an architecture decision: keep cardholder data out of scope entirely.

Three habits keep it that way:

1. Trust webhooks, not clients. Payment confirmations should arrive via signed webhooks from your aggregator, never by believing what the mobile app claims. Our webhooks design guide covers signature verification and idempotency keys. 2. Never log secrets. Full card numbers, CVVs, OTPs, and UPI credentials must be masked inside the logging library, where no developer can forget to redact them. 3. Watch the calendar. PCI DSS v4.0's future-dated requirements—stronger authentication and expanded controls on payment-page scripts among them—become mandatory on March 31, 2025. If your payment partner has not confirmed readiness, this is the week to ask.

## Audit Trails: Build Them on Day One

Every framework above eventually converges on one question: can you prove what happened? Regulators, auditors, and dispute teams all consume the same artifact—an audit trail—and retrofitting one into a live system is miserable. The minimum schema we now ship in every fintech build records the actor (user or system), the action, the entity affected, before-and-after values for sensitive changes, a timestamp from NTP-synced clocks, and a correlation ID that ties a mobile tap to the API call to the database write. Store it append-only, with archival storage and write-once protection for the five-plus years that KYC and transaction records typically require.

Operational requirements stack on top. CERT-In's 2022 directions require entities to retain logs for 180 days within India and to report security incidents within six hours of noticing them—a window you can only meet with alerting that actually pages a human, plus a rehearsed runbook. On compliance-sensitive flows, Manvi's QA team archives test evidence—runs, screenshots, sign-offs—because an auditor's favourite question is not whether a control exists but whether you can show it working. Keep your patch cadence honest as well: the Next.js middleware authorization bypass (CVE-2025-29927) disclosed just last week is a fresh reminder that a fintech stack is only as compliant as its dependency list. Our secure software development guide covers the wider practice.

## What Radiant Finance Taught Us

The lessons that survived the project were organisational as much as technical. Compliance scoping happened before estimation, not after, which kept the budget honest. A weekly regulatory sync between engineering and the client's compliance officer caught issues while they were still design discussions. And partner selection mattered as much as code: the bank and payment aggregator you integrate with determine half your obligations, so we evaluated their compliance posture as rigorously as their APIs. Our CEO Vivek Kumar has a standing rule that compliance items go on the sprint board like any other feature—with owners and deadlines—rather than living in a separate document nobody reads. Notably, the technology itself barely changed: we built on the same React Native and Node.js foundation that powers TalkDrill, our in-house English-speaking practice app. The stack was familiar; the compliance layer is what made fintech different.

• Map every data element to a storage region before writing code
• Choose a licensed payment aggregator and keep raw card data out of scope
• Design tiered KYC with async verification and a Video KYC fallback
• Ship an append-only audit log with actor, action, entity, and synced timestamps from day one
• Retain logs 180 days in India and rehearse the 6-hour incident-reporting runbook
• Record consent for every category of personal data the app collects
• Audit third-party SDKs for cross-border data flows each release
• Keep a compliance evidence folder: policies, test reports, vendor agreements

None of this should scare you off. India's fintech rails—UPI, Aadhaar, CKYC, DigiLocker—are genuinely world-class, and the rules above exist because real money moves through them. Teams that treat compliance as architecture ship on schedule; teams that treat it as paperwork discover it in week ten. If you are weighing a build and want a second opinion on the regulatory surface area before you commit, talk to us—it is a conversation worth having before the first sprint, not after.