Spotting Payment Redirection Scams: Advanced Controls for Australian Treasury Teams

The supplier portal looks identical. The login page, the dashboard, the invoice history — all perfect. Only the "Update Payment Details" button now points to a server in Eastern Europe, not your vendor's finance team.

Ten years ago, payment fraud was a badly spelled email from a prince. Today it's a credentialed session inside your approved supplier network, using a compromised finance officer's MFA token to request a banking change that passes every automated check. The invoice is real. The relationship is real. Only the destination account isn't.

The scam doesn't arrive in spam. It arrives in your approved supplier portal, sent from a compromised finance officer's authenticated session. The MFA token checks out. The IP address matches the vendor's known range. The invoice history, the purchase order references, the payment terms — all legitimate. Only the new BSB and account number belong to a mule account in Eastern Europe, set up three days ago.

This is account takeover fraud, not phishing. The attacker doesn't need to trick your AP team; they've already tricked your supplier's finance team. By the time the request hits your inbox, it carries every marker of authenticity: correct sender, valid credentials, established relationship, proper formatting. Your automated controls — three-way matching, PO validation, duplicate detection — all pass. The fraud lives entirely in the one field nobody verifies by phone: the destination account.

The Anatomy of a Redirection Scam

The scam doesn't start with the invoice. It starts weeks earlier when the attacker gains access to your supplier's finance mailbox — phishing a junior clerk, reusing credentials from a unrelated breach, or exploiting an unpatched VPN. They don't rush. They read. They learn the cadence: which clients pay on the 15th, which require PO numbers, who approves changes over $50,000. By the time the request arrives, it's not an attack. It's a routine admin update from a known contact at a verified domain.

The mechanism relies on three failures in your process. First, the request for change arrives through the same channel it seeks to alter — email to email — creating a closed loop with no independent verification. Second, urgency is manufactured: "We need this updated before Friday's pay run" or "Our bank is migrating platforms this weekend." Third, your standard checks — three-way matching, PO validation, duplicate detection — all pass because the invoice itself is genuine. Only the BSB and account number have changed. Your controls verify the invoice; they don't verify the destination.

The most dangerous variant doesn't impersonate the supplier at all. It compromises the supplier's actual email account and sends the change request from the legitimate address, with the correct signature block, referencing real invoice numbers from last month's statement. Your SPF, DKIM, and DMARC checks all pass because the message genuinely came from their domain. The only anomaly is the new BSB — and no control in your AP workflow flags a banking detail change as a high-risk event unless someone manually notices it.

Contrast this with a standard invoice query: a supplier emails "Invoice INV-4022 appears unpaid" and your team checks the ledger, finds the payment sent, and replies with the remittance advice. Low risk, routine, resolved in minutes. A banking detail change is structurally different — it redirects every future payment until caught. Yet most ERPs treat both as "supplier correspondence" with identical workflows. The request sits in a shared inbox, a clerk updates the vendor master file, and the next pay run sends $200,000 to a mule account in Western Sydney. The fraud isn't discovered until the real supplier calls 45 days later asking why they haven't been paid.

The scam succeeds because it weaponises your own process discipline. A clerk sees "urgent" in the subject line, matches the ABN to the vendor master file, and updates the record — exactly as the SOP instructs. The ERP logs the change with a timestamp and user ID, creating a perfect audit trail of the fraud's execution. No alarm fires because the system records a valid action by an authorised user on a verified supplier record. The control gap isn't technical; it's categorical. Your workflow treats a banking detail change as a data entry task when it is, in substance, a new onboarding event.

Portal mimicry compounds the problem. Attackers now replicate supplier self-service portals — down to the SSL certificate and the "forgot password" flow — then email a link claiming "we've upgraded our payment portal, please verify your details." The AP team clicks, logs in, and unwittingly authorises the redirect. The legitimate supplier never sees the request. By the time the real portal shows the unauthorised change, the pay run has cleared. The only reliable signal is the request itself: any unsolicited change to settlement instructions, regardless of channel or apparent authenticity, must be treated as hostile until independently verified.

Mandatory Verification: Beyond the Email Signature

An email signature proves nothing. A compromised mailbox sends perfectly signed messages from the real CFO's account, complete with the correct disclaimer block and the right internal threading. The only verification that survives account takeover is a live, out-of-band confirmation — phone the supplier on the number you held before the change request arrived, or open a video call with a known contact. If your SOP accepts a reply email as proof, the SOP is the vulnerability.

Email-only workflows create a single point of failure: the inbox. Once an attacker controls that inbox, every "approval" they generate looks legitimate to your system. A 2022 ASIC enforcement action against a mid-tier logistics operator (ASIC 22-187MR) cited the absence of independent verbal verification as a contributing factor in a $1.4M redirection loss — the CFO had "approved" the change via compromised email, and no second channel existed to catch it.

