Case Library / Phishing / NZ Bank-Impersonation Caller-ID Spoofing Scam: $30,000 Banking Ombudsman Case
PhishingVishing (Voice Phishing) Documented incident

NZ Bank-Impersonation Caller-ID Spoofing Scam: $30,000 Banking Ombudsman Case

A scammer spoofed a New Zealand bank's number and obtained authentication codes by claiming they would suspend banking and cancel payments. A NZD 30,000 unauthorized credit-card transaction followed; a later safe-account request raised the customer's suspicions. The Ombudsman recommended reimbursement, without documenting that it was paid.

Share:

Social Engineering Examples·4 sources

What happened

A New Zealand bank customer received a phone call from a man claiming to work for her bank's fraud team, who said he had identified unusual transactions on her account. The call displayed a caller ID matching the bank's genuine, published phone number; the number had been spoofed. He told her she would receive codes to suspend her internet banking and cancel the suspicious payments, and instructed her to read the codes back to him; she complied because the number appeared legitimate. She grew suspicious only when he then said she needed to move her money to a "safe account," at which point she hung up and called the bank directly, learning it had been a scam. By then the scammer had already executed a $30,000 transaction on her credit card account (used to purchase goods at an Auckland merchant, picked up roughly 15 minutes before the customer called the merchant) and had attempted a second, large payment that the bank's fraud-detection system blocked. The bank initially refused full reimbursement, arguing she had breached its terms of service by sharing the codes, and offered only half the loss. The Banking Ombudsman Scheme (case note 87834, published December 2024) found she had acted reasonably and recommended full reimbursement plus compensation for handling delays. RNZ reported the decision on 12 January 2025.

How it worked

The scammer called the bank customer using a spoofed caller ID that displayed the bank's genuine published phone number, so it matched the number on the bank's own website when she checked it. He claimed to be a bank fraud-team staff member who had spotted unusual transactions, and said he would suspend her internet banking and cancel the suspicious payments, actions for which she would receive verification codes that she needed to read back to him. The codes were, in reality, one-time authorization/2FA codes; reading them out let the scammer approve fraudulent actions on her account. He "skilfully mimicked" genuine bank call-centre procedure throughout. She only became suspicious when he then told her she needed to move her money into a "safe account" (a safe-account scam warning sign), at which point she hung up and called the bank directly, discovering the fraud. By then the scammer had already used the credit card account to make a $30,000 purchase at an Auckland merchant and had attempted a second, large payment that the bank's automated fraud detection blocked.

The lure and the tell

The lure: a call that displayed the bank's real, publicly listed phone number (via caller-ID spoofing), combined with a script that closely mirrored genuine bank fraud-team language: flagging "unusual transactions" and framing the codes as necessary to suspend banking and cancel payments, which was "sufficiently close to their true purpose to trick a reasonable person" per the Ombudsman. The tell: the pivot to asking her to move money into a "safe account," a request no legitimate bank fraud team makes, which triggered her suspicion and prompted her to hang up and call the bank independently.

Outcome

The scammer completed a $30,000 unauthorized transaction on the victim's credit card account (used to buy goods at an Auckland merchant, collected roughly 15 minutes before she called the merchant) and attempted a second, large payment that the bank's security system blocked. The victim reported the fraud immediately, but the merchant would not return funds since the goods were already released. The bank initially denied full reimbursement, citing a terms-of-service clause against sharing verification codes, and offered only 50% ($15,000). The customer escalated to the Banking Ombudsman Scheme (case note 87834, published December 2024), which found she had acted reasonably: noting the number was convincingly spoofed, the scam script closely mimicked real bank procedure, the bank's own SMS codes carried no anti-sharing warning, and the bank itself had separately asked her husband to read out a 2FA code, undermining its own rule. The Ombudsman also faulted the bank's fraud-response handling. It recommended reimbursement of NZD 30,000 along with NZD 1,000 already offered for delays. The case note does not say these amounts were paid. Banking Ombudsman Nicola Sladden described it as a sophisticated bank impersonation case and noted bank-impersonation scams made up almost a quarter of all fraud/scam cases the Scheme received that financial year. RNZ reported the recommendation on January 12, 2025.

