H.R.3633 把加密規則變成一張圖

H.R.3633 把數位資產的監管切成 SEC、CFTC、Fed 三條線，重點是你要怎麼畫出自己的合規地圖。

我盯加密政策很多年了，最煩的不是法條難讀，是每次有人嘴上講「清楚了」，我一打開文件還是三套說法互相打架。SEC 一套、CFTC 一套、Fed 又是另一套，外加一堆人把摘要講得像已經定案。直到我讀到 H.R.3633 on Congress.gov，我才覺得這東西至少像一份系統設計稿，不像純情緒輸出。它不是在講一個漂亮口號，它是在切權責、切邊界、切誰能碰誰。

我不是把它當新聞看。我是把它當一份規則路由圖來看。因為如果你是做交易所、錢包、託管、支付、發行，或者任何會碰到數位資產的產品，真正麻煩的從來不是「有沒有監管」，而是「哪個機關管哪一段」。這種東西一旦看錯，後面整個產品線都會歪掉。

它不是一個市場，它是三條管線

“To provide for a system of regulation of the offer and sale of digital commodities by the Securities and Exchange Commission and the Commodity Futures Trading Commission...”

翻譯一下就是：這個法案不是想把所有東西塞給同一個主管機關，而是要把數位商品的規則拆給 SEC 跟 CFTC。這句話看起來很乾，但它其實在講一件很實際的事：別再假裝所有 token 都是同一類東西。

我最在意的字是 “digital commodities”。因為這代表法案想留一條不是證券的路。也就是說，它不是先假設所有資產都要進 SEC 的框，再慢慢補例外；它是先承認有些東西應該走商品邏輯，再去定邊界。這種設計思路很像我看 API 規格時最怕的事：文件先說「支援多種模式」，結果每個模式都靠人工判斷，最後根本沒有模式，只有事故。

我以前做過一個平台，團隊也很愛說「我們先做一套統一規則」。聽起來很省事，實際上就是把分類問題延後。延後不會消失，只會變成更貴的例外處理。H.R.3633 也是這味道。你如果要真的用它來做產品設計，第一件事不是看口號，而是看分類。

實操寫法很簡單：先把你手上的資產一個一個列出來，不要先寫產品文案。每個資產都要回答它更像證券、商品，還是混合型。然後把發行、交易、託管、清算拆成不同欄位。因為最貴的不是你不知道產品功能，是你不知道哪一步會踩到哪個機關。

• 先分類資產，再談上架。
• 把發行、交易、託管、清算拆開看。
• 把「誰管這一步」寫進文件，不要只寫「合規處理中」。

真正的重點不是監管多寡，是邊界誰說了算

這份法案讀起來不像消保宣言，比較像邊界管理文件。這點很重要，因為很多人談加密監管都在問「會不會更嚴」。我覺得那問題太粗了。真正該問的是：誰對哪一段流程有第一句和最後一句話語權？

SEC 跟 CFTC 的歷史包袱不一樣，執法習慣也不一樣。這不是學術差異，這會直接變成產品差異。你怎麼寫揭露、怎麼做交易報告、怎麼設計託管、怎麼處理市場操縱風險，全部都會被主管機關的邏輯反推回來。你不可能只在前端掛一層「我們很重視合規」就收工。

我看過太多團隊想要「一個 policy engine 解決所有問題」。結果最後根本不是 engine，是 router。這份法案給我的感覺也是一樣：它不是要把所有規則混成一鍋，而是要先決定流量怎麼走。只要 routing 清楚，後面才有可能落地；routing 不清楚，所有公司最後都會自己發明一套解釋，然後互相打架。

實操上，我會直接做一張內部對照表，讓產品、法務、風控坐同一張桌子看。不要等法務最後丟一句「再確認一下」。那種說法通常代表前面根本沒對齊。

• 做一張矩陣：資產類型、產品型態、交易型態、主管機關。
• 標出哪個功能會跨到不同監管邏輯。
• 把假設寫下來，因為未來一定會被問。

Fed 那段最容易被滑過去，但其實很要命

“...to amend the Federal Reserve Act to prohibit the Federal reserve banks from offering certain products or services directly to an individual...”

翻譯一下就是：法案想限制 Federal Reserve banks 直接對個人提供某些產品或服務。這不是枝微末節，這是結構限制。因為一旦中央銀行系統不能直接碰個人，整個零售端的數位金流設計就會長得不一樣。

我看支付跟 fintech 團隊時，最常出現的誤會就是把「Fed」想成只有宏觀政策層面的東西。其實這句話更像產品邊界條款：誰可以直接服務使用者，誰只能在後台運作。這會影響 onboarding、身份驗證、託管、客服、爭議處理、失敗回復，全部都會被拉進來。

這也代表私人中介的角色不會消失，反而更重要。因為如果公共部門不能直接到前台，那前台就還是你們這些做產品的人在扛。很多人以為這類法條是在講中央銀行權力，其實更像是在保留私部門的介面層。

實操寫法：如果你在做支付，不要把這段當成抽象央行政策。你要問的是，你的商業模式是不是建立在「公共發行方直接碰用戶」這件事上。如果是，那你就要重新想中介層；如果不是，那你要把自己定位成哪一層服務商，寫清楚。

