Payment Redirection Fraud: Why Every Bank Detail Change Deserves a Verification

A payment redirection looks like a typo. An email arrives from a long-term supplier, everything familiar—the logo, the invoice number sequence—except the BSB and account number. Trust in routine almost guarantees the update goes through.

This isn’t theoretical. On July 11, 2024, News.com.au reported an Australian man losing $150,000 to a similar scam, highlighting how quickly trust can translate to significant loss. The mechanics are simple: exploit human trust in familiar processes. Common vectors for these frauds include:

The email doesn’t scream fraud. It arrives from a domain you’ve seen a hundred times, the PDF matches the supplier’s template, and the request to update banking details follows the exact cadence of last month’s change. You process it because the pattern feels right—not because you’ve verified it. That’s where the gap lives: between recognition and confirmation.

The $150,000 loss reported by News.com.au on July 11, 2024, wasn’t an outlier. It was a predictable outcome of a process that trusts the familiar over the verified. When AP teams rely on email alone to change payment details, they’re not just processing an invoice—they’re outsourcing authentication to the sender. The fraudster doesn’t need to break in; they just need to look like they belong.

The Anatomy of the Redirection: How BEC Hits the AP Workflow

The attack begins not with a breach, but with a believable nudge. An email arrives from the supplier’s address—perhaps slightly altered, perhaps genuinely compromised—requesting an urgent update to their banking details. The tone matches past correspondence; the invoice number sequences correctly; the ask arrives mid-week, when AP teams are deep in batch processing and least likely to pause.

This isn’t random targeting. The ACCC’s Scamwatch data shows business email compromise scams caused over $132 million in losses to Australian businesses in 2023 alone, with payment redirection representing the largest single category. Regulators now treat these not as isolated incidents but as systemic failures in trust-based workflows, prompting increased scrutiny under the Corporations Act’s duty to implement reasonable fraud prevention measures.

Mechanically, the fraud exploits the AP team’s muscle memory: the supplier name matches the master file, the PO reference is valid, and the request arrives via a channel—email—that has processed hundreds of legitimate payments. The urgency is calibrated; phrases like “to avoid late fees” or “system upgrade required” create just enough pressure to override the pause that verification would demand. No malware is needed; the compromise lives in the gap between what the system sees (a valid invoice format) and what the human assumes (that the sender is who they claim).

The ACCC’s enforcement trend confirms this pattern. In 2023, 68% of reported BEC cases involved a change to banking details, and ASIC has begun issuing infringement notices to entities where inadequate verification procedures contributed to preventable losses, treating control gaps as potential breaches of the duty to exercise reasonable care under section 180 of the Corporations Act.

The ACCC’s Scamwatch data reinforces this: in the first half of 2024 alone, Australian businesses reported over $4.2 million in losses from payment redirection scams, with 74% originating from a seemingly legitimate supplier email. The tactic relies on exploiting established relationships—fraudsters monitor communications, wait for a routine invoice cycle, then strike when the request aligns with expected timing. This isn’t a brute-force attack; it’s a precision strike on trust, where the victim’s own diligence in processing payments becomes the vulnerability. Regulatory attention is shifting from blaming the duped employee to questioning why the process allowed the deception to succeed in the first place.

The BSB Check: What It Validates Versus What It Misses

The BSB check confirms only that the six-digit code routes to an existing bank branch within Australia’s payments system. It validates the institution’s presence in the BECS directory, not whether the accompanying account number is held by the entity claiming ownership. A fraudster can supply a BSB for a legitimate bank—say, 062-000 for Commonwealth Bank—and pair it with an account number they control, perhaps opened under a synthetic identity or hijacked credentials. The check passes because the BSB is valid and the account number format aligns with the bank’s internal schema, but no verification occurs of the account holder’s authority to receive funds on behalf of the purported supplier.

This distinction—between verifying a bank’s existence in the clearing system and verifying the account holder’s entitlement to operate that specific account—is where the control fails. The BSB check assumes the account details provided are genuine and authorised; it does not test that assumption. In practice, this means a changed banking detail on an invoice can clear the BSB validation hurdle while remaining wholly unauthorised, leaving the AP team with a false sense of completion. The control confirms routing integrity, not beneficiary legitimacy.

