India app compliance guide: DPDP, IT act and data localization

In 2018, the Reserve Bank of India gave payment companies six months to move all payment data onto Indian servers. Companies that had built global infrastructure - processing Indian transactions on AWS US East or Google Cloud US - had to rebuild their architecture from scratch. Some missed the deadline. The RBI blocked their licenses until they complied.

That wasn't a warning shot. That was the enforcement pattern India has maintained ever since.

India has 900 million internet users and one of the world's most complex compliance frameworks for apps. There's no single law. There's a stack: a general privacy law, an IT liability law, sector-specific mandates from three different regulators, and Aadhaar rules that carry criminal penalties if you get them wrong.

If you're building for the Indian market, you need all of it mapped before your first line of code.

Who this applies to

If your app touches any of the following, Indian regulations apply:

• Indian users (personal data of Indian residents triggers the DPDP Act)
• Indian payment transactions (triggers RBI guidelines, regardless of where your company is based)
• Insurance products in India (triggers IRDAI regulations)
• Securities trading or investment products (triggers SEBI requirements)
• Identity verification using Aadhaar (triggers Aadhaar Act and UIDAI licensing requirements)

You don't need an Indian entity or an office in India. You just need users in India. That's enough to bring you into scope.

India's digital economy isn't small or niche. The Telecom Regulatory Authority of India reported 969 million internet subscribers by March 2025 - the world's second-largest internet market. Any consumer app with global ambitions will collect Indian user data, whether it plans to or not.

The Indian compliance stack

Layer 1 - digital personal data protection act 2023 (DPDP act)

The DPDP Act is India's first full data privacy law. It came into force in 2023 and is modeled loosely on GDPR, with some important differences.

Core requirements:

• Consent before processing - You must obtain free, specific, informed, and unconditional consent before processing personal data. Consent cannot be bundled with terms of service. Each purpose needs separate consent.
• Notice in simple language - Before collecting data, provide a notice in English or any 8th Schedule language specifying what data is collected and for what purpose.
• Data Principal rights - Users (called Data Principals) have the right to access their data, correct inaccuracies, request deletion ("right to erasure"), and grievance redressal.
• Data Fiduciary obligations - As the entity processing data, you're a Data Fiduciary. You must maintain data accuracy, limit processing to the consented purpose, and delete data when the purpose is fulfilled.
• Children's data - Processing data of children under 18 requires verifiable parental consent. Apps that are "likely to cause harm" to children are prohibited.
• Cross-border transfers - The government will publish a negative list of countries to which transfers are prohibited. Until published, transfers are not broadly restricted - but this can change.

Who enforces it: The Data Protection Board of India (DPBI), once constituted. Penalties are assessed by the DPBI based on severity.

Penalty scale:

The enforcement environment is already pressuring compliance. India's Ministry of Home Affairs reported to Parliament that 22.68 lakh (2.27 million) cybercrime complaints were filed in 2024 - a 42% jump over 2023 - with Indians losing approximately Rs 22,845 crore ($2.7 billion) to cyber fraud that year, a 206% increase from the year before. The DPBI will have no shortage of incidents to pursue once constituted.

The DPDP Act vs. GDPR - key differences:

GDPR has six legal bases for processing. DPDP Act has two main ones: consent and certain "legitimate uses" (employment, state functions, medical emergencies). For most commercial apps, consent is the only applicable basis. This means no "legitimate interests" workaround that GDPR allows.

GDPR applies from day one regardless of company size. DPDP Act has a grace period for notified compliance, and full enforcement ramps up as the government activates regulations.

Layer 2 - IT act 2000, section 43a

Section 43A predates the DPDP Act by over a decade. It still applies.

It requires corporate entities handling sensitive personal data to maintain "reasonable security practices." If your negligence causes wrongful loss or gain to any person, you're liable to pay damages to the affected individual - with no upper cap.

The Information Technology (Reasonable Security Practices and Procedures) Rules 2011 define sensitive personal data as: passwords, financial information (bank accounts, card numbers), physical and mental health data, sexual orientation, medical records, and biometric information.

Why this matters alongside the DPDP Act: Section 43A gives users a civil remedy - they can sue you for damages from a data breach. The DPDP Act gives the regulator power to fine you. Both can happen for the same incident. A data breach can trigger a government fine under the DPDP Act and a civil lawsuit from affected users under Section 43A.

