AI in Complaints Handling: What RG 271 Reserves for a Person

Financial firms are putting artificial intelligence into the one complaints process ASIC made enforceable.

Internal dispute resolution, or IDR, is where a customer's complaint meets a licensee's obligations. It is also where AI vendors are now selling: tools that acknowledge and triage incoming complaints, summarise a long file in seconds, draft the response, and read across thousands of complaints to flag patterns. The pitch lands because complaints handling is high-volume, repetitive and slow. But IDR is not an ordinary workflow. Its core is legally enforceable under ASIC Regulatory Guide 271. So the real question for a governance, risk and compliance team is not whether AI can help, because it can. It is which parts of an enforceable process AI is allowed to touch, and which parts RG 271 reserves for a person.

What RG 271 actually requires

RG 271 took effect on 5 October 2021, replacing the older RG 165. It applies to Australian financial services licensees, credit licensees, superannuation trustees, unlicensed product issuers and others, and ASIC publishes the current guide on its RG 271 page. Crucially, ASIC did not leave it as guidance. The standards and requirements in RG 271 are enforceable through the ASIC Corporations, Credit and Superannuation (Internal Dispute Resolution) Instrument 2020/98. Breaching them is not falling short of good practice. It is a compliance failure ASIC can act on.

Four features of the standard matter most when AI enters the picture.

First, the clock. For a standard complaint, a firm must give the complainant an IDR response no later than 30 calendar days after receiving it (RG 271.56). That is a hard reduction from the 45 days allowed under the old RG 165. If the firm cannot meet the deadline because the complaint is genuinely complex or the delay is beyond its control, it must send an IDR delay notification before the deadline expires, setting out the reasons for the delay, the customer's right to complain to AFCA and AFCA's contact details (RG 271.66).

Second, what counts as a complaint. RG 271.27 adopts the AS/NZS 10002:2014 definition: an expression of dissatisfaction made to or about an organisation, related to its products, services, staff or the handling of a complaint, where a response or resolution is explicitly or implicitly expected or legally required. That is deliberately broad. A frustrated message on social media can be a complaint. The definition is wide precisely so firms cannot quietly narrow it.

Third, the reasons. An IDR response is not a yes or a no. Where a complaint is rejected or partially rejected, RG 271.54 requires the response to identify and address the issues raised, set out the firm's findings on material questions of fact together with the information that supports those findings, and give the customer enough detail to decide whether to take the matter to AFCA. The response must also state the outcome and the customer's right to go to AFCA, with AFCA's contact details (RG 271.53). The reasons are the substance of the obligation.

Fourth, systemic issues. RG 271.117 defines a systemic issue as a matter that affects, or has the potential to affect, more than one consumer. The obligations sit alongside the definition at RG 271.118 to RG 271.120: boards must set clear accountability, staff must be able to escalate possible systemic issues they see in individual complaints, firms must regularly analyse complaint data sets to identify them, and identified issues must be escalated promptly for investigation and action. On top of this, firms report IDR data to ASIC, so the regulator sees complaints performance in aggregate.

This is not a dormant standard. In REP 802, published on 5 December 2024, ASIC reviewed 11 general insurers against select enforceable RG 271 obligations. A firm inserting AI into IDR is inserting it into a process the regulator actively measures.

Where AI genuinely helps

None of that means AI has no place in complaints handling. On the admin it is genuinely useful, and refusing it would be its own failure to serve customers well.

AI can acknowledge and triage. An inbound complaint can be logged, categorised and routed the moment it arrives, which helps a firm start the 30 day clock correctly and get the complaint to the right team. AI can summarise. A case manager facing a fifteen-page file with attachments can get a structured, neutral summary of the actual complaint, which saves time and reduces the chance an important point is missed. AI can draft. A first-pass acknowledgement and a plain-English response can be generated for a person to check, correct and approve, which brings consistency to a team that would otherwise write in a dozen different registers.

And AI can help with systemic issues, arguably its highest-value use here. Spotting a matter that affects more than one consumer is a pattern-recognition problem across a large data set, exactly what these models are good at. AI can cluster complaints by product, cause and language, and surface candidate systemic issues for a human analyst to investigate. That does not discharge the obligations at RG 271.118 to RG 271.120, but it makes the human far more likely to see the pattern early.

