> ## Documentation Index > Fetch the complete documentation index at: https://developers.fireblocks.com/llms.txt > Use this file to discover all available pages before exploring further. # Why Screen Through Fireblocks > See where compliance screening runs in a Fireblocks transaction, what the API shows at each step, and which guide covers it. Fireblocks screens a transaction inside its own transaction path, so the outcome of your compliance policy is applied before an outgoing transaction is signed or incoming funds become available, with no enforcement logic for you to build. You set up checks and policies once; Fireblocks applies them to every matching transaction in the workspace. For the business case, see [Why Screen Through Fireblocks](https://support.fireblocks.io/hc/en-us/articles/30614328227100-Why-Screen-Through-Fireblocks) on the Help Center. ## How screening runs in a transaction Transaction lifecycle with screening outcomes | Step | What happens | In the API | Guide | | - | - | - | - | | 1. Transaction starts | You create an outgoing transaction, or Fireblocks detects an incoming one. | [`POST /transactions`](/api-reference/transactions/create-a-new-transaction) | n/a | | 2. Screening starts | Outgoing: right after you submit it, before Policies approval and signing. Incoming: at the first blockchain confirmation. | `status`: `PENDING_AML_SCREENING` | n/a | | 3. Checks run | For each enabled check, in order, the Trigger (Screening Policy) decides whether the transaction is screened. | `status` stays `PENDING_AML_SCREENING` | [What You Can Connect](/docs/what-you-can-connect) (order of checks), [Compliance Policies](/docs/compliance-policies) | | 4. Outcome applies | The Outcome (Post-Screening Policy) acts on each result. **Accepted** (Accept or Alert): the transaction continues; outgoing moves on to Policies approval and signing. **Rejected** (outgoing): never sent. **Frozen** (incoming): funds held. A Reject or Freeze ends screening; later checks do not run. | Accepted: `status` moves past `PENDING_AML_SCREENING`. Rejected: `REJECTED` with `subStatus` `REJECTED_AML_SCREENING`. Frozen: `subStatus` `AUTO_FREEZE`. | [Compliance Policies](/docs/compliance-policies) | | 5. Read the result | Any time after screening starts. In the Console: **Transaction History** > **Transaction Details**. | `transaction.status.updated` event; [`GET /screening/transaction/{txId}`](/api-reference/compliance/provides-all-the-compliance-details-for-the-given-screened-transaction) for the full result | [Compliance Events & Webhooks](/docs/compliance-events-webhooks), [Transaction Screening Operations](/docs/transaction-screening-operations) | | 6. Act on the transaction | Any time after screening starts: bypass a rejection, rescreen, freeze, or unfreeze. Freeze is API only. | Bypass creates a new transaction; the original stays `REJECTED`. | [Transaction Screening Operations](/docs/transaction-screening-operations) | ## Limitations * AML/KYT and Notabene do not screen these routes: vault-to-vault, vault-to-exchange, vault-to-Gas Station, Gas Station-to-vault, and non-custodial wallet to non-custodial wallet within the same workspace. Address Registry Screening, Bring Your Own Screening, Sumsub, and GTR screen every route. * Screening covers transactions in your Fireblocks workspace only, not activity outside it. ## On the Help Center For the business case and the Console view, see [Why Screen Through Fireblocks](https://support.fireblocks.io/hc/en-us/articles/30614328227100-Why-Screen-Through-Fireblocks).