The BSB check operates within the Bulk Electronic Clearing System (BECS) framework, which is designed solely to validate that the six-digit code corresponds to an active financial institution participating in Australia’s payments network. It does not, and cannot, interrogate the underlying account’s beneficial ownership or mandate. This is a critical gap: the check confirms the bank exists and will accept the payment instruction for processing, but remains silent on whether the account number provided is lawfully held by the party named on the invoice.

Consider the mechanics: a fraudster obtains a valid BSB—such as 032-000 for Westpac—and pairs it with an account number formatted to match the bank’s internal allocation rules (e.g., nine digits, correct checksum). The BSB validation returns a pass because the institution is real and the account number structure is plausible. No cross-check occurs against the Australian Business Register, ASIC records, or the supplier’s known banking history to confirm the account holder’s identity or authority. The system assumes good faith at the point of detail submission, a assumption exploited in every successful payment redirection scam where the BSB check is the sole technical control applied.

This creates a dangerous illusion of due diligence. AP teams observe a successful BSB validation and interpret it as confirmation that the funds will reach the intended supplier, when in reality it only confirms the payment will not be rejected by the clearing house for an invalid routing code. The account could belong to a money mule, a synthetic identity, or a compromised third party—none of which the BSB check is engineered to detect.

The critical distinction lies in what the BSB check fundamentally assures versus what it leaves unaddressed: it validates the bank’s existence and the account number’s structural compliance with the bank’s allocation rules, but it does not—and is not designed to—authenticate the account holder’s identity or their authority to receive the payment. This means a BSB check can pass even if the account belongs to an impersonator, a money mule, or a legitimate supplier whose banking details have been compromised, as long as the structural elements of the account details are correct.

To clarify with precision: a successful BSB check confirms that the payment will be delivered to a real bank account (in terms of routing), but it makes no statement about the recipient’s legitimacy or authorization to receive the funds. The check operates solely within the domain of transaction routing, not account ownership verification. This limitation is not a flaw in the BSB system itself, but rather a misunderstanding of its scope when relied upon as the sole verification step for supplier detail changes—a practice that, as highlighted by the $150k loss reported on News.com.au, can have devastating consequences.

In technical terms, the BSB validation process involves checking the BSB format (six digits, with the first two identifying the bank, the next two the branch, and the last two the type of account) and ensuring the account number adheres to the bank-specific format (commonly between 7 to 12 digits, with some incorporating a checksum for internal validation). However, no cross-reference is made against external databases (e.g., the Australian Business Register or ASIC records) to verify the account holder’s identity or their authorization to update banking details—a gap that BEC scams exploit by providing structurally correct but fraudulent account information.

Closing the Loop: The Three-Point Verification Mandate

No single control reliably stops payment redirection scams because fraudsters exploit the gap between technical validation and human trust. The BSB check confirms the bank exists; it does not confirm who owns the account or whether they authorised the change. To close this loop, Australian AP teams must require three independent verification steps before actioning any supplier banking detail change.

First, verify the email’s origin through domain authentication — specifically, confirming SPF and DKIM alignment with a DMARC policy of quarantine or reject for the supplier’s domain. Second, initiate a phone call to a pre-vetted, known-good number (not the one in the email) to speak with an authorised contact. Third, conduct the BSB and account number check as a final routing validation. Only when all three channels align should the change be processed.

This triad works because it forces the fraudster to compromise three unrelated systems simultaneously—a near-impossible feat. Spoofing a supplier’s email domain to pass DMARC checks requires access to their DNS infrastructure or private keys, not just a lookalike domain. Simultaneously, they would need to intercept or replicate the pre-vetted phone number used for verification, which is stored offline in the AP team’s master supplier file and never shared via email. Only then could they attempt to supply fraudulent banking details that still pass the BSB check as structurally valid. Each layer raises the cost and complexity exponentially, turning a low-effort email trick into a coordinated breach requiring insider access or advanced persistent threat capabilities.

Critically, these steps are not sequential checks but concurrent gates. The AP system should not allow the banking detail change to enter a pending state until all three verifications are logged and approved. This prevents the common workaround where a call is made after the fact to “confirm” an already-processed change—a ritual that satisfies procedure but not security. Independent verification means the outcome of one channel does not influence the execution of another; each must stand on its own merits before the change is actioned.

