アドバイザリー
Financial Services Risk Management(FSRM)

銀行オープンAPIに見る、オープン・イノベーションという"制度整備"の実際

2019.10.29

Fintechの重要な分野として、オープンAPIが注目されています。特に銀行の口座情報を外部の接続先に公開するAPIについては、国の重要な施策として取り扱われるとともに、法令に基づく制度として整備されてきました。この制度に則り多くの銀行は口座情報の公開を進め、APIに接続する事業者は電子決済等代行業者として順次登録を完了させています。しかしながら、実際のAPI接続の進展は十分とは言えない状況にあります。問題の根幹にあるのは、オープンAPIの制度あるいはインフラとしての役割に係る認識齟齬ではないでしょうか。即ち、オープンAPIは銀行の口座情報公開を促進するためのインフラに過ぎず、その上層に構築されるサービスやアプリケーションこそが価値の源泉であるということです。サービスやアプリケーションの開発や育成をどうすれば進めていけるのかという観点を共有して、関係者が協働することが重要なのではないでしょうか。

1. 銀行オープンAPIとは

APIとは、アプリケーション・プログラミング・インターフェース(Application Programming Interface)の略であり、システムの機能やデータを外部のシステムや組織に利用させる場合の公開用接続口といえるものです。APIを利用する側は、所定の仕様にしたがってプログラミングすることで、その機能やデータへのアクセスが可能となります。このうち、セキュリティなど一定の要件を充たす外部企業等ならば誰にでも公平に利用を認めるものを、オープンAPIといいます。オープンAPIは、公開する側の目的や戦略に応じて、有償の場合も無償の場合もあります。

銀行がオープンAPIを公開すると、例えば電気料金を家計簿につける場合に、銀行の口座振替データをAPI経由で連携することで、手動入力あるいはスマートフォンのカメラによる明細書の撮影すら不要となります。あるいは、会計帳簿に仕入の請求書情報を入力すれば銀行への振込依頼も一連の操作で済んでしまうといった、便利で快適な使い方が実現可能になります。

オープンAPIの登場以前は、「スクレイピング方式」が利用されていました(現在でもオープンAPI利用契約未締結の場合は利用されています)。これは、家計簿等のサービスに対し利用者がインターネットバンキングのパスワード等を預け、サービスは利用者に成り代わって銀行にアクセスしてWeb画面をプログラムでなぞりデータを取得するものです。この場合、閲覧情報の範囲が限定されない等セキュリティの課題が指摘されています。

2. 制度化されるまでの動き

2018年6月施行の改正銀行法により、預金者の側に立って銀行口座にアクセスし、サービスを提供する者が電子決済等代行業者(以下、電代業者)として定められ、銀行オープンAPIが制度化されました。

銀行オープンAPI利用サービス(以下、電代業)の主要なものの一つであるアカウント・アグリゲーションサービス、即ち複数の銀行口座等の情報を一画面上でまとめて閲覧できる家計簿や会計等のサービスが米国で登場したのは1990年代末頃、国内では2000年代初頭と言われています。国内のサービス提供者は当初銀行が主体で連携可能な銀行やサービスが少なく、利用者にとって魅力的ではなかったようですが、2012年前後に今日の主要な電代業者であるベンチャー数社が相次いで設立されてから、サービス向上に伴い利用者が増加してきました。

その後、決済高度化や生産性革命といった文脈とセキュリティ向上の期待により国の審議会等で取り上げられ、制度化に向けて次のように進んでいます。

  • 金融審議会の「決済業務等の高度化に関するワーキング・グループ」にて、銀行以外のプレーヤーにより決済分野のイノベーションの重要性を報告(2015年12月22日)
  • 「日本再興戦略2016」にて、オープンAPIをはじめとする多様な金融サービスの創出を期待(2016年6月2日)
  • 全国銀行協会はオープンAPIのあり方に係る検討会を組成し、オープンAPI活用促進に向けた官民連携のイニシアティブ(構想、戦略、計画)を取りまとめ、報告書を作成(2017年7月13日)

