At Toyota Assurances, the underwriting file arrives captured and checked

We iterated with the Koncile teams to capture complex information inside the batches of our underwriting files. They supported us until we reached the best extraction quality, with no errors after human verification on samples. We then send the data back to our systems automatically via API.
^{Olivier Jannin, sales director, Toyota Insurance}

The underwriting document batch

Toyota Assurances insures Toyota, Lexus and Kinto customers in France. Behind the brand, the insurer is AND-E, Aioi Nissay Dowa Insurance Company of Europe, a member of the MS&AD group: 60,000 auto policies in its portfolio, 20,000 new contracts each year.

Every underwriting case begins the same way. The customer or the dealership sends their documents to a dedicated management inbox, in bulk, usually merged into a single ten-to-fifteen-page PDF, with no order and no table of contents.

Each type carries its own traps, and it is this variety that makes the case difficult.

• A vehicle registration document (carte grise) where the owner and co-owner are misaligned, and where one of the two is a financing company rather than a person.
• A driving licence that may be in the old pink format or the new one, with up to three drivers, and whose date of issue and expiry date appear on two different lines on the back.
• An identity document that may be a national ID card, a passport or a residence permit, and must be returned under the same set of fields.
• An insurance record statement (relevé d'information) issued by any insurer, with its own layout, around twenty data points to extract, and sometimes two statements in the same batch.
• A name that may include a maiden name and a married name, to be cleanly separated so it can be used.
• A contract number that appears on none of the documents and is found in the accompanying message.

What Koncile checks on each batch

Extraction is only half the work. A case handler never simply re-typed fields: they process a file, check that it is complete, that each document is valid, and that all of them refer to the same person and the same vehicle. The model built with the Toyota Assurances teams applies these checks to every batch, and their results flow back through the same channel as the data.

Completeness and typing

Each page is assigned a type, including when it was not planned in the model: it is then set aside rather than ignored. Duplicates are detected and discarded. An alert is triggered when the batch contains several identity documents, or more than two insurance record statements.

Document validity

Expiry dates of the driving licence and the identity document, start and end dates of the insurance record statement's coverage, the roadworthiness test shown on the registration document, the actual presence of a signature on the SEPA mandate and on the transfer certificate.

Authenticity

A registration document struck through and marked "sold" is flagged. A certificate of passing the driving test, sent while waiting for the final licence, is identified as such and is not treated as a licence.

Consistency across documents

The name of the registration document holder is checked against that of the bank details (RIB), the licence and the insurance record statement; the registration number against that of the statement. This is where a file's compliance is decided, and no document-by-document reading can achieve it.

Koncile lets us systematically compare and check the consistency of our various documents against one another.
‍^{Ghislain Averty, COO, AND-E}

The email is part of the file

The subject, body and sender of the message are transmitted with the batch and analysed on the same footing as the documents. This is how the contract number, almost never present on a registration document or bank details, is found in the message and attached to each document, applying the specific formalism of each distributed brand, Toyota, Lexus or Kinto.

It is also what makes it possible to qualify the submission itself. The same customer sends two messages one minute apart: the first is compliant, the second is not. Without the email context, neither can be processed correctly.

Alerts flow back with the data, in the same call. 87% of batches are processed end to end with no human intervention. The handler no longer opens every file, they open the 13% that require a decision.

What the handler used to do, and no longer does

Applied to the 20,000 new contracts handled each year, the saving exceeds 4,000 hours of data entry and checking, or more than two full-time equivalents returned to the business. Processing is parallelised: a thousand batches sent at once are processed in a few minutes, with no queue.

Five weeks, and a fully custom model

None of the above comes off the shelf. Every field, every reading rule and every checkpoint was defined by the management teams themselves, in natural language, with no development and no model to train. The business nomenclature became the shared reference, and the tool bent to it rather than the reverse.

1. Nomenclature defined by the underwriting and management department, which becomes the reference standard.
2. Natural-language configuration: the handlers write their own extraction rules and checkpoints, and adjust them without going through anyone.
3. API integration completed in four days.
4. Acceptance testing on real documents, from the batches actually received.
5. Continuous extension of the scope to new document types and new checks, with no new project.

The insurance record statement is our riskiest document: a lot of information, and above all no room for error. It is now handled flawlessly.
^{Thierry Efengola, head of the underwriting and contract management department, Toyota Assurances}

The scope has grown from seven to nine document types since going live, with rules written directly by the management teams, in a few hours and with no technical involvement.

We now check by exception. On a standard batch, the data comes in compliant and we only step in on the cases the tool flags.
^{Yasmine Bidois, operations and management group lead, Toyota Assurances}

What's next: document fraud detection

Building on what works today, a multi-layered fraud detection project is under development with the Toyota Assurances teams. It focuses first on the insurance record statement, the most sensitive document in the underwriting file and the easiest to tamper with: a modified bonus-malus coefficient, a shifted cancellation date, an erased claim.

Metadata

Editing traces in the PDF file, authoring software, modification history, internal date inconsistencies.

Visual integrity

Font and alignment breaks, recomposed areas, overlays, local alterations of the page.

Business consistency

Plausibility of the coefficient given seniority and claims history, continuity of coverage periods, agreement with the other documents.

Each document is assigned a risk level, low, medium or high, reported alongside the rest of the data. The handler keeps the decision; the tool tells them where to look.

Do you process batches of supporting documents?

Underwriting, claims, KYC, financing files. Send us your real documents: we configure your fields and your checks, and you judge on your own files. talk with an expert