// Domain 1 of 8
Issuance Authorization & Wallet Management
Before any token is minted, the issuer establishes its regulatory standing (PPSI charter or state license), designs the wallet architecture that governs key custody and transaction authorization, and implements the governance structures — board approval, written policies, capital adequacy — required by OCC 12 CFR § 15.3 and the GENIUS Act. Wallet structure must be designed for control and segregation, not solely operational efficiency.
Process Steps
Charter / PPSI application — submit business plan, 3-yr financial projection, technology description to OCC or state regulator
Capital adequacy verification — maintain operating expense reserve (12 months liquid) and leverage ratio
Wallet architecture design — define hot/warm/cold wallet structure, key generation protocols, and segregation of issuer vs. reserve keys
Board governance setup — approve issuance policy, risk appetite, and written information security program
Key Risks
Regulatory arbitrage — selecting a regulatory regime that does not match operational scale or activity, triggering mandatory federal transition
Weak governance design — inadequate board oversight or undefined risk appetite creates control gaps examiner will find at first safety & soundness review
Poor wallet architecture — co-mingling of operational and reserve keys, or single-point-of-failure design, enabling unauthorized access or key loss
Capital shortfall — insufficient operating reserve exposes issuer to insolvency risk before regulatory approval is finalized
Key Controls
Formal charter application with independent legal review — PPSI documentation reviewed by outside counsel before submission
Board-approved written governance framework — PPSI issuance policy, risk appetite statement, and IT security program approved before operations commence
Segregated wallet architecture with documented key hierarchy — hot/warm/cold tiers, separate keys for reserve vs. operational wallets, documented in technical architecture
Management fitness checks — background screening and OFAC/sanctions interdiction for all board members and senior executives
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Control Environment | Board governance, tone-at-top, organizational structure, and assignment of authority establish the foundation for all downstream controls. COSO Component 1. |
| NIST CSF | GV.OC — Organizational Context; GV.RR — Roles & Responsibilities | Governance function: establishing cybersecurity roles, risk appetite, and organizational context before operations begin. CSF 2.0 Govern function. |
| FFIEC | IT Management — Governance & Oversight | FFIEC IT Handbook (Management) requires board-level IT governance, written policies, and defined roles before systems are deployed in a regulated environment. |
| ISO 27001 | Clause 5 — Leadership; A.5 Organizational Controls | Top management responsibility for ISMS, information security policies, and segregation of duties (A.5.3). Wallet key roles map to access control policy (A.5.15). |
// Domain 2 of 8
Minting
Minting is the creation of new stablecoin tokens triggered by a verified, matching deposit of reserve assets. The OCC NPR requires that off-chain reserve verification be completed and confirmed by the custodian before the smart contract executes mint(). No token may be issued that is not backed 1:1 at the moment of creation. Multi-party authorization is required for every mint event.
Process Steps
Reserve deposit confirmed — client or institutional counterparty deposits fiat; custodian confirms receipt and 1:1 HQLA coverage
Off-chain verification gate — reserve management system validates coverage ratio ≥ 1.0 before issuing mint authorization signal
Multi-party authorization — issuer authorized officer, custodian, and compliance officer each sign; quorum threshold met per OCC § 15.14
Smart contract mint() execution — tokens minted on-chain; immutable event log generated for OCC audit trail
Three-ledger reconciliation — on-chain supply, custodian balance, and internal ledger reconciled post-mint
Key Risks
Over-issuance — tokens minted without confirmed reserve backing, breaking 1:1 peg (the PayPal $300T technical error cited in OCC NPR)
Unauthorized minting — compromised key or insider threat executes mint() without proper authorization, inflating supply
Reconciliation failure — on-chain supply diverges from custodian and internal ledger due to system error or latency, creating hidden exposure
Smart contract vulnerability — bug in mint() logic allows double-mint or bypasses authorization gate
Key Controls
Hard mint gate — off-chain reserve verification is a hard protocol prerequisite; smart contract does not execute without custodian confirmation signal
Multi-signature authorization (M-of-N) — minimum 3-of-5 quorum required; any single party compromise cannot authorize a mint unilaterally
Real-time three-ledger reconciliation — automated reconciliation of on-chain supply, custodian balance, and internal ledger; alert on any variance >$0
Immutable on-chain audit log — every mint event timestamped, logged, and reportable to OCC without manual extraction
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Control Activities — Authorization & Verification | Transaction-level controls: authorization, verification of reserve coverage, and reconciliation are the core control activities preventing over-issuance. COSO Component 3. |
| NIST CSF | PR.AC — Identity Management & Access Control; DE.CM — Continuous Monitoring | Protect function: multi-sig access control for mint(). Detect function: real-time reconciliation and alerting on supply variance. |
| FFIEC | Operations — Transaction Processing; Authentication Guidance | FFIEC Authentication Guidance requires multi-factor, multi-party controls for high-risk transactions. Mint authorization maps directly to these requirements. |
| ISO 27001 | A.8.18 — Use of Privileged Utility Programs; A.8.6 — Capacity Management | Privileged access to smart contract admin functions (A.8.18). Supply monitoring maps to capacity/integrity management (A.8.6). Change management for contract upgrades (A.8.32). |
// Domain 3 of 8
Reserve Management
Reserve management governs the composition, valuation, and liquidity of assets backing outstanding tokens 1:1 at fair market value at all times. The OCC NPR (§ 15.11) requires eight eligible HQLA categories, a WAM ≤ 20 days, minimum 10% daily and 30% weekly liquidity buckets, ≤ 40% concentration per eligible financial institution, and an absolute prohibition on rehypothecation. Reserves must be segregated from operational funds in a bankruptcy-remote trust structure.
Process Steps
Daily fair value monitoring — reserve portfolio valued at market; coverage ratio (reserves ÷ outstanding supply) computed and logged daily
Liquidity bucket monitoring — daily: ≥10% in immediately liquid assets; weekly: ≥30% in assets redeemable within 5 business days
WAM calculation — weighted average maturity of portfolio maintained ≤ 20 days; T-bill maturities ≤ 93 days enforced
Concentration monitoring — ≤ 40% per EFI, ≤ 50% of daily liquidity bucket per EFI; automated alerts on approach to limits
Segregation verification — monthly legal confirmation that reserve assets remain in trust, title held correctly, no commingling
Key Risks
Reserve run / insolvency — mass redemption demand exceeds liquid reserves, causing peg break and potentially triggering receivership
Concentration risk — excessive reserves at a single EFI (e.g., SVB-style failure) renders reserves temporarily inaccessible, blocking redemptions
Valuation error — amortized cost treatment of reserves overstates coverage ratio; fair value decline goes undetected until breach
Rehypothecation — reserve assets pledged or loaned without authorization, violating OCC § 15.11(b)(6) absolute prohibition and creating creditor claims
Key Controls
Real-time fair value feeds — automated market data integration; no amortized cost; daily coverage ratio computed against totalSupply() on-chain
Automated liquidity dashboards — 10%/30% bucket monitoring with breach alerts; monetization playbook tested periodically through live transactions
WAM and concentration hard limits — portfolio management system enforces ≤ 20 day WAM and ≤ 40% EFI caps; pre-trade checks block non-compliant purchases
Contractual no-rehypothecation clause — all custody agreements explicitly prohibit pledging, lending, or reuse of reserve assets; right-to-audit included
Bankruptcy-remote trust structure — independent legal opinion confirming segregation; annual reconfirmation by outside counsel
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Risk Assessment; Control Activities — Safeguarding Assets | Liquidity and concentration risk assessment (Component 2). Segregation, fair value controls, and WAM monitoring are asset safeguarding control activities (Component 3). |
| NIST CSF | ID.AM — Asset Management; DE.CM — Continuous Monitoring | Identify function: inventory and valuation of reserve assets. Detect function: continuous monitoring of coverage ratio, WAM, and concentration against defined thresholds. |
| FFIEC | IT Management — Risk Management; Wholesale & Retail Payment Systems | FFIEC IT Handbook risk management processes for financial asset systems. Liquidity monitoring aligns with the Wholesale Payment Systems booklet's intraday liquidity controls. |
| ISO 27001 | A.5.9 — Inventory of Assets; A.8.10 — Information Deletion; Clause 6 — Risk Assessment | Asset inventory and classification for reserve assets (A.5.9). Data integrity requirements for valuation records. Risk assessment process for liquidity and concentration exposures (Clause 6.1). |
// Domain 4 of 8
Custody & Private Key Management
Custody governs the secure storage and lifecycle management of private keys that control both reserve assets and smart contract administrative functions. For stablecoins, key management is the equivalent of a bank vault — the OCC requires HSM FIPS 140-2 Level 3 controls, geographic redundancy, and full audit logging of all key access. The custodian holds reserve assets in a segregated trust, maintaining physical and logical control such that no transfer occurs without issuer authorization.
Process Steps
Key generation — private keys generated in air-gapped HSM environment; ceremony documented with independent witnesses
Key storage and tiering — hot keys (online, limited amounts), warm keys (MFA-gated), cold keys (offline, geographically distributed)
Custodian oversight — covered custodian separately accounts for reserve assets, maintains possession per OCC § 15.21; sub-custodian arrangements require documented oversight controls
Key rotation and backup — periodic rotation schedule; encrypted backups in geographically redundant cold storage; recovery tested annually
Key destruction — decommissioned keys destroyed via certified process; destruction event logged and independently witnessed
Key Risks
Key theft or compromise — private key exfiltrated by external attacker or malicious insider, enabling unauthorized transfer of reserve assets or token minting
Key loss — private key destroyed or lost without adequate backup, permanently locking reserve assets and preventing redemptions
Sub-custodian failure — third-party custodian insolvency or operational failure creates temporary or permanent inaccessibility of reserve assets
Physical security breach — unauthorized physical access to HSM or cold storage facility enables key extraction
Key Controls
HSM FIPS 140-2 Level 3 — all private keys stored in validated HSMs; key material never exists in plaintext outside HSM boundary
Dual control / two-man rule — no single individual can access or authorize key operations; all key ceremonies require two authorized personnel
Geographically redundant cold storage — encrypted key backups in minimum two geographically separated, air-gapped facilities; recovery tested annually
Comprehensive audit logging — every key access, use, and administrative action logged with individual attribution; logs immutable and regularly reviewed
Custodian right-to-audit clause — formal custody agreement includes right to audit, independent SOC reporting, and no-rehypothecation covenant
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Control Activities — Safeguarding of Assets; Segregation of Duties | Physical and logical security over reserve assets. Dual control and segregated custodian responsibilities are core control activities preventing unauthorized access. Component 3. |
| NIST CSF | PR.AC — Access Control; PR.DS — Data Security; RC.RP — Recovery Planning | Protect function: privileged access management for key operations. Data security for key material. Recover function: key backup and recovery procedures align with recovery planning. |
| FFIEC | Information Security — Cryptographic Controls; Physical Security | FFIEC Information Security Handbook: cryptographic key management, physical security for critical infrastructure, and dual control requirements for sensitive operations. |
| ISO 27001 | A.8.24 — Use of Cryptography; A.7 — Physical Controls; A.8.18 — Privileged Access | Cryptographic key management policy and lifecycle (A.8.24). Physical security for key storage facilities (A.7.1–A.7.4). Privileged access control to HSM and key management systems (A.8.18). |
// Domain 5 of 8
Distribution & AML / Transaction Monitoring
Once minted, tokens circulate across wallets, exchanges, and DeFi protocols. Issuers must monitor not only direct customer transactions but all stablecoins in circulation — including transfers between non-customer holders — using blockchain analytics. The GENIUS Act requires a bank-equivalent BSA/AML program, FinCEN Travel Rule compliance for transfers ≥ $3,000, geolocation screening, and OFAC sanctions controls. Unhosted (self-hosted) wallets require enhanced due diligence.
Process Steps
Customer onboarding (KYC) — identity verification, beneficial ownership, PEP and sanctions screening before first transaction
Travel Rule compliance — collect and transmit originator/beneficiary information for transfers ≥ $3,000 (31 CFR § 1010.410); interoperable with counterparty VASPs
On-chain transaction monitoring — continuous blockchain analytics screening of all wallet addresses; flag transactions linked to illicit activity, mixers, or sanctioned entities
Unhosted wallet due diligence — wallet ownership verification (micropayment test or message signing); enhanced monitoring or transaction limits where elevated risk identified
SAR filing and OFAC screening — suspicious activity reports to FinCEN; real-time OFAC screening before every transaction execution
Key Risks
Illicit finance / sanctions evasion — stablecoins used to move funds for sanctioned parties, criminal organizations, or terrorist financing; issuer faces FinCEN/OFAC enforcement
Travel Rule non-compliance — failure to transmit originator/beneficiary data for in-scope transfers; regulatory fine and potential license suspension
Unhosted wallet exposure — inability to verify wallet ownership creates AML blind spot; tokens reaching anonymous or high-risk wallets undetected
Blockchain analytics gaps — reliance on incomplete or outdated threat intelligence fails to identify emerging illicit wallet clusters
Key Controls
Bank-equivalent BSA/AML program — board-certified AML program with designated BSA Officer, risk-based customer due diligence, and documented transaction monitoring thresholds
Real-time blockchain analytics — continuous screening of transaction counterparties against OFAC SDN list, known illicit wallet clusters, and high-risk jurisdictions
Travel Rule solution with VASP interoperability — automated originator/beneficiary data transmission; incoming transfers lacking required data suspended pending investigation
Freeze / burn capability — smart contract administrative function to freeze or burn tokens associated with sanctioned addresses; exercised under documented legal authority
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Control Activities — Transaction Monitoring; Information & Communication | Monitoring controls for transaction-level compliance. Information and communication component: SAR filing, regulatory reporting, and board AML certification (Component 4 & 3). |
| NIST CSF | DE.CM — Continuous Monitoring; RS.AN — Incident Analysis | Detect function: continuous on-chain monitoring for illicit activity indicators. Respond function: SAR investigation and regulatory notification processes map to incident analysis. |
| FFIEC | BSA/AML — Customer Due Diligence; Transaction Monitoring | FFIEC BSA/AML Examination Manual: CDD, EDD for high-risk customers, transaction monitoring program design, and SAR filing procedures are directly applicable. |
| ISO 27001 | A.5.29 — Information Security During Disruption; A.8.16 — Monitoring Activities | Monitoring of information systems for unauthorized or anomalous activity (A.8.16). Logging and event analysis for transaction surveillance. Legal and regulatory compliance requirements (A.5.31). |
// Domain 6 of 8
Smart Contract Management
Smart contracts encode the core logic of mint(), burn(), freeze(), and transfer() — the operational equivalent of a bank's core ledger system. OCC § 15.14 (operational risk) requires that all smart contracts governing stablecoin issuance be subject to the same IT risk management discipline as any critical banking system: independent security audits before deployment, documented change management, segregated development and production environments, and ongoing vulnerability monitoring.
Process Steps
Contract design and specification — functional requirements documented; mint/burn/freeze logic specified with explicit authorization conditions
Development in segregated environment — separate development, test, and production environments; code review gates at each stage
Independent security audit — third-party smart contract audit conducted before mainnet deployment; findings remediated and re-tested
Deployment via multi-sig governance — contract deployment and upgrades require multi-party authorization; no single developer can deploy to production
Post-deployment monitoring — continuous monitoring for anomalous function calls, unexpected state changes, and known vulnerability patterns
Key Risks
Contract exploit — vulnerability in mint/burn logic exploited by attacker; unauthorized token creation, asset drain, or contract takeover
Unauthorized upgrade — upgradeable proxy contract modified without proper governance, altering mint/burn behavior or removing access controls
Logic error — coding defect causes incorrect token accounting, incorrect coverage ratio calculation, or failure to enforce reserve gate
Oracle manipulation — price or reserve data fed to contract is manipulated, causing incorrect coverage ratio and enabling over-issuance
Key Controls
Independent third-party security audit — full code review before mainnet deployment; re-audit required for any material contract upgrade; findings publicly disclosed
Multi-sig governance for deployment and upgrades — contract owner functions (upgrade, pause, freeze) gated behind M-of-N multi-sig; timelock on upgrades for community review
Segregated SDLC environments — strict separation of dev/test/prod; no direct production access for developers; all deployments via documented change management process
Circuit breaker / pause function — emergency pause capability for contract operations in event of detected exploit; pause authority subject to governance controls and incident response playbook
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Control Activities — Application Controls; Change Management | Application-level controls embedded in smart contract logic (mint gate, authorization). Change management controls over contract deployment and upgrades. Component 3. |
| NIST CSF | PR.DS — Data Security; PR.IP — Information Protection Processes; DE.AE — Anomaly Detection | Protect function: secure software development, change management, and access control for contract admin functions. Detect function: anomaly detection on contract event logs. |
| FFIEC | Development & Acquisition — SDLC; Change Management | FFIEC Development & Acquisition Handbook: secure SDLC, testing requirements, change management, and segregation of environments apply directly to smart contract development. |
| ISO 27001 | A.8.25 — Secure Development Life Cycle; A.8.29 — Security Testing; A.8.32 — Change Management | Secure development practices (A.8.25), security testing including penetration testing of smart contracts (A.8.29), and formal change management for production deployments (A.8.32). |
// Domain 7 of 8
Redemption & Burning
Redemption is the reverse of minting — a token holder returns tokens in exchange for fiat, triggering liquidation of matching reserve assets and destruction (burning) of the returned tokens. OCC § 15.11 requires fulfillment within T+2 business days under normal conditions. At redemption volumes exceeding 10% of outstanding supply within 24 hours, the redemption period may extend to T+7 calendar days. The burn() transaction must be executed only after confirmed wire completion to prevent premature supply decrement.
Process Steps
Redemption request receipt — holder submits redemption request; identity verified; request logged with timestamp initiating T+2 clock
Reserve liquidation — sufficient HQLA liquidated to fund fiat payout; T-bills sold or repo unwound; proceeds moved to settlement account
Burn escrow lock — tokens transferred to burn escrow contract; locked pending wire confirmation; cannot be re-spent during pending redemption
Fiat wire settlement — fiat wire executed to holder's designated account; wire confirmation received from correspondent bank
Burn() execution — smart contract burn() executed only after wire confirmation received; permanent destruction logged on-chain; supply decremented
Key Risks
Liquidity squeeze — mass simultaneous redemption demand exceeds immediately liquid reserves; issuer unable to meet T+2 SLA; peg confidence breaks
Premature burn — tokens burned before wire settlement confirmed; holder receives neither fiat nor tokens; creates liability and legal exposure
Redemption fraud — fake or manipulated redemption requests; spoofed wire confirmations used to trigger unauthorized burns
Receivership trigger — failure to redeem within required timeframe allows OCC to trigger immediate receivership under GENIUS Act insolvency provisions
Key Controls
Burn escrow with wire-confirmation gate — burn() executes only after confirmed wire receipt signal from correspondent bank; escrow prevents token re-use during pending redemption
T+2 SLA monitoring with escalation — automated tracking of all open redemption requests against SLA; escalation to senior management if any request approaches breach
Liquidity stress testing — periodic live monetization tests demonstrating ability to sell T-bills and fund redemptions within T+2; results documented for OCC examination
Public redemption policy — policy published on issuer website per OCC requirement; includes all fees, SLAs, T+7 stress trigger condition (>10% supply in 24hr), and dispute resolution process
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Control Activities — Processing Controls; Monitoring Activities | Transaction processing controls (burn gate, escrow lock) ensure completeness and accuracy of redemption cycle. Monitoring of SLA compliance and liquidity stress scenarios. Components 3 & 5. |
| NIST CSF | PR.DS — Data Security; RC.RP — Recovery Planning; DE.CM — Monitoring | Protect function: escrow and burn controls prevent data/asset integrity failures. Recover function: liquidity stress testing and monetization playbook align with recovery planning and resilience. |
| FFIEC | Wholesale Payment Systems — Settlement Risk; Business Continuity | FFIEC Wholesale Payment booklet: settlement risk controls, finality of payment, and operational resilience for high-value payment processing apply directly to the redemption and burn cycle. |
| ISO 27001 | A.5.30 — ICT Readiness for Business Continuity; A.8.6 — Capacity Management | Business continuity readiness for redemption processing under stress conditions (A.5.30). Capacity management ensuring systems process peak redemption volumes without failure (A.8.6). |
// Domain 8 of 8
Attestation, Reporting & Regulatory Governance
The GENIUS Act and OCC NPR establish a multi-frequency reporting regime with criminal liability attached to CEO/CFO certifications. Weekly confidential reports go to the OCC; monthly reserve composition attestations are published publicly with CEO and CFO signatures (18 U.S.C. 1001 criminal liability); quarterly call-report analogs; and annual PCAOB audit for issuers ≥ $50B. The control environment supporting attestation must generate evidence continuously — not assembled under deadline pressure.
Process Steps
Weekly OCC reporting — confidential reserve total report submitted to OCC by designated deadline; automated data pull from reserve management system
Monthly RPAF examination — Registered Public Accounting Firm examines reserve composition, token supply, and reconciliation; findings documented
CEO / CFO certification — executives review RPAF findings and sign monthly attestation; evidence package assembled and retained; published on issuer website
Quarterly call-report analog — financial and operational metrics submitted to OCC; board attestation on risk management adequacy
Annual PCAOB audit (≥$50B) — full financial statement audit by PCAOB-registered firm; findings reported to OCC and published
Key Risks
False certification — inaccurate reserve data submitted in monthly CEO/CFO attestation; knowingly false certification is a federal crime (18 U.S.C. 1001), same standard as Sarbanes-Oxley
Reporting infrastructure failure — manual, fragile reporting processes fail to produce accurate data within OCC weekly deadline; regulatory enforcement action
Evidence gap at RPAF examination — insufficient audit trail, incomplete reconciliation records, or missing documentation fails RPAF examination; attestation qualified or withheld
Board liability exposure — board members who have not received formal criminal liability notice at onboarding may not appreciate the personal risk of signing attestations
Key Controls
Automated reporting data pipeline — reserve valuation, token supply, and reconciliation data generated continuously; weekly report produced by automated pull, not manual compilation
CEO / CFO certification workflow with evidence package — structured sign-off process with pre-assembled evidence package; legal review before signature; retention of signed certificates
Continuous audit trail — all mint, burn, reserve movement, and valuation events logged in tamper-evident system; directly exportable for RPAF examination without manual extraction
Board education program on criminal liability — formal briefing for all board members and certifying executives at onboarding and annually; documented acknowledgment retained
RPAF engagement pre-launch — RPAF engaged during pre-launch period to review evidence architecture; examination readiness assessed before first live certification
// Framework Mapping
| Framework | Component / Domain | Specific Mapping & Rationale |
|---|---|---|
| COSO | Information & Communication; Monitoring Activities | External reporting to regulators (Component 4: Information & Communication). Ongoing evaluation of control effectiveness through RPAF examination and independent audit (Component 5: Monitoring). |
| NIST CSF | GV.SC — Cybersecurity Supply Chain; ID.RA — Risk Assessment; DE.CM — Monitoring | Govern function: reporting obligations and accountability structures. Identify function: ongoing risk assessment and regulatory gap analysis. Detect: continuous monitoring supporting evidence generation for attestation. |
| FFIEC | IT Management — Audit; Reporting to Board & Senior Management | FFIEC IT Handbook (Audit booklet): independent audit function, audit trail requirements, and reporting to board. Management reporting cadence and escalation requirements for regulatory findings. |
| ISO 27001 | Clause 9 — Performance Evaluation; A.5.35 — Independent Review; A.5.36 — Compliance | Internal audit and management review of ISMS effectiveness (Clause 9). Independent review of information security controls (A.5.35). Compliance with legal and regulatory requirements (A.5.36). Nonconformity and corrective action (Clause 10). |