Fake bank alerts and POS scams: how fraudsters do it and how defenders catch them

A fake bank alert is a message that looks like a credit notification when no money has actually arrived. The only check that settles it is your balance inside the banking app, internet banking or a statement, because the SMS, email or screenshot is just text that anyone can produce.

That one sentence is the whole defence for a shop owner. For someone starting a cybersecurity career, it is the beginning of a much more interesting question: why is the alert so easy to fake, and how do banks, merchants and fraud analysts catch the people doing it? This post walks through both sides. Every example uses fictional businesses and a fictional bank, and nothing here is a claim about any real bank’s systems.

Why a fake bank alert works: the trust problem in one picture

Most people treat an alert as proof of payment. It is not. It is a notification about a payment, delivered over a channel the bank does not fully control. Fraudsters exploit the gap between “I received a message” and “money is in my account”.

Three things make the gap wide:

1. Speed and social pressure. The scam usually happens at a till, a market stall or a POS kiosk, with a queue behind the customer and a friendly “it has entered, check your phone”.
2. Habit. Merchants get dozens of genuine alerts a day. A message that looks right gets a glance, not an investigation.
3. The channel itself. SMS was never designed to prove who sent a message, and screenshots prove nothing at all.

How fraudsters fake transfer alerts

Spoofed SMS sender IDs

When a business sends a bulk SMS, it can set an alphanumeric sender ID, the name you see in place of a phone number. That field is chosen by whoever submits the message to an SMS gateway. Mobile networks and regulators can filter or register sender IDs, but end-to-end the SMS system does not cryptographically prove that “MyBank” really is your bank.

The nasty consequence: phones group messages by sender name, so a spoofed alert can land in the same thread as your genuine bank alerts. It looks legitimate precisely because it sits next to real ones. MITRE ATT&CK catalogues this family of behaviour under Impersonation (T1656) and, for links sent by text, Phishing (T1566).

Edited or generated receipts

The second method needs no SMS at all. The fraudster shows a “transfer successful” screen or sends a PDF receipt on WhatsApp. These are edited screenshots, templates copied from real receipts, or output from “fake alert” apps that circulate online. Common tells:

• The amount, name or reference uses a slightly different font or alignment.
• The receipt says “processing” or “pending”, and the customer insists it will “drop soon”.
• The session ID or reference does not match the format on your own genuine receipts.

None of those tells is reliable. A good forgery has none of them. That is why the defence is not “spot the fake”, it is “verify in the app”.

The follow-up call

Sophisticated crews add a second step. After you release goods, someone calls claiming to be from the bank: “a transfer was sent to you by mistake, please return it”. If you send money back from your real balance, you have just paid the fraudster twice.

How POS scams work

POS fraud overlaps with fake alerts but adds the physical card and the terminal. The patterns below are well known to anyone who has worked a fraud desk; the specifics vary by location.

Notice the pattern: every defence moves verification away from the channel the attacker controls (the SMS, the screenshot, the customer’s word) and into a channel the attacker cannot touch (the bank app, the merchant dashboard, the official dispute process).

How defenders and fraud analysts catch it

This is the part that matters for your career. Banks and payment companies employ fraud analysts, SOC analysts and detection engineers to catch exactly these schemes. Here is how the layers fit together.

Layer 1: the merchant’s process

The cheapest control is a rule written on a card at the till: goods leave only after the credit shows in the app or merchant portal. For a business with staff, that becomes a written procedure, a named person who checks, and a log of transactions that failed the check. In NIST terms this sits in the “Protect” and “Detect” functions of the Cybersecurity Framework 2.0: you are reducing the chance of the attack working and creating a record when it is tried.

Layer 2: transaction monitoring at the bank

Money taken by fraud has to go somewhere. Usually it lands in a mule account, an account opened or rented to receive stolen funds, and then moves on fast, split across other accounts or withdrawn. Transaction monitoring systems look for those patterns. Typical rule ideas:

• Rapid pass-through: a credit followed within minutes by debits of nearly the same total.
• Fan-out: one credit split into several outgoing transfers to new beneficiaries.
• New account, high velocity: a recently opened account suddenly receiving many credits from unrelated senders.
• Device and location changes: a login from a new device just before large transfers.
• Complaint clustering: several victims reporting the same beneficiary account.

Real systems combine rules with scoring models and human review, and tune thresholds constantly to keep false positives manageable. You do not need access to a bank to understand the logic, though. You can build a toy version in ten minutes.

Lab: a pass-through rule in Python

Here is a fictional transaction log for a fictional bank. Save it as transactions.csv:

timestamp,account,direction,amount_ngn,counterparty,channel
2026-12-12 19:02:11,ACC-1001,in,450000,ACC-7731,transfer
2026-12-12 19:04:40,ACC-1001,out,200000,ACC-8820,transfer
2026-12-12 19:05:02,ACC-1001,out,240000,ACC-8821,transfer
2026-12-12 19:41:15,ACC-2002,in,35000,ACC-3310,pos
2026-12-12 20:10:09,ACC-2002,out,5000,ACC-4410,transfer
2026-12-13 08:15:30,ACC-1001,in,380000,ACC-7790,transfer
2026-12-13 08:17:12,ACC-1001,out,375000,ACC-8820,transfer