The "Four Eyes" principle isn't a courtesy — it's a control gate. Any banking detail change requires simultaneous sign-off from both Procurement, who owns the commercial relationship and knows the supplier's operational rhythm, and Treasury, who owns the settlement risk and controls the payment rails. One function initiates, the other authorises; neither can execute alone. This dual control survives individual compromise because an attacker would need to breach two separate business units with different reporting lines, approval matrices, and system access.

Build the workflow so the system enforces it: the ERP should reject any vendor bank update that lacks both digital signatures, timestamped within a four-hour window, with the Procurement approver confirming the commercial rationale (contract variation, entity restructure) and the Treasury approver confirming the account passes sanction screening and ownership verification. No exceptions for "urgent" requests — urgency is the attacker's lever. If a supplier genuinely needs same-day settlement, they call their relationship manager, who triggers the escalation matrix with pre-authorised emergency contacts verified at onboarding.

Document every verification attempt, successful or failed. The audit trail must capture who called whom, at what number, at what time, and what specific details were confirmed — account name, BSB, account number, entity ABN. Store the recording or written attestation against the vendor master record in the ERP, not in a separate email folder that disappears when someone leaves. ASIC's guidance on internal controls under s 198D of the Corporations Act expects directors to ensure financial records are maintained in a way that enables true and fair financial statements; a missing verification log for a $2.3M misdirected payment is a control deficiency the auditor will flag, and the regulator will trace back to governance.

Test the control quarterly with a red-team exercise: have an authorised tester attempt a bank detail change using a spoofed domain and a plausible urgency narrative. Measure how many layers catch it — the phone callback, the Four Eyes gate, the ERP rejection, the escalation matrix trigger. If the test payment reaches the payment file, the process has failed. Report the result to the Audit Committee with the same rigour as a penetration test on the firewall. The control is only real when it survives a deliberate attempt to bypass it.

Governing the Flow: Legal and Procedural Guardrails

Directors who treat payment controls as an IT project rather than a governance obligation expose themselves to personal liability under s 180(1) of the Corporations Act — the duty to exercise care and diligence. When a fraudulent bank detail change results in a material misstatement of the financial position, the question isn't whether the AP clerk followed the checklist. It's whether the board ensured the system was designed to prevent the loss in the first place. ASIC's enforcement actions against officers for internal control failures (see ASIC v Cassimatis [2020] FCAFC 52) make clear that reliance on subordinate compliance without independent verification of the control environment is not a defence.

The Australian Payments Network's Payment System Rules require participants to implement fraud detection and prevention measures commensurate with transaction risk profiles. Mapping your bank detail change workflow against these rules — specifically the obligation to verify payee identity and authorise payment instructions — turns a procedural document into a regulatory shield. If your process cannot demonstrate that a $2.3M redirection was blocked because the Four Eyes gate caught a mismatch between the requestor's domain and the supplier's ASIC-registered address, the control exists only on paper.

Directors who treat payment controls as an operational detail rather than a governance obligation expose themselves to personal liability under section 180(1) of the Corporations Act — the duty to exercise care and diligence. When a fraudulent bank detail change results in a material misstatement of the financial position, the question isn't whether the AP clerk followed the checklist. It's whether the board ensured the system was designed to prevent the loss in the first place. ASIC's enforcement actions against officers for internal control failures (see ASIC v Cassimatis [2020] FCAFC 52) make clear that reliance on subordinate compliance without independent verification of the control environment is not a defence.

The Australian Payments Network's Payment System Rules require participants to implement fraud detection and prevention measures commensurate with transaction risk profiles. Mapping your bank detail change workflow against these rules — specifically the obligation to verify payee identity and authorise payment instructions — turns a procedural document into a regulatory shield. If your process cannot demonstrate that a $2.3M redirection was blocked because the Four Eyes gate caught a mismatch between the requestor's domain and the supplier's ASIC-registered address, the control exists only on paper.

The Corporations Act doesn't prescribe a specific payment fraud checklist. It imposes a duty of care and diligence under section 180(1) that courts interpret through the lens of what a reasonable director would ensure exists — not what a reasonable clerk remembers to do. In ASIC v Cassimatis [2020] FCAFC 52, the Full Federal Court held that officers cannot delegate their obligation to verify that control systems actually function. A board that approves a "supplier verification policy" but never tests whether the Four Eyes gate triggers on a live $2.3M bank detail change has not discharged that duty.

The Australian Payments Network's Payment System Rules require participants to implement fraud detection and prevention measures commensurate with transaction risk profiles. Mapping your bank detail change workflow against these rules — specifically the obligation to verify payee identity and authorise payment instructions — turns a procedural document into a regulatory shield. If your process cannot demonstrate that a redirection was blocked because the Four Eyes gate caught a mismatch between the requestor's domain and the supplier's ASIC-registered address, the control exists only on paper.

Uncommon Insights

