MiCA把合規變成產品設計

MiCA 逼 Web3 團隊把合規當成產品設計，而不是事後補文件。

我最近一直在看一件很煩的事：很多 Web3 團隊講到歐洲市場，口氣都像在講「先上線再說」。幣先發了、錢包先接了、穩定幣先串了，然後才有人慢吞吞問一句：那歐盟到底能不能用？我真的看過太多次這種場面，前面大家都很有信心，後面一碰到法規就整桌安靜，像剛剛才發現自己把產品蓋在地雷上。

MiCA 讓這件事變得更貴。它不是多幾份聲明書、多幾個勾選框而已，它直接改你怎麼設計資格判斷、託管、代幣分類、穩定幣流程，甚至連 app 裡誰能按哪個按鈕都要重新想。你如果還把它當法務備註，那我只能說，這種做法很容易把團隊送進反覆重工的地獄。

這篇我主要是拆 Blockchain Council 的文章，不是當法規摘要看，而是當成一份給真的要出貨的人看的 build guide。MiCA 原文是 Regulation (EU) 2023/1114，這不是傳聞，是已經落地的規則。你如果還想靠「等最後指引」拖時間，我只能說，時間早就開始跑了。

MiCA 不是公告，是系統約束

MiCA 不再是背景政策，它是產品設計的限制條件。

白話翻譯就是：MiCA 改變的是產品怎麼跑，不只是你對外怎麼寫聲明。只要你的產品碰到歐盟使用者、上架代幣、發行穩定幣、做託管、做交易、做兌換，這件事就不是法務最後看一眼而已，而是從第一個 sprint 就要設進架構裡。

我之前最常看到的失敗模式，是工程跟法務互相丟球。工程說「歐洲就交給法務」，法務說「產品應該知道怎麼擋」，結果沒人真的把邏輯寫進系統。等到使用者真的進來，才發現 onboarding、KYC、付款路由、代幣權限、客服流程全都在往歐洲前進，然後才想臨時 geo-block。太晚了。

MiCA 的時間線也很現實：穩定幣相關規則已經從 2024 年 6 月 30 日開始適用，CASP 相關的大部分規則也已經在 2024 年 12 月 30 日全面上路。這代表「等一下再說」不是策略，只是拖延。

實操寫法很簡單，先做 scope map，再做功能。不要先寫 feature 再補政策。把每一條使用者路徑列出來，標記哪裡會碰到歐盟，然後把結果寫成機器看得懂的規則，不要只放在 PDF 裡面裝樣子。

• 盤點所有 EU-facing 接觸點：網站、App、API、客服、行銷、推薦連結。
• 每個接觸點都問一次：這是 offer、託管、交易、兌換，還是穩定幣發行。
• 把判斷結果寫進權限或政策層，不要只寫在 Notion 文件。

CASP 授權就是新的市場門檻

MiCA 對 Web3 團隊最直接的改變，就是 CASP 制度。CASP 是 crypto-asset service provider，也就是加密資產服務提供者。白話講，你如果要做託管、交易平台、下單執行、投資組合管理、代幣配售、建議服務，這就不是「我們有在歐洲做生意」這麼簡單，而是你要先拿授權。

授權是由各會員國主管機關處理，拿到一國之後，理論上可以做跨境通行。這聽起來很爽，但前提是你得先有夠完整的治理、內控、風險控管、申訴處理、利益衝突管理、客戶資產保護。這些東西不是寫一份漂亮 policy 就會自己長出來。

我看過很多新創最愛犯的錯，就是把授權當成法務備案。結果到了要送文件時，才發現資料結構根本不夠。你只存電話國碼或最後登入 IP，根本沒辦法證明使用者到底是不是歐盟客戶、服務到底是提供給哪個實體、限制到底是誰決定的。主管機關一問，你就只能開始猜。

實操寫法是把授權準備當成平台里程碑，不是法務收尾。你要先把未來授權文件會問的東西做進系統。

• 定義誰負責、誰核准、誰能 override。
• 把客戶資產和公司資產在帳務與託管設計上分開。
• 申訴、揭露、例外處理都要能被稽核。

如果你要追主管機關與標準更新，先看 歐洲證券及市場管理局 和 歐洲銀行管理局。這兩個不是擺設，是真會影響你怎麼做產品的人。

穩定幣是 MiCA 最先咬人的地方

如果你只想看一段，那我會先看穩定幣。文章講得很直白：ART 和 EMT 是 MiCA 管得最嚴的部分，因為監管者把它們看成消費者保護、金融穩定、貨幣主權問題，不是單純的 token 類型而已。

