JPMorgan Deposit Token
JPMorgan's tokenized deposit for commercial clients — distinct from Kinexys wholesale rails. Deposit tokens represent JPM commercial account balances, enabling programmable payments and 24/7 treasury operations within JPM's ecosystem.
Step 1 · Commercial Client Identity (JPM Internal CIP)Policy-Enforced
"A JPM Treasury Services corporate client logging into the JPM Access portal — bank-grade due diligence already complete at relationship onboarding, ongoing monitoring under JPM's BSA/AML program."
The commercial client is an existing JPM customer with a complete CIP file (12 C.F.R. § 21.21), beneficial-ownership disclosure (31 C.F.R. § 1010.230), and ongoing-monitoring program coverage under JPM's BSA/AML framework.
The deposit token is a Kinexys party-id provisioned by JPM Treasury Services and bound to the customer's existing commercial DDA. Identity is JPM-internal — there is no consortium-bank coordination because there is no consortium; every participant in C7 is a JPM commercial customer.
L4 ACCOUNT (Kinexys party-id ↔ commercial DDA) + L5 APPLICATION (JPM Access portal + JPM CIP file) lit, policy-enforced. The single-bank model is the structural contrast with C1-C6 (Cari consortium): all attestation, all monitoring, all reconciliation runs at JPM.
Step 2 · Programmable Payment Terms (Conditional Logic)Code-EnforcedINGESTDETECTALERT
"An escrow agreement with conditional release triggers — except encoded as smart-contract logic on the bank's permissioned ledger and released atomically on condition satisfaction."
JPM commercial clients can encode conditional payment terms directly in the Kinexys settlement contract. Common patterns: time-locked release (payment fires at a specific datetime), oracle-conditional release (payment fires when an external data oracle confirms a delivery event or a price condition), multi-signature release (payment fires when N-of-M corporate signatories approve), and chained-release (payment B fires only after payment A confirms).
The programmable-payment surface is the structural innovation that distinguishes C7 from a standard JPM Treasury Services wire; without programmability, the customer can already move funds via Kinexys (cf. W4K) or Fedwire. The terms encoding is the moment when the payment intent becomes machine-enforced rather than operations-team-managed.
L3 EXECUTION (programmable-payment contract) + L5 APPLICATION (customer authorization workflow + JPM contract-deployment surface) lit, code-enforced. C13 (market integrity) and C16 (programmable compliance) both attach — the payment logic IS the compliance artifact.
Step 3 · JPM Compliance Pipeline (Internal Screen)Mixed EnforcementINGESTDETECTALERT
"JPM's internal correspondent-banking compliance desk reviewing an outbound payment — single-institution screening, all parties known to JPM."
JPM's internal compliance pipeline runs the standard outbound and inbound screens on every C7 payment. Because both counterparties are JPM commercial customers, the screening is single-bank: outbound sanctions check on the originating customer, inbound check on the receiving customer, structuring/velocity heuristics across both sides, Travel Rule data exchange (internal to JPM and therefore an operational simplification — no external IVMS101 packaging needed).
The Kinexys settlement contract enforces the compliance result code-side: payment fires only after JPM's compliance pipeline returns clear. Mixed enforcement: bank-internal screening is policy-enforced, on-chain settlement gate is code-enforced.
L3 EXECUTION (settlement-contract compliance gate) + L5 APPLICATION (JPM compliance pipeline) lit. The single-bank model collapses what would be cross-bank Travel Rule packaging in C2/C3 to an internal data exchange.
Step 4 · Atomic Settlement (JPM Coin on Kinexys)Code-Enforced
"An intra-bank book transfer between two JPM commercial DDAs — except executed on the Kinexys ledger with cryptographic settlement record and conditional-trigger composability."
On condition satisfaction (cf. step 2's programmable terms) and clear compliance (cf. step 3's screen), the Kinexys settlement contract executes the atomic transfer. Originating customer's JPM Coin balance debited; receiving customer's balance credited; both customers' JPM commercial DDAs reflect the symmetric memo entries on JPM's general ledger.
The settlement is a JPM book transfer at the GL layer — value never leaves JPM's balance sheet because both parties bank with JPM. This is the single-bank operational simplification: no external counterparty risk, no inter-bank settlement cycle, no Fedwire window dependency.
L1 NETWORK · L2 CONSENSUS · L3 EXECUTION · L4 ACCOUNT all lit. Final on Kinexys consensus near-instantaneously.
Step 5 · Reporting & Recordkeeping (JPM Internal)Policy-EnforcedINGESTDETECTALERT
"A JPM internal reconciliation between two commercial-DDA general-ledger entries — except the canonical record is the Kinexys cryptographic transaction hash plus the GL memo entries."
Each settlement's record sits in JPM's internal books: the Kinexys transaction hash anchors the on-chain leg; the JPM general-ledger memo entries reflect the symmetric DDA debits and credits.
C11 (recordkeeping) is satisfied at JPM under existing 12 C.F.R. §§ 12.1, 12.3 (records of account); C12 (independent audit trail) is satisfied because the Kinexys cryptographic record and the GL memo entries are independently cross-verifiable.
Reporting to the customer is via the standard JPM Treasury Services statement surface; reporting to regulators (OCC primary supervisor for JPM Chase Bank N.A.) is via standard examination-cycle infrastructure. L5 APPLICATION lit, policy-enforced. Single-bank model means the reporting story is operationally simpler than any consortium pattern — JPM owns every leg of the audit trail.
Resolved 5 steps across 0 chain(s). 0 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.
Coverage notes: 5 disclosed gap(s).