Compliance Features - The Institutional Toolkit | Tokenization on XRPL | XRP Academy - XRP Academy
3 free lessons remaining this month

Free preview access resets monthly

Upgrade for Unlimited
Skip to main content
intermediate60 min

Compliance Features - The Institutional Toolkit

Learning Objectives

Implement each compliance feature with correct configuration and timing

Evaluate appropriate use cases for freeze, clawback, and authorization

Understand the trade-offs between control and holder trust

Design compliance workflows for regulated tokenized assets

Compare XRPL's approach to alternative compliance implementations

INDIVIDUAL FREEZE MECHANISM:

- Specific trust line marked as frozen
- Holder can ONLY send tokens to issuer
- Holder CANNOT send to other holders
- Holder CANNOT receive more tokens

Implementation:
TrustSet with tfSetFreeze flag

To Unfreeze:
TrustSet with tfClearFreeze flag
LEGITIMATE USE CASES:

1. COURT ORDER: Asset preservation during litigation
2. FRAUD INVESTIGATION: Freeze while investigating
3. SANCTIONS COMPLIANCE: Holder on sanctions list
4. ACCOUNT COMPROMISE: Prevent theft while resolving
5. COMPLIANCE VIOLATION: Failed re-verification
FREEZE WORKFLOW:

1. Trigger event (sanctions match, court order)
2. Internal review and documentation
3. Compliance officer approval
4. Execute freeze transaction
5. Notify holder (if appropriate)
6. Resolution: unfreeze OR clawback

---
GLOBAL FREEZE:

- ALL trust lines frozen
- No holder-to-holder transfers
- Holders can ONLY send to issuer
- Emergency halt capability

Implementation:
AccountSet with asfGlobalFreeze flag
GLOBAL FREEZE SCENARIOS:

1. SECURITY BREACH: Issuer keys compromised
2. REGULATORY ORDER: Regulator requires halt
3. ASSET BACKING ISSUE: Reserve problem discovered
4. MIGRATION: Controlled transition to new system
5. MARKET EMERGENCY: Circuit breaker equivalent
CRITICAL CONSIDERATIONS:

- Global freeze is PUBLIC and visible
- Market will react
- Should be temporary
- Have resolution plan ready
- Prepare communication beforehand

---
DEEP FREEZE:

- Holder CAN send to issuer
- Holder CANNOT receive

- Holder CANNOT send (even to issuer)
- Holder CANNOT receive
- Complete isolation

- OFAC SDN list inclusion
- Complete sanctions compliance
- Court order requiring total isolation

---
CLAWBACK REQUIREMENTS:

1. asfAllowTrustLineClawback MUST be enabled
2. MUST be set BEFORE any trust lines created
3. Cannot enable after first issuance

- Issuer retrieves tokens from holder
- No holder consent required
- Tokens returned to issuer
CLAWBACK USE CASES:

1. COURT-ORDERED SEIZURE: Legal judgment
2. SANCTIONS ENFORCEMENT: OFAC designation
3. ERROR CORRECTION: Tokens sent in error
4. FRAUD RECOVERY: Fraudulent acquisition
5. REGULATORY REQUIREMENT: Compliance action
CLAWBACK GOVERNANCE ELEMENTS:

- Circumstances triggering clawback
- Approval process (who decides)
- Documentation requirements
- Notification procedures
- Appeal process (if any)

- Valid court order
- Regulatory directive
- Sanctions match confirmed
- Material error discovered
  • Reduces holder trust
  • Could be abused
  • Requires strong governance
  • Cannot comply with court orders
  • Sanctions risk
  • May preclude institutional adoption

AUTHORIZATION FLOW:

1. Issuer enables asfRequireAuth
2. Holder creates trust line (unauthorized)
3. Issuer verifies holder off-chain
4. Issuer sends TrustSet with tfSetfAuth
5. Holder can now receive tokens
AUTHORIZATION USE CASES:

1. ACCREDITED INVESTOR: Reg D compliance
2. KYC/AML COMPLIANCE: Identity verification
3. GEOGRAPHIC RESTRICTIONS: Jurisdiction limits
4. INSTITUTIONAL ONLY: Minimum thresholds
5. CONTROLLED DISTRIBUTION: Staged releases

---
COMPLIANCE IMPLEMENTATION:

Feature        | XRPL              | ETHEREUM
---------------|-------------------|------------------
Freeze         | Native protocol   | Smart contract
Clawback       | Native protocol   | Smart contract
Authorization  | Native protocol   | Smart contract
Audit required | No (protocol)     | Yes ($50K-500K)
Bug risk       | Protocol-level    | Contract-level
Consistency    | Identical for all | Varies by contract

CONFIGURATION CHECKLIST:

□ RequireAuth: Enable if KYC required
□ Clawback: Enable BEFORE first trust line
□ Freeze policy: Document before launch
□ Clawback policy: Document before launch
□ Authorization workflow: Establish
□ Emergency procedures: Define
GOVERNANCE DOCUMENTATION:

1. COMPLIANCE POLICY: When features used
2. HOLDER DISCLOSURE: Clear explanation
3. OPERATIONAL PROCEDURES: Step-by-step
4. EMERGENCY RUNBOOK: Response plans

---

Create comprehensive playbook for hypothetical tokenized security with configuration settings, policies, workflows, and emergency procedures.

Time investment: 2.5 hours


1. Why is protocol-level compliance advantageous?
Answer: B - Eliminates smart contract audit requirements and bug risk

2. Can issuer enable clawback after launching token?
Answer: B - No, must enable BEFORE first trust line created

3. When to use global vs. individual freeze?
Answer: C - Individual for specific holder; global for emergencies affecting all

4. What is Deep Freeze (XLS-77)?
Answer: B - Complete isolation where holder cannot send OR receive

5. Trade-off of enabling clawback?
Answer: C - Enables compliance but reduces trust; requires governance


End of Lesson 9

Key Takeaways

1

Protocol-level = lower risk

: Native features eliminate smart contract audit requirements.

2

Clawback timing critical

: MUST enable BEFORE first trust line—cannot add later.

3

Governance essential

: Document policies for when and how features will be used.

4

Trade-offs are real

: More control = less holder trust; find appropriate balance.

5

Transparency builds trust

: Clear disclosure helps holders make informed decisions. ---