How JIL identity binding prevents wrong-recipient transfers before value moves.
Business Email Compromise (BEC) and impersonation fraud cause over $2.7 billion in losses annually (FBI IC3). The root cause is simple: traditional payment systems verify the instruction, not the recipient. JIL solves this by binding cryptographic identity to every beneficiary before settlement can proceed.
Beneficiary verification is a mandatory gate in JIL's settlement flow. No value moves until the intended recipient's identity is cryptographically confirmed - not by the sender's assertion, but by the beneficiary themselves.
Sender creates settlement intent with beneficiary address
System issues identity challenge to beneficiary wallet
Beneficiary signs challenge with MPC key shard
Validators verify identity proof against on-chain binding
Settlement proceeds only after 70% validator consensus
Every JIL wallet is bound to a verified identity through MPC key generation. During wallet creation, the user's identity is cryptographically linked to their key shard. This binding is recorded on-chain and cannot be transferred or spoofed.
| Check | Method | Failure Action |
|---|---|---|
| Wallet ownership | MPC signature challenge | Settlement rejected |
| Identity binding | On-chain identity hash lookup | Settlement rejected |
| Sanctions screening | Compliance API cross-reference | Settlement frozen, alert raised |
| Jurisdiction check | Geolocation + compliance corridor | Settlement rejected or routed to compliant lane |
| Liveness | Challenge response within timeout | Settlement expires |
The beneficiary verification uses a cryptographic challenge-response protocol:
The settlement engine generates a unique nonce bound to the settlement ID, beneficiary address, and current timestamp. This challenge is delivered to the beneficiary's wallet endpoint.
The beneficiary's wallet signs the challenge using their MPC key shard. The signature proves wallet ownership without revealing the private key. The signed attestation includes the settlement ID to prevent replay attacks.
The signed attestation is broadcast to the validator network. Each validator independently verifies the signature against the on-chain identity binding. Settlement proceeds only when 70% of validators (14 of 20) confirm the identity match.
If the beneficiary address does not match the intended recipient's identity binding, the challenge-response fails at Step 2. The settlement is rejected and the sender is notified with a clear error: BENEFICIARY_IDENTITY_MISMATCH.
If the beneficiary does not respond to the challenge within the configured timeout (default: 15 minutes for standard settlements, 60 minutes for high-value), the settlement enters EXPIRED state. Funds are never at risk - they remain in the sender's wallet until a valid settlement completes.
If the compliance API returns a sanctions match for the beneficiary, the settlement is immediately frozen. A compliance alert is raised to the institution's compliance officer and the settlement enters COMPLIANCE_HOLD state.
Beneficiary verification sits between the policy enforcement gate and the escrow release gate in JIL's settlement lifecycle:
| Phase | Gate | Status |
|---|---|---|
| 1 | Settlement intent submitted | Complete |
| 2 | Policy enforcement (amount limits, corridors) | Complete |
| 3 | Beneficiary verification (identity binding) | Active |
| 4 | Escrow lock | Pending |
| 5 | Validator consensus (70% attestation) | Pending |
| 6 | Finality receipt generation | Pending |
Wire transfers verify the routing number and account number - not the person. If a fraudster intercepts an invoice and changes the account number, the payment goes through. The sender only discovers the fraud days or weeks later.
JIL verifies the recipient's cryptographic identity before releasing funds. Even if a fraudster changes the wallet address, the identity challenge will fail because the fraudster cannot produce a valid MPC signature bound to the intended recipient's identity. The settlement is rejected in real-time.