RG 271 is the ASIC regulatory guide that sets internal dispute resolution standards for Australian financial services licensees, including insurance brokers. It defines what counts as a complaint, how quickly you must acknowledge and respond, and what the response has to contain. Automation can safely handle the detection, logging, timing and escalation around a complaint. It cannot make the substantive decision, and treating an IDR response as a document-generation problem is how brokerages get into trouble.
What does RG 271 actually require?
Three obligations do most of the work, and each one has an automation story.
Complaints have to be recognised as complaints. RG 271.27 adopts the definition from AS/NZS 10002:2014:
[An expression] of dissatisfaction made to or about an organization, 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.
Note what is absent: any requirement that the person use the word "complaint". ASIC is explicit that a firm should not reclassify a qualifying expression of dissatisfaction as "feedback", an "inquiry" or a "comment" merely because it was made verbally or informally. RG 271.27–271.29 are enforceable paragraphs, not guidance.
This is the requirement brokerages most often fail, and they fail it invisibly — a complaint arrives as an ordinary email to an account manager, gets handled as ordinary correspondence, and never enters the register at all.
Acknowledgement should be prompt. RG 271.52 sets the expectation at within 24 hours, or one business day, of receipt — or as soon as practicable.
A response is due within a maximum timeframe. Table 2 of RG 271 sets these out:
| Complaint type | Maximum IDR response time |
|---|---|
| Standard complaints | 30 calendar days |
| Superannuation complaints (except death benefit distributions) | 45 calendar days |
| Traditional trustee complaints | 45 calendar days |
| Credit-related complaints involving default notices | 21 calendar days |
The response must set out the outcome, the reasons for it, and the complainant's right to take the matter to AFCA. Which timeframe applies to which parts of your book is a question for your licensee — that mapping is the one thing you should not derive from a blog post, ours included.
Separately, the Insurance Brokers Code of Practice carries its own 30-day complaints commitment, with an obligation to write to the complainant explaining the delay and their escalation rights if that is not met. NIBA has the Code under review, with a revised version expected in 2026 — and has signalled support for elevating record-keeping from guidance to an explicit Code obligation, which is worth knowing if you are designing a process now.
The clock starts on receipt. Not on the day someone realised it was a complaint.
Which parts can automation safely handle?
The parts where consistency matters more than judgement — which, in complaints handling, is most of the machinery around the decision rather than the decision itself.
Detection and triage. A classifier reading inbound correspondence can flag likely complaints for human confirmation. Note the framing: flag for confirmation, not classify and file. A model that silently decides an email is not a complaint has introduced exactly the failure mode the process exists to prevent. Run it as a net that catches things a busy account manager would miss, with a human making the call on anything it flags.
Logging and the clock. The moment a complaint is confirmed, the system creates the record, timestamps receipt, and starts the countdown. This is pure mechanism and it is where automation is unambiguously better than people — a workflow does not get distracted, take leave, or lose the thread when the account manager changes.
Acknowledgement. A prompt acknowledgement that confirms receipt, explains the process and sets expectations is a template. Sending it automatically on confirmation is safe and removes a step that gets delayed for no good reason.
Escalation before the deadline, not after. The most valuable thing an automated process does here is escalate at day 10 and day 20, not day 29. A breach that gets noticed on the deadline is already a breach. The system's job is to make sure a human is looking at the file while there is still time to act on it.
The evidence trail. Every touch, timestamped, attached to the complaint record. This is what a licensee audit or an ASIC review actually asks for, and it is the thing manual processes reconstruct badly after the fact.
Which parts must stay human?
The decision, and everything that shapes it.
An IDR response sets out an outcome and the reasons for it. That is a substantive determination about a client's circumstances, made by a person accountable for it under your licence. No language model should be generating the reasoning in a complaint response, and no brokerage should want it to — not because the output would read badly, but because a fluent, confident, wrong justification is worse than an awkward correct one, and it is harder to spot.
The same goes for anything involving remedy or compensation. Those decisions carry consequences that sit with your licensee.
There is also a category worth naming separately: complaints that signal something systemic. A single complaint about a policy exclusion is a complaint. Five complaints about the same exclusion is a problem with how that cover is being explained at the point of sale. Systems can surface the pattern; a human has to recognise what it means and act on it.
The workable division is that automation runs the process and a broker owns the determination. When those get inverted — a person nagged by reminders while a model drafts the reasoning — you have automated the wrong half.
What is this actually worth?
Complaints automation is not primarily an hours-saved play, and brokerages that pitch it internally on time savings usually undersell it.
The hours are real but modest. A brokerage handling 60 complaints a year, at roughly 90 minutes of administrative overhead each — logging, acknowledging, chasing internally, assembling the file, tracking the deadline — is spending about 90 hours a year on the machinery around complaints. Automating most of that recovers perhaps 60 hours. At a loaded $55/hour, call it $3,300. Useful, not transformative.
The real value is the two failure modes it removes. The first is the unlogged complaint — the one handled as ordinary email, never entering the register, invisible until it turns up at AFCA and you have no record of the timeline. The second is the missed deadline, which turns a resolvable dispute into a compliance breach on top of a dispute.
Neither of those is priced in hours. Both are the kind of finding that makes a licensee audit go badly.
How do you build it so it survives review?
Design for the audit from the first day, because retrofitting an evidence trail is far harder than building one.
Make the record immutable and complete: what arrived, when, who confirmed it as a complaint, every action and its timestamp, what went out and when. If an automated step made a decision — flagged, escalated, sent an acknowledgement — log that it was automated and on what basis. A reviewer needs to distinguish a human judgement from a system action, and a log that blurs them raises more questions than it answers.
Keep the data where you can account for it. Complaints files contain some of the most sensitive material a brokerage holds — client circumstances, financial detail, sometimes health information. Passing that through a third-party API to classify an email is a Privacy Act decision, and it is one worth making deliberately rather than by default.
Two things make this concrete. Under s 16C of the Privacy Act, an entity that discloses personal information to an overseas recipient is accountable for that recipient's handling of it — if they breach the APPs, that is treated as your breach. And the OAIC's guidance on commercially available AI products is clear that privacy obligations attach to information you put into an AI system as well as what comes out of it. Classifying a complaint email is an input.
Processing on infrastructure you control, or in an Australian region, keeps the answer straightforward when your licensee asks. This is the same argument we make about data sovereignty generally, and complaints handling is where it bites hardest.
Build human confirmation into the classifier from the start, not as a phase-two improvement. And keep the pattern-detection reporting simple: complaint volume by cause, by product, by month. The value is in noticing the cluster, and a plain report does that as well as anything sophisticated.
If you want this mapped against how your brokerage actually handles complaints today, that is the work we do in our insurance broker automation engagements.
Ready to make sure nothing falls through?
If your complaints process depends on someone remembering to log an email, it is worth a conversation. Book a discovery call and we will map your current process, show you where the automated detection and clock would sit, and be honest about which parts should stay exactly where they are — built by the engineers who would run the project, with your data staying in Australia.
Sources
- ASIC, Regulatory Guide 271: Internal dispute resolution (September 2021) — complaint definition at RG 271.27, acknowledgement at RG 271.52, maximum IDR timeframes at Table 2
- ASIC, RG 271 landing page
- AFCA, Insurance Brokers Code of Practice
- NIBA, Insurance Brokers Code of Practice and Code of Practice Review
- OAIC, Guidance on privacy and the use of commercially available AI products (October 2024)
- OAIC, APP 8: Cross-border disclosure of personal information
This article is general information about automating compliance processes, not legal or compliance advice. Your obligations depend on your licence, your book and your licensee's requirements.
