Stress-Test the Rails: A Continuity Plan for a Multi-Day bKash or Nagad Outage

Diagnosis

The risk is concrete and operational: a multi-day outage at bKash or Nagad that, in the words of the curated problem characterization, produces a "cash + remittance freeze." Mobile financial services in Bangladesh are now load-bearing infrastructure for everyday liquidity, wage disbursement, and inbound remittances. When one of the two dominant providers goes dark for days rather than hours, the failure is not an inconvenience. It strands households that hold their working balance inside the wallet, it interrupts remittance cash-out at the exact moment recipients need it, and it pushes informal cash demand onto a system that has been deliberately moving away from cash.

Two features make this a tier-class hazard rather than a routine IT event. First, concentration: the freeze risk is tied to a single provider, so there is no automatic shock absorber when that provider fails. Second, duration: a multi-day window converts a technical outage into a liquidity event, because users cannot simply wait it out. The lead responsible body for this domain is the ICT Division (ICTD), per the GovTwin entity registry, and the absence of a current_state reading underscores the core gap: there is no live continuity metric being watched before an incident occurs.

Recommended actions

1. Mandate a continuity and failover standard for systemically important MFS providers. Owner: ICT Division (ICTD), working through a binding technical directive (circular) developed with Bangladesh Computer Council. Mechanism: require each major provider to maintain hot-standby infrastructure, a documented recovery-time objective, and an annual independent resilience attestation. Observable signal: every systemically important provider files a tested continuity attestation and a measured recovery-time objective on file with ICTD.
2. Stand up a real-time MFS availability monitor. Owner: Bangladesh Computer Council under ICTD direction. Mechanism: a uptime and transaction-success dashboard fed by provider telemetry, replacing the current null state with a watched indicator. Observable signal: a live availability metric exists and triggers a defined escalation when sustained degradation crosses threshold.
3. Build a cross-provider fallback so a freeze at one wallet does not freeze the user. Owner: ICTD coordinating with Bangladesh Hi-Tech Park Authority on the interoperability layer. Mechanism: enforce interoperable cash-out and transfer routing so that during a provider outage, agents and recipients can complete essential transactions through an alternate channel. Observable signal: in a simulated outage of one provider, a test user can still cash out a remittance through an alternate route.
4. Establish a remittance-and-wage backstop protocol. Owner: ICTD as convener, with the supporting bodies named in the registry. Mechanism: a pre-agreed playbook that, on a declared multi-day outage, activates agent-based manual cash-out and priority queues for remittance recipients. Observable signal: the playbook is published, rehearsed, and has named accountable owners before the next incident.
5. Run a mandatory annual outage drill. Owner: ICTD with Ministry of Science and Technology. Mechanism: a scheduled exercise that simulates a multi-day single-provider freeze end to end. Observable signal: a completed drill with an after-action report and a closed list of remediation items.

Sequencing (first 12 months)

Start with the monitor (action 2): replacing the null current_state with a watched availability signal is the cheapest, fastest step and it unlocks everything else, because you cannot manage a freeze you cannot see. In parallel, issue the continuity directive (action 1) so providers begin building failover capacity on a clock. Once telemetry and standards exist, the interoperability fallback (action 3) and the remittance backstop (action 4) can be designed against real data. Close the year with the first drill (action 5), which validates whether the prior four actions actually hold under a simulated multi-day outage.

Risks and constraints

The binding constraints are political and structural, not technical. Concentration gives the dominant providers leverage to resist costly resilience mandates, so ICTD needs a directive with teeth rather than voluntary guidance. Interoperability touches commercial rivalry between providers, which is the hardest fallback to enforce. Fiscally, the monitor and drills are low-cost, but provider-side hot-standby capacity is not, and that cost will be contested. There is also a coordination risk: the freeze spans wallets, agents, and remittance flows, so a single lead body must own the playbook end to end rather than leaving gaps between agencies.

Bottom line

A multi-day bKash or Nagad outage is a liquidity event, not an IT event, and Bangladesh currently watches no live signal that one is underway. ICTD should move first on a real-time availability monitor and a binding continuity directive, then rehearse the freeze before it happens for real.