Who uses tokenized deposits for interbank settlement?

Global banks, regional banks and sponsor banks that issue deposit tokens or settle with banks that do.

Goldsky

Tokenized deposits for interbank settlement

Talk to our team

What are tokenized deposits for interbank settlement?

Tokenized deposits for interbank settlement are payments between banks made by moving deposit tokens, ordinary bank deposits recorded as tokens on a chain, instead of wiring money between correspondent accounts.

Global and regional banks use them to settle with each other at any hour, and every token movement has to appear in the core banking system as the same booking.

Goldsky decodes each mint, burn and transfer of the deposit token for your systems and checks the onchain totals against your core; the token platform, the bookings and the matching stay with the bank.

You can settle tokenized deposits two ways: stream every token movement to your queue or database with Turbo Pipelines, or index the token contract with a hosted subgraph and receive a webhook for each change.

How tokenized deposit settlement between banks works

The diagram follows one interbank payment from the debit in your core banking system to the check that the onchain and core totals agree. Your setup may differ.

Book an interbank paymentYour core debits the paying client

Deposit token platformMove deposit tokensYour token platform sends the transfer

Tokens change handsDeposit tokens reach the receiving bank

TurboDecode the transferMint, burn and transfer events read

Match and postTied to the core payment and booked

TurboPublish to your queueOne message per token movement

ComposeCheck against the coreOnchain and core totals compared, breaks flagged

Goldsky
Your provider

Ways to settle interbank payments in tokenized deposits

The pipeline pushes each movement into a queue or database you run and can read several chains at once; the subgraph keeps the records behind a hosted query API for one chain.

Usual setupOption 1: Stream to your queue

Best for: Several chains, movements in your own queue
Products: Turbo Compose
What you run: The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write: Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives: In your own database or systems
How results reach you: Pushed to you

Option 2: Hosted subgraph

Best for: One EVM chain, read through a hosted API
Products: Subgraphs Compose
What you run: Nothing; Goldsky runs indexing, storage and the API
What you write: A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives: Hosted by Goldsky
How results reach you: You query; changes are pushed

Ways to settle interbank payments in tokenized deposits
	Usual setupOption 1: Stream to your queue	Option 2: Hosted subgraph
Best for	Several chains, movements in your own queue	One EVM chain, read through a hosted API
Products	Turbo Compose	Subgraphs Compose
What you run	The destination: your database, queue or bucket, or a Postgres database Goldsky hosts	Nothing; Goldsky runs indexing, storage and the API
What you write	Pipeline YAML and SQL; TypeScript transforms when needed	A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives	In your own database or systems	Hosted by Goldsky
How results reach you	Pushed to you	You query; changes are pushed

Option 1: Settle interbank payments in tokenized deposits with a settlement stream

A Turbo Pipelines pipeline decodes every mint, burn and transfer of your deposit token and publishes it to your queue or database. A scheduled Compose task checks the onchain totals against your core.

When to stream deposit-token movements to your systems

Your bank settles on more than one chain, or your core and settlement systems already read from a queue or database you run.

What you’ll need

Goldsky Turbo
Goldsky Compose
A deposit token platform, your own or a provider’s
A message queue or database your core systems read
An API on your core that reports the deposits behind the token

Book the interbank payment in the core
The payment exists first as a booking in your core banking system, which debits the paying client.
The core records the client debit, the receiving bank and a payment reference. That reference is what ties the token movement back to the booking later, so it has to travel with the payment.
Move the deposit tokens
Settling between banks means the deposit tokens move from your bank’s wallet to the receiving bank’s wallet.
Your token platform builds and sends the transfer, or mints or burns tokens when money enters or leaves the token. A transfer sent without the payment reference has to be matched later by amount and time, which breaks when two payments are the same size.
Settle the tokens on the chain
The payment is settled when the receiving bank holds the tokens on the chain both banks read.
The transfer is recorded as an event in a block. Until enough blocks sit on top of it, a reorg can still replace that block, so a booking made from it early may have to be undone.
Decode every token movement
Handled by Goldsky Turbo
Your systems need each mint, burn and transfer in plain fields, not as raw chain logs.
Every event from the token contract is read and turned into sender, receiver, amount and type. Decoding against an out-of-date interface after the token is upgraded puts wrong values in every field.
Turbo Pipelines can read the token contract’s logs and decode them with _gs_log_decode, pulling the interface with _gs_fetch_abi so the pipeline keeps up when the token is upgraded.
Decode logs with SQL functions (opens in a new tab)
Publish each movement to your queue
Handled by Goldsky Turbo
Your settlement engine reads token movements from a queue it already consumes, so it books them in its own order and pace.
Each message needs a stable key, because delivery can repeat after a network error and your engine has to skip a message it already booked. When the chain replaces recent blocks, the engine also has to remove what it booked from them.
Goldsky’s Kafka sink publishes each row keyed on its ID, with a dbz.op header that marks it as an insert, update or delete. A movement undone by a reorg arrives as a delete for your engine to apply.
Set up the Kafka sink (opens in a new tab)
Match each movement to the payment and post it
A token movement only counts in the books once it’s tied to the payment it settles.
Your systems match each movement to a core payment by reference, wallet and amount, then post the receiving side. A movement with no payment, or a payment with no movement, is a break someone has to explain.
Check the onchain totals against the core
Handled by Goldsky Compose
Every token in circulation should match a deposit on the books, and the two records drift apart if any movement is missed.
On a schedule, compare the tokens outstanding on the chain with the deposits your core holds against them, and raise a break when they differ. The check has to record its inputs, so an auditor can see what was compared and when.
A scheduled Compose task can read the token’s totalSupply on the chain, fetch the matching figure from your core’s API and post a break to your operations tooling when they differ. Every read and request is logged on the run.
Check supply against your records (opens in a new tab)

