# Identity block-list

Source: https://docs.settlemint.com/docs/operators/compliance/identity-block-list
Configure the DALP identity block-list module so an asset rejects specific identities for sanctions, fraud, or per-case compliance action.



The identity block-list compliance module rejects regulated operations when any involved identity is on the asset's block-list. Use the block-list to enforce sanctions, fraud responses, or per-case compliance actions without changing the asset's broader holder-eligibility policy.

The block-list is the inverse of the [identity allow-list](/docs/operators/compliance/identity-allow-list). Most assets use one or the other; combining both is unusual and produces the most restrictive policy.

For the architecture reference, see [Identity lists](/docs/compliance-security/security/compliance/identity-lists).

## Prerequisites [#prerequisites]

* The asset already exists (configure during creation) or you have the Asset administrator role on the deployed asset.
* The identities to block have registered OnchainIDs (the block-list operates on OnchainID, not on raw wallet address — for wallet-level blocking, use the [address block-list](/docs/operators/compliance/address-block-list)).
* Operating-team approval to block the identities, with documented justification for the compliance evidence pack.

## Configure during asset creation [#configure-during-asset-creation]

In the Asset Designer compliance step, pick the identity block-list module. Add the OnchainID addresses to block. Most newly created assets start with an empty block-list; entries land later as compliance events occur.

## Configure on an existing asset [#configure-on-an-existing-asset]

From the asset detail workspace, open the compliance tab and add or remove OnchainID entries on the block-list. The platform queues an on-chain transaction per change.

## Operating considerations [#operating-considerations]

* The block-list checks the OnchainID. A holder with multiple wallets under the same OnchainID is blocked across all of those wallets simultaneously.
* Adding an OnchainID to the block-list does not move existing balances. Coordinate forced transfer or escheatment through the operating runbook when the block must take effect on existing holdings.
* Removing an OnchainID from the block-list does not restore lost evidence. The compliance event that triggered the block stays in the audit trail.

## What stays external [#what-stays-external]

The decision to block an identity, the supporting due-diligence evidence, the disclosure to the affected party (where required by law), and the periodic review of the block-list stay with your compliance team.

## Troubleshooting [#troubleshooting]

| What you see                                  | What to check                                                                                             |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Holder still transacts after block-list entry | Confirm the on-chain transaction has confirmed; the block-list edit is asynchronous.                      |
| Block-list set on wrong OnchainID             | Remove the incorrect entry, add the correct one. Each change is a separate transaction.                   |
| Whole-wallet block needed instead             | Use the [address block-list](/docs/operators/compliance/address-block-list) for wallet-level enforcement. |

## Read next [#read-next]

* [Compliance overview](/docs/operators/compliance/overview)
* [Identity allow-list](/docs/operators/compliance/identity-allow-list) for the inverse module.
* [Address block-list](/docs/operators/compliance/address-block-list) for wallet-level blocking.
* [Identity lists architecture](/docs/compliance-security/security/compliance/identity-lists)