RBI and SEBI Cloud Rules: India's BFSI Data Boundary

Search here and you get law-firm restatements of the circulars, or provider pages assuring you a Mumbai region settles it. Both flatten three obligations — residency, supervisory access, testability — into one claim RBI's own FAQ contradicts.

One disclaimer, once: this is engineering guidance on infrastructure that satisfies published regulatory text, not legal advice.

Two Regulators, Two Different Obligations

The first mistake is reading the wrong instrument. Any sentence beginning "Indian financial services must…" is probably wrong: four instruments bind four populations.

A bank reads the RBI (Outsourcing of Information Technology Services) Directions, 2023, which apply to "all Banking Companies, Corresponding New Banks and State Bank of India" — collectively "commercial banks" — and, with them, Tier 3 and Tier 4 urban co-operative banks, credit information companies and the all-India financial institutions.

A non-banking financial company in the Middle layer or above no longer does. The RBI (NBFC – Managing Risks in Outsourcing) Directions, 2025, dated November 28, 2025, state that on issue "the existing Directions… as applicable to NBFCs stand repealed." Chapter IV and Chapter II's IT provisions reach the Middle layer and above, not the Base layer; existing agreements had to comply at renewal "or by April 10, 2026, whichever is earlier."

A payment system provider reads something narrower and older: RBI's April 2018 directive on payment system data, whose reach extends past the licence-holder to "system participants, service providers, intermediaries, payment gateways, third party vendors and other entities… in the payments ecosystem."

A SEBI-regulated entity reads one of two things depending on how it deploys — the next section. Three obligations get conflated. Residency is where bytes sit. Supervisory access is who can reach them, and how far down the sub-contracting chain. Testability is whether the documented exit has ever run.

What Actually Has to Sit Inside India

Draw the boundary on two axes: data class and deployment model. Payment system data is the sharpest — "All system providers shall ensure that the entire data relating to payment systems operated by them are stored in a system only in India." That is payment system data, not banking data generally. RBI's FAQ says banks "earlier specifically permitted to store the banking data abroad" "may continue to do so; however, in respect of domestic payment transactions, the data shall be stored only in India." So the regulator itself contradicts the all-banking-data-onshore claim, though the carve-out attaches to a pre-existing permission.

SEBI data on public, community or hybrid cloud. The March 2023 cloud framework (SEBI/HO/ITD/ITD_VAPT/P/CIR/2023/033) covers public and community cloud, and hybrid — "a combination of two or more out of public cloud, community cloud and private cloud." In scope, residency is broad: "the storage/ processing of data (DC, DR, near DR etc.) including logs," inside "the MeitY empaneled CSPs' data centers holding valid STQC… audit status."

SEBI data on private cloud or on-premise. Here the framework excuses itself: "A private cloud shall be considered as an on-premise deployment model," governed instead by SEBI's cybersecurity, outsourcing and BCP-DR circulars, so such deployments "are permitted, however… may not be governed by this cloud framework." The MeitY-empanelment condition belongs to the framework, which does not reach a private cloud: telling a self-hosting entity it must sit inside an empanelled provider is wrong. What remains is CSCRF's Box Item 10 on data localization: "SEBI REs shall ensure that processing and storage of data is done within legal boundaries of India." Its parallel mandatory standard puts the operative duty more narrowly still: original Regulatory Data kept available and easily accessible inside India. Both are CSCRF, and they are not the same bar.

The exceptions are narrow. The 2018 directive permits that "for the foreign leg of the transaction, if any, the data can also be stored in the foreign country" — note *also*: the India copy stays. Processing abroad carries a clock, below; CSCRF exempts global-SOC and SaaS security telemetry, conditionally.

Click to zoom

The Data Plane: Primary, DR and Near-DR Inside the Boundary