Why it matters

The Ombudsman found that this customer acted reasonably in the circumstances, including the convincingly spoofed caller ID, the code messages' lack of warnings, and the bank's own practice of asking her husband to read a code aloud. This is a case-specific reimbursement recommendation, not a court ruling or a universal promise of compensation.

Current Ombudsman guidance distinguishes unauthorized payments from payments made with a customer's knowledge and consent. Additional Code commitments for eligible authorized payments began on November 30, 2025; they do not by themselves invalidate this earlier unauthorized-payment analysis. Callback/TOAD terminology in the existing taxonomy remains subject to review: the malicious call was incoming, while the customer's later genuine callback exposed the fraud.

Defenses

Defensive lessons from the Ombudsman's recommendation include: (1) SMS/OTP messages that explicitly warn customers never to share the code, since the bank's messages carried no such warning; (2) consistency in bank practice, since staff themselves had asked the customer's husband to read out a 2FA code during account setup, undermining the "never share codes" T&C the bank tried to enforce against the victim; (3) faster, more coordinated fraud-report handling, since the Ombudsman found the bank's own delays may have let the loss happen; (4) broader telecom/bank work (flagged in CERT NZ's Q2 2022 report) to block caller-ID spoofing of bank numbers. For consumers, the case underscores that a matching caller ID is not proof of authenticity when numbers can be spoofed, and that a legitimate-sounding request to read out a "cancellation" or "suspension" code is functionally identical to handing over the code that authorizes a fraudulent transaction.

Sources
  • Assessing scam complaints. Banking Ombudsman Scheme (primary), updated February 2026. Distinguishes unauthorized payments from the commitments for eligible authorized payments made on or after November 30, 2025.
  • Customer acted reasonably despite sharing codes with scammer (Case note 87834). Banking Ombudsman Scheme (New Zealand) (primary). Official published case note detailing the facts, the bank's position, the Ombudsman's investigation and reasoning, and the reimbursement outcome. The outcome is a recommendation, not confirmation that reimbursement was paid.
  • CERT NZ Q2 2022 Cyber Security Insights report. CERT NZ / National Cyber Security Centre (NCSC) (primary). Government report documenting the broader NZ scam pattern of bank-impersonation phone-number spoofing and scammers asking victims to read out SMS verification codes; provides background context, not specific to this individual case. Historical background citation; unavailable through Exa in this run, not confirmed dead.
  • Bank told to reimburse $30,000 after scammer impersonates staff. RNZ (Radio New Zealand) (secondary). News report summarizing the Ombudsman case, including direct quotes from Banking Ombudsman Nicola Sladden and the statistic that bank-impersonation cases made up nearly a quarter of the Scheme's fraud/scam caseload that financial year. Published January 12, 2025; the characterization attributed to Sladden is indirect speech.
Cite this case

Social Engineering Examples. “NZ Bank-Impersonation Caller-ID Spoofing Scam: $30,000 Banking Ombudsman Case”. Accessed 3 November 2026. https://socialengineeringexamples.com/nz-bank-impersonation-spoofed-callback-vishing-2024

Attack Chain & Defense
1Reconnaissance
What happened

The scammer likely obtained the victim's phone number and confirmed which bank she used before calling, consistent with the target selection typical of telephone-oriented attack delivery (TOAD) campaigns; the published sources do not confirm the specific method used in this case.

The control that would have stopped it

Consumer-side exposure of phone numbers and banking relationships is very hard to close at a population scale given data broker records, prior breaches, and social media; the realistic control assumes attackers can already identify a real customer of a given bank and focuses defenses on the later stages of the call itself.

2Caller ID spoofing setup
What happened

The scammer used caller ID spoofing (documented by CERT NZ as a recurring pattern in New Zealand bank-impersonation scams, sometimes via commercial phone-spoofing services) to display the bank's genuine, publicly listed phone number on the victim's phone when he called.

The control that would have stopped it

Telecom-and-bank collaboration to authenticate or block spoofed calls impersonating registered bank numbers, the approach CERT NZ and New Zealand banks pursued with the Telecommunications Forum, directly targets this stage, though scammers can adapt by using closely-imitating numbers instead of exact spoofs.

3Pretext call and authority establishment
What happened

The scammer called posing as bank fraud-team staff, claimed to have identified unusual transactions on the account, and used a script and manner the Banking Ombudsman found had "skilfully mimicked" genuine bank call-centre procedure.

The control that would have stopped it

Customer education and in-app or statement messaging stating plainly that the bank will never call and ask a customer to read out a verification code reduces the odds a scripted "fraud team" call is believed, regardless of what the caller ID shows.

4Real-time OTP relay to defeat two-factor authentication
What happened

While the victim was on the line, the scammer triggered genuine bank-generated one-time SMS codes tied to real account actions, described them as "cancellation" or "suspension" codes, and had the victim read them back to him, using her as an unwitting relay to authorize actions that actually benefited him.

The control that would have stopped it

This is the highest-leverage control point. SMS/OTP messages should explicitly warn "do not share this code with anyone, including bank staff" (a warning the Ombudsman found missing here), and banks should never have their own staff ask customers to read codes aloud, since that practice is exactly what made the scammer's request sound normal to the victim.

5Unauthorized transaction execution
What happened

Using the relayed codes, the scammer authorized a $30,000 purchase on the victim's credit card account at an Auckland merchant and attempted a second, large payment that the bank's automated fraud-detection system blocked.

The control that would have stopped it

The bank's security system blocked the second large payment attempt; the source does not identify the particular rule or verification control. Transaction monitoring and independent verification are possible defenses, not confirmed details of that block.

6Escalation to a fake "safe account" transfer
What happened

The scammer pivoted to instructing the victim to move her remaining funds into a supposed "safe account," the classic follow-on stage of safe-account social engineering scams intended to capture additional funds beyond the initial unauthorized transaction.

The control that would have stopped it

Front-line staff and automated fraud rules should treat any instruction to move funds into a new "safe account" as a near-certain scam indicator, since no legitimate bank fraud process asks a customer to transfer money to a separate account for safekeeping.

7Cash-out via rapid goods pickup
What happened

The scammer collected the goods from the Auckland merchant. They had been picked up about 15 minutes before the customer contacted the merchant, after a lengthy call with her bank; the source does not say pickup occurred within 15 minutes of purchase.

The control that would have stopped it

Faster bank-to-merchant fraud alerts immediately after a report, and merchant or card-network holds on high-value purchases pending fraud confirmation, could narrow the window between purchase and pickup; in this case the bank's contact to the merchant came after the goods had been released; the reported 15 minutes measures time before the customer's merchant call, not the duration of a recovery window.

Quick Facts
Victim
A customer of an unnamed New Zealand retail bank; her husband is also referenced
Location
New Zealand
(purchase made via an Auckland-based merchant); Banking Ombudsman Scheme is a national NZ dispute-resolution body
Date
Incident date not established in retrieved sources
; Ombudsman case note published December 2024, RNZ report January 12, 2025
Impact
NZD 30,000 unauthorized credit-card transaction used to buy goods from an Auckland merchant.
BasismeasuredOmbudsman case-note amount: NZD 30,000 loss; NZD 15,000 initial offer; NZD 30,000 recommended reimbursement and NZD 1,000 offered for delays. Offers and recommendations are not confirmed recovery. NZD is inferred from the domestic New Zealand case; the incident sources print dollar signs without an explicit currency code, and no conversion was performed.
A second large payment was blocked; its amount and comparison with NZD 30,000 are not given. The bank offered NZD 15,000, half the loss. The Ombudsman recommended reimbursement of NZD 30,000 along with NZD 1,000 already offered for handling delays. The sources do not confirm payment of the reimbursement or compensation.
Status
Documented incident
Case Type
Real-World Incident
Sector
Financial Services & Insurance
Threat Actor
unknown
Explore more

Related Cases

Browse by what this case has in common with others in the library.