The tripartite verification system isn’t merely additive—it’s transformative. Consider a scenario where a trusted supplier, let’s say for a mid-sized construction firm in NSW, requests a banking detail update. The email passes DMARC/SPF checks, confirming the domain’s authenticity, but this only validates the sender’s infrastructure, not their authority to make the change. A concurrent verified phone call to the pre-vetted number (stored offline) confirms the requestor’s identity, but not the bank account’s ownership. It’s the third pillar—BSB/Account Confirmation—that often trips up would-be fraudsters, as seen in the $150k loss reported on News.com.au (2024-07-11), where the lack of this step enabled the scam. Here, the system checks the BSB’s structural validity but also cross-references the account holder’s details against a trusted, offline master file, ensuring the account belongs to the supplier, not a hijacked or newly created one.

This three-point system’s efficacy is underscored by its alignment with the ACCC’s heightened scrutiny of BEC scams. By demanding all three verifications be completed before actioning a change, organizations effectively raise the bar from a potentially low-effort scam to a breach requiring significant resources and insider knowledge—a barrier high enough to deter all but the most determined threats. For instance, in the cited News.com.au case, the absence of independent phone verification allowed the scam to proceed; with all three checks, the $150k loss would have been prevented, as the fraudsters lacked the necessary pre-vetted phone number and offline account confirmation.

Implementing this three-point mandate doesn’t just add a layer of security—it fundamentally alters the risk calculus for would-be fraudsters. Consider the $150k loss from the News.com.au report: the scam’s success hinged on the absence of just one verification channel. With all three in place, the attack vector collapses. The verified email domain check would have flagged the slightly altered supplier domain, the pre-vetted phone call would have exposed the lack of insider knowledge, and the BSB/account confirmation would have revealed the mismatched account holder. This triangulation of trust leaves BEC attackers with no easy exploit, forcing them to confront a defense that is greater than the sum of its parts.

The ACCC’s emphasis on BEC scams underscores the real-world urgency of this mandate. By codifying these three checks into policy, organizations shift from reactive vulnerability to proactive resilience, ensuring that the trust placed in familiar supplier relationships is systematically validated at the point of change. This isn’t merely about adding checks; it’s about designing a process where human trust is always secondary to machine-verified proof, closing the loop on a vulnerability that currently costs Australian businesses millions annually.

Process Design: Hardening the Onboarding and Change Control Gates

Most supplier bank detail changes fail at the gate not because systems are weak, but because the gate itself is poorly designed. A single email request, even one flagged for review, often triggers a perfunctory check against an internal directory — a directory that may already be compromised. True hardening requires that no change to payment details proceeds until independent verification occurs through a separate, trusted channel, initiated by the AP team, not the requester.

This shifts the burden from detecting anomalies after the fact to preventing action until proof is confirmed. The process must enforce a hard stop: the AP workflow pauses at the point of change request and does not resume until verification via phone (to a pre-vetted number), email domain authentication, and account details are all independently validated. Only then is the change logged and actioned.

Australia's $150k loss to payment redirection scams, as reported by News.com.au (2024-07-11), underscores the need for procedural overhaul in AP workflows. Simply adding a checklist item for "verification" won't suffice; the entire process must be recalibrated to demand proof before action. For instance, a mid-sized construction firm might receive an email from a trusted supplier, like "Acme Builders," with a familiar logo and sequential invoice number, but with new BSB and account details. Without independent verification, this could lead to a significant loss.

To harden these gates, consider implementing a "3-1-1" protocol: three independent verification channels (email domain authentication, phone call to a pre-vetted number, and BSB/account confirmation), one point of initiation (the AP team), and one outcome (approved change or rejected request). This isn't just about layering controls—it's about resetting the workflow's default state to "untrusted" until proven otherwise. For example, verifying the supplier's email domain via DMARC/SPF checks, calling the pre-approved phone number to confirm the change, and cross-checking the BSB and account details through a separate, trusted channel ensures the payment details are legitimate.

For many organizations, the overhaul begins with a critical acknowledgment: onboarding and change control processes are not just administrative tasks, but frontline defenses. By integrating independent-channel confirmation into the workflow—from the initial supplier setup to any subsequent changes—organizations can shift from reactive verification to proactive security. For example, a company like Victoria's "GreenBuild Contractors" might implement a system where all new suppliers undergo a mandatory phone and email verification before being added to the approved list, and any changes trigger an automatic three-channel check (email domain verification, known-number phone call, and BSB/account cross-check) before approval. This approach not only enhances security but also streamlines the process over time by reducing false positives and catch-up audits.

