寄付窓口はこちら

仮想通貨交換業等に関する研究会 第9回 ウォレット(カストディ)業規制についての言及まとめ

傍聴していなかった第9回について、議事録が公開されたので発言をまとめました

資料より抜粋

  • ウォレット業務は、顧客の支払・決済手段を管理し、当該支払・決済手段を顧客が指定する者に移転させる行為を行うものであり、以下の点を踏まえると、決済に関連するサービスとして、金融規制の導入が期待されるとも考えられるが、この点についてどのように考えるべきか。
    • ウォレット業務には、サイバー攻撃による顧客の仮想通貨の流出リスク、ウォレット業者の破綻リスク、マネロン・テロ資金供与のリスクなど、一部、仮想通貨交換業と共通のリスクがあると考えられること
    • 仮想通貨はインターネットを介し容易にクロスボーダーで移転が可能であり、国際的に協調して対応することが重要であるところ、FATF(金融活動作業部会)において、仮想通貨交換業に加え、ウォレット業務もマネロン・テロ資金供与規制の対象にすることを各国に求める旨の改訂FATF勧告が採択されたこと(本年10月19日)
  • ウォレット業務に対する規制の導入が期待される場合、そのリスクに鑑み、仮想通貨交換業のうち顧客の仮想通貨の管理に係る以下のような対応と、同様の対応を求めることが考えられるが、この点についてどう考えるべきか。
    • 登録制
    • 内部管理体制の整備
    • 業者の仮想通貨と顧客の仮想通貨の分別管理
    • 分別管理監査、財務諸表監査
    • 仮想通貨流出時の対応方針の公表、弁済原資の保持
    • 利用者保護又は業の適切な遂行に支障を及ぼすおそれがあると認められる仮想通貨を取り扱わないこと
    • 顧客の本人確認、疑わしい取引の当局への届出

討議内容

各メンバーよりウォレット規制に言及があった部分を抽出

岩下メンバー

  • 国内でモナコインを預かった業者がサイバー攻撃を受け事業を中断した
  • NEM-BTCの交換にカナダのウォレット業者が利用された(1週間で100億円の取引)
  • 技術的な難しさもあるのではないか
    • 仮想通貨交換業と同じ協会で管理するのか、ウォレット業者協会をつくるのか
  • 顧客に被害を及ぼすことを防ぐ意味はあるのではないか

福田メンバー

  • 特定の業者ではなく幅広い業者を規制する考え方は大事、ウォレット業者もその一つ
  • 仮想通貨は個々の規制が難しいため可能な部分について規制することは大事
  • 望ましい規制とできる規制という考え方はかなり違うものである
  • 去年から今年にかけてのバブルの側面があった中での問題に対する対処的な観点だけではなく、規制体系に対する中長期的な観点も大事

井上メンバー

  • AML/CFT、リスク説明や勧誘のルール、管理保全のルールが中心ではないか
  • AML/CFTのルールはすぐにでも適用する必要がある
  • 保全管理ルールは、今後この業態が日本でも広がるなら、交換業同様のルールが必要
  • カストディアンに対して顧客が期待するレベルの管理を当然求めるべきであり、そのレベルを都度アップデートする必要がある
  • 破綻リスクからの保全ルールも必要
  • 日本においてカストディ業務を中核にする業者がいないのであれば、それほどゆるい経過処置は必要ないのではないか

永沢メンバー

  • 仮想通貨の周辺の業についてなにか非常事態が生じたときに、金融当局が把握できる状況を用意していただきたい

楠メンバー

  • いろいろな種類のウォレットがあるため、リスクに高いものをきちんと規制の枠組みに入れていくということは非常に重要
  • 法定通貨で言うところの銀行のような機能にはふさわしい安全管理処置を考えていく必要がある
    • 一方で、オープンソースでいろいろな人が勝手に立てているようなものもあるが、リスクレベルも異なり、期待されるセキュリティも違うであろう
    • しかしZaifからの漏洩モナコインはそうしたサーバーを介して送金されており、野放図に立てて構わないかというと悩ましい
      • ルノードに対するトランザクションよりウォレットサーバーに対するアクセスのほうがログが残っている可能性が高い
        • それほどリスクが高くないウォレットに関しても、AMLの観点からどのような規律を入れるべきか考える必要がある
  • 国外で運営されるウォレットサーバーに対して規制をかけられるのか
    • 日本における立法処置だけではなく、FATFを始めとした場でグローバルに考える必要がある

翁メンバー

  • FATFでウォレット業務について対応を各国に求めており、規制を考えていく必要がある

