> For the complete documentation index, see [llms.txt](https://synthesys-2.gitbook.io/synthesys-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://synthesys-2.gitbook.io/synthesys-docs/mint-overview/compliance-and-security/kyc-and-whitelisting.md).

# KYC & Whitelisting

Fund tokens issued through the Synthesys platform can only be held or transferred by wallets that have been explicitly whitelisted following successful KYC/AML verification. This is a fundamental architectural design choice — compliance controls are enforced by the underlying smart contract code and cannot be circumvented.

***

### The On-Chain KYC Barrier

| Without Synthesys (Standard Token) | With Synthesys (Fund Token)                               |
| ---------------------------------- | --------------------------------------------------------- |
| Any wallet can receive tokens      | Only KYC-verified, whitelisted wallets can receive tokens |
| No identity verification on-chain  | Wallet whitelisting enforced at the smart contract layer  |
| Transfers unrestricted             | Transfers blocked to non-whitelisted addresses            |
| No blacklist capability            | Blacklist contracts available for sanctions compliance    |

***

### Investor Onboarding & Whitelisting Process

The KYC-to-whitelist flow works as follows:

1. An investor submits KYC documentation to a sub-distributor or directly to the fund's designated onboarding channel.
2. The sub-distributor completes KYC verification in accordance with applicable AML/KYC regulations and passes verified investor status to Mint via the Synthesys Network API.
3. The Transfer Agent (TA) reviews the verified investor record in the Mint UI and adds the investor's wallet address to the Fund Token Contract's on-chain whitelist.
4. Once whitelisted, the investor's wallet is eligible to receive fund tokens. The whitelist entry is recorded immutably on-chain.
5. The TA can revoke whitelist access at any time (e.g., for sanctions, redemption, or regulatory requirements), immediately blocking the wallet from receiving further tokens.

***

### Zodiac Whitelisting (Wrap/Unwrap)

Zodiac's Wrap/Unwrap feature — which converts permissioned fund tokens to permissionless zTokens and back — requires a separate whitelisting process:

1. Connect your wallet and navigate to the Wrap/Unwrap page on Zodiac.
2. If your wallet is not on the allowlist, you will see a "Request Whitelisting" prompt.
3. Select your region (APAC, Europe, Middle East, or Americas).
4. Choose from the authorized distributors available in your region and complete KYC/AML through their external portal.
5. The distributor submits a whitelist transaction to the ERC-1400 contract.
6. On the next page load, Zodiac detects the updated status and unlocks Wrap/Unwrap.

This is a one-time process per wallet.

***

### Blacklist & Sanctions Controls

In addition to whitelisting, the Synthesys platform supports the deployment of blacklist contracts. Blacklisted wallet addresses are blocked from all token interactions regardless of whitelist status. This provides a secondary layer of control for:

* Sanctions screening compliance
* Regulatory freeze orders
* Investor disputes or legal holds

***

### Key Points

* KYC must be completed before any wallet can receive fund tokens.
* Sub-distributor wallets must be whitelisted before any tokens can be delivered.
* All whitelist and blacklist actions are recorded immutably on-chain.
* The Transfer Agent can revoke access at any time, with immediate on-chain effect.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://synthesys-2.gitbook.io/synthesys-docs/mint-overview/compliance-and-security/kyc-and-whitelisting.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.