When an unusual transfer arrives minutes before payroll, pause it long enough to verify the sender, the purpose and the payment path. Speed matters, but an irreversible release needs evidence stronger than urgency.
In 1983, Stanislav Petrov was on duty at the Serpukhov-15 early-warning station when the Soviet system reported that US missiles had been launched. Then it reported more. Petrov had minutes to assess whether the warning was real. He judged it a false alarm rather than treating the screen as proof. The alerts were later traced to sunlight reflecting from clouds, a failure documented in the National Security Archive’s account of the 1983 war scare.
The stakes in a startup payment queue are smaller, thankfully. The shape of the decision is familiar: a system has raised a signal, a plausible explanation is available, and someone needs you to release the money before the window closes.
Urgency explains a transfer. It does not clear it.
A customer trying to fund payroll before midnight may send from a new account, pay an unfamiliar invoice amount, or ask for a destination change that bypasses the usual workflow. Each detail can have a legitimate explanation.
Each detail can also be how a fraudulent payment enters a business.
Treat the message from the customer as one piece of evidence, not the decision itself. Call a known number. Confirm through the buyer or finance contact already recorded in your CRM. Check whether the legal entity, sending account and invoice match what your team expected before the transfer arrived.
The fastest available channel is often the least reliable one. A reply from a compromised inbox, a WhatsApp message from a new number, or a forwarded payment receipt should not carry the whole decision.
Build a short verification path before the next alert
The useful preparation happens before 11:47 PM. Decide which payment changes require a second person, what counts as a known sender, and who can approve an exception when the founder is travelling between Accra, Berlin and the US.
Keep the process small enough to use under pressure:
- Match the transfer against an issued invoice and the contracted entity.
- Confirm any new bank account or beneficiary change through a pre-existing contact channel.
- Record who approved the exception and what evidence they used.
- Hold the funds when the evidence conflicts, even if the customer says payroll depends on it.
This protects the customer as well as the company. A legitimate customer with a genuine deadline may be frustrated by a short hold. They will be far worse off if a compromised account redirects money that was meant for their team.
The issue is ownership. If everyone can say yes to a transfer but nobody is responsible for verifying an exception, the decision will drift toward whoever feels the deadline most sharply. The same ownership gap can leave a critical workflow exposed long after the original builder has moved on, as in The One Name Behind a Critical Workflow, and What It Could Cost the Team.
Make the hold visible to the real customer
A hold should come with a plain explanation: the payment needs confirmation before it can be released, here is the person who can verify it, and here is the information required. Do not make a customer hunt through a generic support queue while payroll is waiting.
That message also creates a useful test. A real customer can usually identify the invoice, confirm the account through a known contact, and explain why the timing changed. A fraudster often pushes for secrecy, a new destination, or an exception to the normal approval route.
Petrov did not have certainty in 1983. He had incomplete signals and enough judgment to avoid treating an alarm as a conclusion. Founders need the same discipline around money: build the checks when the system is quiet, then follow them when someone asks you to move faster than the evidence allows.
Comments
No comments yet.