金融庁の中間とりまとめについて(2:リスク管理・コンプライアンス部門)

金融庁の中間とりまとめについて(2:リスク管理・コンプライアンス部門)

金融庁の中間とりまとめについて解説する2回目は、リスク管理・コンプライアンス部門(第2線)についてです。
金融庁の仮想通貨交換業者等の検査・モニタリング 中間とりまとめについて(総論)
金融庁の中間とりまとめについて(1:ビジネス部門)
も合わせご覧ください。

こちらも引用部には太字の箇所はありません。著者が編集しております。

2.リスク管理・コンプライアンス部門(第2線)

2−1.マネロン・テロ資金供与対策

①マネロン・テロ資金供与対策

(ア)人材等の問題

(多数の業者で認められた事例)

・口座開設、暗号資産の移転取引に係る各種規制の理解、暗号資産のリスク特性を踏まえたマネロン・テロ資金供与対策など、第1線にアドバイスを行うのに必要な専門性や能力を有する要員が確保されていない。

ブロックチェーンといった個別技術に詳しい、システムの構築に詳しい、というだけでは金融機関としては認められない、ということを打ち出しています。特に2回目の指摘となっているマネロン対策については、金融庁だけではなく、世界各国が協調して実施することが非常に重要なこともあって、このような助言を行える要員がいないことが問題視されています。もちろん、システム的に防ぐことも重要ではありますが、対策が重要であることを助言できなければ、システムに実装することもできません。

(イ)運用の問題

(複数の業者で認められた事例)

  • 取引時確認において、確認対象となる利用者の職業や取引目的について空欄である等、具体的な詳細を確認していない。また、確認記録において、法人の事業内容の確認を行った方法や実質的支配者と利用者との関係など、法令で求められる記録事項に関する記載がない。
  • 反社会的勢力との取引を排除するための事前審査が行われていない。また、取引開始後、利用者等が反社会的勢力と判明した場合の具体的な対応方針を定めていない。
  • 厳格な取引時確認や再度の取引時確認が必要となる具体的な手続及び基準等が定められておらず、なりすましの疑いがある取引等に関して必要な取引時確認が行われていない。
  • 疑わしい取引の該当性判断に際し、利用者の職業等の情報を考慮していない。また、高リスクと評価する取引について、統括管理者による承認が行われていない。

(個社で認められた事例)

  • 特定の利用者との間で複数回にわたり多額取引を行っているにもかかわらず、法令上求められる取引時確認を行っていないほか、疑わしい届出の判断も行っていない。
  • 内部管理規程にて閾値を設定の上、当該閾値を超える疑わしい取引を検知するシステムを開発しておらず、取引モニタリングが行われていない。
  • 利用者が反社会的勢力と判明したにもかかわらず、一定期間、暗号資産の外部アドレスへの移転を許容している。
  • 自社発行暗号資産を販売するに際して、購入者のメールアドレスを受領するに留まり、法令上求められる取引時確認を行っていないほか、疑わしい届出の判断も行っていない。

(個社で認められた事例)

  • 特定の利用者との間で複数回にわたり多額取引を行っているにもかかわらず、法令上求められる取引時確認を行っていないほか、疑わしい届出の判断も行っていない。
  • 内部管理規程にて閾値を設定の上、当該閾値を超える疑わしい取引を検知するシステムを開発しておらず、取引モニタリングが行われていない。
  • 利用者が反社会的勢力と判明したにもかかわらず、一定期間、暗号資産の外部アドレスへの移転を許容している。
  • 自社発行暗号資産を販売するに際して、購入者のメールアドレスを受領するに留まり、法令上求められる取引時確認を行っていないほか、疑わしい届出の判断も行っていない。

こちらも簡単にまとめると、金融機関として(少なくとも金融庁が求める)正しい状態ではない、ということを指摘しています。銀行や証券会社であれば、当然に実施されている内容が実施されていないということです。特に重要なのは反社会的勢力との取引を行わないことで、取引開始時(口座開設時)には、各金融機関とも、警察とも連携して、反社会的勢力に該当しないことを確認しています。これが現状実施できていないことを、金融庁だけではなく、警察庁も強く懸念しているというメッセージだと考えられます(この資料の序盤に、「警察庁とも連携している」と書いてあるのが、マネロンに関する対策ができていることの確認を重点項目としていることの現れです)。

