I have had the same conversation about insurance compliance so many times this year that I can predict the order the objections arrive in.
We will have to report more. The regulator will find things. We will not have the money to fix what surfaces.
Each one is delivered as though it were new. Each one is the same sentence underneath: we would prefer not to know.
What I find harder to accept is where the money goes instead.
What paper-based insurance compliance actually looks like
Most insurers, MGAs and brokers still run compliance on documents.
A risk and compliance manual, revised every few years. A compliance obligations register held in a spreadsheet, owned by one person, reviewed annually and reconciled against nothing. Attestations signed by managers confirming that controls operated, based on memory rather than evidence. Complaints in one system, claims in another, breaches in a third, and the detail of what actually happened sitting in email chains and in the heads of people who may not be here next year.
This is what people mean by fragmentation, and its practical effect is that no single view of the compliance position exists anywhere in the business.
The test is simple. Ask which obligations a product line touches, which controls should have caught late claims decisions last quarter, and whether those controls operated. In a paper environment each of those questions becomes a three-week project that returns an answer already out of date.
Why sample-based compliance audits miss systemic risk
The usual supplement to the manual is an external diagnostic or file audit. Thirty files sampled, policies read, a report bound and presented to a committee.
I spent much of my career producing exactly those documents, so this is not sneering. But a thirty-file sample tells you about thirty files. It is a point estimate taken from a portfolio that may run to tens of thousands of claims, and it is weighted toward whatever the sampling method happened to select.
Systemic issues in general insurance rarely announce themselves in thirty files. They show up as a recurring cause across product lines, a drift in handling times, or a pattern in one delegated authority that looks unremarkable in isolation. A sample sized for assurance is not sized to find those.
There is also a timing problem. Fieldwork, drafting and committee scheduling mean the findings describe a position that has already moved by the time anyone reads them.
A business that says it cannot fund remediation will sign that engagement off without blinking.
What changed: RG 271, GICOP and CPS 230 all assume detection
The paper model was not stupid. It was built for a world where information moved slowly, regulators assessed compliance largely by reading documents, and fragmentation was a physical fact of filing cabinets. Annual review cycles made sense in that world.
The obligations have since moved, and they now share a common assumption.
Section 912A of the Corporations Act requires licensees to do all things necessary to ensure financial services are provided efficiently, honestly and fairly, and to have adequate risk management systems. That is an obligation about operation, not documentation.
The reportable situations regime requires lodgement with ASIC within thirty calendar days of first having reasonable grounds to believe a reportable situation has arisen. A thirty-day reporting clock only works if the underlying detection happens in days.
ASIC Regulatory Guide 271 sets maximum internal dispute resolution timeframes for complaints, and expects licensees to identify and address systemic issues arising from complaints — which requires seeing complaints in aggregate and by cause, not one file at a time.
The General Insurance Code of Practice imposes claims decision timeframes, including the four-month standard decision period, and the current direction of the Code consultation moves it further toward contractual enforceability. That changes the consequence of a gap from criticism to liability.
APRA’s CPS 230 requires regulated entities to identify and manage their critical operations, tolerance levels and material service provider arrangements — which presupposes that an entity can describe its own processes and dependencies on demand.
Every one of those assumes a capability paper does not have: knowing, currently and specifically, what is happening inside the business.
Curium’s Compliance Platform connects obligations, controls, complaints and risk signals in one place, giving teams real-time visibility to identify and act on issues before they become systemic.
What real-time insurance compliance monitoring looks like
Curium is an insurance-native compliance, risk and claims management platform that connects regulatory obligations to the operational data insurers, MGAs and brokers already hold, so that risk signals, breaches and complaints are detected early and traced to the controls that were meant to prevent them.
In practice that means four things.
Data from real sources. Claims and policy systems, email traffic, documents and the conversations where decisions are actually recorded — rather than an annual questionnaire asking people to summarise their own performance.
Early signal detection. The complaint with the shape of a systemic issue rather than a one-off. The claims decision approaching a Code deadline. File handling that has drifted from what the procedure describes.
Connected context. Every signal linked to the obligation it engages, the risk that was supposed to describe the exposure, and the contract or delegated authority that determines who carries the consequence. Where no risk in the register describes the exposure, that absence is itself the finding.
Control traceability. The control that should have caught the issue, with evidence of whether it was performed, when, by whom and on what basis.
That is the difference between describing a control environment and operating one.
How a single complaint connects to obligations, controls and contracts
Take an ordinary sequence. A customer complains about how a claim was handled.
In the paper model, the complaint gets a log entry and a reference number, is closed within the required period, and the outcome is recorded. Nothing in that log tells you whether the same thing is happening elsewhere.
In Curium it becomes a different object. The complaint is read against the claim itself — decision dates, reserve movements, correspondence, and how long the file sat before it was assigned. If the timeline is running toward a Code decision deadline, that surfaces as a signal before it becomes a breach. The complaint is classified by cause rather than by product, so six complaints sharing a root cause across three lines appear as one issue rather than six unrelated tickets.
From there it connects outward to obligations, to the risk framework, to the delegated authority that determines responsibility where a third party did the handling, and to the control with the record of whether it operated.
When a director asks whether the issue is isolated, the answer takes minutes and rests on the underlying records — not on an assurance from the person being asked.
See how Curium can connect complaints to the underlying claims, obligations, controls and contracts in real time — Book a demo.
Will better detection mean reporting more breaches to ASIC?
In the first period, the number of identified issues rises. That is what a baseline looks like in a business that has never had one, and it should be planned for rather than pretended away.
But the objection runs two different numbers together. Most late breach reports are late because detection was slow, not because anyone decided to conceal. Lateness is frequently the more serious failing: the underlying issue may be modest, while eleven months of not noticing goes directly to whether the licensee understands its own operations.
Signals caught early stay isolated. Isolated issues are remediated before they compound into systemic ones, and systemic is the word that changes the scale of the consequence entirely.
Reported issues may rise for a period. Significant breaches fall. Those are not the same line on the graph.
What if we cannot afford to fix what we find?
This is the honest objection, and usually a true one.
Regulators and courts do not punish the existence of a problem. They punish the absence of a plan. A prioritised, board-approved remediation roadmap — with honest sequencing, resourcing constraints stated plainly, and the highest-harm items taken first — is itself a mitigating position and is read as evidence of an organisation that functions.
What cannot be produced at any price is credit for remediation that was never started, on an issue that was never identified, because the systems were never connected.
The arithmetic also runs against delay. What cannot be afforded today becomes existential once it has spread across a portfolio, accumulated customer detriment and acquired an enforcement multiplier. In compliance as in medicine, cost of treatment rises with stage.
Paper does not prevent problems in an insurance business. It prevents their detection, which feels identical from the inside until the day it does not.
The technology to know exists today. Not in a roadmap, not in a pilot. Today.
Use it.
Frequently asked questions
What is an insurance compliance obligations register? An obligations register is a structured record of the legislative, regulatory and code obligations that apply to a licensee, mapped to the products, processes and entities they affect. In most businesses it is a spreadsheet reviewed annually. Used properly it is a live instrument, connected to the risks, controls and contracts that give each obligation operational effect.
Why are sample-based compliance audits insufficient? A file sample tells you about the files sampled. Systemic issues typically present as recurring causes across product lines, drift in handling times, or patterns within a single delegated authority — none of which a small sample reliably detects. Sampling also produces findings that describe a position which has already changed by the time the report is presented.
Does earlier detection increase breach reporting to ASIC? Identified issues generally rise in the first period after detection improves, because no baseline previously existed. Significant breaches tend to fall, because issues are remediated while still isolated rather than after they have become systemic. Late reporting — which is usually caused by slow detection — is itself frequently treated as the more serious failing.
How does compliance technology support RG 271 and GICOP obligations? Both require timeframes to be met and systemic issues to be identified from complaints and claims. That depends on seeing complaints and claims in aggregate, classified by cause, with decision timelines monitored against deadlines as they approach rather than after they pass.
What makes insurance compliance different from general-purpose GRC? Insurance obligations are specific, they change, and the distinctions matter operationally — whether a code obligation applies directly or flows through a service supplier arrangement, how delegated authority allocates responsibility, how claims handling timeframes interact with dispute resolution. General-purpose GRC platforms treat these as configuration. An insurance-native platform treats them as structure.
Implementation notes
Verify before publishing: the thirty-day reportable situations timeframe, the four-month GICOP claims decision period, RG 271 IDR timeframes, and the current status and commencement dates of CPS 230 and the GICOP consultation. These are stated at a level of generality that should hold, but they are the sentences a regulator-facing reader will check first.
Schema: mark up as Article with author and organisation, and the FAQ section as FAQPage. Both improve retrieval and give LLMs clean question-answer pairs to lift.
Internal links: obligations register product page, claims management page, any existing GICOP or RG 271 commentary, the Risk & Compliance Summit page.
External links: ASIC RG 271, the reportable situations guidance, the General Insurance Code of Practice, APRA CPS 230. Outbound links to primary regulatory sources materially improve topical authority.
Retrieval note: each H2 is written as a question or a query a reader would actually type, and each section answers it within its own first two sentences so the passage stands alone when lifted out of context.
Author:
Tetiana George, CEO of Curium, Co-Chair of Insurtech Australia and member of ASIC Digital Finance Advisory Committee. LinkedIn Profile.