> ## 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. # Compliance Policies > How compliance policies decide what happens to a screened transaction, and how to read rules, configure outage and delay behavior, and set workspace-wide limits through the Fireblocks API. A compliance policy decides what happens to a transaction during screening. You build your policies in the Console, under **Policies** > **Compliance**. Through the API, you read the rules you built, configure how screening behaves when a provider is slow or unavailable, and set limits that apply across your workspace. To act on a single transaction after screening, for example, to bypass a rejection or unfreeze funds, see [Transaction Screening Operations](/docs/transaction-screening-operations). ## How a policy is structured Each check type has its own policy, made of two parts: * **The Trigger (Screening Policy)** determines which transactions are screened. * **Outcome (Post-Screening Policy)** decides what happens automatically once a result comes back. What counts as a result depends on the check: a risk level for AML/KYT, a message status for Travel Rule, or a group match for Address Registry Screening. | Policy | Actions | | - | - | | Trigger (Screening Policy) | Screen (send to the provider), pass (skip screening), or freeze (hold without screening). | | Outcome (Post-Screening Policy) | Accept, reject, or alert, for every provider. Freeze, wait, and cancel, for some providers only. | See ["Building a Compliance Policy"](https://support.fireblocks.io/hc/en-us/articles/30614325308828-Building-a-Compliance-Policy) in the Help Center for instructions on building rules in the Console. ## What you can do through the API | Task | AML/KYT | Travel Rule | Address Registry Screening | | - | - | - | - | | Build, edit, and delete rules | Console | Console, except Sumsub and GTR (see below) | Console | | Read rules | API | API | Console | | Configure outage and delay behavior | API | API | Console | | Set workspace-wide limits on bypass and unfreeze | API | API | API | Rules cannot be built, edited, or deleted through the API. Sumsub and GTR do not yet support Console configuration either: to change their rules, submit a policy template to Fireblocks Support, copying your workspace Owner, whose approval is required for the change. ## Read your rules | Policy | Endpoint | SDK method | | - | - | - | | AML/KYT Trigger (Screening Policy) | [`GET /screening/aml/screening_policy`](/api-reference/compliance/aml--view-screening-policy) | `compliance.getAmlScreeningPolicy` | | AML/KYT Outcome (Post-Screening Policy) | [`GET /screening/aml/post_screening_policy`](/api-reference/compliance/aml--view-post-screening-policy) | `compliance.getAmlPostScreeningPolicy` | | Travel Rule Trigger (Screening Policy) | [`GET /screening/travel_rule/screening_policy`](/api-reference/compliance/travel-rule--view-screening-policy) | `compliance.getScreeningPolicy` | | Travel Rule Outcome (Post-Screening Policy) | [`GET /screening/travel_rule/post_screening_policy`](/api-reference/compliance/travel-rule--view-post-screening-policy) | `compliance.getPostScreeningPolicy` | | Sumsub and GTR policy | [Get TRLink policy](/api-reference/trlink/get-trlink-policy) | See the API Reference | ### What a rule looks like Each rule is an if-then statement: if a transaction matches the rule's conditions, Fireblocks applies the rule's action. For example, a Trigger rule can say "if an outbound ETH transaction is over 10,000 USD, screen it", and an Outcome rule can say "if the risk level is high, reject it". Rules come back in the order Fireblocks evaluates them. The first rule whose conditions match a transaction decides its action, so a rule's position matters as much as its content. The last rule is always a catch-all default. ## Configure outage and delay behavior Each check type has settings for when a provider is unreachable or slow. They apply per check type (AML/KYT, Travel Rule), not per provider. | Check type | Read | Update | | - | - | - | | AML/KYT | [`GET /screening/aml/policy_configuration`](/api-reference/compliance-screening-configuration/get-aml-screening-policy-configuration) | [`PUT /screening/aml/policy_configuration`](/api-reference/compliance/update-aml-configuration) | | Travel Rule | [`GET /screening/travel_rule/policy_configuration`](/api-reference/compliance-screening-configuration/get-travel-rule-screening-policy-configuration) | [`PUT /screening/travel_rule/policy_configuration`](/api-reference/compliance/update-travel-rule-configuration) | | Field | Type | Description | | - | - | - | | `bypassScreeningDuringServiceOutages` | boolean | `true` by default. If the provider is unreachable or does not return a result before the delay elapses, the transaction bypasses screening: outgoing transactions are sent, and incoming funds are released. When `false`, a missed result fails the transaction: outgoing transactions are not sent, and incoming funds are frozen. | | `inboundTransactionDelay` | number | How long Fireblocks waits for a result on inbound transactions before the bypass behavior applies, in seconds. | | `outboundTransactionDelay` | number | How long Fireblocks waits for a result on outbound transactions before the bypass behavior applies, in seconds. | Defaults and maximums for the delays vary by check type and provider. Update requests accept an optional `Idempotency-Key` header, valid for 24 hours. ```ts theme={"system"} const { data } = await fireblocks.complianceScreeningConfiguration.getAmlScreeningConfiguration(); console.log(data.bypassScreeningDuringServiceOutages, data.inboundTransactionDelay); ``` ## Set workspace-wide limits Two settings control screening operations across your whole workspace, through [`PUT /screening/configurations`](/api-reference/compliance/tenant--screening-configuration): | Field | Type | Description | | - | - | - | | `disableBypass` | boolean | Blocks bypassing a rejected outgoing transaction. | | `disableUnfreeze` | boolean | Blocks unfreezing a frozen incoming transaction. | When an operation is blocked, it requires a Fireblocks Support ticket instead. ## Disconnecting a provider Disconnecting a provider also removes the policy tied to it. * **AML/KYT (Chainalysis, Elliptic, TRM Labs)**: through Fireblocks Support only. There is no API or Console option. * **Travel Rule ([Sumsub](/docs/sumsub), [GTR](/docs/gtr))**: through the API, with [Disconnect customer integration](/api-reference/trlink/disconnect-customer-integration). This permanently removes the stored credentials. ## Limitations * **One policy per connected tool.** You configure a policy separately for each connected tool. There is no single policy that applies across every tool at once. * **Routes that are not screened.** Some transaction routes are not screened, whatever the check type: vault account to vault account, vault account to exchange, Gas Station to vault account, and non-custodial wallet to non-custodial wallet within the same workspace. ## On the Help Center To build rules in the Console, see [Building a Compliance Policy](https://support.fireblocks.io/hc/en-us/articles/30614325308828-Building-a-Compliance-Policy).