Integration
intactly reads from your claims system and writes back obligations, findings and reports. It does not replace a policy administration system, it does not become the system of record, and it does not require you to migrate anything.
Three flows. Claims and documents in, obligations and findings out, reports on demand.
The integration surface is deliberately small because the alternative - a platform that wants to own the claim - is a two-year programme nobody approves. intactly needs enough of the claim to evaluate it and enough of the file to read it. It does not need your policy administration system to change.
| Flow | Direction | Typical transport | Cadence |
|---|---|---|---|
| Claim events | Your system → intactly | Webhook, message bus, or batch file | Near real time, or nightly |
| Documents | Your system → intactly | Pre-signed object storage, or content API | On attach |
| Policy & product | Your system → intactly | API on demand, or reference extract | On claim open, then on change |
| Obligations & findings | intactly → your system | Webhook, or work queue API | On change |
| Compliance reports | intactly → you | API, or scheduled delivery | On demand, or on close |
Everything inside the boundary runs in Australian regions. No claim content crosses a border, including at inference time.
Pick by what your claims system can already do, not by what is technically ideal.
Your claims system emits an event when something happens on a claim. intactly evaluates and pushes changed obligations back. Lowest latency, and the only pattern where the queue is genuinely live.
Guidewire messagingKafka / Event Hubs Azure Service BusAWS EventBridgeWebhook
A nightly or hourly extract of claims and events. Perfectly workable: obligation clocks run in days, not seconds, so a nightly cadence loses very little. This is the right first step for a legacy or mainframe claims system, and it is how most pilots start.
SFTP file dropS3 / BlobODBC extractFivetran / ADF
intactly polls your claims API on a schedule. Useful where you cannot emit events and cannot schedule an extract, but it puts read load on your system and is the least preferred of the three.
Rather than replicating the work queue in your claims UI, embed the intactly claim view as an iframe or a Guidewire page fragment, authenticated by the same SSO session. Fastest route to a handler actually using it, because it does not require a change to your claims UI release cycle.
| Model | Where it runs | Suits | Trade-off |
|---|---|---|---|
| Managed | intactly-operated, ap-southeast-2 |
Most insurers and scheme agents | Fastest to value. You take a material service provider under CPS 230. |
| Customer tenancy | Your AWS or Azure account, Australian region | Where data must stay under your own account | You own the infrastructure and its patching; we deploy into it. |
| Engine-only | Your infrastructure, no network egress | Scheme agents with the strictest data rules | The obligation and coverage engines are dependency-free and run anywhere. Document intelligence needs more. |
The engine-only option exists because of a deliberate build decision: the obligation, coverage and integrity engines have no third-party dependencies and make no network calls. They can be reviewed line by line and run inside an air-gapped environment. That was a constraint chosen for APRA's third-party AI risk expectations, and it turns out to be an unusually good answer to a procurement question.
A claim and event extract for a single line of business. No writes anywhere, no change to your claims system. Produces the first breach-ranked queue, typically within two weeks of receiving data.
Your legal or compliance function verifies each obligation rule against the primary instrument. Every rule ships unverified and is labelled as such until this is done. This is a gating step, not an optional one.
The engine runs against 90 days of closed claims. Projected breaches are compared to known outcomes, thresholds are tuned, and integrity typologies are enabled or disabled against your own book.
Obligations flow to handlers, in your claims UI or in the intactly view. This is the point at which the compliance position starts improving, because it is the point at which someone works it.
Document ingestion, integrity examination and coverage assessment against the PDS. Sequenced last because it is the heaviest lift and depends on document access that usually needs its own approval.
Compliance reports, the CPS 230 material service provider pack, and the APP 1 automated decision disclosure generated from what the system actually does.
Honest estimates of your effort, not ours. These are the numbers to take to a steering committee.
| Task | Your team | Typical effort |
|---|---|---|
| Claim & event extract | Claims IT / data | 3–10 days, depending on whether an extract already exists |
| Event mapping workshop | Claims technical + IT | 1–2 days. Mapping your statuses to the canonical event vocabulary is the real work of integration. |
| SSO & provisioning | Identity | 1–2 days (SAML or OIDC, plus SCIM) |
| Rule verification | Legal / compliance | The gating item. Budget properly - it is a legal review, not a config task. |
| Document access | Records / IT security | Highly variable. Often the longest approval, so start it early. |
| Security review | Risk / CISO | Pack is pre-built. See Security & compliance. |