# Identity allow-list

Source: https://docs.settlemint.com/docs/operators/compliance/identity-allow-list
Configure the DALP identity allow-list module so an asset accepts only the specific identities explicitly authorised by the compliance operator.



The identity allow-list compliance module restricts an asset to a specific set of authorised identities. Every regulated operation checks whether the involved identities are present on the asset's allow-list; the module rejects the operation if any participant is missing.

Use the allow-list when the holder base is small, explicitly approved, and managed case-by-case (private placements, club deals, investor-class lists).

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.
* Every prospective holder has a registered OnchainID in the identity registry.
* The approved holder list is signed off by your operating team. Each entry references the OnchainID address, not the wallet address.

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

In the Asset Designer compliance step, pick the identity allow-list module. Add OnchainID addresses for the initial authorised holders. An empty allow-list rejects every transfer once the module is enabled, so populate the list before the asset goes live or before enabling the module.

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

From the asset detail workspace, open the compliance tab and enable the identity allow-list module. Add or remove OnchainID addresses through the list editor. The platform queues an on-chain transaction per change; multiple additions can usually batch into one transaction.

## Operating considerations [#operating-considerations]

* The allow-list checks the OnchainID, not the wallet. A holder with multiple wallets registered under the same OnchainID passes for all of those wallets.
* Adding an OnchainID to the allow-list does not give the wallet tokens; it only permits future operations involving that identity.
* Removing an OnchainID does not move existing tokens; coordinate forced transfer or burn through the asset operating runbook when removal must take effect on existing balances.
* Per-asset allow-lists are independent. Adding an OnchainID to one asset's list has no effect on other assets.

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

Approval of new holders, periodic review of the authorised list, and the off-chain due-diligence that justifies adding or removing an OnchainID stay with your compliance team.

## Troubleshooting [#troubleshooting]

| What you see                                             | What to check                                                                                             |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Transfer rejected for an approved holder                 | Confirm the holder's wallet maps to a registered OnchainID and that OnchainID is on the allow-list.       |
| New OnchainID added but the holder still cannot transact | Confirm the on-chain transaction that added the entry has confirmed; the allow-list edit is asynchronous. |
| All transfers blocked after enabling the module          | The allow-list is empty. Add the authorised OnchainIDs and wait for the transaction to confirm.           |

## Read next [#read-next]

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