3. ここまでの進捗

各銀行が公表する「電子決済等代行業者等との連携及び協働に係る方針」の金融庁調査(2019年6月)によれば、137行(*1)中130行がAPI開放を表明し、そのうち99行は何らかのAPIを公開済みでした。これは政府の未来投資戦略で定められたKPIの80行(2020年6月までAPI公開)を上回っており、制度として順調に滑り出したと評価できるのではないでしょうか。

電代業者は財務局への登録が必要であり、金融庁が公表している登録電代業者の一覧によれば、2019年8月末時点の登録社数は58となっています(マルチペイメントネットワーク等のオープンAPIではない方式を使用する電代業者を含みます)。このほかに、「電子決済等代行業再委託者(*2)」として登録を要しない立場のサービス提供者もあり、電代業者の登録数にKPIは設定されていないものの、登録数の水準は良好であると評価できるのではないでしょうか。

オープンAPIを利用するサービスの内容は、家計簿、会計を含むバックオフィス業務支援、送金・決済、自動貯金等のほか、電子決済等代行業再委託者と銀行との接続仲介(*3)といったサービスが、提供ないし計画されています。

*1 : 外国銀行支店を除く全ての国内銀行。信託銀行、地方銀行、第二地方銀行を含み、協同組織金融機関を含まない。
*2 : 登録電代業者との連鎖接続により銀行へアクセスするサービスを提供する事業者は、銀行法上の電子決済等代行業再委託者とされ、財務局への登録を要しないものの、登録電代業者による監督を受ける。
*3 : 自らは電代業者として登録し、電子決済等代行業再委託者である他事業者の委託を受けて銀行に接続することを業とする事業者のことであり、数社存在すると思われる。

4. 連携の進展状況

電代業は銀行と電代業者の契約に基づいて接続、連携してサービスを提供するのが原則ですが、スクレイピング方式の場合は契約未了であっても、口座データ閲覧は技術的および法的に可能です。2020年5月まではこの契約の締結が猶予されていますが、それ以降は契約未締結での口座データ閲覧は法的に禁止されます。そのため、既存サービスへの影響回避の観点より契約の締結が急がれています。

照会を多用する家計簿、会計、接続仲介等の6電代業者について調査(*4)したところ、各社いずれも100超の銀行に対応可能(スクレイピング方式による参照を含む)である一方で、契約締結は十数社以下に留まり、契約締結が進んでいないことが推測されるほか、銀行との契約未締結の電代業者や、契約済銀行が1、2行に留まるといった電代業者も散見されます。

契約の進展に向けては、関係者間で課題認識を共有できているようで、全国銀行協会を中心に契約書締結にあたり交渉負荷の高い条文内容について検討が行われました。検討には、銀行、電代業者、弁護士等の関係者が参加し、法令および前出の報告書(2017年7月13日)を踏まえ契約条文例とその整理された論点を公表しています。電代業者は、条文例制定により契約交渉がスムーズに進むようになったと感じているようです。また、銀行担当者向けの電代業各社からのサービス内容集合説明会が開催され、契約締結に向けた銀行内手続きも支援されているようです。

*4 : 銀行と電代業者は、契約締結内容の公表を法により定められている。但し、接続する銀行から契約相手先として公表されているにもかかわらず自社では当該銀行との契約締結を公表していないなど、電代業者側の対応は必ずしも徹底されていないようである。

5. 電代業普及に向けた課題

契約が十分に進捗していない背景として、次の3点が考えられます。

(1)費用の分担

