← US Incorporation

/ 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.

DC

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.

  1. Data classification: identify which data categories are regulated (payment data, personal data under DPDP, SEBI records, telecom subscriber, insurance policyholder, health records).
  2. Data map: document where each category is stored, processed, accessed, retained.
  3. Architecture gap analysis: identify where current architecture doesn't match localisation requirements.
  4. India infrastructure setup: AWS/GCP/Azure India regions; India-held encryption keys; India-based disaster recovery.
  5. Data processing agreements: with Indian processors; cross-border transfer SCCs where applicable (post DPDP Section 16 notifications).
  6. Compliance audit: CERT-In empanelled auditor annual audit for payment data; sector-specific audits as applicable.
  7. Reporting: RBI quarterly / annual reports; DPDP breach notifications; sector regulator reports.
  8. 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.

Does India have a general data localisation law?
No single unified law. Instead layered regime: RBI payment data localisation (April 2018, mandatory India-only), DPDP Act Section 16 country blocklist (no notifications yet 2026), sector-specific rules (SEBI, TRAI, IRDAI, health). Foreign SaaS must map data types to applicable regulator and architect data residency accordingly.
What exactly is 'payment data' under RBI localisation?
User data at various stages of payment flow: customer data (name, address, device), payment sensitive data (card number, CVV, OTP), transaction data (location, origin, destination, timestamp), beneficiary data. End-to-end payment transaction data. Entire data must be stored only in India for payment system operators, PAs, PGs, PPIs, card networks, fintechs offering payment-related services.
Can I temporarily process payment data abroad for fraud scoring?
Yes - temporary processing abroad is permitted but processed copy must be deleted after processing complete. End-state storage must be India-only. In practice: fraud scoring data flows abroad for ML inference, then is deleted; India-stored transaction record remains. Audit trail must document this flow.
How does DPDP Section 16 affect cross-border data transfer?
Blocklist approach: Central Government may notify specific countries where personal data of Indian residents may NOT be transferred. Currently no restrictions notified (2026). Prudent approach: document cross-border flows, DPAs with foreign processors, India-side data residency for sensitive sectors, prepare for future restrictions if notified.
What are the typical architectural patterns for Indian data localisation?
Hybrid architecture: AWS/GCP/Azure India regions for Indian users; global stack for non-Indian users. India-only database replicas (no cross-region to non-India for regulated data). Multi-tenant with Indian tenants on Indian infrastructure. India-held encryption keys. Non-India engineers can access anonymised data but not raw regulated data. India-based disaster recovery.
Does BQP help foreign SaaS / fintech with India data localisation compliance?
Yes - data classification + mapping, architecture gap analysis, India infrastructure structuring, DPA + SCC drafting, CERT-In empanelled auditor coordination, RBI reporting, DPDP compliance integration. Co-ordinated with foreign client's engineering + security teams + global privacy counsel. Scope-based engagement. WhatsApp +91 78018 87130.

Related reading

Keep going.