Skip to main content
Address screening checks a wallet address against sanctions data before that address is allowed to authenticate. Dynamic screens every wallet address that signs in to your environment or is linked to a user. Screening runs server-side. You do not call it, and you cannot skip it.

​
Default behavior

  • Sanctions screening runs on every wallet address at sign-in and when a wallet is linked to an existing user.
  • Screening uses Dynamic-managed sanctions data compiled from government sanctions lists, including the OFAC Specially Designated Nationals (SDN) list.
  • Screening cannot be disabled. The dashboard shows Block Access to Sanctioned Wallets as permanently on.
  • Every wallet on the user’s account is screened on each verification: embedded, external, and smart contract wallets.
  • If any wallet on the account matches, the whole sign-in is rejected. It is not enough to disconnect the matched wallet during that attempt.

​
What blocks an address

An address is blocked when screening returns a sanctions match:
  • the address is on a sanctions list, or
  • a screening vendor attributes the address to a sanctioned entity or a sanctioned jurisdiction.
The following do not block an address:
  • a vendor risk score or risk rating, at any value
  • indirect or counterparty exposure to a sanctioned address
  • non-sanctions vendor categories, such as gambling, mining, or scam attribution
Dynamic blocks on sanctions signals only. Dynamic does not apply risk-based blocking, and does not block on your behalf for any other category.

​
Bring your own screening key

Bring your own screening key is in Beta and is enabled per environment. To enable it, contact us through Slack or email.
By default, screening uses Dynamic-managed screening. You can instead supply your own vendor API key, so screening calls run against your contract with that vendor and appear in that vendor’s audit trail. Two vendors are supported:
  • TRM Labs — the Wallet Screening API. Requires a TRM Labs contract that includes wallet screening.
  • Chainalysis — the Address Screening API. Requires a Chainalysis contract that includes address screening.
Best for: compliance teams that already hold a vendor contract and need screening decisions, billing, and audit logs to sit in their own vendor account. Supplying your own key changes which account the screening call bills to and which vendor data backs the decision. It does not change what blocks an address: the sanctions-only rules above still apply.

​
Add a key

  1. Open Fraud Protection in the dashboard.
  2. Under Security Integrations, find Bring Your Own Screening Key.
  3. On the TRM Labs or Chainalysis card, select Add, paste your API key, and save.
You must have the Admin role on the environment to add, update, or remove a key. Members with a lower role see the section read-only. Dynamic validates the key against the vendor before storing it. A key the vendor rejects is not stored, and the dashboard reports why: an invalid key, a key in the wrong format, a rate or quota limit on your vendor account, or a vendor that could not be reached.

​
How your key is used

  • Keys are scoped to one environment. Sandbox and live environments hold separate keys.
  • You can configure one vendor or both. When both are configured, both run on every screen.
  • If either vendor returns a sanctions match, the address is blocked.
  • If every configured vendor call fails, screening falls back to Dynamic-managed sanctions screening for that check.
  • Keys are encrypted at rest. The dashboard shows only the last three characters, and no API returns a stored key.

​
Rotate or remove a key

  • Update replaces the stored key. Screening uses the new key on the next check.
  • Remove deletes the stored key. Screening returns to Dynamic-managed screening on the next check.
Dynamic does not notify you when your vendor key stops working. Monitor wallet.sanctions.blocked volume and your vendor’s own dashboard to confirm your key is still in use.

​
When an address is blocked

  • Dynamic rejects the verification request with 403. No JWT is returned, so the user does not reach an authenticated state.
  • The end user sees an access-denied view instead of completing sign-in. Dynamic’s UI renders this view; SDKs without Dynamic’s UI surface a typed screening error you handle yourself. See the address screening page for React, React Native, or JavaScript.
  • Dynamic sends a wallet.sanctions.blocked webhook event containing the blocked address, the chain, and which provider produced the match.

​
Your responsibilities

  • Dynamic screens addresses against sanctions data and blocks matches.
  • You are responsible for your own compliance program, including any risk-based decisions, record keeping, and reporting obligations that sanctions screening alone does not satisfy.
  • You are responsible for keeping any vendor key you supply valid and funded.
Last modified on August 26, 2026