Verifying Payments in the AI Era: Advanced Controls Against Supplier Bank Detail Changes

An email arrives from your long-standing IT vendor, requesting an urgent update to their payroll account. The sender address matches their domain. The invoice references a recent project. Only the BSB and account number have changed.

This isn't a typo. It's a context-aware deepfake scam, where AI analyses years of correspondence to mimic tone, timing, and transaction patterns — turning payment fraud into a precision strike.

It crafts the request using language lifted from past emails, references genuine project codes, and times the ask to coincide with known payment cycles. The fraud isn’t in the forgery of a document but in the manipulation of trust — exploiting the very rhythm of legitimate business to bypass controls designed for cruder fakes. This evolution means traditional red flags — poor grammar, mismatched logos — are increasingly absent, leaving finance teams facing threats that are indistinguishable from routine requests until funds are diverted.

The tangible risk is no longer theoretical loss but immediate, irreversible cash outflow. Once funds leave an Australian account and are layered through offshore structures — a common tactic observed in ASIC investigations — recovery prospects diminish rapidly, often to near zero. The sophistication of these attacks shifts the burden from detecting anomalies to proactively validating every payment instruction change, regardless of how authentic it appears.

Beyond the Phone Call: Hardening Payment Instruction Change Protocols

A verbal confirmation over the phone is no longer sufficient. Attackers now use deepfake audio to mimic a supplier’s finance controller, making a simple call-back a vector for fraud rather than a control. The moment you rely on a single channel — especially one the attacker can spoof or intercept — you inherit their risk profile.

Effective hardening requires mandatory out-of-band verification: a confirmation method that travels completely outside the original communication path. This means initiating contact through a pre-registered, independently verified channel — such as a secure video call within your organisation’s approved portal, or a time-limited MFA challenge sent to a known device on file — never using details provided in the change request itself. The ‘why’ is straightforward: if the attacker controls the email, they likely control the phone number in the signature. Your verification must be blind to their manipulation.

One robust implementation involves binding the verification to the supplier’s master record in your ERP. Before accepting new banking details, the system triggers a dual-approval workflow: one finance officer initiates a video call via the organisation’s authenticated portal to a pre-registered contact, while a second, independent officer validates the change against historical payment patterns and tax file number matches. This creates an immutable audit trail — timestamped, geolocated, and linked to user IDs — that cannot be repudiated.

Consider a scenario where a construction firm’s supplier emails updated account details. The AP clerk follows protocol: instead of replying to the email or calling the number in the signature, they log into the supplier portal, initiate a verified video session with the supplier’s nominated finance contact (whose identity was confirmed during onboarding via ASIC-registered ABN details), and observe them displaying the new bank statement on screen. Only after both parties confirm the change verbally and visually, and the session is automatically recorded and stored, does the ERP allow the update. This method defeats deepfakes because the verification channel is controlled by the organisation, not the attacker.

This approach shifts verification from a reactive check to a proactive, trust-but-verify gateway. By requiring confirmation through a channel the attacker cannot compromise—such as a pre-registered video link or a time-bound MFA push notification sent to a known device—you eliminate the risk of social engineering via compromised email or phone. The protocol’s strength lies in its independence: it does not rely on the potentially fraudulent instruction itself for validation.

Implementing this creates a clear delineation of responsibility. The finance officer initiating the change must prove they followed the secure channel, while the independent validator confirms the instruction aligns with established patterns and organisational policy. This dual control, enforced by system workflow rather than memory or diligence, is what transforms a vulnerable manual step into a auditable, repeatable control.

The Governance Gap: Fiduciary Duty and Payment Integrity

Accepting an altered payment instruction without robust verification isn't just a process failure; it can constitute a breach of the duty of care and diligence under section 180 of the Corporations Act 2001 (Cth). Directors and officers must exercise their powers with the degree of care and diligence that a reasonable person would exercise in their position. When fraudsters manipulate payment details, the failure to independently verify that change through a secure, out-of-band channel may be seen as falling short of this objective standard, particularly if the red flags were apparent or the control environment was knowingly weak.

