# Compliance Architecture Explanation

**Date**: 2025-12-24  
**Purpose**: Clarify the distinction between different compliance systems

---

## 🔍 Two Types of Compliance

### 1. Legal Compliance (NEW - For Travel Rules Exemption)

**Purpose**: Ensure contracts meet legal requirements and are exempt from Travel Rules

**Location**: `contracts/compliance/LegallyCompliantBase.sol` and `contracts/compliance/ComplianceRegistry.sol`

**Features**:
- ✅ Hague Conventions compliance
- ✅ ISO standards compliance
- ✅ ICC compliance
- ✅ Travel Rules exemption
- ✅ Regulatory compliance exemption
- ✅ Instrument of Value Transfer classification

**Key Point**: **NO KYC/AML** - This is for exemption, not compliance enforcement

---

### 2. eMoney Compliance Registry (EXISTING - For Policy Enforcement)

**Purpose**: Enforce compliance policies in eMoney system (KYC/AML, freezing, risk tiers)

**Location**: `contracts/emoney/ComplianceRegistry.sol`

**Features**:
- Account allowed/frozen status
- Risk tier management
- Jurisdiction tracking
- Policy enforcement

**Key Point**: This has **KYC/AML features** which are NOT compatible with Travel Rules exemption

---

## ⚠️ Important Distinction

### For Travel Rules Exemption

**USE**: `contracts/compliance/LegallyCompliantBase.sol` and `contracts/compliance/ComplianceRegistry.sol`

**DO NOT USE**: `contracts/emoney/ComplianceRegistry.sol` for Travel Rules exempt contracts

**Reason**: The eMoney ComplianceRegistry has KYC/AML features (allowed, frozen, riskTier) which would trigger Travel Rules requirements.

---

## 🎯 Implementation Strategy

### For Value Transfer Tokens (USDT, USDC, etc.)

**Use**: `LegallyCompliantBase` + Legal Compliance Registry

**Design**:
- No KYC/AML requirements
- No account freezing
- No risk tier management
- Pure value transfer
- Private peer-to-peer

### For eMoney System

**Use**: Existing eMoney ComplianceRegistry (if needed for policy enforcement)

**Note**: If eMoney tokens need Travel Rules exemption, they should NOT use the KYC/AML features of the eMoney ComplianceRegistry, or should have an opt-out mechanism.

---

## 📋 Contract Classification

### Travel Rules Exempt Contracts

These contracts should use `LegallyCompliantBase`:
- ✅ CompliantUSDT
- ✅ CompliantUSDC
- ✅ Governance Token (if exempt)
- ✅ Bridge contracts (if exempt)
- ✅ Any private value transfer instrument

### Policy-Enforced Contracts

These contracts may use eMoney ComplianceRegistry:
- ⚠️ eMoneyToken (if policy enforcement needed)
- ⚠️ ISO20022Router (if compliance checks needed)

**Note**: If these need Travel Rules exemption, they should NOT enforce KYC/AML policies.

---

## 🔧 Migration Path

### Option 1: Separate Systems (Recommended)

- **Value Transfer Tokens**: Use `LegallyCompliantBase` + Legal Compliance Registry
- **eMoney System**: Use existing eMoney ComplianceRegistry (if policy enforcement needed)
- **Clear separation**: No mixing of systems

### Option 2: Unified System (If Needed)

- Create unified compliance system that supports both:
  - Legal compliance (for exemption)
  - Optional policy enforcement (if not exempt)
- More complex but allows flexibility

---

## ✅ Recommended Approach

**For Travel Rules Exemption**:
1. Use `LegallyCompliantBase` for all value transfer contracts
2. Use Legal Compliance Registry for tracking
3. **DO NOT** implement KYC/AML features
4. **DO NOT** use eMoney ComplianceRegistry for exempt contracts

**For eMoney System**:
1. If Travel Rules exemption needed: Do NOT use KYC/AML features
2. If policy enforcement needed: Use eMoney ComplianceRegistry but understand it may affect exemption status
3. Consider separate eMoney tokens for exempt vs. non-exempt use cases

---

**Last Updated**: 2025-12-24