On a Tuesday morning in June 2023, a chunk of AWS’s Mumbai region (ap-south-1) hiccupped. For most consumer apps, it was a two-hour inconvenience. For a couple of NBFCs and payment aggregators we know, it meant failed EMI collections, stuck UPI reconciliations, and a very uncomfortable call with their board. One fintech lost close to ₹40 lakh in a single day from failed transaction retries and SLA penalties to merchant partners. That’s the kind of story that gets a CTO rethinking “we’re on AWS, we’re fine” as a strategy.
At Speqto, we’ve sat in enough of these post-mortems to notice a pattern: the BFSI and fintech companies that recover fastest from cloud incidents aren’t the ones with the biggest budgets. They’re the ones who never bet their entire infrastructure on one provider’s uptime, pricing, or compliance posture.
It’s Not Just About Downtime
Everyone talks about multi-cloud as a hedge against outages, but for regulated businesses in India, there are three other pressures that matter just as much:
- Regulatory data residency — RBI’s 2018 payment data storage circular and subsequent guidance mean certain transaction data must stay within India. If your primary cloud’s India region has limited service maturity (fewer managed services, smaller capacity), you need a credible fallback that still meets residency rules.
- Vendor pricing leverage — We worked with a mid-sized lending platform that renegotiated its AWS enterprise agreement and got a 22% better discount simply because they had a working production workload already running on GCP. The account team knew they weren’t bluffing.
- Concentration risk from an audit standpoint — SEBI and RBI auditors increasingly ask about business continuity plans that go beyond “we have backups.” A documented multi-cloud DR plan carries real weight during IT audits and vendor risk assessments.
A Real Example: How One NBFC Client Split Its Stack
A Mumbai-based NBFC we work with runs its core loan management system and customer data on Azure (largely because of their existing Microsoft enterprise licensing and AD integration), but keeps their disaster recovery environment on AWS, with database replication happening via a managed service layer rather than native cloud-to-cloud tools. Their customer-facing collections app, which needs to stay up even if core banking systems have a hiccup, runs on a separate GCP project with its own Cloud SQL instance synced every 15 minutes.
Is this more complex to manage? Absolutely. They needed us to build out a unified observability layer (we used a combination of Datadog and custom scripts) because each cloud’s native monitoring doesn’t talk to the others. But when their primary Azure region had a networking issue last year, their collections app never went down. Customers didn’t even notice.
Where Multi-Cloud Actually Makes Sense
We’ll be honest — multi-cloud isn’t free, and it’s not for every workload. Running everything redundantly across three providers is a great way to triple your DevOps headcount for no good reason. The CTOs who get this right are selective:
- Payment and transaction processing — highest priority for redundancy, since downtime here has direct revenue and regulatory impact.
- Customer data storage — split by residency requirements and backup strategy, not necessarily by provider for the sake of it.
- Analytics and non-critical batch jobs — good candidates to run wherever pricing is cheapest that week; these don’t need the same redundancy guarantees.
- Internal tools, dev/staging environments — usually not worth the multi-cloud complexity at all.
One mistake we see often: teams go multi-cloud by accident, through shadow IT and M&A, rather than by design. A fintech client inherited a Google Cloud setup from an acquired startup while running everything else on AWS, and nobody had mapped out the security boundaries between the two. That’s not a strategy — that’s technical debt wearing a strategy’s clothes.
What We Tell CTOs Before They Start
Before adding a second cloud provider, we push clients to answer three questions honestly:
- Which specific workloads actually need cross-cloud redundancy, based on revenue and compliance impact — not everything does.
- Do you have the in-house skills (or a partner) to manage networking, IAM, and observability across providers? This is where most multi-cloud efforts quietly fail.
- What’s your actual recovery time objective (RTO) for each workload, and does your proposed setup realistically meet it — have you tested a failover, or just assumed it works?
Multi-cloud isn’t about chasing the latest infrastructure trend. For BFSI and fintech CTOs, it’s risk management with a technical face — the same instinct that makes you diversify a loan book or hedge currency exposure. At Speqto, we’ve helped half a dozen regulated fintechs design these splits without turning their ops team into a three-ring circus. If you’re staring at a single-cloud dependency and wondering if it’s a liability on your next audit, that’s usually the right instinct to listen to.
