Scams: warning signs and protecting information
AFCA publishes consumer guidance on scam warning signs and protecting personal information.
AFCA scam guidanceAn attacker inside the client's genuine mailbox can send a real form, continue a familiar thread and pass email-authenticity checks. Verify the instruction outside the channel that carried it.
Advice practices are trained to inspect sender domains, odd addresses and poor formatting. Those signals help with imitation emails. They do not solve a compromised mailbox.
Here, the attacker signs in as the client. The message comes through the client's normal provider and can sit inside years of genuine correspondence. The criminal may know the portfolio, adviser, family circumstances and expected process because the mailbox contains all of them.
The correct question is therefore not “is this email authentic?” The email may be technically authentic. The question is “did the client authorise this instruction?”
The load-bearing distinction
Email authentication proves which infrastructure sent a message. It does not prove which human controlled the authorised mailbox.
This composite timeline describes a recurring pattern, not a named client or determination.
Day -14
The attacker gains access to the client's real email account through stolen credentials, session theft or another compromise.
Why it matters: Nothing has reached the adviser yet. The criminal can quietly read old conversations, signatures, holdings and the firm's normal tone.
Day -7
Past threads reveal who handles withdrawals, which forms are used, what questions staff ask and when the client is unavailable.
Why it matters: The genuine mailbox is reconnaissance. Accurate answers later are evidence of access, not identity.
Day -1
A real form is copied or completed, a plausible signature is added and destination bank details controlled by the attacker are inserted.
Why it matters: Document consistency can show that the attacker studied the file. It cannot show that the client authorised this version.
Day 0 · 9:12
The withdrawal arrives from the client's actual mailbox, often inside an existing thread. The attacker can delete sent messages and hide adviser replies.
Why it matters: SPF, DKIM and DMARC can all pass because the authorised mail service sent the message. This is account compromise, not domain spoofing.
Day 0 · 10:05
The attacker answers follow-up email quickly or calls with facts from the thread, explaining urgency and any changed account.
Why it matters: Staying in the compromised channel lets the same attacker manufacture both the request and its confirmation.
Day 0 · before payment
Staff stop, use the contact already held in a separate client record and run an out-of-band check before processing.
Why it matters: The instruction is not rejected because it looks fake. It is paused because the consequence requires independent proof.
SPF helps receiving systems check whether a server is permitted to send for a domain. DKIM applies a cryptographic signature so the receiver can check that signed content was not altered in transit. DMARC tells receivers how to evaluate and handle alignment failures.
Those controls are valuable against domain spoofing and message tampering. In this pattern, there may be no alignment failure. The attacker uses the client's authorised account and provider, so the same technical checks that protect genuine mail can pass on the fraudulent instruction.
Header review, login alerts and mailbox-security investigation remain useful incident tools. They are not a substitute for an out-of-band authorisation check before funds leave.
Treat every withdrawal, rollover, changed destination and unusual urgency as requiring a fresh verification, even when the email and form look genuine.
Use the phone number already held in the firm's CRM or client record. Do not use a number in the email, attached form or signature block under review.
Initiate a one-time Vericode code by SMS to that phone number and require the client to read it back during the live interaction.
After the contact check and any identity checks, separately confirm the amount, reason, destination, account-name evidence and authority under the firm's approval rules.
If the check fails, reveal no further facts. Preserve the email, form, headers, phone details and notes; contact the genuine client and escalate.
Rely on the authorised-contact record for the verification result itself, then retain the instruction version, destination checks, approver and any exception in the client file and incident register.
Vericode lets staff highlight a client phone number visible in a browser-based CRM, platform or email client, right-click and send a one-time SMS code. The client reads it back on the call.
The control is CRM-agnostic and is not a direct integration with a named advice platform. Verification messages are sent through Australian SMS provider MobileMessage, using Vericode's ACMA-registered sender ID, VERICODE. A fully compromised phone can still defeat possession-based verification, so firms should retain dual approval and account-destination checks.
Each authorised-contact check creates a timestamped, hash-chained record of the requester, masked target, method and outcome. Compliance-authorised users can export the record as PDF or CSV.
The record supports evidence that the firm followed its procedure. It does not guarantee a best-interests, efficiency, AFCA, insurance or compliance outcome and does not satisfy an AFSL condition by itself.
AFCA publishes consumer guidance on scam warning signs and protecting personal information.
AFCA scam guidanceAFCA's factsheet covers receiving banks and accounts opened without authorisation in the scam-payment chain.
AFCA receiving-banks factsheet