The Realm Mobile Platform Experience #RealmWorldTour17

去年の記事、下書きのままだったので今更ですが公開します。モバイルアプリケーション用データベースRealmのミートアップです。

realm.connpass.com

  • 沢山の企業に採用されています
    • みなさんが使っているiPhoneの中には少なくとも1つはRealmを使ったアプリが入っているはずです
  • RealmのDBエンジンはモバイルデバイスに最適化されるように1から開発されました
    • 大きな特徴であるオブジェクトの自動更新 "Live Object" という機能を持っていたり、モバイルアプリを作る上で便利な機能が整っています。
  • Live ObjectやReactive、オープンソースであるということは大きな特徴ですが、これからその特徴の中でもDBの部分の特徴であるLiveObjectを使って、Reactiveなモバイルアプリをどのように作っていくかを少し詳しくご説明します。
  • LiveObjectを使うとデータが勝手に更新されるので、データを取り直す必要がなくなります。
    • 上手く使うことによってモバイルアプリケーションをスマートに開発できるようになります
  • Realmの重要な代表的なAPIはTransactions, Objects, Queries, Notificationsです
    • 最初はObjectsのAPIです
      • Realmを使うにはRealmに保存するためのオブジェクトが必要になります。
      • 通常通りクラスを定義するだけです。SwiftならRealmの"Object"を継承する、Javaなら"RealmObject"インターフェースを継承する必要がありますがそれだけです。
      • 中間のモデルファイルやDBの定義は必要ありません。ミドルウェアが不要で直接オブジェクトを使えるということが重要な特徴になります。
      • このRealmのモデルには自由にプロパティを定義できて、Realmに保存されます
      • メソッドを定義することも出来ます
      • SQLのようなJoinという概念はないですが、Relationshipsを定義することは出来ます。
        • 関連を直接定義することができ、関連が保存されるので、Joinのようなハイコストな処理ではなく、パフォーマンスを気にせず関連するオブジェクトを取得することが出来ます。
    • 作成したオブジェクトを保存して、それを利用するにはQueryを利用します
      • Queryを使うとResultというオブジェクトを取得でき、そのなかから取り出すことが出来ます。
      • 関連するオブジェクトをプロパティから取得できます。
      • 1対多ならListとして取得できます。
      • 逆方向の関連もプロパティとして取得できます。
      • Realmはできるだけメモリを使わないようにします。Queryを実行してもオブジェクトや、関連オブジェクトにアクセスするまでは実際に取得しません。
      • Queryを書くのは非常に簡単です。
      • Queryの結果は、変更があった場合自動的に更新されます。2歳以下の犬を取得して得た結果があるとします。2歳以下の犬がその後追加されたら、再度検索を行う必要はありません。自動で変更が反映され、変更があったことを通知で取得できますのでそのまま画面を更新すれば良いです。そうした簡単な方法でアプリケーションを作ることが出来ます。
      • パフォーマンスのためにRealmのデータをキャッシュするようなことは必要ありません。Realmに任せるだけで全て最適化されて実行されます。
    • 別のスレッドから変更される可能性がありますがどうすればよいでしょうか。Queryの結果は自動で更新されるので、通知を受けて画面を更新すれば良いです。
      • 通知にブロックを登録して、そのブロックの中で画面を更新したりします。
      • 何が追加され、何が削除され、、と言った情報がわたってくるので、画面を更新する際にアニメーションさせることも可能です。
      • アプリケーションで犬の画像を共有するInstagramのようなものを作るとします。
    • ユーザーが追加したり削除したりしてデータが変更される場合があります。データの変更はTransactionsというAPIを使って行います。
      • データの更新はオブジェクトのプロパティを更新するだけです。
      • Realmは内部的にはメモリマップして動いているのでプロパティの変更は即座にディスクに反映されます。Transactionを使うことで変更をロールバックしたりまとめて反映させることが可能になっています。
      • Transactionをつかうことで変更に一貫性を持って、たとえば別スレッドで未コミットの状態のものが見えたりしないようになっています。Transaction中の中途半端な変更はほかからは見えないようになっています。
  • ここまでが基本的な機能のご紹介になります
    • 基本的には高速で使いやすいデータベースになっています。
    • Java, Swift, Objective-C, ReactNative, Xamarin 5つのプラットフォームに対応しています
  • ここからは、データベースの他に開発者の方が課題だと考えていることについてのソリューションをご紹介します。データの同期に関するソリューションです。
    • Realm Mobile Platform
    • データを同期しようとすると複雑で神経をすり減らすのではないでしょうか
    • 表面に出ている部分は簡単でAPIを叩いてデータを取得して保存するだけ。でも実際には隠れている部分がすごく大変で、リクエストが失敗したらどうするのか、度のタイミングでエラーが起きるかだけでもたくさんあるし、どうやり直すかの場合分けも考えているととても複雑になります。
    • 同期がうまく行ったとしても実はそのときには別のユーザーがサーバーのデータを更新しているかもしれません。そうした場合もデータを正しく反映することはとても難しいです。
    • Realmを使った場合は全てのデータは自動的に同期されるようになります。デバイスがネットワークにつながっている間は。
    • クライアントとサーバーで同じオブジェクトが使えて同じデータが存在して、同期された状態になります。
    • Realmはクライアントとサーバーで双方向に通信しています。リアルタイムに最新の状態が同期されるようになっています。もし同じものを各デバイスで変更して衝突した場合も、予め決められたルールで解決されてデータが反映されます。
    • 同期の通信は最小限に抑えられているのでCPU消費もネットワークの消費も非常に低く抑えられています。
    • 今までと同じようにデータの変更をローカルのデータベースに書き込めばいいだけになります。
    • 面倒な部分はRealmによって自動で行われます。
    • 唯一単体でRealm Mobile Databaseを使っていて違うことは、バックグラウンドのスレッドでの変更をUIに変更しなければならないのと同じ感覚で、他のデバイスで置きた変更が他のデバイスに通知されるので、他のデバイスで置きた変更もUIに反映する機能を備えていなければなりません。
    • JSONから変換する処理も不要になりますし、APIにアクセスする必要もなくなります。データの転送を全てRealmに任せることが出来ます。
    • 差分だけをやり取りするので通信量は少なく済みます。
    • よくあるネットワーク通信を使ったモバイルアプリケーションはJSONシリアライズなどとてもたくさんのことをクライアント側で行う必要があって、スパゲッティのようになってしまいがちで、メンテナンスが難しくなることが容易に起こります。
    • RealmMobilePlatformを使うと、同期が自動でRealmで行われます。
    • もし必要なら既存のAPIとRealm Mobile Platformを通信させながら、クライアントはRealmを使ってシンプルにということが出来るようになっています。
    • サーバー側もクライアントサイドと同様に簡単にRealmを使うことが出来ます。
    • サーバーサイドのRealmはNode.jsを使います。ReactNativeを使っていたらそれと使い方は全く同じです。
  • 基本的な同期の機能の他にほかにも多くの機能を提供しています。ユーザー認証、水平スケーリングなど。幾つかの機能はこのあとデモします。
  • Realm mobile platformのDemoはrealmのサイトからダウンロードできます。
    • Realm Mobile Platform Realm mobile platformは複数のエディションが有ります
    • 無料
      • 同期機能を使う
    • 有料: 2ヶ月トライアル
      • サーバーサイドで処理が書ける
  • We're hiring
    • 沢山ポジションが有るわけではない(とくにここに多いと思われるiOSエンジニアのポジションはない)が、リモートで働いている人もたくさんいます。
    • リモートワークに興味が有る方も話を聞きに来ていただければと思います
    • Realm Jobs | Work at Realm