The common thread: each is admin or pattern-spotting a person still signs off. The AI drafts, organises and surfaces. It does not decide.

What RG 271 reserves for a person

The line falls at the outcome. Deciding whether to uphold or reject a complaint, and explaining the reasons, is a regulated decision. It is the substance of the IDR response, and RG 271 makes a person accountable for it. Handing that to a model creates two problems at once.

The first is fairness. A language model produces the most plausible-sounding response, not the correct one, and it will write a confident, well-structured rejection whether or not the rejection is right. Put that in front of an aggrieved customer without a person weighing the actual facts against the actual obligations, and the firm has automated the exact thing IDR exists to prevent: a fast, tidy brush-off.

The second is explainability. RG 271.54 requires findings on material questions of fact and the information that supports them. A model's real reason for a wording is buried in its training, not in your complaint file, so an AI-drafted rejection can read persuasively while resting on reasoning no one can stand behind. If AFCA later asks why the firm decided as it did, the honest answer cannot be that the model wrote it that way.

The systemic issue call sits on the human side of the line too. AI can surface a candidate pattern, but deciding that something is a systemic issue, escalating it, and acting on it are accountable judgements under RG 271.118 to RG 271.120. So does the clock. The 30 day obligation is the firm's, and AI mishandling triage, or a delay notification never sent because the workflow assumed the model had it covered, is the firm's breach, not the vendor's.

The tool is also a system that handles sensitive data

There is a second-order risk that the just-deploy-a-complaints-assistant pitch skips. A complaint file is some of the most sensitive information a firm holds. Complaints routinely involve financial hardship, health conditions, and disclosures of family and domestic violence. An AI tool that reads and drafts on that file is processing sensitive personal information, frequently through a third-party service and into logs.

That makes the complaints assistant a system to govern, not just a productivity feature. Privacy Act obligations attach, and the OAIC's guidance on privacy and the use of commercially available AI products, published in October 2024, is the relevant lens: know where the data goes, collect and expose only what is necessary, and be able to explain and defend the arrangement. The tool is also a candidate for third-party and operational-resilience scrutiny in its own right: a complaints function that cannot operate, or that leaks, is a live operational risk on top of a supervised process.

So RG 271 plus AI creates two obligations, not one. The first is to keep the enforceable decisions with accountable people. The second is to govern the tool that helps them: know what data it sees, log what it drafted versus what the person decided, monitor its quality, and treat it as the high-consequence system it is.

A worked example: the drafted rejection that did not survive review

Here is how the rule plays out at the desk. Every detail is de-identified and illustrative.

The situation. A case manager at [FIRM], a general insurer, is at day 22 of the 30 day clock on a complaint from [CUSTOMERNAME] about a partially declined home and contents claim after a storm. The file runs to 14 documents, including an assessor report and a hydrology report that do not fully agree. The case manager asks the team's approved AI assistant for a first-pass response:

Summarise the attached de-identified complaint file, then draft a first-pass IDR response for a partially rejected complaint. State the proposed outcome as [OUTCOME]. Set out the issues [CUSTOMER_NAME] raised, the findings on each material question of fact, and the document that supports each finding. Use plain English at a general reading level. Include the required referral to AFCA with contact details. Mark any statement you cannot support from the file as [UNSUPPORTED] rather than writing around it.

What came back. A clean, confident draft: outcome stated, each issue addressed, the water damage exclusion explained in plain English, the assessor report cited. It read like it could go out.

What the review found. Two problems a signature would have owned. The draft paraphrased the policy exclusion more broadly than the actual [POLICYTERM] wording in the product disclosure statement, and it asserted the date water entered the property as settled fact when the assessor and hydrology reports gave different dates. Under RG 271.54 both are findings on material questions of fact, and neither was supported the way the draft implied.

What the person decided. The case manager corrected the exclusion to the verbatim clause, rewrote the timing finding to acknowledge both reports and explain which was preferred and why, confirmed the AFCA paragraph, and made the decision under the firm's authority matrix. The file holds both versions, what the model drafted and what the person changed and decided. That is the evidence trail that shows ASIC or AFCA a person owned the outcome and the reasons.

Two prompts to put to work

