# Zone policies Every zone operator is a regulated entity, so compliance cannot be an afterthought, and in a zone it is not. KYC, AML, sanctions screening, and account freezes are enforced by the substrate itself, on every transfer. You configure the policy that matches your regulatory regime, and the zone enforces it and writes your audit trail for you. You are not building an enforcement engine. You are configuring one that already exists.  ## Three checks on every transfer A transfer inside your zone clears only if three checks all pass. The first is **issuer freezes inherited from the host chain**. If Circle or Tether freezes an address, your zone honors it, and you cannot override it. You get issuer-level sanctions compliance without tracking it yourself. The second is **your zone's own policy**, the KYC or AML program you configured. This is where most of your compliance posture lives. The third is **per-account flags**, the instant operational controls like a fraud freeze. The first check is inherited; the other two are yours to set. ## Policies you configure Three policy shapes cover almost everything a regulated operator needs: * **Whitelist:** only listed addresses can transact. This is the KYC-gated zone, where anyone not verified simply cannot move money inside it. * **Blacklist:** everyone can transact except listed addresses. This is your sanctions or AML-hit list. * **Compound:** different rules for senders and recipients. For example, senders must be KYC'd while anyone can receive. You bind a policy to the whole zone, or to a specific token, so you can require KYC for USDC while leaving a zone-native token open. ```ts // (V2) require KYC'd addresses for USDC transfers in your zone const kyc = await kakushi.policies.create({ type: "whitelist" }); await kakushi.policies.addToWhitelist(kyc, [aliceAddress, bobAddress]); await kakushi.policies.setTokenPolicy("USDC", kyc); ``` ## Per-account controls Some things are about one account, not a policy: a fraud alert, a compliance review, a legal hold. Per-account flags are the fast path, applied instantly without reconfiguring a policy. ```ts // (V2) freeze an account immediately on a fraud alert await kakushi.compliance.freezeAccount("alice"); // (V2) restrict: can receive, cannot send, during a review await kakushi.compliance.restrictAccount("bob"); ``` ## Delegate to your compliance team You can hand control of a single policy, say the AML blacklist, to a separate admin without giving up operator-level access. Your compliance team manages their list as alerts fire, and they never touch anything else in the zone. ```ts // (V2) give your compliance team control of just the AML blacklist await kakushi.policies.setAdmin(amlBlacklist, complianceTeamAddress); ``` ## Audit trails write themselves Every policy change and every account flag emits an event. Your dashboard keeps a live view of compliance state, and you export a scoped log for any account or period when a regulator asks. It is the same purpose as the audit logs in a legacy compliance stack, generated for you instead of assembled by hand. ## Bounded authority :::note You can freeze, restrict, or unfreeze accounts in your zone, the same authority any custodian has today, now explicit and auditable. What you cannot do is confiscate. A frozen user can still exit their own funds through the forced-exit path. Policy enforcement governs transfers inside the zone, not ownership. And compliance state is private: other users never see who is frozen or on a list, only you and the affected account do. ::: ## Availability :::warning The operator-controlled policy system on this page, the whitelist, blacklist, and compound policies, the per-account flags, and enforcement on internal transfers, is a V2 capability. In V1, operators run KYC and AML out of band, and the zone honors host-chain issuer freezes at the deposit and withdrawal boundary. The full toolkit lands in V2. :::