How banks detect pig butchering payments (2026 inside view)

Banks don't lose pig-butchering money because they can't see it — they lose it because the customer overrides the warning. Modern retail-bank fraud stacks already flag the great majority of these transfers in real time. What follows is what those models actually look at, in plain language, so you can either (a) reverse-engineer your own bank's likely friction points before a loss happens, or (b) brief a victim on exactly which lever to pull in the first 24 hours.

What pig-butchering looks like to a fraud model

From the bank's side, the transfer is not 'crypto investment'. It's a sequence of signals — almost all behavioural, a few structural. The five that move every model are:

1. New beneficiary, large first transfer. First payment to a never-before-seen account, sized at >2× the customer's 90-day mean outbound.
2. Crypto-exchange MCC or known on-ramp IBAN. The beneficiary resolves to a Merchant Category Code or counterparty IBAN already tagged by the bank as a retail crypto on-ramp (Kraken, Binance, OKX, Bitstamp, MoonPay, Ramp, etc.).
3. Velocity break. Two or more transfers to the same on-ramp inside 7 days after months of zero crypto activity.
4. Session anomaly. The transfer was initiated from a session with screen-sharing software running, a new device fingerprint, or a remote-desktop user-agent.
5. Beneficiary-name mismatch. The customer types a friendly nickname into the reference field ('Jenny investment') that doesn't match the registered beneficiary ('Acme Crypto Services').

Any three of those firing inside the same payment authorisation are enough to trigger a hard hold at most tier-1 retail banks. Two will usually trigger a soft hold and a callback.

The forensic signals banks share post-hoc

When the payment does go out and gets reported as fraud later, fraud teams pivot to the network signals. These are the ones investigators actually use during a recall attempt:

• First-hop on-ramp. Identifies which exchange to send the Section-1782 / mutual-legal-assistance request to. The bank itself can't seize on-chain funds; the exchange can.
• Wallet-cluster age & funding pattern. A drainer wallet that just received eight victim deposits in 72 hours is a much stronger case for an exchange freeze than one with 18-month history and mixed activity.
• Behavioural cohort match. Most major banks now share anonymised victim-cohort hashes through industry utilities (UK's Stop Scams, US's FRB/SCAS feeds). If your transfer cohort already has eight other victims, the case escalates automatically.
• Recovery-scam re-victimisation flags. Banks now actively watch for a *second* outbound to a new 'recovery' beneficiary 7–30 days after the original loss. Reporting one is faster than ever and often blocks it pre-authorisation.

All of these are visible to the bank within hours — but only if the customer reports fast.

What victims and professionals can do

Three concrete moves, in order of impact:

1. Call the bank's 24/7 fraud line inside the first hour. Use the words 'authorised push payment fraud' and 'SWIFT recall' explicitly — those phrases route the call to the right team. (UK residents can quote the CRM Code; US residents quote Reg E; EU residents quote PSD2 strong-customer-authentication failure.)
2. Get the on-ramp wallet address from the bank, then run it through the free wallet checker and the Risk & Recon report. If the cluster is already on the GACS blacklist, screenshot the warning — it's the single fastest evidence pack you can hand the bank.
3. Report the entity on GACS at /report. Three independent reports auto-promote it to critical severity, and the resulting /scam/<slug> page outranks the scammer's own site in Google within weeks. That is what stops the *next* victim — which is what every bank fraud team genuinely wants.

For professionals advising clients, the Panic Guide is the single-screen workflow we hand to fresh victims. It includes the exact phone scripts and the data-preservation checklist your fraud team will ask for.

FAQ — pig-butchering and bank detection

• *My bank let the transfer go through. Are they liable?* In the UK, often yes under the CRM Code unless you ignored a specific warning. In the EU, increasingly yes under PSD3 drafts. In the US, generally no — Reg E excludes authorised payments, although class actions are eroding the line. Always get a written reason for the bank's decision.
• *Why didn't the bank warn me?* Most banks now interrupt high-risk crypto on-ramp payments with a confirmation step. The drop-off comes from customers who tick 'I trust the beneficiary' under coaching from the scammer.
• *Is there any model that catches it before the first transfer?* Yes — relationship-graph models that detect the romance-app introduction and the screen-sharing session before the payment is set up. Several UK and Dutch banks deploy these in 2026, but they require app-side telemetry that not every bank has.