ご清聴ありがとうございました。何かご質問の有る方はいらっしゃいますか?

Q: メモリのコピーが起きないとおっしゃっていたが、ファイルから読み込むときはメモリ領域を確保しなくてはいけないと思うが、二回目Queryを実行する時にキャッシュされているからコピーが発生しないのでしょうか?

A: 仕組みとして、Realmのファイルとメモリはマップされていて、RealmオブジェクトはRealmのディスクからデータを実体化したものではなく、メモリマップされたポインタを持っているものになります。オブジェクトへのアクセスはRealmからコピーされたデータへのアクセスではなくて、メモリマップされたRealmのデータに直接アクセスしているような形になります。 Realmインスタンスを作ったときはメモリを利用するが、Realmに保存されたら、メモリは使わないことになります。 メモリマップされたものはキャッシュメモリとは別の管理になります。

Q: サーバーサイドはnode.jsしか使えないということだが、Swiftも使えないでしょうか

A: 現在は出来ないです。 RealmSwiftはObjective-Cに依存しています。Objective-Cは現在Linux環境では利用できません。 またRealmのCoreはC++です。SwiftからC++をダイレクトに扱う方法は提供されていないのでObjective-Cを挟んで利用している。 今のところServerSideのRealmはその2つの理由でSwiftを利用できません。 RealmはPureSwiftで書くというプランになっているので遠くない将来実現できると思います。そうしたいと思っています。

