The Payout Account Change Alert SOP

Purpose

This SOP makes sure that when anyone changes where the shop's payment processor deposits money, a named person knows within the hour and can stop the next payout before it leaves. The attack it exists for is quiet: someone gets into the processor account, swaps the bank account on file for one they control, and lets the shop keep taking cards as normal. Nothing looks wrong until the deposits stop arriving, and by then several days of card takings have gone to a stranger. The processor almost always sends an email when the payout destination changes. Without this SOP, that email lands in one inbox, often the very inbox the attacker already controls, and nobody acts on it.

Scope

Covers: changes to the payout bank account, the payout schedule, the account's login email or password, and the user list, on any processor or payments platform that deposits money to the shop. It covers both the standing setup that routes those alerts and the response when one arrives.

Does not cover: the shop's own bank and its outgoing payments (see related: Setting Up Bank Alerts and Dual Approval for Outgoing Money); a full incident response once a takeover is confirmed, which this SOP hands off to The First Hour After a Suspected Breach SOP at step 7; and diagnosing deposits that stopped with no alert at all (see related: Payouts Stopped Arriving in the Bank).

Roles and responsibilities

The handoff that matters is the second row. The secondary recipient is authorized in advance, in writing, to pause payouts without the owner's permission. A pause costs a day or two of cash timing. A payout sent to the wrong account may never come back. The person holding the alert must not have to wait for the person who might be the one compromised.

Procedure

1. Route the alerts to two people, one of them outside the login inbox. Action: in the processor's notification settings, switch on every alert for payout destination, payout schedule, login email, password, and user changes, and send them to the owner and the secondary recipient. At least one of the two addresses must be an inbox that is not the processor login email, so an attacker who controls the login inbox cannot delete the only copy. Acceptance: both addresses listed, and a test change (adding then removing a dummy user, or the processor's own test notification) produces an alert in both inboxes within 15 minutes. If wrong: only one address receives it, or the processor allows only one recipient; in that case set the login email to a shared address both people read, and set a forward from it to the secondary's own inbox. Re-run this check every quarter and whenever either person changes. Hazard: none physical, a desk step.

2. Open the alert, but not through the alert. Action: within 60 minutes of receipt, including evenings, the first recipient to see it signs in to the processor by typing its address or using a saved bookmark, never by clicking a link in the email. Acceptance: the dashboard's account or security history shows the change the email describes, with a date, time and the new destination's last four digits. If wrong: the dashboard shows no such change. Then the email itself is probably phishing built to look like an alert; do not click anything in it, forward it to the owner, and see related: Reading a Phishing Email Aimed at a Trade Shop. Hazard: none physical, a desk step.

3. Check the change against the change log. Action: open the shop's change log, a single shared note where the owner writes any planned change to payout details before making it, with the date and the new account's last four digits. Compare the alert to it. Acceptance: an entry with the same date and the same last four digits. If it matches, record "planned, matched" and close. If wrong: no entry, or an entry whose last four digits differ. Proceed to step 4; a mismatched digit is treated exactly like a missing entry, because "close enough" is how a swapped account gets waved through. Hazard: none physical, a desk step.

4. Call back on a channel you already trusted. Action: call whoever the processor's history names as having made the change, or the owner if no user is named, on the phone number in the shop's staff list. Do not reply to the email, and do not text a number that appears in it. Acceptance: within 30 minutes of the first call attempt, the person confirms or denies making the change in a live conversation. If confirmed: ask them to add the change log entry now, record the late entry, and close. If wrong: they deny it, or 30 minutes pass with no answer. Stop rule: treat the change as unauthorised and go to step 5 without waiting longer. See related: The Verify on a Second Channel Rule. Hazard: none physical, a desk step.

5. Freeze the money, then the access. Action: in the processor, switch payouts to paused or manual so nothing more leaves. Then, if the recipient's role allows: change the destination back to the shop's known account, change the password, sign out all other sessions, and remove any user not on the shop's roster. Acceptance: payout status reads paused or manual; the destination shows the shop's own last four digits; the session list shows only the current session; the user list matches the roster name for name. If wrong: the recipient cannot sign in, or their role cannot pause payouts or change the destination. Stop rule: do not keep trying passwords, which can trigger a lockout that slows the processor's own response. Go straight to step 6. Hazard: none physical, a desk step.

