Grossly Negligent Was the Finding. Systems Were the Cause.

Not deliberate. Still grossly negligent.

That pairing is the whole lesson of the Westpac hardship case, and it is the sentence a risk function has to put in front of a board. The Federal Court did not find that anyone set out to ignore customers in financial difficulty. It found an online intake channel that ran for years with system and operational failures nobody investigated, and it held the contraventions to be grossly negligent. The control that was absent is named on the court file, in ASIC's own pleading.

ASIC media release 26-107MR, published 27 May 2026, records the order and the finding: "while the contraventions were not suggested to be deliberate and arose instead from inadequate systems and operational failures, I have accepted that they were grossly negligent". The reasons are those of McEvoy J in the judgment delivered on 26 May 2026, cited as [2026] FCA 651. No appeal is recorded in the material relied on here.

The practitioner consequence has nothing to do with banking. Any channel that accepts a request through software and hands it to a team for action needs one control a downstream count cannot supply: a monthly reconciliation of what arrived at the front door against what the answering team resolved, with a named owner for every unexplained break.

Westpac did not lack a reconciliation everywhere. One leg of the channel had a reconciliation report whose missing applications were not raised with the teams who could act. A reconciliation becomes a control where its exceptions reach somebody who can act.

This is general information and education, not legal, compliance or financial advice.

What the court found, and what it did not

The judgment records at least 1,013 applications from 1,003 customers that were not sent to the Customer Assist team, or were not properly processed, from 2 October 2015. Across the Relevant Period of 2 October 2015 to 7 June 2023, 277 hardship notices received no decision notice in time or at all. Within the Agreed Contravention Period of 4 September 2017 to 8 May 2023, 223 were contraventions of section 72(4) of the National Credit Code. The channel served the Westpac brands and also St George Bank, BankSA and Bank of Melbourne.

ASIC's release records the court's observation that a particularly serious aspect was that the contraventions "caused a number of customers to have adverse credit information recorded on their credit files".

The statement of agreed facts records $1,439,526.11 in refunds of fees, interest and time value, plus $295,600.70 for non-financial loss, stated as at 13 December 2023.

The court ordered $26 million, adopting neither party's position: ASIC's $30 million was more than deterrence required, and Westpac's $10 million "would be little more than derisory in the circumstances and therefore wholly inappropriate". The gross negligence finding is made at paragraph 107 and restated at paragraph 189. For a risk function, that means a systems explanation carries weight only alongside the record of what was done to prove the channel worked.

How does a request disappear inside a working channel?

Quietly, and in more than one way at once.

The judgment records at paragraph 25 ASIC's summary of four system failures and three operational failures, in labels the reasons then adopt, the mechanisms being batch transfers, file configuration, a missing account number validation, data formatting and human error. Two of the seven carry the transferable lesson. One is that missing validation, which let an application be submitted without a valid account number and go no further than the front door. The other is Operational Failure A, human error in which missing applications appearing in a reconciliation report were not raised with the correct teams for action.

One path let a request enter and stop. The other detected requests that had stopped, then stopped again at the person who had to act.

The bank's own incident description states the gap in one sentence. Schedule A to the Amended Concise Statement filed in the Federal Court proceeding VID 695 of 2023, accepted for filing on 27 October 2023, records that "there was a lack of a control in place to reconcile that all online hardship applications received by the OneClick system were also received by the Tallyman system". The same document quotes internal audit language describing an "[E]nd to end control gap identified between hardship applications lodged within One Click and the application being correctly flagged in the core collections systems".

Two systems, one queue, and no count proving the second held everything the first accepted.

Continuous reconciliations between OneClick and App105 were implemented on 21 and 22 May 2023, after the Agreed Contravention Period had closed and years after the failures began.

Why did it take a customer phone call to surface the fault?

Because nothing inside the organisation was counting.

The signals existed. Employees were aware of the problem from at least December 2018. The judgment records 16 customer complaints about unanswered online hardship notices between 12 September 2017 and 31 January 2022, and that window matters, because ASIC's separate submission counts 13 complaints over the shorter period from 13 March 2019 to 31 January 2022. Either count describes individual customers reporting, one at a time, a defect no systemic measure was catching.

System Failure A was identified on 31 January 2022, prompted by a customer telephoning about their application. It was reported to ASIC on 3 March 2022. The remaining failures were identified between 31 January 2022 and 7 June 2023.

The court's assessment of that period is the sentence to carry into control design: "At any time from the commencement of the relevant systems failures in October 2015 until January 2022, Westpac could have and should have conducted a thorough investigation of its systems and processes".

The clock that turns a queue into contraventions

Three provisions do the work, and all three are read from Compilation No. 52 of the National Consumer Credit Protection Act 2009 (Cth), compilation date 1 July 2026, as at 26 September 2026.

Section 72(4) of the National Credit Code, which is Schedule 1 to that Act, requires the credit provider to give the debtor a decision notice "before the end of the period identified under subsection (5)". The table at section 72(5) sets 21 days from receipt of the hardship notice where no further information is required under section 72(2), and a different period where it is, so a control has to know which row applies. In every row the period is fixed by the instrument, not by when the request reaches a human. Section 72(4A) disapplies subsection (4) where the parties agree a deferral of not more than 90 days, so a reconciliation must count that as an answer.

