FIRST-DRAFTbydOrg
Edition 22

Joining a tokenized-deposit network? Map the integration first.

Follow a fictional deposit request from authorization to network confirmation. Identify the ownership and recovery decisions your bank and vendor need to settle.

Joining a tokenized-deposit network? Map the integration first.
ยทยท4 min readยท

The write-up

The interesting part of a bank joining an onchain network starts with the first customer operation. Someone requests a transfer. The bank needs to decide what the customer can spend, what the network has done, and what its own systems should record.

That is a practical engineering problem with several owners. Drawing those boundaries early gives the implementation team a much better starting point.

A real reason to look now

On September 2, 2026, Cari announced $32.5 million in funding from banks. The announcement describes capital for bank onboarding, integrations and the network's move toward production. Its investors include First Horizon, Huntington, KeyBank, M&T, Old National, SouthState and Glacier. Cari announcement.

That is evidence of an active infrastructure initiative. The details of each bank's implementation, vendor selection and budget still need to be established with the teams involved.

For builders, the useful opening is to examine what a participating institution must connect around a network, using an explicit hypothetical model rather than guessing a provider's private architecture.

Start with the responsibility map

Take a fictional request to convert part of a customer's eligible balance into a network representation of a deposit. The institution must define eligibility, authorization, balance treatment, network submission and customer communication.

These steps should have named owners. Who can authorize the request? Which system records a reservation? What evidence permits completion? Who investigates an unresolved operation?

A tokenized deposit and a stablecoin can have different issuers, legal claims and operating rules. The implementation needs the actual product terms. A diagram cannot establish redemption rights, deposit insurance or regulatory treatment.

Explore the interruption

The most informative test is often a request that stops halfway through.

Suppose an internal reservation succeeds and the network response is delayed. Releasing the reservation solely because a local timer expired could make the same value available while the external operation is still unresolved. Retrying with a new operation identifier could also create an unintended second request.

A conservative illustrative design places that operation into a reconciliation state. It retains the original identifier, checks authoritative status and asks the appropriate owner to resolve the uncertainty. Whether this is implemented as a reservation, another ledger mechanism or a different workflow depends on the bank and network.

This example does not describe Cari's implementation. It gives a bank and its vendor a concrete scenario to settle before writing an adapter.

Turn the diagram into an acceptance test

A useful first scope is one operation crossing one internal system and one network boundary. Agree on the valid states, identifiers, retry behavior and evidence required for completion. Then test a successful response, a delayed response and a conflicting response.

We built Deposit Handoff Lab around a reservation followed by a successful or unresolved network result. Switch between the two outcomes and follow the available balance and explanation. All balances and transitions are fictional. It is a design conversation aid with no connection to a bank core or tokenized-deposit network.

Prepare the delivery relationship too

Bank implementation includes third-party oversight. The OCC's community-bank guide describes risk considerations for using outside providers. The practical preparation includes a clear contracting entity, delivery responsibilities, access boundaries and evidence of relevant capabilities. OCC third-party guide.

An integration sprint can make a broad initiative easier to discuss. Bring the operation, its owners and the systems involved. dOrg can help map the boundary and assess a testable engineering scope, subject to the institution's requirements.

Research snapshot: September 8, 2026. The prototype is an educational browser simulation. Product-specific behavior requires validation with the institution and network.

Working proof ยท Built by dOrgPrototype

Don't just read the thesis

See what happens when the idea has to work.

Compare a confirmed conversion with an unresolved network result. Follow a fictional $5,000 reservation from a $10,000 baseline.

Interactive simulationFictional data
Open in a new tab

Simulated where noted. No wallet, transaction or purchase is required.

What's not in this prototype
  • Educational browser model using fictional data; no live provider, bank, broker or network connection.
  • No real funds, custody, signing, customer data, compliance certification or audit.
  • No production persistence, concurrency guarantees or recovery infrastructure. Provider-specific behavior needs validation.
Build notes: audience, approach and business model

Optional background for readers exploring implementation.

01

The Problem

Define the responsible systems and owners. Agree on observable outcomes and acceptance tests.

Who feels it

Bank digital-asset teams, network providers and implementation partners.

Why now

Research checked September 8, 2026. Primary sources and their dates appear in the article; published initiatives establish relevance, while external delivery demand remains to be validated.

02

The Solution

What it does

01

Source-backed integration walkthrough.

02

Concrete, explicitly hypothetical failure scenario.

03

Scoped engineering starting point.

Built withJavaScriptHTMLCSS

Business Model

Paid, scoped integration sprint: one flow, one provider boundary, tests and handover. Timeline and price require technical review. Start with test data and no real funds; institutional vendor checks still apply.

End Goal

Help the reader identify and scope a concrete integration workstream.

Bring the operation, its owners and the systems involved.

A senior dOrg engineer can review the flow and help scope a paid implementation after checking technical fit, capacity and requirements.

Just browsing? Get the next edition by email

Previous

#21 5 Banking Integrations to Try with AI Agents and Web3

Next

#23 Put stablecoin payments on a budget your team can enforce.