This duty extends beyond intentional misconduct to encompass recklessness or negligence in the face of foreseeable risk. ASIC has consistently highlighted that inadequate controls over payment processes, especially where they enable fraud, can attract civil penalty proceedings. The cost of defending such an action, coupled with potential reputational damage and the obligation to repay misdirected funds, far outweighs the investment in preventive verification protocols. Governance isn't about perfection; it's about demonstrating that reasonable steps were taken to mitigate known threats.

Consider the scenario where a finance manager receives an email, seemingly from a long-standing supplier, requesting an update to their bank account details for an upcoming $450,000 payment. The email domain is subtly misspelled, a detail missed in the rush of month-end processing. Without initiating an out-of-band verification call to a known contact at the supplier, the payment is processed to the fraudulent account. Under section 180, if it can be shown that a reasonable finance officer in the same position would have noticed the irregular domain or deemed the request suspicious given the payment size and context, the failure to verify could be construed as a breach of the duty of care and diligence. This moves beyond simple error; it questions whether the officer exercised the level of vigilance expected of their role.

The objective standard set by section 180 is not subjective to the individual's intent but to what a reasonable person in that position would do. This means that even if the officer did not act dishonestly, their conduct may still fall short if it deviates from the objective standard of care, especially when basic verification steps — such as confirming the request via a separate, trusted channel — are omitted despite known fraud tactics targeting payment instruction changes. The focus shifts from intent to the adequacy of the process followed and the vigilance exercised.

This objective lens is critical for directors and senior finance officers. Section 180 imposes a duty to exercise care and diligence that a reasonable person would exercise in their position, with the responsibilities they hold. When processing a payment instruction change, the reasonable officer would not rely solely on the incoming email, no matter how convincing. They would initiate independent verification through a pre-established, trusted channel — a phone call to a known contact using a number on file, not the one provided in the request — before altering banking details in the ERP system. Failing to take this basic, documented step when the request involves changing where funds are sent constitutes a failure to meet that objective standard.

The consequence is not merely an internal control failure; it creates exposure to civil penalty proceedings under section 1317E of the Corporations Act. ASIC can pursue directors or officers for breaches of their duty of care and diligence where the contravention is serious and they have not acted honestly and conscientiously. While intent (dishonesty) is not required for a section 180 breach, the context of known, prevalent fraud tactics targeting payment changes means that omitting verification is unlikely to be seen as merely an honest mistake. It demonstrates a lack of the vigilance the law expects from those entrusted with corporate funds, turning a processing error into a potential governance breach with significant personal liability.

Uncommon Insights

Relying on manual spot-checks for payment instruction changes feels economical until the first successful fraud exposes the hidden cost: recovery efforts, reputational damage, and potential civil penalties under section 1317E. Advanced AI monitoring tools, by contrast, analyse contextual patterns — invoice timing, supplier communication history, even linguistic nuances — to flag anomalies invisible to human reviewers processing hundreds of requests weekly.

The perceived saving of manual checks ignores the opportunity cost of skilled finance staff diverted from strategic work to repetitive verification, a task where fatigue and familiarity breed error. AI doesn't eliminate human judgment but elevates it, presenting only high-risk exceptions for expert review, thereby transforming verification from a bottleneck into a targeted control.

The counter-intuitive insight is that manual verification often increases risk through false confidence. A finance officer who "spot-checks" 10% of payment changes may believe they are exercising due diligence, but this sampling creates predictable gaps fraudsters exploit by timing changes to avoid the check cycle. Advanced behavioural analytics, however, establishes a baseline for each supplier relationship — detecting when a long-standing vendor suddenly invoices for atypical goods or requests payment to a newly registered entity in a high-risk jurisdiction.

