Reconciliation

Why reconciliation compares against one ledger, not several#

Asset Lifecycle names the cost this discipline answers. A programme that keeps issuance in one system, identity screening in a second, custody in a third, trading in a fourth, and settlement and reporting in a fifth needs a comparison at every handoff between them. That handoff is where an instrument's ledger state and its legal record can drift apart. The platform records issuance and servicing against one asset instead, so reconciliation here is a comparison between two parties, your register and one ledger, in place of the several comparisons a multi-system programme would run.

That is also why the platform never asks you to hand over book-of-record status to get the comparison. An institution that already runs its own operations of record, its own accounting treatment, and its own regulatory sign-off can prove the chain agrees with that record. It can do so on a cadence its own operations team sets, without retiring the system those functions are built around. The decision to let the ledger take over stays yours, made through your own legal, regulatory, accounting, and operational review, never a setting the platform switches for you.

Running reconciliation day to day#

You run reconciliation on a schedule you set. The platform does not run it for you. The DALP ledger answers a point-in-time query at any past block, so pulling the register as of a cutoff and comparing it to your own is a repeatable lookup rather than a live capture you have to time carefully. Either cadence works, and each costs something different. A batch pull, once a day or once a cycle, needs only that one point-in-time query and skips event handling entirely, but a difference can sit undetected for up to a full cycle. An event-driven comparison runs when a change event arrives. The consumer must handle provisional, final, and retracted events, and reconcile any gaps or duplicates. An operation running an end-of-day close is usually well served by the batch cadence. One carrying intraday exposure needs the event-driven path to catch a difference before the day closes.

Most differences trace to one of two causes. The first is timing. Every DALP ledger read answers as of its progress point, the furthest block its record can be trusted through, and how far that point trails the chain's newest block depends on the network's own finality settings. The Ledger Data index reports degradation when its lag or staleness passes the thresholds in the ledger indexing stalled runbook. Your reconciliation policy sets its own acceptable discrepancy. Your register may post before or after the index's progress point. The second is a chain reorganisation, which the platform corrects on its own by deleting and replaying the affected records. Wait for that correction rather than reconciling against a figure captured mid-rollback.

A difference that survives both explanations does not get resolved automatically. Route it to a person who can pull the DALP ledger's own evidence, the transfer list and the progress point it covers, and compare it against your register's underlying instruction. That step stays manual on purpose: nothing in the platform decides which of two disagreeing records is correct.

How the two records relate#

Two platform records feed reconciliation: the DALP ledger, a decoded, queryable projection of the chain you follow, and the Settlement Verdict, the platform's own terminal outcome for a write you submitted. They answer different questions. The ledger reads each block once and commits its records and progress point together. When the chain replaces recent blocks, it deletes the affected records and replays the canonical chain rather than leaving a stale figure in place. The verdict is recorded once, for the write itself, and never revoked.

Ordinarily those two agree: a verdict of completed means the platform's write reached the chain and the ledger has caught up to the block it landed in. One case breaks that pairing: a reorganisation orphans the exact transaction that a verdict already reported completed. The ledger deletes the orphaned records and replays, but nothing in the platform revisits the verdict. Treat the ledger's record as the authority for what the chain holds, and have your comparison flag any completed verdict whose transaction the ledger no longer holds.

Neither record extends past the chain the platform follows. The ledger proves what happened on that chain. It proves nothing about a custody provider's own books, an external bridge, or a reserve held off-chain. Any of those needs its own evidence, sourced separately, before your reconciliation process can rely on it.

A token can also require every movement of its units to carry a reference to the entry in your register that records it. With the Booked movements feature attached, the token moves units only when an administrator books a movement under a register reference, and it refuses every other mint, burn, transfer, forced transfer or wallet recovery. Each webhook event for a booked movement includes registerLine, with the ID of the booked line and its register reference, so a reconciliation job can match the movement to its register entry when each entry has its own reference. Booked movements explains the lines and how a correction works, and the Booked movements workflow shows how to book them in the Console.

The integration contract#

Two API surfaces give a reconciliation job what it needs, and neither requires you to poll the raw chain. Query the DALP ledger for the register as of a past block, for one holder's transfers across a period, or for period aggregates such as fees, exemptions, yield, and redemptions. A point-in-time or per-transfer answer includes the progress point it covers, so a comparison against your register states exactly which blocks it accounts for. A period aggregate is stricter: the ledger folds a running total forward only to the newest settled block, so compare an aggregate against that block instead of the progress point.

For the event-driven path, subscribe to Platform Event notices, the signed record the platform emits as a write changes state, delivered through Webhook Delivery, the HTTPS push that carries each notice to your endpoint. Each step in a write arrives as its own event with its own identifier. For example, a transfer can post as provisional before it posts final. A reorganisation that invalidates a delivered event produces a retraction naming the identifier it replaces. Your consumer reconciles by replacing the record for that identifier, not by guessing which of two events is current.

