金融制度ワーキング・グループ（第４回）議事録
１． 日時：
平成28年12月８日（木）17時00分～19時00分
２． 場所：
中央合同庁舎第７号館13階 金融庁共用第一特別会議室
【岩原座長】
それでは、予定の時刻になりましたので、ただいまより「金融制度ワーキング・グループ」第４回会合を開催いたします。皆様、ご多忙のところをご参集いただき、まことにありがとうございます。
初めに、本日参考人としてお越しいただいている方について、事務局よりご紹介をお願いします。
【井上信用制度参事官】
事務局を務めさせていただきます信用制度参事官の井上でございます。
本日、参考人としてマネーフォワード取締役兼Fintech研究所長の瀧様、それからfreee株式会社代表取締役、佐々木様にお越しいただいております。どうぞよろしくお願いいたします。
【岩原座長】
それでは、議事に移らせていただきます。前回までの討議において、いわゆる決済に関する中間的業者の取扱いについて議論を進めてきたところでございます。本日は、まず事務局から、本日の討議資料である資料１により、これまでの議論を踏まえた、決済に関する中間的業者の取扱いに関する論点等について説明いただき、続いて瀧参考人から資料２により、佐々木参考人から資料３により、オープン・イノベーションと中間的業者について、それぞれお話をいただいた上で討議を行いたいと存じます。
それでは、事務局から資料１について説明をお願いいたします。
【井上信用制度参事官】
それでは、私からご説明申し上げます。皆様方のお手元に資料１として「討議資料（決済に関する中間的業者の取扱い）」をお配りさせていただいております。本日は、この討議資料に沿いまして、ご説明申し上げたいと考えてございます。
討議資料の１ページ目でございますけれども、オープン・イノベーションの重要性とその課題についてということでございます。
まずは「（１）オープン・イノベーションの重要性」といたしまして、ITの進展に伴い、金融サービスをめぐる環境が構造的に変化する中にあって、決済関連分野において、FinTechの動きを進展させることを通じて利用者利便の向上、さらには我が国金融・経済の発展が図られるような環境整備を進めることが重要となっているのではないか。特に、我が国においては、諸外国と比べて、銀行システムが提供するネットワークが発達していることに鑑みれば、金融機関とFinTech企業とのオープン・イノベーション（外部との連携・協働による革新）を進めていくことが重要な課題の１つとなっていると考えられるのではないか。その際、顧客が抱える課題やニーズを出発点に、単なる金融サービスのIT化にとどまらず、より高い付加価値を提供するとの方向性を考えた場合、決済関連分野において、近年、金融機関と顧客との間に立ち、顧客からの委託を受けて、ITを活用した決済指図の伝達や金融機関における口座情報の取得・顧客への提供を業として行うもの（以下、電子決済等代行業者または業者という。）が登場・拡大していることが注目されるのではないか。これらの業者は顧客とのインターフェース（接点）を確保しつつ、金融機関とも接続することで、ITの進展を活用した多様なサービス展開の可能性を有しており、FinTechを利用者利便の向上等につなげる動きの１つの核となることが考えられるのではないかとさせていただいています。
２ページに移っていただきまして、上のほうからでございますが、また金融機関と電子決済等代行業者との接続の方法については、API（Application Programming Interface）を利用した方法が、利用者のセキュリティを確保しつつ、電子決済等代行業者が銀行システムにアクセスして、さまざまなFinTechに関連したサービスを提供することを可能とする技術となっており、オープン・イノベーションの１つの核になる技術として考えられるのではないか。我が国におけるFinTechの進展のためには、各金融機関においてAPIの導入が広く進むとともに、それが外部企業との連携・協働（オープン・イノベーション）のもとで、適格性や情報管理能力等の面で問題がある業者以外の業者に広く開放されること（オープンAPI）が重要であるとの指摘について、どう考えるかとさせていただいています。
以上の点が、「オープン・イノベーションの重要性」としての基本的な考え方及び論点としてお示しさせていただくものでございます。
続きまして２ページの真ん中からでございますけれども、「（２）オープンAPIをめぐる状況と課題」について、ご説明申し上げます。
他方、我が国におけるオープンAPIをめぐる状況を見ると、以下のような問題点が指摘できるのではないか。オープンAPIを実施している金融機関は少数にとどまっており、また、オープンAPIを実施している金融機関においても、必ずしもAPIを電子決済等代行業者に対し広く開放するには至っていないのではないか。電子決済等代行業者においても、そもそも多くの業者が、金融機関の連携・協働先として認知されていない状況にあるのではないか。また、金融機関において認知されている業者であっても、オープンAPIにより接続できる金融機関は限られているのではないか。
３ページに移っていただきまして、このため、多くの電子決済等代行業者が、顧客から預かったパスワード等を使って、金融機関との間で契約締結等の明確な法的関係を構築することなく、銀行システムにアクセスする「スクレイピング」による方法で、サービスを提供する状態となっているのではないか。こうした状況については、以下のような点からどのように考えるべきか。利用者において、サービスの利用に当たり、銀行口座に関するパスワードといった重要な認証情報を業者に取得・保有させることとなることについて、顧客情報の漏洩、認証情報を悪用した不正送金等、セキュリティ上の問題が生じないかとの不安が生じていることがないか。電子決済等代行業者による決済指図の誤伝達・不正伝達による決済リスク、あるいは電子決済等代行業者からのアクセスの増大に伴う銀行システムへの過剰な負担の可能性など、決済・銀行システムの安定性に影響を与えているといったことはないか。「スクレイピング」によることにより、業者のコストがAPIによる場合に比して増大する場合もあり、結果として社会全体のコストを増大させているといったことはないか。
以上、こうした点が、「オープンAPIをめぐる状況と課題」としてお示しさせていただくものでございます。
続きまして、３ページの下のほうから４ページ以降にかけまして、「オープン・イノベーションに向けた環境整備」について、ご説明させていただきます。
今後、我が国において、オープン・イノベーションを関係者において健全かつ適切に進めていけるようにするための制度整備として、欧州も参考にしつつ、仮に一つのモデルを提示するとすれば、例えば、以下のようなものが考えられるがどうか。業者に登録制を導入し、当該業者が顧客から資金を預かることがないことに留意しつつ、例えば以下を求める。適正な人的構成（欠格事由等）、必要に応じた財務要件、情報の適切な管理、業務管理体制の整備。業者が、金融機関と接続して顧客に対して電子決済等代行業サービスを提供する場合には、金融機関との契約締結を求める。（注）業者のうち、決済指図の伝達を行わず、口座情報の取得・顧客への提供のみを行うものについては、金融機関がオープンAPIを導入するために必要な期間を勘案して、一定期間、契約締結を猶予する。こうしたオープン・イノベーションの取組みに参加しようとする金融機関においては、一定の期間内にオープンAPIに対応できる体制の整備に努めることとする。金融機関は、小規模業者等の接続を合理的理由なく拒否しないよう、契約締結の可否に係る判断の基準を策定・公表し、当該基準を満たす業者とは、原則として契約を締結することとする。金融機関は、オープン・イノベーションの観点を踏まえたオープンAPIの導入に関する方針及び（オープンAPIを導入した場合には、契約を締結した）業者との間で顧客に生じた損失の分担を定め、公表することとする。なお、顧客との間での損失分担ルールについては、電子的取引等をめぐる私法上のルールが必ずしも確立されていない現状において、一般的なルールを規定することは難しいが、上記の対応として、責任保険への加入の可能性等も含め、関係者の申し合わせによる取組み等が検討されるべきではないか。上記、４ページの真ん中の（注）の猶予期間経過後であっても、金融機関との契約に基づくものであれば、業者がスクレイピングによりサービスを提供することも可能とするが、金融機関は情報管理体制の整備等が十分である業者に対してのみ、これを認めることができるものとするとさせていただいております。
討議資料の５ページの真ん中あたりから、論点として、以下のものを提示させていただいております。
以上のようなモデルに対して、米国においては、現時点では、法制による利用者保護やオープンAPIの活用等を通じたオープン・イノベーションの推進のための措置は講じられていない。我が国の状況等に照らして考えた場合、いずれの方向性が求められていると考えるか。この点に関し、決済指図の伝達を行う業者とそれ以外の業者とで、何らか異なる考慮が必要になるということがあるか。以上のほか、決済に関する中間的業者の取扱いなど、オープン・イノベーションに向けた環境整備に関し、検討しておくべき点があるかということでございます。
事務局からの説明は以上でございます。
【岩原座長】
どうもありがとうございました。続きまして、瀧参考人から、資料２について１５分程度で説明をお願いしたいと思います。
【瀧参考人】
マネーフォワードの瀧でございます。本日はどうもありがとうございます。本日お持ちしております資料は、当社がもともと家計簿と会計ソフトなどを提供しているサービスという立場ではございますが、より広く金融機関への将来像も含めたときに、今APIとこの議論について、当社としてどのような意見を持っているかというのを述べたものでございます。２段構えとなっておりまして、後半に参考資料として海外での動向というのを付させていただいております。
２ページ、下でございますけれども、現時点で、なぜAPIが重要なのか。当社でAPIについては２年ほど前から、銀行業がAPIをあけることは重要なのだということを、いろいろな形で提言をさせていただいてきたのですけれども、なぜかというところのたてつけが、この枠組みで示されております。
１つは、一般化した話ではございますが、金融機関のこれまでとこれから５年後、１０年後の金融を見据えた中でのこれからでございますけれど、今までであれば、金融機関の中にある専門性でありますとか、あるいは日本が現金経済であるところに即すと、どうしてもATMというものが比較優位を持っており、かつ顧客が非常に金融の振り込みの手続などについて、世の中が寛容であったわけでございます。こういった世の中の期待値のところから、現在スマートフォンとか、あるいはもっと便利なツールが出てきている中で、金融に対する期待値が今後消費者として変わってくるであろうというのが、右側のボックスで、おおむね４点にあらわされるのかなと思っております。
まず、さまざまな、例えばファイナンシャルプランニングであるとか、企業財務の判断とかが、以前ほどには金融機関の専売特許ではなくなってくる、外部でもさまざまな共有知ベースのものが出てくるというのが１点目でございます。
２点目は、従来であれば金融機関の中から出てくるレベルのアドバイスというものが非常に価値を持っていたところが、顧客から見て、さまざまな金融機関の情報を集めた、カスタマイズされたアドバイスでないと、満足感を得られにくくなってくるという顧客の変化がございます。
あと３点目としまして、これはアマゾンでの決済などにも代表されますけれども、何かを買おうと思ったときに、わざわざ振り込み行為というものを行いたくないというのがあります。どうせであれば、買うという意思決定をするときに、決済などがシームレスに提供されるような経済圏が当たり前になるという姿がございます。
そして最後にあるのが、よくオンライン化と申し上げますときに、銀行のオンライン化とはインターネットバンキングの提供だと、そういう期待値がいまだあるわけでございますけれども、将来、実はパソコンすら持っていない層が当たり前になったときに、その人のユーザーインターフェースとは何かという話題がございますわけで、この右側のビジョン感をちゃんとかなえていくために現状、当社をはじめ、新しい技術を活用したサービス群が１つお役に立っているのかなというのが、この真ん中にあるボックスというところでございます。
１枚めくっていただきまして、３ページにございますのが、本日の議論とも接合する関連箇所。金融機関のこれからの４ポイントに即して申し上げますと、１つ目の専門的判断のところは、どうしても今後とも不安のヒアリングなどを通じて銀行、店舗等が優位性を持つところであろうというところにはなっていくのですが、この２点目のところが、特に我々のような家計簿や会計ソフトにとっては重要でございます。１つの銀行口座の情報から得ることができるアドバイスというものには結構限度があるであろう、そうではなくて、さまざまな金融機関から、英語で言うとentiretyですね、全体的な情報を持って、そこに対するアドバイスが行われるからこそ価値を持つのであろうというところが、参照系のAPIを敷衍していくことによって意味を持つのかなというところでございます。
また３点目としまして、意思決定とシームレスさでございますけれども、ここにまさに更新系のAPIですね。支払い指図手段が、より広範に広がることのメリットが出てくるわけでございます。何かを買いたいと、例えば、住宅ローンを組みたいと思った際に、マンションのショールームにいるというタイミングにおいて、融資の判断がおりるかとか、実際の決済ができるかというようなところで考えていきますと、やはり金融機関の中で取引需要は発生しないわけでございまして、金融機関の外で生じる取引需要に対してシームレスな提供が行われるというところが、ここの肝なのかなと考えております。
また最後のところですけれども、やはりパソコンを使わない層が何を使うかといえば、今はスマートフォンでございます。ただ、１０年後、これ、まだわかりませんというところになっていく中で、その動きを、やはりいち早く取り入れられるようなプレイヤーに対して、いかに金融機関さんと協業ができるかというところが重要になってくるわけでございます。そのときの、やはりコアになるのはAPIという概念でございます。４ページは非常にベーシックな話ですので割愛いたしますけれども、やはりAPIとは何かといいますと、それは何らかのコアビジネスだと思われていたものを他社の中で部品化すると、そういう発想でございます。部品化をあえて受け入れることで、他社の利益でありますとか、他社の利便性の中のエコシステムの中で、実際にインフラを使ってもらうところに価値を見出すタイプのビジネスモデルでございまして、そこをいかに訴求していくのかというのは、さまざまな実験と、ある意味さまざまな失敗を経ながら進化していくものだという理解なのかなと思っております。
５ページでは、参照系APIと比較しますときに、スクレイピング技術というのがよく比較に挙がりまして、これが危ないものだといったご主張もよく聞かれますので、一旦これまでの歴史感というのをお伝えしたく思っております。スクレイピング技術というのは、１６年ほど前から日本でも存在しているものでございまして、大手のシステムインテグレーターさんであるとか、メガバンクさん自身も、こういった技術を活用したサービスというのは今までも提供してきたものであるわけでございます。現に２００２年の時点で、こういったスクレイピング技術をベースにしたアグリゲーションのあり方について、全銀協さんでも１つ考え方が出されておりまして、日本では長らく、特に事故もなく運用されてきたものだというご理解を得られればと思っております。そして２０１２年ごろから、やっとスマートフォン人口が増え、初めて家計簿を使った人たちが増え、世の中でも、こういった技術自体の普及が図られたということで、やはりユーザー層の拡大ということが、ある種、今般の議論の背景にあるわけです。技術としての危険性があるから取り上げられているわけではないという点は申し上げておきたく思っております。
下に行きまして６ページでございますが、現状、既に参照系のAPIというのは、日本では４つの銀行で展開をされているものでございます。この４つという数字は、世界でも最先端でございまして、よく周回おくれとか、いろいろ言われる日本のFinTechではあるのですけれども、この数については非常に、既に世界的にも類を見ない成果を得たものとも言うことができるところではあります。こういったものを、当社であれば４００万人の家計簿利用者と５０万事業者の会計ソフトユーザーが使っていただいているというところでございます。
めくっていただきまして７ページ、８ページはご参考でございます。仮に更新系のAPIが出てくると、どういったことが可能となってくるかという話でございまして、家計簿のソフトで、より更新系のAPIが使える世界観が可能となれば、家計への不安は、貯金ができれば結構解消されるところですので、そういったことを、より促進することができるというのが上側でございます。片や下側の更新系のAPIであれば、端的に言うと、意思決定をした瞬間に支払いをしたり、わざとお金がたまってしまう仕組みをつくらないというのがございまして、経営のPDCAが早くなるというところが出てくるわけでございます。
めくっていただいて９ページでございますけれども、APIについては非常に重要な観点で、今後とも全銀協等の場所でも進めていくべきトピックとして、質というトピックがございます。現状、よくAPIは仕様の標準化がどうこうだという議論があったりもするのですけれども、一ユーザーとして考えますと、質の高い仕様が担保されていくことが同等以上に大事だというところがございます。ボックスで囲っておりますけれども、それぞれAPIは、より世の中をセキュアに運用するための認証・認可の技術におけるあり方というのもございますし、現状、データ参照の仕様というのがまだ定まっていない点がございます。現状、APIで入出金のデータをとろうとしますと、年号が入っていなかったりとか、そもそも１カ月分しかデータがとれないといった、ある種、データを利用する企業にとっては非常に不便な状況が発生しえます。このデータを元に、例えばトランザクショナルファイナンスをしようとしても、１カ月分のデータでは何もできませんみたいなところになりますので、ユーザビリティーがまずは低いデータの形式、もしくは期間として提供されているという点の改善も、問題意識としてあるわけでございます。また最後のボックスにございますけれども、実際の振り込みをするときに、ものすごく手間がかかってしまう仕様に最終的になってしまうと、そもそも銀行のサイトのままでよかったじゃないかみたいな話もあるわけでございまして、やはりシームレスさをどのようにして担保していくのかについては、不断の努力が求められるというのがあるわけでございます。
私どもの中間的業者規制が入ってきたときに対するスタンスは、１０ページにございます。略字で恐縮ですけれども、PISPは送金指図等を行う業者でございまして、AISPは、これPSD２の用法に倣っておりますけれども、口座参照型のプレイヤーでございます。
PISPのほうは、まだ日本では明確な状態が存在していない業態でございます。ですので、ある種これから生まれる業態に対して制度という、ある意味、不確実性を減らすという過程を通じてプレイヤーを生んでいこうとする、そういう考え方の中での規制の考え方になります。私どもが仮に、家計簿の中でお金を送る機能をつけたいと。実際に当社のサービス内でそれを完結させようとしますと、基本的には銀行代理店をとってくださいという話になってまいります。ですので、ここは、さすがに１社だけであれば銀行代理店の契約は結べるかもしれませんと。ただ、マネーフォワードがある種データ連携をしている１５０、２００といった銀行とそれぞれ契約を結ぶことは困難なものになってまいります。ですので、何か汎用的なライセンスに近い概念がここでは求められているという理解でございます。また、１つは必ず、誤送金をしてしまったとか、金額を間違えてしまったというリスクがあるわけでございまして、これは１つ例えで申し上げますと、耳が聞こえない方が銀行の窓口に来ました。その方が手話を理解できる介助人を連れてきました。その介助人の方が、Aさんに１万円振り込んでくださいと伝えられたのを、１０万円、Bさんに振り込んでしまうといった、そういう聞き違いをして、それをそのまま銀行の方に伝えてしまいましたと。この責任は誰にあるのかという話を考えたときに、従来は、やはり、それは介助人の方と依頼人に責任があるというのが１つの判断だったわけでございますけれども、APIを用意することによって、実は、その介助人自体を、銀行が選んだ人であるという、ロジックが出てくるわけでございます。ですので、この人にどこまでの責任を社会的な規範の中で求めていくのかが、ここでの議論の出発点になるのかなというのが当社の理解でございます。
一方で、口座参照型のプレイヤーであるAISPのほうでございます。こちら英語で書いてしまっておりますけれども、何か、データ活用において不適切な行為をしてしまう業者が出てきたときにどうするのだという話があるわけでございます。ただしこれは、必ずしも金融法の中で見るべきかという議論は常にあるのかなとは思っております。ただ、今般の金融制度をより便利にしていくという枠組みの中では、こういったものに対して一定の枠組みを構えることで、協業がやりやすくなる点があるわけです。悪い方向へのは運用が行われないという期待値をつくれる点においては、非常に評価がされ得るものなのかなというのが意見でございます。また、何もない枠組みの中ですと、当社が例えば銀行様と提携していくに当たっても、まだまだいろいろな各社ごとに異なるデューディリジェンスを受けるわけでございまして、私どもとかfreeeさんとか、わりと大きくなってきた会社でもあっても、こういう状態でございますので、より新しいFinTech事業者が新しいサービスを考えていくに当たっては、ここの前提に対して何らかの枠組みがあるということは、１つ評価に値するのかなと考えております。ただ、金融制度の中でとらえるべきかという話と、個別の事業者がセキュリティを大切にしましょうという話は、ある意味、別軸の話でございまして、ここは今、FISCさんのところでもFinTechの有識者会議がございますけれども、そこの中での期待値をしっかりつくり上げていくと。当社もFISCの会員に最近なりまして、そういった中で、ソフトな枠組みを見ていくということが重要なのかなと考えている次第でございます。
めくっていただきまして１１ページでございますけれども、やや当社として考えている点、２点ございまして、１つは規制の目的自体がエコシステムの醸成であると、何か危ないことが起きているから規制が必要だという文脈よりは、制度の不確実性を減らすことで新しいプレイヤーが出てくるのだというところが大事なわけでございます。これは、新しいプレイヤーがどのようにして生まれるのかという議論を非常に大切にする必要があるという理解でございまして、海外ですと、よく銀行APIをあけるときというのは、ある意味、本番のサイトであけるというよりは、２年間、３年間ぐらい、どういう事業者さんが、どういうAPIが欲しいというテスト期間を設けることが、わりとよくあることでございまして、そういった中でハッカソンをやるとか、クローズド環境で開発者向けのテストをしてもらうということをやってくるわけでございます。日本は、そこで１つ議論が飛んでしまったところがございます。既に、先ほどございましたように、４つほどの銀行が実際に使えるものを契約ベースで使えるようにしているというところがございまして、非常に喜ばしいことではあるんですけれども、よくProof Of Conceptと呼ばれるような、ビジネス自体がほんとうにつくられるのかという検証をまだしている過程でもあるというご認識をいただければと思っております
そのようなことを考えたときに、ここの２点目であるのですけれども、参照系のAPIは、それ単体では、FinTech事業者がすごく儲けることができているかというと、非常にそこは、まだ我々事業者としても頑張っているというところが正直なところでございまして、一方で、振り込み等がいずれ可能になる更新系APIの世界であれば話は変わってまいります。振り込みがたくさん行えるようであれば、それは銀行に手数料が落ちてまいりますので、そこに対する戻しがあるような形であれば、ゴールイメージとしてはビジネスが見えやすいと。ただ参照系のところは、まだまだここは、じゃあすぐに、ここからお金を取るモデルが銀行さんに生まれるかというと、これは結構まだ検証が必要なタイミングなのではないかというのが当社としての思いでございます。ただ、現状では、APIを入れるためのシステム開発を通すために、やはり目の前のROIを非常に追求するというのが金融機関様の中でのスタンスとしてもございまして、そこから各社ごとに、例えば月額１０万円、３０万円といったものが発生してしまうと、最後、私ども、２００行とか３００行ぐらいのさまざまな金融機関さんと接続したときに、仮にAISP規制が軽やかなものになったとしても、実態としては誰もやりたくない規制になることにはしたくないなというのが１つ懸念としてあるわけでございます。というのが１１ページでございます。
１２ページは割愛させていただきまして、１３ページ、１４ページでございますけれども、海外でどうなっているのかというのを、数年間この議論を見てきた身からしますと１つ。この場がその場というわけではないと思うのですけれども、データポータビリティというキーワードは必ず残していただければと考えております。これは欧州でも、英国でも、米国であったとしても、今ユーザーにとって、みずからのデータへのアクセス権をいかにして担保するのかという話が非常にポリシー上、重要になっているということでございます。それをベースに、ハードローの中でそれを定めるのか、あるいは自主的な、こういったことが便利ですよねという商慣行を通じていくかというのはさておき、そういった、実際にユーザーさんがみずからのデータを、必ずしも金融機関のサイトでないところであったとしても、認証・認可の過程を経ることで使うことができるということが非常に重要な観点になるわけでございます。そのもとで、それをどのようにして、やはりデータのセキュリティをちゃんと保つかといった議論自体も、これもハードローで定めるべきなのか、いや、もう自主規制機関でいいのではないかとか、さまざまな議論がございまして。
１つの発想は、英国のOBSも定めている自主規制機関というところでございます。全部読み上げませんけれども、独立機関を１つ作成しまして、望ましいデータの仕様でありますとか、セキュリティのガイドラインをつくると。場合によっては、ホワイトリストをFinTech企業の中でつくることで、これを担保しようというあり方が英国ではあるわけでございます。
また１５年前の議論ではございますが、下側１４ページですけれども、やはり同じような議論は１５年前になされておりまして、米国のBITSと呼ばれております業界団体の中で行われた議論というのも、これは基本的には、やはり自主規制的な枠組みの中で、送金指図とかをしない場合のアグリゲーターについては法的規制は要らないのではといった話もあるわけでございます。必ずしも会計ソフト、家計簿ソフトが送金をしたいというニーズを持っているわけではない中で、そこは明確な制度的な分けがあるべきではないのかなと考えております。
また最後になりますけれども、最近、CFPBという消費者金融保護局が、Project Catalystという、FinTechを促進するためのプロジェクトを長らく続けておりますけれども、その中でのまとめが最近出てまいりまして、最後の二、三行を見ていただければと思うのですが、米国においても、個々人がデータに対して、さまざまなツールを通じてアクセスすることの価値は、最終的には消費者の価値のある金融制度をつくるために必要だというスタンスを見せてきているわけでございます。
ですので、このあたりも勘案しながら、今般の制度に関する議論形成をしていければと思っている次第でございます。以上でございます。
【岩原座長】
どうもありがとうございました。続きまして、佐々木参考人から、資料３について１５分程度で説明をお願いしたいと思います。
【佐々木参考人】
freeeの佐々木でございます。私たちは実際に、じゃあユーザーさんが、このAPIにおいて、どういったメリットがあるのかと、こういったところを念頭に置きながら、このAPIによるエコシステムがどんなインパクトをもたらすのか、何が必要かといったところをお話しさせていただければと思うのですが。私たちは主にBtoB向け、スモールビジネス向けのサービスを展開しておりますので、その取組みというのを前提としてご紹介させていただいた上で、将来のあり方、そして規制のあり方について、お話しさせていただければと思います。
まず４ページになりますけれども、私たちのご紹介とさせていただきますと、スモールビジネス、こちら中小企業の方、それから個人事業主の方、これらに携わる全ての人が創造的な活動にだけフォーカスできるような世の中をつくりたいと、こういった思いを持って、私たちは４年前に会社を設立して、６０億円以上の資金を調達して成長してきた会社でございます。
今では２５０人以上の従業員がいるのですけれども、このサービスの成長を支えてきた背景として、５ページをご覧いただければと思いますけれども、非常に多くの中小事業者に支持をされてきたといったところがございます。この提供しているサービスは、クラウド型の会計ソフトというものを提供しているのですけれども、こちらは銀行とかクレジットカードの口座と連携して、自動でデータをとってくると。そこから人工知能を用いて、自動で銀行やカードの明細から帳簿をつけていくところが１つの特徴となっています。もう一つの特徴として、請求書を作成するとか、受け取った請求書を、この会計ソフトの中に入れて管理をしておくだけで、そういった情報も含めて、会計情報に反映される。ここが大きな特徴となって、圧倒的なスピードで成長してきたサービスになります。
では、なぜこういったものが開発されたかという背景ですけれども、私は以前、数十名程度のベンチャー企業で財務の責任者として仕事をしていたのですね。そのとき、私は全く経理のプロセスを知らなかったのですけれども、横にいる経理の担当の人間が１日中入力業務をしているといったところが見ていられなくてですね。この１人の入力の時間というのが、このベンチャー企業にとってより、例えば高度な財務分析だとか、そういったところに時間が充てられたら、かなり強いサポートになると思いました。この原体験が、この会計ソフトを生みました。では、どうやって、この入力を減らせるのだろうと考えてみると、１つは、こういった現金だとか、いろいろな取引のデータを入力するわけですけれども、実は、こういった取引のデータというのは、銀行とかクレジットカードの明細の中に全て入っている。もう一つは、例えば請求書を受け取って支払うというまでのプロセスの間に、請求書の支払日、支払ったら資金繰りがどうなるかというのをエクセルで管理しておく、そのデータを会計帳簿につける、オンラインバンキングで同じデータを入力して支払う。こういったことをやっているんですね。これらを全て一気通貫させるようなサービスがつくれたら、圧倒的に帳簿をつける作業というのは減りますし、その分、人が人らしく創造性を持って働くことができることになるのではないかと思って、そのコンセプトによって、このサービスは実現された次第です。
次にございますけれども、結果として今、このfreeeで実現していることとしては、銀行ですとかクレジットカード、さまざまな決済サービス、あるいはPOSレジのデータ、こういったものを全て一貫して会計ソフトの中に取り込んでいくと、帳簿をつけることが簡単になるということなのですけれども、この中でも特に銀行の明細は最も重要なデータソースということになっています。これがあることによって帳簿の作成の手間も省けますし、さらに財務分析だとかそういったところに、よりリソースを割くことができるようになることが、中小企業にもたらされるということです。
７ページ目になりますけれども、実際この自動取得される明細というのは、私たちのソフトウエアの中で同期連携の設定をいたしますと、このような形でクレジットカードあるいは銀行の口座というのが連携されます。連携されると、例えば東京電力ということが明細の中に書いてあれば、これは水道光熱費なんじゃないかということを自動で人工知能が推測しまして、ユーザーさんは入力する必要なく、確認するだけで帳簿がつけていくことができるという形です。
この中で、私たちもどんどんAPI連携というものも進めてきているわけですけれども、８ページになりますが、まず、その口座の情報をとってくるというところでは、２行の銀行さんと既に入出金明細の取得はやっておりますし、また、ほかにも幾つかの銀行さんと、このような似た連携は既に検討を開始している段階になっています。こちらをやることによって安定でセキュアな高速なデータ連携を実現することができまして、きちんとAPIが設計されている場合には、これまでのスクレイピングの技術を用いてデータをとってくることに比べても、圧倒的に低いコストで開発を実現することができるといったような形になっています。
次に決済の指図、こういったところですけれども、こちらも現在、幾つかの銀行さんと開発を検討して、連携仕様をつくっている段階にありますが、こちらは先ほど私が例で申し上げたとおり、freeeの中では既に請求書の支払い日、それが全てデータとして入っている。支払い日と相手の口座ですとか、そういったものが書いてありますので、そのfreeeの中に入っている債権情報を全て自動で決済してしまうといったことが、銀行の決済APIと連携することによって実現できます。そうすると、経理の業務は、支払いに関しては、ほぼ全て自動化をすることができますので、全く新しいユーザーエクスペリエンスが、これによって実現できるのではないかということを期待しています。また、さらに今後は、私、例えば会社を設立するツールというのをインターネット上で無料で提供しているのですけれども、会社を立ち上げるときには銀行の口座が必要ですので、それをそのまま開設する、そんなエクスペリエンスだったりですとか、あるいは振り込みが失敗したとき、あるいは入金があったときなどに、モバイルアプリに、そのまま、こういうエラーが起きていますよということを通知するような、そういったことも提供できるのではないかなと考えています。
次に１０ページです。銀行APIの実現することによる今後の世界といったところですけれども、こちら、銀行APIが存在する意味合いというのは、やはりユーザー自身が、自分の使いたいサービスを選ぶことができて、銀行に預けているデータ、それをもとに意思決定をして、実際取引を行う、あるいは資金移動を行う、こういったことを、そのままシームレスにできるようにしていく環境を実現していきたいという動きだと理解しております。実際にこれを実現するためには、どんなアプリケーションに対しても自由にアクセスができるといったところが前提になるのですけれども、どんな銀行をユーザーさんが使っていたとしても、どのFinTechのアプリケーションも選ぶことができると。これが例えば特定の銀行としか使えないといったものになってしまうと、これによってユーザーの利便性は大きく制限をされてしまうということになります。
次のページに、１１ページですけれども、こちら、私たちのユーザーさんに調査をした結果になります。私たちのユーザーさんに、法人のインターネットバンキングに、どんな機能が欲しいかといったような調査をいたしました。こうすると、例えば、もっと画面を見やすくしてほしいという話が３割を超えたりですとか、あるいは会計ソフトなどの画面から、そのまま振り込みできるようにしたい、こういったもののニーズが非常に高かったりですとか、あるいは口座情報とか、入金元企業だとかの情報をよりリッチにしたいと、こんなニーズがあったりします。またさらに、この下のほうになっても、例えば５％ぐらいの会社さんだけが持っているニーズみたいなものも、非常に多くありまして、これら全てを、じゃあインターネットバンキング上で実現できるかというと、やはり、そうではないのですね。ただ、オンラインバンキング上で実現できなかったとしても、これをサードパーティーがどんどん自由に開発できていくようにすれば、これは企業に存在するニーズ、あるいは消費者に存在するニーズというのを、１００％まではいかないかもしれないけれども、９９％かなえていくような、そういうプラットフォームをつくっていくことができるのではないかと考えておりまして、APIというのは、まさに、このような小さなニーズまでも含めて実現していく動きだと思っています。
その上で、じゃあ規制がどうあるべきなのかといったところですけれども、１３ページになりますが、まず前提として、私たちが実現したい世界というのは、先ほど申し上げたとおり、ユーザーさんのいろんなニーズに合わせてアプリケーションを選ぶことができて、それらが、あらゆる金融機関と連携して使うことができる世界ではないかと考えています。これを実現するためには、あらゆるユーザーの利用する銀行が、参照系だけではなくて更新系まで含めて十分実用に耐え得るAPIを開放していることだと捉えています。この十分実用に耐え得るAPIということですけれども、１つは、先ほど瀧さんのお話の中にありましたが、このAPIを開発するのに、スクレイピングをやるよりも大きなコストがかかるというものでは、なかなかサードパーティー側も、開発コストを負担できずに進んでいかないということになりますので、こちらのしっかりした技術仕様にのっとった仕様でつくっていくことは１つ求められることかなと思っています。また、これらを実現するためには、一定の期間を仕様作成のディスカッションということで置くべきではありますので、その準備期間が、まず必要だと捉えています。次に、開発に関するコストに加えて、やはりユーザーへのコスト転嫁が発生しないことは非常に重要だと考えています。結局、APIで連携するコストは高いということで、それがユーザーに負担させられるようなことが起こってしまうと、結局広げたかったイノベーションを広げていくということが実現しなくなりますので、大きなボトルネックになる可能性があるのではないかなと思っています。これらのような状況が実現されるまでに、先ほど瀧さんの話にもありましたけれども、スクレイピング自体が悪いテクノロジーだということではありませんので、そこが恣意的に停止されることは回避したいと考えています。
１４ページ目になりますけれども、コスト・利用料、この観点で言いますと、銀行APIというのは、ユーザーから見れば、いろんなアプリケーションを使う、その選べる選択肢でありまして、銀行側から見れば、オープン・イノベーションを実現するための手段です。だとすると、これが、じゃあ、どんどん対応している新しいアプリケーションがAPIから出てくるというところが、まず皆さんの共通のゴールということになってまいりますので、これをしっかり前提として認識することが大事だと思います。
その中で、特に、まず利用されることが重要だというところで考えていくと、新規参入の障壁にならないといったところが１つ重要です。今のところ、銀行さんも外部に発注してAPIを開発するといったところをやっておりますので、それによって外部のサードパーティー側に負担を強いるといったケースが出てきてはいますけれども、こういったことが続いてしまうと、先ほど瀧さんがおっしゃったように、実はAPIを利用することによってビジネスも成立しない、経済合理性もないという状態になってしまうと、つくりたかったプラットフォームはできないというようなことになります。ですので、こちらのAPIの利用料は無料にしていくのが１つ重要な要件になるのではないかなと思っています。もう一つ、先ほど瀧さんのお話もありましたとおり、みずからのデータを参照するといったところで、なぜお金を取られるのか、口座残高を照会するときにお金を取られないといったところと同様に、これによって利用料が発生するということは１つ、ユーザーにとって違うところなのではないかなと考えております。
１５ページ目、スクレイピングの安全性というところ、先ほどの話もありましたので、こちらも長く使われている技術ですといったところで、安全性については問題はないと考えておりますが、今後といったところでいきますと、中間的事業者を登録制にするといった中でやっていくのであれば、そういった事業者がスクレイピングを提供し続けるといったところでは、銀行さんが必要に応じてしっかり、この事業者であればホワイトリストにするよというような取組みをとっていけば、特に問題はないところなのかなという認識でおります。
１６ページ目になりますけれども、APIの範囲といったところで考えますと、まず登録制の仕組みを敷いて、APIで接続している業者というのは信頼されている業者であるよといったことを担保する。そして、それを世の中に認知させるというのは、１つのよい案だと考えております。ただ一方で、例えば、その登録だといっても、口座の情報を利用するだけであれば、決済をするといったところに比べるとリスクは低いよねといったところで、登録の猶予期間があるというのは、あってもよいのではないかなということを考えています。ただ、この登録要件に圧倒的な資本力を要するようなものが入って、それが前提となってしまうと、先ほどあったような新規の参入は起こらなくなりますので、そうすると、ゴールであったプラットフォームをつくっていく、エコシステムをつくっていくというところが満たされなくなるということは配慮していただきたいと思います。
そして、単に今、決済、それから情報の参照というところだけを話しておりますけれども、将来的には銀行口座の全てのサービスの指図をAPIで開放していくべきではないかなということを考えています。銀行口座の開設から、あるいは融資を実施するところ、それから口座の閉鎖をしていくところまで含めて、外部のサービスと連携して行うことで利便性が上がっていく部分はいっぱいあるのではないかなと考えておりまして、これらは単純にAPIの議論だけではなくて、銀行代理業の制度による制約も含まれておりますので、こういったもの自体の改善なのか、もしくは今回の中間的事業者の枠組みの中で、こういった銀行の代行するようなサービスを利用可能にしていくといったことも求められていくんじゃないかなと考えております。
最後に１７ページ目において、セキュリティについての考え方を述べさせていただきますけれども、セキュリティの基準。私たちもいろんな金融機関と話すたびに、セキュリティのチェックリストなんかを受けて、長い時間をかけてセキュリティ大丈夫だよということを話していくわけですけれども。ただ、セキュリティの基準は法律で定めてしまうと、そもそも提供するサービスのリスクの度合いだとか、あるいは中間的事業者、どんな業務をやろうとしているのか、それから、その時点での技術の状況によって、どんな対策が必要なのかというのは、日々刻々と変わっていくのだと考えています。ですので、これが法律にハードコーティングされてしまうということではなくて、適切に状況に応じて変わっていくべきもの、柔軟であるべきものだと捉えております。ただ、業者としても、自分たちのビジネスが何か大きな事故が起こったことによってなくなってしまう可能性があるといったことは重々認識していることでありますので、法律によって定めるというよりは、自分たちにおいて適宜、自主ガイドライン等で最適なやり方を定義していくということが、最もいいやり方なんじゃないかなと考えています。
同様に、金融機関側と中間業者と責任分担のあり方というのも非常にテーマになるところではありますけれども、こちらも同じように、提供するサービスのリスクなり事業業態によって変わってくるところではありますので、接続する銀行と中間的業者の間の個別契約で任せていくべきものではないかなと考えています。先ほど、こういった責任分担などの話で、保険に入るというような話でもあったのですけれども、こちらは実質的に、しっかりと利用者保護は担保されているといったことが重要だと考えておりますので、保険に限らず、いろんな手段をオープンにして、限定しない手段で、こちら実質が担保されればよいのではないかなと思います。
また、データの利活用範囲。どのようなデータを中間的業者が扱えるのかといったところもあるのですけれども、こちらは法律で制限するのではなくて、ユーザーとの利用規約の間で中間的事業者がセットできるというようなことにしておく。今、機械学習、人工知能によって、どんどん利便性の高いサービスが提供できるような時代になってきている中で、ここのデータ利用に制限がかかることは今後のイノベーションの阻害となり、それから国としての今後のテクノロジーの目が失われていくといったことにつながっていくと考えております。
もちろん、１８ページ目にありますが、こうやって個別の論点、議論としていくと、銀行さんと中間的業者の契約は大変になっていくのではないのかという議論点はありますけれども、こちらはどんどん業界でひな形の共有ですとか、そういったことを進めていくことによって、ある程度、松竹梅じゃないですけれども、こういった場合にはこれというのが自然形成されていくと考えています。これらは私たちも今、Fintech協会などあわせて、いろんな業界団体の活動の中で、これらを積極的に進めていこうということはコミットしていきたいと思っています。
以上になります。ご清聴ありがとうございました。
【岩原座長】
どうもありがとうございました。それでは、討議資料に沿いまして、討議を行いたいと思います。また、瀧参考人、佐々木参考人へのご質問等があれば、あわせてお願いしたいと存じます。どなたからでも結構でございますので、ご発言をお願いいたします。いかがでしょうか。福田さん、どうぞ。
【福田委員】
ありがとうございます。実際にイノベーションが進行している中で、今までのような規制一辺倒という形ではなくて、一歩踏み出す形でのご提案だと思いますし、非常に重要であるとは思います。常にこういう問題を考えるときに気にしなければいけないのは、やっぱり金融というのは特殊だという問題とのバランスを考えながら議論をしなければならないということです。例えばセキュリティの問題といって、通常であれば自己責任という問題で片づけられることは多いのですけれども、必ずしも金融の世界では、そうはいかないという難しい問題があると思います。そういう意味では、業務範囲がどこまでかということと、規制がどこまでかということは密接に関連している問題で、あまりお金を直接取り扱わないレベルでは、あまり厳しい規制は必要ないと思いますし、他方で、その射程範囲がどんどん広がっていくならば、より厳しい規制が必要だという問題は起こってくるのだろうとは思います。
また、こういう電子決済ということになると、海外との電子決済というような形も非常に広がっていく可能性は高いと思います。実際に決済のコスト、海外送金のコストは、現状非常に高いものですので、電子決済の利用価値は非常に多いはずです。そうすると、海外との整合性という問題等も議論することが必要にはなってくるのではないかとは思います。
参考人の方に唯一質問させていただきたいのが１点だけありまして、やはり、こういう問題を考えるときに、金融機関、銀行側の協力というのは絶対不可欠だとは思います。さきほどユーザー側のメリットは非常に丁寧にご説明いただきましたし、それからビジネスとしての可能性も非常に丁寧に説明していただきました。けれども、やっぱり金融機関が全面的に協力していただかないと成り立たない話だと思うので、銀行側にも非常に大きなメリットがあるという点は、こういう問題が発展するための１つの不可避な条件だと思います。その点、何かご意見があれば、できればお伺いできればと思います。
【岩原座長】
それでは、瀧さん。
【瀧参考人】
かしこまりました。私の資料でございますと、１１ページの真ん中にも述べたところではあるのですが、参照系と更新系といいますか、取引を実際に指図できるような環境になるところでは、わりとメリットの打ち出せる度合いというのは結構違うのかなと思っております。参照系のところは、ある意味、インターネットバンキングと同じようなところでございまして、インターネットバンキングで残高が見られて、すごく便利です。ただ、それに皆さん、月額３００円、５００円払いますかというと、そうでもないよねというところがありまして。やはりデータが見られるだけでは最終的にはエコノミクスではなかなか動かない。その先で、例えば銀行APIを使ってアマゾンでの支払いが行えますと。なので、通販サイトで、今までであればクレジットカードしか使えなかったところが、今後はデビット取引ができますといったところまでいくと、もうこれは明確に手数料が落ちる話でございますので、銀行さんにもメリットが見えてくるのかなと思っております。なので、よく申し上げるのは、参照系の世界というのは、ユーザー層と利便性を非常に広げていく、ある種、前段階的な色彩が結構強いわけでございまして、その過程においては、どちらかというとユーザーが利便性自体は非常に共感するところではあるのですけれども、その先のところで、ほんとうに更新系の取引が生まれ始めると、誰が見ても明確な世界観が生まれてくるのかなと、まず思っているところでございます。
ただ、私ども、そうとはいえ、例えば地方銀行様などに向けたアプリを提供したりとか、別途、私どものサービスを通じて広告的な価値とかを提供しているところもございまして、こちらは現に私どもの会社のビジネスの半分は個人向けででき上がっているところでございますので、銀行様にも価値を感じていただいているからこそ、お金を支払っていただいているみたいなところはございます。ですので、そのような組み合わせのところでお考えいただくのかなというところでございます。
【岩原座長】
佐々木さん。
【佐々木参考人】
私たちは主に中小企業向けといったところでやっているのですけれども、中小企業の対象の金融サービスといったところで、やはり１つ大きな、国全体のコストとなっているのが、オンラインバンキングが全然浸透していないというところですね。こちら、地銀さんなんかになりますと、もう十数％しかオンラインバンキングの利用率は進んでいないみたいなところというのは非常に多いのです。この問題が解決するためには、もちろん、それを単に広めていこうよという動きはあるんですけれども、インターネットバンキングを使って、そこからデータを会計ソフトなんかにつなげていくことによって会社の経理が楽になることによって、じゃあオンラインバンキングをやっていこうかというインセンティブが、またさらに広がっていくということがすごく重要なんじゃないかなと思っています。それは今のところ、銀行さんにとっては、店舗で対応すれば、それだけコストが高いわけなので、それがオンライン化、より広がっていくといったことによってコストダウンにつながるというのは１つ大きなメリットとしてあります。
もう一つ、今、銀行さんと話しているのは、freeeに入ってきた財務情報をユーザーさんが許可した場合には、銀行と共有することができるということを実施すると、今まで営業活動をする上で、相手の取引先の財務状況も把握して、リレーションも構築して、事業の特性も分析してとするには、１人の営業の方が扱える取引先の数というのは限られていたものが、こういった財務データをプラットフォームとして共有してしまうことによって、圧倒的に多くの取引先を持つことができたり、小さな取引先までカバーすることができたりするようになっていくわけです。そのようなデータソースを得られるということで、銀行口座の情報と連携したサービスがどんどん増えていくというのは、そういった銀行の営業の可能性をさらに広げていくようなポテンシャルというのもあるのではないかなと思っています。同時に、そういった、ある１カ所にデータが、外のアプリケーションにデータがあることによって、そこを使った新しい融資のサービスだとか、別のプロダクトの開発の方向性というのもありますので。単に更新系であれば、もちろん決済の話、決済のボリュームが増えるというのはあるのですけれども、参照系からも出てくるビジネスの広がりはあるのではないかなと思っております。
【岩原座長】
よろしいでしょうか。
【福田委員】
はい。
【岩原座長】
ほかに。関委員。
【関委員】
ありがとうございます。資料１につきまして幾つか質問したいのですけれども。まだ正確な理解ができていないので、細かい話で恐縮ですが、２ページ目の一番上というか、この資料の中で出てくる金融機関というのは、銀行とイコールだという認識でよろしいでしょうか。もし違っていたら教えてください。また、電子決済等代行業者についてですけれども、収納代行業者は、これに含まれないという理解をしているのですが、それで間違っていたら教えてください。収納代行業者の銀行口座を経由して送金的なことが行われているので、違うのかなとは思っているのですが、念のための確認です。
それから２点目が、そのページの（２）の最初の３つのポツについて、先ほど来の参考人のご説明を聞いていると、API化を推進していくことについては、そういう方向だろうなとは感じるものの、それは後ろのほうの提案でいくと、例えば登録制を導入して、幾つかの要件を設けるであるとか、銀行に対しては、その接続の義務化とも言えるような提案をされているので、そこまでやるほどの何か問題があるのかというのは、ちょっと理解できなくて、事務局としてどう考えているのか、この最初の３つのポツですね。例えばAPIを広く開放するに至っていないとか、金融機関が限られているとか、あるいはスクレイピングによるサービスを提供する状況になっていると。まるでスクレイピングは悪いと言っているような感じもするのですけれども、このあたりで何を問題としているのか、事務局の見解をお聞かせいただきたい。
もう１個が、３つ目ですけれども、その下の３つのポツについて、立法事実という意味で、この不正送金、セキュリティ上の問題とか、あるいは過剰な負担の可能性とか、スクレイピングによるコストといったものについての実態。先ほどの参考人のご説明を聞いていると、どうも、こういった問題が起きていないように思うのですが、何かこれを示すようなデータを事務局のほうでお持ちでしたら、お聞かせいただきたいと思います。
それから最後、４つ目ですけれども、欧州を参考にしつつ、それからアメリカのほうも見ながらということですが、米国では現状制度はないみたいですが。法制化を検討しているという話も聞きますが。米国での立法事実という意味でのトラブルの状況とかビジネスの状況について、お聞かせいただければと思います。以上です。
【岩原座長】
それでは、井上さん。
【井上信用制度参事官】
金融機関の定義でございます。もちろん銀行は念頭に置いておりますけれども、今回、決済に関するというようなことで議論をいただいておりますので、決済システムに関与する預金取扱金融機関というのはある程度念頭に置いて検討していく必要があるのではないかと考えております。
２点目のご質問ですが、いわゆる収納代行業者についてでございますけれども、収納代行業者については資金決済法の制定時のご議論で引き続き検討課題とされていたところでと承知しています。こうした課題につきましては、利用者保護の観点から制度整備を図るべきという意見がある反面、規制をかけるということは事業者のイノベーションを阻害するといった意見があるなど、さまざまな考え方があると承知しておりまして、決済業に係る情勢の変化等を踏まえつつ、今般のご議論とはちょっと別の論点として、必要に応じて検討していきたいと考えております。
次のご質問、２ページ目から３ページ目にかけてのAPI、スクレイピングに関する現状認識でございます。このあたり、もちろん先ほど両参考人からお話がございましたように、スクレイピングの技術自体が、もちろん技術的に問題があるというわけではないのだと思いますけれども、その３ページ目の上から２つ目の黒ポツで書かせていただいたように、利用者において、顧客情報の漏洩とか認証情報を悪用した不正送金等、セキュリティ上の問題が生じないかという不安がやっぱりあるということは、ご指摘があるところではないかと思います。そのあたりも含めて、ご判断いただければとは思います。
４点目です。アメリカの動向ということでございますけれども、前回少し欧米の制度を見ていく中でアメリカの動きをご紹介させていただきまして、現状において具体的な制度整備というようなご提案まではないということはご説明させていただきましたけれども、金融消費者保護局、連邦の消費者保護を担当するところでは、そのような金融情報への安全なアクセスに係る課題について調査をするという動きがございます。あとは、１２月になってからでございますけれども、OCC、連邦通貨監督庁も、FinTech業者向けの新しい銀行免許についての提案というのを公表しておられると承知しておりますので、議論としては引き続き行われていると考えております。
【関委員】
アメリカは何を課題認識しているのでしょう。
【井上信用制度参事官】
アメリカは、これも報道ベースの把握でございますけれども、１つはスクレイピングに関して、銀行界のほうで顧客情報にアクセスしているということは、銀行システムの安定性や利用者保護に懸念があるのではないかという指摘や、スクレイピングによらないサービス提供に向けた環境整備が必要ではないかというようなご指摘もあると承知しております。
【岩原座長】
それでは、翁委員。
【翁委員】
私も質問ですけれども、こちらの討議資料につきまして、お尋ねしたいのです。前提となる情報として、オープンAPIを今、銀行が体制整備をしていると思うのですけれども、現状、大体どのぐらいのところが、どのぐらいの数というか、が、その体制整備に対して用意ができていて、それで一定期間の間に努めるという記述が４ページのところにもございますが、大体それはイメージとして、どのぐらいのことをイメージして議論をすればいいのかということをお伺いしたいのと、それから先ほどコストのお話もあったんですけれども、銀行がそのオープンAPIの体制整備をするためのコストというのは、大体どういう規模の金額をイメージして議論していけばいいかと。そのあたりのところについて、おわかりになる情報を教えていただければと思います。
【岩原座長】
井上さん。
【井上信用制度参事官】
銀行の対応ですので、私どもでヒアリングした結果、お知らせできることをお話しさせていただいて、もし補足があれば、田村委員からお願いしたいと思います。私どもが、国内の地方銀行も含めましてお伺いしたところ、大体８０％ぐらいを超える銀行でシステム上、オープンAPIに対応済み、または技術的に容易に対応可能であると伺っています。 期間的なところは、もちろん全て銀行ということですと、あるいは金融機関ということですと、何年というところまで、確たることは今申し上げられないのですけれども、技術的には２年ないし３年あれば対応できるのではないかというようなご回答をいただいています。 コスト面も、これは、いわゆる参照系のみなのか、あるいは勘定、更新系にまで及ぶのかということで大きく変わってくると承知しておりますけれども、仮にベンダーのネットワークシステムで対応して、口座情報の照会等に限るのであれば、１００万円程度のコストでできると、仮に勘定系、そのシステムを刷新するという場合ですと、数千万から数億円程度と伺っております。
【岩原座長】
翁さん、よろしいですか。
【翁委員】
はい。
【岩原座長】
それでは次、田村委員、お願いします。
【田村委員】
ありがとうございます。先ほどの井上参事官のご説明に特段の補足はありませんが、コストについては、APIの機能をどこまで提供するのか等によっても大きく変わってくると認識しております。前回の会合で、私から全銀協のオープンAPI検討会についてご説明させていただきましたが、その際にも申し上げましたとおり、オープンAPIは、オープン・イノベーションを実現するための重要な取組みの１つだと私どもとしても考えております。
第２回の事務局説明資料に、現行の法制度に必ずしも適合する枠組みがないことが、銀行との連携・協働等の妨げとなるといったような意見がFinTechサポートデスクにも寄せられているというお話がございました。 確かにそういう面もあるのかなと思っております。現在、多くのFinTech事業者と銀行がオープンAPIの活用可能性を検討しておりまして、このタイミングで、我が国の状況を踏まえた制度整備が行われれば、民間の動きの後押しになるだろうと思います。
他方、このイノベーションに向けた戦略は、銀行によって区々ということもございます。この事務局資料の４ページのところに、オープンAPIの導入に関する方針、あるいは判断の基準ということが書かれておりますが、先ほど申し上げた戦略が各行で区々ということを踏まえて、各金融機関が主体的に定められるような仕組みとし、FinTech企業との創意工夫を凝らした連携・協働に資するような枠組みとしておくことが重要だと考えております。例として申し上げますと、銀行の中には都市銀行もあれば地域金融機関もあり、また新しいタイプの銀行もございます。それぞれのビジネスモデルに応じて、特色のある方針や基準を定め、オープン・イノベーションに取組んでいく、そういう方針を定めていくことがオープン・イノベーション促進のエンジンにもなるのではないかと考えております。
それから、先ほどマネーフォワードさんとfreeeさんから、いろいろなご説明ありがとうございました。その中で接続手数料の話が出ておりました。オープンAPIは、実際につなごうということを、今まさに各銀行が検討している段階ですので、まだあまりきめ細かな設計にはなっていない部分があるのかもしれませんが、通常の銀行取引一般について申し上げますと、もちろん銀行にもよりますが、スタートアップの企業さん向けに成長を支援するさまざまなパッケージや料金プランを用意していたり、あるいは個別に条件面について相談に応じているといったこともございます。したがって、APIについても、各銀行がFinTech企業さんと打ち合わせながら対応していく必要があるのだろうということかと思います。
全銀協でオープンAPIを検討しておりますが、この手数料について統一的な目線を定めることはなかなか難しい面もございますので、あくまで個人的な意見として申し上げれば、ある意味で、銀行も、先ほどマネーフォワードさんの資料の最初のほうにあったように、これから変わっていかなければいけない、それは痛切に感じておりまして、新しいアイデアやサービスをお持ちのベンチャー企業さんとは、銀行としても提携してオープン・イノベーションを進めていきたいと考えているところが多いかと思います。そのときに手数料がネックとなって、この銀行とは組まないというFinTechベンチャーさんが生じることは、銀行にとってもマイナスになる面はあると思います。
したがって、どのようなビジネスをやっていくのかについてFinTech企業さんと銀行が密にディスカッションして、Win-Win-Winの関係、つまり、利用者、FinTech事業者、銀行の３つのWinの関係が目指せればと個人的には考えております。
【岩原座長】
それでは永沢委員、どうぞ。
【永沢委員】
ありがとうございます。事務局でご用意いただいた資料１の前に、瀧様に質問させていただきたいことがございまして、その後で、瀧様にお答えいただいた後で、こちらの資料１について意見なり質問をさせていただきたいと思いますが、よろしいでしょうか。
【岩原座長】
どうぞ。
【永沢委員】
まず瀧様に質問させていただきたいのですが、スクレイピングにつきまして、技術上の問題はないというお話を伺いました。わからないから納得も何もなく、ああ、そういうものなのかと思ったのですが。１つ質問させていただきたいのは、事務局でご用意いただいた資料１の３の上から２番目の黒い丸印のところにかかわるところでございますが、利用者がサービスの利用に当たり銀行口座に関するパスワードといった重要な認証情報を業者に与えることによるビジネス上のリスクというのは、あると理解してよろしいのでしょうか。そこを、まず１つお伺いしたいと思います。
それからもう１点、この資料に直接関係することではないのですが、瀧様の資料の中の１１ページで、手数料収入が更新系APIであれば生まれるというお話だったのですが、これは全く今までどこにも発生していなかったものが生まれるのか、それとも、ほかに落ちていた手数料収入がこちらに移るという理解でいいのでしょうか。２点をお伺いしたいと思います。
【岩原座長】
瀧さん。
【瀧参考人】
かしこまりました。まず１点目の、この討議資料３ページの２ポツ目のところだと思うのですけれども。ビジネスリスクが全くないものは世の中には、一般論から言うと存在しないというのはあるのですけれども。これまで１６、１７年間、世界のいろいろなところでスクレイピングを活用したサービスは存在してきて、アメリカと日本においても、いろいろな口座データを引き込むサービスというのはあったわけなのですけれども、その範囲においては特に今まで発生した事故はなかったというのが私の認識でございます。そのことをもって、もちろんリスクがないという話ではございませんし、個別の事業者がサイバーアタックに遭いました、あるいは内部犯行がありましたというシナリオは、これはある種、金融の枠を離れて、通常のデータを預かる会社として、セキュリティリスクは常にございますので、それをいかにマネージしていくかというのが、ある種、近代のIT企業というか、当たり前のようにIT企業がやらなければいけないことであるわけでございます。
個別の企業の中では、やはり、そこで何か非常に、いとも怪しいような会社というのは長らく、そういったデータを集め続けることは当然できませんので、例えば世の中に存在している個人情報保護のPマークでありますとか、あるいはISOの定めるような認証によって、内部管理体制を外部にも示していくわけです。ほんとうにサイバーアタックを受けた場合であっても、流れ出るデータに価値がないようにするとか、さまざまなレイヤーで、これはある種、リスクを減らしていくという努力が個別企業に求められているものでございますし、当然ユーザーさんも何も考えず使っているわけではございませんので、そこは、やはり広くユーザーさんの期待値に応えていくという範疇の中で不断の努力がされているものだという認識でございます。
ただし、当然ではあるのですけれども、ITとパスワードというのは、ある種、流出してしまいますと、住所の書いてある鍵のようなものでございまして、鍵をあけてしまうことができます。鍵を変えるまで、つまり、パスワードを変えるまではあけてしまうことができます。この世界観というのは当然、API化をすることで、ある人しか使えない鍵とすることができてまいりますので、そこは業界を挙げても、API化に向けた動きを後押ししていくところではございますというのが１点目のお答えになります。もし不足しておりましたら、後ほどご指摘ください。
２点目のところで、更新系の話というのがございますけれども、これは２つ、両方あるのかなと思っておりまして、経済学で言うところの代替効果である、何かほかの取引をとってくるものではないかというところは当然に発生し得ます。例えば今までであれば現金で取引されてきたもの、もしくはクレジットカードで取引されてきたもの、電子マネーで取引されてきたもの、こういったものが銀行における振り込みに代替されるような形というのは当然ございますし、おそらく通販サイト等々でも、そういったオプションがつくられるのかなというのは１つでございます。ただ、よくFinTechもしくはキャッシュレス化経済の中で言われますのは、やはり目の前に、より有益な情報があって、すぐにそれが経済取引につながりやすい環境があると。すると、そこには常に需要創出の側面というのがありますので、そこを経由した新しい付加価値が生まれるというのはあろうかと思っておりますし、やはり、そういった環境を用意することで、人間がより自分が欲しいものを制約なく行動できるという非常に普遍的な価値はあろうかと思っております。ですので、その足し算で見ると増えますというのが、お答えになるのかなと思っております。
【永沢委員】
ありがとうございました。続いて、今お答えいただきましたことを踏まえまして、資料１について意見を述べさせていただきたいと思います。
一般的に消費者、私たちは銀行口座に関するパスワードは大変重要なものだから他人に渡してはいけないと通常教わってきていたのに、結構便利だからといって、いろんな方がパスワードを他人に渡していらっしゃるという現状には、正直言って驚いております。現在、このようなサービスがスクレイピングという技術を使って事故なく運営されているのは、関係者の方々の真摯に、非常に大きなエネルギーとコストをかけて対応されているからであろうということも理解したつもりです。
午前中、銀行協会の、オープンAPIに関する検討会にも参加してきました。そこでわからないながら、いろいろお話を伺う中で、今まで事故が起きた起きないは別にして、やはり利用者自身がパスワードという重要な情報を自分で守るという意味でも、スクレイピングよりはオープンAPIのほうが望ましい形態であり、オープンAPIを推し進めていかなくてはいけないという理解に至りました。そして、オープンAPIを推進していくためには、銀行サイドが全面的に協力が必要不可欠であり、そのためにも、中間的事業者に登録制を導入することが必要だと考えます。登録制というと、なかなかハードルが高そうに見えますけれども、それは金融庁の方で工夫をいただく必要があると思います。
最後に、資料１のページ３のところで、こうした状況についてどのように考えるべきかというところですが、利用者に不安が生じていることがないかという問題提起には違和感があります。（利用者トラブルが顕在化していない現段階では）スクレイピングでいいじゃないかと思われる方があるのではないかと私は気にしておりまして、ここは、業に携われる方々がカンファタブルなのがオープンAPIであると書いていただいた方が良いのではないかと思いました、以上でございます。
【岩原座長】
はい。何か井上さんからありますか。いいですか。
【井上信用制度参事官】
はい。大丈夫です。
【岩原座長】
ほかにいかがでしょうか。加毛委員、どうぞ。
【加毛委員】
ありがとうございます。まず、本日の討議資料で提案された内容と、お二人の参考人がおっしゃった今後の中間的業者のビジネスモデルの関係と申しますか、齟齬のようなものについてうかがいたいと思います。
討議資料の１ページでは、電子決済等代行業者が、ITを活用した決済指図の伝達や金融機関における口座情報の取得・顧客への提供を業として行う者と定義されており、決済指図の伝達や口座情報の取得・顧客への提供という行為を切り出して規制の対象にすることが検討されています。他方で、瀧参考人は資料の３ページのあたりでおっしゃったと思いますし、佐々木参考人は資料の１６ページで非常に詳細にまとめてくださったわけですが、中間的業者の今後のビジネスについて、融資や口座開設などを含めた複合的なサービスの提供という発展の方向性が示されています。これらのサービスを行うとすれば、現在の制度の下では銀行代理業として規制の対象になると思いますが、そうだすると、電子決済等代行業者という形で切り出して規制対象を議論することの意味がどのくらいあるのかという疑問も生じます。また、電子決済等代行業者に関する規定と銀行代理業の規制の関係や、区別の根拠が問題になると思います。
さらに、今日の参考人お二人のご報告は、銀行代理業の規制の見直しにまで踏み込んでいらしたかと思いますけれども、その点について事務局はどのようにお考えなのかということを伺えればと思います。
【岩原座長】
井上さん。
【井上信用制度参事官】
今の加毛委員のご質問に対しては、２回目のご議論の際、中間的業者の取扱いというときに、分類として、銀行からの委託を受けて業務を行う方と顧客の委託を受けて業務を行う方にまず分けた上で、それと決済に関する方と、それ以外、預金、融資に関する方と分けて議論させていただきたいというご提示を差し上げました。その中で決済に関する業務というのは、現時点でも、かなりサービスとして進んでいるというような実情も踏まえた上で、まず、こちらのことを議論させていただきたいということで、今回、議論の枠組みを設定させていただいたところでございます。 将来にわたって、預金、融資のところについて、どのようなシステムが必要かという議論は当然あり得るものだとは思っていますけれども、現状の整理としては、そういうことでございます。
それと、その結果として、銀行代理業者との関係がどのような整理になるのかというようなご指摘かと思います。これについては、おっしゃるとおり、銀行代理業のほうが決済だけではなくて預金、融資もカバーしていて、今回ご議論いただくのが決済を中心にということですので、少しミスマッチが生じるところはあり得るかと思います。それにつきまして第１回のご審議でも、銀行代理業の規制内容については、そもそも銀行代理業者及び銀行の双方にとって過剰規制となりオープン・イノベーションの妨げとなりかねないというご議論をいただいたと思いますけれども、その中で、仮に中間的業者に対する法制を導入するとした場合に、こうした点について、この中間的業者にルールを設けているかということを検討していくことは必要になってくるのだと思っています。銀行代理業規制と対象の明確化ということもあわせて、そうした問題につきましては、できれば次回のご審議の際にも少しご議論いただきたいと思っています。
【岩原座長】
加毛さん、よろしいですか。どうぞ。
【加毛委員】
ありがとうございます。顧客の委託か銀行の委託かという区別につきましても、今回のご提案によれば、電子決済等代行業者は銀行と契約を締結することが前提となっておりますので、両者の区別が相対化しているところがあるような気も致します。そのような観点からも、銀行代理業の規制と電子決済等代行業者の規制の関係は今後も問題になるだろうということを申し上げたいと思います。
違う質問を差し上げてもよろしいでしょうか。
【岩原座長】
どうぞ。
【加毛委員】
ありがとうございます。討議資料の４ページの下のところにある損失分担のルールの問題、あるいは５ページの下から２つ目の白丸にある決済指図の伝達を行う業者とそれ以外の業者で何が違うのかという問題にかかわる質問です。今回のご提案では、金融機関と電子決済等代行業者との契約締結が前提とされています。そうであるとすれば、非常に乱暴な言い方ですが、プロ同士の関係であり、両者の間の損失分担は当事者の合意・個別の契約に委ねてもよいのではないかと考えられるところです。
これに対して問題として残るのは顧客の保護であるといえます。電子決済等代行業者が広く社会に浸透し、誰もが普通に利用するということになりますと、顧客にとっては、金融機関とインターネット・バンキングなどで直接取引をした場合と、電子決済等代行業者を介して金融機関と取引をした場合とを区別する合理的な根拠はあるのだろうかという疑問が生じるように思われます。顧客から見れば、電子決済等代行業者は金融機関側の存在であると感じられる状況になるかもしれません。そうだとしますと、電子決済等代行業者を利用したからといって、顧客の保護が切り下げられる理由はないように思われます。無権限取引につきましては、このワーキング・グループでも既にご紹介があったとおり、全銀協の申し合わせがあります。電子決済等代行業者を利用した場合にも、顧客に同等の保護を与えるべきではないかと思います。また参考人のお話にもありましたが、決済指図の誤伝達の問題があります。これには幾つかの問題のパターンがあると思いますが、例えば顧客は適切に電子決済等代行業者に対して指図を行ったにもかかわらず、何らかのトラブルでその指図が金融機関等に伝達されずに、間違った取引がなされてしまった場合には、誤振込みのように扱われるのか、それとも金融機関側のオペレーションのミスによって適切な取引がなされなかったという扱いとするのかが問題となります。先ほどの議論との関係では、後者のような扱いをすることに一定の合理性があるように思われるところです。これは法制化の検討対象ではないのかもしれませんが、今後、金融機関と電子決済等代行業者が契約の内容を交渉する際には、どのような損失を自分たちで引き受けなければならないのかが確定している必要があるように思われます。そのあたりにつきまして、お考えをお聞かせいただければと思います。
【岩原座長】
井上さん。
【井上信用制度参事官】
ご指摘の点は、４ページの下から５ページにかけての（注）に関係するところだと考えております。ご提案では４ページの一番下の黒丸にございますように、中間的業者と銀行との間の損失分担ルールについては、法制度上は両者の契約により規定してもらうということを想定しています。他方、顧客と銀行との間の損失分担ルールについては、加毛委員ご指摘のとおり、現状は私法上のルールは確立されていない。インターネットバンキングの場合は全銀協に申し合わせという形で扱われていることを踏まえますと、現段階において法制度上それを規定することは難しいのではないかと考えて、その旨を（注）に書かせていただいております。
ただ、ここについては、その（注）の後半にございますように、関係者の申し合わせによる取組み等が検討されるべきではないかと考えておりまして、今、加毛委員のご指摘のような点も含めて、ご検討されることが必要と考えております。
【岩原座長】
加毛さん、よろしいですか。それでは関委員。その後、田村さん。
【関委員】
ありがとうございます。コメントを幾つかと、簡単な質問をしたいと思います。
まず今までの参考人のご説明等を聞いていると、立法事実という意味で、トラブルが現実に起こっているという状況にはないようにも思いましたので、制度として何か考えるのであれば、規制的なものではなくて、オープンAPIを促進するような、インセンティブを与えるような制度にしていくほうが望ましいのではないかと思います。そういう意味で、登録制の導入がいいのかどうか、ちょっと私にもわからないのですが、仮に導入したとしても、例えばベンチャー企業が参入しづらくなるとかといったことには配慮すべきだと思っていまして、その登録の要件については十分考慮すべきかなと思います。例えば財務要件は本当に必要なのかということであるとか、あるいは決済指図をする事業者と、そうでない事業者について、リスクは相当違うと思いますので、その間の制度上の差というのは十分考えるべきかなと思います。
それから、４ページ目の下から２つ目のポツで、一定条件のもとで、金融機関が原則として契約を締結するということに書いてあるのですけれども、基本的に民―民でビジネス的に判断をするというのがビジネスの原理原則かなと思いますので、安易に、こういった形で接続の義務化とも言えるような制度というのは、どうかなと思っております。
それから、もう１点。先ほど米国のお話もしましたけれども、拙速に何か決めてしまうというよりは、米国の検討状況等も踏まえて、日本でどういう制度を導入するかということは考えていくほうがいいのではないかと思います。
それから質問が１点でございまして、金融機関と、例えばここの資料で言うと、登録事業者が接続した場合に、このデータの管理責任がどちらにあるのかというのが、よくわからなかったので質問です。例えば中間業者のほうでデータの漏洩があった場合、そこの中間業者の責任になるのか、あるいは金融機関も何らかの責任を負わされることになるのか。そのあたりも見解があれば、お聞かせいただければと思います。以上です。
【岩原座長】
井上さん。
【井上信用制度参事官】
まず、ご質問にお答えする前に、ご意見に関して少しコメントさせていただきたいと思いますけれども、１つ目のご意見のところでも、オープンAPIを促進する制度であるべきというところについては、事務局としても、前半で述べさせていただいたように、そういう観点は非常に重要だと認識しております。その点で、ベンチャー企業にとって参入しづらくならないようにというご指摘も、非常にごもっともだと思っておりまして、４ページ目の１つ目の丸で登録制ということはご提案させてはいただいて、業者が顧客から資金を預かることがないことに留意しつつと書かせていただいております。顧客から資金を預かる資金移動業者の登録要件と比べて、そこまでのものは求めなくてもいいのではないかというような１つの目安になるのではないかということを念頭に置いて、このような表現にさせていただいているところでございます。その上で、データの管理責任がどちらにあるかということですけれども、それぞれの銀行ないしあるいは中間的業者側でも、個人情報保護法等の適応はあると理解していますので、それぞれに管理責任があるとは理解しております。その上で、今回の場合は銀行と中間的業者との関係は委託関係というものではない。契約関係ということではございますので、どちらかに、委託元から委託先に対する管理責任というような構成ではないとは理解しておりますけれども、その上で、損失分担については、先ほど申し上げましたように、契約関係において定めていただくのが適当ではないかと考えております。
【岩原座長】
田村委員、続いてお願いします。
【田村委員】
ありがとうございます。１つ前の加毛委員のおっしゃられたことに関しまして、少し全銀協の検討会の検討状況についてご説明をさせていただければと思います。
利用者保護をしっかりと図り、オープンAPIに対する利用者の信頼を確保することはオープンAPIが普及していく大前提であり、その中でもお客様に生じた損失の分担についてはご指摘の通り、非常に重要な論点だと考えております。特に、オープンAPIでは、中間的業者と銀行が取引に関与することになりますので、損失が発生した場合に、責任の所在や対応窓口などが不明確になる可能性があります。したがいまして、現在、全銀協では、まだ検討いただいている段階ではございますが、そのルール案では、まず、その都度個別に判断するのではなくて、お客様に対して速やかな補償が行われるよう、あらかじめ中間的業者と金融機関の間で契約などによって、お客様に対する補償や返金方法、あるいは対応窓口をしっかりと定めておくとともに、お客様にそれを十分認識できるような形で表示しておくこと、また、API接続先が補償や返金資力に乏しく利用者保護に欠けるおそれがあると判断した場合には、責任保険への加入や責任財産の充実を求めるといった規律づけも検討しております。
それから補償範囲につきましては、これは今後の検討事項と考えておりますが、オープンAPIで接続する場合には、さまざまな形態があると思います。例えば中間的業者から銀行に送金指図データが送信されて、インターネットバンキングと同様に承認処理をとるという形をとれば、先ほどのご指摘のとおり、インターネットバンキングと同一の補償範囲とすることも考えられると思います。一方で、オープンAPIを活用したサービスには、例えば社内のイントラネットなどで従業員が経費精算するような仕組みや、あるいはインターネットを通じた取引だけではなくて、お客様がお持ちの電子マネーに自動的にチャージするような仕組みなど、いろいろなものが考えられます。したがって、しっかりと補償範囲やリスクに関する説明、表示を行うといった取組みも併用することも含めて、お客様に不測の損害が生じないような枠組みを、検討会では、FinTech事業者さんなどにも入っていただいて、検討していく必要があると思っております。
いずれにしても、銀行としましては、銀行のお客様ですので、大切なお客様の資産、その情報を預かって業務を行っていますので、しっかりと利用者保護を図り、オープンAPIに対してお客様の信頼が得られるように、関係者のご意見を聞きながらルールづくりをしっかりと進めていきたいと考えております。
【岩原座長】
それでは、佐々木参考人。
【佐々木参考人】
先ほど何度かスクレイピングについてコメントが出ていたので、それにコメントさせていただきますと、まず、利用者にとってのスクレイピングとオープンAPIのメリットは何なのかというと、先ほどお話あったように、ID、パスワードを預けることに対する抵抗感というのは、もちろんない方もいますし、ある方も、やっぱりいらっしゃいます。これは１つ、今後こういったFinTechサービスが広がっていくことに対してキャップにはなることではあるというので、オープンAPIに移行することは基本的にいいことだと考えているのが１つ。
もう一つは、スクレイピングによって利用者に提供できるサービスの質には限界があります。なぜかというと、スクレイピングという技術は、一般のユーザーさんがウェブサイトにアクセスするような形で情報を取得するという仕組みなので、銀行側のウェブサイトに変更があると、スクレイピングしている事業者側は、それを捕捉してソフトウエアを更新するという作業が必要になるんです。この間、正しく情報が取得できなかったということが起こり得、利用者側から見れば、何で今情報を取得できないのというようなことが、それなりに発生します。この限界を、オープンAPIによって超えることができるので、サービスのクオリティーとしてもアップしていくというところがあります。
今度、事業者側から見ると、このスクレイピングというのは、銀行さんのサイトの変更に対応する変更が必要ということになりますので、実は、非常に参入コストが高いです。これをきちんと運用するということができない限りは、新しい事業者の参入がなかなかできないといったところになりますので、ここをオープンAPI化することによって、もちろん新規参入の促進にもつながるし、利用者側の得られるサービスの質は、それだけで上がります。
ただし、オープン・イノベーションというところを実現する上では、もちろんAPIの仕様だとかがしっかりしていないと、ほんとうはスクレイピングよりも圧倒的にAPIのほうがコストが下がるはずだったのに落ちないということが起こり得るので、それは避けたいというのが私たち事業者からの意見なのかなと思っています。
【岩原座長】
それでは古閑さん、お願いします。
【古閑委員】
今回ご提案いただいたような制度整備が必要なのかどうかというのを考えるときに、今日、参考人の方にもいろいろお話をお伺いしまして、直ちに、その立法事実に当たるようなことがあるのかどうかは、よくわからなかったなというところです。ただ、いずれにしろ、法制度を求める声が事業者の中からも一部上がっているといった理由により、法制度化を進めようかという議論になっているのかと思います。では、その法制度を求める理由は何なのか。これも多分、事業者によって理由はいろいろなのかと思うのですけれども、先ほど来、ちょっと話に出ている銀行代理業との関係もあるのかと思います。何をやると銀行代理業に当たってしまうのかとか、その辺の判断がなかなか難しいというところで、こういった制度ができて、その登録を受ければ、銀行代理業に関するそういった部分が解消されるのではないかとか、そういった期待もあるのかなと、お聞きしているところでもあります。次回その辺の議論もあるということで安心しているのですけれども、この制度を使って登録をしたからといって、じゃあ銀行代理業の問題が生じないのかどうかというのは、おそらく別物なのだろうと理解をしていますので、その前提で、どういう制度が今般求められるのかというところは見ていかないといけないのだろうなと思っています。
制度整備を進めるということであれば、今回ご提案いただいた、その資料１において、ちょっと注意が必要かなと思っているところについて３点お話をさせていただきます。
１つは、規制の対象となる業者の範囲について適切な範囲、かつ、それを明確にしておくというのが必要であろうと思っています。なかなか将来を予測して、どの範囲でということを確定するのは難しい作業ではありますけれども、ただ、そこがある程度ないと、何が規制対象になるのかとかということがよくわからなくなってしまって、またそこでビジネスに躊躇が生じるということになると、かえってオープン・イノベーションの妨げになると思いますので。その将来の予測性とのトレードオフになる部分もあると思いますけれども、そこは慎重に議論をしていく必要があるのかなと思っています。それから以前、金融庁さんからご提示いただいた資料の中で、中間的業者の例というのが幾つか挙がっていたと思います。その中に口座振替代行サービスみたいなものも挙げられていて、中には古くから行われている態様と同様のものがあり、そこのところまで登録がということだと混乱が出てしまうと思うので、そこのご配慮はいただきたいというところです。
それから２番目として、今回検討しているのはオープン・イノベーションの促進ということを目的にしているところですので、そうだとすると、登録要件が過度な負担にならないようにというのは十分注意していく必要があると思います。既存の制度においても、何らかの登録をしなければいけないとかという場面がありますけれども、やっぱり非常に時間がかかってしまうという現実があります。それから、登録要件として明確に定められていないのだけれども、その点について説明を求められて資料を作成したりであるとか、場合によっては、システム変更が求められたりとかということもあります。ここで議論しているときには、適切なものをつくったとしても、その後の運用で厳しいものになってしまわないかというところも同時に注意が必要になってくるところだと思っていますので、そこも含めて配慮がなされるような形で進められるといいなと思います。
それから３点目です。先ほど来何人かの委員もご発言されていたところかと思いますけれども、金融機関に接続を合理的な理由なく拒否しないようにということが書かれていますけれども、契約締結自体は本来自由なものであって、どういうところと組んでやるのかというところも、金融機関側の差別化につながり得るところでもあると思いますので、この合理的理由の有無について自主性を尊重した形で運用がなされるべきではないかとも思いました。以上です。
【岩原座長】
それでは松井委員。
【松井委員】
すみません、ありがとうございます。これまでご議論いただいたことと重なるかとも思うのですけれども、１点確認をさせていただきたいことがございます。
基本的な今回のご提案の方向性に私は異存ないのですけれども、今回の提案の前提となっている認識というのが、おそらく３ページのこの事務局の資料にあるのだと思います。これ、繰り返し確認をされている事項で、電子決済等代行業者のあり方によって顧客の保護の状況に影響を与えるだろう。では、そのために、どういう枠組みがあるのかというのが、ここの問題認識なのだと思います。もしそういう認識なのだとすると、通常、制度的な提案とかをする場合には、その業者のありようをターゲットにして規制を加えていくというのが一番シンプルなのだと思います。業者の規制を加えるであるとか、業者に行為規制を課すとか、そういう形になるんだろうと。そこで４ページを拝見しますと、この登録制のところに少し業者規制の話が出ているのですけれども、後半は、例えば金融機関において契約締結の可否に係る判断の基準を策定・公表せよでありますとか、その前提となっているオープンAPIの導入に関する方針を公表するでありますとか、顧客との損失分担の方針を公表するでありますとか、これ全て金融機関が名宛人になっているのですね。そうすると、中間的業者が参入し、そこでの行動を適切にするために、金融機関を名宛人とする。要するに、直接のターゲットではない金融機関が名宛人となるようなご提案が幾つか出ている。これは非常に興味深いことだと私は見ています。そうだとしますと、なぜ今回、中間的業者のことをターゲットにした議論をしているにもかかわらず、金融機関にさまざまな要請が出ているのか。ここにはいろいろな配慮があるのだろうと推察するのですけれども。そのあたりの考え方を、これまでの議論でもいろいろ出ていますけれども、改めてお伺いできればと思って発言させていただきました。よろしくお願いいたします。
【岩原座長】
井上さん。
【井上信用制度参事官】
今回のご議論の中の事務局の１つのモデルとしてご提示させていただいたものというのは、少し大胆な言い方をさせていただければ、従来の金融規制の利用者保護を中心としたあり方だけではなくて、この資料の前半にございますように、オープン・イノベーションを促進するという観点も十分に勘案して、このようなご提案をさせていただいているところでございます。そういう意味からしますと、前半でご覧いただいたように、中間的業者のパートナーになります金融機関のほうにおいても、ある程度ご努力いただきたい点は、このオープン・イノベーションを協働で進めていくという観点からは考え得る政策のオプションではないかと考えておりまして、そういうことも加味いたしまして、金融機関に過剰な負担にならない範囲で、ご協力いただくということも含めて、ご提案を差し上げたところでございます。
【岩原座長】
よろしいですか。じゃあ、舩津委員、お願いします。
【舩津委員】
ありがとうございます。参考人お二方からのお話を聞いておりまして、討議資料の今回の議論の範囲についてお聞きしたいと思いました。とりわけ参照系と更新系という形で、おそらく別々の規制というか、別に考える可能性があるということだと思いますし、討議資料の４ページでも、そういう趣旨で書かれているところもあるかと思います。
ただ、この場合の更新系とか参照系の意味なのですが、例えば決済指図の伝達をするか、しないか。それから、それは決済指図の伝達はしないのだけれども、口座情報の取得をするか、しないかということで、一応区分をされているように思われるわけですが、この場合の前工程とか後工程をどこまで含むのかなということが気になっております。
といいますのも、先ほど参考人お二方のお話を聞いておりますと、今後のビジネスモデルのあり方として、例えば、自動的に払い込みをするようなプログラムを組むのだということであるとすれば、どの段階が決済指図なのかがわからなくなるのではないかという気がしております。要するに、ここで議論をするのは、例えば業務管理体制の整備といった場合に、前工程を含めて、ビジネスモデル特定のものというか、今後ありそうなものを想定して議論をするという話になるのかどうかというあたりでございます。例えばAISPといいますか、参照系の場合であっても、家計診断であるとか提案というようなことをするという付加価値をつけるとすると、おそらく、それは口座情報の取得だけではなくて、何か、今のはやりで言いますと、フィデューシャリーのような関係が出てくるということになると、そういった人たちに、そういったことをするのにふさわしい人的構成であるとかといったところまで踏まえて、登録要件だとかを考えなければいけないのかなという気がしておりまして、そのあたり、どのように考えたらいいのかお聞かせいただければと思います。
【岩原座長】
井上さん。
【井上信用制度参事官】
基本は決済指図の伝達がどういう概念かということ、法律に落とした場合に、どういう概念になるかということにもかかわってくると思いますけれども、基本的には銀行との間の為替取引を内容とする契約の申込みの意思表示を伝達するというのが、銀行法に照らしたときの１つの考え方ではないかと思います。その上で、舩津委員が前工程とおっしゃるものがどの範囲のものかというのは非常に難しいところでございますけれども、それに付随する業務ないし、この場合、特に他業を禁止するような規制が必要だとは思われませんので、他業という形で整理されるということかもしれませんけれども、その関連のことがどちらに当たるかによっては、確かに審査要件に関連する可能性はあるとは思っています。
【岩原座長】
よろしいですか。翁委員、どうぞ。
【翁委員】
私も、この考え方につきまして、今日、瀧参考人と佐々木参考人、実際に事業をなさっている方のお声を伺うことができて大変参考になったと思っています。それを踏まえて、登録制というやり方で一定の枠組みを用意していくというようなこととか、それからルールではなく。ルールというか、オープン・イノベーションを促すために公表という形で基準を出すというようなこと。ここはもちろん合理的な理由なく拒否しないということが前提の上で、自主性とかビジネスモデルを前提とした形での基準を策定して公表するという考え方については、基本的に、よりオープンAPIを広げていくという方向に作用するとすれば、よい方向ではないかなと思っております。
ただ、やはり、これらは運用によって非常に厳しくなったりもする懸念もございますので、先ほどからご指摘があったような財務要件のところとか、それからどういった締結の可否に係る判断の基準にするのかとか、こういったところがどういうふうになるかということに、かなりかかってくるところもあるかなと思いますので、そこは、やはり、こういったオープン・イノベーションを広げていくという大きな方向に沿ったような形で実現していくことが必要かなと思っております。
【岩原座長】
ほかに何かございますでしょうか。與口委員。
【與口委員】
お時間も来ているようですので、ご質問を１点だけさせていただければと思います。今日の議論でスクレイピングの技術的な安全性の問題よりも、むしろ我々からすると、消費者の方が、いわゆる金融機関等に無断で、本来第三者に提供してはならないパスワードであるとか、そういったものを提供することによって、正規なアクセスでログインしてくるということが非常に、問題であり気持ちが悪いと言ったら変な言い方ですけれども、ちょっとおかしいと感じるところではないかなと思っています。
ただ一方で、どの程度、規制が必要なのかということについては、確かにいろんな議論があるのだろうと思います。そこで、１点、参考人の方にお尋ねしたいのですけれども。先ほど意見の中で自主規制的なもので対応することも考えられるのではないかというお話があったと思うのですが、いわゆる自主規制の団体のようなものを既にお持ちなのか。そこで既に自主ルール的なものが存在するのか。もし現時点で自主規制等がないとしたら、今後どういうものを存在させていこうと考えているのか。その際、どういうリスクに対して、自主的に規制していこうとしているのかということを、もし、もうお考えになっていれば教えていただければと思います。
【瀧参考人】
かしこまりました。私の資料の１３ページにございますけれども。まず結論から申し上げると、今の時点で何か動きとか団体があるわけではございませんでして、またFinTech協会とかFinovatorsといったFinTech産業を代表するような業界団体というのは存在しているのですけれども、こと、この中間的業者規制に向けて枠組みがある団体というわけではございませんので。例えばFinTech協会の中ではセキュリティの、自分たちで今後批准していこうと思う基準をつくっているさなかではあるのですけれども、こちらに批准すればAISPとして大丈夫とか、そういった目的性を帯びたものではないので、そこは現時点ではないというのが、まずお答えになります。
その上で、非常にある種、ちゃんとコストをかけられるケースというのは、イギリスのOpen Banking Standardに述べられている、この１３ページの３点目の３つ目のバーがあるところですけれども、基本的に１つはデータ活用に関する苦情受付の窓口が必要でしょうという点。もう一つは、APIを使う会社側のセキュリティスタンダードを決めようという点。３つ目が、API自体の仕様と一般的に言われるものですけれども、あり方について、これが非常に短期であり方が変わっていくものですので、メンテナンスをする点というところが１つは、理想像としては求められていくところというのは１つございます。また②のセキュリティを担保できる会社について、自分たちの間でスタンダードをつくって、それに批准できるホワイトリストをつくりましょうというのがOBSにおける１つの考え方でございますが、これも彼らの中での提言という形でございまして、現状、実際に成立しているものではないという理解をしております。なので、日本に現状の議論を踏まえて言うと、仮に登録制が入るのだとすると、そこに登録した人たちが、ある種のホワイトリスト感を得てきますので、その中での何らかのあり方は、やはり、この制度ができ上がる中で考えていくというのが１つの基準でございます。
もう一つは、全銀協で行われているAPIの検討会の中身も、かなりの度合いで、このセキュリティのあり方については、銀行側及びAPI活用側の両方について、あり方をある種ソフトロー的に求めようとする動きでもございますので、おそらく全体像として、総合点でどのようなものをつくるのかというところは、これからやっていくところではあるのですが、こういったところはFinTech企業、団体ともに非常に、ある種、協力的に進めていこうという形はあるのかなと思っております。
【岩原座長】
よろしいでしょうか。それでは池田局長、お願いします。
【池田総務企画局長】
先ほど松井先生からあったご指摘の関係ですけれども、今回のテーマの中ではオープン・イノベーションを実現していくのだという大きな目的があって、同時にそれは利用者保護をきちっと図りながらやらなければいけないということも当然の前提となっている。そういうものを実現するときに金融法制全般にそうだと思うのですけれども、ご指摘のあった業規制というのが１つの規制の手法です。そのほかに、例えば金融商品取引法等を考えると、取引規制があったり、開示規制があったり、さまざまな、あるいは自主規制などがあって、そうしたものを組み合わせて利用者保護というものを実現している。
今回オープン・イノベーションを実現するという目的が大きくありますので、それを損なわないように利用者保護を実現しようとすると、やはり業者規制にかかるウェイトというのは、相対的には小さくならざるを得ないであろう。そうすると、その部分を何らかの形で補っていくことが必要になって、それがおそらく、松井先生から指摘のあった、契約相手である銀行の方々に一肌脱いでいただくという部分があるし、あるいは翁先生のおっしゃったような見える化を促進していく。そういうものの組み合わせで、この問題を、業者規制のレベルを上げないで、狙っている利用者保護という目的を実現していくのが、今回、法制整備をするとなれば、我々にとっての大変大きいチャレンジなのだろうと思っています。
それで、もう一つ、PISPとAISPが観念的には決済指図あるなしの違いがあるわけですけれども、どちらにしろ、最大でも資金移動業者相当だということを考えると、それほどの業規制が期待されるわけではない。そもそも２つに分けるほどの業者規制があるのかどうか、論点としてあろうかと思うのですけれども、いずれにしても、我々、利用者をないがしろにするということはできません。皆さんからもお知恵をいただきながら、トータルとして利用者保護を実現する道を探っていきたいと考えていますので、次回以降もご議論いただければと考えております。
【岩原座長】
どうもありがとうございました。ほかに何かございますでしょうか。よろしいでしょうか。私の不手際で、大分時間も過ぎてしまいました。申しわけございません。特にご発言がないようでございましたら、討議を終わらせてだきます。本日いただきましたご説明やご意見等を踏まえ、引き続き検討を進めていきたいと思います。
最後に、事務局から連絡事項等がございましたらお願いします。
【井上信用制度参事官】
次回のワーキング・グループの日時につきましては、皆様のご都合を踏まえた上で、後日、速やかに事務局よりご案内させていただきたいと思いますので、どうぞよろしくお願いいたします。
【岩原座長】
それでは、以上をもちまして、ワーキング・グループを終了させていただきます。長時間、熱心にご討議、ありがとうございました。
── 了 ──
サイトマップ
