> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Programmable Compliance

> How institutions enforce payment rules through accounts, receive policy, and private proofs

Compliance is Metal's top priority because it determines whether
institutional finance can exist on a shared network at all. Metal builds
enforcement into its payment primitives. An institution configures policy
for the onchain identities it operates. During a payment, Metal invokes the
checks attached to the send and receive policy contracts and binds their decisions
to the asset movement.

## Send and receive controls

Each institution configures policies for the accounts it operates. The sending
and receiving institutions may operate in different jurisdictions and apply
different rules. A transfer reaches the recipient only if both policies
approve. If the recipient opts into quarantine, a refused credit is held in
escrow until it is recovered. Each
institution can therefore enforce its own requirements without trusting the
other to perform an offchain check.

![An account checks its spending rules before a MIP20 transfer. ReceivePolicy screens the intended credit, allowing the recipient credit, reverting an ordinary refused transfer, or holding refused funds in quarantine.](https://mintcdn.com/nexus-ed339086/RqZ8DjiF3RN_92qp/images/start/transfer-policy.svg?fit=max\&auto=format\&n=RqZ8DjiF3RN_92qp\&q=85\&s=7df41120a91398a7d1018f0aeeb9f4d9)

## Payment-control primitives

Metal provides primitives that institutions can compose to:

* Require a signed sanctions-screening result
* Enforce per-payment or cumulative limits
* Bind Travel Rule evidence to a payment
* Require signed evidence from an offchain decision service
* Restrict a specific onchain identity
* Allow only approved senders, recipients, or operators
* Route payments through an explicit call to a treasury or an account holding funds for review

These are building blocks. Each institution decides which rules apply to its
customers, products, and jurisdictions. Institutions can compose them and add
rules in their policies as their requirements evolve.

## Onchain enforcement and offchain decisions

Institutions can make policy decisions from public or private information. A
public rule can read onchain state directly. A private rule is evaluated by the
institution or its chosen service, then represented onchain by verifiable
evidence. Metal verifies the required authorization or policy result without
receiving the private inputs used to produce it.

| On Metal | Outside Metal |
| - | - |
| Authenticate signed policy decisions | Identify and onboard customers |
| Bind evidence to a specific payment | Perform screening and risk decisions |
| Verify signatures, commitments, and proofs | Produce and retain supporting evidence |
| Enforce rejection or quarantine | Review exceptions and make disclosures |

The institution decides which information its policy uses and which evidence
the transaction must carry. Encrypted offchain channels can deliver private
records between authorized parties, while Metal verifies the resulting
signature, commitment, or proof.

## Policy can vary by asset

Send and receive policies can use the token address to apply different rules
to different assets. An institution can set limits or permissions for one
MIP20 token independently of the other tokens an account holds.

> [card] [Write your first policy](https://docs.metalntwx.com/build/controls/restrict-token-transfers.md)
>
> Configure incoming rules and control outgoing payments.

> [card] [Compliance architecture](https://docs.metalntwx.com/learn/compliance/programmable-compliance.md)
>
> Compare the policy surfaces available across Metal payments.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.