What to know about streaming deposit-token movements

Goldsky runs the pipeline; the queue or database it writes to, and the code that books each movement, are yours.
Each movement is pushed as it’s decoded, so nothing on your side polls the chain.
A queue receives reorg corrections as delete records your consumer applies; database tables with a primary key are corrected in place.
Delivery is at least once, so your consumer skips a message it has already booked.

Option 2: Settle interbank payments in tokenized deposits with a hosted subgraph

A subgraph indexes your deposit token’s contract on one chain and serves its mints, burns and transfers over GraphQL, with a webhook to your backend for each change. A scheduled Compose task checks the totals against your core.

When to use a hosted subgraph for deposit-token settlement

Your deposit token runs on one EVM chain, settlement volume is moderate, and your team would rather query a hosted API than run a database for the records.

What you’ll need

Goldsky Subgraphs
Goldsky Compose
A deposit token platform, your own or a provider’s
An HTTPS endpoint on your backend for webhooks
An API on your core that reports the deposits behind the token

Book the interbank payment in the core
The payment exists first as a booking in your core banking system, which debits the paying client.
The core records the client debit, the receiving bank and a payment reference. That reference is what ties the token movement back to the booking later, so it has to travel with the payment.
Move the deposit tokens
Settling between banks means the deposit tokens move from your bank’s wallet to the receiving bank’s wallet.
Your token platform builds and sends the transfer, or mints or burns tokens when money enters or leaves the token. A transfer sent without the payment reference has to be matched later by amount and time, which breaks when two payments are the same size.
Settle the tokens on the chain
The payment is settled when the receiving bank holds the tokens on the chain both banks read.
The transfer is recorded as an event in a block. Until enough blocks sit on top of it, a reorg can still replace that block, so a booking made from it early may have to be undone.
Index every token movement
Handled by Goldsky Subgraphs
Your systems need each mint, burn and transfer as a record they can query, from the token’s first block on.
A schema sets the records and mappings turn each contract event into one. A field you leave out can’t be queried later without changing the index and building it again.
Goldsky Subgraphs runs your mappings over the token contract from the block you start at and serves the records at a hosted GraphQL endpoint.
Learn how Subgraphs work (opens in a new tab)
Push each movement to your backend
Handled by Goldsky Subgraphs
Settlement can’t wait for someone to query, so each new movement has to reach your systems as it’s recorded.
Each change has to say whether it’s a new record, an update or a rollback after a reorg. Changes can arrive out of order, so your backend keeps its own last-updated time for each record.
A Subgraphs webhook on the movement entity sends an INSERT, UPDATE or DELETE payload for every change, and each version’s block_range marks a reorg rollback.
Set up subgraph webhooks (opens in a new tab)
Match each movement to the payment and post it
A token movement only counts in the books once it’s tied to the payment it settles.
Your systems match each movement to a core payment by reference, wallet and amount, then post the receiving side. A movement with no payment, or a payment with no movement, is a break someone has to explain.
Check the onchain totals against the core
Handled by Goldsky Compose
Every token in circulation should match a deposit on the books, and the two records drift apart if any movement is missed.
On a schedule, compare the tokens outstanding on the chain with the deposits your core holds against them, and raise a break when they differ. The check has to record its inputs, so an auditor can see what was compared and when.
A scheduled Compose task can read the token’s totalSupply on the chain, fetch the matching figure from your core’s API and post a break to your operations tooling when they differ. Every read and request is logged on the run.
Check supply against your records (opens in a new tab)

What to know about indexing deposit tokens with a hosted subgraph

Goldsky hosts the index and its GraphQL endpoint; your backend receives the webhooks and keeps its own copy if it needs one.
Webhooks can arrive out of order, and each record version’s block_range is how your code tells a reorg rollback from an update.
Adding a field later means changing the subgraph and indexing again.
One subgraph covers one chain, so settlement on several chains needs one subgraph each.

What you control

Your team: Book the interbank payment in the core
Match each movement to the payment and post it
Your providers: Deposit token platform

Questions and answers

What are tokenized deposits?

Tokenized deposits are ordinary bank deposits recorded as tokens on a blockchain, issued by a bank and held on its balance sheet like any other deposit. The customer’s claim on the bank doesn’t change; only the record does, so the money can move between accounts or banks on the chain at any hour. Banks use them for treasury moves and for payments between institutions.

How are tokenized deposits different from stablecoins?

A tokenized deposit is a deposit at the bank that issued it, while a stablecoin is issued by a separate company and backed by a pool of reserve assets. Deposit tokens usually move only between the bank’s approved clients and partner banks. Stablecoins circulate more widely, including on public chains between people who aren’t customers of the issuer.

How do tokenized deposits work?

A bank debits a client’s account and mints the same amount as deposit tokens, which move on a chain between approved wallets until they’re burned and credited back as an ordinary deposit. Each mint, transfer and burn is an event on the chain that the core banking system has to book. Banks match every event to its payment and compare the tokens outstanding with the deposits behind them.