Skip to main content
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. The sanctions baseline always runs, so screening works without any setup. When you configure a screening provider 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.

​
What is screened and when

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

​
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, and not from the risk state alone.
The SDK guides cover the specific errors each SDK returns.

​
Next

Payment sources

Which sources are screened, and how to choose which to offer.

Webhooks

How risk changes are reported alongside execution and settlement.
Last modified on October 27, 2026