Skip to main content
Compliance checks apply to every flow. Some are always on; others you enable when your risk posture or your regulator calls for them. Risk is tracked as its own axis on a flow, separately from execution and settlement, so a flow reports a compliance outcome independently of whether the money moved. See Webhooks and events.

On by default

Sanctions screening. Connected wallet addresses are screened before funds move. A payer whose address is flagged is stopped at that point rather than mid-settlement. Geographic restrictions. Access is blocked by IP according to the configuration on your environment.

Optional

Signature verification. Require the payer to sign a message proving they control the wallet they are paying from. This is the prerequisite for spam token filtering. Spam token filtering. Known spam tokens are blocked. Available once signature verification is enabled. Name matching. Verify the depositor’s identity against an expected name, for flows where you already know who should be paying.

Handling a rejection in your product

A screening rejection is a normal outcome rather than an error to swallow. The reader-facing consequence is that a payer can connect a wallet successfully and still be refused, so your UI needs a state for it. The pattern is the same as for wallet connection generally: detect the rejection and show a clear access-denied experience rather than letting a transaction fail without explanation. The per-SDK guides under Implement cover the client-side handling.

Next

Webhooks and events

How risk state is reported alongside execution and settlement.

Security

Dynamic’s wider security posture and screening configuration.
Last modified on September 21, 2026