Q: お絵かきのアプリがありましたがどのような形でデータを保存しているのでしょうか

A: とてもいい質問ですね。 結論から言うと、色と、どこからスタートして通った座標と終わった座標をDBのSchemeとして持っています。そのようにデータを持っている理由は二つのデバイスを同期してもあとから来たデータを追加するだけで良いようにするためです。 ストロークと、いつ、という情報だけ持っていれば、基本的にはあとから来たものを追加していくだけになるので、そのようなデータの持ち方をしています。

Q: Swiftは基本的に値型がメインだと思うが、RealmObjectは参照型である。その点は相性が悪いということはないでしょうか

A: SwiftはValueTypeを推奨しているのはおっしゃるとおりです Realmはデータベースを使う以上は更新される度に引きなおすこともありですが、Live Objectというコンセプトがあるのでそのような方法を取っています。 将来的なプラントしてはバリュータイプを扱えるようにするという検討もしています。

Q: サーバーサイドのDBと同期できるということで、PostgresSQLを利用できるということだが、ほかのRDBは利用できるようになりますか?

A: はい。ほかのDB対応予定もあります。MySQLなどもプランに有ります。

Q: サーバーサイドのDBの状態とクライアントのDBの状態と、クライアントに同期する必要が無いものがある可能性がありますが、同期するテーブルとしないテーブルを選択することは可能でしょうか

A: このテーブルはテーブルごとにファイルを分けることになります。

Q: 同期を手動で実行することは可能でしょうか。バックグラウンドフェッチで任意のタイミングで同期処理を開始させ、完了したらcompletionHandlerを実行したい。

A: 変化があった時に自動で同期が開始する 今のところは手動で同期を発火させることは出来ません。 同期のスタートは自動で任せなくてはいけない。 バックグラウンドフェッチは時間が限られているので完了するかが難しい場合もあります。 手作業で開始するAPIの提供予定はあります。同期の完了を取れるかは、それは現在も可能で、Sync Progress Notificationで実行中なのか送信中なのか受信中なのか、何%なのか、完了したのかが分かるようになっています。

Q: オフラインで同期できないままアプリをバックグラウンドに送った時、次の同期されるタイミングはいつになるのでしょう

A: 次にアプリケーションを起動してObjectServerに繋いだあと、すぐにサーバーの未受信のデータ、ローカルの未アップロードのデータが同期されます。

仮想通貨カストディ(ウォレット)業の規制動向まとめと僕の考えるカストディ規制の留意点

金融庁の「仮想通貨交換業等に関する研究会」の報告書が先日公表され、仮想通貨カストディ(ウォレット)を業として規制する方針が盛り込まれました。

そこで、カストディの規制が求められた背景から、「仮想通貨交換業等に関する研究会」で検討が行われ、その報告書に記載された内容まで、経緯をまとめました。

仮想通貨カストディ業に規制が求められている背景

主な登場人物は、日本の金融庁、先進国に新興国を加えた主要20か国の首脳会合であるG20、そして政府間機関のFATF(マネーロンダリングに関する金融活動作業部会)になります。

2018/03 G20がFATFに対して暗号資産の基準見直しと世界的な実施の推進を要請

2018年3月のG20財務大臣中央銀行総裁会議にて、日本は以下を主張しました。

  • 政府間機関であるFATF(マネーロンダリングに関する金融活動作業部会)のガイダンスの内容を、拘束力のあるFATF基準へ格上げすることを期待する
  • 仮想通貨交換業についての法制度が未整備の国は、速やかに法整備を進めることが必要である
  • G20として力強いメッセージを発信すべき

G20では世界的な対策実施の推進をFATFに対し要請する合意に至り、次のような財務大臣中央銀行総裁会議宣言(2018年3月19・20日)が出されました。

我々は、暗号資産に適用される形での金融活動作業部会(FATF)基準の実施にコミットし、FATFによるこれらの基準の見直しに期待し、FATFに対し世界的な実施の推進を要請する。 我々は、国際基準設定主体がそれぞれのマンデートに従って、暗号資産及びそのリスクの監視を続け、多国間での必要な対応について評価することを要請する。

(「仮想通貨交換業等に関する研究会」第9回資料3より)

2018/10 FATFが交換所をはじめとする、 "仮想資産サービス業者" (ウォレット提供者が含まれる)に対する規制の必要性を明確にする

これを受けて、FATFは2018年10月にFATF勧告を改正しました。

改正された箇所は以下の通りです。