Read a write's own outcome from its Settlement Verdict, not from acceptance. Acceptance only means the platform durably queued the instruction. Idempotency has an edge your pipeline must handle. The queue attaches a matching submission to an existing transaction request when the key, sender, network, and wallet selection match inside the 24-hour window. That does not cover work the API route may perform before queue admission. Outside the window, or with a different wallet-selection fingerprint, a matching queue submission does not attach. It fails outright. Inspect the original operation's status and on-chain result before creating a new attempt. A new key identifies new work and can duplicate an operation that already succeeded. Build your comparison job to key off the progress point and the verdict, not off request timing, and a chain reorganisation becomes a correction your job absorbs rather than an alert it has to raise.

Custody reconciliation#

When custody operations are on, the platform runs a reserve check for custody receipts and keeps a register of reconciliation breaks. The reserve check compares custody receipt supply with the coins held at custody addresses. The break register keeps the differences a registrar file reconciliation finds on record until a later clean run closes them or a resolution or write-off is applied after a second user approves it. The platform does not read the custody provider's own statements, so those stay a separate comparison outside the platform.

The reserve check covers custody receipts. A custody receipt is the token that represents coins held at the organisation's custody addresses. Every five minutes, the platform reads indexed state for each organisation and compares a receipt's total supply with the coins held at the organisation's custody addresses. The expected supply is the balance of the underlying coin at the custody addresses the organisation watches, minus the quarantined, held, unsupported and unallocated amounts the custody gateway reports, plus the coins in open gateway instructions, which are custody instructions still in progress. When the difference has not cleared for two hours, the platform raises a critical operations case. The case carries the label Balance difference, is listed by the operations cases route of the Platform API, and reaches a webhook subscriber as an operations.case.opened event. The same check raises a case with the same label when an address holds the supply management role on a receipt, an address other than the gateway factory is a supply delegate, the Hold feature is detached, the gateway factory is no longer the Hold reserver, a forced transfer passed a hold, a gateway implementation was updated, a gateway escrow locks fewer receipts than open requests are owed, or a keeper or screener wallet falls below its low-balance threshold. A case resolves itself when a later check of that network no longer finds its condition, except a gateway implementation update, which does not resolve itself.

A bank rail recall that a manager abandons leaves the holder's tokens in place, so the bank's debit stays an unexplained difference between the bank balance and the token supply until a manager records a reserve adjustment. The Abandon dialog in the Console states this before it submits, and a second manager has to approve the abandon.

A registrar file reconciliation compares a registrar's holder file with the chain. When an organisation Owner or platform administrator runs it, every holder line that does not match becomes a break in the organisation's register with the cause External, keyed by wallet and asset. A break has five statuses.

A break is open when a run finds it. An organisation Owner or platform administrator can mark it investigating and back to open, each time with a note. While the organisation's “Custody operations” approval is on, resolving it or writing it off asks a second user, an organisation Owner or platform administrator other than the requester, to approve. With that approval off, the default, the change applies at once. A later run that finds the same wallet and asset clean closes it as resolved automatically. A later run that still differs updates the same break and advances its age in weekdays without creating a duplicate.

A closed break is never edited again. A difference that returns after a resolution opens a new break linked to the closed one. A write-off covers the difference it was approved for. While the same amount keeps showing in every run since the write-off, no new break opens. A clean run in between ends that cover, and a difference that returns or changes then opens a new linked break. The approved write-off, its note and its maker and checker stay as recorded. A run changes a break only when the run's date is not earlier than the latest date the break already rests on, so rerunning an earlier date neither clears a break first seen later nor reopens one that a later run cleared.

To work the register, follow Custody reconciliation in the Console.

What the evidence proves, and what it does not#

Reconciliation evidence has two layers. One records what happened on the chain that the platform follows, with repeatable queries and traceable sources. The other records who in your organisation acted on each exception. The DALP ledger supplies the first, deterministic under the same query and the same blocks. Every correction traces to the chain's own canonical history, never to an operator editing a figure, which is what makes it defensible evidence for what the chain did. It does not, on its own, establish who in your organisation investigated or cleared a specific reconciliation exception. That trail lives in your own operations record, not the platform's.

The platform's Audit Trail, the append-only log of which session performed each step, records the session that acted, which is normally the person who acted. When someone works under a Delegated Authority, the permission for one participant to act on another participant's behalf, the log names the operator's own session rather than the party they stood in for. Do not present the platform's log as independently proving who a delegated step was taken on behalf of.

State the evidence claim's limits to a reviewer: the ledger evidences the chain the platform follows, known contract types only, for the period processed under its current recording rules. It says nothing about a custody provider's own books, an external bridge, or an off-chain reserve. Those need separate evidence that you produce and defend yourself.

Frequently asked questions#