This shifts the control from periodic, discretionary review to continuous, objective monitoring. The cost-benefit analysis favours automation not because it is cheaper per transaction, but because it reduces the variance in control effectiveness. Where manual checks yield inconsistent results dependent on individual vigilance and workload, AI tools apply the same forensic logic to every transaction, generating auditable evidence of consistent application — a critical factor in defending against allegations of breached duty of care under the Corporations Act.

One counter-intuitive insight is that the greatest vulnerability often lies not in the transaction itself, but in the reconciliation lag. Fraudsters know that banking detail changes submitted late on a Friday afternoon, or just before a public holiday, exploit the delay between payment initiation and bank confirmation. By the time the mismatch surfaces in reconciliation—often days later—the funds have already been layered through multiple accounts, making recovery nearly impossible under the ePayments Code. This timing tactic bypasses even diligent end-of-day checks because the initial payment instruction appeared valid at the point of release.

Another overlooked mechanism is the use of compromised supplier portals. Instead of spoofing emails, attackers gain legitimate login credentials to a supplier’s accounting system (via phishing or credential stuffing) and alter banking details directly in the source invoice template. Subsequent invoices generated from that system appear authentic—correct ABN, logo, and historical invoice sequencing—because they are, in fact, genuine documents from the supplier’s own system, merely manipulated at the source. This defeats email-based verification controls entirely, as the fraud originates upstream of the accounts payable team’s inbox.

These tactics reveal why relying on manual spot-checks of outgoing payments is insufficient. Effective defence requires validating the integrity of the instruction at its origin—whether through secure supplier portal access controls, real-time banking detail validation against the PayID registry, or cryptographic verification of invoice authenticity—shifting the focus from detecting anomalies after the fact to preventing the corruption of the instruction before it enters the payment stream.

Advanced AI monitoring tools are often dismissed as an unnecessary expense when manual spot-checks appear to cost nothing. This view ignores the true cost of manual verification: the opportunity cost of skilled finance staff diverted from strategic work, the inconsistency of human attention across high-volume periods, and the near-zero probability of catching a deepfake voice call or a subtly altered invoice that mirrors historical patterns. AI-driven anomaly detection, by contrast, operates continuously, learns evolving fraud patterns, and flags deviations in real-time—such as a sudden change in payment timing inconsistent with a supplier’s historical behaviour or a banking detail change originating from an unfamiliar geographic IP address.

Perceived savings from manual processes evaporate when a single successful fraud event incurs not only direct financial loss but also reputational damage, regulatory scrutiny under the Corporations Act 2001 (Cth) for inadequate controls, and the cost of incident response. The counter-intuitive insight is that investing in AI-assisted verification is not about adding cost—it is about replacing a false economy with a scalable, auditable defence that reduces both the likelihood and impact of payment fraud at a fraction of the expected loss from a material incident.

Compliance Checklist

Any change to a supplier’s banking details triggers a mandatory, documented workflow that cannot be bypassed by email or verbal request alone. The process begins with a formal change request submitted through the authorised procurement system, which locks the fields and initiates an out-of-band verification sequence.

Verification requires two independent factors: confirmation via a pre-registered, non-email channel (such as a callback to a known landline or secure portal message) and sighting of an original, signed bank letter or verified bank portal screenshot. Both factors must be recorded, timestamped, and attached to the change request before it proceeds to approval.

The workflow mandates segregation of duties: the officer initiating the change cannot be the same person who performs the verification or grants final approval. This separation is enforced within the procurement system through role-based access controls, preventing a single individual from completing the entire chain.

Final approval requires explicit sign-off from a nominated senior finance officer or, for changes exceeding a materiality threshold (e.g., >$500,000 annualised value), direct board committee endorsement. Each approval layer generates a unique, system-issued authorization code that must be entered to progress the request, creating an immutable, time-stamped audit trail traceable to specific individuals.

Every approved banking change must generate a complete audit packet retained for seven years. This packet includes the original change request, the two-factor verification records (callback log and bank document sighting), the segregation-of-duties attestation, and all system-generated authorization codes with timestamps.