報道(日本経済新聞2019年8月16日)によれば、銀行から電代業の採算に合わない高額の接続手数料を求められるケースが増えていることが伝えられています。また、自由民主党の金融調査会の提言(2019年5月7日)においても、一部銀行とFintech企業間でのAPI接続手数料交渉の難航が指摘されています。家計簿業者を例にすると、本稿の推計では有料利用者比率が全体の数%程度(利用料金は年額数千円程度)に留まっており、130余の銀行のほか信金、信組、労金、農協・漁協等を含めると500超の金融機関が揃ってシステム開発、機器設置等の費用を回収できるAPI接続料を設定することは困難と思われます。

先ずは2020年5月の期限までの契約締結完了が再優先事項であり、API接続料の議論はその後に行うこととしなければ、既に電代業を利用している消費者や中小事業者への悪影響は避けられないのではないでしょうか。接続料は、開発費や機器費用の回収ありきで算出されるのではなく、新しい銀行チャネルとしての営業貢献度を評価に取り込んで議論と交渉が行われるべきであり、例えばAPI接続による集客効果や通帳、ATM等の他チャネルの負荷軽減等を評価することにより、電代業者/電代業ユーザーへの負担転嫁の一部ないし全額を減じる余地があるのではないかと思われます。実際に一部のネット銀行ではオープンAPIを重要な顧客チャネルと位置付け、無料公開しているようです。

(2)データ利活用

全国銀行協会の契約条文例では、予め電代業のサービスの内容を特定し、その範囲でのみデータ利用が容認されるとしています。サービス内容を変更する場合の取り扱いは規定されているものの、例えばデータの蓄積が進んだ後に新たなデータ利活用の方策を考案、開発した場合など、接続する全銀行への通知等の手順を要する場合があります。加えて、当初のサービスとの関連が薄い、革新的な方策の場合は銀行の異議により実現を阻害されるリスクがあります。(1)の通り電代業本体の収益性が高いとは考えにくく、新規参入や新サービス開発を促進し、電代業の発展を後押ししていくには、データの利活用による収益化の道を開いておくことが重要と思われます。

経済産業省・総務省による「データポータビリティに関する調査・検討会」(2018年7月)でも、API接続のコスト分担の問題と併せて、データの2次接続によるデータ流通に関するルール整備が課題とされています。

(3)審査対応

  • 1)銀行側の課題

    銀行は、契約を通じて電代業者による情報の取り扱いや安全管理措置の審査を行うこととされています。審査は契約と同様に個別銀行と電代業者の間で行われるものであり、多数の銀行による審査に対応する電代業者の負担は大きいことから、対象項目を銀行間で共通化したチェックリストの作成が望まれました。これは、公益財団法人金融情報システムセンター(FISC)主導の連絡会により対応され、銀行、電代業者、ITベンダーが参加した検討会における議論により「API接続チェックリスト」が制定されました。「API接続チェックリスト」は機密性(*5)項目を中心とした内容であり、一部に可用性(*6)および完全性(*7)項目も取り込むべきとの意見があるようですが、先般FISCより公表された「API接続チェックリスト」の定期更新検討ではその予定はないようです。

    電代業は銀行の委託先ではないため、電代業者システムの稼働に銀行が依存する訳ではなく、可用性項目は不要であると考えられます。また、完全性について更新系取引では銀行への影響が考えられるものの、一律共通のチェックリストの項目とするよりも、サービス内容に即して個別、具体的なチェックが行われるべきであり、チェックリストに取り込むべき内容ではないと思われます。この点は、FISC「金融機関におけるFinTechに関する有識者検討会報告書」(2017年6月)において、"タイプⅢの安全対策のあり方"として示された通り、銀行はデータ保全または本人確認に係る部分に安全対策の責務は限定されるとして、既に明確化済みです。

    さて、「2.制度化されるまでの動き」の全国銀行協会の報告書(2017年7月13日)では、ビジネスモデルとその固有リスクに応じて、あるいは各銀行のポリシーに沿って必要と判断された場合は、独自項目を追加することとしていますが、具体的にどのような状況において必要と判断されるのでしょうか。電代業のサービス固有のリスクが「API接続チェックリスト」でカバーできない場合は対象とすべきですが、これは各銀行が審査項目として追加する以前に、電代業者が自発的にリスク認識と対策状況を開示すべきと考えられます。

    自行ポリシーについてはどうでしょうか。FISCの検討会でのチェックリストの議論において、自行の外部委託基準を持ち出して項目追加を主張する銀行もあったようですが、そもそもオープンAPIは外部委託ではありません。また、銀行が作成し公表することとされている電代業者に求める事項の基準について、各銀行の事例を見る限りでは「API接続チェックリスト」の内容に審査項目を上乗せする程の具体性を備えていないようです。

    なお、自行独自の審査項目を追加しない場合に、リスク管理の不備を指摘されることを、各銀行の担当者が懸念することが想定されますが、金融庁による各種ヒアリング等において、そのような懸念には及ばない旨が説明されているようです。

  • 2)電代業者側の課題

    銀行の意見として「API接続契約を締結するための審査であるから、取り組みの状況や背景をなるべく理解し、行内の手続きを速やかに進めたい。しかしながら、回答の稚拙や不備によりスムーズに進めることができない場合がある。」というものがあります。技術的な事実を述べるに留まり、リスクに対して自社は適切に認識していること、あるいは課題事項を的確に認識していることをもってAPI接続を認めさせようという姿勢の有無に疑問を感じるという事情のようです。

    金融機関におけるリスク管理は他業種からの参入組には馴染みがないことが多いため、コミュニケーションツールとしての「API接続チェックリスト」の位置付けや記載のコツ等について、例えば業界団体を中心とした研修会や銀行提出の際の事前チェックといった取り組みを実施する余地があるのではないでしょうか。

