Reconciliation breaks in stablecoin settlement: a taxonomy, the treatment for each, and the ageing report

Reconciliation breaks in a stablecoin settlement are items that do not agree across the three records an institution keeps: the public chain, the payments subledger that holds the customer-level position, and the general ledger that holds the institution's books. They fall into a short list of types, unmatched inbound, wrong chain or wrong asset, partial amount, duplicate, dust, fee asset and timing, and each has a standard treatment, a named owner and a time limit that can be written into the procedure. This article sets out that taxonomy, the treatment and owner for each type, the ageing report a reviewer asks for and the upstream controls that stop most breaks occurring.

What are the three records, and what counts as a break?

The chain record is the set of transactions to and from the institution's wallets, read from a node or an indexer and stored as a table of transaction hash, block time, asset, amount, sender and recipient addresses, and fee. The subledger is the payments system's record of each expected movement: a customer instruction, its UETR, the expected asset and amount, the expected wallet and the status. The general ledger is the accounting record, usually posting from the subledger, with the stablecoin holdings as an asset account per token and per chain and the customer obligations as liabilities.

Reconciliation runs in two directions. Chain to subledger asks whether every on-chain movement corresponds to an expected item. Subledger to general ledger asks whether the accounting agrees with the operational record. A break is any item present in one record and absent in another, or present in both with a different amount, asset, chain or date, outside a stated tolerance. The tolerance should be near zero for amount, because a stablecoin transfer is exact, and a small number of blocks or minutes for time. A daily balance proof, the wallet balance from the chain against the subledger position against the general ledger account, closes the loop; if the three balances agree and all items are matched, the day is clean.

What are the break types, and what is the standard treatment for each?

The types below cover almost everything a settlement operation sees. Each entry gives the symptom, the usual cause and the treatment that a first-line analyst should apply without escalation.

Unmatched inbound. Tokens arrive at an institution wallet with no expected item in the subledger. The cause is usually a counterparty sending without a reference, sending early, or sending to the wrong address in the institution's set. Treatment: hold the funds in a suspense position, screen the sending address, search open expectations by amount and counterparty, and if no match within the time limit, contact the counterparty and return by the agreed path, evidenced by a pacs.004 with a reason code where the flow is message-driven.

Wrong chain or wrong asset. The expected asset arrives on a chain the institution does not operate for that counterparty, or a different token arrives, for example USDT where USDC was expected. Treatment: never post to the expected item. Record the receipt as a distinct asset position, screen it, confirm whether the institution can access it at all, and either agree with the counterparty to treat it as settlement of the obligation with an adjusting entry or return it. A receipt on an unsupported chain may be irrecoverable, and the procedure should say so.

Partial amount. The received amount is less than expected, usually because the sender deducted a network fee or a provider fee from the amount rather than paying it on top. Treatment: match the item, post the shortfall to a fee variance account, and apply the customer contract to decide whether the shortfall is charged back or absorbed. If partial receipts recur from one counterparty, the fix is in the agreement's charge bearer terms, not in the reconciliation.

Duplicate. Two on-chain transactions satisfy one expected item, or one on-chain transaction is recorded twice in the subledger because a webhook fired twice. Treatment: the subledger must be idempotent on transaction hash, so a true duplicate record cannot exist and a double send from a counterparty appears as an unmatched inbound for the second amount. Return the second amount by the agreed path and record the return against the original UETR.

Dust. Very small balances that accumulate from rounding, from airdropped tokens, or from counterparties testing an address. Treatment: define a dust threshold per asset, exclude balances below it from the daily proof with a standing note, and sweep or write them off on a schedule. Unknown tokens that arrive unrequested should never be moved, since interacting with them can be a security risk.

Fee asset. The network fee is paid in a different asset from the one being transferred, for example a chain's native token when moving a stablecoin, so the stablecoin balance reconciles but the fee asset balance drifts. Treatment: hold the fee asset as its own account, reconcile it on the same daily proof, and post fees per transaction from the chain record rather than from an estimate.

Timing. The item exists in both records but with different dates, typically because the chain confirmed after the subledger's day-end cut, or the general ledger posts on a batch that runs before the last on-chain confirmations. Treatment: define the day boundary once, in a single time zone, apply it to all three records, and carry items that straddle it as reconciling items with an expected clearing date of the next business day.

