Resilience Atlas

An interactive simulator showing how shared cloud outages can become systemic banking risks — and whether pooled SCFR capacity can improve recovery without a larger reserve budget.

Comment

Inspiration

A bank can be resilient on its own — and the financial system can still remain fragile.

Resilience Atlas grew out of my broader research on what affects bank resilience and what role digitalisation plays in it.

Digitalisation brings speed, scalability and continuity to banking. But it also creates a quieter and more systemic vulnerability: many institutions can end up depending on the same critical digital infrastructure.

That led me to a narrower question:

What happens when many banks rely on the same cloud provider and need recovery capacity at the same time?

An individual bank may have a reasonable backup plan. But if multiple institutions need failover resources simultaneously, the problem is no longer only institutional.

It becomes systemic.

That insight led me to the idea of a Systemic Cloud Failover Reserve (SCFR) — a shared reserve mechanism designed to prepare recovery capacity before a crisis rather than searching for it only after a major disruption begins.

Resilience Atlas is my attempt to turn that research idea into something that people can actually see, test and challenge.

What it does

Resilience Atlas is an interactive systemic cloud-resilience simulator for banking.

It models a synthetic banking system exposed to a shared cloud-provider shock and compares three recovery mechanisms:

1. Post-shock Market Sourcing

Banks try to obtain emergency failover capacity only after the outage has already happened.

2. Individual Reserves

Capacity is prepared in advance, but each bank holds its own reserve separately.

This creates an important systemic paradox:

capacity may exist in the system and still remain unavailable to the institutions that need it most.

3. SCFR Pooled Reserve

The same aggregate reserve budget is pooled and can be allocated across affected institutions according to a transparent coordination rule.

The core experiment is deliberately controlled:

Same shock. Same reserve budget. Different coordination.

That is the heart of Resilience Atlas.

The project does not ask whether “more backup capacity” helps.

It asks a more interesting and more policy-relevant question:

Can better coordination make the same recovery resources work better?

The product includes:

  • a six-scene Guided Simulation
  • an interactive Scenario Lab
  • a controlled comparison between Individual Reserves and SCFR
  • a local Robustness Sweep
  • a Model & Evidence section that separates real-world motivation from synthetic outputs

How I built it

I built Resilience Atlas as a browser-based interactive prototype that combines a simulation model, product design and explainable visual storytelling.

The product includes:

  • a deterministic simulation engine for bank recovery under shared cloud stress
  • synchronized Guided Simulation scenes
  • an interactive Scenario Lab that lets users change assumptions
  • dynamic UI and SVG-based visualisation
  • a local robustness analysis module
  • mobile-responsive behaviour
  • regression checks and CI workflows
  • a public deployment through GitHub Pages

The broader research framing and the SCFR concept existed before LovHack.

During the LovHack build period, I transformed that research direction into the current Resilience Atlas software product, including the interactive simulation logic, Guided Simulation, Scenario Lab, robustness module, mobile UX, testing, CI workflows, screenshots and final demo media.

So the research question came first — but the working product experience was built during the hackathon.

Challenges I ran into

The hardest challenge was not just technical.

It was conceptual.

I had to build something that was:

  1. academically serious
  2. visually understandable
  3. convincing as a real product demo

A project like this can easily become too abstract for a hackathon, or too simplified to preserve the systemic mechanism.

I also had to be careful about what the product claims — and what it does not claim.

A polished simulator can look more empirical than it really is, so I deliberately built a clear boundary between:

  • documented real-world motivation
  • synthetic assumptions
  • illustrative outputs

Another challenge was turning a systemic-risk mechanism into something intuitive.

“Shared cloud concentration” sounds abstract until the user can watch several institutions become affected at once and see recovery capacity become stranded in one structure and reallocated in another.

On the product side, I also spent a lot of time refining mobile interactions, simulation clarity, narration timing, transitions and regression protection after identifying real usability issues during testing.

Accomplishments that I'm proud of

I am most proud that Resilience Atlas is not just a concept explained in slides.

It is a working interactive prototype that allows the central idea to be tested.

A judge or user can:

  • trigger a different provider shock
  • modify assumptions
  • compare recovery mechanisms
  • inspect robustness
  • understand the evidence boundary
  • see how coordination changes outcomes

I am also proud of the fairness of the comparison.

SCFR does not perform better because I simply give it more resources.

Individual Reserves and SCFR operate under the same aggregate prepared reserve budget.

The difference is the coordination mechanism.

That makes the comparison much more meaningful.

Finally, I am proud that the project keeps intellectual honesty: it is ambitious in concept, but transparent about its synthetic nature.

What I learned

The biggest lesson behind this project is simple:

individual resilience does not automatically add up to systemic resilience.

Digitalisation creates enormous benefits for banking, but resilience cannot always be evaluated one institution at a time.

When infrastructure is shared, recovery becomes a coordination problem.

I also learned that research becomes much more powerful when people can interact with it.

Turning an abstract idea into a working simulator forced me to make every assumption explicit, every mechanism visible and every claim more disciplined.

It also showed me how product design can strengthen research communication: a concept becomes much more persuasive when people can test it themselves instead of only reading about it.

What's next for Resilience Atlas

I do not see Resilience Atlas as a finished answer.

I see it as the beginning of a stronger research and product framework.

Next steps could include:

  • richer shock design
  • additional resilience metrics
  • deeper sensitivity analysis
  • cost-aware reserve optimisation
  • governance and incentive design
  • expert validation with resilience practitioners
  • closer integration with future academic research on digitalisation and bank resilience

My broader goal is to keep developing this work toward practical systemic cloud resilience in banking.

I want this project to move from a synthetic prototype toward something that can help researchers, banks and supervisors discuss systemic digital resilience more concretely.

Important research boundary

Resilience Atlas is a synthetic mechanism stress-test and research prototype.

It does not assess real banks or real cloud providers.

It does not forecast real operational losses.

It does not claim that SCFR is already empirically validated.

Instead, it asks a narrower and testable question:

When a common digital shock affects multiple banks at once, can better coordination make the same recovery resources work better?

That is the question I want to keep developing beyond this hackathon.

Share this project:

Updates

Submission history