A residency boundary that lives only in a design document is one a Helm value breaches on a Tuesday. Make it an admission decision, so a misplaced replica fails at kubectl apply rather than at an inspection — an enforced golden path aimed at a jurisdictional constraint.

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: regulated-workloads-stay-in-india   # Kyverno 1.18+, ValidatingPolicy is GA
spec:
  validationActions: [Deny]
  matchConstraints:
    objectSelector:                 # the Pod must carry the class label
      matchLabels: { data.example.com/class: regulated }
    resourceRules:
      - { apiGroups: [""], apiVersions: [v1], resources: [pods],
          operations: [CREATE, UPDATE] }
  variables:
    - name: indiaZones
      expression: "['in-mum-a', 'in-mum-b', 'in-hyd-a']"
  validations:
    - expression: >
        has(object.spec.affinity) &&
        has(object.spec.affinity.nodeAffinity) &&
        has(object.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution) &&
        object.spec.affinity.nodeAffinity
          .requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms
          .all(t, has(t.matchExpressions) && t.matchExpressions.exists(e,
            e.key == 'topology.kubernetes.io/zone' && e.operator == 'In' &&
            e.values.all(z, z in variables.indiaZones)))
      message: "Regulated Pods must pin nodeAffinity to in-boundary zones."

The topology follows: every instance, WAL segment and base backup lands on India-resident capacity, and the keys stay where the provider cannot reach them. RBI's cloud appendix prefers an architecture "where encryption keys and Hardware Security Modules are under the control of the RE." SEBI, in its framework's scope, requires the entity to "retain the complete ownership of all its data and logs, encryption keys, etc." with the provider "working only in a fiduciary capacity." "Bring Your Own Key" is the named method, but only "wherever applicable": absent BYOK and Bring Your Own Encryption, the entity owes "a detailed risk assessment" and "equivalent functionality/ security" instead.

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata: { name: ledger-archive, namespace: regulated }
spec:
  configuration:
    destinationPath: s3://ledger-archive/
    endpointURL: https://objects.in-mum.example.com   # an endpoint you operate
    s3Credentials:                              # a Secret you hold, not a cloud role
      accessKeyId: { name: archive-creds, key: ACCESS_KEY_ID }
      secretAccessKey: { name: archive-creds, key: ACCESS_SECRET_KEY }
  retentionPolicy: "30d"
---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata: { name: ledger, namespace: regulated }
spec:
  instances: 3
  # NOT metadata.labels: CloudNativePG inherits nothing from Cluster metadata
  inheritedMetadata:
    labels: { data.example.com/class: regulated }
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values: [in-mum-a, in-mum-b, in-hyd-a]
  postgresql:
    synchronous:
      method: any           # quorum-based synchronous replication
      number: 1             # one in-boundary replica confirms each commit
      failoverQuorum: true  # only promote a replica known to hold quorum WAL
  storage:
    size: 500Gi
    storageClass: in-mum-nvme   # encrypted at rest, keys from an HSM you operate
  plugins:
    - name: barman-cloud.cloudnative-pg.io
      isWALArchiver: true
      parameters:
        barmanObjectName: ledger-archive

failoverQuorum: true promotes only a replica holding quorum-acknowledged WAL — the difference between a failover and a silent data-loss event. That spec field has been stable since CloudNativePG 1.28; the experimental label now attaches only to the deprecated alpha.cnpg.io/failoverQuorum annotation, which this manifest does not use. The archive is a barmancloud.cnpg.io/v1 ObjectStore driven by the Barman Cloud Plugin, not the in-tree barmanObjectStore field deprecated from CloudNativePG v1.26.

Turning the 24-Hour Repatriation Rule Into an Assertion

Exactly one crossing carries a deadline, which makes it the only one you can mechanically assert on. Where processing happens abroad, RBI's FAQ says the data "should be deleted from the systems abroad and brought back to India not later than the one business day or 24 hours from payment processing, whichever is earlier."

In practice this is discharged by a vendor attestation — a claim about the past, from the party with the least incentive to look. The alternative costs a cron entry: query the offshore store for records that outlived the window, fail loudly, record the verdict.

#!/usr/bin/env bash
# repatriation-check.sh — assert RBI's 24-hour bound on payment data held
# offshore. Non-zero exit on breach.
set -euo pipefail

: "${OFFSHORE_DSN:?set OFFSHORE_DSN to the offshore processing store}"
EVIDENCE_DIR="${EVIDENCE_DIR:-/var/lib/compliance/repatriation}"
RUN_AT="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
mkdir -p "$EVIDENCE_DIR"

read -r -d '' QUERY <<'SQL' || true
SELECT count(*),
       coalesce(max(extract(epoch FROM (now() - processed_at)) / 3600), 0)
FROM payment_records
WHERE processed_at < now() - interval '24 hours';
SQL

result="$(psql "$OFFSHORE_DSN" --no-align --tuples-only --field-separator='|' \
          --set=ON_ERROR_STOP=1 --command="$QUERY")"
