Who uses DvP settlement monitoring?

Market infrastructure operators, custodian banks, global banks and tokenization platforms that settle tokenized assets against stablecoins or deposit tokens.

Goldsky

DvP settlement monitoring for tokenized assets

Talk to our team

What is DvP settlement monitoring?

DvP settlement monitoring is matching each delivery-versus-payment (DvP) settlement, in which a tokenized asset moves against a stablecoin or deposit token, to its booked trade and chasing any trade not settled by its deadline.

Market infrastructure firms, custodian banks and tokenization platforms run it because on venues that move both legs in one transaction the risk is a booked trade that never settles, and a leg can settle without the other only where the legs move separately or on different chains.

Goldsky writes the settlement events from each chain to one table and runs a scheduled check that alerts on trades still unsettled near their deadline; your team books each trade, matches settlements to it and marks it settled.

How DvP settlement monitoring works

The diagram follows one trade from booking to the moment your team marks it settled, and shows who does each step. Your setup may differ.

Book the tradeAsset, cash and settlement deadline

CustodianSign each sideEach side’s custodian approves its transfer

Settlement platformRun the settlementOne transaction, or two linked transfers

Asset and cash settleTogether, or leg by leg

TurboLand every settlementEach chain’s events in one table

Match to the bookingEach settlement checked against its trade

ComposeChase an unsettled tradeA scheduled check alerts near the deadline

Mark the trade settledSettlement matched and final

Goldsky
Your provider

How to monitor DvP settlement for tokenized assets

A pipeline decodes the settlement events on each chain into one table in your database, where your systems match each settlement to its booked trade. A scheduled task alerts when a trade is still unsettled near its deadline, or has settled on one leg only.

What you’ll need

Goldsky Turbo
Goldsky Compose
A trade booking system with each trade’s legs and deadline
Custody providers that sign each side’s transfer
The ABIs of the settlement and token contracts on each chain
A database for the settlement events
An alert channel your operations team watches

Book the trade
Operations needs a record of what should settle, for how much and by when, before anything moves.
Book the asset, the cash amount, both parties’ wallets and the settlement deadline, with a reference the settlement can be traced to, whether the two sides agreed the trade directly or a venue matched their orders. Without that reference, matching settlements to trades later turns into guesswork on amounts.
Sign each side’s transfer
Each side’s transfer, or its order on a venue, needs approval from whoever holds that side’s keys.
Each side’s custodian approves under its own policy. A transfer or order that’s never approved never settles, and the trade misses its deadline.
Run the settlement
The settlement platform moves the asset against the cash according to the agreed terms.
Your tokenization platform or trading venue submits the settlement, either as one transaction that moves both legs or as two linked transfers. In one transaction both legs move or neither does; when the legs move separately, one can settle while the other fails.
Settle the asset and cash
The trade is done only when the tokenized asset and the cash, a stablecoin or deposit token, have both moved.
On a venue that settles atomically, one transaction moves both on the same chain. When the legs move separately they can land at different times, or on different chains. If the cash moves offchain instead, only the asset leg can be watched onchain.
Land every settlement in one table
Handled by Goldsky Turbo
Checking settlements against bookings is easiest when every settlement event, from every chain, arrives in one place.
Decode the settlement events from every chain involved and write them to one table, each row tagged with its chain and keyed so retries don’t duplicate it. When legs land in separate systems, nobody sees that one is missing.
With Goldsky, one Turbo pipeline can read logs from several chains, decode the settlement, asset and cash events and combine them with UNION ALL into a single table, the pattern the cross-chain settlement ledger guide uses.
Build a cross-chain settlement ledger (opens in a new tab)
Match each settlement to the booked trade
A settlement closes a trade only once you know which trade it belongs to.
In your database, join each settlement, or each leg where the legs move separately, to its trade by reference, or by wallets and amounts where there’s no reference onchain, and check the amounts agree with the booking. A settlement that matches no trade is a break to investigate.
Chase an unsettled trade before the deadline
Handled by Goldsky Compose
A trade that hasn’t settled as its deadline nears needs someone to act while there’s still time.
Check trades close to their deadline and alert your operations team on any with no settlement yet, or, where the legs move separately, with only one leg recorded. This is a rule about something missing, so it runs on a schedule rather than waiting for an event that never comes.
Compose can run a task on a cron trigger that calls your trade system for trades near their deadline with no matched settlement, or with one leg only, and posts an alert, with each call recorded on the run.
Schedule a task with cron (opens in a new tab)
Mark the trade settled
Operations, risk and finance all need to know the trade is finished.
Mark the trade settled once its settlement has matched the booking and is final, and where the legs move separately, once both have. A trade marked settled on one leg leaves exposure on the books that nobody is watching.

What you control

Your team: Book the trade
Match each settlement to the booked trade
Mark the trade settled
Your providers: Custodian
Settlement platform

Questions and answers

What is atomic settlement?

Atomic settlement means both legs of a trade, the asset and the payment, move in one transaction, so both transfers happen or neither does. It stops one side delivering without the other, though not risks tied to the asset, its issuer, custody or the technology. A booked trade can still miss its deadline if it’s never submitted or the transaction fails, so operations still match each settlement to its booking.