勧告 15: 新技術の悪用防止

仮想資産により生じるリスクを管理及び軽減するため、各国は、仮想資産サービス業者が、マネロン・テロ資金供与対策の目的で規制され、免許又は登録制が課されるとともに、FATF勧告において求められる関連措置の遵守を確保し、モニタリングするための効果的なシステムを適用するための措置を講ずるべきである。


用語定義 「仮想資産サービス業者」

「仮想資産サービス業者」とは、勧告の他の場所でカバーされていない自然人又は法人であって、他の自然人又は法人のために、業として以下のいずれかの行為を行う者をいう。

  1. 仮想資産と法定通貨との交換

  2. 他の仮想資産との交換

  3. 仮想資産の移転※

  4. 仮想資産又は仮想資産のコントロールを可能にするインストラメントの保護預かり及び/又は管理

  5. 仮想資産の発行オファー及び/又は販売に関する金融サービスへの参加及び提供

※仮想資産の文脈において「移転」とは、仮想資産を別の仮想資産アドレス又はアカウントに移動させる自然人又は法人のために取引を行うことをいう。

(「仮想通貨交換業等に関する研究会」第9回資料3より)

これによって、従来の交換業規制に加え、ウォレット業やICOへの規制が国際的に要求されるものとなりました。

この改正についてFATFは、 Recommendations Regulation of virtual assets の中で

These changes add to the Glossary new definitions of “virtual assets” and “virtual asset service providers” – such as exchanges, certain types of wallet providers, and providers of financial services for Initial Coin Offerings (ICOs).

これらの変更では、"暗号資産"、そして例えば取引所や特定の種類のウォレット提供者、そしてInitial Coin Offerings(ICO)の金融サービス提供者である"仮想資産サービス提供者"の新しい定義を用語集に加えました。

と言及しています(【対訳】FATF勧告 - 仮想資産の規制 (FATF Recommendations Regulation of virtual assets) 2018/10/19 - niwatakoのはてなブログより)

2018/12 G20が暗号資産への規制を宣言する

FATF勧告の改正を受けて、2018年11月30日〜12月01日に開催されたG20で以下のような首脳宣言がなされました。

我々は,金融活動作業部会(FATF)基準に沿ったマネーロンダリング及びテロ資金供与への対策のため,暗号資産を規制し,必要に応じて他の対応を検討する。

G20ブエノスアイレス・サミット | 外務省におけるブエノスアイレス首脳宣言(仮訳)より。

日本は2019年10月までにウォレット・ICO規制の整備が必要?

日本では現段階で交換所についての規制しか無いので、ウォレットとICOについては新たに規制の制定が必要です。

来年2019年10〜11月には、日本がFATFのオンサイト審査を受ける予定となっています。これに間に合わせるには、規制の制定は急がれる状況であると考えられます。

f:id:niwatako:20181203113329p:plain

Assessment Calendar - Financial Action Task Force (FATF) より。

我が国は2008年に公表されたFATF第3次対日審査において49項目中25項目で要改善(不備10項目、一部履行15項目)という厳しい評価を受け、その後、2014年6月には、指摘事項に対する対応の遅れから、FATFより迅速な立法措置等を促す異例の声明を受けた経緯があり、金融庁を含む関係当局は強い危機意識の下、2019年のFATF第4次対日審査に向けて連携し、万全を期している。

FATF第4次対日相互審査に向けた金融庁のAML/CFTガイドラインに基づく態勢整備・高度化|Financial Services Risk Management(FSRM)|EY Japan より。

法を制定する機会となる通常国会は、1月中に招集され150日間に渡って開催されるので、次回は2019年1月〜6月に行われると思われます。

日本における規制の検討状況

交換業、ICO関連、カストディ業のいずれの法規制の改定・制定についても、金融庁仮想通貨交換業等に関する研究会で検討が進められています。

研究会第9回 - ウォレットの整理が行われる

2018年11月12日に開催された仮想通貨交換業等に関する研究会の第9回ではウォレットの種類について取り上げられていて、ウォレットを以下のように分類したものを参考資料としています。出展は民間情報サイトとのことです。

種類 秘密鍵の管理場所 手順 特徴・リスク
①オンラインウォレット ウォレット業者
(交換業者に移行する者も多い)
交換業者
  • 業者でアカウント開設、アドレス作成(秘密鍵は業者が管理)
  • 仮想通貨を移転したいときは業者に指図
  • 業者がハッキングを受けるリスク
  • 業者の破綻リスク
