By Joshua Clouston, Head of Product, ezyshield
Nick Scali's Ransomware Hit Exposed Australia's Payment Control Blind Spot
Nick Scali's August 2026 ransomware attack forced manual payment processing. Here's what that reveals about payment fraud controls - and what businesses must fix before it happens to them.
On 14 August 2026, Nick Scali - a $1.43 billion ASX-listed furniture retailer - filed a market announcement disclosing it had been hit by ransomware. Systems went offline. Orders shifted to manual processing. Staff began contacting customers directly to manage delays. The company told the ASX it had notified the Australian Cyber Security Centre and the Australian Federal Police.
Most media coverage landed on one reassuring detail: Nick Scali confirmed it does not store customer credit card details on its own systems. Payments were routed through a secure third-party provider, which stayed operational. Crisis, arguably, contained.
But for any business that processes B2B payments - progress payments, supplier invoices, subcontractor draws, professional fees - the more uncomfortable question is not what Nick Scali lost. It is what every finance team loses access to the moment their own systems go dark.
What Happened at Nick Scali
The ransomware appears to have been deployed around 8 or 9 August, with Nick Scali disclosing the incident publicly on 14 August via an ASX filing. Offshore criminal groups are believed to be responsible. The company’s online ordering and delivery processing systems were taken offline, forcing staff to switch to manual workflows.
Nick Scali stated it had “no evidence of unauthorised access to customer data,” though reporting by The Australian indicated that customer residential addresses may have been accessed. A ransom was demanded. The company is reportedly engaging with the hackers through an intermediary - a not uncommon position when encrypted operational data makes self-recovery a weeks-long proposition.
The decision to route customer payments through an independent third-party processor turned out to be exactly the right call. Credit card details were never at risk. That architectural choice - made long before this incident - deserves recognition. It is the kind of quiet resilience planning that only gets noticed when it works.
The gap that did not get noticed is the one that matters for the businesses reading this.
Ransomware Doesn’t Just Lock Files - It Locks Your Controls
The standard ransomware narrative focuses on data: what attackers encrypted, what they stole, what it costs to recover. That framing is accurate, but it stops short of describing what ransomware does to the operational layer that sits on top of the data.
Modern businesses do not just store data in their systems. They run controls through them. Accounts payable automation. Supplier bank account verification workflows. Bank account change approval queues. Payment run sign-off processes. Invoice matching against purchase orders. Vendor onboarding checklists that require a verified BSB before a new supplier is set up for payment.
When ransomware takes those systems offline, the result is not only an IT problem. It is a payment fraud window - and that window can open before anyone realises it is there.
Fraudsters understand this. The moment a ransomware attack becomes public, through an ASX announcement, a news article, or even an internal memo that leaks to the wrong place, it signals to business email compromise (BEC) operators that the target’s automated controls are down. An attacker watching the ASX wire on 14 August saw exactly what they needed: a major business, running manual processes, with staff under pressure to keep orders and deliveries moving.
That is the environment BEC was designed to exploit.
Manual Processing Is Where Payment Fraud Walks In
The mechanics of payment redirection fraud are well-documented by the AFP’s Operation Dolos and AUSTRAC’s typologies guidance. An attacker impersonates a trusted supplier or a senior executive. They send a convincing email requesting that a payment go to a new bank account, typically explaining that the existing account has been closed or is under investigation. They often time the approach to coincide with a real invoice cycle.
In normal operations, a finance team might catch this through automated flagging, or by cross-referencing the request against a verified supplier register inside the AP system. A verification step might surface a mismatch between the new account number and the registered ABN. An approval workflow might route the change request to a second approver before the account is updated in the system.
In manual processing mode, those checks do not happen automatically. A staff member handling three times their normal volume, under pressure to keep deliveries and customer commitments on track, receives what looks like a legitimate invoice. The call to verify gets skipped. The payment goes to the wrong account.
Australian businesses lost $166.8 million to payment redirection scams in 2025, up 9.3 per cent from the year prior. AUSTRAC has documented in its typologies reporting that payment fraud events cluster around periods of organisational disruption - systems transitions, staff changes, mergers, and increasingly, cyber incidents. The pattern is consistent: attackers monitor for operational vulnerabilities, then accelerate their social engineering campaigns while defences are down.
The cases that never appear in the statistics are the ones where a business was already managing an IT crisis when the fraudulent invoice arrived.
The Structural Weakness: Verification Inside Compromised Systems
Nick Scali’s third-party payment processor is the detail every finance leader should learn from. By keeping payment processing independent of their own infrastructure, they ensured that one failure could not cascade into another.
Most businesses that process B2B payments have not applied that same logic to their verification layer.
If the process for verifying a supplier’s bank account lives exclusively inside an ERP or AP system - if the verified BSB for a supplier is a field in a database that is now encrypted - the finance team has no independent means of confirming where a payment should go during an outage. They cannot look up what account number was used last time. They cannot verify that a new account number matches the ABN registration for that supplier. They are working from memory and trust.
That gap exists in most businesses. Most do not know it is there until they need to make a payment with their systems down.
The construction sector faces this acutely. High-value progress payments flow between principals, head contractors, and subcontractors on fixed programme schedules. A head contractor cannot always delay a subcontractor draw because the AP system is offline - the subcontractor has payroll to meet. When the system is down and the payment still needs to go out, what independent verification capability does the finance team have?
The same question applies in professional services - law firms disbursing settlement funds, accountancy practices paying on behalf of clients - and in property conveyancing, where the settlement calendar is not flexible and the amounts involved mean a single misdirected payment is catastrophic.
The AFP has noted the construction sector’s particular exposure to BEC, citing “high-value transactions and complex subcontracting chains” combined with frequent invoicing and often under-resourced security. Ransomware disrupting internal controls compounds that exposure. The sector needs verification that works even when the system holding the supplier register does not.
The September Backdrop
Australia’s Scams Prevention Framework core obligations take effect on 1 September 2026 - ten days from today. Banks, telcos, and digital platforms face fines of up to $50 million per breach if they cannot demonstrate appropriate detection and disruption measures were in place.
For businesses that originate large B2B transfers, the implication is clear: “our systems were offline” is not a defence under the framework. The obligation is to have controls that work in foreseeable failure conditions. Ransomware is a foreseeable failure condition. The Australian Signals Directorate has listed it in the top four threat categories for several consecutive years, and Australian enterprises experienced materially significant cyberattacks at a rate of 85 per cent in the prior 12 months - well above the 54 per cent global average.
Regulators have signalled consistently that foreseeable failure modes require foreseeable mitigations. A verification capability that goes dark whenever the internal network does is, plainly, a foreseeable failure mode.
What Australian Businesses Should Ask This Week
Nick Scali’s incident is a useful forcing function. Before the next ransomware announcement lands on the ASX - and there will be another - here are the questions finance and IT leaders should ask:
Where does your supplier bank account verification live? If it lives only in your ERP or AP system, your team has no independent means to verify a BSB when that system is offline. That is a gap worth closing before you need it.
What is your manual payment playbook? If systems went offline today, which approval steps would still apply before a payment left the business? Who authorises exceptions? Is there a documented procedure, or does it live in someone’s head?
Are your staff trained on BEC risk after a system incident? The window between a system going down and coming back up is when social engineering attempts peak. Finance teams should treat any bank account change request during that window as high-risk by default, and require secondary verification through a known, trusted phone contact - not a number from the email.
Have you notified your bank? Banks operating under the Scams Prevention Framework have obligations when they receive suspicious payment instructions. Letting your bank know that your systems have been compromised puts them on alert to apply additional scrutiny to outbound transfers during the outage period.
Is your payment verification independent of your internal infrastructure? If the answer is no, that is the structural change worth making - before an incident forces you to confront it at 11pm on a Thursday.
Nick Scali’s third-party payment processor worked because it was architecturally separate from the systems that failed. The businesses that come out of a ransomware event without a payment fraud loss stacked on top of the IT recovery bill are the ones that applied that same logic to their verification capability - before the attack, not after.
ezyshield is on a mission to eliminate payment fraud in Australia. We verify the person, the business, and the bank account before money moves - so payments only ever land with who they’re meant to. Learn more
Keep reading
$152 Million Lost as Australia's New Payment Fraud Law Arrives in 26 Days
BEC losses jumped 66% to $152.6M in 2024. Three charged in May. Australia's Scam Prevention Framework goes live 1 July. Here's what it fixes - and what it doesn't.
How a Fake Email and a New BSB Cost an Australian Government Agency $3.5 Million
BEC fraud cost Australian businesses $152.6 million in 2024 - up 66%. A real AFP case shows exactly where account verification stops the attack.
Australia's Scams Prevention Framework Is Now Law - and the September Clock Is Ticking
Australia's Scams Prevention Framework is now law. Banks, telcos and platforms face $50M fines per breach. Here's what changed on 1 July 2026 and what's coming 1 September.
Stop payment fraud before money moves
Verify the person, business, and bank account before any payment leaves your account.