Layer 3 - IT act 2000, section 69

Section 69 gives the Indian government the power to intercept, monitor, or decrypt information transmitted through any computer resource - including apps. Any government agency can issue a direction to your app to allow access or provide data.

For most commercial apps, Section 69 is background compliance: you need to have a mechanism to respond to lawful orders, and you can't design your architecture to make that technically impossible.

For apps handling sensitive data (messaging, financial records, health data), you'll want legal guidance on how to handle Section 69 orders - particularly if your user base includes foreign nationals.

Layer 4 - RBI guidelines for payment apps

This is where India gets stricter than almost any other country.

In April 2018, the RBI issued a circular requiring all payment system operators to store payment system data only in India. The requirement covers:

• End-to-end transaction details
• Information collected, carried, or processed as part of the payment message
• Customer data (names, mobile numbers, emails, Aadhaar numbers, PAN numbers combined with transaction data)

What "stored only in India" means: The data must reside on servers physically located in India. Processing abroad for a short time (for fraud checks, for example) is permitted, but the data must be deleted from foreign systems after processing and only the Indian copy can be the system of record.

No mirroring allowed: You can't mirror Indian payment data to an overseas database for backup or disaster recovery. Your Indian systems must have local backup solutions.

Who it covers: Payment aggregators, payment gateways, card networks, prepaid instrument issuers, White Label ATM operators, and any other entity authorized under the Payment and Settlement Systems Act. Foreign entities offering payment services to Indian users are included.

AWS Mumbai (ap-south-1), GCP Mumbai, and Azure India Central are the standard cloud choices for RBI compliance.

Sector-specific regulators

On top of the general laws, three sectoral regulators add their own requirements.

IRDAI (Insurance Regulatory and Development Authority of India)

Insurance apps must comply with IRDAI's data localization and security guidelines. Customer data collected for insurance purposes must be stored in India. IRDAI's cyber security guidelines (2023) require insurers and intermediaries to maintain security operations centers, conduct regular audits, and report breaches within 6 hours of discovery.

SEBI (Securities and Exchange Board of India)

Securities apps (trading platforms, investment apps, mutual fund platforms) must comply with SEBI's cybersecurity framework. Data related to trading activity, client records, and audit trails must be maintained in India for a minimum period (typically 5 years for trading records). SEBI also mandates regular penetration testing and vulnerability assessments.

Telecom Regulatory Authority of India (TRAI)

Apps that use telecom data - call records, SMS, location data from telecom networks - are subject to TRAI regulations. Telecom data cannot be transferred abroad without specific authorization.

Aadhaar and ekyc - the high-risk area

Aadhaar is India's biometric identity system with over 1.4 billion enrolled citizens. It's used for eKYC (electronic Know Your Customer) verification in banking, insurance, telecom, and government services.

Here's the compliance trap: most private entities cannot use Aadhaar authentication.

The Supreme Court's 2018 ruling restricted private entities from using Aadhaar-based eKYC. A 2019 amendment opened it up - but only with explicit UIDAI authorization. Banks, telecom companies, and certain financial entities can apply for this authorization. Generic apps cannot.

What you cannot do:

• Store Aadhaar numbers in your database without authorization
• Use Aadhaar biometric data for authentication
• Display or print full Aadhaar numbers to users
• Use Aadhaar data for purposes beyond what UIDAI authorized

What unauthorized storage means: Under the Aadhaar Act 2016, unauthorized collection and use of Aadhaar data is a criminal offense. Imprisonment of up to 3 years and fines of up to 10,000 INR per violation.

The alternatives for KYC: For apps that aren't eligible for Aadhaar eKYC, alternatives include Video KYC (RBI-approved for banking), PAN card verification through the NSDL database, and DigiLocker document verification. These are slower and more friction-heavy but legally safe.

Architecture implications for Indian market apps

The compliance layers above have concrete infrastructure consequences.

Cloud infrastructure for Indian market apps:

You need a primary data center in India. The go-to choices:

• AWS Mumbai (ap-south-1) - most mature Indian region, widest service availability
• AWS Hyderabad (ap-south-2) - newer, good for redundancy
• GCP Mumbai (asia-south1) - strong alternative, especially for GCP-native stacks
• Azure India Central (Pune) - best if you're Azure-native