②ソフトウェアウォレット 個人のPCやスマホ
  • PCやスマホにアプリをダウンロード、アドレス作成
  • 仮想通貨を移転したいときは秘密鍵を用いて移転
  • オープンソースや特定の業者が提供するアプリが多数存在
  • 端末のハッキングリスク
③ハードウェアウォレット 個人が購入した
専用のUSBデバイス
  • アドレスを生成できるデバイスを購入
  • 仮想通貨を移転したいときはデバイスをPCに接続し、秘密鍵を用いて移転
  • 複数の業者が販売
  • ①②よりセキュリティに優れていると考えられるが、ウィルス感染した端末に接続した場合には、ハッキングのリスクもあり
  • 紛失リスク
④ペーパーウォレット
  • 専用サイトにアクセスして、アドレス作成
  • アドレス・秘密鍵が印字された紙を印刷
  • 仮想通貨を移転したいときは、上記のウォレットで秘密鍵をインポートし、上記ウォレットに移行
  • 紛失リスク
  • カメラで撮影されるリスク

(仮想通貨交換業等に関する研究会第9回資料3 3ページより)

ここで、オンラインウォレットに ウォレット業者 と書かれていることから、業者がアカウントやアドレスを用意して資金や鍵を預かるタイプをウォレット業者として規制することを想定していることが伺えます。

規制の内容については、交換業のウォレット業務に関わる部分を適用することについて検討がなされています。

仮想通貨交換業のうち顧客の仮想通貨の管理に係る以下のような対応と、同様の対応を求めることが考えられるが、この点についてどう考えるべきか。

  • 登録制
  • 内部管理体制の整備
  • 業者の仮想通貨と顧客の仮想通貨の分別管理
  • 分別管理監査、財務諸表監査
  • 仮想通貨流出時の対応方針の公表、弁済原資の保持
  • 利用者保護や業務の適正かつ確実な遂行に支障を及ぼすおそれがあると認められる仮想通貨を取り扱わないこと
  • 顧客の本人確認、疑わしい取引の行政当局への届出

第9回は私は出席していないのでどのような発言があったか把握できていません。そのうち、金融庁から議事録が公開されるはずです。

2019/01/07追記

第9回の議事録が公開されています。ウォレット(カストディ)業規制についての言及をまとめました

研究会第11回 - カストディに表現を変更して報告書(案)に記載

仮想通貨交換業等に関する研究会は2018年12月14日の第11回が最後となりました。

研究会の報告書案として作成された文章では、「報告書が想定している範囲より世の中でウォレットと呼ばれるものの範囲が広いため」、これまでウォレット業務と呼ばれていたものがカストディ業務に改められました。

また「顧客の仮想通貨の返還請求権を優先弁済の対象とすること」が明確化を意図して規制内容に加えられました(倒産したら顧客への仮想通貨の返還が他の債務の返済などよりも優先されるという意味です)。

最新の規制が検討されている項目は下記の通りとなります。

  • 登録制
  • 内部管理体制の整備
  • 業者の仮想通貨と顧客の仮想通貨の分別管理
  • 分別管理監査、財務諸表監査
  • 仮想通貨流出時の対応方針の公表、弁済原資の保持
  • 顧客の仮想通貨の返還請求権を優先弁済の対象とすること (NEW)
  • 利用者保護や業務の適正かつ確実な遂行に支障を及ぼすおそれがあると認められる仮想通貨を取り扱わないこと
  • 顧客の本人確認、疑わしい取引の行政当局への届出

第11回 報告書(案) より