Most organisations treat a bank detail change as a standalone event — verify the request, update the record, move on. That misses the signal sitting in your own ERP. A legitimate supplier's payment history carries a fingerprint: consistent invoice cadence, stable remittance advice formats, predictable rounding patterns. When a change request arrives claiming to be from that supplier but the email metadata, domain registration date, or signatory name don't align with the onboarding dossier you built three years ago, the discrepancy is the control.

Cross-referencing the requestor against ASIC's register of companies and registered office addresses is a check that takes ninety seconds and costs nothing. If the email comes from "[email protected]" but the supplier's ASIC record shows a registered office in a different state with a different authorised officer, the Four Eyes gate should hold automatically. This isn't forensic analysis — it's baseline hygiene that turns a reactive verification into a proactive integrity test before a single dollar moves.

ABN Lookup and the ASIC Connect API let you script this check into the workflow rather than leaving it to a busy AP clerk. When a change request hits your inbox, an automated lookup can confirm the ABN matches the legal entity on the purchase order, flag if the registered address has shifted in the last six months, or surface a recent external administration appointment that the supplier hasn't disclosed. The same data feed can cross-reference director names against the disqualified persons register — a control that catches phoenix operators before they re-enter your supply chain under a new entity.

Layer in bank account verification through the New Payments Platform's PayID directory or BSB validation services, and you close the loop: the account name returned by the bank must match the legal entity on the ASIC record, which must match the supplier master record in your ERP. A mismatch on any one of those three points stops the payment without human judgment calls. This isn't future-state architecture — the APIs exist today, and the integration cost is a fraction of a single fraud loss.

Supplier portals add another verification layer when configured correctly. A mandatory portal-based change request — where the supplier logs in with MFA, uploads a signed authority on company letterhead, and the system auto-validates the ABN against ASIC — removes the email vector entirely. The portal can enforce a 48-hour cooling-off period before the new details go live, during which the old account remains active and any payment attempt to the new BSB triggers a dual-approval workflow. Scammers rarely have the patience or access to clear that hurdle.

Historical transaction data provides its own fraud signal. If a supplier's average invoice is $12,000 and a sudden $85,000 payment request arrives alongside a banking change, the deviation should auto-escalate regardless of how legitimate the request appears. Machine learning models trained on your own AP history can flag these outliers in milliseconds — not to replace human review, but to prioritise which change requests get the four-eyes treatment today versus next week. The goal isn't perfect detection; it's making the fraudster's effort exceed the payoff.

ASIC's register isn't just for onboarding. A monthly batch check against the Companies and Business Names registers catches director changes, registered office shifts, and external administration appointments that suppliers rarely volunteer — but that fundamentally alter who controls the bank account. A supplier entering voluntary administration on Tuesday shouldn't have their banking details changed on Wednesday without the liquidator's written authority. The Corporations Act s 440D stays enforcement against the company, but it doesn't authorise new payment instructions.

ABR and ASIC API integrations cost pennies per query and can run overnight. Flag any change request where the ABN status has shifted, the principal place of business no longer matches the invoice address, or a new director appears who wasn't on the original onboarding pack. Cross-reference with the PPSR — a fresh security interest registered against the supplier's assets the week before a banking change request is a signal worth a phone call. Most fraud leaves footprints in public records weeks before it hits your inbox.

Key Takeaways

An emergency escalation matrix isn't a flowchart — it's a phone tree that works at 6pm on a Friday when the CFO is unreachable and a $450,000 payment to a "new" supplier account is sitting in the batch. Designate three authorised approvers across Procurement, Treasury, and Legal with standing authority to freeze outbound payments without waiting for email chains. Each holds a physical token or app-based override that bypasses standard AP workflows. Test it quarterly with a live drill: inject a fake banking change request and measure time-to-halt. If it exceeds 15 minutes, the matrix fails.

Training that stops at email phishing misses the channel fraudsters now prefer. Voice cloning tools let attackers mimic a known finance contact on a Teams call; SMS spoofing makes a "quick verification" text appear from the supplier's saved number. Run quarterly simulations across phone, IM, and video — not just email — scoring staff on whether they escalate or comply. The only passing grade is a refused transaction and a raised ticket. Anything else is a control gap waiting to be exploited.

• Escalation matrix tested quarterly — three authorised approvers across Procurement, Treasury, and Legal with standing authority to freeze outbound payments within 15 minutes, no email chains required.
• Multi-channel simulations mandatory — quarterly drills across phone, Teams, SMS, and IM using voice-cloning and spoofing scenarios; passing grade is a refused transaction and a raised ticket.
• Four-eyes sign-off on every banking change — Procurement and Treasury must both approve any supplier account update, verified by live verbal or video confirmation with a known contact.
• Physical or app-based override tokens — each approver holds a dedicated authentication method that bypasses standard AP workflows when the matrix is triggered.
• Public-record cross-check before payment — ASIC and ABR data integrated into the change-request workflow to verify the requesting entity's legitimacy before authorisation.