> For the complete documentation index, see [llms.txt](https://docs.useprivatus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useprivatus.com/compliance/regulatory-framework.md).

# Regulatory Framework

Privatus's compliance model is built around a single principle that shapes everything else in this section: privacy scales with verification. Amounts are confidential by default for everyone. Deeper privacy, shielded state at Layer 3 and full privacy at Layer 4, is unlocked only by progressively stronger identity checks. Every mechanism described below follows from that design.

***

## Operating framework

Privatus operates as non-custodial infrastructure. Users hold their own keys, and Privatus operates no signing infrastructure and takes no custody of funds. The platform is a protocol layer, not a custodian or money transmitter, and its regulatory posture in each market reflects that.

All settlement happens in regulated stablecoins: USDG (Paxos' Global Dollar) and USDC, both natively issued on Solana, alongside SOL. Fiat on and off ramps, where offered, are provided through licensed third parties.

***

## Jurisdictional scope

US persons are excluded during beta. Initial markets are the EU, UK, Singapore, and UAE, subject to ongoing review under each market's virtual asset framework (MiCA in the EU among them). Jurisdictions with an explicit prohibition on crypto payment services are excluded from beta access.

***

## KYC and identity verification

Verification requirements are tiered by account type, matching the depth of privacy each tier unlocks:

| Tier              | Requirements                                               | Unlocks                               |
| ----------------- | ---------------------------------------------------------- | ------------------------------------- |
| Shadow Lite       | Email plus on-chain wallet attestation                     | Confidential amounts, standard limits |
| Shadow Agent      | Email plus wallet attestation (via the deploying operator) | Confidential amounts, x402 and MPP    |
| Shadow Pro        | Government ID, liveness check, proof of address            | Layer 3 shielded state, higher limits |
| Shadow Enterprise | Full KYB: incorporation records, beneficial ownership      | Layer 4 full privacy, bulk agent API  |

The deeper the privacy, the stronger the identity requirement. Layer 4's shielded pools are available only to KYB-verified enterprises and use association sets to keep the pool free of illicit funds.

***

## Travel Rule compliance

Cross-border and above-threshold transfers to and from regulated institutions are subject to Travel Rule requirements. Privatus supports compliance through:

* View key-based selective disclosure proofs, shared with a counterparty's compliance system when required (see [KYC & Travel Rule](/compliance/kyc-and-travel-rule.md))
* Counterparty address screening via Chainalysis or TRM Labs integration
* Standard identity information exchange between regulated originating and beneficiary institutions where applicable

***

## Agent operator responsibility

Entities deploying agent accounts are responsible for their agents' compliance obligations under applicable law. Spend policies are enforced on-chain by the Privatus agent program, which gives operators a verifiable record that their agents transacted within the limits they set.

***

## Data residency

User metadata, meaning account profiles and any verification records, is stored in jurisdiction-appropriate regions based on where the account was opened. On-chain data is global by nature, since it lives on Solana mainnet rather than in Privatus's own infrastructure, and this is disclosed clearly during onboarding.

***

## Why privacy and compliance aren't in tension

Privatus's confidential transfer layer hides amounts. It does not hide the existence of transactions, and at the default tier it does not hide addresses. Account holders can respond to lawful legal process through view key-based selective disclosure, described in [Selective Disclosure & Audit Export](/privacy-and-confidential-transfers/selective-disclosure.md): a cryptographic proof of correctness that satisfies a regulator without exposing the underlying data to the public, and without custody of keys ever leaving the user. This is the model regulated privacy-preserving payment systems have broadly converged on, and it is the model Privatus is built around: full accountability where the law requires it, and confidentiality everywhere else.

***

## Next

* [KYC & Travel Rule](/compliance/kyc-and-travel-rule.md)
* [Selective Disclosure & Audit Export](/privacy-and-confidential-transfers/selective-disclosure.md)


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.useprivatus.com/compliance/regulatory-framework.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
