The Outlier Lab

Contact Change Cooling-Off Periods

Temporarily restricting payouts, payee changes and other high-risk actions after a change to email, phone, MFA or payout destination, so a takeover can't cash out before the owner notices.

What it is

ATO cash-out nearly always follows the same pattern. The attacker takes control, changes something so the owner can't see or stop what happens, then moves the money. The change might be swapping the email to silence alerts, swapping the phone to own the OTPs, adding an authenticator, or adding a new bank account, card, wallet or gift-card destination. A cooling-off period adds time between the change and the money movement, which is what the attacker most wants to avoid and what the genuine customer rarely needs urgently.

It works because ATO is a race. Attackers know the owner may notice within hours, so they cash out quickly. Making the riskiest actions wait, while alerting the old channels, turns that race in the defender's favor.

Diagram: Sensitive change (email / phone / MFA / payout dest), Notify OLD channels + in-app, Start cooling-off window, Payout or high-risk action requested?, Window expires, normal limits, Allow with reduced limit or step-up, Hold / review / block until window ends, Owner taps 'not me', Freeze payouts, revert change, start ATO case

What it stops (and what it doesn't)

Stops:

  • Change-then-cash-out patterns across bank, card, PayPal, crypto and gift-card payout rails
  • Outbound brokerage transfers soon after a contact change (ACATS Transfer Fraud)
  • Seller payout-account switches on marketplaces, where a takeover or bust-out redirects pending payouts (Seller Non-Delivery and Fake Listings)
  • Rewards cash-out to a new destination on a taken-over account (Loyalty and Rewards Redemption Fraud)

Doesn't stop:

  • Attackers who wait the window out. Long dwell is less common in ATO cash-out but does happen; defend with Transaction Monitoring and limits.
  • Customers being coached by a scammer to add a payee (Authorized Push Payment (APP) Scams). The cooling-off can still buy time for intervention.
  • Payments to destinations that already exist on the account.

Design considerations

1. Define a change taxonomy and a restriction matrix. An illustrative structure (calibrate to your data):

ChangeNotifyRestrict during window
Email changedOld email, phone, app pushNew payout destinations; large withdrawals; further contact changes
Phone changed / SIM-change signalOld phone (where reachable), email, appSMS as a factor; payout changes; withdrawals to new destinations
MFA method added or removed; passkey registeredAll channelsPayout-destination changes; Tier 3 actions
Password reset via recoveryAll channelsEverything in the rows above
New payout destination addedAll channelsPayouts to that destination above a small amount; daily caps
Address changedEmail, appCard reissue or shipment to the new address; checkbook orders
Several changes in one sessionAll channelsStrongest restriction set; route to review

Phone changes deserve extra care: pull carrier data (Phone Risk Signals) for recent SIM changes or ports, and require a non-SMS factor from MFA for the change itself.

2. Stack changes. One change is common and mostly benign. Email plus phone plus a new bank in a single session is rare and highly predictive. Restrictions should compound.

3. Scale the window to risk and value. A low-balance rewards account can have a short window with a reduced cap. A brokerage account with a large balance and a brand-new bank link warrants longer restrictions or a review. Use Customer Tenure and History and the change context (known device or new device) to scale.

4. Notify the old channels, with a real "not me" button. The notification is half the control. It has to reach the previous email and phone, explain what changed, and give a one-tap path that freezes payouts and opens an ATO case. Measure how fast customers respond.

5. Give legitimate customers a higher-assurance way through. A customer who changed banks and needs money today should be able to clear the restriction with stronger proof, such as a passkey assertion from a long-tenured device, document plus selfie matched to onboarding, or a verified callback. Don't let the support desk lift it based on a phone call alone.

6. Prefer restrictions to blocks where possible. Reduced limits and a forced step-up keep most legitimate activity working while cutting the attacker's take.

7. Every channel triggers the window. Changes made through support, IVR, partner APIs or back-office tools must start it too. Many ATO cases come from changes made through an agent.

Implementation path

StageWhat it looks likePrerequisites
CrawlFixed window after email, phone or payout-destination change: no payouts to new destinations; notify the old channelsEvent log of account changes; payout endpoint hooks; notification service
WalkRestriction matrix by change type; stacking logic; scaled by tenure and value; "not me" freeze flow; high-assurance override path; support-initiated changes includedAccount Change Events pipeline; policy service; IDV for overrides
RunRisk-scored windows (device and carrier context, value at risk); the window feeds Real-Time Transaction Risk Scoring; per-segment calibration through holdout tests; change-to-payout monitoringClean ATO labels; Experimentation and Champion-Challenger

Customer friction and trade-offs

  • Friction falls only on customers who just made a sensitive change, a small share of the base, many of whom are moving banks or replacing a phone.
  • The worst friction is a payout delay for someone who urgently needs money. Clear messaging ("for your security, transfers to new accounts are available on [date]") and an override path cut complaints a lot.
  • Overly long windows push customers toward support, where social engineering happens.

Measuring effectiveness

  • Change-to-cash-out ATO: confirmed ATO losses where a sensitive change came before the payout. Compare with the period before the control.
  • Catch inside the window: ATO attempts that hit the cooling-off, and the share of those where the owner hit "not me".
  • Notification response time: median time from change to "not me" for confirmed ATO. This tells you how long the window needs to be.
  • Genuine impact: payouts delayed per 1,000 changes, override requests, complaints and support contacts.
  • Displacement: watch for losses moving to existing destinations or to longer dwell, which means the attackers adapted.

Common failure modes

  • Wrong recipient: notifications sent only to the new email or phone.
  • Back-door changes: contact changes through support or back-office tools skip the window.
  • Reset by later changes: the window restarts, or worse ends, when another change happens.
  • Edits treated as old: a change to an existing payout destination's details isn't treated as a new destination.
  • Weak overrides: a phone call with knowledge questions is enough to lift the restriction.
  • One-size windows: the same rules for low-value and high-value accounts, so the control is too heavy for one and too light for the other.

Regulatory and policy notes

  • FTC Red Flags Rule (16 CFR Part 681). Card issuers have specific duties when an address change is followed shortly by a request for an additional or replacement card. Cooling-off generalizes that idea to other contact changes.
  • FFIEC 2021 authentication guidance. Supports layered controls around high-risk activities. Changes to account maintenance details are commonly treated as high-risk.
  • Brokerage. Rule 4512 trusted-contact information and Rule 2165 holds can complement cooling-off for older customers (Trusted Contact and Senior Investor Holds).
  • Reg E. A cooling-off hold delays a consumer-initiated transfer. Make sure account agreements and disclosures cover it.

Mechanisms addressed

Sources and further reading