How TotalSettle uses AI with your data

When a handler ingests an engineer report, the PDF is parsed in the browser using PDF.js where possible. The plain text is then sent to the AI provider so it can extract the structured figures the platform needs (pre-accident value, retail, trade, salvage, category, repair estimate) along with the identifiers the settlement flow requires (vehicle registration, claimant name, postcode, email, phone, third-party insurer, reference).

Before the text is sent, it passes through a server-side redaction layer that replaces identifiable values (emails, phone numbers, NINO, UK driving licence, IBAN/card, vehicle registration, titled and labelled person names) with opaque placeholders such as NAME_1 or VRM_1. The original values are restored locally on the way back, into the structured case fields. The AI model itself never sees the underlying identifiers in the text path.

Where a scanned or image-only PDF defeats text extraction, the original PDF is sent to the AI provider so the fields can still be read. This fallback path cannot be redacted in-place. Every use of the fallback path is logged per case so it can be reviewed.

While the case is live, we hold only the extracted fields needed to run the settlement: vehicle registration, claimant name, postcode, claimant contact details, valuation figures, salvage and category, and the engineer's reference. A short plain-English summary of why the vehicle is a total loss is generated for the customer-facing portal. Raw engineer PDFs are not retained beyond extraction.

The moment the case completes (the claimant accepts), personal data is automatically scrubbed. Claimant name, email, phone, postcode, vehicle registration, engineer comments, finance company and the settlement link token are permanently removed. Uploaded evidence files are deleted from storage and related email logs are redacted. Any case still open 30 days after it was created is automatically anonymised in the same way and marked as expired, with an email warning to the operator 7 days beforehand.

SMS delivery logs record the send (status, timestamp and provider reference). The claimant mobile number stored against the case, and the mobile number and message link on any SMS delivery log, are cleared by the same automatic purge that clears the rest of the personal data (case completion, or 30-day expiry).

What remains after purge is an anonymised statistical skeleton (case status, decision, valuation figures, timestamps and reference) so operator reporting is preserved. Every purge is recorded in an audit entry with a timestamp and reason.

All data is stored in the European Economic Area (AWS eu-central-1, Frankfurt). Transfers between the UK and the EEA are covered by UK GDPR adequacy regulations. Row-level security in the database isolates each operator's data server-side on every request.

TotalSettle calls the AI model through the Lovable AI gateway, currently using Google Gemini. The provider does not retain your data and it is never used to train any model. Processing is performed in supported regions only.

AI outputs are reviewed by a trained handler before any settlement decision is communicated to a customer. AI is not used to make final settlement decisions.

Case data is logically isolated to your organisation using row-level security in the database. Handlers only see your organisation's cases. Access is enforced server-side on every request, not by the front-end.

The database is encrypted at rest and in transit. Settlement links are unique per case and verified against the registration and postcode on the case.

CaseFlow Automation Ltd (registered at 7-9 Macon Court, Crewe, CW1 6EA; ICO ZC013423) acts as Data Processor under your instructions. Your organisation is the Data Controller. A signed DPA, sub-processor list, and full DPIA are available on request.

This page is the customer-friendly summary. It is not a substitute for the DPA or your own privacy notices.