Payouts Stopped Arriving in the Bank
Why this matters
When card payouts stop landing in the bank, there are four ordinary explanations and one ugly one, and the ugly one gets more expensive every business day it is mistaken for an ordinary one. The ordinary ones are a risk hold, a reserve, a bank-side problem and a legitimate change somebody forgot to mention. The ugly one is that someone else now controls where the money goes. This case follows a six-person appliance repair shop through each candidate in turn, and the useful part is not the answer but which record killed each wrong answer, because those are the records you will need on the day it is your bank.
The signal
The shop's processor paid out every business day, two business days after each sale. On Thursday morning the owner was reconciling the week for payroll and noticed the business bank account had no processor deposits on Monday, Tuesday, Wednesday or Thursday. The prior Friday's deposit had arrived normally. Card sales had been steady all week; techs were taking cards in the field as usual and nobody had reported a failed transaction.
Four business days without a deposit, against a normal week of card sales, is not a rounding problem. The owner set aside payroll and started working the list.
One thing done first, before any diagnosis: the owner did not click any link in any email while investigating, and signed in to the processor by typing its address. That matters for the fifth hypothesis, and the owner did it because the shop's bookkeeper had insisted on it after an earlier phishing scare.
Hypothesis one: a risk hold
Why it was plausible. The previous week a tech had sold a full kitchen package, roughly four times the shop's usual ticket, on one card. Processors run automated risk checks, and an unusually large transaction from a small merchant is exactly what trips one. A risk hold is a processor pausing payouts while it reviews activity, and it can freeze everything, not just the large sale.
The record that killed it. The processor's payout history. A held payout shows as pending or paused, usually with a banner or a message asking for documents such as an invoice or proof of delivery. The shop's payout history showed four payouts, Monday through Thursday, each marked Paid, in green, with no banner and no message in the account inbox. A processor that has sent the money is not holding it.
That green "Paid" was the most misleading thing on the screen, and it nearly ended the investigation. On Tuesday the owner had glanced at the dashboard, seen Paid, assumed the bank was slow, and moved on. Paid tells you the money left the processor. It says nothing about where it went.
Hypothesis two: a reserve
Why it was plausible. A reserve is money the processor keeps back from payouts as a cushion against refunds and chargebacks. A rolling reserve withholds a percentage of each day's sales for a set number of days, and processors can impose one after a risk review, sometimes with only an email to say so. A large sale followed by a reserve is a common sequence.
The record that killed it. The payout detail for each day. A reserve shows as a separate line, a withheld amount next to the payout, and a reserve balance on the account summary. The shop's payouts were the full day's sales less the usual processing fees, about 97 percent of gross, the same proportion as every week before. No reserve line, no reserve balance. More basically, a reserve takes a slice of each payout; it does not take all of it, and the bank had received nothing at all.
Hypothesis three: the bank is the problem
Why it was plausible. If the processor sent the money and the bank never showed it, the bank might have rejected it. ACH deposits get returned for a closed account, a frozen account, or a mismatched name on the account. The shop had opened a separate savings account at the same bank that spring, and the owner wondered whether something had been mixed up there.
The record that killed it, and opened the real question. Two records together. First, the bank's incoming ACH activity for the week, which the owner pulled from online banking: no attempted processor deposits, and no returns. A rejected ACH deposit leaves a trace on the bank side, and none existed. Second, the processor's payout detail again, this time read line by line instead of glanced at. Each payout listed its destination as an account ending 4471. The shop's operating account ends 0918. The new savings account ends 2265.
That is the moment the case changed shape. The money had not been held, reserved or bounced. It had been sent, successfully, to an account the shop did not recognize.
Hypothesis four: a legitimate change nobody mentioned
Why it was plausible. Before assuming theft, it is worth ruling out the dull version. In a small shop, an owner, a bookkeeper and an office manager may all have processor access, and one of them might have moved payouts to a new account for reasons that made sense at the time.
The record that killed it. Three calls and a document. The owner phoned the bookkeeper and the office manager on their mobile numbers from the staff list; both said they had changed nothing and had no account ending 4471. The bank confirmed 4471 was not an account at that bank in the shop's name. And the processor's security history showed who made the change: the owner's own login. The owner had not.
Hypothesis five: someone else is in the account
The records that confirmed it. The processor's security history, read in full:
- Saturday, 11:14 PM: password reset requested, reset link sent to the owner's email
- Saturday, 11:17 PM: password changed
- Saturday, 11:20 PM: sign-in from a new device and a location two states away
- Saturday, 11:26 PM: payout bank account changed to the account ending 4471
No second factor was enabled on the account, so a password reset through email was all it took. That pointed at the owner's email as the real point of entry, and the owner went looking for the processor's alert, which should have arrived at 11:26 PM on Saturday. It was not in the inbox. A search found it, marked as read, in a folder called "RSS" the owner had never created, along with the password reset email.
The owner's email settings explained why. An inbox rule, created Saturday at 11:09 PM, moved any message containing "payout", "bank account" or "password" into that folder and marked it read. Someone had signed in to the owner's email first, set the rule so the alerts would be swallowed, reset the processor password from there, and then changed the destination.
This is the general lesson of the case, and it is why the green Paid nearly won. The processor did its job and sent the alert. The alert went to one inbox, and that inbox was the first thing the attacker took. See related: The Payout Account Change Alert SOP, which routes those alerts to a second person for exactly this reason.
Stopping it
With the takeover confirmed, the order of work was containment before cleanup.
- Payouts paused first, from the processor dashboard, before anything else. The fifth payout, Friday's, was due to leave in a few hours.
- The processor's fraud line called, using the number on its website. Case opened, account locked, destination reverted to 0918, all sessions ended.
- The email account secured next, because it was the master key: password changed from a different computer, every other session signed out, the inbox rule deleted, the recovery phone number and recovery email checked (the attacker had added a recovery email; it was removed), and a second factor turned on.
- The bank called, to report the diverted deposits and to confirm nothing had changed on the shop's online banking. Nothing had.
- A report filed with the FBI's Internet Crime Complaint Center (IC3) the same day, with the four payout dates and the receiving account's last four digits from the processor's records.
From there the shop moved into its incident response, which a sibling owns. See related: The First Hour After a Suspected Breach SOP.
What came back, and what did not
The processor contacted the bank that held the account ending 4471. Of the four diverted payouts, the two most recent, Wednesday's and Thursday's, were still sitting in that account and the receiving bank froze them; they were returned to the shop about three weeks later. Monday's and Tuesday's had already been moved out. So roughly half of four business days of card takings came back, and half did not.
Who bears the lost half is not something an article can settle. These were deposits to a business account, so the consumer protections of Regulation E do not apply; the processor's merchant agreement and the state's commercial law govern, and most processor agreements make the merchant responsible for the security of its own login. The owner took three things to an attorney and to the shop's insurance agent: the processor security history, the email inbox rule with its creation time, and the IC3 report number. This is not legal advice, and the coverage question in particular depends on the exact wording of the shop's policy. See related: What Cyber Insurance Applications Actually Ask.
The two records that would have shortened this
Looking back, the owner wrote down the cost of each day of delay: every business day between Monday and Thursday sent one more payout to 4471, and the two that left before Wednesday were the two that were lost. The case could have ended on Monday at the first glance if either of two things had been in place.
A second alert recipient. The processor's change alert existed and fired on time. A copy going to the bookkeeper's own inbox, which the attacker did not control, would have been read Saturday night or Sunday morning, before the first payout went out.
A daily match between payouts and deposits. The owner checked the processor dashboard but not the bank against it. Matching "processor says Paid" to "bank shows received" each morning is a two-minute task, and on Monday it would have shown one Paid with nothing received. See related: Setting Up Bank Alerts and Dual Approval for Outgoing Money, which covers deposit alerts alongside outgoing ones.
Neither of those would have kept the attacker out of the email. Multifactor authentication on the email and the processor would have, and both are on now. See related: Turning On Multifactor Authentication Without Locking Yourself Out.
References
- FBI Internet Crime Complaint Center (IC3), for reporting diverted funds
- Regulation E (12 CFR 1005), which covers consumer accounts and not business accounts
- See related: The Payout Account Change Alert SOP
- See related: The First Hour After a Suspected Breach SOP
- See related: The Owner's Personal Accounts Are Business Accounts