And the rule, mule_rule.py:

import csv
from datetime import datetime, timedelta

WINDOW = timedelta(minutes=15)   # money leaves soon after it arrives
PASS_THROUGH = 0.9               # at least 90% of the credit moves on

rows = list(csv.DictReader(open(“transactions.csv”)))
for r in rows:
    r[“ts”] = datetime.fromisoformat(r[“timestamp”])
    r[“amount_ngn”] = int(r[“amount_ngn”])

for credit in (r for r in rows if r[“direction”] == “in”):
    debits = [r for r in rows
              if r[“account”] == credit[“account”] and r[“direction”] == “out”
              and credit[“ts”] <= r[“ts”] <= credit[“ts”] + WINDOW]
    moved = sum(d[“amount_ngn”] for d in debits)
    if moved >= PASS_THROUGH * credit[“amount_ngn”]:
        print(f"ALERT {credit['account']}: received {credit['amount_ngn']:,} at “
              f”{credit['ts']:%H:%M}, sent out {moved:,} to {len(debits)} account(s) “
              f”within {WINDOW.seconds // 60} min")

Run it:

$ python3 mule_rule.py
ALERT ACC-1001: received 450,000 at 19:02, sent out 440,000 to 2 account(s) within 15 min
ALERT ACC-1001: received 380,000 at 08:15, sent out 375,000 to 1 account(s) within 15 min

ACC-2002 received a POS payment and later spent a small part of it, which is normal behaviour, so it stays quiet. ACC-1001 behaves like a pipe, and it does so twice, which is what an analyst would escalate. Now play with it: change the window to five minutes, add a rule that flags beneficiaries who appear in more than one alert (ACC-8820 shows up twice), and think about which legitimate customers would trip your rule. A salary account that pays rent the same morning? A business that sweeps funds to a savings account? That trade-off between catching fraud and annoying genuine customers is the daily work of a fraud analyst.

Layer 3: the alert channel itself

On the messaging side, defenders work to make spoofed alerts harder to send and easier to spot:

• Sender ID controls with mobile networks, so unregistered senders using a bank’s name are filtered.
• Email authentication (SPF, DKIM and DMARC) so forged email alerts fail checks and land in spam or get rejected.
• In-app notifications that only the bank’s own app can display, which is one reason many banks push customers to rely on the app.
• Customer education that repeats one message: verify in the app, never from the alert.

Layer 4: reporting and case handling

When a merchant reports a fake alert, or a customer reports being defrauded, the report becomes a case. The analyst records the beneficiary account, the time, the amount and any phone numbers used, then checks whether the same details appear in other cases. Reports are how mule accounts get found and frozen, so a report that feels pointless to the victim can be the piece that links ten other cases.

For readers in Nigeria: report to your own bank first, using the number in the app or on the back of your card, not a number from the suspicious message. If a complaint isn’t resolved, the Central Bank of Nigeria has a consumer protection function; check the CBN’s consumer protection pages for the current escalation route. Readers in the UK can find reporting guidance on the NCSC’s phishing and scams pages.

A quick analyst workflow for a suspicious alert

If you were the analyst handed a “was this alert real?” ticket, this is a sensible order of work:

1. Confirm the ledger. Does the credit exist in the core banking record for that account and time? This answers the question in most cases.
2. Identify the source. For an SMS, what sender ID and originating route? For an email, what do the Received, Return-Path and Authentication-Results headers say? (Our post on how to analyse a phishing link safely covers the safe-handling side.)
3. Pull the counterparty. If there was a real transaction involved, such as a refund request, which account is the money meant to go to? Has that account appeared in other reports?
4. Look for the pattern. Same template, same phone number, same beneficiary, same time window across several reports?
5. Act and record. Block or flag what you can within policy, notify the right team, and write up what happened so the next analyst can find it.

That five-step shape (confirm, source, follow the money, pattern, act and record) reappears in almost every fraud and SOC role you will apply for.

Personal safety: the short version

If you only remember four things:

• Verify in the app. Not the SMS, not the screenshot, not the customer’s phone held up to your face.
• Never “refund” money you can’t see in your own balance, and never to a number or account given in the message.
• Call the bank on a number you already have, never one from the alert.
• Protect the PIN at POS terminals, and check the card you get back is yours.

What a beginner can practise from this

You don’t need a job at a bank to build skills on this topic:

• Extend the Python rule above with a fan-out check and a beneficiary watchlist, and write down the false positives you’d expect.
• Collect the headers from a few genuine notification emails you receive and learn to read SPF, DKIM and DMARC results.
• Write a one-page fraud runbook for a fictional shop, “Acme Provisions”, covering how staff verify payments and who they report to.
• Map the scams in the table above to MITRE ATT&CK techniques and note which control breaks each one.

These are small, concrete pieces of work you can describe in an interview, which beats a list of course titles. If account security more broadly interests you, our guide to how account takeovers work is the natural next read, and the same techniques show up again every December, as we cover in festive-season scams.