*5 : FISCのシステム監査基準の定義では「重要な情報が非権限者に知られることがないように保護されていること」とされ、電代業者は銀行から連携を受けた利用者の情報を漏えいしないように管理しなければならない。
*6 : 同「必要とされる情報が必要なときに利用可能であり、また必要な資源の継続的使用が確保されていること」とされる。電代業のサービスが停止すれば利用者に影響することは事実であるが、その点に責任を負わない銀行は関与不要と考えられる。
*7 : 同「不正や障害等により情報の一貫性が失われることがないよう保護されていること」とされる。銀行から連携を受けたデータを電代業者が一貫性を持って管理することは電代業者単独の課題であるが、銀行へ伝達する送金指図データと利用者の意図との一貫性であれば、銀行と電代業者が連携して安全管理を図る必要がある。

6. まとめ

銀行オープンAPIは、オープン・イノベーションの好事例と捉えられることもありますが、あくまでも制度という環境整備についての好事例です。実際のイノベーションが進展するか否かは別の取り組みであり、オープンAPIを利用したサービスやアプリケーションの開発や育成をどうすれば進めていけるのかという視座を関係者が共有することが重要であると思われます。

そうは言いながらも、ここまで見てきたように、歴史的、文化的背景の異なる多数の関係者の献身的努力により制度として整備できたことは、規制業種という銀行業の性質を差し引いても他分野でのオープン・イノベーションの参考にされるべきであり、それでこそ関係者の苦労も報われるのではないでしょうか。

EYでは、銀行および電代業者が本来のイノベーション促進活動、即ちサービスやアプリケーションの開発や育成に注力できるよう、リスク管理に係るアセスメントやアドバイザリーサービスをご提供いたします。是非ご照会ください。

【筆者】

EYアドバイザリー・アンド・コンサルティング株式会社
シニアマネージャー 原島 茂幸

一般社団法人電子決済等代行事業者協会前事務局長
大手銀行を経て新日本監査法人入所後、EYアドバイザリー・アンド・コンサルティング株式会社へ転籍。金融機関のシステムリスク管理に関するアドバイザリー業務、システム監査業務等に従事。

※所属・役職等は掲載当時