FCAが協議している内容
英国Financial Conduct Authority（FCA）は10月21日、暗号資産の規制境界に追加される除外のガイダンス案CP26/36を公表しました。FCAはtemporary settlement arrangement、payment transactionのためのUK qualifying stablecoinの一時保有、stablecoinのbacking assetに関するarrangement、一部のproprietary trading、第三者serviceまたはdecentralised protocolへのaccessを単に提供するtechnical serviceを挙げています。ここまではFCAが公表した提案であり、以下はIneezaの本番運用分析です。
Consultationの期限は2026年11月18日で、FCAは2027年1月にfinal guidanceを公表する予定です。より広い制度は2027年10月25日に発効する予定です。またFCAは、technical-services exclusionの不確実性がarranging permissionの分析へ重大な影響を与えた場合、その他の点で完全なapplicationに限定的な追加期間を認めるとしています。
これはconsultation中のdraft guidanceであり、特定のarchitectureやproviderが規制外だと最終決定するものではありません。直近の運用上の重要性は、wallet、payment、exchange、custody、protocol accessのproductが複数functionを組み合わせる一方、除外は狭く定義された一つのfunctionだけに適用され得る点です。
Product labelではなく各functionを分類する
Wallet、gateway、API、protocol interfaceと呼ばれるserviceでも、user認証、route選択、transaction構築、asset保有、order送信、counterpartyの手配、settlement照合を行う場合があります。一つのproduct名は、これら異なるcontrol pointを覆い隠します。
Ineezaの分析: 実行可能なfunction単位でperimeter mapを維持すべきです。各経路についてlegal entity、user type、jurisdiction、asset classification、counterparty、custody state、decision owner、transaction authority、control durationを記録します。その分類は実装するcodeとproduct configurationとともにversion管理する必要があります。Passive accessに適用した除外を、別の評価が必要なrouting、execution、safeguardingへ暗黙に広げるべきではありません。
「Accessを単に提供する」状態をruntimeでも維持する
提案されたtechnical-services exclusionは、第三者serviceまたはdecentralised protocolへのaccessを単に提供するserviceを対象とします。したがって実務上の境界は、契約文言やinterface設計だけでなく、systemが実際に何を行うかで決まります。
Ineezaの分析: Access layerはuser指定のinstructionをrelayするだけなのか、venueの選択、条件の推奨・変更、transaction orderingの制御、signing authorityの保有、destinationの差し替えも行うのかを示す証跡を生成すべきです。Feature flag、smart routing、agentic execution、managed keyはlaunch後にfunctional profileを変え得ます。これらのcapabilityを変更するたびにrelease reviewでperimeter classificationを再実行する必要があります。
Temporary stablecoin holdingには明示的な状態と期限が必要
FCAはpayment transactionに使うUK qualifying stablecoinのtemporary holding arrangementを明示しています。「Temporary」と「for payment」はlifecycleの性質であり、wallet balanceだけでは証明できません。
Ineezaの分析: Payment systemは各holding eventをpayment instruction、予定recipient、amount、currency、許可されたrail、entry timestamp、deadline、terminal stateへ結び付けるべきです。Delivery失敗、refund、dispute、sanctions hold、chain congestion、partial execution後に残ったassetへの決定的なruleも必要です。Monitoringでは許可時間を超えたbalanceを検出し、reconciliationではwallet movementを、その理由を示すpayment recordとcustomer recordへ接続する必要があります。
一度限りのlegal memoではなく、変更に耐える証跡を作る
今回のconsultationは、企業がすでにapplicationを準備している時期に公表されました。FCAは、遅い段階での法令変更が一部technical-service providerに不確実性を生んだと認めています。Final guidanceはconsultation textから変わる可能性があります。
Ineezaの分析: Perimeter decisionを統制された運用artifactにすべきです。根拠としたrule・interpretationのversion、対象function、assumption、approval owner、effective date、本番動作が評価済み境界内にあることを示すtestを保存します。Custody、routing、signing、asset support、counterpartyの変更にはdeployment gateを設け、final guidanceで分類が変わる場合のrollback pathも維持する必要があります。
Ineezaの見解
CP26/36が重要なのは、規制scopeをsystem designの問題へ変える点です。信頼できる境界は「technology providerである」や「資金保有は短時間である」という説明ではありません。Function、authority、state transition、time limitを検証できる一つのchainです。このchainをarchitecture、release control、runtime evidenceへ組み込むことが、英国のfinal guidanceへの備えと、実際に構築したproductの安全な運用の両方につながります。