Tokenized Deposits

Cari Interbank Deposit Transfer

Instant deposit transfer between consortium banks on a shared ledger. Huntington customer → KeyCorp customer in seconds, not hours. ZK proofs verify balances without exposing customer data — the "Glass Vault" model.

Vendors

Cari Network · Huntington · M&T Bank · KeyCorp · First Horizon · Old National

Compliance Center

ZK-proof transport — shared ledger validates balance and authorization without revealing customer identity or transaction details to counterparty bank.

Filter by shape:
|
C2 · UNKNOWNCari Interbank Deposit Transfer·5 stations(3 compliance, 2 infra)·cari-network · huntington · m-and-t · keycorp · first-horizon · old-national
S1INTENTS2S3DISCOVERYS4S5TRANSPORTS6AUTHORIZATIONS7FACILITATIONS801Bank Account02Sanctions03Network Gate04Settlement05Tx Monitoring
3+5 shape system
GatePre-condition — blocks if it failsMonitorConcurrent — observes without haltingObligationPost-settlement — reports after the factsolid = codedashed = policy
How to read this diagram
Each station on the rail represents a compliance or infrastructure event in the Cari Interbank Deposit Transfer path. Hover any station to inspect it. The shape tells you what kind of event it is. The ring tells you how it's enforced.
Gate Monitor Obligation| Ingress Crossing Transform Settlement Venue
This path at a glance
5 stations across 5 of 8 segments. 3 are compliance checkpoints, 2 are infrastructure.
2 code-enforced3 policy-enforced
C2 · CARI INTERBANK DEPOSIT TRANSFER · PRIVIDIUM (CARI NETWORK ZK SUBSTRATE)
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONHuntington online banking + Huntington BSA/AML pipeline (structuring · velocity · OFAC re-screen)
L4 ACCOUNTOriginating customer Prividium wallet ↔ Cari party-id (destination)

Step 1 · Originating Customer Initiates TransferPolicy-Enforced

"A retail customer initiating a Zelle transfer — the bank's online banking surface accepts the instruction and the bank's compliance program runs the screening before any value moves."

The originating customer (a Huntington DDA holder, in the canonical example) initiates a transfer via the Huntington online banking interface. The destination is identified by Cari party-id — analogous to a routing+account number, but on the Prividium party-model rather than ABA/account number.

Identity is inherited from Huntington's CIP file — no new attestation. The originating bank's BSA/AML pipeline runs at this step: structuring detection, velocity heuristics, OFAC re-screen on the originating customer (which the bank does as part of its standard ongoing-monitoring program).

L4 ACCOUNT (customer wallet eligibility) and L5 APPLICATION (bank online banking + BSA/AML pipeline) lit, both policy-enforced bank-side controls. The originating bank holds the regulatory perimeter for its customer; the receiving bank will hold its own customer's perimeter symmetrically.

Counterparty
Originating bank BSA/AML pipeline
Latency
Real-time
Finality
N/A — instruction only
Vendors
Huntington online banking · Huntington BSA/AML pipeline (NICE Actimize · Verafin · SAS pattern — VERIFY bank-by-bank) · Cari party-id directory
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONOriginating bank wire-room (NICE Actimize · Verafin · SAS pattern) — outbound sanctions screen
L3 EXECUTIONCari transfer contract — consortium-allowlist gate + on-chain sanctions oracle (Chainalysis OFAC Oracle Prividium-adapted · VERIFY)
◆ Enforcement Line — mixed code- and policy-enforced

Step 2 · Originating Bank Authorization + Sanctions Re-ScreenMixed EnforcementINGESTDETECTALERT

"A bank's wire-room sanctions screen plus the receiving-side correspondent-bank's onboarding check — except both legs collapse into a single shared-ledger gate because the participating banks have pre-attested each other's BSA programs at consortium join."

The originating bank's wire-room runs the outbound sanctions screen against OFAC SDN, EU Consolidated, UK HMT, and any bank-specific lists. The receiving bank's identity is implicitly vetted because all consortium members completed the Cari Network onboarding — bank-bank counterparty risk is pre-cleared at consortium-join time, not per-transaction.

The on-chain Cari transfer contract enforces that both originator wallet and destination party-id are on the consortium-allowlist; sanctions screening on the destination party-id happens code-side via Cari's sanctions oracle [typically Chainalysis OFAC Oracle adapted for Prividium party-ids — VERIFY exact vendor and contract address].