ART 是 asset-referenced token，EMT 是 e-money token。這兩類發行人要面對授權、白皮書、儲備資產、贖回權、治理、申訴處理等要求。還有一條很多產品團隊會漏掉：MiCA 禁止對穩定幣持有人支付利息。也就是說，如果你的成長模型是「持有就有收益」，那你在歐盟這邊大概率要重算。

我看過不少團隊很愛把穩定幣包裝成點數、獎勵、餘額，覺得換個 UI 名稱就沒事。沒有。監管看的是實質，不是你前端文案寫得多溫柔。只要它在功能上像受監管的支付工具，監管就會用那個角度看你。

文章也提到一個很容易踩雷的點：某些 CASP 服務如果有推廣或廣告 stablecoin，可能就會被視為對 ART 或 EMT 的公開發行或分銷。這就是我一直說的，listing 不一定只是 listing，distribution 也可能被你自己做成 offer。

實操寫法是把所有穩定幣依賴都當成審查對象，不要只看技術串接。

• 列出所有用在支付、金庫、獎勵、抵押、結算的穩定幣。
• 標記它是 ART、EMT，還是其他類型。
• 確認產品是否依賴利息、收益或激勵機制。

代幣上線前，先分類再行銷

MiCA 對公開發行和上架交易的揭露要求，會讓很多代幣團隊卡住。白皮書要交代發行人或提案人、代幣本身、權利義務、技術、風險，必要時還要寫環境或氣候相關影響。這不是可有可無的說明文件，這本身就是 offer 的一部分。

Utility token 和 governance token 不是自動免死金牌。這點很重要，因為很多團隊超愛以為只要貼上「治理」兩個字，就等於法規安全。不是。你如果賣進歐盟，或想在歐盟交易平台上架，就得做真實的分類分析。更麻煩的是，如果持幣人期待的是核心團隊持續推動價格或價值，證券法可能又會跑出來插一腳。

我以前看過創辦人對「治理」這個詞有莫名執著，好像名字一改，風險就消失。其實沒有。只要你的代幣被包裝成投資標的，或經濟模型高度依賴中心團隊，MiCA 可能只是第一層，後面還有別的法規等著你。

實操寫法是把上幣和發幣流程做得很無聊，這是好事。無聊代表可重複、可稽核、比較不會分類錯。先做分類，再排宣傳，不要等 influencer 文案都寫好了才補法務。

• 白皮書定稿前先完成代幣分類 memo。
• 確認它是 ART、EMT、其他 MiCA crypto asset，還是 MiFID II 金融工具。
• 上架、空投、宣傳都要先過法律簽核。

如果你要看證券工具的歐盟基準，可以先對照 MiFID II。有些 token 一旦長得像金融工具，MiCA 可能就不是主法規了。

你需要一套合規堆疊，不是五套互不相干的工具

文章裡我最認同的一點，是 MiCA 不會取代 AML，也不會取代 EU Travel Rule。它是疊在旁邊一起工作的。也就是說，KYC、制裁名單、鏈上風險、Travel Rule、MiCA 資格判斷，這些東西必須互通，不然你的控管在 production 會互相打架。

很多團隊一開始最愛做成合規動物園：一套 KYC、另一套制裁、再一套鏈上分析、再一套 Travel Rule、再一套 token 權限，然後全部都不太會講話。結果使用者被擋一次、又被放行一次，客服只會說「系統判定」，誰都不知道到底發生什麼事。這種架構很常見，也很常出事。

文章也提醒了一個很務實的資料問題：如果你只存電話國碼或最後登入 IP，你根本不能證明 EU eligibility。這句話我完全同意。你需要的是能反映法律現實的資料模型，不是方便抓的欄位而已。

我之前遇過一個團隊想做超簡單的「EU yes/no」旗標，聽起來很省事，實際上超危險。人會搬家、法人和自然人不一樣、服務可能透過子公司或代理商提供。你如果說不清楚客戶是誰、服務是在哪個法域提供，控制就只是裝飾品。

實操寫法是把身份和政策做成共用層，不要每個系統各搞各的。

• 同一份 customer profile 同時存法域、實體類型、居住地、產品權限。
• AML、制裁、Travel Rule、MiCA eligibility 都接同一份 profile。
• 每一次阻擋、例外、覆寫都要有 reason code。

Travel Rule 的相關工作可以先看 FATF。MiCA 不會幫你把這一層消掉，假裝沒看到只會讓你之後重做得更痛。

不要把 DeFi 空白地帶誤會成免責區

MiCA 對一些領域還留了空間，像很多 DeFi 活動、加密借貸、很多 NFT，都還不是完整覆蓋。文章在這裡寫得算克制，這點我反而欣賞。因為太多人一聽到「還沒完全管到」，腦袋就自動翻譯成「那就安全了」。不是這樣。