Both prompts suit ChatGPT, Claude or an equivalent tool your firm has approved for internal documents. Two rules before pasting anything: never put a raw complaint file into a public AI tool, and treat every output as a draft for a person to verify, never as compliance evidence.

Prompt 1: build the RG 271 obligation map

You are a governance, risk and compliance analyst helping an Australian financial firm govern the use of AI in its internal dispute resolution (IDR) function under ASIC RG 271. You map each RG 271 obligation to what an AI tool may do and what a human must own, and you flag where the AI itself needs governing as a system that handles sensitive data.

CONTEXT TO USE:
- RG 271 is enforceable via ASIC Instrument 2020/98. Standard complaints get an IDR response within 30 calendar days (RG 271.56), with an IDR delay notification before the deadline if it cannot be met (RG 271.66).
- A complaint is defined broadly (AS/NZS 10002:2014, adopted at RG 271.27). IDR responses must state the outcome and AFCA rights (RG 271.53) and, for rejections, set out findings on material questions of fact and the information that supports them (RG 271.54).
- Systemic issues (defined at RG 271.117; obligations at RG 271.118 to 271.120) must be identified, escalated and acted on. Firms report IDR data to ASIC.
- Complaint files routinely contain sensitive information (health, hardship, family and domestic violence).

INPUTS I WILL PASTE BELOW:
1. The AI tool(s) we are considering and what the vendor says they do.
2. Our current IDR process steps.

YOUR TASK: Produce a table with columns: RG 271 obligation | What AI may do (draft, summarise, triage, surface) | What a human must decide and own | Evidence to keep | AI-as-a-system risk (data, logging, fallback). Cover at least: acknowledgement and triage, the 30 day clock and delay notifications, the outcome decision and reasons, systemic issue identification and escalation, AFCA referral, and IDR data reporting. Then list the top 3 controls to put in place before go-live, ranked by customer harm and regulatory exposure.

HUMAN-REVIEW BOUNDARY: this is a drafting aid, not legal or compliance advice. A qualified person must confirm every mapping against the current RG 271 and Instrument 2020/98 and own the decision. Do not treat any output as evidence of compliance.

INPUTS:
1. AI tool(s): [PASTE_VENDOR_CLAIMS]
2. Current IDR process: [PASTE_PROCESS_STEPS]

How to run it: paste the prompt into a ChatGPT Project or a dedicated Claude chat as standing instructions, keep your IDR process map in a pinned note, and run two passes. First let the model build the full obligation map. Then ask it to re-read its own output as a sceptical AFCA reviewer testing whether a real person owns each outcome and each reason. Repeat until the map stops changing.

Prompt 2: red-team an AI-drafted IDR response

The obligation map governs the deployment. This prompt governs a single response, surfacing exactly what the person must verify before signing an AI-drafted IDR response.

You are a sceptical reviewer inside an Australian financial firm, checking an AI-drafted IDR response against ASIC RG 271 before a person signs it. You do not decide the complaint. You test the draft and list what the human decision-maker must verify.

CONTEXT TO USE:
- Where a complaint is rejected or partially rejected, RG 271.54 requires the response to identify and address the issues raised, set out findings on material questions of fact with the information that supports them, and give enough detail for the complainant to decide whether to go to AFCA.
- The response must state the outcome and the complainant's right to take the complaint to AFCA, with AFCA's contact details (RG 271.53).
- The reasons must rest on the complaint file, not on plausible-sounding generalities.

INPUTS I WILL PASTE BELOW (all de-identified: use [CUSTOMER_NAME], [PRODUCT], [POLICY_TERM]):
1. The complaint summary.
2. The AI-drafted IDR response.
3. The key documents relied on, or a list of them.

YOUR TASK:
1. Test every factual statement in the draft against the file and mark each one SUPPORTED, UNSUPPORTED or CONTRADICTED, quoting the file where possible.
2. Flag any clause, term or figure the draft states that does not appear verbatim in the documents.
3. Check the RG 271.53 and RG 271.54 elements are present: outcome, issues addressed, findings on material questions of fact, supporting information identified, AFCA rights and contact details.
4. List, in order of risk, what the human decision-maker must personally verify before signing.

HUMAN-REVIEW BOUNDARY: you are a checking aid, not the decision-maker. The person accountable for the IDR response owns the outcome and the reasons. Do not soften or strengthen the decision itself.

