> ## 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. # Compliance > The screening and verification checks that run on a flow, which are on by default, and which you opt into. 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](/docs/flow/webhooks). ## 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 How risk state is reported alongside execution and settlement. Dynamic's wider security posture and screening configuration.