overdue="${result%%|*}"
evidence="$EVIDENCE_DIR/repatriation-${RUN_AT}.json"

printf '{"at":"%s","bound_h":24,"over_bound":%s,"worst_age_h":%s}\n' \
  "$RUN_AT" "$overdue" "${result##*|}" > "$evidence"

if [ "$overdue" -ne 0 ]; then
  echo "BREACH: $overdue record(s) past the 24-hour bound. $evidence" >&2
  exit 1
fi
echo "OK: nothing offshore past the bound. Evidence: $evidence"

Note what the script does not do: interpret "one business day." That is a policy decision with holidays and settlement cycles in it; a wrong calendar silently loosens the control, and a flat 24 hours is never weaker. Note also which half it asserts: that nothing lingers abroad past the bound. That the same records landed in India is a second assertion, against the India-side store.

The evidence has a named consumer. The 2018 directive required system providers to report compliance to RBI with a System Audit Report "conducted by CERT-IN empaneled auditors." An auditor handed machine-generated verdicts is doing a different job than one handed a vendor letter.

Supervisory Access: What an Auditor Must Be Able to Reach

Residency is the obligation everyone designs for. Access is the one that quietly disqualifies architectures, because it is a property of the contract chain and the topology together.

RBI's IT outsourcing Direction requires clauses "to allow RBI or person(s) authorised by it to access the RE's IT infrastructure, applications, data, documents… stored or processed by the service provider and/ or its sub-contractors." The reach is transitive. The entity gets a matching "right to conduct audit of the service provider (including its sub-contractors)."

Two further clauses describe what must survive the relationship ending badly. The provider "is prohibited from erasing, purging, revoking, altering or changing any data during the transition period." Across borders, "availability of records to the RE and the RBI will not be affected even in case of liquidation of the service provider." That is architecture dressed as contract: if your only copy sits in a provider's estate, a receiver decides whether the regulator sees it.

CSCRF adds two that read as engineering requirements. A hosted service provider "shall ensure that there is no \"Kill Switch\" available in the Application, which would remotely disable the functioning of the solution." And exempted telemetry must still reach SEBI or CERT-In "within a reasonable time not exceeding 48 hours from the time of request." Exempt from residency is not exempt from retrieval.

An architecture passes the access test when four things hold:

• Every layer is reachable by someone you can compel. A managed control plane or fourth-party SaaS outside your contract chain is where the transitive audit right stops.
• Records outlive the provider. Backups, WAL archives and audit logs exist readable, on capacity you control.
• Logs are complete and jurisdictionally placed. Audit logs in a SIEM you operate beat asking a vendor, and CERT-In already sets 180-day retention inside India.
• Nobody else holds a switch. No remote disable, no licence heartbeat, no unrecoverable key.

India's DPDP Act is the horizontal baseline underneath; BFSI adds a sectoral layer with sharper access and testability duties. Where an entity elects public or community cloud, MeitY empanelment and STQC audit status is the gate.

Testing the Exit Instead of Writing It

Both regulators ask for an exit. SEBI: "Exit strategies shall be developed, which should consider the pertinent risk indicators, exit triggers, exit scenarios, possible migration options, etc." RBI's 2025 NBFC Directions say what it must accomplish — "prompt take-over of all records of transactions, customer and operational information, and configuration data… and purging at the CSP end, and ensuring independent assurance." Neither is satisfied by a document.

Take-over, purge and independent assurance are operations, and RBI already mandates a schedule for rehearsing them.

The RBI (IT Governance, Risk, Controls and Assurance Practices) Directions, 2023 set DR-drill periodicity for critical information systems at "least on a half-yearly basis," and define the drill precisely: "using it as the primary site… where usual business operations of at least a full working day (including Beginning of Day to End of Day operations) are covered." A ten-minute failover reverted before batch does not meet that. The target is "minimal RTO… and a near zero RPO."

Near-zero is not zero, and the gap is where the work lives. Every half-year you get a mandatory, budgeted, executive-visible window in which the estate is stood up elsewhere from artifacts you hold. That is the exit rehearsal, provided the drill emits evidence.

apiVersion: velero.io/v1
kind: Schedule
metadata: { name: regulated-hourly, namespace: velero }
spec:
  schedule: "0 * * * *"          # worst-case RPO for this set is 60 minutes
  template:
    includedNamespaces: [regulated]
    snapshotMoveData: true       # snapshot data lands in the in-boundary store
    ttl: 720h0m0s