6. Call the processor's fraud or support line. Action: phone the processor using a number from its official website typed in by hand, or from the shop's original agreement, never from the alert email. Report an unauthorised payout destination change and ask them to hold all payouts and lock the account. Acceptance: a case or reference number, and the processor's confirmation that payouts are held. Ask, and write down, how many payouts have gone to the new destination since the change and on what dates. If any has, the owner files a report with the FBI's Internet Crime Complaint Center (IC3) the same day, because a receiving bank is more willing to freeze funds against a filed report. If wrong: the processor cannot verify the caller, because the attacker changed the login email. Have the owner make the call with whatever identity proof the processor asks for; this is why the owner's own details must stay current with the processor. Hazard: none physical, a desk step.

7. Tell the bank, then hand off. Action: call the shop's bank on the number on the back of the business debit card. Tell them a processor payout destination was changed without authority, ask whether any deposits from the processor have arrived recently, and ask them to confirm no users, alerts or payees have changed on the shop's online banking. Acceptance: the bank confirms its own settings are unchanged, or the recipient now knows which are not. Then open The First Hour After a Suspected Breach SOP, which owns finding how the attacker got in. If wrong: the bank finds changes too. That is a broader takeover; the breach SOP runs at once and the owner leads it. Hazard: none physical, a desk step.

8. Resume payouts only after the cause is found, and verify the first one. Action: when the owner and the processor agree the account is secure and the route in (a reused password, a phished login, a compromised email inbox) is closed, the owner switches payouts back to their normal schedule. Acceptance: the first payout after resuming arrives in the shop's bank account, with the amount matching the processor's payout record, on the processor's normal schedule. If wrong: it does not arrive, or arrives short. Stop rule: pause payouts again and return to step 6; do not resume twice on the same unanswered question. Hazard: none physical, a desk step; the risk is resuming while the attacker still holds the route in, which is why the cause comes first.

The record this produces

Every alert gets one line in the change log, whether it was planned or not: date and time received, who opened it and when, what changed (old and new last four digits), whether it matched a planned entry, callback result and time, pause time, processor and bank case numbers, root cause, resume date, and the date the first payout after resuming was verified in the bank. The owner reads the log monthly. An insurer, the processor or police may read it later, and its value to them is the timestamps.

Worked pass

This is a filled-in run from a pool service shop of nine. The alert, as it arrived:

From: notifications@[processor]
Subject: Your payout account was updated

The bank account receiving your payouts was
changed on Tue 7:42 PM.

  Previous account: ****0918
  New account:      ****4471

If you did not make this change, review your
account security now.  [Review account]

Step 1. Set up in the spring: alerts to the owner's address and the bookkeeper's own address. Quarterly test passed in July, both received within 4 minutes. Pass.

Step 2. The alert went to both at 7:42 PM. The owner was at a late service call with his phone in the truck. The bookkeeper opened it at 8:10 PM, 28 minutes after receipt, inside the 60-minute window. She typed the processor's address rather than clicking Review account. Security history showed the change at 7:42 PM, new destination ending 4471. Pass.

Step 3. The change log's last entry was from the previous year. No entry for 4471. Fail, proceed to step 4.

Step 4. The history named the owner's own login as the account that made the change. She called the owner's mobile at 8:15 PM: no answer. Again at 8:25 and 8:40: no answer. At 8:45 PM, 30 minutes after the first attempt, the stop rule fired. Treated as unauthorised.

Step 5. She switched payouts to manual at 8:52 PM. Status read manual. Pass on the pause. She then tried to change the destination back to 0918 and the processor refused: her role was bookkeeper, which can pause payouts but not edit bank details. Fail on the second half of the acceptance. Stop rule: she did not try other logins and went to step 6.

Step 6. She called the processor's fraud line from the number on its website at 9:05 PM, got a case number, and the processor locked the account. They confirmed no payout had yet gone to 4471; the next one was scheduled for 6:00 AM, about two days of card takings. Pass.

Step 7. The bank's after-hours line confirmed no changes to online banking users, alerts or payees. Pass. The owner called back at 9:40 PM, said he had made no change, and took over the breach SOP.

Step 8. Two days later the cause was found: the owner had reused his processor password on a supplier site that had been breached, and his processor login had no second factor. Both fixed, MFA on. Payouts resumed Friday; Monday's bank statement showed the deposit matching the processor's record. Pass.

Reading the run back against the purpose: the one failing step, the role that could pause but not revert, did not cost anything, because the pause alone was enough to stop the 6:00 AM payout. That is the case for authorizing the secondary to pause and nothing more: it is the one action that cannot itself be abused to move money.

References

• See related: The Verify on a Second Channel Rule
• See related: The First Hour After a Suspected Breach SOP
• See related: Payouts Stopped Arriving in the Bank
• FBI Internet Crime Complaint Center (IC3), for reporting a completed diversion of funds