Section 47(1)(a) of the Act, the obligation Westpac admitted contravening, requires a licensee to "do all things necessary to ensure that the credit activities authorised by the licence are engaged in efficiently, honestly and fairly", and section 47(4) makes that paragraph a civil penalty provision.

Section 175A(2) is the provision that decides how fast an unanswered queue gets worse. A person "commits a separate contravention of that provision in respect of each day during which the contravention occurs". An unanswered request accrues while nobody looks at it. That is the argument for running a reconciliation monthly rather than when somebody eventually asks.

What changes when the intake queue is AI-assisted

No artificial intelligence system is mentioned anywhere in the judgment, and it would be wrong to suggest either that an assistant caused this or that one would have prevented it. The case matters to an AI-assisted queue for a different reason: it describes the failure mode that assistance makes easier to produce.

An assistant that triages, summarises, classifies or auto-closes an intake queue adds a new way for a request to be resolved inside a system and produce nothing to the person waiting. The non-artificial version is already in the enforcement record. ASIC media release 25-165MR, published 13 August 2025, records that "The failure arose from NAB staff incorrectly using a 'reject' button in its system, meaning that the customer did not receive any communication from NAB or AFSH in response to their hardship application". The same release records that between 2018 and 2023 the two lenders failed to respond to 345 hardship applications within the 21-day timeframe required by law, for a $15.5 million penalty.

A reject button and a confident classifier are the same defect wearing different clothes. Both close a record. Neither sends anything.

The governance language for the answer is already published. The Department of Industry, Science and Resources set out its Guidance for AI adoption: implementation guidance, published 5 May 2026. Practice 5, test and monitor, asks organisations to "Establish monitoring systems for each AI system to track key performance metrics and indicators relevant to the identified risks", and to map "business targets to system performance metrics". Practice 6 is to maintain human control, and in an intake queue that resolves to one rule: an assistant may classify, draft and route, and the record closes only on a recorded outbound communication to the requester. That is guidance, not a mandatory instrument.

In a queue, the business target is that every request received is answered inside the statutory period, and the metric is the count of received requests with no answered match. Readers designing the gate rather than the queue will find the companion control at retry limits on automated eligibility gates, published 14 September 2026.

Is this one lender's problem?

The enforcement record says no, and the regulator's sector position says no.

ASIC media release 25-314MR, published 19 December 2025, records that "ANZ failed to respond to 488 customers who submitted financial hardship notices to the bank between May 2022 and September 2024", with a $40 million hardship penalty forming part of a $250 million combined order. The sequence matters: ASIC first notified ANZ of issues in June 2023, and "steps taken by ANZ to fix the issues did not work consistently, resulting in some further failures by ANZ up to September 2024". A regulator warning tells you where to look. Only a measured remediation tells you whether the looking worked.

On the sector, ASIC media release 25-216MR, published 25 September 2025, accompanied Report 815 Hardship, not so hard to get help. ASIC acknowledged improvements, then qualified them: "However, we have some concerns about the overall quality of lenders' hardship responses." The release records that lenders receiving tailored feedback were required to respond with an action plan, and that external independent assurance was requested in some cases. That is a September 2025 position, and it is quoted here with its date rather than as the regulator's position today. An action plan and an assurance statement are documents. Only the count fails visibly.

The control, in one table

The artefact is a one-page channel reconciliation definition, written once per automated intake channel. The whole value sits in three rows: the matching key, the exception owner and the escalation rule.

Three tests decide whether this is implemented rather than documented.

1. The received count comes from the intake system, not from the downstream queue, because a count taken downstream cannot detect what never arrived.
2. Every break carries a role title against it within the routing time.
3. Every unexplained break has either a closure note or an escalation, and never a blank.

Three prompts for the reconciliation

TheAICommand works to the Verified Draft Method: de-identify the inputs, ground the model in your own source material, keep a person at the decision point, verify against the primary source, and log what happened.

You are helping [ORGANISATION] define a reconciliation control for one automated intake channel, [CHANNEL_NAME]. Use only the attached documents. Do not use outside knowledge and do not assert a fact the attachments cannot support.

Attachments: the channel process map, the system inventory extract naming [INTAKE_SYSTEM] and [DOWNSTREAM_SYSTEM], and the work instruction for [ANSWERING_TEAM].

No individual names appear in the attachments. If a name appears, replace it with a role title in your output.

Produce a one-page reconciliation definition with these fields, and nothing else:
1. Channel: the named intake channel and the request type it accepts.
2. Received count: what counts as a request received, and the system of record, quoting the attachment that establishes it.
3. Answered count: what counts as answered, stating explicitly whether an outbound communication to the customer is required for the record to count, and the system of record.
4. Matching key: the identifier present on both sides that links one received request to one answered request, and what to do when a request carries none.
5. Statutory or policy period that applies, quoted from the attachments.
6. Run frequency and run owner: how often the reconciliation runs, by which day, and the role that produces it.
7. Tolerance, and what counts as an explained difference.
8. Exception owner, by role title only.
9. Routing rule for each break type, and the time within which each must be actioned.
10. Escalation trigger for an unexplained break.
11. Evidence location: where the output, the exception list and the closure notes are held, and the review date with the reviewing role.