通常、金融機関では「疑わしい取引」を届け出ることになっています。このため、疑わしい取引に該当するような取引が発生した場合は、端末やシステムにメッセージが出るようになっています。

金融庁:疑わしい取引の届出等:https://www.fsa.go.jp/str/

金融庁:疑わしい取引の参考事例:https://www.fsa.go.jp/str/jirei/index.html

いくつか例を挙げます。いずれも「疑わしい取引の参考事例」に記載のあるものです。

  • 架空名義口座又は借名口座であるとの疑いが生じた口座を使用した入出金。
  • 匿名又は架空名義と思われる名義での送金を受ける口座に係る取引。
  • 自行職員又はその関係者によって行われる取引であって、当該取引により利益を受ける者が不明な取引。
  • 自行職員が組織的な犯罪の処罰及び犯罪収益の規制等に関する法律第10条(犯罪収益等隠匿)又は第11条(犯罪収益等収受)の罪を犯している疑いがあると認められる取引。
  • 暴力団員、暴力団関係者等に係る取引。

この項目で指摘されているものだけではなく、今回の中間とりまとめの資料で指摘されている内容が、だいたい「疑わしい取引」として網羅されています。

また、金融機関によっては2段階認証のように、取引の重要度に応じた認証や本人確認が行われますが、こちらが暗号資産では実施されていないということと、なりすまし取引が実施されるリスクに対して考慮が不足しているということを指摘しています。IDとパスワードだけでは、利用者は保護されていないと判断していることの裏返しでしょう。

法制度の対応が遅れていた業界でもありますし、急成長した業界でもありますが、少なくとも、類似の法制度に準拠するためのシステム対応や、手続き上の対応は必要でしょう。

なお、金融庁から別の資料として、8月17日付けで「マネー・ローンダリング及びテロ資金供与対策の現状と課題」という資料が出ています。この資料は、いわゆるマネロン対策として、各業態の取組について説明しているものですが、この23ページに、仮想通貨交換業者に向けたメッセージが出ています。詳細な内容については、今回解説している「中間とりまとめ」とおおむね同様の指摘事項となっているため省略しますが、「金融機関の実効的な態勢整備」というキーワードを含めて、立て続けにメッセージを出しているところからしても、金融庁(だけではなく警察庁も含めて)はかなり強い危機感を持っていることは確実でしょう。

「マネー・ローンダリング及びテロ資金供与対策の現状と課題」の公表について:https://www.fsa.go.jp/news/30/20180817amlcft/20180817amlcft.html

②分別管理

(ア)暗号資産の管理の問題

(複数の業者で認められた事例)

  • 取扱い暗号資産について、ハッキングリスクの高いホットウォレットで管理している。
  • 利用者の暗号資産に係る帳簿とブロックチェーン上の有高との照合作業を毎営業日実施しておらず、照合作業が適切に行われているかについて事後的な検証を行っていない。
  • 利用者の暗号資産を分別管理するに際して、ブロックチェーン等のネットワーク上の有高を帳簿上の残高よりも上回らせる目的で、同一のウォレット内において、必要以上の多額の自己保有の暗号資産を混蔵して管理している。

コインチェック事件の再発防止として、ホットウォレットで管理していることを問題視しているものと思いますが、「どれくらいの量」だったのか、という点は記載されていません。もちろん、コインチェック事件の再発防止は重要ですが、すべてコールドウォレット(ハードウォレット)で管理するべきということになると、流動性の観点から問題になりかねません(現金を全額金庫にいれてしまうようなものです)。

銀行の場合、預金の1%程度を日銀の当座預金に預けることが義務となっていますが(預金準備率)、暗号資産の場合、ホットウォレットとコールド(ハード)ウォレットの配分比率については、おそらく盗難等のリスクを踏まえた経営判断になるものと考えられます。金融庁の資料で割合について触れられていないのは、想定以上に高い割合であったことが推定されますが、それがリスクを踏まえた経営の判断を受けていないことを問題視しているものと考えられます。

また、スーパーノードとなるように、あえて自己保有の資産を追加している事例があったようです。利用者の資産を管理するという目的であれば、あえてスーパーノードになる必要はなく、おそらく業者としてスーパーノードの収益を自分の手元に確保するための手段と考えられます。スーパーノードという表現はありませんが、「帳簿上の残高よりもネットワーク上の残高が上回る」ということは、スーパーノードになることを目的としていなければ、他に理由が見当たりません。

