> ## 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. # Screening > The risk screening included in every Flow payment, which payment sources are not screened, and what a blocked result does. Every Flow payment includes risk screening by default. Dynamic screens addresses at two points: your destination addresses when your server creates a flow, and the payer's wallet when the payer pays from a wallet. The result for the payer's source is recorded on the flow's risk axis, separately from execution and settlement. A payer's wallet is screened with your environment's [address screening](https://www.dynamic.xyz/docs/get-started/security/address-screening.md). The sanctions baseline always runs, so screening works without any setup. When you configure a screening provider and a [transaction policy](https://www.dynamic.xyz/docs/policies/screening-policies.md#a-sign-in-policy-and-a-transaction-policy), they apply to Flow payments too, and a policy that blocks the address blocks the payment. Fireblocks Flow also offers compliance checks that work outside a payment, such as wallet ownership verification. They are not part of this screening; see [Compliance](https://www.dynamic.xyz/docs/flow/compliance.md). ## What is screened and when | Address | When it is screened | If it is blocked | | - | - | - | | Your destination addresses | When your server creates the flow | The create request is rejected, and no flow is created | | The payer's wallet | Each time the payer attaches a wallet source, and again when the payer changes the amount on a `deposit` mode quote | The flow's `riskState` becomes `blocked`, and the request that triggered the screening is rejected | A wallet that passed screening when it was attached can still be blocked on a later `deposit` mode quote that changes the amount. Your UI should handle a blocked result on a quote as well as on attach. Screening does not run again after the payment is sent. A screening result that blocks or alerts on an address also sends the address screening [webhooks](https://www.dynamic.xyz/docs/embedded-wallets/mpc/policies/webhooks.md#screening-verdicts), the same as screening elsewhere in Dynamic. A sanctions block sends `wallet.sanctions.blocked`, and a block or alert from your own policy sends `wallet.addressScreening.blocked` or `wallet.addressScreening.alerted`. The event's `origin` is `flowSource` for a payer's wallet and `flowDestination` for one of your destination addresses. A screening that does not return a result sends no event. ## What is not screened Dynamic does not screen the funder of an exchange payment or of a deposit-address payment. When the payer attaches either source, the flow's `riskState` is set to `cleared` without screening. If your compliance program requires screening those payers, you are responsible for doing it. ## Risk states | State | Meaning | | - | - | | `unknown` | Screening did not return a result. The payment can continue. | | `cleared` | The wallet passed screening, or the payer chose a source that Dynamic does not screen | | `blocked` | The wallet was blocked by screening | ## What a blocked result does A blocked wallet cannot be used to pay. While `riskState` is `blocked`, the flow does not accept a quote or an approval for that wallet. A blocked result does not end the flow. The execution state does not change, and the payer can attach a different source to the same flow. You do not need to cancel the flow or create a new one. ## How risk can change The risk state can change until the payment is sent. Each time the payer attaches a source, the risk state is set again for that source: * A payer whose wallet was blocked can attach a different wallet that passes screening, or choose an exchange or a deposit address, and the risk state changes to match. * A payer who attaches a blocked wallet after a cleared one changes the risk state to `blocked`. * A screening that does not return a result sets the risk state to `unknown`. After the payment is sent, the risk state does not change. ## What your UI should do A screening rejection is an expected outcome, not an error to hide. A payer can connect a wallet successfully and still be refused, so your UI needs a state for it. * When attaching a wallet or requesting a quote is rejected because the wallet is blocked, tell the payer that this wallet cannot be used, and offer another source. * Do not retry the same wallet. Its result does not change on its own. * Decide fulfillment from your server, as described in [Access and data](https://www.dynamic.xyz/docs/flow/security.md#decide-fulfillment-on-your-server), and not from the risk state alone. The SDK guides cover the specific errors each SDK returns. ## Next > **[Payment sources](https://www.dynamic.xyz/docs/flow/payment-sources.md)** > > Which sources are screened, and how to choose which to offer. > **[Webhooks](https://www.dynamic.xyz/docs/flow/webhooks.md)** > > How risk changes are reported alongside execution and settlement. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.