Items 1 to 5 are read from the attachments. For any of them the attachments do not establish, write "not stated in the attached documents" and stop, and do not infer a system of record, a matching key or a period. Items 6 to 11 are design decisions the attachments will not contain. Propose a value for each, label it "proposed, not established by the attachments", and name the attachment or the absence that drove the proposal.

What to check: confirm that the received count is drawn from the intake system, not the downstream queue. Confirm the answered count requires an outbound communication rather than a closed status. Confirm every "not stated" is genuinely absent from the attachments, since each one is a finding to be resolved before the control operates. Decide every proposed value yourself before the definition is signed.

Classify the attached de-identified reconciliation break list for [ORGANISATION], channel [CHANNEL_NAME], for [MONTH]. Use only the attached break list and the attached channel reconciliation definition.

The list contains no customer names, account numbers or contact details. If any identifying value appears, exclude the row from the output and report its row number and the column that carried the value, so the row can be de-identified and run again.

For each break, return a table with columns: break reference, cause type, the evidence in the attached list that supports the cause type quoted verbatim, and the owning team named in the reconciliation definition. Where the definition does not name an owning team for that break type, write "owner not stated in the definition". Do not infer an owner from the break description or from the answering team.

Cause type is exactly one of:
- not transferred (present in the intake system, absent downstream)
- transferred and not queued (present downstream, never allocated for action)
- queued and closed without an outbound notice
- unknown

Use "unknown" wherever the attached list does not contain evidence for one of the first three. Do not guess and do not merge unknown into another category.

After the table, state the number of rows in the attached break list, the number classified and the number excluded for identifying values, and confirm the three reconcile. Then count each cause type, list the unknown break references separately, and list the break references whose owner is not stated, because each one is an open finding.

What to check: count the unknown rows yourself first, because a triage that returns no unknowns on a first run is the result to distrust. Check that the classified rows plus the excluded rows equal the break list. Open two rows in each named cause type against the source list and confirm the quoted evidence is present. Confirm each owning team appears in the reconciliation definition, and treat every "owner not stated" row as an open finding. Then de-identify every excluded row and run it again.

Test the intake channel [CHANNEL_NAME] at [ORGANISATION] against the generalised failure list below, which extends the pattern in this case rather than reproducing it. Use only the attached process documents and system configuration extracts. Do not use outside knowledge about any other organisation.

The attachments are de-identified. If any individual name, user ID or mailbox address appears, replace it with a role title in your output.

The failure types to test are:
1. A request can be submitted without a mandatory identifier and progress no further.
2. A request is created in [INTAKE_SYSTEM] and is not transferred to [DOWNSTREAM_SYSTEM].
3. A transferred request is not allocated to [ANSWERING_TEAM] for action.
4. A request is closed in the system with no outbound communication to the requester.
5. An exception report is produced and has no named recipient with authority to act.
6. The deadline clock is calculated from allocation rather than from receipt.
7. A reprocessing or retry step overwrites the original receipt date.

For each failure type, return one of: ruled out (with the attachment and clause quoted verbatim), not ruled out (with what the attachments do not cover), or not applicable (with the reason). Do not record a failure type as ruled out on the basis of intent, policy language or an assurance statement. Only a stated control or system configuration rules a failure type out.

What to check: every "ruled out" must carry a verbatim quote naming a control or a configuration, and an assurance that the process is designed to prevent the failure does not qualify. Treat every "not ruled out" as an open finding with an owner and a date. Confirm failure type 6 against the field used to start the clock, since a deadline measured from allocation hides every request that was never allocated.

Do this Monday

The artefact is the one-page definition above, built for a single automated intake channel.

The owner is the operational risk lead for that channel, not the platform team that built it. That team can produce the counts. It cannot decide whether a break matters.

The first step fits in an hour with nothing beyond this article. Pick one channel. Write down two queries in plain words, each returning one row per request keyed on a shared identifier: one that lists what the requester submitted at the front door, naming the system of record, and one that lists what the answering team resolved with an outbound communication, naming its system of record. Then write the tolerance, the exception owner by role title, and who receives the break list. Send both definitions to the team that holds each system and ask for last month's rows against each, with a date.

The check that proves it worked is a single run for last month, with the two lists matched on the shared identifier and every unmatched request explained. If nothing is unmatched, or every unmatched request has a written explanation and a role title against it, the control exists and can be scheduled monthly. If the received query cannot be written at all, because no system holds a front door count, that is the finding.

The bottom line

A systems failure and a gross negligence finding are not competing explanations, and any risk function that treats the first as a defence to the second is reading the wrong half of the judgment. The transferable control is not better technology. It is a count of what a channel received measured against what the answering team sent, run monthly, with a tolerance, a named exception owner and an escalation rule for an unexplained break. Reconciliation without a routed exception is what Westpac already had. Build the definition for one channel first, then run it for last month, then argue about the rest.