Each procedure names who acts and the calls it takes. Releasing any stop takes the approvers its control requires, so no procedure here goes around four eyes.

​
Stop and resume

  1. Risk pauses it: POST /v1/instruments/{instrumentId}:pause with a rationale. One call holds the asset, at once.
  2. The asset reads paused on GET /v1/instruments/{instrumentId}, and instrument.paused goes to the feed and the webhooks.
  3. To resume, release the hold: risk asks, two approvers sign.
The pause stops what NodeAsset does. It cannot stop a transfer between two custodians, which never reaches the engine. The registrar can stop such a transfer by archiving the asset’s configuration on the Registry: every Registry choice on the asset then fails until the registrar creates the configuration again with the same fields. Pause NodeAsset first, so its own settlements end cleanly. The restored configuration has a new contract id, which wallets and the engine read afresh.
A hold stops an asset’s distributions, redemptions and new issuance. A newer, agreeing statement clears the finding behind it, never the hold.
  1. Read the latest run, GET /v1/reconciliation-runs/latest, and confirm the finding is answered.
  2. Risk asks for the release: POST /v1/holds/{holdId}:release.
  3. Two approvers, neither the maker nor an auditor, approve it (POST /v1/approvals/{actionKey}:approve). hold.released goes to the feed and the webhooks.
  1. Reconciliation finds the cover below the minimum, holds the backed instrument and announces reserve.cover-low. New mints are refused; redemptions go on.
  2. The issuer restores the cover: the reserve’s holder tops a par reserve up with assets of its own, or the price source publishes a fresh point where a stale price caused it.
  3. The next run finds the cover met. Risk asks for the hold’s release, and two approvers sign it.
POST /v1/standing-approvals/{standingApprovalId}:revoke, by the operator, risk or approver role, alone. It takes effect at once, and standing-approval.revoked is announced.

​
Findings

  1. Reconciliation finds the mint and holds the asset, naming the run (GET /v1/reconciliation-runs/{reconciliationRunId}).
  2. The registrar burns the units back, naming that run as the burn’s reference.
  3. The next run explains the burn by the finding it named, and is clean.
  4. Release the hold: risk asks, two approvers sign.
A burn that names a run which found less, or nothing, is itself a finding.
A pulled kill switch, an expired NAV, or an official NAV that disagrees with the price source’s on the ledger holds the asset.
  1. The administrator sends a fresh NAV, or lowers the kill switch. The next run clears the finding.
  2. Risk asks for the hold’s release, and two approvers sign it.
On an asset that rebases, a transfer between two custodians moves units away from their income, so the finding holds the asset. A registered succession explains a holder’s move to its successor; anything else is investigated, then the hold released under two approvers. On a par or accumulating asset the transfer is reported only.

​
Orders

A subscription or a redemption whose investor allocated, but which can no longer settle (the order was closed, or its deadline passed), would leave the investor’s cash or units set aside until that deadline.
  1. Release it: POST /v1/subscriptions/{subscriptionId}:release or POST /v1/redemptions/{redemptionId}:release. The venue, as the settlement’s executor, cancels the investor’s allocations and withdraws its request in one transaction.
  2. Withdraw the order, or ask the investor again.
An act refused 409 package-not-vetted names the package and the party whose node has not vetted it. That node’s owner vets the release’s package; the same request then goes through.
One leg refused on either registry refuses the whole cycle, and nothing moves. Release the cycle, POST /v1/dealing-cycles/{dealingCycleId}:release, and open a new one without the order at fault.

​
The engine and its connections

Health answers connected: false. A write’s operation fails with the problem ledger-unavailable, and a call that waits on the ledger answers 503 with a Retry-After. Once health answers connected again, read the resource to see whether the write took effect, then send it again under a new Idempotency-Key.
Calls answer 503 idp-unavailable with a Retry-After: the engine cannot fetch the provider’s keys, and the caller’s token may be fine. Restore the engine’s reach to the provider’s key set; nothing else changes.
When the engine is ready, it resolves every operation the previous process left queued or running. A settlement whose start was recorded carries on from the ledger. A distribution caught mid-way fails with its resume call, POST /v1/distributions/{distributionId}:resume, which finishes it under the approval it already has. Anything else fails interrupted, with what to check before repeating it: read GET /v1/operations?state=failed.
Restore it from a backup, or start a fresh one at the right reconciliation offset. See Backup and recovery.
Related: Monitoring · Holds, freezes and issuer powers · Reconciliation