Digital money needs rules as well as rails.

The requirement

Account-level payment policy attaches spending, receiving or settlement rules to the account that holds or moves value, so transactions can be evaluated as they occur rather than only inside a separate application. It is a control architecture, not a substitute for licensing, screening or legal responsibility.

An asset-control model defines who may hold the asset, who may receive it, who may send it, which counterparties are permitted, when freeze or recovery applies, what conditions a transaction must meet, what the issuer can see, and how operational signing is governed.

Some of that can sit in native ledger controls. Some of it belongs as custom policy on the account. Much of it remains off-chain. The design work is placing each rule at the right layer.

Native issuer controls.

On Xahau, several institutional controls are ledger-native rather than application inventions. They matter where the issuer of the settlement asset must remain able to authorise holders and act on the asset model. Two of them are design-time decisions: holder authorisation and clawback can only be switched on before anyone holds a trust line to the issuer, and clawback also requires that the issuer’s account owns no other ledger objects.

Holder authorisation RequireAuth

The issuer can require explicit authorisation before a trust line may hold its issued asset.

Freeze including deep-freeze

Individual, global and deep-freeze mechanisms let an issuer restrict movement of an issued asset where the asset model allows it.

Clawback enabled before any trust lines

The issuer can revoke previously issued balances where the asset model provides for it. Clawback cannot be combined with a no-freeze commitment.

Deposit authorisation DepositAuth

Receiving accounts can require preauthorisation before they accept value.

Account-level custom policy.

Where the rule is specific to an institution’s operating model, programmable logic can attach to the account that holds or moves value. Business patterns include approved counterparties, backend approval before a payment proceeds, transaction-size limits, currency or issuer restrictions, time-bound controls, and multi-step institutional workflows. Each rule needs an owner, a source of authoritative information and an agreed response when a payment cannot proceed.

Opt-in issuer transaction hooks.

An issuer can opt in to weak (collect-call) execution, so that its account logic runs after third-party transactions that involve its issued currency. The issuer pays for that execution, and it cannot roll back the third-party transaction. It can update issuer state or emit follow-up transactions. It is a visibility and policy surface, not a veto over holder payments.

Protocol identifier: IOUIssuerWeakTSH – see Xahau documentation. · Weak and strong transactional stakeholders ↗

Keys are not business policy.

Regular keys and signer lists govern who may authorise a transaction. Account-attached logic can govern what the transaction is allowed to do. Design both together: who can sign, who can change the rules, and how access and policy are reviewed.

What remains off-chain.

A ledger can enforce a rule. It cannot decide what the law requires.

• KYC records
• sanctions data
• customer files
• legal agreements
• regulatory reporting
• adverse media
• human decisions