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

# Configure a Screening Policy

> Author a screening policy in the developer console: choose which addresses reach the provider, map provider signals to block or alert, and except individual addresses.

This page walks through authoring a [screening policy](/docs/policies/screening-policies) in the developer console, from a stored screening provider key to a saved policy.

The policy editor and the API write to the same policy. To author through the API instead, see [Screening policy rules](/docs/policies/screening-policy-rules).

<Note>
  Screening policies are in Beta and are enabled per environment. To enable them, contact us through [Slack or email](/docs/get-started/welcome#support-&-feedback).
</Note>

## Prerequisites

* Your own provider key for TRM Labs or Chainalysis, stored on the environment. See [bring your own screening key](/docs/get-started/security/address-screening#bring-your-own-screening-key).
* The Admin role on the environment.
* Screening policies enabled for the environment.

## 1. Open the policy editor

1. Open [Fraud Protection](https://console.dynamic.xyz/dashboard/fraud-prevention) in the developer console.
2. Under **Compliance Screening**, find **Bring Your Own Screening Key**.
3. Select **Edit policy** on the **TRM Labs** or **Chainalysis** card.

The card shows how many rules the provider holds across its sign-in policy and its transaction policy. A rule with more than one threshold counts once.

The editor is a page with its own URL, such as `/dashboard/fraud-prevention/screening/trm/policy/sign-in`. The URL names the screening provider, `trm` or `chainalysis`, and the policy, `sign-in` or `transactions`. The URL is linkable and survives a reload. A URL that names a provider or a policy that does not exist redirects rather than rendering an editor.

Each provider has its own policies. Configuring TRM Labs does not change anything about Chainalysis.

## 2. Choose the sign-in or transaction policy

The editor has one tab per policy: **Sign-in** for the sign-in policy and **Transactions** for the transaction policy. See [a sign-in policy and a transaction policy](/docs/policies/screening-policies#a-sign-in-policy-and-a-transaction-policy) for what each covers.

* Each tab is a separate policy with its own rules and its own save.
* Switching tabs does not discard edits. A dot on a tab marks unsaved changes on the policy you are not looking at.
* Saving applies to the policy on screen only.

## 3. Choose which addresses are screened

**When to screen** decides which addresses are sent to the provider at all. It runs before the provider call, so it reads only the address, the chain, the asset, and the USD amount. An address skipped here is never evaluated against your rules.

Each control reads as part of a sentence:

| Control | Tab | When left empty |
| - | - | - |
| **Screen**, followed by chains | Both | Shows **Any chain**. Every chain is screened. |
| **when the asset is**, followed by assets | Transactions only | Shows **any asset**. Every asset is screened. |
| **Don't screen transfers under** a USD amount | Transactions only | Every transfer is screened, whatever its value. |

Each control narrows what is screened. Anything outside what you list is not sent to the provider. A sign-in carries no transaction, so the **Sign-in** tab has no asset or amount control.

To stop calling the provider for this policy entirely, turn on the switch labeled **Disable sign-in address screening** on **Sign-in**, or **Disable transaction address screening** on **Transactions**. Each label names the provider it stops calling. While the switch is on, the other controls are hidden.

<Warning>
  An asset is matched against the symbol the transaction reports, ignoring case, so `usdc` matches `USDC`. Otherwise the match is exact, so `USDC.e` does not match `USDC`. A transaction whose asset is not on the list is not screened, so a misspelled symbol such as `USCD` stops those transfers from being screened at all. A transaction that reports no asset is still screened.
</Warning>

<Warning>
  Skipping the provider call drops that provider's own sanctions and ownership blocks at that surface. Dynamic-managed screening runs in its place, so the address is still checked against Dynamic's own sanctions list.
</Warning>

## 4. Add a rule

Under **Rules**, select **Add a category rule** and choose a category. Categories come from the provider's own taxonomy, so the list differs between TRM Labs and Chainalysis. The TRM Labs list is grouped by theme, with anything outside a group under **Other**.

A new rule reads as a sentence:

> **Alert** an address when **the address itself** is flagged as **Mixer** at **any risk**

Each highlighted part is a control you select to change:

| Part | Choices |
| - | - |
| The action | **Block** or **Alert**. Select it to switch between the two. |
| The relationship | **the address itself**, **someone it dealt with**, **someone further out**, or **anyone in its history**. You can choose more than one. |
| The category | Any category in the provider's taxonomy. |
| The risk level | **any risk**, **low risk**, **medium risk**, **high risk**, or **severe risk**. A level matches at or above itself. |

The relationship is where the category has to appear in the provider's response. **the address itself** means the address carries the category. **someone it dealt with** means a direct counterparty carries it, and **someone further out** means indirect exposure carries it.

An alert never blocks and never holds a request for review. The editor authors block and alert rules only. An allow rule is authored through the API.

Each policy holds at most 200 rules. At the limit, the editor stops offering **Add a category rule** rather than dropping a rule. A category can hold one rule per choice of relationships, so the editor does not offer a combination another rule already covers.

### Adding thresholds

Select **+ tier** to act differently at different risk levels. The added threshold hangs below the rule and reads **otherwise**, followed by its own action and risk level. A common shape is to block a category at **severe risk** and alert on it at **medium risk**.

Within one rule, the stricter action is evaluated first, and a higher risk level before a lower one, whatever order you added them in. Ordering within a rule is therefore not something you set. Ordering between rules is, and it is covered in the next step.

Select **+ \$** on a threshold to apply it only **on transfers of** a USD amount **or more**.

<Warning>
  A threshold with an amount never matches where the USD amount is unknown, and evaluation moves on to the next rule. The amount is established only for Flow, checkout transactions, and the explicit context accepted by the screening API. Every sign-in has no amount, so on the **Sign-in** tab a threshold with an amount never matches.
</Warning>

### Deleting a rule

Delete a rule from its row. A notice appears with **Undo**, which puts the rule back in its original position. Only the most recent deletion can be undone.

## 5. Put the rules in order

Rules are evaluated top to bottom and the first match decides. One address can match more than one rule, so order changes the verdict. Each rule shows its position number.

* The sanctions baseline is always first. It reads **Block** an address when it is flagged as **Government-sanctioned**, and cannot be edited or moved. Select **Show the rule** to read the rule it compiles to.
* Address exceptions are evaluated after the baseline and before your rules.
* Your rules follow, in the order shown. Use the move controls beside a rule to reorder it. Moving past an advanced rule moves over the whole rule.
* An address that matches none of your rules is allowed.

<Warning>
  An alerting rule placed above a blocking rule decides first, and the block never runs. The editor marks a rule in that position. Put the strictest rule for an overlapping category above the looser one.
</Warning>

## 6. Except individual addresses

An address exception always blocks or always exempts one address. The **Address exceptions** section is marked **Shared by sign-in and transactions**, because entries belong to the provider rather than to one policy.

Select **Add an address**. In **Add an address exception**, set:

* **Decision**: **Block this address**, or **Exempt from screening**. Block is the default.
* **Address**, exactly as it appears on its chain.
* **Chain**, or **Any chain**. Leaving it as **Any chain** is the common case.
* **Applies to**: **Both**, **Sign-in**, or **Transactions**.
* **Label**, an optional note up to 255 characters.

Select **Add exception** to save the entry. An exception is written as soon as you add or remove it, not when you save the policy.

<Warning>
  An exempt address is still blocked if it is sanctioned. The sanctions baseline runs above this list, so an exemption excuses an address from your own rules and nothing more.
</Warning>

An address already listed for that provider and chain is refused. Remove the existing entry to change its decision.

## 7. Save

A bar appears at the bottom of the page as soon as you change something, showing **Unsaved changes** with **Save changes** and **Reset**.

* **Save changes** writes the policy on screen. The other tab keeps its own draft.
* **Reset** discards the draft and reads the stored policy again.
* Developer console navigation is disabled while the bar is showing, so a policy cannot be half-edited and walked away from.

<Note>
  A saved policy is live everywhere within 60 seconds. Testing immediately after saving can still return the previous result. The sanctions baseline is never affected.
</Note>

### If a save fails

| What you see | What happened | What to do |
| - | - | - |
| This policy changed somewhere else since you opened it | Another edit was saved after you opened the page. Your write was rejected rather than applied over it. | Select **Reload**, then reapply your edit. |
| Your changes were saved, but this editor could not pick up the new version | The write committed. The read after it did not. | Select **Reload** before editing again. |
| This policy could not be saved. Please contact support | The rules were rejected as invalid. | Contact support, quoting the request ID if one is shown. |
| This policy could not be loaded | The read failed. What is on screen may not be what is live. | Select **Retry** before making changes. |

A failed read is not an empty policy. The editor says so rather than showing an empty rule list.

## Rules the editor cannot express

The editor writes one rule shape: a provider category, where that category has to appear, and one or more thresholds on risk level and amount. Anything else is an advanced rule, authored through the API.

* An advanced rule is shown read-only, at its real position in the evaluation order, with **Show JSON** and **Delete rule**.
* Saving from the editor does not rewrite an advanced rule and does not move it.
* An advanced rule does not disable the editor. Rules the editor recognizes stay editable.

See [Screening policy rules](/docs/policies/screening-policy-rules) for the format.

## What the editor does not offer

* No enable or disable control for a policy. Deleting the policy through the API leaves only the sanctions baseline for the screening that policy covered.
* No rule templates.
* No dry run. There is no way to test an address against a draft.

See [what a policy cannot do](/docs/policies/screening-policies#what-a-policy-cannot-do) for the guarantees that hold regardless of how a policy is authored.


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