/ Foreign Clients · Data Localisation · Updated 2026-10-15
India data localisation, what foreign SaaS must architect.
India does not have a single unified data localisation law. Instead, sector-specific rules + the DPDP Act's country-blocklist mechanism create a layered localisation regime. For foreign SaaS, fintech, e-commerce handling Indian user / payment / sensitive data, understanding which data must stay in India is critical infrastructure decision. Here's the complete 2026 framework.
Written by CA Durgesh Chavda
Chartered Accountant (ICAI) · Founder, Bharat Quantum Prospera · US incorporation, India-US DTAA, FEMA ODI, NRI taxation, cross-border structuring · LinkedIn
/ The layered regime
Multiple regulators, different rules.
- RBI (Reserve Bank of India): payment data of Indian consumers — mandatory India-only storage (April 2018 circular).
- DPDP Act 2023: Section 16 permits Central Government to notify countries where personal data of Indian residents may NOT be transferred. 'Blocklist' approach (no notifications yet 2026).
- MeitY (Ministry of Electronics and Information Technology): proposed Digital India Act (DIA, pending) may add digital services localisation; current draft framework still being discussed.
- SEBI (Securities and Exchange Board of India): broker / depository data retention in India; critical records on Indian servers.
- TRAI / DoT (telecom): subscriber data storage within India under Unified Access Service Licence conditions.
- IRDAI (insurance): policyholder data in India; cloud hosting restrictions.
- Health Ministry / specific health IT framework: Ayushman Bharat / electronic health records residency rules.
Foreign SaaS / fintech must map data types to applicable regulator and architect data residency accordingly.
/ RBI payment data localisation
The strictest.
- April 2018 circular: 'all system providers shall ensure that the entire data relating to payment systems operated by them are stored in a system only in India'.
- 'Payment data' definition: user data at various stages of payment flow — customer data, payment sensitive data (card number, CVV, OTP, device data), transaction data (location, origin, destination, timestamp), beneficiary data.
- Entities covered: payment system providers — banks, non-bank payment system operators (PPI, PA, PG, card networks), payment service providers, international payment networks (Visa, Mastercard, Amex), payment system intermediaries, FinTechs offering payment-related services.
- Entire data: 'end-to-end transaction data'. Full data stored in India; copies abroad only for processing (then deleted after processing complete).
- Audit + reporting: RBI empanelled CERT-In auditor annual system audit confirming localisation; findings reported to RBI.
- Non-compliance: suspension of payment operations in India. Severe operational risk.
/ Architectural implications
What foreign SaaS builds.
- Hybrid architecture: India-hosted stack for Indian users + global stack for non-Indian users. Common pattern: Indian AWS Mumbai / Google India / Azure India region for user-facing stack; global edge for non-regulated functions (CDN, analytics without PII).
- India-only database replicas: primary + replica in India regions; no cross-region replication to non-India regions for regulated data.
- India-specific tenant / shard: multi-tenant SaaS with Indian tenants on Indian infrastructure.
- Data access controls: non-India engineers can SEE anonymised / aggregated data; cannot access raw regulated data stored in India.
- Processing abroad with deletion: temporarily permissible to process payment data abroad (e.g., fraud scoring at global data centre) but must delete processed copy after processing complete.
- End-to-end audit trail: logs showing where regulated data was stored / processed / accessed at every stage.
- Encryption: at rest + in transit, with India-held keys for Indian regulated data.
/ Compliance workflow
What foreign SaaS does.
- Data classification: identify which data categories are regulated (payment data, personal data under DPDP, SEBI records, telecom subscriber, insurance policyholder, health records).
- Data map: document where each category is stored, processed, accessed, retained.
- Architecture gap analysis: identify where current architecture doesn't match localisation requirements.
- India infrastructure setup: AWS/GCP/Azure India regions; India-held encryption keys; India-based disaster recovery.
- Data processing agreements: with Indian processors; cross-border transfer SCCs where applicable (post DPDP Section 16 notifications).
- Compliance audit: CERT-In empanelled auditor annual audit for payment data; sector-specific audits as applicable.
- Reporting: RBI quarterly / annual reports; DPDP breach notifications; sector regulator reports.
- Ongoing monitoring: data access logs, incident response, periodic re-classification.
/ Common foreign-SaaS mistakes
Avoidable breaches.
- Global SaaS stack with India users: AWS US East holds all data including Indian users. Payment data breach if any payment data flows there.
- Analytics with PII to foreign CRM: Indian user events (clicks, impressions, demographic) streamed to Mixpanel / Segment / Amplitude without PII removal.
- Email providers abroad: Indian user emails sent via Mailgun / SendGrid / Postmark US — email content touches foreign servers.
- Customer support tools: Zendesk / Intercom / Freshdesk tickets with Indian user data stored outside India.
- Payroll / HR: BambooHR / Rippling with Indian employee data stored outside India (though HR data less strictly regulated).
- Backup / DR to foreign regions: snapshot backup to non-India region containing regulated data.
- Not storing audit logs in India: logs showing user actions = user data = may need India storage.
Each of these requires architectural review + India-side mitigation.
Last updated: 2026-10-15.
/ Ready when you are
Foreign SaaS / fintech with Indian user or payment data?
Multi-regulator localisation regime: RBI + DPDP + sector-specific. BQP: classification + architecture gap analysis + India infrastructure + audit + reporting. Scope-based engagement.
FAQ
Common questions, answered.
Related reading