銀行で言えば、例えば「300万円以上だと金利が1%から3%になるので、顧客の50万円の定期預金に250万円を追加して、3%の定期預金にしてしまい、利子の差分を自分のものにする」ということと同義です。この方法では、事業者の資産と顧客の資産が一体になってしまうため、適切に保護されているとは言えない、というのが金融庁の判断と考えられます。

(もちろん、事業者の自己資金だけ、または顧客の資産だけでスーパーノードを作ることは、そのリスクを十分に判断した結果であれば、問題にならないだろうと推測しています)

(イ)金銭の管理の問題

(複数の業者で認められた事例)

  • 利用者財産の銀行口座の残高について、毎営業日、帳簿等と照合していない。また、照合作業が適切に行われているかについて事後的な検証を行っていない。

(個社で認められた事例)

  • 利用者財産を管理する銀行口座の残高が帳簿上の残高を下回る状況が、頻繁に発生しているにもかかわらず、その原因を究明していない。
  • 利用者財産を管理する銀行口座の資金を、一時的に他の目的のために流用している。

(ウ)帳簿作成の問題

(複数の業者で認められた事例)

  • 法令に基づき作成が求められる法定帳簿のうち、「総勘定元帳」を作成するに留まり、「取引日記帳」「自己勘定元帳」「顧客勘定元帳」等を作成していない。

法定帳簿については、作成しないという選択肢はありません。金融機関での業務経験者が不足しているのでしょう。

ここで大きく問題になるのは、利用者の財産を一時的とはいえ、他の目的に流用していたことです。これは顧客資産の保護のため、絶対に認められない取引です。

2−3.システムリスク管理

(ア)システム安全管理等の問題

(多数の業者で認められた事例)

  • 業容や事務量に比べ、システム担当者が不足している。

どれくらいの担当者を配置するのが適切なのか、という比率が決まっているわけではありません。ただ、資料に記載するほどの内容であるということは、システム担当者の勤務時間がかなりの超過勤務になっていることや、スケジュールの遅延が発生していることで、システム上で対応すべき課題が消化できないほど逼迫した状態だったことを示しています。

FISC安全対策基準では、【統2】において、人材を含めた経営資源を考慮した計画を策定するように求めています。

  • サイバー攻撃に関するリスクシナリオやコンティンジェンシープランを策定しておらず、セキュリティに関しての研修を実施していない。

こちらは【統4】セキュリティ管理体制、【統5】サイバー攻撃対応態勢をそれぞれ整備することを求めていますし、【統14】でセキュリティ教育の実施を求めています。なお、サイバー攻撃に関するコンティンジェンシープランに特化した基準は存在しませんが、【実73】で、障害時や災害時を含めたコンティンジェンシープランの策定を求めています。

(個社で認められた事例)

  • 使用されるブロックチェーンやスマートコントラクトの安全性等の評価を行わないまま、暗号資産を自社で発行し、販売している。

暗号資産を直接的に規定した内容ではありませんが、暗号の利用にあたっては適切な評価を行うことが、【実13】で求められています。また、暗号を利用するにあたっては、CRYPTRECによる電子政府推奨暗号リストを参考にすることが求められています。

CRYPTREC:https://www.cryptrec.go.jp/

もちろん、このリストに掲載されていない暗号の利用を否定するものではありませんが、暗号は、コンピュータの処理能力の向上によって、だんだんと強度が弱くなっていきます。このため、顧客の資産が(暗号の強度が弱い場合は)保護されない可能性があることを指摘しているものと思われます。

(イ)開発と運用の牽制の問題

(複数の業者で認められた事例)

  • システムの開発及び運用・管理を同一の担当者が担当している。

システム開発を経験したことがあれば、「開発と運用の分離」は、絶対に必要なことというのは理解していただけるものと思います。これが徹底されていなかったばかりに、システムを悪用した犯罪がいくつも発生しています。当然、FISC安全対策基準でも【統9】で、開発担当者が本番環境を操作できないようにすることが求められています。

(個社で認められた事例)

  • 特権IDを付与している社員に対する牽制をしていない。

FISC安全対策基準では、【実27】で特権IDについては、利用者を限定して特別に注意するように明確に求められています。特権IDは非常に強い権限を持つため、不正利用だけではなく、サービスの予期せぬ停止を防ぐため、厳重に管理される必要があります。

(ウ)システム障害対応の問題

