The Settlement instructions tab of a venue shows which token moves from whom to whom, and in what amount, before and after a trade settles, without a chain explorer. It is read-only. The organisation's operations signer, which holds the venue's submitter role, settles each matched trade on chain unless a fill is held or the trade is undone, and any wallet can trigger a delivery that has fallen due. An operator reads the batches that delivered and the ones that did not.
Trading venue explains how a fill becomes a delivered trade. A fill the platform could not settle waits on Held fills, and a trade that must not settle is undone on Trade busts.
The “Settlement instructions” tab with its status selector, filter bar and export controls above the batch table.
The “Batch status” selector reads “All statuses”. The filter bar holds “Search”, “Instrument”, “Participant”, “Client classification”, “Side”, “Minimum price”, “Maximum price”, “Matched from” and “Matched to”. Beside it sit the “Export CSV” and “Export Excel” buttons, the “Open XvP settlements” link, and “From date” and “To date” with “Export a date range”, all above the batch table.
Steps
Open Settlement instructions
Open “Asset lifecycle”, then “Venues”, and select the venue. Select “More” in the tab row, then Settlement instructions.
Read the batches
Trades that settle in one transaction form one batch. A trade that has no settlement transaction yet is its own batch, shown as Pending delivery. The table names each batch by its reference, with its status, its trade count, its counterparties, the time it was “Matched”, its chain id, and the buyer and seller fees in the quote token.
Each batch has one of four statuses, and the Batch status filter selects among them:
- “Pending delivery” means at least one trade in it still awaits delivery. It does not mean the batch is unsettled: on an instrument with a holding period, a batch that already has its settlement transaction stays in “Pending delivery” until the holding period ends and the trades deliver.
- “Delivered” means every trade delivered.
- “Undone” means every trade was undone.
- “Partly undone” means delivered and undone trades share it.
Open a batch
Open a batch to see each trade, named by its pair, quantity, and price, such as “EUROC / AEDT · 1 EUROC at 4.01 AEDT each”, with a button that copies its trade id. The buyer and seller show by participant or contract name, with the address on hover. Each trade lists its legs: the securities, the cash, and the fee, and, where the venue collects it on chain, VAT paid to the venue's VAT recipient. Each leg names its asset by name and symbol, linked to the asset page, with the token address beneath, and its payer, payee and amount. A trade that has no settlement transaction yet shows its cash at gross value and no fee leg, because the fee is fixed when the settlement transaction lands. Once it has landed, the trade shows its fees even while the batch is still in “Pending delivery”.
A fill's trade reference on an order's page lands here with the batch that holds the trade already open and highlighted, and the trade in view. When no batch the tab loaded holds that trade, for example because it is older than the 200 newest batches the tab loads, the tab searches for the trade id instead, and clearing Search brings back the whole list.
Each trade also shows its buyer fee and its seller fee next to the buyer and the seller, and the table shows the buyer fees and the seller fees of a batch in two columns, with “None” for a batch whose trades have no settlement transaction yet. The table shows every amount of a token to the longest exact fraction any of them needs on the page, so a Cash total of 3.99 beside fees of 0.02 and 0.01 reads with two decimals, and a page that holds a figure needing six decimals shows all of that token's figures with six. The fee leg is the sum of the two. In the export, a trade with no settlement transaction yet has empty fee cells. Batch totals leave out undone trades. A buyer's and a seller's Trading member shows beside them to a venue operator.
Filter the batches
The filter bar narrows the trades in the list:
- Participant takes a wallet address and keeps trades where that wallet is the buyer or the seller.
- Client classification takes a class, Retail, Institutional or Proprietary, and keeps trades where a party has that class. The class is the one stored on the party's order when the venue accepted it, so a later change to the participant's class does not move an old trade, and a party with no class never matches.
- Side becomes available once you set a participant or a client classification: choose “Buy” or “Sell” to test only the buyer or only the seller. With both a participant and a class, the same party must match both.
The bar also filters by “Instrument”, “Search”, “Minimum price”, “Maximum price”, “Matched from” and “Matched to”. A batch that matches lists only its matching trades. “Matched from” and “Matched to” refuse a typed day that does not exist, such as 2026-02-30, and show a message under that field. Until you correct or clear the refused date, the list stays filtered by the last date that field accepted, or by none.
The tab loads the newest 200 batches and says when the venue has more. Filter by batch status to reach the rest.
Export the batches
Export CSV and “Export Excel” download the trades that match the current filters, up to 100,000 rows, not only the batches on screen. Narrow the filters when more match. While “Matched from” or “Matched to” holds a refused date, both buttons stay unavailable.
Export a date range downloads every batch between “From date” and “To date” as JSON, which is the form that carries the legs and the fees of each batch. The range follows the status filter and has no upper bound on batches, and it stops with a message instead of returning a list that could repeat or miss a batch when the batches change mid-export. Leave a date empty for no limit on that side. “From date” and “To date” count whole days in your browser's time zone, while “Matched from” and “Matched to” count whole UTC days. “From date” and “To date” refuse a “From date” after the “To date” or a typed day that does not exist, such as 2026-02-30, and show a message under that field. “Export a date range” stays unavailable until you correct or clear that date.
Follow a batch to delivery
Settling a trade is a chain transaction. The instrument's holding period, the delay between match and delivery, decides when that transaction runs. A holding period of zero delivers both legs and the fee inside the fill's own transaction, so an instrument with no window settles the moment it matches. A holding period greater than zero reports and prices the trade at the fill, keeps both legs and the fee locked in the venue's escrow, and delivers when the trade is due. Only a due delivery reaches the chain after the fill. Any address can trigger a due delivery even while the platform is down, and a fill that has not reached the chain still needs the platform.
A token's own transfer rules can refuse a delivery. Each leg runs the token's own transfer compliance path. A token that rejects the transfer inside the fill's own transaction fails that fill and returns the commitments to the resting orders, so no trade is left half settled. A due delivery undoes the trade without an operator decision, with both legs returned to their owners' free escrow balances, only for an outside cause: a paused token, a trade lock a custodian shrank, a frozen sending side, or a receiver added to the compliance bypass list during the holding period. Any other refusal parks that leg. The venue pays the legs it can and books the refused leg to its receiver's free escrow balance, and the batch shows “Delivered”. The receiver withdraws the parked units once the token's rules accept its wallet again. An escrowed leg never lapses while it waits, though a holder of the token's custodian role can still move it out of the escrow with a forced transfer.
A stop order that has fired fills from the reservation it took when the trader placed it, so its fills settle like any other order's.
You do not start a settlement. You read it on Settlement instructions, where the batch status moves from “Pending delivery” to “Delivered” or “Undone”, and the platform sends a settled-trade webhook for the delivery, which distinguishes a delivered trade from one still awaiting delivery. Settlement reports lists the records that keep them.
The participant's side of the same settlement is the trade blotter, the Your trades tab on the trading desk, read through GET /api/. Each row is one side of one trade with its price, quantity, quote-token value, fee, status and undo reason, so a participant who asks whether a trade settled reads the same status you see on the batch. The blotter answers one page of fills at a time, newest first, and its status filter narrows it to the fills still pending delivery. The blotter lists only the trades of the caller's own wallets: a settling desk that does not trade reads every trade on “Settlement instructions” and the bust console instead.
Close the day on Custody reconciliation
The close is a reconciliation of one closed day, and it is the record that says what settled and what did not. It lives on Reconciliation under “Custody” in “Organisation settings”, not on this tab, as Custody reconciliation covers every column, refusal code and retry, and its “Download CSV” writes the day as a file with a trades section and a funds section. Closing the day needs the organisation's Owner role or Platform admin access.
Settle off the order book
A delivery versus payment that does not come from this venue is an XvP settlement. The tab links to it as Open XvP settlements when that add-on is deployed. A venue batch is proven by its settlement transaction and the trades it carries. An XvP settlement is proven by its resulting Settlement Verdict and its execution. Read XvP settlement for creating, approving, executing and cancelling one.
How a trade settles
The held list is the one queue that needs a decision, and it feeds the day's close.
Settlement reports
The platform generates each report from the ledger it indexed, not from a second system's copy.
In settlement-and-fails a venue trade has two rows, its delivery leg in the instrument and its payment leg in the cash asset, and its settlement id is the trade id. The outcome reads settled once the settlement transaction is indexed, cancelled after a bust, failed when the trade was refused or its reservation was removed, with the fail reason naming which, and pending while delivery is still due. The intended date of a venue leg is the time the trade executed, so days late measures how long delivery took.
Troubleshooting
A batch stays on Pending delivery past its due time
A held fill in that batch needs a decision, an open bust proposal flagged the trade, or the chain has not answered yet. Open the held fills and the trade busts and check for the trades in the batch. A batch whose legs are locked and whose fill is neither parked nor flagged delivers when the due delivery runs. Any address may call the venue contract's due delivery directly, or wait for the platform's own run. A venue operator wallet can clear a flag on the venue contract directly, so check the trade busts before you assume a flag still holds.
The tab shows only the newest batches
The tab loads the newest 200 batches and says “Showing 200 of N batches, and the table export holds only these.” when the venue has more. Filter by Batch status, or use “Export CSV”, “Export Excel” or “Export a date range”, which read past the first 200.
API routes
The request and response fields are in the v2 API reference.