INPUTS:
1. Complaint summary: [PASTE_COMPLAINT_SUMMARY]
2. Draft IDR response: [PASTE_DRAFT_RESPONSE]
3. Documents relied on: [PASTE_DOCUMENT_LIST]

The pre-deployment checklist

For a GRC team asked to bless an AI complaints tool, the work is concrete. Treat this as the first pass and keep the evidence behind each answer.

• Map every RG 271 obligation to a role. For each duty, the 30 day clock, the acknowledgement, the reasons, the systemic issue escalation, the AFCA referral, name what the AI may draft or surface and what a person must decide. The outcome and the reasons stay human.
• Keep the human in the loop on outcomes, not just in theory. A review that rubber-stamps AI-drafted rejections at volume is not a control. Define what a case manager must actually check before an IDR response goes out.
• Log the split. Record what the model drafted and what the person changed and decided, so the firm can show, to ASIC or AFCA, that a person owned the outcome and the reasons.
• Govern the tool as a system. Data flows, sensitive-information handling, retention, access, monitoring and a fallback if the tool fails, all documented.
• Watch the systemic issue pipeline. If AI is clustering complaints, confirm that a human analyst still reviews and escalates, so the obligations at RG 271.118 to RG 271.120 are met by a person, not assumed by a model.
• Confirm against the current instruments. RG 271 and Instrument 2020/98 are the authorities. Validate the deployment against them, and the timeframes against the current guide, before go-live.

What to do on Monday

1. Pull your IDR process map and open ASIC's RG 271 page beside it. Confirm you are working from the current guide and the current Instrument 2020/98, not a 2021 summary deck.
2. Open ChatGPT, Claude or an equivalent tool approved for internal documents. Create a project or dedicated chat named RG 271 obligation map and paste Prompt 1 into the project instructions.
3. Paste in your IDR process steps and the vendor's capability claims, then run the map. Save the output as a working draft.
4. Run the red-team pass described above and tighten the weakest rows until the map stops changing.
5. Take the map to the complaints owner and put a named role, not a team, against every human-owned row. Any row without an owner is your gap list.
6. Test the logging on one live complaint. If you cannot produce what the AI drafted and what the person changed and decided, that logging is the first control to build before the tool goes anywhere near an outcome.
7. Book the privacy review. Data flows, retention, third-party terms and de-identification practice, checked against the OAIC's AI products guidance before go-live, not after.

AI belongs in complaints handling. It can make IDR faster, more consistent and better at spotting the patterns RG 271 wants firms to catch. What it cannot do is decide the complaint, own the reasons, make the systemic issue call, or carry the clock. Those are the enforceable core of RG 271, and they were assigned to people on purpose. The firms that get this right will let AI do the drafting and the pattern-spotting while a person, and the audit trail behind that person, owns every outcome.

References

1. ASIC, Regulatory Guide 271 Internal dispute resolution, issued 2 September 2021, standards effective 5 October 2021. https://www.asic.gov.au/regulatory-resources/find-a-document/regulatory-guides/rg-271-internal-dispute-resolution/
2. ASIC Corporations, Credit and Superannuation (Internal Dispute Resolution) Instrument 2020/98, Federal Register of Legislation F2020L00962. https://www.legislation.gov.au/F2020L00962/latest
3. ASIC, REP 802 'Cause for complaint: Complaints handling in general insurance', 5 December 2024. https://download.asic.gov.au/media/5p3axgd0/rep802-published-5-december-2024.pdf
4. Standards Australia, AS/NZS 10002:2014 Guidelines for complaint management in organizations (complaint definition adopted at RG 271.27).
5. OAIC, Guidance on privacy and the use of commercially available AI products, October 2024. https://www.oaic.gov.au/privacy/privacy-guidance-for-organisations-and-government-agencies/guidance-on-privacy-and-the-use-of-commercially-available-ai-products

Content disclaimer: This article is for general educational and informational purposes only. It does not constitute legal advice, regulatory guidance, or a substitute for professional compliance judgement. Regulatory obligations vary by entity type, licence and circumstance. RG 271 and its instrument may be updated. Always confirm your obligations against primary source guidance from ASIC and the current instruments before acting.