また、第11回の研究会における発言で、カストディに関わる可能性がある発言には以下のようなものがありました。

  • (交換業の)安全対策基準の策定、遵守状況のチェックについてもう少し踏み込むべきではないか(中島メンバー)
  • (交換業の)1000万最低資本金は少ないのではないか、多くの業登録待ちが出るのは参入障壁が低いのではないか(中島メンバー、永沢メンバー)
    • ホットウォレットにあるものは別途財務の確保を求めるというもので、オペレーションリスクや事業の規模に応じて資本、資金的な規制がかかってくるという形になっておりまして、そうするとベンチャー的なものも存在しうるし、大きな業務を行うところには大きな規制がかかるという形で対応されている(金融庁
  • 仮想通貨デリバティブ取引、カストディ等の業規制導入にあたり、みなし期間に限度を設けるべきではないか(中島メンバー)
    • 実際何社出てくるか推測ができないので、一定の期間を予め設けることは難しいと思っている(金融庁)
  • イノベーションに配慮しつつ利用者保護の観点からリスクの高低等に応じて規制の柔構造化を図る、必要なさらなる検討会を行っていくことは非常に重要(森下メンバー)
  • 仮想通貨の私法上の位置づけの検討が進んだ段階で改めて検討が必要なことも出てくるだろう(三宅メンバー)
  • ハードフォークした通貨の取り扱いが事前申告では、顧客資産が保護されにくいのではないか(楠メンバー)
  • カストディでないウォレットに関しても、通信事業者のように警察への協力やログの保存と必要な場合の提出など、何らかの規制をかけていくということは考えられる(楠メンバー)
  • 匿名通貨を一概に規制するのではなく、適切に取り扱おうとしているかという行為規制の方向も考えられる(楠メンバー)
    • ビットコインでもミキシングで匿名送金できる
    • ※匿名機能を備えるが非匿名で送金できる通貨もある
  • さまざまなトークンが登場することを考えると金融にとどまらない議論が必要(楠メンバー)

その他、11回の議事録はこちらで、荒い速記ですが記事にしています。そのうち、金融庁からも公式な議事録が公開されるはずです。

仮想通貨交換業等に関する研究会 報告書

2018年12月21日に、これまでの仮想通貨交換業等に関する研究会の結果を取りまとめた報告書が公開されました。

第11回で検討された報告書(案)から、カストディ規制の箇所について大きな変更はなく、仮想通貨流出時の対応方針の 策定 の単語が挿入されました。

- 仮想通貨流出時の対応方針の公表、弁済原資の保持
+ 仮想通貨流出時の対応方針の策定・公表、弁済原資の保持 

また、上に記載した第11回で出された意見のうち、報告書に直接反映されたものは、

  • 交換業者の最低資本金について
    • 「最低資本金が少ないのではないか」「一律基準を強化すべきではない」という双方の意見が追記された
  • イノベーションに配慮しつつ利用者保護の観点からリスクの高低等に応じて規制の柔構造化を図る
    • 「ルールが明確化される中で、歪みのない形で、イノベーションの可能性が追求されることが期待される」

です。

その他、注と本文の間で移動された内容等があります。詳しくは下記エントリを参照ください。

niwatako.hatenablog.jp

僕の考える規制にあたっての懸念

国際的な背景と、これまでの議論の中で、カストディは業規制の対象となることがほぼ確実です。

しかしながら、交換業と同じ感覚で規制することは、事実上国内のカストディ業者を排除し、ブロックチェーンを活用したビジネスが日本で誕生する土壌を破壊することになりかねないと危惧しています。

イノベーションに十分配慮した規制となることを強く望んでいます。

カストディ業務の実態に照らして

これまで、国内ウォレット業者(カストディ及びソフトウェアウォレット含む)を対象に、Webまたは直接お会いしてのヒアリングを行ってきました。

カストディ業務はマネタイズできるビジネスとは言い難いです。OSSエコシステムの中で行われるボランティア的な取り組みとしての側面が強いのではないでしょうか。仮に手数料をとっても、クレジットカードのように日常的に決済に利用されるものではないため、利益にはなりません。

現実の用途の一つにTwitter上でのTipbotなどのマイクロペイメントがありますが、マイクロペイメントを目的としたカストディの預かり総額は数十万円や数百万円といった規模です。こうしたサービスはほぼ個人のボランティアで運営されています。手数料収入(とっていない、あるいは月間数十円程度)から複数名の運営体制整備や取引モニタリング、監査を受けるといったコストを負担することは困難と考えます。預かり総額だけで1名分の1ヶ月の人権費に消えてしまいます。

(数十円や1円以下の支払いができるマイクロペイメントは仮想通貨がもたらす一つのイノベーションだと思います。ほんの少しの気持ちを価値に乗せて表現したり、本を1ページ読む毎に課金、1分充電するごとに課金といったことが実現します)

国内のカストディ事業者で大規模なところは把握できておりませんが、「鍵や資金を預からない」タイプのソフトウェアウォレット業者には、国内に数十億円規模まで存在します。しかしながら、規模が大きくなってもウォレット事業は収益源とはなっていないのが現状です。

数千万規模のウォレット業者によると、収益はアプリ内に設置した広告から年間で数十万程度であり、数名が報酬なしで開発しているとのことでした。また、プロジェクトがトークンを上場させるために適度にトークンの所有者や利用者を増やす目的で行われるエアードロップ(トークンの無償配布)をウォレットが代行するビジネスモデルが存在しますが、この代行についてプロジェクトからオファーされる金額は100万程度であり、また必ずしも魅力的な内容ではない(支持できないプロジェクトであったり、告知が条件となっているなどユーザーに利益とならない条件がついている)場合が多いとのことで、安定した十分な収益源になることは現状では考えにくいです。

あらゆる規模のカストディが交換業と同様の基準で、検討されている規制のすべての項目の対象となれば、撤退するカストディがでる可能性が高い一方、現実にはユーザーに利用されています。仮に国内事業者が撤退し海外や身元のわからないサービスが代わりに利用されるようになれば、本来規制が目的としていたAML/CFTも消費者保護も果たせません。個人や小規模なカストディ事業者でも遵守できる、リスクに合わせて柔軟に対応できる規制が必要だと考えています(登録制と、ログの保管期間・ログに残す項目の指定、ユーザーへのリスクの説明が最低限の現実的規制ではないかと個人的には考えています)。

一方で、ウォレット事業者の中には規制に対してネガティブな受け止め方だけではなく、事業を多面展開して収益基盤を持つなどしており、よりユーザーに提供するサービスを充実させるため、「遵守することで提供できるビジネスの幅を広げることが認められるような規制がほしい」という声もあります。

例えば、交換業のうちのカストディ業務が独立した規制対象になるのであれば、交換業務(マッチング)についても独立した規制として切り出し、DEX(分散型取引所)と言われるような資金を預からないタイプの取引所を国内で営業可能にし、KYCを行ったカストディ業と提携するスキームが組めるような仕組みづくりも、検討の価値があるのではないでしょうか。

カストディの応用が積極的にできることの重要性

イノベーションの可能性が追求されるための道をしっかりと確保することも重要です。

ブロックチェーンを活用したサービスがカストディ機能の提供を伴う場合があります。ブロックチェーンには現状で課題が多く、その課題を避けるためです。

  • ブロックチェーンの技術的課題(スケーリング問題等)を回避するため
    • 同時に多数のユーザーが利用するとすぐに手数料が高騰し、処理に何時間もかかるようになる
  • ブロックチェーンを活用したビジネスモデルの模索段階で、サービスのロジックに柔軟性を確保するため
  • ユーザーが利用する敷居を下げるため
    • サービスを試してみるだけでも鍵を管理する手間が必要
  • 発行するトークンを容易に取り扱えるウォレットが一般に普及していないため

将来的にはすべてブロックチェーン上で手続きを行うとしつつも、こうした理由・目的で仮想通貨の口座をサービスに内包し、すべての手続きをブロックチェーンに記録するのではなく、Webサービスとしてプログラムを動かして、その結果を口座の残高として管理する形でサービスを提供するケースがあります。

Webインターフェースを通してサービスを提供し、サービス内にカストディを内包することで、ユーザーはウォレットを用意しなくてもサービスを利用開始できます。逐一ブロックチェーンに書き込むのではなく、口座を操作することで、トランザクションの混雑や手数料を避けることができます。口座を操作するロジックを更新することで、繰り返しサービスを改善していくことができます。

しかし、このようなサービス内に専用のカストディを内包するケースについても厳しい規制に準拠する必要がある場合、ブロックチェーンを応用したイノベーションの模索が阻害されかねません。個人やスタートアップがアイディアを試せる余地を残し、過度に参入障壁が上がるべきではないと考えます。

まだブロックチェーンを活用した分散型アプリケーションの決定的なビジネスモデルは誕生していないため、さまざまなアイディアが試されることが、今後日本から競争力を持ったブロックチェーン活用サービスが登場するために必要だと考えます。

また、仮想通貨交換業が取り扱える仮想通貨の種類はホワイトリスト式に管理されていますが、カストディが扱う仮想通貨についても同様の基準のリストによって管理され、事前申告・承認が必要とされれば、トークンを活用する新しいサービスを作るとき、カストディ機能を内包してすぐにサービスを利用できる形で提供することが困難となり、イノベーションを阻害する要因となります。カストディが取り扱う仮想通貨には規制を適用しない、あるいは交換業やICOのために管理されるリストとは別に管理される必要があると考えます。

ご意見を募集しています

私はこれまでに国内の大小様々なカストディ・ウォレット事業者様にヒアリングを行ってきました。

今後トークンエコノミー、Dapps等のブロックチェーンを活用したアプリケーションがサービスにカストディ機能を組み込むようなケースも織り込んだ上で、実際の法律策定段階で参考とされることができるような論点を取りまとめることができればと考えております。

そこで、実態調査のためヒアリングにご協力いただける・規制についてのご意見を伺える事業者様を探しています。

ご協力いただけますと幸いです。ご連絡は下記まで。

twitter.com