Counterparty Screening — Pass the Result, Not the Reasons

Are you in the bind where, every time you want to share a credit or sanctions decision with another firm or auditor, you have to choose between shipping the basis along with the decision or letting them re-check the same party themselves? Ship the reasons, scores, and query history and you move leakage, defamation, and interference risk. Withhold them and the group companies, the partner banks, and the trading partners each re-screen the same party from scratch.

Do you have a technical path that keeps "share the trust of the decision" and "don't share the basis" satisfied at the same time?

• Credit / compliance leads at banks, FinTechs, and crypto exchanges
• Procurement, purchasing, and risk teams at manufacturers, trading firms, and critical-infrastructure operators running supplier vetting
• Legal and compliance functions that need to share sanctions / credit decisions across the group and with partners
• Teams beginning to delegate transaction and procurement decisions to AI agents and looking for per-action independent verifiability

Counterparty credit and sanctions screening is a job where three things are required at the same time: prove the decision without revealing its contents; let a third party, auditor, or AI verify it independently; and make it impossible to alter after the fact. Every conventional tool is missing one of them.

A spreadsheet or database can be rewritten by an administrator, and sharing it leaks the contents. A signed PDF identifies the signer but exposes the reasons and scores. Encryption hides the data but can't show the other side that the decision is correct.

Only a ZK proof satisfies all three. Conversely, if even one of the three is dispensable for a given task, conventional tools are enough and Lemma isn't needed. Only work that requires all three at once is Lemma's territory.

The result travels. The contents don't.

Lemma lets the issuer that ran the decision (a bank, a compliance team, a credit / sanctions data provider) emit the decision as a predicate — "not on the sanctions list", "credit score above threshold", "not resident in a restricted jurisdiction" — as an independent attribute proof. The underlying data (transaction history, credit information, the full list, query history) stays under the issuer; what travels to the verifier is only the ZK proof of the result.

The receiving side (counterparty, group company, auditor, AI agent) verifies "does it meet the bar" independently, without ever touching the underlying data. When, by whom, and that the decision was issued tamper-free is fixed via a provenance anchor (docHash) and stays reconstructable years later. The duplicate-screening work across firms and the leakage / defamation risk of shipping the basis come off the same design at once.

Where this proof-issuance layer drops into your existing credit / sanctions data providers, in-house decision pipelines, or compliance workflows is what the first conversation maps out.

Where is your credit / sanctions path redundant, and where is it generating risk? Tell us the structure. The first conversation maps whether Lemma's predicate-proof layer fits — no technical detail or sensitive disclosure required.

Once the fit is visible, we move into NDA-bound work: industry-specific reference architecture, data-source connector patterns, PoC design.

Book a Discovery Call → Download the Whitepaper

The same decision delivers different value depending on where you sit. All figures below are directional.

The deciding side (credit, procurement, compliance) Keep the basis of a decision in-house while sending only its trustworthiness outward. Both the "won't be trusted because it can't be shown" problem and the duplicated re-checking of the same party go down. e.g. responding to disputes and audits shifts from assembling documents to presenting a cryptographic trail.

The receiving side (counterparties, group companies, auditors, AI agents) Verify on the spot without seeing the contents, with no need to re-check the same party. Trust the decision itself rather than a plaintext claim. e.g. cross-org duplicate screening shifts from N separate inquiries to a single verification.

The screened side (counterparty, individual) No unnecessary personal or transaction data spreads. Only the needed decision reaches the other side; reasons, scores, and query history stay private. e.g. disclosure shifts from submitting every field to proving one decision (predicate).

The HQ of mid-sized trading group A runs sanctions and credit screening on a prospective counterparty. The basis: transaction history, credit data, third-party database queries. The same counterparty then gets re-screened independently by regional subsidiary B, overseas subsidiary C, and partner bank D handling settlement — that's the live operation.

Two problems. First, every group company and partner bank re-checks the same party. Second, even when HQ A tries to share the basis with the subsidiaries and the bank, leakage of the underlying data moves defamation and interference risk; withholding it pushes the receivers back to re-screening because they can't trust the decision alone.

With Lemma in place, the ZK proofs HQ A emits at decision time — "not on the sanctions list", "credit band acceptable", "not resident in a restricted jurisdiction" — are what go to subsidiaries B / C and bank D. The basis (transaction history, scores, the list that was queried, the query history) stays under HQ A; the receivers verify "does it meet the bar" independently without ever seeing it. When an audit or regulatory report lands later, the provenance anchor still shows when, by whom, and tamper-free the decision was issued.

The non-membership circuit selection, list-revocation and decision-withdrawal handling, and connector patterns for existing credit / sanctions data providers ride on the industry kit that follows the Discovery call.

Lemma does not replace existing credit / sanctions data providers or your in-house decision pipeline. It drops a per-predicate ZK proof layer in one slot between the issuer (the compliance team / data provider / bank that ran the decision) and the verifier (the receiving counterparty / group company / auditor / AI agent).

Cryptographic constituents: BBS+ over BLS12-381 for attribute-level selective disclosure; Poseidon over BN254 list commitments with Groth16 (Circom circuits) for "(non-)membership" decisions that keep the full list private; docHash (P1 Verifiable Origin) to fix the decision's issue time and tamper-freeness. The verifier checks only the received proofs — never the underlying data, never the full list, never the query history.

Predicate-category design, connector patterns against existing credit / sanctions data sources, and the handling of list revocation and decision withdrawal live in the whitepaper and the post-call technical materials.

• The issuer, issue time, and the authenticity of the decision (sanctions-list non-membership, credit band, jurisdiction status, and so on), per predicate
• Non-disclosure of the underlying data, the full list, and the query history (the basis cannot leak out of the predicate proof)
• That the decision has not been tampered with, and that it remains independently verifiable years later
• A structure in which issuer, receiver, auditor, and AI agent all verify the same fact independently, without ever sharing the underlying data

This isn't a standalone SaaS purchase. We enter through AI-adoption and data-governance consulting plus a PoC, and land on an existing monthly plan as the use case warrants. Concretely, five steps:

1. A 30-minute review — identify where in your credit/sanctions flow the decision is "untrusted because un-showable" or duplicated across firms.
2. Narrow to 1–2 decisions (results) to prove — e.g. "not on the sanctions list," "credit tier at or above threshold." You don't expose the full schema; only the needed decision becomes the proof target (technically, a predicate — a true/false condition over attributes).
3. Design connection and revocation — how it connects to existing credit/sanctions data sources, and how list updates and decision withdrawal (revocation) are handled.
4. Prove one path via a (quote-based) PoC — confirm it works on a single decision path.
5. Land on an existing monthly plan (indicative) — Lemma Compliance / Critical as the use case warrants; pricing is confirmed together in conversation.

To start, tell us where in your current screening the "untrusted because un-showable" risk concentrates — in the first 30 minutes. No disclosure of sensitive data is required.