Products Lemma APIProof issuance & verification platformTrust402Delegate to agents, and transactSealSign-in for the agent era — no keys handed over
Use cases Manufacturing & Critical InfraInspection Record AssuranceFinance & FinTechCounterparty Record VerificationPublic SectorCertificate-less ProceduresHealthcareQualified Worker AssuranceProcurement & Supply ChainSupplier Credential MonitoringMedia & ContentContent AuthenticityService & RetailCross-group IdentityAI Adoption (cross-industry)AI Run GovernanceDevelopers & Agent OpsAgent Authority Control ▸ Browse the use-case index
Pricing
Resources Critical BriefThe frontier of AI × trustBlogThinking and implementation notesDocumentationAPI & specsVerification CenterReal verification & issuance countsAbout usFRAME00, Inc.ContactSales & press inquiriesGlossaryDefinitionsFAQFrequently asked questions
Dashboard ↗ JA
Home / Critical Brief / No. 151
No. 151 Critical Brief · Verifiable Origin

TOPPAN: During a manual send, a list of 177,426 Sompo Japan policyholders slipped into another insurer's ZIP and went out (insurance-premium deduction certificate service)

nothing checks that the contents match the recipient before the send

177,426people
Sompo Japan policyholders in the list sent to the wrong insurer (may include duplicates). Kana names, policy numbers and more
17:15
On the day of the mis-send (2026-09-01), when the receiving insurer queried the General Insurance Association of Japan
28days
From the mis-send to disclosure (09-29)
CountryJapan
Incident date2026-09-01
Published2026-10-14
Revised v2.0 · 2026-10-21
AuthorsLemma Critical Team
Contents
  1. 01TL;DR
  2. 02What happened
  3. 03Timeline — disclosure and response
  4. 04Why it wasn’t stopped
  5. 05How to counter this
  6. 06Sources

TL;DR

  1. 01What happened

    On September 1, 2026, while running the insurance premium deduction certificate service it operates for non-life insurers, TOPPAN sent a list of 177,426 Sompo Japan policyholders to another insurer by mistake. With ZIP files for several insurers in the same folder, a drag-and-drop slip put Sompo Japan’s file inside another insurer’s ZIP. TOPPAN confirmed it was not an outside attack.

  2. 02Why it was hard to tell

    The ZIP’s contents were not re-checked before sending. Only the operator’s actions and eyes decided which company’s data went to which recipient.

  3. 03The missing layer

    The receiving insurer noticed the same day and queried the General Insurance Association of Japan. By then, though, the list had already left the company. What failed was the layer that checks, separately from the operator’s actions and before the send, that the contents match the recipient.

What happened

Service
Operations for the insurance premium deduction certificate service, which 14 non-life insurers outsource to TOPPAN (per Sompo Japan).
What was mis-sent
A list (CSV) of Sompo Japan policyholders who do not need a postcard certificate, sent to one other insurer.
Count and fields
177,426 people (may include the same policyholder more than once). Name in kana, policy number for deduction purposes, and a work ID. No kanji names, addresses, dates of birth, phone numbers, emails, card or bank details, or My Number.
Cause
A manual operating slip and a gap in the checking procedure. With several insurers’ ZIPs in the same folder, a drag and drop copied Sompo Japan’s ZIP into another insurer’s ZIP, and the contents were not re-checked before sending (per TOPPAN).
At the recipient
TOPPAN says the data was promptly deleted at the recipient and no leak to third parties has been confirmed. Sompo Japan says it contacted the recipient and confirmed deletion, and no secondary leak or misuse has been confirmed.
Other mix-ups
TOPPAN confirmed this was the only one in this delivery run.

Glossary
Premium deduction certificate service — A shared service that issues non-life insurers' tax deduction certificates. TOPPAN runs it for 14 insurers.
Drag and drop — Grabbing a file with the mouse and dropping it elsewhere. Drop it in the wrong place and the file ends up in an unintended folder or ZIP.

Exhibit 1The chain of events, as far as disclosed

The point to stop it was ③. Checking, separately from the operator's actions, that the ZIP's contents belonged to that recipient would have stopped the send.

TOPPAN
1
Packs each insurer's list into a ZIP and puts them in one folder

Several insurers' files.

Operator
2
A drag-and-drop slip puts Sompo Japan's file in another insurer's ZIP

2026-09-01.

Operator
3
Sends it by file transfer without re-checking the contents

Delivered as the other insurer's.

Receiving insurer
4
Notices the mix-up and queries the industry association

Same day, 17:15.

Timeline — disclosure and response

  • The mis-send happens during a manual transmission. At 17:15 the receiving insurer queries the General Insurance Association of Japan about another insurer’s data mixed in.
  • The association asks TOPPAN to investigate, and the mix-up is identified. TOPPAN stops the file transfer service.
  • TOPPAN and Sompo Japan disclose on the same day.

