> ## 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. # About Identity & Compliance > Where Identity & Compliance screening runs in the Fireblocks transaction lifecycle, what you can do with it through the API, and where to start. Identity & Compliance lets you verify who you are transacting with, screen transactions and addresses for risk, and apply your compliance policies automatically as transactions move through your workspace. You set up your providers and policies once. Fireblocks then applies them to every matching transaction: an outgoing transaction is screened before it is approved and signed, and an incoming transaction is screened once it receives its first blockchain confirmation. For why screening in the transaction path matters, see [Why Screen Through Fireblocks](https://support.fireblocks.io/hc/en-us/articles/30614328227100-Why-Screen-Through-Fireblocks) on the Help Center. It covers counterparty and transaction compliance. It does not cover onboarding or KYC for your own end customers, and it does not replace your compliance program: you remain responsible for reviewing flagged activity and filing any required regulatory reports. Most setup, such as connecting providers and building policy rules, happens in the Console. Through the API, you react to screening outcomes, read results and policies, act on individual screened transactions, and attach your own customer identifiers. Each guide states whether a task is available through the API, the Console, or both. ## Where screening runs in a transaction Screening flow for outgoing and incoming transactions | Step | What happens | What you see in the API | | - | - | - | | 1. A transaction starts | You create an outgoing transaction, or Fireblocks detects an incoming one. | [`POST /transactions`](/api-reference/transactions/create-a-new-transaction), or a new incoming transaction | | 2. Screening starts | An outgoing transaction enters screening right after you submit it, before policy approval and signing. An incoming transaction enters screening upon receiving its first blockchain confirmation. Screening covers every check below. | `status` is `PENDING_AML_SCREENING` | | 3. Checks run in order | [Address Registry Screening](/docs/address-registry-screening), then [AML/KYT](/docs/aml-kyt-overview), then [Bring Your Own Screening](/reference/bring-your-own-screening-check-developer-guide) if you use it, then [Travel Rule](/docs/travel-rule-overview). For each check, the Trigger (Screening Policy) decides whether the transaction is screened, and the Outcome (Post-Screening Policy) decides what happens with the result. | `status` stays `PENDING_AML_SCREENING` | | 4. The Outcome applies | Accept or alert: the transaction continues, and an outgoing transaction moves on to approval and signing. Reject: an outgoing transaction is never sent. Reject or freeze on an incoming transaction: the funds are frozen. | `status` and `subStatus` change, for example `REJECTED` with `REJECTED_AML_SCREENING`, or `AUTO_FREEZE` | | 5. You are notified | Fireblocks sends an event for each status change. Read the full result when you need the details. | `transaction.status.updated` event, and [`GET /screening/transaction/{txId}`](/api-reference/compliance/provides-all-the-compliance-details-for-the-given-screened-transaction) | If [AML/KYT](/docs/aml-kyt-overview) freezes an incoming transaction, the checks after it do not run. ## How this section is organized If you are new to Identity & Compliance through the API, start with Get started, then read the Key concepts, beginning with [Compliance Events & Webhooks](/docs/compliance-events-webhooks). **Compliance screening** covers everything that happens during a live transaction. * **Get started** * [What You Can Connect](/docs/what-you-can-connect): which checks and providers are available, how each is enabled, and which workspace types support it. * **Key concepts** * [Compliance Events & Webhooks](/docs/compliance-events-webhooks): how screening outcomes reach your systems, so you can automate your own flows on top of them. * [Compliance Policies](/docs/compliance-policies): how Trigger and Outcome rules decide what happens to a transaction, and what you can read and configure through the API. * [Transaction Screening Operations](/docs/transaction-screening-operations): what you can do with one transaction after it is screened, for example, bypass a rejection or unfreeze funds. * [Customer Reference ID](/docs/customer-reference-id): how to tag transactions with your own customer identifier, so screening results are attributed to the right customer. * **Checks** * [Address Registry Screening](/docs/address-registry-screening): confirm whether a counterparty is a verified entity in Fireblocks' shared [Address Registry](/reference/address-registry). * [AML/KYT](/docs/aml-kyt-overview): screen for blockchain risk through [Chainalysis](/docs/chainalysis), [Elliptic](/docs/elliptic), or [TRM Labs](/docs/trm-labs). * [Travel Rule](/docs/travel-rule-overview): exchange required originator and beneficiary information. * Providers: [Notabene](/docs/notabene), [Sumsub](/docs/sumsub), [GTR](/docs/gtr), [TRUST](/docs/interact-with-trust) * Connected accounts: [Exchanges](/docs/exchanges-travel-rule), [On/Off-Ramps](/docs/on-off-ramps-travel-rule) * [Bring Your Own Screening](/reference/bring-your-own-screening-check-developer-guide): pause a transaction for your own verdict, based on whatever review process or provider you choose. **Compliance tooling** supports your compliance program outside live transactions. * [Address Registry](/reference/address-registry): look up the legal entity behind an address, register your legal entity, and manage participation. * [Cyber and Operational Resilience (COR) Compliance Package](https://support.fireblocks.io/hc/en-us/articles/30614376322716-Cyber-and-Operational-Resilience-COR-Compliance-Package): the legal, reporting, and audit materials that help you manage Fireblocks as a third-party ICT provider under the EU's Digital Operational Resilience Act (DORA). Help Center only. * [Fireblocks' Compliance Policy (OFAC Sanctions)](https://support.fireblocks.io/hc/en-us/articles/30614329049756-Fireblocks-Compliance-Policy-OFAC-Sanctions): Fireblocks automatically blocks outgoing transactions to addresses on OFAC's sanctions list, before your own policy rules run. A blocked transaction returns `status` `BLOCKED` with `subStatus` `BLOCKED_BY_POLICY`. There is nothing to configure. ## On the Help Center To configure these capabilities in the Fireblocks Console, see [About Identity & Compliance](https://support.fireblocks.io/hc/en-us/articles/30614325206556-About-Identity-Compliance).