---
apiVersion: v1
kind: ServiceAccount
metadata: { name: exit-rehearsal, namespace: velero }
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: drill-evidence, namespace: velero }
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: in-mum-nvme
  resources: { requests: { storage: 1Gi } }
---
apiVersion: batch/v1
kind: CronJob
metadata: { name: exit-rehearsal, namespace: velero }
spec:
  schedule: "30 18 20 2,8 *"     # half-yearly; restore-timing only
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 0
      template:
        spec:
          restartPolicy: Never
          serviceAccountName: exit-rehearsal
          volumes:
            - name: evidence
              persistentVolumeClaim: { claimName: drill-evidence }
          containers:
            - name: drill
              image: registry.in-mum.example.com/velero-drill:v1.18.2
              volumeMounts: [{ name: evidence, mountPath: /evidence }]
              command: [/bin/sh, -c]
              args:
                - |
                  set -eu
                  DRILL="drill-$(date -u +%Y%m%dT%H%M%SZ)"
                  START=$(date -u +%s)   # measure, do not estimate
                  velero restore create "$DRILL" \
                    --from-schedule regulated-hourly \
                    --namespace-mappings regulated:regulated-drill --wait
                  ELAPSED=$(( $(date -u +%s) - START ))
                  RTO=3600   # approved by the ITSC, in seconds
                  echo "$DRILL restored in $ELAPSED s, declared RTO $RTO s" \
                    > /evidence/"$DRILL".txt
                  test "$ELAPSED" -le "$RTO"

The restore is only stage one. The full loop — restore, run as primary through a real Beginning-of-Day to End-of-Day cycle, reconcile what the non-zero RPO cost, emit the bundle — converts an exit clause into a capability. The mechanics of Velero, etcd and honest RPO/RTO are a separate read.

Click to zoom

Failure Modes We See in Practice

These configurations pass a control questionnaire and fail the clause text. Most are defaults.

• Provider-held keys with a compliance label. A key marked "customer-managed" is still operated by the provider; RBI's HSM preference and SEBI's key-ownership rule both point at a key the provider cannot use without you.
• Cross-region replication left at the default. Object stores and managed databases replicate for durability, and the default region set follows the provider's footprint, not your jurisdiction.
• An offshore managed control plane. Data plane in Mumbai; control plane and support tooling elsewhere. Supervisory access follows the whole chain.

Then the readable-copy line, routinely quoted out of its scope. It is technical specification 4 for a Hosted Service — an "IT/ SaaS provider rendering IT services/ SaaS solutions hosted on IT infrastructure either owned or controlled and managed by the service provider": "If the data center is operated from outside the legal boundaries of India, then a copy of REs' data in human/ application readable form shall be maintained within the legal boundaries of India." That binds such a provider; offshore primary plus a readable India copy is an addition to the Box Item 10 duty above, never a substitution. *Readable* then does its own work — an opaque archive you cannot restore without the provider does not satisfy it.

The Long Game: Designing So the Next Circular Is a Config Change

This regime moves. The 2023 framework gave entities already on cloud "upto 12 months" to comply; CSCRF's timelines were later extended "till August 31, 2025 to all REs," with some entity classes carved out. Architecting for the current text alone is architecting for a snapshot.

The most instructive signal is a power SEBI reserved without exercising: "SEBI may specify concentration limits on CSPs (thereby setting a limit on the number of REs that a CSP may provide its services to)." That is not a security or residency requirement; it is a requirement to be able to *move* — the instinct behind DORA's concentration-risk regime.

So put the parameters a regulator can change behind boundaries you own. The placement boundary — the zone and storage-class allow-lists above — is where a new residency rule lands as a pull request. The key boundary — an HSM or KMS you operate, addressed through a standard interface, not a provider SDK — is where a key-custody rule lands. The portability boundary — open formats, exportable state, a restore path against artifacts you hold — is where a forced exit lands.

None of this argues against cloud; both regulators permit it. The argument is narrower: the obligations that actually bind — supervisory reach into sub-contractors, records surviving a liquidation, keys the provider cannot use, an exit executed rather than drafted — are properties of who controls the substrate. A team that owns its substrate satisfies them as a by-product; a team that rents one asks permission every time the text changes. Over the decades these systems run, that compounds.