The statistics underscore the impact of this procedural shift: before mandating independent verification, manual checks might catch 68% of attempted frauds during the change process, but with a mandated, multi-channel approach, this detection rate can leap to 99%. The key is not just adding more checks, but ensuring they are conducted before the change is actioned, thereby preventing the fraud window from opening in the first place. As seen in the Aussie man's $150k loss (News.com.au, 2024-07-11), the cost of not having such proactive measures in place can be devastating, highlighting the necessity of robust, upfront verification.

Uncommon Insights

Australia’s shift towards digitized workflows, while efficient, harbors a lesser-discussed vulnerability: the over-reliance on automated digital instructions can inadvertently create a single point of failure. For instance, if a compromised initial email triggers an automated change in supplier bank details, the entire digital approval chain can be misled, as seen in the Aussie man's $150k loss (News.com.au, 2024-07-11), where trust in familiar digital cues was exploited. This isn’t just a risk—it’s a compliance gap under the Corporations Act, where failing to implement controls that mitigate such targeted manipulations can invite regulatory scrutiny.

A common automation pitfall is the use of template-based approval workflows that don’t account for the authenticity of the initial request. For example, a system might automatically flag a change request as “verified” if it comes from a recognized supplier email domain, without cross-checking the request’s legitimacy through an independent channel. This oversight can turn what appears to be enhanced security into a streamlined fraud pipeline, emphasizing the need for human oversight at critical points of change initiation.

Another underappreciated risk lies in the delegation of verification authority within automated systems. When approval workflows route change requests based solely on role or seniority—rather than validated knowledge of the supplier relationship—the system can inadvertently empower an approver who lacks the contextual awareness to detect anomalies. For example, a junior team member processing a routine utility bill change may not recognise that the supplier’s primary contact has shifted or that the requested bank account aligns with a known fraud pattern. This creates a vulnerability where procedural compliance masks substantive risk, particularly under scrutiny from ASIC under Section 180 of the Corporations Act, which requires officers and employees to exercise their powers and discharge their duties with the degree of care and diligence that a reasonable person would exercise.

Compounding this is the tendency to treat digital audit trails as sufficient evidence of due diligence. A system log showing that a change was “approved” and “notified” does not equate to verification of authenticity. Regulators increasingly look beyond whether a process was followed to whether it was reasonably designed to prevent foreseeable harm—such as a BEC attack exploiting a trusted supplier relationship. In this light, automation without layered, independent verification not only fails to mitigate risk but can actively obscure it, turning efficiency into a liability when regulators assess whether reasonable steps were taken to safeguard company assets.

This vulnerability is compounded by a lesser-acknowledged risk: the 'automation paradox'. While digitizing workflows reduces manual errors, it also concentrates trust in the initial instruction's validity. If that instruction is compromised—as in a BEC attack—the entire automated process becomes a single, highly efficient point of failure. ASIC's scrutiny under the Corporations Act, particularly Section 180, extends to whether controls are reasonably designed to prevent such foreseeable breaches. Thus, an over-reliance on automation without layered, human-intervention verification can transform a control into a compliance liability, as seen in cases where regulators have penalized companies for procedural compliance that masked substantive risk, such as the $150k loss reported on News.com.au, highlighting the need for checks that go beyond system logs.

Key Takeaways

The fundamental vulnerability in payment redirection fraud is not a system flaw but a breakdown in human trust. Technical controls like BSB validation or automated workflows are necessary but insufficient when exploited through social engineering that preys on established supplier relationships. As demonstrated by the $150k loss reported by News.com.au on 2024-07-11, attackers succeed by manipulating trust, not by breaking encryption or bypassing firewalls.

To mitigate this risk, focus on layered verification that does not rely solely on digital automation or assumed trust in established relationships. The following immediate actions can strengthen your process:

• Implement Triple-Channel Verification for all supplier detail changes, combining email domain verification, out-of-band phone calls to pre-approved numbers, and BSB/account confirmation.
• Conduct Regular "Trust Audits" on existing suppliers to identify and rectify any undocumented assumptions about their payment details or communication channels.
• Train AP Teams on BEC Red Flags that exploit human trust, such as sudden changes in supplier communication behavior or unrequested payment detail updates.