> Source: [/docs/resources/guides/compliance-controls](https://tempo.xyz/developers/docs/resources/guides/compliance-controls.md) > Section: [Get Started](https://tempo.xyz/developers/get-started.md). Choose a starting point, send a test payment, get testnet funds, connect a coding agent, find the SDKs and CLI, and use the resource guides to plan payment workflows, liquidity, provider selection, and partner integrations. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. [Guides](https://tempo.xyz/developers/docs/resources/guides) / [Compliance and security](https://tempo.xyz/developers/docs/resources/guides#compliance-and-security) / Token and receive controls # Token and receive controls Use TIP-20 roles for privileged token operations, TIP-403 policies for token access rules, and receive policies for an account's incoming assets. Keep the institution's screening decisions and case records separate from the technical controls that enforce them. For address risk checks and transaction monitoring, start with [Screen blockchain payments](https://tempo.xyz/developers/docs/resources/guides/payment-screening). ## Choose the control for each responsibility | Responsibility | Tempo control | Application or institution responsibility | | --- | --- | --- | | Restrict token circulation | TIP-403 token policies. | Supply, review, and maintain the underlying address decisions. | | Limit incoming transfers | Account-level receive policy. | Set accepted senders and tokens, choose recovery authority, and handle held receipts. | | Pause token movement | TIP-20 pause and unpause roles. | Approve the action, protect the role holders, and document its basis. | | Burn eligible balances | Dedicated TIP-20 burn authorities and guard receipt rules. | Establish authority for the action and preserve the approval and case evidence. | | Connect a transfer to a case | A supported 32-byte transfer memo. | Store personal and case information offchain and control access to it. | These controls enforce decisions; identity checks and sanctions screening happen in your application or provider. An allowlist records policy membership only, so keep the address-to-customer mapping current offchain. ## Separate issuer roles [TIP-20 roles](https://tempo.xyz/developers/docs/protocol/tip20/spec#tip-20-roles) separate minting, pause controls, and burn authorities. Give each role only to the accounts authorized for that operation and protect the ability to grant or revoke roles. * `ISSUER_ROLE` controls minting and issuer burning operations. * `PAUSE_ROLE` and `UNPAUSE_ROLE` control the token's paused state. * `BURN_BLOCKED_ROLE` permits burning eligible, unprotected balances from addresses that fail the TIP-403 sender check. * `BURN_AT_ROLE` permits burning an unprotected balance without TIP-403 authorization, subject to the specification's checks. Own-balance burning, burning a blocked balance, and `burnAt` are different operations. Burning reduces supply; it doesn't move funds to another account. Guard-held funds have [separate receipt-level burn rules](https://tempo.xyz/developers/docs/protocol/tip403/receive-policies#burns). Pausing affects token movement, while administrative functions and protocol operations have their own rules. Read the [pause controls](https://tempo.xyz/developers/docs/protocol/tip20/spec#pause-controls) before relying on a pause as an emergency response. ## Configure token-level policies The [Tempo Policy Registry](https://tempo.xyz/developers/docs/protocol/tip403/spec) supports simple allowlist and blocklist policies and compound policies. A compound policy can select different rules for senders, transfer recipients, and mint recipients. An issuer associates a policy with its token. Policies can be shared across tokens, so a change to a shared underlying policy can affect several assets. Record that dependency when approving a policy update. For customer-based restrictions, maintain the customer-to-address mapping offchain and update policy membership through an authorized workflow. Preserve who approved the change, the affected addresses and tokens, the transaction, and the internal case reference. Start with [managing an issued stablecoin](https://tempo.xyz/developers/docs/guide/issuance/manage-stablecoin) and the [TIP-403 specification](https://tempo.xyz/developers/docs/protocol/tip403/spec). ## Handle receive-policy holds as a separate outcome A [receive policy](https://tempo.xyz/developers/docs/accounts/policies/receive-policies) controls which senders and TIP-20 tokens an account accepts. It is an inbound control, not a general outbound transaction policy. Token-level checks run first and revert on failure. If those checks pass but the receiver's policy blocks delivery, the call succeeds while funds are held in `ReceivePolicyGuard`. The token's `Transfer` event names the guard as the recipient, so don't credit the intended receiver on transaction success. Handle each outcome separately: | Outcome | Payment handling | | --- | --- | | Token policy rejects the operation | Record the failed attempt; do not credit delivery. | | Receive policy holds the inbound | Index the blocked receipt and route it through the authorized recovery process. | | Expected transfer reaches the receiver | Verify the token, recipient, amount, and successful transaction before crediting it. | Each blocked inbound creates a receipt. The receipt captures the recovery authority in effect for that inbound; changing the account's authority affects future receipts. Claims consume a full receipt, and the allowed destination and current policy checks depend on the claim path. Held funds aren't part of the account balance; the [receive-policy specification](https://tempo.xyz/developers/docs/protocol/tip403/receive-policies) defines the claim rules. ## Keep compliance records offchain [Transfer memos](https://tempo.xyz/developers/docs/guide/payments/transfer-memos) carry a 32-byte reference through supported TIP-20 methods. Use an opaque identifier to connect a payment to internal records. Do not put names, identity documents, account details, or other personal data in a public memo. A memo isn't an information-sharing message. [FATF's virtual-asset standards](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Regulation-virtual-assets-interpretive-note.html) call for covered providers to obtain, retain, and transmit originator and beneficiary information, which doesn't need to travel with the onchain transfer. Keep that information and the exchange evidence in offchain systems. Before updating a customer or case ledger, verify delivery with the [receiving guide](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment), not only the matching reference. ## Test control changes before operating them :::steps ### Map the authorities List each token, policy, role holder, receive account, recovery authority, and offchain decision owner. Identify shared policies and the accounts that can change permissions. ### Exercise permitted and blocked paths Test allowed transfers, issuer-policy rejections, receiver holds, authorized claims, and the pause behavior your application depends on. Check that a held transfer never credits a customer. ### Preserve action and decision evidence Link policy and role changes, blocked receipts, claims, and burns to internal approvals and case records. Monitor changes to privileged authority and provide a way to stop new application submissions during an incident. ::: ## Token control questions ### Does TIP-403 perform KYC or sanctions screening? No. It enforces configured address policies. Your institution or provider supplies the identity, screening, and review workflow behind those decisions. ### Can an account reject an unsupported token? It can configure a receive-policy token filter. A blocked inbound is held by the guard rather than credited to the account. Index and handle the resulting receipt. ### Does an onchain control establish legal compliance? No. Onchain controls enforce the institution's decisions. Compliance also depends on the applicable requirements and the institution's own workflow.