OCCのGENIUS Act最終規則に対応する発行者は、2027年1月18日までに対象判定、準備資産と額面償還、内部統制、報告、申請・移行の準備を進める必要があります。申請受付日、XML仕様、AML・制裁要件は公表待ちですが、待ってから着手するのでは週次報告や通し訓練の準備が間に合いません。
- 今すぐ：自社の発行者類型を判定し、準備・償還・報告データを棚卸しする
- 公表後：申請様式やXML仕様との差分を確定し、実装と模擬提出を行う
- 発効前：経営承認、例外対応、発行から償還・報告までの通し訓練を終える
- 発効後：週次・四半期報告、残高照合、規則更新の監視を継続する
発効日と申請受付日を混同すると、申請準備を始める時点を誤ります。既存発行者の免除も自動ではなく、実質的に完全な申請が審査中であることを前提に書面で求める仕組みです。さらにPS-01の週次サイクルは短いため、データの所在や承認経路を発効後に探し始める余裕はありません。
責任編集：暗号資産ラボ編集部 法規制レビュー：暗号資産ラボ編集部 最終レビュー日：2026年10月24日
OCC、Federal Register、法律原文などの一次資料を優先し、業界団体の主張は見解として区別しました。編集部による一般情報であり、法律・会計・税務・投資の個別助言ではありません。自社の事実関係は有資格の専門家と監督当局へ確認してください。
OCC最終規則の全体像と2027年1月18日までの期限
まなぶ「クリプ先生、12 CFR Part 15は法律そのものですか？」
クリプ「GENIUS Actを実務へ落とすOCC規則だよ。申請や報告まで具体化しているんだ。」
最終規則の公表から発効までのスケジュール
OCCは2026年10月21日に最終規則を公表し、10月23日付のFederal Registerに掲載しました。最終規則とGENIUS Actの主要規定は2027年1月18日に発効します。申請受付はOMBによる情報収集の最終承認後に始まり、開始日はOCCが別途公表します。発効日と受付開始日を混同せず、受付を待つ間にも資料整備を進める必要があります。
対象判定フローと最小用語集
- 誰が発行するか：発行法人と親会社、設立地、現在の免許を特定する。
- どこで提供するか：米国顧客への発行・販売・償還の経路を図にする。
- 誰が監督するか：OCC、FDIC、州当局などの候補を法人ごとに対応付ける。
- 何が不足するか：12 CFR Part 15と現行の規程・契約・システムとの差を記録する。
| 略語 | 初心者向けの意味 | 実務で確認すること |
|---|---|---|
| OCC | 米国通貨監督庁。国法銀行などを監督する機関 | 自社または子会社がOCCの管轄に入るか |
| OMB | 行政管理予算局。政府の情報収集手続も審査する | 申請受付の前提となる承認とOCCの開始告知 |
| PS-01／PS-02 | 許可発行者が使う週次・四半期の標準報告様式 | 元データ、締め時刻、承認者、訂正手順 |
| LEI | 法人を国際的に識別する番号 | 既存番号の利用可否。報告だけのための新規取得は必須ではない |
| Digital Ledger Identifier | 報告対象の分散型台帳を識別するコード | 社内のチェーン名との対応表 |
| GAAP／IFRS | 米国会計基準／国際財務報告基準 | 外国発行者もPS報告では米国GAAP前提との差分がある |
| BSA・AML・CFT | 銀行秘密法、マネーロンダリング・テロ資金供与対策 | OCC規則とは別に確定する財務省系ルール |
| OFAC | 米財務省の制裁執行機関 | 対象者のスクリーニングと取引停止・記録の手順 |
12 CFR Part 15が定める主要領域
新設12 CFR Part 15は、発行、準備資産、額面償還、リスク管理、監査・報告、カストディ、申請、監督、資本を扱います。準備資産だけの規則ではなく、利用者の請求に応じる業務、状態を検証する統制、当局へ継続報告するデータ基盤までを一体で整える枠組みです。
自社は対象か：発行者類型と監督当局を確認する
OCC規則の対象となる発行者
対象には国法銀行・連邦貯蓄金融機関の子会社、連邦認可非銀行発行者、一定の州認可発行者、外国発行者が含まれます。ただし、すべてに同じ監督経路が当てはまるわけではありません。発行法人、設立地、親会社、免許、顧客所在地、準備資産の保有法人、販売仲介者を法人単位で整理します。
州認可・FDIC監督下・外国発行者で異なる適用関係
州認可発行者は州制度との関係を、FDIC監督下の主体はFDIC側の規則を確認します。外国発行者も米国外法人というだけで対象外とは限りません。比較の視点は英国ステーブルコイン規制の申請ガイドも参考になりますが、米国での適用判断はOCC等の規則に基づきます。米国での提供形態と同等監督、報告義務を調べます。現段階ではPS報告をIFRSに置き換えることは認められていないため、米国GAAP前提との差分も確認します。
準備資産と額面償還の体制を整える
額面償還を支える準備資産の要件
許可発行者は額面償還に応じられる準備と、事業モデルに見合う流動化能力を維持する必要があります。資産の適格性、残高、保管先、満期、集中、担保設定を記録し、発行残高と継続照合します。償還は請求受付、権限確認、トークン処理、支払指図、例外処理まで端から端で文書化します。
市場流動性とオペレーションを含む換金能力の点検
高品質な資産でも、市場の買い手、銀行、カストディ、台帳が止まれば換金が遅れる場合があります。償還能力は資産の信用力だけでなく、国債・レポ市場、ディーラー、決済網、運用体制にも左右されます。請求集中、取引先障害、チェーン停止、鍵へのアクセス不能を組み合わせ、自社データに基づくストレステストを行います。
リスク管理・カストディ・資本の統制を設計する
リスク管理・監査・資本バックストップ
規則はリスク管理、監査、カストディ、資本も扱います。流動性、信用、オペレーション、サイバー、第三者、法令などをリスク台帳へ登録し、責任者、指標、エスカレーション条件を決めます。監査では規程の存在だけでなく、残高、承認ログ、例外、是正状況を検証できる証拠を残します。
カストディ資産と自己資産の分別管理
準備資産と資本は同じものではありません。準備はトークン償還を支え、資本バックストップは事業上の損失を吸収します。カストディでは顧客・準備資産と自己資産を契約、口座、ウォレット、帳簿で分けます。委託先の再委託、監査権、障害通知、事業継続、終了時の返還も契約で確認します。
利息・利回り禁止と第三者報酬の境界を見直す
まなぶ「第三者が払えば報酬は必ず大丈夫ですか？」
クリプ「必ずではないよ。原資や指図など実態ごとに判断されるんだ。」
発行者に禁止される保有連動の利息・利回り
発行者がステーブルコインの単なる保有を理由に利息・利回りを払うことは禁止されます。名称をポイントや特典に変えても、保有残高や期間に連動し、発行者が原資や条件を支配するなら検討が必要です。利用規約、広告、アプリ画面、会計仕訳、送金記録を同じフロー図で照合します。
関連会社・取引所など第三者報酬の個別判断
取引所、関連会社、販売先など第三者の報酬は一律禁止ではなく、事実関係ごとの判断です。支払法人の名前だけでなく、原資、損失補填、最低報酬保証、条件設定、指図、ブランド表示を確認します。銀行業界と暗号資産業界の評価は分かれていますが、実務では最終規則とOCCの説明を基準にします。
銀行業界と暗号資産業界で分かれる評価
銀行業界は、取引所や関連会社を通じた保有連動報酬が広く残れば、銀行預金から資金が移り、融資原資にも影響し得ると批判しています。これに対し暗号資産業界は、法律が直接禁じたのは発行者自身による利息・利回りであり、第三者を一律に禁じるのは権限を超えると主張しました。どちらも規則そのものではなく、利回り禁止の境界に対する利害関係者の評価です。
実務では賛否を採用するのではなく、報酬の原資、金額の決め方、発行者の指図、関連会社との契約、保有期間との連動を事実で確認します。名称を「ポイント」や「特典」に変えても、発行者が実質的に資金を出し、保有だけを条件に設計していれば評価は変わり得ます。反対に、取引所が独自の役務対価として支払うから自動的に許されるとも断定できません。
PS-01・PS-02の週次・四半期報告に備える
PS-01・PS-02で提出する財務・準備・流通情報
PS-01・PS-02は許可発行者の準備、発行残高、償還、財務情報などを週次・四半期で標準報告する様式です。各項目について原始データ、集計ロジック、所有部門、承認者、保存先を記したデータ辞書を作ります。短い締め周期に備え、時刻、休日、遅延、訂正の手順を決めて模擬報告を行います。
Digital Ledger Identifierと制限残高のデータ整備
報告では自由記述のチェーン名ではなくDigital Ledger Identifierを用い、アクセス制限、タイムロック、紛失などによる利用不能残高も区分します。LEIは利用できますが、提出だけのための新規取得は必須ではありません。XMLスキーマ、編集チェック、サンプルは実施前に別途公表予定なので、抽出と変換を分離して変更可能にします。
外国発行者・LEI・XML仕様の留意点
外国発行者も原則として同じPS-01・PS-02を使い、現段階ではIFRSの数値をそのまま代替提出できません。まず現地帳簿の勘定科目と米国GAAP前提の報告項目を対応させ、換算・組替え・承認の責任者を決めます。米国側だけで数値を作るのではなく、海外本社、準備資産の保管先、会計担当の締め時刻を週次日程へ組み込みます。
LEIは既に持っていれば利用できますが、PS提出だけを理由に新規取得する義務は示されていません。XML仕様は未公表なので、現時点では元データの抽出、業務上の計算、提出形式への変換を分けて設計します。仕様公開後に変換層だけを更新できれば、会計ロジック全体の手戻りを抑えられます。
申請開始を待ちながら移行措置を準備する
申請受付開始までにそろえる資料
申請受付日は未公表でも、組織図、所有関係、経営陣、事業計画、準備・償還、財務、リスク管理、監査、カストディ、技術、外部委託の資料は準備できます。各資料へ基準日、所有者、承認状態を付け、説明と運用実態が一致するかを検証します。申請書は広報資料ではなく監督上の審査資料です。
既存発行者が検討する書面免除
実質的に完全な申請が審査中の既存発行者には、書面で一部要件の免除を申請する道があります。自動猶予ではなく、申請中と承認済みも別です。必要な活動、理由、リスク低減策、完全対応への工程を示します。対象判定、差分分析、契約・システム改修、模擬報告、独立レビューの順に内部期限を逆算します。
発効日までの社内対応順序
- 適用判定：法務が法人・商品・提供地域を整理し、監督当局と未解決論点を示す。
- 差分分析：財務、リスク、技術、業務が現行状態と要件の差を記録する。
- 設計と改修：規程、契約、データ項目、権限、例外処理を更新する。
- 模擬運用：発行、準備計上、PS報告、償還までを実データで追う。
- 独立確認と承認：担当外のレビュー担当と経営陣が残余リスクを確認する。
工程の完了条件は「会議を開いた」ではなく、承認済み成果物と再現できる証拠があることです。免除を申請する場合も、承認前は通常要件に対応できる代替計画を残し、免除申請予定を完了扱いにしません。
AML・制裁対応と預金保険の誤解を残さない
別途確定を待つAML・CFT・OFAC要件
FinCENの規制動向も踏まえる必要があります。BSA・AML・CFTとOFAC制裁の実施要件は、OCC最終規則とは別のFinCEN・OFACルールで扱われます。OCC対応だけでコンプライアンス設計が完成したとはいえません。規則案、最終規則、ガイダンスを区別し、顧客確認、取引監視、制裁スクリーニング、記録保存の変更箇所を管理します。
ステーブルコインと銀行預金の保護の違い
決済用ステーブルコイン自体はFDIC預金保険や米国政府保証の対象ではありません。準備預金が銀行に置かれていても、利用者のトークンが銀行預金になるわけではありません。利用者向け表示ではドル連動、額面償還、準備資産、預金保険を区別し、安全性や価格維持を保証する表現を避けます。
証拠・変更管理と通し訓練
証拠資料を一つの管理表へ集約する
規則対応では、規程を作ることと、規程どおり運用した証拠を示すことは別の仕事です。準備残高の照合記録、償還テスト、取締役会資料、委託先審査、報酬契約のレビュー、報告値の承認ログを一つの証拠管理表へ登録します。各証拠には対象要件、基準日、作成部門、承認者、保存期間、次回更新日を付けます。申請時と監督時で異なる数字を提出しないよう、正式版を識別できる状態にしてください。
文書の名称だけを並べるのではなく、どの条文や報告項目を裏付けるかまで対応付けます。たとえば流動性方針には、保有可能資産の説明だけでなく、実際の保有明細、売却経路、権限者、ストレステスト結果が必要です。外部委託先から受け取る報告に不足があるなら、契約改定や追加データの取得に時間がかかるため、早い段階で依頼します。
未確定事項を変更管理する
未確定事項は空欄のまま放置せず、「何が未確定か」「どの公式情報で確定するか」「確定後にどのシステム・規程・契約へ影響するか」を記録します。申請受付日なら申請プロジェクト、XMLスキーマなら報告システム、AML最終規則なら顧客管理と取引監視が主な影響先です。更新を見つけた担当者が関係部門へ伝え、影響評価と承認を経て本番へ反映する手順を決めます。
報道は早い一方、見出しだけでは提案、最終規則、施行済み要件を区別できない場合があります。OCCの公式ハブ、Federal Register、FinCEN・OFAC、FDICの資料へ戻り、文書の種類、公表日、発効日、適用対象を確認します。業界団体の声明は争点を知る材料になりますが、義務の根拠そのものとは分けて記録します。
発行から償還・報告まで通しで訓練する
部門ごとのテストに加え、一件の発行を選び、入金確認、トークン発行、準備計上、カストディ記録、PS報告への集計、償還受付、消却、支払いまでを追跡します。通常取引だけでなく、タイムロック、凍結、利用不能、訂正、チェーン障害などの例外も試します。法務上の定義とシステムのステータスコードが一致しない場合は、報告前にマッピングを修正します。
訓練では、担当者不在、銀行休業、委託先障害、データ遅延も想定します。代替承認者と連絡網を確認し、手動処理を使った場合の記録方法を定めます。結果は成功・失敗だけで終わらせず、原因、是正担当、期限、再テスト日を残します。こうした運用証拠が、書面上の方針が実際に機能することを示します。
経営陣へ残余リスクを報告する
経営報告では、完了率だけでなく、未解決の適用論点、流動性上の弱点、契約改定の遅延、技術仕様待ち、模擬報告の差異を示します。確定事項への未対応と、当局の公表待ちで確定できない事項を色分けすると、意思決定を誤りにくくなります。免除を検討する場合も、申請予定であることを対応完了として扱わず、承認されない場合の代替策を用意します。
2027年1月18日は計画の終点ではなく、継続監督と報告の開始点です。発効後も準備残高、償還実績、第三者報酬、障害、規則更新を定期的に見直します。買収、新チェーン対応、新しい販売先、新報酬制度など事業変更の際には、当初の対象判定と統制評価を再実施してください。
ステーブルコインの基礎はステーブルコインの仕組みも参照してください。制度は特定商品の安全性、価格、利回りを保証するものではありません。
発効日までの実務チェックリスト
2027年1月18日から逆算するロードマップ
| 時期 | 主担当 | 成果物 | 完了条件 |
|---|---|---|---|
| 今すぐ | 法務、財務、システム | 法人別対象判定、準備・償還フロー、データ棚卸し | 根拠、責任者、未解決事項が一つの管理表にある |
| 申請受付前 | 法務、経営企画、各統制所有者 | 組織・所有・事業計画、規程、契約、財務、監査資料 | 基準日と承認状態が明確で、説明と運用実態が一致する |
| 仕様公表後 | システム、財務、報告責任者 | XML変換、編集チェック、サンプル提出、訂正手順 | 仕様との差分が解消し、模擬提出を再現できる |
| 発効前 | 全関係部門、経営陣 | 通し訓練、独立レビュー、取締役会等の承認 | 例外を含むテストが終わり、残余リスクと代替策が承認される |
| 発効後 | 報告、財務、コンプライアンス | PS報告、日常照合、障害・変更記録 | 期限内提出と訂正が継続し、公式更新を定期確認する |
日付が未公表の作業は「保留」ではなく、公開を検知する担当者と影響先を先に決めます。受付日なら申請責任者、XMLなら報告システム、AML最終規則なら顧客管理と取引監視が更新先です。公表から社内反映までの所要日数を決めておくと、発効直前の集中を避けられます。
今すぐ着手する確定済み要件
今すぐ着手するのは、適用判定、準備と償還の照合、統制責任者の決定、第三者報酬の実態確認、PS報告データの棚卸し、申請証拠の収集です。項目ごとに責任者、期限、証拠、未解決事項を付けます。チェック欄を埋めるだけでなく、実データで発行から準備計上、報告、償還まで一件を追跡します。
対応を「完了」と判断するための基準
対象判定の完了は、単に「OCC対象」と書くことではありません。発行法人、親会社、設立地、保有する認可、米国での提供方法、準備を保有する法人、償還義務を負う法人を一枚の図にし、法人ごとに想定監督当局と判断根拠を付けます。州認可や外国発行者を含む場合は、OCC規則と別の監督経路を混ぜず、確認が必要な論点を未解決として残します。判断の前提が変わったときに再評価できることが完了条件です。
準備・償還の完了は、方針書の承認だけでは測れません。ある基準日の発行残高を準備資産明細と照合し、差異があれば原因と修正者を追えること、償還請求から権限確認、トークン処理、支払指図まで一件を再現できることが必要です。通常時だけでなく、請求集中、銀行休業、カストディ障害、チェーン停止、鍵へアクセスできない場合を組み合わせ、代替経路と承認者が機能するかを確かめます。
報告対応の完了は、PS-01・PS-02の欄に仮の数字を入れた状態ではありません。各項目について、原始データ、対象時刻、計算式、除外条件、所有部門、承認者、保存場所をたどれなければなりません。利用可能残高とタイムロック、凍結、紛失などの利用不能残高を、システム上の状態コードから同じ基準で分類します。複数チェーンでは合計だけでなく台帳別に再集計できるようにし、Digital Ledger Identifierとの対応を管理します。
申請準備の完了は、資料のファイル名が並んだ時点ではなく、組織、所有、経営陣、事業計画、財務、リスク、監査、カストディ、技術、外部委託の説明が相互に矛盾しない状態です。資料ごとに基準日、作成者、承認者、正式版、更新予定日を示します。規程には実際の権限やデータ取得方法を反映し、運用していない理想像を申請資料へ書かないことが重要です。
利回り・報酬の確認では、名称ではなく取引全体を図にします。誰が利用者へ支払い、資金を誰が負担し、率や対象者を誰が決め、発行者や関連会社がどこまで指図するかを契約と資金移動で照合します。発行者自身の保有連動利息・利回りの禁止と、第三者報酬の個別判断を混同せず、新しい販売先やキャンペーンを始めるときも同じ審査を通します。
通し訓練で必ず含める例外
最初の訓練では、一件の発行を選び、入金、トークン発行、準備計上、保管記録、PS報告への集計、償還、消却、支払いまで同じ識別情報で追います。次に、締め時刻をまたぐ取引、休日の償還、データ到着の遅延、誤った分類の訂正を試します。週次報告では調査時間が限られるため、担当者が不在でも代替承認者が根拠を確認できる状態を作ります。
技術上の例外として、アクセス制限、タイムロック、紛失、凍結、チェーン障害を別々の状態として扱います。法務が使う定義、利用者画面の表示、台帳のイベント、報告項目の分類が一致するかを確認します。あるチェーンの機能やステータスを別チェーンへそのまま当てはめると、利用不能残高や償還処理を誤るため、共通ルールと台帳固有のルールを分けます。
外部依存の例外では、銀行、カストディ、取引相手、データ提供者が止まる場面を想定します。連絡先だけでなく、代替サービスへ切り替える権限、手動処理の記録、利用者への通知、復旧後の照合を確認します。テスト結果は成功・失敗の二択で終わらせず、原因、暫定措置、恒久対応の担当、期限、再テスト日を残します。
経営陣へは完了率だけでなく、確定要件への未対応と、当局の公表待ちで確定できない事項を分けて報告します。申請受付日、XML仕様、AML・制裁の最終要件は、未確定だから対応不要なのではありません。公式情報を確認する担当、影響を受ける規程・契約・システム、公表後の判断期限を置き、免除が認められない場合も含めて代替策を承認します。
公表待ちの仕様・開始日・別規則
公表待ちは申請受付開始日、XML関連仕様、AML・制裁の最終要件、追加解釈です。法務は適用・契約・表示、財務は準備・流動性・資本・会計、システムは台帳識別・状態分類・データ品質を担当します。同じ用語集、法人図、データ辞書を共有し、2027年1月18日から逆算して取締役会承認とテスト日程を置きます。
法務・財務・システム部門の最終確認
| 部門 | 最終確認 | 完了を示す証拠 |
|---|---|---|
| 法務・コンプライアンス | 適用類型、申請・免除、報酬契約、利用者表示、AML・制裁の未確定事項 | 法人別判断メモ、契約レビュー、変更管理票 |
| 財務・リスク | 準備の適格性、発行残高照合、流動性、資本、GAAP差分 | 残高照合、ストレス結果、承認済み方針 |
| システム・業務 | 台帳識別、利用不能残高、XML変換、権限、障害・訂正処理 | データ辞書、テストログ、再実施結果 |
| 経営陣 | 未解決事項、免除不承認時の代替策、発効後の報告責任 | 承認議事録、残余リスク一覧、責任者指名 |
参考資料
OCC、Federal Register、米国政府刊行物、FDICなどの一次資料を中心に確認しました。
義務の確認はOCCの最終規則・通達・報告様式と法律原文を優先してください。ABAとBlockchain Associationは業界見解、APとRoll Callは報道、arXiv論文は研究資料として参照し、公式要件とは区別しています。
