Cari Commercial Payment
B2B commercial payment between corporate clients of different consortium banks. Pre-negotiated terms settle atomically on the shared ledger — replacing ACH batch windows with real-time finality.
Step 1 · Corporate Originator (Treasury Workstation)Policy-Enforced
"A corporate treasury team initiating a vendor payment from their treasury management system — Kyriba, Reval, or the bank's commercial portal — under existing payment-workflow controls."
The originating corporate's treasury workstation (Kyriba · Reval · GTreasury · the originating bank's commercial portal — VERIFY tenant-by-tenant) accepts the payment instruction with structured commercial metadata: purchase order reference, invoice number, payment terms (Net 30, 2/10 Net 30, etc.), and optional escrow conditions.
The corporate's BSA/AML posture sits at the originating bank as a corporate customer of that bank; identity inheritance is the same pattern as C1/C2 — the bank's existing CIP and beneficial-ownership file (31 C.F.R. § 1010.230) gate the corporate's access to the Cari surface.
L4 ACCOUNT (corporate wallet eligibility · bound to the corporate's DDA at the originating bank) and L5 APPLICATION (treasury workstation + bank commercial portal) lit, policy-enforced. Corporate-internal approval workflow (single signer · dual signer · authorization matrix) runs before the instruction reaches the bank.
Step 2 · Pre-Negotiated Commercial TermsPolicy-EnforcedINGESTDETECTALERT
"A corporate procurement contract reviewed and agreed before any invoice is cut — the commercial terms exist as a binding agreement before the cash movement."
The commercial terms (PO reference, invoice number, payment-term encoding, optional escrow conditions) are pre-negotiated between the corporate counterparties off-ledger. This negotiation sits at the corporate-procurement / AR-AP layer, not at the bank.
The Cari payment carries the agreed terms as structured calldata bound to the cash leg — every settlement is atomic with the commercial-terms binding. The receiving corporate's AP system can auto-match the credit to the invoice without separate remittance advice arriving out-of-band, which is the dominant pattern that ACH-batch + paper-or-email remittance traditionally produces.
L5 APPLICATION lit, policy-enforced. C13 (market integrity) attaches because the commercial-terms binding has contractual weight — a credit landing with the wrong PO reference is a contractual defect, not just an operational nuisance.
Step 3 · Originating Bank Authorization + Sanctions ScreenMixed EnforcementINGESTDETECTALERT
"A corporate-banking RM authorizing a high-value payment against the corporate's commercial DDA — full compliance screen runs before any value moves."
The originating bank's commercial-payments compliance pipeline runs the outbound sanctions screen against the receiving corporate, structuring detection on the originating corporate's payment patterns, and dual-control authorization for amounts above per-corporate thresholds.
The Cari transfer contract gates the on-chain leg via the consortium-allowlist + sanctions oracle (same gates as C2 step 2). The receiving-corporate counterparty visibility is direct if both corporates bank with the same institution, or via consortium-bank attestation if not.
L3 EXECUTION (oracle + allowlist) and L5 APPLICATION (bank commercial-payments compliance pipeline) lit. Mixed enforcement — bank-side dual-control is policy-enforced, on-chain gates are code-enforced.
Step 4 · Glass Vault — ZK Proof + Commercial-Terms BindingCode-EnforcedINGESTDETECTALERT
"A SWIFT MT103 with a structured remittance field that the receiving bank can parse and route directly to the receiving corporate's AP system — except cryptographically bound and privacy-preserving across counterparty banks."
The Cari transfer contract generates the ZK-balance-proof (same primitive as C2 step 3) AND binds the structured commercial calldata into the same cryptographic envelope. The receiving bank verifies balance + authorization without seeing originating-corporate detail.
The receiving corporate (via its bank's AP-routing surface) consumes the commercial metadata directly — auto-matching the credit to the open invoice on its AR-AP system without out-of-band remittance advice.
L3 EXECUTION lit, code-enforced. The structural innovation: cash leg + commercial calldata are atomic and cryptographically bound, eliminating the remittance-disconnection problem that plagues ACH-batch B2B settlement.
Step 5 · Atomic Settlement — Cash Leg + Commercial-Terms AnchorCode-Enforced
"An ACH credit hitting the receiving corporate's bank account at the same instant the remittance advice lands in the AP system — except in seconds rather than T+1 batch cycle."
The Cari transfer contract executes the atomic settlement: originating corporate's wallet debited, receiving corporate's wallet credited, both banks' GLs posted memo entries, and the commercial-terms calldata anchored cryptographically to the on-chain transaction hash.
Receiving corporate's AP system ingests the credit + remittance bundle simultaneously and auto-applies the cash to the open invoice. The reconciliation work that traditionally consumes 1-2 days of AR-AP staff effort per cycle is collapsed to a real-time auto-match.
L1 NETWORK · L2 CONSENSUS · L3 EXECUTION · L4 ACCOUNT all lit. Final on Prividium consensus in under 2 seconds. C13 (market integrity) attaches to the commercial-terms anchor because misstated PO/invoice references in the calldata create contractual exposure for both corporates.
Step 6 · Receiving Bank + Corporate Compliance InheritancePolicy-EnforcedINGESTDETECTALERT
"A corporate AR team confirming a customer payment posted to the right invoice — except the matching is automatic because the calldata anchored the PO reference."
The receiving bank runs its standard inbound-funds compliance against the receiving corporate (cf. C2 step 5). The receiving corporate's AP system auto-matches the credit to the open invoice via the commercial-calldata binding.
Travel Rule data is preserved across the settlement for credits above $3,000 — the IVMS101-packaged payload that flowed through the Cari transfer payload feeds the receiving bank's monitoring pipeline.
L5 APPLICATION lit, policy-enforced. C11 (recordkeeping) attaches at the receiving bank for the inbound funds and at the receiving corporate for the books-and-records of the cash receipt; C12 (independent audit trail) is satisfied because the on-chain transaction hash and commercial calldata are cryptographically linked.
Resolved 6 steps across 1 chain(s). 0 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.
Coverage notes: 5 disclosed gap(s).