BOARD DRAFT
DECISION MEMO 01Prepared for Business Continuity Review Board

Warm standby, designed for financial correctness.

Run payments in Mumbai and continuously replicate to Hyderabad. Keep the standby transaction path production-identical and pre-scaled, but preserve a single financial writer to eliminate active-active split-brain risk.

RECOMMENDATION

Pilot-light economics are too slow. Full active-active is too risky.

Application fleet at 40–50% standby capacity
No DNS dependency: Global Accelerator health routing
Automated failover with human financial-write approval
Quarterly production-grade game days
99.99%Availability target
< 60 secRecovery point
< 5 minRecovery time
₹500 CrDaily value protected

02 / TARGET STATE

Two Indian regions. One controlled writer.

A cell-based application tier fails independently; durable systems replicate with service-specific semantics. The failover controller enforces fencing before promotion.

AWS INDIA RESILIENCE BOUNDARY
— synchronous/local╌ cross-region
Global AcceleratorAnycast · health checks
WAF + ShieldPCI edge controls
Failover controllerFencing · pre-armed · audit

MUMBAI · ap-south-1

ACTIVE
EKS cells100% traffic
Aurorawriter
DynamoDBglobal table
Redisprimary
MSK — 3 AZproducer authority

HYDERABAD · ap-south-2

HOT
EKS cellspeak-ready
Aurorasecondary
DynamoDBglobal table
Redisreplica
MSK — 3 AZreplicated topics
Immutable evidenceS3 Object Lock · CloudTrail
Regional KMS keysIndia-only key material
Unified SLO telemetrySynthetic payment probes

WHY NOT ACTIVE-ACTIVE?

Cross-region write conflicts can become double charges or settlement divergence. A single ledger writer makes correctness explicit.

WHY NOT COLD STANDBY?

Provisioning, cache warming and broker recovery cannot reliably fit a five-minute RTO during peak load.

FAILOVER AUTHORITY

Composite alarms trigger a pre-armed, fenced sequence; the Incident Commander can confirm or abort, but no manual build step sits in the five-minute path.

03 / REPLICATION

Different data demands different guarantees.

Replication is selected by business semantics—not by a blanket active-active label.

Single writer in Mumbai; storage-level replication to Hyderabad. Managed switchover for drills, unplanned failover only after fencing the old writer. Transaction idempotency, a unique ledger constraint and reconciliation prevent double posting. Actual lag is continuously measured rather than assumed.

Correctness invariant: authorization, capture, refund and settlement mutations require a globally unique idempotency key. Ambiguous outcomes remain pending until ledger reconciliation—never retried as a fresh payment.

04 / OPERATIONS

Twelve runbooks. One command structure.

Every runbook declares trigger, authority, timed actions, validation, rollback and evidence capture.

RB-01 · SEV-0OWNER · INCIDENT COMMANDER

Complete Mumbai region loss

Execution pattern: Route, promote DB, Kafka, Redis, validate.

  1. 00:00–00:301
    Declare and contain

    Page SEV bridge; freeze deployments; validate two independent regional-failure signals.

  2. 00:30–01:302
    Fence financial writes

    Set Mumbai payment ingress to deny-new; capture last committed ledger sequence and Kafka checkpoints.

  3. 01:30–03:303
    Promote and route

    Approve Hyderabad authority; promote required data services; shift Global Accelerator weights in 10/50/100 stages.

  4. 03:30–05:004
    Prove and communicate

    Run synthetic authorize/capture/refund, compare ledger sequence, publish status and preserve evidence bundle.

SUCCESS GATE

Three synthetic payments pass; lag < 60s; ledger gap = 0; p95 < 300ms.

ABORT / ROLLBACK

Any duplicate posting, writer ambiguity, reconciliation break, or CDE control failure.

05 / ASSURANCE

Controls that leave evidence.

The matrix converts regulatory obligations into preventive controls, operating evidence and named accountability.

FRAMEWORKCONTROL OBJECTIVEIMPLEMENTED EVIDENCEACCOUNTABLE
RBI resilience & PA controlsBCP/DR, cyber resilience, auditability, incident responseQuarterly regional exercise, immutable evidence bundle, dual-control activation, board metricsCRO + CISO
RBI payment data localisationPayment-system data stored in India; overseas processing, if any, returned and deletedap-south-1 + ap-south-2 only, India-scoped backups/logs/keys, SCP region deny-listCompliance
PCI DSS v4.0.1Req. 1, 3, 4, 6, 7, 8, 10, 11, 12 across both sitesIdentical CDE segmentation, encryption, MFA/PAM, log integrity, scans, annual exerciseCISO
NPCI UPI operating standardsAvailability, latency, reconciliation, duplicate prevention and certification300ms latency budget guardrails, idempotency ledger, TPS tests, reconciliation reportsVP Engineering

Control interpretation must be validated by PaySecure’s legal counsel, acquiring partners, Qualified Security Assessor and NPCI certification team against the versions in force at implementation.

06 / BCRB

Five stakeholders. One defensible decision.

The board should approve the target state subject to measured exit criteria—not architectural intent alone.

01

CTO

Can this recover in five minutes?

Automated gates run in 210 seconds; DNS is not on the critical path.

02

CRO

What is the maximum financial exposure?

Writes pause on ambiguity; the ledger bounds loss to unconfirmed in-flight requests within the replication window.

03

Compliance Head

Can an auditor prove residency?

Region-deny policies, India-only keys/backups and quarterly evidence exports provide preventive and detective proof.

04

VP Engineering

Can eight engineers operate it?

Managed replication, one failover state machine and twelve rehearsed runbooks constrain operational load.

05

External Auditor

Is the cost proportionate?

Warm standby protects ₹500 crore/day while avoiding a permanently doubled application fleet.

BOARD RESOLUTION

Approve hot standby with pre-armed automated failover.

Release only after two consecutive game days demonstrate RTO ≤ 5 minutes, RPO ≤ 60 seconds, zero duplicate financial postings, India-only evidence, and peak TPS headroom of 30%.

15DAYS TO DESIGN
Q3TARGET

PRIMARY REFERENCES

RBI Payment AggregatorsRBI payment data storageRBI IT governance directionPCI DSS v4.0.1AWS reliability guidance