P4 · Regulatory Attribute Proof

KYC/AML Selective Disclosure

Hide name, address, date of birth and other identity attributes
Prove meets KYC / AML requirements

Satisfy KYC/AML requirements with per-attribute ZK proofs — no shared customer data.

Banking · Fintech · Cross-border payments 6 min read
live in production since 2025 · Public-infrastructure PoC in production · ETHGlobal AI Agents 2026 Finalist
01 · THE PROBLEM

Three voices from the front line.

  • Bank KYC team

    “We only need to confirm a customer's age and eligibility, yet we end up receiving the full originals — passport, proof of address”

  • Compliance

    “We want to prove only compliance to regulators, without taking on PII leakage risk”

  • Platform operator

    “Every time we outsource KYC, personal data spreads further outside”

02 · THE SHIFT

Hand over the source, or just the facts?

Change what reaches the AI, and the leakage risk goes with it.

Without Lemma
Hand over the original
name:
Taro Tanaka
dob:
1985-04-12
address:
Tokyo…
passport_no:
TR1234…
id_image:
base64…
↓ all of it goes to the AI / outside
With Lemma
Hand over just the facts
holder:
did:lemma:user-customer-001
issuer:
did:lemma:authority-jp-mha
jurisdiction:
JP
licenseType:
kyc-attestation
disclosed:
[age_18+, residence_JP, aml_clean]
hidden:
[name, address, dob, passport_no]
ZK verified:
✓ VALID
↓ only the necessary facts to the AI

An issuer that has already done the screening (the bank) issues each customer attribute as an independent trail. The original address, date of birth and transaction history stay with the issuer; what the receiving side gets is only the proof of the needed attributes — "18 or older," "resident in Japan," "not on a sanctions list." Without sharing the data, regulators, receiving institutions and the customer can independently verify the attribute's authenticity, issuer, validity and consent.

See the technical details ↗
03 · HOW TO CHOOSE

Choose on three criteria.

Only work that needs all three at once — pass without exposing, independent verification, tamper-proof — is Lemma's domain.

Method Pass without exposing Independent verification Tamper-proof
Access control only
Masking / anonymization
Encryption only
Lemma (ZK proof)the only one with all 3
04 · HOW IT WORKS

What's next

We enter through KYC/AML compliance and data-minimization support and a PoC, and stay alongside you through to operations.

  1. A 30-minute review — identify paths where the same KYC packet is re-submitted per institution, and workflows where cross-border PII triggers revalidation.
  2. Narrow to 1–2 decisions (results) to prove — e.g. "Japan-resident," "18 or older," "sanctions-list clear" — the attributes passed to the verifier. Not the raw data.
  3. Design connection and issuer integration — how the attribute-issuance layer slots into your existing KYC/AML pipeline, and linkage of issuer signatures and expiry.
  4. Prove one path via a (quote-based) PoC — confirm one attribute-verification path works.
  5. Hands-on support from rollout through operations — existing plan tiers (Civic / Critical / Compliance) serve only as a cost reference; the setup and pricing are designed together.

Tell us one workflow where "share to demonstrate compliance" and "minimize data sharing" run in parallel, in the first 30 minutes. No disclosure of sensitive data required.

The bigger picture

The bigger picture this use case belongs to.

We map use scenarios across industries and workflows by the four axes.

See use scenarios for Regulatory Attribute in Solutions →

TRY LEMMA

Run it yourself.

No sales call needed — start hands-on with Lemma's products.