Tokenized Deposits Need a Recipient Map

Analysis | October 17, 2026

Jack Henry's October 16 announcement outlines tokenized-deposit plans with Google Cloud Universal Ledger.

A wider distribution channel raises a second question: which payments become possible? Open Market Notes proposes evaluating a rollout against the payer–recipient relationships it can actually serve. The calculations below are invented planning examples, not estimates of customer activity, adoption or any provider's network coverage.

Google labels it Preview.

We have not tested the announced integration. Google's technical documentation describes its service; it does not establish what any particular bank has deployed.

Count the usable relationships

Google's transfer reference requires a payer role for the sender and a receiver role for the recipient.

For our proposed evaluation, a route means one specified payer can send the agreed asset to one specified recipient under the intended conditions. Bank names on an integration list are not enough to fill that map. Verify the actual accounts, asset, amount and operating window for each use case. These are proposed checks, not assertions about restrictions in the announced offering.

Keep directions separate. A demonstrated payment from one party to another does not, by itself, demonstrate the reverse journey. Also distinguish a directly supported payment from a workaround involving another service. A workaround may be useful, but its extra steps should remain visible.

Six banks do not tell the whole story

Imagine six banks, split into two groups of three. In this deliberately simplified model, every ordered pair of different banks is a possible direct payment route: six times five gives 30. Within each group, all six directed routes work. No route between the groups works, and forwarding through intermediaries is excluded. Thus 12 of 30 possible routes are enabled, or 40%.

Now enable one additional, one-way route between a bank in the first group and a bank in the second. The count of participating banks stays at six. Enabled routes rise to 13 out of 30, about 43.3%. The change does not automatically enable every cross-group pair; that would require different assumptions.

This is a model of permissions and usable relationships, not a diagram of GCUL. Real arrangements could allow routing or other services that change the calculation. The point is to state those capabilities before counting their benefit.

Weight the map by the work it serves

Suppose a fixed sample contains 1,000 intended payments. Of these, 700 use the original 12 routes, 200 use the newly enabled route, and 100 use other unsupported routes. Assume every payment meets all other conditions and that the enabled routes work throughout the test.

The original network can serve 70% of that sample; the expanded one can serve 90%. A single extra route increases the share of possible pairs by only about 3.3 percentage points, yet raises payment-count coverage by 20 percentage points. Neither number is wrong. They answer different questions.

That distinction can improve a rollout plan. Rank candidate additions by the existing payments they would unlock, then compare implementation effort and ongoing cost. Adding a heavily used relationship could be more valuable than adding several rarely used ones. This is a prioritization method, not a claim that payment patterns are concentrated in any particular market.

Report payment counts and payment values separately. A route carrying many small payments and one carrying a few large payments can deserve different priorities. Keep unsupported instructions in the denominator, rather than selecting the sample after learning which routes work.

Test the route that matters most

In our unchanged sample, taking the new route out of service drops coverage from 90% back to 70%. The institution count still reads six. That is why a participation headline can conceal a meaningful change in customer usefulness.

A pilot should preserve the same sample while testing unavailable recipients, closed operating windows and other conditions relevant to its design. Record whether each instruction used the proposed service, required a fallback, or remained unfinished. A successful fallback is a customer outcome worth recording; it should not silently become evidence of the proposed route's availability.

The next useful evidence is a recipient map tied to representative payment activity, with its assumptions and failure cases shown. A broad distribution channel creates an opportunity. Demonstrating which relationships it makes usable is how that opportunity becomes a service.