# Custody reconciliation

Source: https://docs.settlemint.com/docs/console/organisation-settings/custody-reconciliation
Work the reconciliation break register in the DALP Console: assign breaks, record investigations and resolve or write them off with a second approval.

Custody reconciliation keeps every difference a registrar file reconciliation finds on record in a break register. A break stays open until a later clean run closes it, until a resolution or write-off is applied after the required approvals, or at once when the custody-ops approval family is off. The **Reconciliation** tab shows that register.

A separate reserve check compares the supply of a custody receipt, the token that represents coins held at custody addresses, with the coins held at those addresses. A difference it finds raises an operations case labelled "Balance difference". The [concept page](https://docs.settlemint.com/docs/concepts/records-and-evidence/reconciliation#custody-reconciliation) describes both. The platform does not read the custody provider's own statements, so compare those statements separately, outside the platform.

## Before you start [#before-you-start]

- Select the active organisation. You need its Owner role, or platform administrator access.
- Custody operations must be enabled on the deployment. Without them, the "Custody" page does not show the "Reconciliation" tab. If you open the tab's link directly as an Owner or platform administrator, it reads that custody operations are not enabled for the deployment. Anyone else who opens a Custody link directly sees the Not available page.
- The **Custody operations** row under "Approvals" on the organisation's [General](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals) page decides whether resolving or writing off a break waits for a second person.

  It reads "Not required" until an owner or platform administrator turns it on, and while it reads "Not required", the change applies at once. With it on, a second Owner or platform administrator must approve. When the row's "Approvals required" count is more than 1, that many different people must approve.

  The user who asks cannot approve their own request, a member who is neither an Owner nor a platform administrator cannot approve, and a session that an administrator has borrowed to act as another user cannot approve. Approval follows the platform's maker-checker rule: the maker asks and a different checker decides.

## Steps [#steps]

### Open the break register [#open-the-break-register]

In the sidebar, open "Custody" under "Business operations", then **Reconciliation**.

The tab shows the "Reconciliation break register". A registrar file reconciliation, which compares a registrar's holder file with the chain, opens a break for every holder line that does not match, but only when an Owner or platform administrator ran it. The platform identifies a break by wallet, asset and cause.

The register shows up to 200 matching breaks, longest age first. If more than 200 match, narrow "Status" or "Cause" to reach the rest. Each row shows "Wallet", "Asset", "Trade", "Amount", "Cause", "Age", "Owner", "Status" and "Actions". "Asset" and "Amount" show the token's symbol and unit where the platform knows them, and base units where it does not. When nothing matches, the table reads "No breaks match these filters".

- **Cause** is "External" for a break that a registrar file reconciliation opened. The filter also offers the other causes a break can carry, including "Other".
- **Age** counts weekdays from the break's first sighting to the latest run that saw it. It changes only when a run touches the break. It falls in the buckets 0 to 1, 2 to 5, 6 to 10 and more than 10 days. The organisation's holiday calendars do not apply.
- **Amount** shows a dash in the table, and "Unavailable" in the break's sheet, when the platform does not know the break's amount. The platform keeps that amount empty and never writes it as zero.

The register opens on "Open" breaks. "Status" and "Cause" are menus. Choose a value to narrow the list, or "All" to drop that filter. Choose a member in "Owner" and select **Assign** to give a break an owner, or choose "Unassigned" to remove it. When the member directory cannot be read, the field takes the member id instead.

A later registrar file reconciliation keeps updating an open break instead of creating a duplicate. A run that finds the same wallet, asset and cause clean sets the break to "Resolved automatically", with no note or approval. The platform rejects a pending resolution request when the break's amount changes or when a clean run clears the break.

A closed break is never edited again, and it cannot be assigned or moved: its sheet says the break is closed and offers no status change. If a difference returns after a resolution, the platform 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 ends that cover, so if the difference returns or changes, the platform opens a new linked break. The approved write-off, its note and its maker and checker stay as recorded.

### Review withdrawal destinations [#review-withdrawal-destinations]

Below the register, the "Withdrawal destinations awaiting review" table lists the addresses that investors proposed as withdrawal destinations and proved they control by signing. Each row shows the customer, the destination address and when it was proved. The **Actions** inbox also lists each one as a "Review withdrawal destination" row, with a "Review destination" link to this tab.

Select **Clear** to make a destination active, or "Refuse" to reject it for good. Both ask for a reason. The user who proved a destination cannot review it, and neither can an administrator who proved it while acting as that user. Their row shows that another custody operator must review it, with no buttons. On each network, an address can be active on only one investor's entry. Clearing another investor's entry for that address on the same network is refused.

## What the platform checks [#what-the-platform-checks]

- **Scope.** Each organisation sees only its own breaks. Reading or changing a break needs the organisation's Owner role or platform administrator access.
- **Precision.** Every amount is an integer in the asset's smallest unit, carried as text, so no total loses precision.
- **Audit.** The platform records the read as a sensitive read and the assignment and status change as changes. The assignment and status change need a fresh session, not a cached one.

## You should see [#you-should-see]

- In the break register, filter to **Open** and check that every remaining break has an owner.
- Filter to "Resolved" or "Written off" to check that a break you closed shows the approved change.
- In "Withdrawal destinations awaiting review", check that each address you cleared or refused no longer awaits review.

## Troubleshooting [#troubleshooting]

**The tab shows an access message instead of the register**

Custody is managed by organisation owners and platform administrators, so ask an Owner for access. If the message says
custody operations are not enabled, the deployment has them switched off and the Console hides the register.

**A resolved or written-off status did not apply**

With the "Custody operations" approval on, the change waits for a second user. Check that a different Owner or
platform administrator approved the request in the "Actions" inbox, then open the break with "Review" and select
**Complete checker approval**. The control stays on the sheet after a reload. If the approver rejected the request or
it expired, the same control closes it and the sheet offers "Save status" again. A different note or status than the
one approved is refused while the request waits.

## API routes [#api-routes]

The Console reads and writes the break register through routes that serve the Console only. The platform marks them as Console routes, so the [Platform API reference](https://docs.settlemint.com/docs/api-reference/v2) does not publish them. The published reporting routes offer a `break-ageing` report, which reports the register's breaks by age. A reporting obligation can include it in its report set. `GET /api/v2/reporting/capabilities` lists it when the deployment's report catalogue includes it.