The packet must be signed off by the verifying officer and the approving authority before being filed in the central procurement compliance repository, accessible to internal audit and external regulators upon request. Failure to produce this packet during an ASIC investigation under Corporations Act s 180 (duty of care) or s 588G (insolvent trading) weakens the defence that reasonable steps were taken to prevent loss.

Regular, unannounced spot-checks of these packets by the internal audit team — targeting at least 5% of all banking changes quarterly — provide the necessary assurance that the process is not merely documented but consistently executed.

Key Takeaways

Verification cannot be a one-time onboarding checkbox. It must be embedded as a continuous, recurring control applied at both initial supplier setup and mandatory annual review cycles, treating every existing relationship as subject to re-verification of payment details.

This shifts the mindset from episodic checks to a living due diligence process where banking instruction changes trigger immediate, documented re-validation against trusted, independently sourced data — not just the last invoice or email on file.

The directive is clear: integrate payment detail verification into the core supplier lifecycle management workflow, making it as routine and non-negotiable as confirming an ABN or validating insurance certificates, with accountability tracked at the process level, not left to individual discretion.

For CFOs, the mandate extends to board reporting: any material change to a Tier 1 supplier’s banking details must be disclosed in the quarterly risk attestation, signed off by both the CFO and the General Counsel, creating an explicit audit trail that satisfies ASIC’s expectations under RG 176 for proactive fraud risk management.

Procurement leads must ensure that supplier master data fields for BSB and account number are locked in the ERP system unless a dual-control workflow is triggered — one initiated by accounts payable, the other independently verified by treasury using a pre-agreed, out-of-band method such as a callback to a known landline number on file, not the number supplied in the change request.

The sharp directive is this: treat every banking instruction change as a potential compromise until proven otherwise through verifiable, independent corroboration — not as a routine update to be processed, but as a control point demanding the same rigour as a new vendor onboarding, with failure to escalate for verification constituting a clear process deviation requiring immediate investigation.

The annual review cycle must treat supplier banking details with the same scrutiny as initial onboarding. Every 12 months, finance teams should trigger a re-verification process for all active suppliers, cross-referencing current BSB and account numbers against independently sourced data — such as the supplier’s published ABN lookup via the Australian Business Register or confirmed contact via their verified corporate website — not relying solely on historical ERP fields that may have been compromised undetected.

Embedding continuous, cross-referenced due diligence means linking payment instruction changes to broader supplier risk signals. A change in banking details should automatically prompt a check for concurrent alterations in contact names, email domains, or invoice formatting — patterns often seen in business email compromise schemes. This triangulation, built into the ERP workflow, transforms verification from a reactive checkpoint into a proactive, intelligence-driven control that evolves with the threat.

Actionable mandates for CFOs and Procurement leads: treat every banking instruction change as high-risk until verified through an independent, out-of-band channel, and document the verification method and result as part of the audit trail.

Verification must be a non-negotiable gate in both supplier onboarding and the mandatory annual review cycle, with failure to complete it triggering an automatic escalation to finance leadership for investigation.

Embed continuous, cross-referenced due diligence by linking payment detail changes to automated checks for anomalies in supplier contact information, email domains, and invoice patterns within your ERP workflow.

• Mandate out-of-band verification for any change to supplier banking details, requiring confirmation via a pre-registered phone call or secure video call using independently sourced contact information.
• Integrate verification into onboarding and annual reviews, treating the 12-month re-check with the same rigour as initial vendor setup, using the Australian Business Register to validate ABN-linked banking details.
• Automate cross-referencing of banking changes with shifts in supplier email domains, contact names, and invoice formatting to detect business email compromise patterns in real time.
• Require documented sign-off from senior finance or the board for all banking instruction updates, creating an auditable trail that satisfies directors' duty of care under the Corporations Act.
• Monitor verification completion rates as a key risk indicator, investigating any process deviation where a change is processed without the required independent confirmation.