The Ledger That Stays Closed.
Follow how three Brazilian banks can uncover clients involved in collaborative fraud — without any of the three ever seeing the others' list.
The Scenario
Three banks suspect the same group of taxpayer IDs is moving suspicious amounts across all three simultaneously. Each bank wants to find out WHICH IDs appear in all three lists — without revealing anything else.
The Problem
For legal (LGPD) and competitive reasons, no bank can show its list to the others. PSI under FHE solves this mathematically.
The Guarantee
The neutral server never sees any of the lists. The ONLY information that comes out is the intersection, collectively decrypted. Mathematical guarantee (RLWE), not political.
Define the parameters.
Before any encryption, we choose the FHE scheme parameters. Each parameter is a trade-off between security, speed and computational capacity.
Chosen Parameters · BGV
What each term means
BGV ("exact" scheme) — A homomorphic encryption family that operates over integers. It has no approximation noise. The result is always bit-identical to the plaintext. Ideal for counts, SQL queries and boolean logic — exactly what PSI needs.
8 192 slots — An FHE ciphertext is not a single value: it is a vector of 8 192 packed values. You operate on all 8 192 at once with a single operation. This native "batching" is what makes FHE viable at scale — in production, millions of IDs fit per ciphertext.
Multiplicative depth 2 — How many chained multiplications a ciphertext supports before becoming unstable. Each multiplication consumes 1 level. 3-party PSI needs 2 chained multiplications → depth 2 is enough.
~128 bits of security — Industry standard. Brute-forcing the key would require ~2128 operations — an astronomical number, infeasible even on foreseeable quantum hardware.
RLWE base — Ring Learning With Errors. The mathematical problem underpinning security. It is the same problem over which NIST standardized ML-KEM and ML-DSA, the next generation of post-quantum cryptography.
Generate the key pair.
In production, this key would be generated via threshold cryptography across the 3 banks + a neutral authority. Here we simplify with a single key for clarity.
Key Flow
Quorum required to decrypt the final result. No single party can see anything alone.
What Was Generated
Each bank generates and encrypts.
Each bank produces a binary characteristic vector (1 = ID in the list) and encrypts locally. ONLY the ciphertext leaves the bank.
Cleartext Lists (didactic reference only)
- Bank A (BB)007 023 089 142 200
+ 5 own IDs - Bank B (Itaú)007 023 089 142 200
+ 5 own IDs - Bank C (Bradesco)007 023 089 142 200
+ 5 own IDs
BGV Encryption
The overhead is the price of mathematical privacy. In exchange, the other banks will never see this list.
What the neutral server receives.
The 3 banks send only their ciphertexts. The neutral server NEVER receives the secret key.
Real Ciphertext Sample (first 32 bytes)
74 65 78 74 4d 65 74 61
44 61 74 61 22 3a 7b 22
53 63 61 6c 65 22 3a 7b
...
Each full ciphertext has ~384 KB of pseudo-random bytes. Without the secret key, recovering the list of IDs would require solving Ring-LWE at dimension 8 192 — ~2128 operations.
Total Transferred
Compute intersection under encryption.
The server multiplies the 3 ciphertexts element-wise. Slot by slot, the product is 1 only where ALL three banks have 1 — exactly the intersection.
The Algorithm
Real Measured Performance
Collaborative decryption.
The encrypted result is decrypted collectively (in production, via a threshold quorum). Each 1-bit in the resulting vector reveals an ID in the intersection.
IDs Detected in the Intersection
★ ID#023
★ ID#089
★ ID#142
★ ID#200
What Each Bank Receives
ONLY these 5 IDs. The other 5 IDs from each list stay private — no bank learns the competitors' lists.
Mathematical validation.
To prove that the encrypted computation equals the plaintext one, we compare against the expected intersection computed in cleartext.
FHE vs Plaintext
| Metric | Value |
|---|---|
| Expected | 5 IDs |
| Found | 5 IDs |
| Correct | 5 / 5 |
| False positives | 0 |
| False negatives | 0 |
| Status | PERFECT MATCH |
Why It Is Exact
BGV is an exact scheme (no approximation noise like CKKS). For integers within the plaintext modulus, the FHE result is bit-identical to the plaintext.
What a dishonest bank can get.
Suppose one of the banks (or an employee of the neutral server) tries to find out the OTHER banks' lists from the received ciphertext.
Attack Attempts
- Attempt 1 — Read ciphertext bytes Result: pseudo-random bytes. Nothing extracted.
- Attempt 2 — Brute force the lists Universe of 256 positions, ~10 active. Combinations: C(256,10) ≈ 1017. Infeasible; and would still need decryption to verify.
- Attempt 3 — Recover sk from pk Solve Ring-LWE at dimension 8 192. Best known attack: ~2128 operations. Infeasible on classical or foreseeable quantum hardware.
What leaves the system
The ONLY information that legitimately leaves is the result decrypted by the threshold quorum: the intersection. That's it.
What just happened.
In under 1 second total, three banks discovered shared fraudsters without any of them seeing the others' lists.
The Complete Flow
- Three banks generated private lists of flagged IDs
- Each bank locally encrypted its list under BGV
- Only the ciphertexts were sent to the neutral server
- The server multiplied the 3 ciphertexts under encryption (7 ms)
- Collaborative decryption revealed only the intersection
- Each bank discovered the 5 shared fraudsters