L3 EXECUTION (oracle + allowlist contract) and L5 APPLICATION (bank wire-room) lit. Mixed enforcement: bank-side wire-room is policy-enforced, oracle and allowlist gate are code-enforced.

Honesty marker: Cari Network's sanctions-oracle architecture is in pilot at the model's January 2026 cutoff. The exact oracle vendor, contract address, attestation cadence, and dispute-resolution process are not publicly disclosed and carry VERIFY. Renderers should not assume the oracle is the same Chainalysis OFAC Oracle deployed on public EVM chains; the Prividium permissioned environment likely uses a vendor-adapted variant with different operational parameters.
Counterparty
Originating bank wire-room + Cari sanctions oracle
Latency
<1s · KV-cached oracle reads
Finality
Pre-condition — halts on sanctions hit or off-allowlist destination
Vendors
Originating bank wire-room screening (NICE Actimize · Verafin · SAS — VERIFY) · Cari sanctions oracle (Chainalysis OFAC adapted for Prividium · VERIFY) · Cari consortium-allowlist contract
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L3 EXECUTIONZK proof system (PLONK or Groth16 · VERIFY) — balance + authorization attestation without identity disclosure
◆ Enforcement Line — code-enforced at this layer

Step 3 · Glass Vault — ZK Balance & Authorization ProofCode-EnforcedINGESTDETECTALERT

"A SWIFT settlement message that proves funds are reserved without exposing the originating customer's account history — the cryptographic equivalent of a confirmed-good-funds advice."

The Cari transfer contract generates a ZK-balance-proof: a cryptographic attestation that the originating wallet holds at least the transfer amount, that the originating bank has authorized the transfer, and that the transfer amount falls within all programmatic ceilings — without revealing the originating customer's identity, full balance, or account history to the receiving bank.

The receiving bank consumes the proof as confirmed-good-funds-advice and is willing to credit its customer's wallet on that basis. The receiving bank sees the destination party-id (its own customer) in clear and the token amount in clear; it does NOT see the originating customer's identity, balance, or transaction memo.

L3 EXECUTION lit, code-enforced. The proof system [PLONK or Groth16 — VERIFY] is the structural primitive that enables bank-grade counterparty privacy at the consortium layer while preserving each bank's internal BSA/AML visibility into its own customer.

Honesty marker: Prividium privacy means counterparty banks see a balance proof, not transaction details. This constrains certain BSA/AML monitoring topologies that depend on counterparty-side visibility — for example, network-level analysis of inter-bank flow patterns is structurally impossible because no single bank sees the full graph. Conservative compliance programs should anticipate that any cross-bank monitoring (e.g., consortium-wide structuring detection) requires either a Cari-Network-operator-level analytics layer with appropriate legal carve-outs, or per-bank cooperation under specific information-sharing agreements (such as USA PATRIOT Act §314(b)). The Cari Network operator's role in this analytics layer carries VERIFY at cutoff.
Counterparty
ZK proof system + receiving-bank validator node
Latency
<2s · proof generation + verification
Finality
Pre-condition — receiving bank credits only after proof verifies
Vendors
Cari ZK-balance-proof system (PLONK or Groth16 · VERIFY) · Receiving-bank Prividium validator node
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L4 ACCOUNTOriginating wallet ↔ destination wallet (atomic debit/credit on Prividium)
L3 EXECUTIONCari transfer contract — atomic settlement coordinated with both banks' GL memo entries
L2 CONSENSUSPrividium BFT consensus
L1 NETWORKPrividium ZK substrate — proofs settle to Ethereum L1 for finality anchoring
◆ Enforcement Line — code-enforced at this layer

Step 4 · Atomic Settlement — On-Ledger TransferCode-Enforced

"A Fedwire transfer that completes in seconds rather than the multi-hour Fedwire window — the value moves atomically with finality on the shared ledger."

The Cari transfer contract executes the atomic settlement: the originating customer's wallet is debited and the receiving customer's wallet is credited in a single Prividium transaction. Both legs commit together or both revert.

Originating bank's GL posts a memo debit against the originating DDA; receiving bank's GL posts a memo credit against the receiving DDA — both legs reconcile end-of-business-day per Cari operational rules. The deposit liability moves between member banks at the GL level; the on-chain token movement is the canonical record of the transfer.