A reconciliation that matches on amount is a reconciliation that will one day match the wrong thing. Match on the identifier, and let amount be the check, not the key.

Who owns each break type, and how long may it stay open?

Ownership and time limits are what turn a taxonomy into a control. A workable allocation is as follows.

• Unmatched inbound is owned by settlement operations, with a limit of two business days to match or contact the counterparty and five business days to return, and escalation to the head of operations at day three.
• Wrong chain or wrong asset is owned by settlement operations with treasury sign-off, with a limit of one business day to confirm accessibility and five business days to agree treatment, and escalation to treasury and compliance on day one because the asset may be unscreened.
• Partial amount and fee asset breaks are owned by the finance team that posts the general ledger, with a limit of one business day to post the variance, and a monthly review of counterparties that cause them.
• Duplicates are owned by settlement operations with a limit of one business day to identify and five business days to return, and a defect ticket to engineering if the cause was a system double-record.
• Dust is owned by treasury with a scheduled monthly sweep or write-off, and no per-item time limit provided the standing note is current.
• Timing breaks are owned by finance and must clear on the next business day; any timing item older than one business day is reclassified as another type and investigated.

The escalation route matters as much as the limit. A break that is escalated on time to the right person is a controlled item; a break that sits in an analyst's queue past its limit is what an examiner calls a control failure, whatever its value. The procedure should name roles, not people, and the workbench should change an item's status automatically when it ages past its limit.

What does the ageing report look like, and who signs it?

The ageing report is a single page that a reviewer, whether internal audit, an external auditor or an examiner, will ask for before anything else. It shows, for each break type, the count and value of open items in age buckets, typically zero to one business day, two to five, six to ten and over ten, with the total open value against the wallet balances so the reader can judge materiality. Beneath the table it lists the individual items older than five business days with the UETR or transaction hash, the counterparty, the amount, the owner and a one-line status. Any item over its time limit is flagged. Recurrences from the same counterparty or the same cause are grouped, because the reviewer's next question is what has been done about the cause.

The report is produced daily from the workbench and signed at month end by the head of settlement operations and the finance controller, with the daily balance proofs attached. A reviewer will test it by selecting items and asking for the evidence trail: chain record, subledger entry, general ledger posting, counterparty correspondence and the approval of the treatment applied. If each item can be pulled by identifier and the trail is complete, the reconciliation control is demonstrated; if items must be reconstructed from email, it is not.

Which upstream controls prevent most breaks?

Most breaks are caused before the funds move. The single most effective control is a payment reference carried end to end. In the ISO 20022 message the UETR identifies the payment; on chain, the same reference is either placed in the transaction's memo or destination tag where the chain supports one, or held in a lookup table that maps the expected transaction to the UETR before the counterparty sends. Matching then runs on the identifier and amount becomes a check. The second control is address discipline: one receiving address per counterparty or per expected item, so that an inbound transfer identifies its sender by construction. The third is the charge bearer rule agreed with each counterparty, which decides whether fees are on top or deducted and removes the partial amount type at source. The fourth is an allowed chain and asset list per counterparty enforced at the point the counterparty is given an address, which removes most wrong chain and wrong asset breaks. The fifth is idempotency on transaction hash in the subledger, which removes duplicates caused by the institution's own systems.

With those five in place the daily break volume falls to genuinely external items, and the ageing report becomes short enough to read.

Where StableNet fits

StableNet, built by SpendTheBits, is a cross border B2B payment and settlement platform for banks, credit unions, licensed money service businesses, exchange houses and remittance fintechs. It is designed around the identifier discipline this article describes: every settlement, in regulated stablecoins such as USDC and USDT on public blockchains, is tied to an ISO 20022 pacs.008 or pacs.009 inside a head.001 envelope and tracked end to end by UETR against the on-chain transaction hash, with pacs.002 status reports and pacs.004 returns carrying structured reason codes for the return path. Customers keep custody, so the chain record is the institution's own wallets. Wallet screening and KYT run on inbound transfers before they are matched, which is the control an unmatched inbound needs on day one, and the compliance workbench and tamper evident audit trail hold the evidence trail a reviewer pulls by identifier. SpendTheBits is a Bank of Canada registered payment service provider and a named finalist in the Swift Hackathon 2026 Technical Challenge.