• 檢查你是不是依賴直接公共機構接觸用戶。
• 把中介層責任寫進產品流程。
• 把客服、身份、託管視為核心能力，不是附屬功能。

CBDC 那句話不是技術規格，是用途煞車

“...to prohibit the use of central bank digital currency for monetary policy...”

翻譯一下就是：這份法案想限制 CBDC 被拿去做貨幣政策工具。注意，我說的是「限制用途」，不是直接說「完全不能有 CBDC」。這差很多。因為政策文件最有意思的地方，往往不是東西能不能存在，而是它能不能被拿去做某件事。

我很怕技術討論只盯著名詞吵。大家一直問「這算不算 CBDC」，但真正該問的是「它能不能被用來做貨幣政策」。這份法案的語氣很明顯是在管行為，不是在管名牌。對我來說，這才是重點，因為限制用途比限制存在更接近實作。

如果你是架構師，這段就該翻成 guardrail。系統可以存在，但某些操作被鎖住，這在軟體裡很正常，在政策裡也該一樣正常。不要把「有這個工具」跟「可以怎麼用」混在一起，不然你會把規則看得很模糊。

實操寫法：每次你評估數位貨幣方案，都先拆成兩層。第一層是這東西是不是存在；第二層是它被允許做什麼、禁止做什麼。只要用途被禁，就不要再拿架構幻想去硬拗。

那句「and for other purposes」不是廢話，是提醒你別只看摘要

我每次看到法案最後那種 “and for other purposes” 都會提高警覺。因為這通常代表摘要只講了表面，真正會影響執行的東西藏在定義、例外、過渡條款、執法機制裡。你如果只看一行摘要，就很容易以為自己懂了。

這跟我看 dependency upgrade 很像。README 寫得很平靜，真正炸掉的通常在 edge case。法案也是一樣。它說要建立一個監管系統，那就代表註冊、揭露、豁免、執法、過渡安排，全部都會有影響。這些才是落地時最痛的地方。

所以我的做法從來不是只看摘要。我會先把全文拆成 checklist，再叫團隊一起看 flow。你是新創就做一份 regulatory diff；你是大公司就做 gap analysis；你是法務就別只丟 memo，直接跟產品把流程畫出來。這樣比較不會各說各話。

• 把定義條文翻成產品語言。
• 把例外條款單獨列出來看。
• 把過渡條款跟常態義務分開處理。

如果你真的要照這份法案做準備，我會這樣切

如果 H.R.3633 真的往前走，而且形式沒有大改，我不會先動手重寫所有東西。我會先做暴露面盤點。哪些地方碰到 digital commodities？哪些地方碰到直接零售服務？哪些地方碰到可能被解讀成貨幣政策相關？先把這三塊切出來，才知道火會燒哪裡。

我也會把不確定性講白。這不是那種看完就能拍桌說「結論很明確」的文件。它的價值在於想把邊界講清楚，但「講清楚」跟「完全定案」是兩回事。只要進入實作，爭議一定會冒出來。

所以真正該做的不是猜結果，而是準備分類工作。建立內部審查關卡、保留決策紀錄、讓產品負責人能說清楚為什麼這個功能落在這個框。這樣未來真的被問到時，你不會整組人一起裝死。

我對 H.R.3633 的理解很簡單：它不是在替加密站台，它是在畫線。線畫得再漂亮，如果你的系統跟不上，那也是白搭。你要準備的不是口號，是能跟著線跑的流程。

可抄的模板

# 數位資產規則地圖模板（可直接貼進內部文件）

## 1) 資產分類
- 資產名稱：
- 產品表面：
- 可能類別：證券 / 商品 / 混合 / 未定
- 判斷理由：
- 未解問題：

## 2) 主管機關路由
| 活動 | SEC | CFTC | Fed | 其他 |
|---|---:|---:|---:|---:|
| 發行 |  |  |  |  |
| 交易 |  |  |  |  |
| 託管 |  |  |  |  |
| 清算 |  |  |  |  |
| 零售接觸 |  |  |  |  |
| 貨幣政策相關用途 |  |  |  |  |

## 3) 直接對用戶檢查
- 是否需要公共機構直接對個人提供服務？
- 如果有，是哪一項服務？
- 該服務是否受法規限制？
- 現在由哪個私人中介承接？

## 4) CBDC / 貨幣政策檢查
- 這是不是 CBDC 或 CBDC-adjacent？
- 使用情境是否涉及貨幣政策？
- 是否有明確禁止條款？
- 哪個控制點可以防止違規用途？

## 5) 實作備註
- 需要揭露：
- 報告義務：
- 註冊影響：
- 託管影響：
- 執法風險：

## 6) 決策紀錄
- 日期：
- 審查人：
- 決策：
- 理由：
- 來源條文 / 引用：

## 7) 下一步
- 法務複核：
- 產品調整：
- 工程修改：
- 合規更新：
- 下次重審日期：

這份模板我會真的拿去用。它把一份看起來很硬的法案，轉成能放進 planning doc、risk review、或產品 spec 的格式。重點不是猜最後會不會過，而是別再假裝這種文字不能操作化。

原始來源是 Congress.gov 的 H.R.3633 全文。我上面的拆解是原創評論，模板則是根據法案內容整理出的衍生工作稿；另外可對照 SEC、CFTC、Federal Reserve 的官方頁面一起看。