Transaction Screening Operations

After a transaction is screened, you can read its full compliance result and act on that specific transaction: bypass a rejection, rescreen it, or freeze and unfreeze its funds. These operations apply to one transaction at a time. To change what happens to future transactions, update your policy instead. See Compliance Policies.

What happens after screening

What happens next depends on the Outcome (Post-Screening Policy) and on direction:

Outcome	Outgoing transaction	Incoming transaction
Accept	Continues to Policies approval and signing, then is broadcast.	Completes, and the funds are available in your wallet.
Alert	Same as accept. The transaction is also flagged for review.	Same as accept. The transaction is also flagged for review.
Reject or freeze	Ends as `REJECTED` and is never sent to the blockchain. No funds move, so nothing is frozen: a freeze action rejects an outgoing transaction.	The funds are already in your wallet, so Fireblocks freezes them. The rest of the wallet keeps working; only the funds from that transaction cannot be spent.

Transaction states

The Console and the API describe the same states with different labels. See Sub-statuses for the full list of subStatus values.

Console	API	What you can do
Screening	`status` is `PENDING_AML_SCREENING`	Wait, or rescreen it if it is taking longer than expected.
Frozen	`subStatus` is `AUTO_FREEZE` or `FROZEN_MANUALLY`	Unfreeze it once you have reviewed the case.
Rejected	`status` is `REJECTED`, with a screening `subStatus` such as `REJECTED_AML_SCREENING`	Bypass it if the block was a false positive.

A transaction can stay in PENDING_AML_SCREENING for reasons unrelated to the screening result, most often network confirmation delays between Fireblocks and your provider. This usually resolves on its own within a short time, and does not indicate a problem with the transaction or your policy.

Read the compliance result

Call GET /screening/transaction/{txId} for the full AML/KYT and Travel Rule result. Address Registry Screening results are not included:

const { data } = await fireblocks.compliance.getScreeningFullDetails({ txId });

console.log(data.status, data.aml?.verdict, data.aml?.risk);

Field	Description
`aml`	The final AML/KYT result.
`tr`	The Travel Rule result.
`amlList`	Every AML/KYT result recorded for the transaction, including earlier ones before a rescreen.
`status`	Screening progress across checks, for example `AMLStarted`, `AMLCompleted`, `TRStarted`, `TRCompleted`, or `Completed`.

Each result in aml, tr, and amlList includes:

Field	Description
`provider`	The provider that ran the check.
`verdict`	The provider’s verdict, for example `PASS`.
`risk`	The risk level. Values are provider-specific strings, such as `lowRisk`.
`screeningStatus`	The status of this check, for example `COMPLETED`.
`bypassReason`	Why screening was skipped, if it was, for example `PASSED_BY_POLICY` or `UNSUPPORTED_ASSET`.
`customerRefId`	The Customer Reference ID the result is attributed to.
`payload`	The provider’s raw, unmodified response. Its structure differs by provider.

The transaction status PENDING_AML_SCREENING is not the same as a check’s screeningStatus. A check can finish while the transaction is still moving through later checks. Screening outcomes also arrive on the transaction.status.updated webhook event: the payload includes the status and subStatus change, plus an amlScreeningResult object with the AML provider, verdict, risk, and related fields. See Transaction events.

Act on a transaction

Operation	Endpoint	Applies to	Permission	Result
Bypass	`POST /screening/transaction/{txId}/bypass_screening_policy`	Rejected outgoing transactions	Owner, Admin	Creates a new transaction, with the API user as initiator, that skips the screening check. The original stays rejected.
Rescreen	`POST /screening/transaction/{txId}/rescreen`	Any screened transaction, for example one stuck in screening	All roles	Returns the transaction to pending screening. Set `resetTravelRuleMessage` to `true` to discard the existing Travel Rule message.
Freeze	`POST /transactions/{txId}/freeze`	Incoming transactions	Admin, Non-Signing Admin	Makes the funds unspendable: the full amount for account-based assets, or all of the transaction’s UTXOs for UTXO-based assets.
Unfreeze	`POST /transactions/{txId}/unfreeze`	Frozen transactions	Owner, Admin, Non-Signing Admin	Makes the funds available again.

All four accept an optional Idempotency-Key header, valid for 24 hours. These permissions are workspace defaults, not fixed rules. Bypass and unfreeze can be blocked for your whole workspace with the disableBypass and disableUnfreeze tenant settings. When an operation is blocked, it requires a Fireblocks Support ticket instead. See Compliance Policies. Bypassing affects only that one transaction. It does not change your policy or how future transactions are screened.

On the Help Center

To bypass, rescreen, freeze, or unfreeze a transaction in the Console, see Transaction Screening Operations.

Get Started

Transactions

API Co-Signers

Workspace & Security

Webhooks

Direct Custody Wallets

Manage Wallets

Embedded Wallets

Canton

Gas Management

Treasury & Trading

Smart Contracts & Tokenization

Assets & NFTs

Identity & Compliance

Compliance Screening

Compliance Tooling

Payments

Offchain Signing

Key Link

Integrations

What happens after screening

Transaction states

Read the compliance result

Act on a transaction

On the Help Center

​What happens after screening

​Transaction states

​Read the compliance result

​Act on a transaction

​On the Help Center

What happens after screening

Transaction states

Read the compliance result

Act on a transaction

On the Help Center