Inspiration

A hurricane can pass in hours. For the people left without a safe home, clean water, or basic supplies, the emergency continues long afterward.

Getting help to those people takes more than donations. Someone needs to know what was ordered, what actually arrived, and whether the payment matches.

After Hurricanes Irma and Maria, those connections broke down in Puerto Rico. A 2020 Department of Homeland Security Inspector General report found that FEMA lost visibility of approximately 38% of its commodity shipments to Puerto Rico, worth an estimated $257 million. The report also found that FEMA did not ensure documented proof of deliveries. These findings concern tracking and accountability; they do not mean every untracked shipment was stolen or never arrived.

Behind those records were people waiting for help. Relief workers needed answers they could trust.

That is the problem Calm After the Storm addresses. Our prototype could help with the delivery documentation and payment accountability part of a response like this by keeping accepted quantities, payment allowances, and banking records connected. It cannot repair roads or make supplies arrive, but it can help a team understand what it received and what it should pay.

What it does

Calm After the Storm follows relief supplies from delivery acceptance to payment confirmation.

A separate person checks and accepts the delivery, so the supplier cannot approve their own count. The app then determines what can be paid based on the accepted quantity, previous payments, and permitted advances.

Our demo makes that concrete. A team orders 200 hygiene kits at $50 each, but only 100 arrive and are accepted.

The first bill covers 60 kits. The app allows a $3,000 payment through Capital One’s Nessie sandbox and checks the banking record before confirming it. Forty accepted kits remain unpaid.

The next bill requests payment for another 60 kits. Paying it would mean paying for 120 kits when only 100 were accepted. The app stops the payment and explains the mismatch.

That matters because the money still available may be needed for the next delivery.

How we built it

We built a web application that connects delivery records and payment rules to Capital One’s Nessie API.

Our application determines whether a bill can be paid. Nessie provides the sandbox banking activity. We connect the returned transaction to the bill and check its details before showing confirmation.

We also built a guided story mode that lets someone follow the same delivery through acceptance, payment, and an overpayment refusal.

All demonstrated banking activity uses test data. No real money moves.

Challenges we faced

One of our hardest challenges was a payment with no clear answer.

What happens if the bank records a payment, but the app never receives the reply? Pressing “pay” again could send the money twice.

We built the workflow to pause that bill, keep its money and accepted quantity reserved, and check Nessie’s records before allowing another attempt. If the result remains uncertain, the payment stays paused.

Another challenge was making the explanation useful under pressure. Someone coordinating relief needs to understand why a payment stopped and what needs attention. We worked to make those answers visible in ordinary language.

What we learned

We learned that accountability depends on keeping a few essential facts connected: what arrived, who accepted it, what was paid, and what the bank recorded.

We also learned that an unusual bill does not automatically mean someone cheated. People make mistakes, deliveries arrive in parts, and systems lose replies. A useful tool needs to explain the evidence without turning uncertainty into an accusation.