Configure a Screening Policy

This page walks through authoring a screening policy 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.

​

Prerequisites

• Your own provider key for TRM Labs or Chainalysis, stored on the environment. See 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 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 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: 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.

​

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: 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.

​

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.

​

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. 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.

​

If a save fails

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 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 for the guarantees that hold regardless of how a policy is authored.