> ## Documentation Index
> Fetch the complete documentation index at: https://tetrafi.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance Policy

> One policy, composed per deployment and controlled by your institution - enforced on-chain at the escrow, and the same gate on every layer.

Every deployment runs under one **compliance policy**: composed and controlled by your institution, enforced **on-chain** at the escrow against attested credentials. The check runs inside the settlement path, so the audit trail *is* the settlement record.

## Where It Is Enforced

| Point              | What happens                                                                                                                                                                                                                                  |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **The request**    | RFQ requests reach workspace-approved LPs only, jurisdiction-filtered before they reach a desk. If no eligible LP can quote, you get a typed product-unavailable answer, never a silent fallback.                                             |
| **The credential** | Attested credentials travel in the `X-TetraFi-Attestation` header ([Authentication](/core-concepts/authentication)): something verifiable, not a self-declared flag.                                                                          |
| **The deposit**    | `ComplianceSettlerEscrow` enforces the policy when your router locks the input under the signed order; its output-side twin gates fills on the destination chain ([Settlement & Smart Contracts](/core-concepts/settlement-smart-contracts)). |

A trade that fails the policy is refused before any value moves; non-compliant funds never sit in escrow, so there is no post-trade unwind.

## What You Compose

The policy attaches to your deployment, not to the app calling it:

* **Your compliance pipeline** - checks added, removed, or layered to fit your regulatory perimeter
* **Your counterparty perimeter** - which LPs, jurisdictions, and venues your requests and router may reach
* **Onboard once** - one verified onboarding pack, reused for KYB with every counterparty
* **One audit trail** - enforcement evidence shared across parties instead of repeated manual reviews

An asset restricted to qualifying investors or jurisdictions stays gated wherever it is routed.

## In the Workspace

The pre-trade gate runs on every order in a fixed order: sanctions screening of originator and beneficiary, deposit screening, jurisdiction and corridor rules, travel-rule checks, then your workspace overlay. The **Compliance Center** composes that overlay, tighten-only: workflows that run in **shadow** before they enforce, sanctions evidence with recorded overrides, entity profiles, reporting. Every trade leaves an evidence pack in a tamper-evident ledger. (Workflow builder and reporting rolling out.)

## The Same Gate on the Next Layers

<Note>
  **Coming soon.** [Multilateral Netting](/netting) and the [Shared Collateral Network](/collateral) are in design.
</Note>

The policy you compose for the rails is the one both primitives run under:

* **Netting** - membership is compliance-gated (KYB'd participants, jurisdiction-aware, per policy domain), checks run at every run entry, and compliance can only exclude a pairing, never redirect money
* **Shared collateral** - every vault draw re-runs the policy: KYB'd counterparties, jurisdiction filters, machine-checkable policy