For RBI-compliant payment apps, your payment data must be stored and backed up within these Indian regions only. You cannot use S3 Cross-Region Replication to a non-Indian region for payment data.

Consent management: The DPDP Act requires granular, purpose-specific consent. Build a consent management layer that records: what the user consented to, when, and which version of the notice they saw. This log needs to be immutable - it's your evidence if the DPBI investigates a complaint.

Breach notification: The DPDP Act requires notification to the DPBI of any personal data breach. IRDAI requires notification within 6 hours. Build a breach detection and notification workflow before you launch, not after an incident.

"The most expensive architecture mistake we see on Indian market apps is treating RBI compliance as a separate workstream. Payment data localization, DPDP consent management, and breach notification all touch the same data layer. When you design them together from the start, the cost is a fraction of what teams pay to retrofit each one separately."

• Ashit Vora, Captain at 1Raft

Questions to ask your development partner

Before signing with any team to build for the Indian market, ask:

1. "Have you built RBI-compliant fintech apps in India?" - Specifically ask about payment data architecture. Do they know the 2018 circular? Have they built on AWS Mumbai for payment workloads? Past experience here is the clearest signal.

2. "How do you implement DPDP-compliant consent flows?" - Look for specific answers: purpose-linked consent, immutable consent logs, versioned notice documents, and a user-facing interface to view and withdraw consent. "We'll add a consent banner" is not the right answer.

3. "How do you handle Aadhaar in your KYC flows?" - This question has a clear correct answer: they should immediately explain that Aadhaar eKYC requires UIDAI authorization, and propose alternatives (Video KYC, PAN verification, DigiLocker) for apps that don't qualify. If they say "we'll just collect the Aadhaar number from users," walk away.

4. "What's your breach detection and notification setup?" - DPDP Act and IRDAI both require fast breach notification. Ask about their monitoring stack, incident response process, and how they'd handle a notification to the DPBI.

5. "How do you handle IT Act Section 69 orders?" - An experienced team will explain how they build a lawful intercept mechanism that doesn't compromise user privacy beyond what's legally required. This is sensitive, but it needs to be planned.

6. "How do you architect for both DPDP Act and RBI requirements simultaneously?" - These two laws have different scopes - DPDP Act covers all personal data, RBI covers payment data specifically. The right architecture satisfies both without duplication.

India app compliance checklist

Before development starts:

• Identify whether your app processes personal data of Indian users (DPDP Act scope)
• Identify whether your app handles Indian payment transactions (RBI scope)
• Identify applicable sectoral regulators (IRDAI, SEBI, TRAI)
• Determine whether your app will use Aadhaar - if yes, begin UIDAI authorization process
• Choose your India cloud region (AWS Mumbai, GCP Mumbai, Azure India Central)
• Engage Indian legal counsel for regulatory mapping

During architecture design:

• Design consent management layer - purpose-specific, version-tracked, immutable logs
• Design user rights workflows - access, correction, deletion, grievance
• For payment apps: architect payment data storage to Indian regions only, no cross-region replication
• For insurance apps: confirm IRDAI data localization requirements with counsel
• For securities apps: plan 5-year audit trail storage within India
• Build breach detection and notification workflow before launch
• Implement "reasonable security practices" per IT Act Section 43A - encryption at rest and in transit, access controls, audit logging

For Aadhaar handling (if authorized):

• Confirm UIDAI authorization is in place before building Aadhaar eKYC
• Never store full Aadhaar numbers in your database
• Implement masking - show only last 4 digits in any UI display
• Use Aadhaar data only for the authorized purpose, delete after use
• Conduct regular Aadhaar compliance audits

Before launch:

• Privacy notice published in English and regional languages if targeting non-English users
• Consent collection flows tested end-to-end
• Data Principal rights (access, deletion) tested and working
• Grievance Officer appointed and contact details published
• For RBI-regulated apps: compliance certification from RBI or payment network
• Incident response plan documented and tested
• Security audit completed (mandatory for SEBI/IRDAI regulated apps)

India's regulatory environment is maturing fast. The DPDP Act's implementing rules are being published in phases. The DPBI will become more active as it's constituted. RBI continues to tighten fintech regulations. An app that was compliant in 2023 may need updates by 2025. Build with regulatory flexibility in mind - not just compliance at the moment of launch.