ClaimsIQ is a claims intelligence platform. It exists to help handlers run cleaner claims, give managers a clearer view of the work, and produce a defensible audit trail. None of that requires storing the customer's identity.
This isn't a marketing posture. It's an architectural commitment. The PII layer runs across every input on every tool, redacting names, phone numbers, emails, full addresses, account numbers, NHS numbers, NI numbers, dates of birth, vehicle registrations, and other identifiers before they reach the canonical store. Where a handler types "Mrs Patel called from 07700 900123 about her flat at 14 Acacia Road, M14 1AE", the platform stores "[NAME] called from [PHONE] about [ADDRESS], [POSTCODE_TRIMMED:M14]". The tools work just as well on that record. The customer remains a person to the handler, not a data point in a system.
| Type | Examples | Status |
|---|---|---|
| Names (with title) | Mrs Patel, Mr O'Brien, Dr Williams | Redacted to [NAME] |
| Names (first + surname) | James Smith, Sarah Williams | Redacted to [NAME] |
| Phone numbers | UK and international | Redacted to [PHONE] |
| Email addresses | Any format | Redacted to [EMAIL] |
| Street addresses | 14 Acacia Road, 23 High Street | Redacted to [ADDRESS] |
| NHS numbers | 485 777 3456 | Redacted to [NHS_NUMBER] |
| National Insurance numbers | AB 12 34 56 C | Redacted to [NI_NUMBER] |
| Bank details | Sort code, account number, IBAN | Redacted |
| Card numbers | 16-digit primary account number | Redacted to [CARD_NUMBER] |
| Dates of birth | Any format following DOB / born | Redacted to [DOB] |
| Driving licence numbers | Standard UK format | Redacted |
| Vehicle registrations | AB12 CDE | Redacted to [VEHICLE_REG] |
| Field | What we keep | Why |
|---|---|---|
| Postcode | Outward code only by default (M14, not M14 1AE) | Regional cost benchmarking and accommodation searches need geography. Full postcodes only stored where a tool's function genuinely requires it (CostIQ regional rates, AAIQ accommodation search) — and they remain server-scoped, never shared across teams. |
| Cause of loss | Standard categories (EoW, Fire, Storm, Subsidence, etc.) | Drives every downstream tool. Not an identifier. |
| Severity | Banded (Minor, Moderate, Significant, Severe) | Drives reserve and routing logic. |
| Property type | Banded (Detached, Semi-detached, Flat, Commercial, etc.) | Drives cost benchmarking and accommodation logic. |
| Reserve estimate / claim cost | Numeric values | The financial picture of the claim. |
| Vulnerability flag | Category only (cognitive / financial / digital / sensory / capacity / language) | Required for FCA Consumer Duty compliance. Specific medical conditions are not captured. |
| Cover position | Sections engaged, exclusions in play, decline rationale | The senior's read on the claim. Captured against wording references, not against a person's name. |
| Dates | Loss date, FNOL date, milestone dates | The timeline of the work. |
| Tool outputs | Verdicts, scores, findings | What the AI flagged, what the handler decided. |
Handler notes are where personal data leaks most easily — a handler under time pressure types "Mrs Patel said her son James has just left for university". The platform handles this in two layers:
Live, while typing. An amber strip below the field flags any detected identifier. Handler can manually redact at the click of a button.
On commit (blur or save). If any identifier remains, it's automatically redacted in place. The textarea visibly updates so the handler can see what was kept.
Pasted notifications — broker emails, portal submissions, eFNOL exports — get the same treatment before reaching the AI extractor or any storage layer. A green confirmation banner shows what was redacted.
Health information (a vulnerability flag pointing at cognitive impairment, or a customer mention of mental health affecting their handling of the claim) falls under Article 9 of UK GDPR. ClaimsIQ captures this as a category — "cognitive" rather than "Alzheimer's diagnosed 2023" — never as a specific medical detail. The handler should record any specific clinical detail in their primary claim system if needed; ClaimsIQ holds only the category needed for proper claim handling under Consumer Duty.
Lawful basis for processing health-category data on insurance claims: Article 9(2)(f) — necessary for the establishment, exercise or defence of legal claims.
ClaimsIQ uses Supabase (PostgreSQL on AWS Ireland) for the canonical store, plus the handler's browser localStorage as a working cache. All claim data is scoped to the handler's sub-team via row-level security; cross-team visibility requires explicit role-based access (manager, lead, analyst).
AI processing for tools that use it (FNOLIQ written extraction, CostIQ benchmarking, hub AI Review) routes through Anthropic's API. The redacted text is what reaches the model — direct identifiers are stripped before any external call.
The PII patterns are conservative — false positives (a legitimate piece of text mistaken for an identifier) are preferable to false negatives. If you spot a case where personal data leaked through anyway, the handler-side migration tool (ClaimsIQPIIMigrate.run({dryRun:true}) in the browser console) sweeps your existing claim records and reports anything that needs cleanup. For platform-level concerns, the route is via your sub-team admin — they have visibility into the audit log and can escalate.