(複数の業者で認められた事例)

  • システム障害に関する管理台帳(発生件数、発生日、発生時間、影響範囲、改善措置の網羅性及び再発防止策の策定等)を作成しておらず、システム障害の発生状況を把握していない。
  • システム障害が多数発生しているにもかかわらず、根本原因の分析が行われていない。

(個社で認められた事例)

  • システム障害の台帳類が複数存在し、一元管理されていない。

FISC安全対策基準では、【実72】において、障害事例を収集して分析を行うことで、再発防止に役立てることを求めています。いわゆるバグトラッキングの仕組みを利用しても問題はないのですが、そもそも登録していなければ、傾向分析も再発防止もできません。この点については、品質確保の取組としても必要だというのがメッセージなのでしょう。

(エ)開発の問題

(個社で認められた事例)

  • システムの開発管理規程に定められた要件定義書、開発計画書及び設計書が作成されていないほか、ビジネス部門による受入テストが実施されていない。

まず、システムの開発管理規程を作成することについては、FISC安全対策基準の【実75】で求められていることなので、これ自体は満たしているものと考えられます。

しかし、計画書や設計書を作成すると規定されているのに、作成されていないというのは、なかなかの問題です。どのレベルの要件定義書や設計書なのか、というのはこの資料からは読み取れませんが、設計書が存在しないということは、非常に大きな問題です。FISC安全対策基準の【実45】では災害時の復旧のために、設計書をバックアップするように求めていますし、【実90】では、設計段階での品質確保のためにも、要件定義書や設計書について、責任者の承認を得ることを明確に規定しています。

  • システム開発時に限界値を把握していない中、システム運用時に取引量がシステムのキャパシティを超え、利用者に影響を及ぼすシステム障害が発生している。

想定以上の取引が発生していることで、システムが高負荷となっている状態です。古い用語では「輻輳」(ふくそう)と呼ばれます。「電話のパンク」が非常に近い意味合いです(輻輳も、もともとは電話用語です)。

キャパシティの管理については、FISC安全対策基準では試験段階の基準として【実92】で試験段階での限界値試験の実施を求めています。また、運用時の基準として【実47】で資源の使用状況について監視することを求めていますし、【実101】で負荷状態の監視を行うことを求めています。さらに【実116】では、インターネットサービスにおける信頼性向上策として、システムが高負荷となる前に、取引量の制限を行うことや、サービス能力を向上させるなど、サービスを安定的に提供するための基準がいくつも定義されています。

2−4.利用者保護

(ア)自社発行暗号資産の問題

(個社で認められた事例)

  • 自社発行暗号資産と関連する事業の詳細や会社の財務状況、当該暗号資産の販売内容等について、利用者への情報提供が行われていない。
  • 自社発行暗号資産の販売に際して、当該暗号資産の販売によって取得した資金を、自社の経費として費消するのみで、利用者に事前に説明していた新規事業の実現のための事業資金として利用していない
  • 自社発行暗号資産の販売に際して、当該暗号資産の販売によって取得した資金及び自社で保有する当該暗号資産の財務諸表上の取扱いについて検討を行っていない。
  • 自社発行暗号資産を販売後、事前に公表していた事業計画等を記載したホワイトペーパーの内容と相違する事実が発生したにもかかわらず、これを開示していない
  • 自社発行暗号資産について、縁故者への大幅なディスカウント販売や無償付与、役職員による販売に対する多額のボーナス付与などの情報が利用者に説明されていない。

利用者保護(投資家保護、顧客保護)の視点では、すでに何度か触れていますが、ここで指摘されているのは、金融の問題ではなく、企業会計上の問題です。システムの問題ですらありません。それでも金融庁がこの資料に記載しているということは、投資家を保護するために(そして、投資判断をする際の参考情報として)、あえて事例として記載したのだろうと推測されます。

(イ)情報管理の問題

(複数の業者で認められた事例)

  • 利用者の個人情報にアクセスできる社員が限定されておらず、また、外部委託先も個人情報にアクセスできる状況にある。

個人情報の管理については、個人情報保護法はもちろんですが、金融分野においては「金融分野における個人情報保護に関するガイドライン」が制定されており、これに従う必要があります。FISC安全対策基準においても、基準の前文から、個人情報を含めた情報管理の重要性について、ページをさいて記載しています。

