日本の金融界が長年取り組んできたオープンAPIの取り組みが、この５月末で大きな節目を迎えました。2017年の改正銀行法に定められた契約締結の猶予期限です注。
本稿では、私が金融庁勤務時代から携わってきたオープンAPI導入の取り組みに関し、この5年間を振り返りながら、その意義、経緯、今後について、改めて考えてみたいと思います。
オープンAPIとの出会い
私が「オープンAPI」という言葉を初めて聞いたのは、日本銀行から金融庁に出向した直後の2015年秋のことでした。金融庁でFintech推進を担当していた信用制度参事官室のチーム内で、欧州の「Open API」の動きに注目し、わが国でもこれに倣った制度を導入すべきではないかと議論したことが発端だったと記憶しています。
私は2016年の春に単身、欧州に出張し、当時議論が進んでいたEUのPSD2と英国のOpen Bankingについて現地調査とヒアリングを敢行しました。欧州では各国のFintech推進策の整合性をとるためにPSD2を導入しようとしていて、その中核となる取り組みが「Open API」でした。英国ではさらに、大手金融機関の寡占状況を解消し、リテールサービスを改善するための切り札として、より強力な「Open Banking」が導入されようとしていました。
このような背景があり、欧州や英国のオープンAPIは、金融機関へのAPI接続の義務化やAPIの無償提供といった「強い制度」として導入されようとしていました。
私は金融庁内への出張報告で、わが国へのオープンAPIの導入の必要性を強調しましたが、一方で、英国や欧州と日本における導入方法は、自ずと違ってくるのではないかという感触も持っていました。
余談になりますが、この頃の日本国内でオープンAPIの導入の必要性や取り組みの方法について議論していた中心メンバーとして、マネーフォワードの取締役でFintech研究所長の瀧俊雄さんがいたことは、今考えると感慨深いものがあります。
オープンAPIの意義
ここで改めてオープンAPIの意義をまとめておくと、①金融サービスの利便性向上、②オープン・イノベーションによる金融サービスの変革、③データの利活用の推進、ということになると思います。
APIとは「Application Programing Interface」の頭文字で、金融機関の口座情報などのデータを外部のサービスやアプリに連携して安全に活用するための接続方式のことです。また、それを外部の事業者に開放することを「オープンAPI」と呼びます。
Fintech企業はこれまで、ユーザーの同意のもとでインターネットバンキングのIDとパスワードを預かり、それをログイン画面に入力することで預金残高や入出金履歴の情報を取得し、自社のサービス上で表示してきました。これをスクリーン・スクレイピング（以下、スクレイピング）と呼んでいます。
もっとも、ユーザーは何処の馬の骨ともわからないFintech企業に自分のIDとパスワードを預けても良いものか躊躇することになります。銀行側も、同意の下とはいえユーザーになりすまして大量のデータを取得していく状況に、セキュリティ上の脅威を感じていました。こうした状況の中で、Fintechサービスの利用が進まないという懸念がありました。
スクレイピングからAPIに移行すれば、IDやパスワードをFintech企業に預ける必要がなくなり、安心してFintechサービスを利用する環境が整備されることになります。銀行側でも、電子決済等代行業者という金融庁の登録業者と契約を締結した上でデータを提供することになり、セキュリティ上の懸念は解消されます。そして何よりも、APIという決まり事に沿った接続のもとでデータ連携を図ることで、必要なデータがより効率的に提供され、利用されることになります。
オープンAPIの導入により、金融機関が外部の革新的なサービスと連携して自行のサービスの付加価値の向上を図る「オープン・イノベーション」も可能となるなど、金融機関とFintech企業の双方に大きなメリットがもたらされることが期待されたのです。
さらに、なかなか利活用が進んでこなかった銀行の預金口座情報などが安全に外部に提供され、様々なサービスで利用されて、そのデータがさらにユーザーの指示のもとで別のサービスで活用されるというデータの連鎖的な利活用の促進につながり、「APIエコシステム」の形成が期待されたのでした。
こうした取り組みの背景として、近い将来、欧米や中国で進化した金融サービスがわが国に進出しようとした際に、「このままではあっという間に国内サービスが席巻されてしまう」という危機感が政府・関係者にあったことは事実です。
一方で、わが国の金融機関は、全銀ネットの継続的な更新やATMネットワークの整備などの独自の取り組みで、グローバルにみても利便性の高い金融サービスを提供し、リーマンショック後もリテールサービスの質や顧客からの信頼を低下させることなく取り組んできていました。金融庁は、こうしたわが国の既存金融システムの良さを活かした独自の工夫を施すことを怠りませんでした。
つまりわが国では、オープンAPIの導入は金融機関の「努力義務」と位置付けられ、金融機関とFintech企業はより対等なビジネスパートナーとして「契約」を結んだ上でAPIを提供していくよう制定されたのです。Fintechは、既存の金融サービスの「破壊」ではなく、共に高みを目指していく「協調」の道を進むことになったのです。
金融庁・日本銀行からマネーフォワードへ
2017年6月末に金融庁への出向期間が終了し、日本銀行に戻ることになったタイミングは、まさに改正銀行法が成立し、オープンAPIの取り組みが実質的に始動した直後でした。6月30日、出向最終日の午後に、金融庁は銀行向けのオープンAPIの説明会を開催し、私が金融庁の代表として、その意義と今後の取り組みを促す説明を行いました。
私はこの時、3年後の契約猶予期限までに様々な新しい挑戦が求められる状況で金融庁を去ることに大きな心残りを感じていました。金融庁出向以来２年間にわたって推進してきたFintechがさらに拡大していけるかどうかは、このオープンAPI制度の導入の成否にかかっていると感じていました。
日本銀行に戻って働き始めてもその気持ちは大きくなるばかりで、私は３週間で日本銀行の退職とFintech企業への転職を決断しました。その時の転職先のいくつかの候補の中から、最終的にマネーフォワードを選んだ背景には、マネーフォワードが個人・法人ともに国内最大クラスのアグリゲーション事業者であったこと、金融庁時代にオープンAPIについて熱く議論していた瀧俊雄さんがいたこと、オープンAPIやFintech業界を先頭で引っ張っていくべき会社であると広く認識されていたこと、が大きかったと思います。
マネーフォワードに転職すれば、金融庁で取り組んできたことの延長線上で、さらにオープンAPIやFintechを強力に推進していけると考えたのです。
この1年の取り組み
マネーフォワードでのオープンAPI対応の中で、この１年間は本当に密度の濃い、激動の１年間でした。
2019年の春、一部金融機関からAPIの「接続手数料」を請求する声が上がり始めました。それまでのスクレイピングは、いわば勝手にデータを取得していたものであり、その料金は無償でした。マネーフォワードとしても、いつまでも無償でいいとは考えていませんでしたが、金融機関から打診された手数料水準を合計すると、有料ユーザーからいただいている売上の数十倍の規模に膨れ上がるおそれがありました。
このままでは事業の収益バランスが大きく崩れ、ビジネスモデルが崩壊してしまう。それよりも、数百万人まで拡大していたユーザーへのサービス提供を停止することだけは絶対に避けなければならないと感じていました。
また、銀行だけで130行、信金・信組を合わせると500先以上になる相手先のそれぞれと、手数料水準を交渉し、セキュリティ・チェックを受け、契約書の内容を詳細まで詰め、接続テストを行い、リリースしていくという手続きに必要となる膨大なリソースも大きな課題でした。
いわばマネーフォワードは、創業以来最大のピンチを迎えることとなったのです。
このピンチを乗り切るために、社内では一大プロジェクト体制を組むことになりました。金融機関との交渉を担当する10数人を核として、セキュリティチェック担当、契約・法務担当、システム変更担当、ユーザー告知担当など、社内の様々な部署で総勢60人以上が関与し、各チームの代表が毎週の定例ミーティングで進捗やリスク管理について共有し、推進していく全社的な体制を組んだのです。金融機関との連絡メールは1日百通以上、社内のディスカッションのチャットは毎日数百メッセージに及びました。
金融機関との交渉も慎重かつ丁寧に進めました。業界全体から金融庁に依頼して地域金融機関向けの説明会を開催してもらい、契約書やセキュリティチェック・シートをできるだけ統一し、効率化できるようお願いするとともに、事業者の代表としてマネーフォワードのビジネスモデルを詳しく説明し、許容できる手数料水準について理解を求めました。
金融機関は交渉の勝ち負けを争う相手ではなく、一緒により良いサービスを作っていくパートナーとして尊重し、担当者ベースでの信頼関係を築きつつ、なんとかお互いにメリットがある形を模索しながら議論を進めてきました。
データの利活用に関しても、Fintechサービスは、ユーザーが自らのデータを便利に使うためにユーザーの代わりにデータを取得しているという点や、それによって間接的に銀行口座の付加価値を高め、ユーザーのロイヤリティの向上につながる点について丁寧に説明し、銀行側の理解を求めました。
APIへの移行に慎重な銀行に対しては、きちんと契約を結んだ上でスクレイピングを継続していくことがユーザーのニーズに応える次善の道であることも説明し、データ連携の切断ではなくスクレイピングによるサービスの継続を粘り強くお願いすることもありました。
オープンAPIの取り組みの成果
全ての関係者が大きな節目と考えていた2020年5月末はあっという間にやってきました。そして、マネーフォワードにとって、取り組みの成果は非常に大きなものとなりました。
最終的に、個人向けAPI（主に『マネーフォワード ME』向け）では、対象となる銀行125行のうち110行以上がAPIに移行予定（ユーザー数では約99％）となり、スクレイピング契約も含めると、125行のすべてでサービスが継続できることとなりました。
また、法人向けAPI（主に『マネーフォワード クラウド会計』向け）では、対象となる120行のうち約100行がAPIに移行予定（ユーザー数では約94％）となり、スクレイピング契約も含めると、こちらも120行のすべてでサービスが継続できることとなったのです。
これらの中には、銀行との調整の結果、一旦はサービスの停止を決めてユーザー向けに告知したところ、ユーザーから継続を求める強い意見が寄せられて、一転してサービスの継続へと変更した銀行も複数ありました。
この１年間、厳しい交渉や連日のハードワークを積み重ねつつ対話を続けてきた金融機関とは信頼関係がさらに強まり、「API連携を活かしてどんな案件に取り組みましょうか？」という今後に向けた対話が進み始めています。
一人当たり最大で20先以上の銀行を担当し、連日数十通のメールやチャットをやりとりしてきた担当者にも、この１年間は大きな成長と自信をもたらしてくれました。
「ユーザーのために」を合言葉に進めてきたプロジェクトが、最もユーザーに痛みの少ない形で着地できたことは大きな安堵でした。また、最後に、ユーザーからの声によって銀行とのサービスの継続につなげられたことは、私たちがユーザーに大きな勇気をもらう結果となりました。
マネーフォワードは、オープンAPIの取り組みを通じて、わが国最大のアグリゲーション・プラットフォームを、更に強力な形で再構築することができました。この原動力はすべて「ユーザーの力」であり、これが「Fintechの強さ」であることを改めて強く実感することができました。
今後に向けて
マネーフォワードの、そしてFintechの挑戦はこれで終わりではありません。むしろ、これからさらに重要な挑戦が続いていくことになります。
まずは銀行、信用金庫・信用組合等を含めると500以上の金融機関のAPIネットワークを活用して、さらに便利なサービスを作り出し、提供していくという使命があります。
今回連携したAPIは、ほとんどがデータを呼び出す「参照系API」でした。一方、データを参照したユーザーは、次に決済、送金、振込などの形でそのお金を動かすニーズが高まります。これを実現するための「更新系API」の推進が次のターゲットとなります。
また、APIを使って呼び出したデータの活用も重要です。データの二次利用、三次利用も含めて、ユーザーのニーズに合ったサービスを安全な形で連携させていく「APIエコシステム」の構築も求められています。政府がグローバルに提案し、推進しているData Free Flow with Trust（DFFT）の取り組みにも合致する形でデータの利活用を進めていくことが期待されています。
そして、このAPIエコシステムをさらに拡大していくために、ユーザーはもちろん、銀行や金融機関を含めたすべてのステークホルダーにメリットのある形でサービスの拡大を図っていかなければなりません。ユーザー・金融機関・Fintech企業のすべてが「win-win-win」になるような革新的なサービスを生み出し、安全な形で提供していくことが必要です。
これまで以上に、大きく、やりがいのあるチャレンジが、私たちの前に開かれているのです。
（注）金融庁は本年4月14日、新型コロナ対策として、一部の案件の契約期限を例外的に本年９月末まで延長することを許容する通達を発出していますが、マネーフォワードでは、APIエコシステムをいち早く構築するため、多くの案件について5月末を期限として進めてきました。
