132 lines
3.7 KiB
Markdown
132 lines
3.7 KiB
Markdown
# 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
|
|
|