直接的な基準としては、【実69】で顧客データの保護の基準として、個人情報にアクセスできる権限を最小限にすることを求めています(もちろん、法やガイドラインに従うことも明記されています)。

  • 利用者の個人情報を管理する台帳等を整備しておらず、また、個人情報を社外へ自由に持ち出すことが可能な状況となっている。
  • 個人情報の取扱状況の点検計画が策定されておらず、現に点検を実施していない。また、個人情報の安全管理に関する研修を実施していない。

こちらは、個人情報保護法の範疇であって、コンピュータシステムの安全性とは直接の関係はありませんが、実施できていないことは重大な問題です。

(ウ)苦情対応の問題

(複数の業者で認められた事例)

  • 利用者からの苦情・相談の内容及び当該苦情等に対する対応状況を把握・管理していない。
  • 利用者からの苦情・相談がその場の個別対応になっており、当該苦情等の内容を一元的に把握・管理しておらず、業務の改善に向けた分析も行っていない。
  • 利用者からの照会や苦情等に対応する要員が十分確保されていないことから、当該照会や苦情等について解決がなされないまま長期間放置している。

(個社で認められた事例)

  • 新規の口座開設に要する期間がHPに掲載されている目安期間を大幅に超えているにもかかわらず、口座開設期間の短縮化に向けた対応を講じていない。

こちらも、コンピュータシステムの安全性とは直接の関係はありませんが、急激な事業拡大に伴い、対応する要員だけではなく、その分析や改善を行う要員が不足していることを問題視しています。余談ですが、苦情対応に関する国際規格として、ISO10002:2014(日本では、JIS Q 10002:2015)が制定されています。こちらはISO9000シリーズとの整合性も確保されていることから、品質マネジメントシステムの一環として整備すると良いでしょう。

(エ)取引の適正の問題

(複数の業者で認められた事例)

  • 証拠金取引において、レバレッジ倍率の設定やロスカット取引の実行に際して、各暗号資産のボラティリティや取引量等を定期的に検証し、これを反映させていない。

金融システムにおける証拠金取引は、外国為替証拠金取引、いわゆるFXに関連するガイドラインを参照することが、もっとも親和性が高いものと考えられます。外貨の場合、これまでの価格変動の推移から、ある程度の根拠をもった基準を策定することができますが、暗号資産の場合は歴史が浅いことから、なかなかレートやレバレッジの設定がむずかしいものと考えられます。このため、「定期的に検証」することを求めているのでしょう。少なくとも、なんらかの(定量的な)根拠をもった基準を設定することができなければ、投資家を適切に保護することができない、というのが金融庁のメッセージのようです。

2−5.外部委託先管理

(個社で認められた事例)

  • 外部委託業者の選定に当たり、当該業者の評価を行っていないほか、委託契約も締結していない。
  • システムを外部に委託(ホワイトラベル)している中、システム障害が発生しているにもかかわらず、当該外部委託先に原因究明や再発防止策を求めていない。
  • 基幹システムを外部企業が提供するサーバーに格納しているが、クラウド事業者を外部委託先と認識しておらず、必要な外部委託先管理がなされていない。
  • 外部委託業者が再委託を行うに際し、再委託内容や再委託業務の実施状況を確認していない。

外部委託先の管理については、FISC安全対策基準も、歴史的な経緯もあり、かなり細かく取り上げています。大きくは直接の委託先の情報管理を求められていた時代から、再委託先を含む、委託ルートすべてにおける管理に進展する「ガバナンス」が課題となってきました。最近では、外部委託先としてのクラウドを含めたシステムの利用に関する安全対策基準が制定されています。

委託先の選定については、FISC安全対策基準の【統20】で、事前に目的や委託範囲を明確にするとともに、委託先(再委託先以降のすべての委託先を含んでいます)の選定基準を明確にするように求めています。また、委託先の範囲にはクラウドや共同センターを含むという明確な記載があります(このため、クラウドは明確に外部委託先となります)。契約を締結していないのは、システムの問題ではなく下請法や民法の問題なので、今回は割愛します。

障害情報の収集については先述のとおり【実72】で障害情報を収集することを定めていますが、外部委託に関しては【統21】でインシデントの取扱いを含む項目を契約に含めることを求めています。

契約が結ばれていないのは論外としても、委託先管理を確実に実施するということについて、金融庁はこの点でも強いメッセージを発信していると受け止めるべきでしょう。

 

次回は「内部監査部門(第3線)」と「カルチャー及びコーポレート・ガバナンス」について取り上げます。

 

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です