I have written before about why your payment "takes three days." It comes down to the batch model: payments do not move one at a time, they move in files, on windows. A few people asked the natural next question. What happens when the batch itself fails?

Here is the part nobody sees.

A failed batch is not one problem. It is thousands of payments sharing one problem. So the first job is not fixing anything. It is scoping. What was in the file, which clients, which currencies, which cutoffs are still reachable today. Until you know the blast radius, every action is a guess.

The triage order matters more than speed

  1. Stop the bleeding. Make sure the file cannot partially process twice. A duplicate run is worse than a late one. You can apologise for late. You cannot un-send money.
  2. Find the poison pill. Often one malformed record fails an entire file. Isolate it, release the rest. Most of the batch is usually fine and waiting on one bad row.
  3. Race the cutoffs. Every payment system has windows. Miss the next one and "late today" quietly becomes "tomorrow," and tomorrow is a different conversation with the client.
  4. Tell people early. Clients forgive delay. They do not forgive silence. The worst version of an incident is the one where the customer finds out before you tell them.
  5. Write it down. The root-cause analysis is not paperwork. It is the only thing standing between you and the same 2am twice.

The pattern holds

Years of this and the pattern holds. The technology fails rarely, and the systems are mostly reliable. What separates a bad hour from a bad week is the human and procedural layer, the order you do things in under pressure.

I carried this triage order straight into running AI agents. Stop the bleeding, find the poison pill, do not let it run twice. It is the same discipline, a different system.