Financial Data Exfiltration

In financial institutions, personnel movement across organizations is routine. Secondments, outsourced operations, agency partnerships, joint ventures — in every case, the moving employee holds valid credentials from both the origin and host organizations, with legitimate access to customer data in both.

At that point, the trust boundary becomes structurally ambiguous:

• Access itself appears legitimate: The employee accesses official systems with valid credentials.
• Access logs are mutable: Both organizations store logs in standard databases with no cryptographic integrity guarantee.
• No shared proof layer exists: The origin and host organizations have no means to independently verify each other's logs.
• Deterrence is weak: Employees know that "logs can be disputed," so psychological deterrence does not function.

When the problem surfaces — customer complaints, regulatory audits, internal whistleblowing — neither organization can precisely prove what was accessed and when. Mutual recrimination, regulatory penalties, and reputational damage occur simultaneously.

Regulatory pressure is intensifying. Japan's revised Act on the Protection of Personal Information, the FSA's cybersecurity guidelines, AI governance frameworks, GDPR extraterritorial application, and national data protection laws worldwide are all shifting requirements from "logs exist" to "tamper-proof grounds can be proven."

Detection already exists (DLP, SIEM). What is missing is a layer that ensures detected events survive as tamper-proof facts.

The MetLife Japan 2026 incident exposed this structural gap. A life insurance company seconded employees to agency partner locations (regional banks, securities firms) to sell insurance products through both channels. A seconded employee exfiltrated 2,476 customer records across 36 agency partners.

Before Lemma — How the Incident Unfolded

Phase	What Happened	Why It Wasn't Detected
Access	Seconded employee queried 2,476 customer records across both organizations' systems	Access appears legitimate. Employee holds valid credentials.
Collection	Data copied to personal devices, USB drives, cloud storage	Logs are mutable and fragmented across organizations
Exfiltration	Data transferred to new employer or buyer	No unified cross-organizational audit trail exists
Discovery	Months later, through customer complaints and regulatory audit	Access logs may have been tampered with. No cryptographic proof of original access patterns.
Response	Cannot precisely prove what was accessed and when	Mutual recrimination, regulatory penalties for both organizations

The root cause is simple: ambiguous trust boundaries operated with mutable logs.

After Lemma — The Same Scenario with a Difference

A Lemma Authentication Gateway is deployed between each organization's CRM/database and its users. Every data access request generates a ZK attestation:

proof(user_id_hash, record_id_hash, timestamp, access_type)

Without revealing record contents, only who accessed what and when is cryptographically fixed. Attestations are anchored on-chain (or via commitment root), making them tamper-detectable by construction.

Phase	Behavior with Lemma
Access	Each query generates a ZK attestation, committed with a timestamp
Collection attempt	Anomalous patterns (volume, timing) are flagged by DLP. Lemma attestations precisely prove which records were accessed
Deterrence	Employees know that "all access is cryptographically proven." Psychological deterrence functions
Discovery	Both organizations immediately present tamper-proof shared proofs. No room for dispute
Regulatory response	FSA requests evidence. Verifiable attestation set exported within hours

Metric	Without Lemma	With Lemma
Anomalous access detection time	Weeks to months	Real-time (DLP) + cryptographic proof (Lemma)
Access log disputability	High	Near zero
Regulatory audit preparation time	Weeks (manual log aggregation)	Hours (attestation set export)
Cross-organizational blame	Mutual denial	Shared non-repudiable proof
Insider threat deterrence	Low ("I can probably deny it")	High ("everything is cryptographically proven")

Lemma's four cryptographic layers correspond to the cross-organizational data access lifecycle.

1. ENCRYPT — Immutability of Access Content

The Lemma Authentication Gateway never stores or inspects data contents. Queries and results to CRM systems and databases simply pass through the Lemma boundary. AES-GCM-encrypted payloads remain in the original systems.

2. PROVE — ZK Access Attestation Generation

The gateway intercepts all reads and queries, generating the following ZK attestation per access event:

proof(user_id_hash, record_id_hash, timestamp, access_type)

Both user identifiers and record identifiers are hashed; no personal information is exposed from the attestation itself. Attestations are aggregated into a local commitment tree.

3. DISCLOSE — Stakeholder-Specific Verifiability

Each party can independently verify:

• Origin organization: "Employee X accessed records [1..N] between dates D1 and D2"
• Host organization: "The same employee accessed our records [M..P] during their secondment"
• Regulatory authority: "Both organizations' attestations are consistent and tamper-detectable"

When DLP/SIEM flags an anomaly, a verified access report can be requested from Lemma. For the first time, the incident has non-repudiable evidence.

4. PROVENANCE — Commitment Root On-Chain Anchoring

The commitment root of all attestations is periodically anchored on-chain. Any party can verify that an attestation was generated at a specific time and has not been modified. No confidential data exists on-chain — only commitments. This enables regulatory compliance, dispute resolution, and post-incident forensics without data disclosure.

Lemma cryptographically guarantees the following facts in financial data exfiltration prevention:

• Actor, target record, timestamp, and access type for each access event
• Tamper-immutability of access logs
• Consistency of cross-organizational access traces
• Non-disclosure of data contents — no PII leaks from attestations themselves
• Independent verifiability by regulatory authorities
• A shared layer of truth accessible to origin organization, host organization, and regulators
• Cryptographic deterrence against insider threats

KYC/AML Selective Disclosure — Prove Without Sharing

Declared ≠ verified

A P4 complement. While this use case addresses "access trace authenticity," KYC/AML selective disclosure addresses "customer attribute authenticity." The same idea applied to a different target.

View use case →

AI Audit Log Proof — Permanent Decision Record

Audited ≠ explainable

AI decisions in financial institutions and the data access traces supporting them operate as a pair. This use case covers "how a person touched data"; AI Audit Log Proof covers "what an AI decided and how."

View use case →

DeFi Bridge Verification — Pre-Execution Attestation

Cryptographically valid ≠ semantically right

The DeFi structural mirror. DeFi's "the message is valid but origin is unproven" and TradFi's "the logs exist but are not tamper-proof" are two implementations of the same idea.

View use case →