L1 NETWORK · L2 CONSENSUS · L3 EXECUTION · L4 ACCOUNT all lit. Settlement is final on Prividium consensus in under 2 seconds — orders of magnitude faster than ACH (T+1 or T+2) and Fedwire (within Fed business hours only).

Counterparty
Cari transfer contract + both banks' GLs
Latency
<2s
Finality
Final on Prividium · EOD GL reconciliation
Cadence
Per transfer event · daily GL reconciliation under Cari operational rules
Vendors
Cari transfer contract (Prividium) · Both banks' core-banking GL memo-entry interfaces · Prividium ZK substrate
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))
L5 APPLICATIONL4 ACCOUNTL3 EXECUTIONL2 CONSENSUSL1 NETWORKPRIVIDIUM
L5 APPLICATIONReceiving bank BSA/AML pipeline (NICE Actimize · Verafin · SAS — VERIFY) — inbound-funds screening + Travel Rule ingest

Step 5 · Receiving Bank Compliance InheritancePolicy-EnforcedINGESTDETECTALERT

"A correspondent bank's inbound-wire screening — the receiving bank treats the credit as if it had received a SWIFT MT103 with confirmed-good-funds."

Once the on-chain settlement clears, the receiving bank runs its standard inbound-funds compliance against its own customer: structuring detection, velocity heuristics, beneficial-ownership re-attestation if the credit triggers a re-attestation threshold, and Travel Rule data acceptance for credits above $3,000.

Travel Rule data is encoded in the Cari transfer payload as a structured field per FinCEN-compatible IVMS101 packaging [VERIFY exact field schema]. The receiving bank's compliance program ingests this structured data and feeds it into the receiving-side monitoring pipeline.

L5 APPLICATION lit, policy-enforced. The receiving bank holds the BSA/AML perimeter for its customer going forward; any subsequent filing obligations (SAR, CTR) attach to the receiving bank under its own program.

Counterparty
Receiving bank BSA/AML pipeline
Latency
Real-time post-settlement
Finality
Final · receiving bank holds inbound-funds perimeter going forward
Cadence
Per inbound credit · async re-attestation if thresholds tripped
Vendors
Receiving bank BSA/AML pipeline (NICE Actimize · Verafin · SAS — VERIFY) · Cari Travel Rule payload (IVMS101-packaged · VERIFY schema)
Chain
Prividium (Cari Network ZK substrate) (Cari Network LLC (consortium operator) · Matter Labs (ZKsync core, VERIFY licensing model))

Resolved 5 steps across 1 chain(s). 0 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.

Coverage notes: 5 disclosed gap(s).

TOOL 01 · LIVE & EMERGING NETWORKS

Tokenized Deposit Network Map

Visual map of tokenized-deposit networks — Cari Network, RLN, JPM Onyx — alongside major stablecoin issuers, with participants, chain infrastructure, privacy model, and rollout status.

TOKENIZED DEPOSIT NETWORKSSTABLECOIN ISSUERSCari NetworkMVPEugene Ludwig / PromontoryPermissioned L2 (ZK)anchored to Ethereum · ZK proofsToken: Cari Deposit TokenFDIC ELIGIBLEMembers AUM: $779B combined5 participantsKinexys (fka Onyx)LIVEJPMorgan ChasePermissioned L2 + Public L2 (pilot)anchored to Ethereum · Permissioned ledger; Base pilot for public chain interopToken: JPM Coin / JPMDFDIC ELIGIBLEDaily volume: $1B+2 participantsBNY Digital CashPILOTBank of New York MellonPermissionedanchored to Proprietary · Institutional permissioned ledgerToken: BNY Digital CashFDIC ELIGIBLELaunch: 20252 participantsUSDC$60B+Circle Internet FinancialState-licensed money transmitter (pursuing OCC c...Chains: Ethereum, Base, Solana, Arc, Arbitrum +2Reserves: US Treasuries + cash at regulated banks (BNY)NOT FDIC INSUREDUSDT$140B+TetherOffshore issuer (BVI)Chains: TRON, Ethereum, Solana, Arbitrum, AvalancheReserves: US Treasuries, secured loans, Bitcoin, gold, other in...NOT FDIC INSUREDPYUSD$700M+Paxos (for PayPal)NY trust company (NYDFS regulated)Chains: Ethereum, SolanaReserves: US Treasuries + cash depositsNOT FDIC INSUREDBANKING PERIMETER