Facts rest on TOPPAN’s and Sompo Japan’s disclosures (both primary). How it happened, the cause and the measures appear only in TOPPAN’s. The count and fields match in both. Statements on deletion and leaks are kept in each company’s own words.

After disclosure

  • TOPPAN: Will attach files only through “choose file”, add a checker separate from the operator to review every step, and match attachment size and timestamps against the source data. As a lasting fix, it will systematise the sending process.
  • Sompo Japan: Is notifying affected policyholders individually by registered email, and by letter where no email is registered. It will press TOPPAN to carry out the measures and strengthen oversight of contractors.

Why it wasn’t stopped

This case was not an outside attack, nor only one operator’s carelessness. Only the operator’s actions and eyes decided which company’s data went to which recipient, and nothing matched contents against recipient before the send.

The core of this case
Only the operator's actions and eyes decided which company's data went to which recipient, and nothing matched contents against recipient before the send.
Exhibit 2The detection–proof gap

Proof works before sending; detection works after the recipient notices. Once sent, the data has left your hands.

Proof layer · absentBefore sending, match the contents to the recipient
The gap177,426 records
already outside
Detection layer · noticed by recipientThe recipient spots the mix-up and asks
STEP 1
Mixed into a ZIP
STEP 2
Sent unchecked
STEP 3
Recipient notices
STEP 4
Sending stopped

Detection worked: the receiving insurer noticed the same day and queried the association. But it noticed after the send, and although “the operator sent this ZIP to this recipient” and “this ZIP’s contents belong to this recipient” are separate facts, the first alone let the send through. That distance is the detection–proof gap, and it is a structural one.

The same structure appears in Tokyo Metropolitan Housing Supply Corporation’s address labels (no one other than the person who made them caught that the labels no longer matched the source list before shipping).

How to counter this

Before sending, match the contents to the recipient, separately from the operator’s actions. Adding checkers still relies on human eyes. Record “whose data is this” for each file when it is created, match it automatically against the recipient just before sending, and don’t send what doesn’t match.

Industries and operations to watch

IndustryFinance & FinTech
Insurers and others that handle large numbers of policyholders and outsource document production and mailing. At the contractor, several companies’ data sits in front of the same operator.
OperationSending & delivery
Manually sending files split by client. A wrong file name or location mixes in another company’s data.

Do today’s controls close it?

ControlThis caseWhy
Operator’s check before sendingIneffectiveThe ZIP’s contents were not re-checked before sending (per TOPPAN).
A checker separate from the operatorPartialMore chances to catch errors, but still relies on human eyes.
Matching size and timestampsPartialIt can catch a whole ZIP slipping in, but does not directly show the contents belong to that recipient.
Systematising the sending processPartialLess manual work, but without matching contents to recipient, the error just moves elsewhere.
ControlsWhat is needed
  1. Record whose data each file is when it is created. Make the owning company identifiable down to each file inside a ZIP.
  2. Match contents to recipient automatically just before sending. Register which companies’ data each recipient may receive, and stop sends that include non-matching files or files of unknown owner.
  3. Record what was matched before sending. Keep the match results and what was sent, separately from the operator’s activity log, in a form that can later be shown to a third party: in other words, as proof.
CheckChecklist

Three things to confirm in your organisation about sending data per client

  • Are files split by client handled by the same person in the same place?
  • Before sending, are the contents matched to the client by means other than human eyes?
  • If a contractor does such sending for you, do you know its checking procedure?

Note: if the range registered for a recipient is itself wrong, a wrong send still goes through. Until a matching mechanism is in place, human checks such as a separate checker have to fill the gap.

Sources

  1. Primary, company disclosureTOPPAN Notice on data mis-sent in the insurance premium deduction certificate service it operates2026-09-29, Japanese · holdings.toppan.com/ja/info/toppan_info20260929.pdf
  2. Primary, company disclosureSompo Japan Notice on data mis-sent by a contractor in the insurance premium deduction certificate service2026-09-29, Japanese · sompo-japan.co.jp/-/…

References: “The last layer left for cyber defense in the age of AI”

The same method elsewhereSee all 4 "Human error" cases Get new cases and checks like these by email

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

Cite this Brief

Lemma Critical Team. (2026).
"TOPPAN: During a manual send, a list of 177,426 Sompo Japan policyholders slipped into another insurer's ZIP and went out (insurance-premium deduction certificate service) — nothing checks that the contents match the recipient before the send".
Lemma Critical Brief No.151. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/151-toppan-sompo-japan-misdirected-zip/
Revision History

Current version: 2.0

Lemma

If it can't be verified,
it doesn't enter your operation.

Lemma attaches cryptographic proofs to data and AI execution, so the receiving side can confirm authenticity without asking the issuer. Detection stays; a proof layer is added in front of it.

Talk to enterprise See the verification center