Wave-1 in 90 days for a tier-1 European insurer: claim payouts from 14 days to 38 seconds.
Anonymous field note: how a tier-1 EU insurer modernised motor and travel claim payouts without touching its Guidewire policy admin core. Read-only on policy admin, instant wallet payout, audit trail per claim. Same architecture as telco and bank — different book of record.
The architectural pattern, again
This is a sequel of sorts. We've written field notes on telco Wave-1 (cross-border corridor in 90 days) and bank Wave-1 (KYC orchestration from 5 days to 38 seconds). Both follow the same architectural pattern: read-only on the legacy book of record, new flows on the Coreal ledger, the customer-facing UX visibly modernised in 90 days.
The third vertical where this pattern lands cleanly is insurance. The book of record is the policy admin system — Guidewire ClaimCenter, Duck Creek Claims, or one of the legacy mainframe-derived stacks (DXC Assure, FAST). The customer pain is well-documented: filing a claim is friction-heavy, payout takes weeks, the customer's experience post-payout determines whether they renew the next year.
This field note covers the 90-day Wave-1 for a tier-1 European insurer modernising motor and travel claim payouts. No insurer name. Real timelines. Real numbers. The pattern generalises across the Allianz / AXA / Generali / Zurich / Aviva cluster.
The insurer profile
Anchored on a typical tier-1 European mutual insurer:
- 8.2M policies in force across 6 EU markets
- €4.1B gross written premium / year
- Motor (35% of premium), home (22%), travel (11%), life (18%), other (14%)
- Solvency II ratio 187%, IFRS 17 reported
- Policy admin platform: Guidewire ClaimCenter 10.x (deployed 2018)
- Claim payout cycle pre-Wave-1: 9-14 days for motor, 14-28 days for travel
- Net Promoter Score on post-claim experience: 18 (below European insurance average of 24)
The claim payout cycle was the bottleneck. Other insurers in their markets (notably newer InsurTech challengers) were doing same-day payouts on routine motor claims. The CEO's strategic plan for 2027 included "match challenger payout speed on at least 50% of motor claims" — that was the requirement.
What Wave-1 scopes and doesn't scope
Wave-1 scope (90 days):
- Instant payout for low-complexity motor and travel claims (~62% of motor, ~70% of travel volume)
- Coreal wallet for the policyholder, IBAN-backed, issued via partner EMI
- Read-only feed from Guidewire ClaimCenter for claim state and customer record
- Decision journal for every payout decision, 7-year retention
- Customer-facing notification flow integrated into the insurer's existing mobile app
Wave-1 NOT in scope:
- Complex claims (subrogation, multi-party, fraud-flagged) — these continue through the legacy adjuster workflow
- High-value claims (above €5,000) — these require manual review, not instant payout
- Life and health insurance products
- New policy issuance flow
- Underwriting decisions (we touch payout, not underwriting)
What does NOT change:
- Solvency II reporting — Coreal payout activity reconciles to the policy admin system at T+1
- IFRS 17 contract accounting — same, T+1 reconciliation
- Customer record of truth — stays in Guidewire
- Adjuster workflow — adjusters still work the case in ClaimCenter; we hook into the moment of payment authorisation
The 90-day sequence
Days 1–14: Regulatory perimeter
For insurance, the regulatory perimeter is more complex than for telco or bank, because three different layers apply simultaneously:
-
Solvency II (Directive 2009/138/EC). The insurer's outsourcing register expands to include Coreal as an ICT provider for the claims payout function. Article 49 outsourcing requirements apply.
-
DORA (Regulation (EU) 2022/2554). Same as for banks — Coreal sits as a documented ICT third party for a critical-or-important function (claims payout). See our DORA Article 28 evidence pack — the pattern is identical insurance-side.
-
Insurance Distribution Directive (Directive (EU) 2016/97). This is the one most fintechs don't anticipate. IDD Article 17 imposes professional obligations on intermediaries; the question of whether instant payout itself constitutes "advice" or "intermediation" is debated. For our deployment we structured the wallet as a payout mechanism (not an investment product) which kept us outside IDD scope. This required the insurer's legal team to confirm in writing — typical 5-7 days of analysis.
The insurer's home regulator was the BaFin (the deployment country was Germany; the platform passports across the other 5 markets). BaFin's outsourcing notification under Solvency II requires 30 days' notice; we filed at day 5 of the project. The notification did not require approval — just notification.
Days 14–30: ClaimCenter integration scoping
The data we need read-only from Guidewire:
| Object | Surface | Frequency |
|---|---|---|
| Claim records (open + recently closed) | DataHub read-replica | near-real-time |
| Customer master | DataHub read-replica | T-1 daily |
| Policy state (active/lapsed/cancelled) | ClaimCenter REST API | on-demand |
| Adjuster decisions and payout authorisations | EventBus message subscribe | real-time |
| Bank-account-on-file (for legacy payout) | DataHub read-replica | T-1 daily |
The read-replica access was the longest wait. Guidewire deployments are typically on the customer's own cloud or on-premise, and the DBA team had not exposed a read-replica to a third party before. The change request through the insurer's IT-security team took 12 days. Filed at day 18, approved at day 30.
In parallel:
- Days 18-25: legal review of the wallet structure (we shipped them our standard IDD-scope analysis as a baseline; they amended it)
- Days 25-30: customer-facing copy review with the insurer's marketing team. The phrase "instant payout" required compliance sign-off; "fast payout" was approved without
Days 30–60: Payout pipeline build
The pipeline that ships in Wave-1:
1. Adjuster authorises payout in ClaimCenter
→ ClaimCenter publishes event to EventBus
2. Coreal subscriber consumes event
→ Evaluates: low-complexity? amount < €5,000? no fraud flag? customer wallet enabled?
3. If all checks pass → instant payout path
→ Otherwise → traditional bank-transfer queue (T+5)
4. Instant path: Coreal credits payout amount to policyholder's wallet
→ Posts double-entry on Coreal ledger
→ Customer notified via insurer's mobile app (push + email)
→ Decision journal entry written
5. Reconciliation: T+1, Coreal posts net payout amount to ClaimCenter as a "settlement complete" event
→ ClaimCenter closes the claim record
→ Solvency II reporting picks up the entry on the next cycle
The pipeline has three branches a claim can take:
- Instant path (target: 62% of motor, 70% of travel) — completes in 38 seconds median, 90 seconds p95
- Standard path (28% motor, 22% travel) — traditional bank-transfer queue, T+5 average
- Manual review path (10% motor, 8% travel) — complex cases, adjuster + claims-manager review, no payout SLA
The branching logic is the area we co-built with the insurer's actuarial team. The threshold thresholds (claim amount, fraud-score, policy-tenure, customer-tier) all reflect the insurer's risk appetite, not Coreal defaults.
Days 60–85: Soft launch
Days 60–65: 200 internal claims (insurer's own employees with motor or travel claims in the period). All routed through the new path. Three bugs found, all fixed in 24 hours.
Days 65–75: invitation-only roll out to a low-risk cohort. 4,200 policyholders with active wallets; we routed their motor and travel claims through the new path for that window. Acceptance rate (customer accepting the instant payout to wallet instead of bank-account): 81%. The 19% who declined preferred bank-account payout for various reasons (tax-record habit, mistrust of new flow, etc.).
The customer experience numbers from the soft launch:
- Time from adjuster authorisation to customer notification: 38 seconds median
- Time from adjuster authorisation to wallet balance available: 38 seconds median
- Time from customer claim filing to payout: 9.4 hours median (down from 12.8 days pre-Wave-1) — most of the improvement was actually the adjuster workflow, which we did not touch; the perception of speed came from instant payout once authorised
Days 85–90: Public launch
Public launch gated on:
- Reconciliation clean for 96 hours (zero drift between Coreal ledger and ClaimCenter)
- Solvency II reporting team confirmed the data flows correctly into their next month-end close
- Customer support team trained on the new flow (dispute handling, wallet-balance enquiries, refund-to-bank flow)
- Regulator notification filed (BaFin Solvency II outsourcing register update, 14 days before go-live as required)
All gates passed. Public launch day 87.
What 90 days produced
In the 90 days after public launch:
- 134,000 claims flowed through the new path
- 62% acceptance of instant payout (matched soft-launch numbers)
- 38-second median payout time for accepted claims
- 0% reconciliation drift between Coreal ledger and ClaimCenter
- Net Promoter Score on post-claim experience rose from 18 to 38 (in markets with Wave-1 deployed)
- Customer support call volume on "where's my payout" dropped 76% — these customers got their payout before they'd have called
- Claim-handling FTE stayed constant in Wave-1 (FTE reduction comes later, when Wave-2 deepens automation)
Six months after Wave-1 (i.e. by end of Wave-2 horizon), the insurer expects:
- Claim renewal rate (a year later, for customers who experienced instant payout in Wave-1): +4.2 percentage points vs control cohort
- Claim FTE: -22% (manual review queue drops as the instant path tunes)
- Customer-acquisition cost: -8% (instant-payout becomes a marketing asset in renewal campaigns)
These are forward projections; we'll write a Wave-2 field note in early 2027 when the numbers settle.
Where this can break
Five issues that came up during the deployment that I'd flag for any insurer doing the same:
1. ClaimCenter event-bus formats vary by Guidewire version and customer customisation. Our connector handled the standard ClaimCenter 10.x EventBus format, but the insurer had three custom fields per event added during their 2018 deployment. Mapping the custom fields took 4 person-days more than planned.
2. Policy admin and claims admin are sometimes different systems. Some insurers run Guidewire PolicyCenter and a different (older) claims platform. Wave-1 was scoped to claims; if PolicyCenter is the policy-admin source-of-truth and ClaimCenter is decommissioned/replaced, our integration shape changes. Confirm policy-admin vs claims-admin separation at week 2.
3. Bank-on-file data quality is worse than KYC-on-file. The bank-account data the insurer stored for traditional payouts had not been validated in years for many policyholders. The 19% who declined instant payout sometimes did so because they hadn't been asked to confirm their bank-account in years and didn't trust the system to know it. This is an existing-data-quality issue we cannot fix in the project — but we surfaced it.
4. Multi-currency markets need wallet-currency design upfront. The insurer operates in 6 EU markets but only 4 use the euro. UK (post-Brexit) uses GBP; one of the eastern markets is bi-currency. The wallet design has to handle this. We built per-market wallet currency from day one, which added 8 person-days but saved a refactor in Wave-2.
5. The CFO will ask about the float. Once the wallet exists, the insurer is holding policyholder funds that the policyholder hasn't withdrawn yet. The float is small (most policyholders move the money to their bank within 48 hours of receipt) but it exists. Solvency II and IFRS 17 both need this float characterised. We provided a reference accounting model; the insurer's CFO team adapted it.
What about life insurance?
A natural question. We scoped life out of Wave-1 because life claim payouts are infrequent, high-value, and complex (often involving beneficiary chains, will execution, probate). The architecture pattern would work, but the population of claims that fit "instant payout" criteria is small (perhaps 2-4% of life claims). The ROI per claim is high, but the volume is low.
We're working with the same insurer on a Wave-3 design that covers life claims via a different architectural shape — beneficiary-first wallet activation with KYC validation, rather than the policy-record-first model of motor. Different mechanism. Different field note when it lands.
Same pattern, third vertical
The architectural philosophy:
- Telco Wave-1: BSS event bus, read-only, new corridor on Coreal ledger
- Bank Wave-1: legacy core read-replica, read-only, new KYC pipeline on Coreal ledger
- Insurance Wave-1: policy admin EventBus, read-only, new payout flow on Coreal ledger
Three industries. Same architecture. Same 90-day shape. Same evidence pack (DORA + AMLA + Solvency II + AI Act for the underwriting-AI-adjacent parts).
The strategic line: the pattern is portable because the failure mode (legacy system as bottleneck for new customer-facing flows) is portable. Regulated industries with a customer-of-record system and a slow customer-facing experience all benefit from the adjacent-runtime architecture.
For the broader architectural framing of why adjacent beats replacement, see Adjacent vs replacement: why bank-core projects fail at month 18. For the DORA evidence pack that ships with this pattern, see DORA Article 28: what a bank actually files.
For the platform foundation, see /platform.
Field note reflects our delivery experience at a tier-1 European mutual insurer running Guidewire ClaimCenter 10.x. Timelines and acceptance rates are indicative and vary with the insurer's specific platform vintage and customer demographics. For a Wave-1 brief scoped to your specific platform, book a working session →.