Nepal's power grid has come a long way from the years of scheduled load-shedding, and internet connectivity keeps improving year over year — but neither is failure-proof yet, and a fintech app that goes dark the moment either one hiccups isn't a serious product. The apps millions of Nepalis rely on daily to pay bills, send money, and run small businesses are built with a specific answer to this problem: layered redundancy, so that no single point of failure — a blown transformer, a cut fiber line, a congested tower — takes the whole system down with it. Here's how that actually works, layer by layer.
Layer One: Power Backup
Every layer above this one depends on power actually being there, which is why it's the foundation rather than an afterthought. At the data center level, licensed payment institutions run redundant power paths: grid electricity as the primary source, uninterruptible power supply (UPS) units to bridge the gap the instant grid power drops, and diesel or gas generators that kick in automatically if an outage stretches beyond what the UPS batteries can cover. Some newer facilities are increasingly supplementing this with solar capacity, both as a cost measure and as an additional buffer. At the branch and agent level — the physical points where cash-in, cash-out, and in-person banking still happen — smaller UPS units and battery backups serve the same purpose on a more modest scale, keeping point-of-sale terminals and local systems alive through shorter outages.
Layer Two: Network Redundancy
A payment system with perfect power but only one path to the internet is still one fiber cut away from going offline. Serious fintech infrastructure in Nepal is built with more than one way to reach the internet: a primary fiber connection from one internet service provider, a secondary connection from a different provider running in parallel, and increasingly, mobile data or satellite links as a further fallback for the most critical systems. When the primary path fails, traffic is meant to fail over to the backup automatically, ideally without a customer ever noticing the switch happened. The value of this layer is directly proportional to how genuinely independent the backup path is — a second ISP that happens to lease capacity on the same physical fiber route as the first doesn't actually add much redundancy at all.
Four layers, each covering for the one beneath it — power keeps the network alive, the network keeps the app alive, and the app keeps the data center connection alive.
Layer Three: App-Level Resilience
Even with strong power and network redundancy upstream, the last mile — the customer's own phone and local signal — is the hardest thing for any provider to fully control. This is where good app design does real work.
Offline Transaction Queuing
A well-built app can accept a payment instruction while offline, hold it locally, and submit it automatically the moment connectivity returns — rather than simply failing the transaction and forcing the user to start over.
USSD and SMS Fallback
Basic USSD codes and SMS-based banking don't require a data connection or a smartphone at all, working over the same signal a simple voice call would use — a genuine lifeline in areas with weak data coverage or during a broader internet outage.
Cached Balance and Recent Activity
Showing a locally cached, clearly time-stamped last-known balance during an outage — rather than a blank error screen — keeps a user informed even when a live, real-time balance check isn't currently possible.
Graceful Degradation
A thoughtfully built app narrows its own functionality during a partial outage rather than failing completely — disabling large transfers while still allowing balance checks, for instance, so users retain some capability rather than none.
Layer Four: Data Center Failover
At the core, behind the app entirely, sits the actual system of record — and that system needs its own backup. Nepal Rastra Bank's IT guidelines for regulated banks and financial institutions specifically require a board-approved business continuity and disaster recovery policy, covering a designated backup data center, defined Recovery Time Objectives (RTO — how long recovery is allowed to take) and Recovery Point Objectives (RPO — how much data loss is acceptable in the worst case), and regular testing of the whole plan rather than a document that sits untouched until an actual disaster proves it was never rehearsed. In practice, this generally means a "hot site" — a near-duplicate backup facility kept continuously synchronized with the primary one — so that if the primary data center genuinely goes down, operations can shift to the backup with minimal disruption to the customer.
When Regulation Meets Reality
This isn't purely theoretical planning. In 2025, during a period of civil unrest and government-imposed movement restrictions, NRB issued a direct notice instructing banks, development banks, finance companies, and payment institutions to keep essential banking and digital payment services running regardless — operating sensitive systems with limited on-site staff and shifting other functions to remote access based on risk assessment, while keeping the public informed about which branches, ATMs, and services remained available. It's a concrete example of business continuity planning being tested outside of a tabletop drill, and a reminder that resilience requirements exist precisely because Nepal's operating environment sometimes demands them on short notice.
| Resilience Layer | What Weak Design Looks Like | What Strong Design Looks Like |
|---|---|---|
| Power | Single grid connection, no UPS at branch level | Grid + UPS + generator/solar, automatic failover |
| Network | Single ISP with no backup path | Two independent ISPs plus a mobile/satellite fallback |
| App | Blank error screen the moment connectivity drops | Offline queuing, USSD/SMS fallback, cached balance display |
| Data Center | No backup site, or an untested one | Synchronized hot site with defined RTO/RPO, tested regularly |
What Users Can Do When an Outage Hits
- Check for a cached balance or "last updated" timestamp before assuming a transaction failed — many apps will clearly mark data as not current rather than pretending it's live.
- Try the USSD or SMS option if the app itself won't load — this fallback often works even when full data connectivity doesn't.
- Avoid retrying a large transfer repeatedly during an outage, since a queued transaction may still be pending submission — repeated attempts can risk duplicate transfers once connectivity returns.
- Keep a small amount of cash on hand as a practical buffer, the same way any prudent approach to occasional service interruptions would suggest, regardless of which provider you use.
- Check the provider's official social media or status page before assuming a personal device issue — a widescale outage affecting many users looks identical to a local one from the user's side.
Discussion