就算 MiCA 沒直接管到，其他規則還是可能會進來。DeFi 前端、託管錢包、代幣發行人、治理基金會、服務供應商，還是可能碰到 AML、消費者保護、制裁、稅務申報、證券法。你如果有控制前端、有 admin key、有收費、有資產篩選，監管通常還是找得到責任主體。

我最常看到的誤判，就是團隊把「去中心化」當成法律護身符。其實不是。你如果前端是公司架的、管理金鑰是公司握的、費用也是公司收的，那監管要找你，通常不難。

實操寫法是把控制權畫清楚，不要靠品牌字眼。把 admin rights、升級路徑、收費、資產篩選、客服責任全部列出來。只要一個正常人看得出你團隊在操作這個系統，就先假設你有法遵義務要分析。

我現在會直接提醒團隊，不要拿「decentralized」當成「我們還沒查」的替代詞。這兩句完全不是同一件事，監管也不吃這套。

可抄的模板

# MiCA 產品範圍備忘錄

## 1) 產品摘要
- 產品名稱：
- 法人實體：
- 主要使用者國家：
- EU-facing 功能：
- 上線日期：

## 2) 使用者與法域模型
- 客戶類型：零售 / 專業 / 機構 / 商業
- 是否蒐集法定居住地：是 / 否
- 是否蒐集簽約實體：是 / 否
- 是否蒐集 IP 訊號：是 / 否
- 是否蒐集 KYC 國別：是 / 否
- 是否依地區套用條款：是 / 否
- EU 存取是封鎖、開放，還是條件式：

## 3) MiCA 分類
針對每個資產或服務記錄：
- 名稱：
- 類別：ART / EMT / 其他 MiCA 加密資產 / MiFID II 金融工具 / 不在範圍內
- 為什麼這樣分類：
- 是否涉及 EU 公開發行或分銷：是 / 否
- 是否涉及交易上架：是 / 否
- 是否需要白皮書：是 / 否
- 是否有穩定幣發行義務：是 / 否
- 是否涉及 CASP 服務：是 / 否

## 4) CASP 服務檢查表
逐項標記是 / 否：
- 託管與管理加密資產
- 營運交易平台
- 加密資產兌法幣
- 加密資產兌加密資產
- 執行訂單
- 代幣配售
- 接收與傳遞訂單
- 投資組合管理
- 加密資產建議

## 5) 控制堆疊
- KYC 供應商：
- 制裁名單供應商：
- Travel Rule 供應商：
- 鏈上風險評分供應商：
- 交易監控規則：
- 客戶資產隔離方式：
- 申訴流程負責人：
- 利益衝突負責人：
- 事件通報負責人：

## 6) 穩定幣依賴
每個穩定幣都記：
- 代幣名稱：
- ART / EMT / 其他：
- 用途：支付 / 金庫 / 獎勵 / 抵押 / 結算 / 其他
- 是否提供利息或收益：是 / 否
- EU 使用者能否透過受監管管道取得：是 / 否
- EU 使用者能否贖回：是 / 否
- 是否需要限制：是 / 否

## 7) 上線與上架關卡
- 代幣分類 memo 核准者：
- 白皮書核准者：
- 行銷文案審核者：
- 交易所上架審核者：
- EU 存取決策核准者：
- 所有必要核准完成前不得 go-live：是 / 否

## 8) 證據包
附上連結或檔案：
- 治理架構圖
- 政策文件
- 存取紀錄
- 申訴處理程序
- 客戶資產保護設計
- 風險評估
- 教育訓練紀錄
- 法律意見

## 9) 決策
- 申請 CASP 授權
- 與已授權 CASP 合作
- 限制 EU 存取
- 上線前重新設計產品

## 10) 負責人與複查日
- 備忘錄負責人：
- 法務審查：
- 工程審查：
- 合規審查：
- 下次複查日：

這份模板就是我把文章裡的法規框架，翻成工程、產品、法務都看得懂的版本。它的價值不是漂亮，而是能直接拿去開會、排需求、做 release gate。

你可以在代幣上線前、加穩定幣支援前、開歐盟註冊前、甚至跟業務說「歐洲合作基本沒問題」之前先跑一次。越早回答這些問題，越不會在授權或稽核時被迫重做。

原始來源是 Blockchain Council；我上面拆的法規脈絡、產品觀點和模板化做法，有一部分是根據原文延伸，有一部分是我自己整理成可執行版本。若你要回頭查法規本體，請直接看 MiCA 原文。