マネーフォワードはなぜ、苦労して「銀行を作る」のか CSOが語る“野心的な未来図”（1/2 ページ）

[斎藤健二，ITmedia]

　なぜSaaSの雄が、わざわざ銀行を“作る”のか。

　マネーフォワードが三井住友フィナンシャルグループ（SMFG）、三井住友銀行と組んで新銀行設立に乗り出した。4月16日、両社は準備会社設立に関する基本合意書を締結。議決権比率は50：50の共同出資企業となる予定だ。企業向けクラウドサービスで成長してきた同社が、規制の厳しい銀行業に踏み込む本当の狙いは何か。

　「銀行機能をSaaSにシームレスに統合することで、革新的なバックオフィス業務体験を創出する」。発表資料ではそう説明されるが、これだけでは謎は解けない。既存の銀行と連携すれば実現できる機能も少なくないはずだ。

　この発表に不思議な点は複数ある。一つは、SMFGが法人向けデジタル総合金融サービス「Trunk」（トランク）をほぼ同時期に発表したことだ。もう一つは、マネーフォワードが2023年から準備してきた「企業向け送金プラットフォーム」との関係だ。

　マネーフォワードの山田一也執行役員（ビジネスドメインCSO）への独占取材から見えてきたのは、SaaSビジネスと金融の融合を見据えた戦略だった。40万社を超える顧客基盤を持つ同社が描く、野心的な未来図とは──。

ボタン一つで送金完了──“SaaSと銀行の融合”で、何ができるか

　マネーフォワードの構想は「銀行の3大業務をSaaSに組み込む」という点に集約される。銀行の3大業務である為替（決済）、融資、預金の機能を、クラウド会計などのSaaSに直接埋め込むことで、バックオフィス業務の効率化を図る考えだ。

　「基本的には銀行の3大業務をクラウドに組み込んでいくイメージ」だと山田氏は説明する。具体例として請求書処理と送金の融合が挙げられる。現在、企業間の送金処理は、SaaSから出力したデータを銀行のネットバンキングにアップロードして行われている。銀行機能をSaaSに組み込めば、請求書データを確認しながら同じ画面上でボタン一つで送金が完了する。会計処理と銀行取引が一つの流れの中で完結するようになる。

　融資機能についても同様の構想がある。SaaSに蓄積された会計データを基に、資金需要を予測し、必要なタイミングで融資を提案できるようになる。「マネーフォワードクラウド上のデータを活用して、ユーザーのキャッシュサイクルを改善させていきたい」と山田氏は語る。売掛金の早期現金化や支払いサイクルの最適化など、企業の資金繰り改善につながる可能性がある。

　同社はすでに「マネーフォワード掛け払い」による売掛保証や「マネーフォワード Pay for Business」によるキャッシュサイクル改善、「マネーフォワードアーリーペイメント」による売掛金の早期入金などのサービスを提供している。しかし、これらはあくまでも外部の金融機能との連携である。銀行機能そのものを組み込むことで、より深い統合が可能になる。

　預金機能のSaaSへの組み込みも視野に入れている。これにより企業の余剰資金管理も効率化でき、企業活動全体の資金の流れを一元管理しながら、余剰資金の最適運用まで提案できるようになる。

　同社が強調するのは、これらが全て同じプラットフォーム上で完結する点だ。銀行とSaaSの境界があいまいになり、ユーザーはバックオフィス業務と金融取引を意識的に切り替えることなく、シームレスに行き来できるようになる。

　マネーフォワードが目指すのは、単なる銀行API連携ではなく、バックオフィスSaaSと銀行機能が融合した業務環境の創出である。では、このビジョンを実現するために、なぜ新たな銀行を設立する必要があるのか。

銀行免許取得の必然性

　銀行機能をSaaSに統合するに当たり、なぜ銀行免許の取得が必要なのか。一見すると資金移動業という、銀行より取得ハードルが低いライセンスでも代替できるように思える。PayPayなど電子マネーサービスの多くもこの資金移動業に該当し、送金サービスを提供している。

　しかし山田氏によれば、資金移動業には決定的な制約がある。「銀行ライセンスがないので滞留させることができない」ことだ。資金移動業の場合、顧客から預かった資金を一定期間内に送金する必要があり、企業の資金需要に応じた送金時期の調整ができない。

　また、唯一資金の滞留が可能な第二種資金移動業でも「100万円以下の送金しか実現できず、B2B決済では耐えられない」と山田氏は指摘する。企業間取引では高額決済も多く発生するため、この制限が大きな障壁となる。

　銀行免許以外のいわゆる「軽い」ライセンスでは、SaaSと金融機能の深い統合に構造的制約が多いのが現状だ。企業のニーズに応じて資金を預かり、必要なタイミングで送金し、余裕資金を運用するという一連のサイクルを実現するには、銀行免許が不可欠との結論に至ったという。

既存API活用の限界

　一方で、既存の銀行が提供するAPIを活用すれば、新たに銀行を設立せずとも同様のサービスが提供できるのではないか。あるいは三井住友銀行のAPIを使えば事足りるのではないか。

　「現時点のBaaS API基盤だと、やりたいことを100％実現するのは難しい」と山田氏は説明する。BaaS（Banking as a Service）とは、銀行機能をAPIなどを通じて他社に提供するサービスモデルである。マネーフォワードはこれまで住信SBIネット銀行やGMOあおぞらネット銀行など、既にBaaSを展開する金融機関のサービスを利用する可能性を探ってきた。しかし検討の結果、既存のAPIでは自社が目指す機能を完全に実現できないと判断したという。

　具体的に何が足りないのかについては「差別化要素になる」として明かされなかった。一般に、既存の銀行APIは各行のシステム制約の中で設計されており、柔軟性や拡張性に限界があるとされる。

　また、新たにライセンスを取得せずとも、三井住友銀行内に別の勘定系システムを構築する案もあるだろう。理論上、三井住友銀行内で2つの勘定系を持つことも可能だ。しかし、銀行システムを開発して提供するには金融庁の審査が必要で、新たに銀行免許を取得するのと同じくらいの労力がかかる。であれば、別会社を作って銀行ライセンスを取る方がよいという判断も納得感がある。

　マネーフォワードが描く構想は単なる銀行機能の利用ではなく、SaaSに銀行機能を深く統合することである。そのためには、自らが主導権を持って開発・運用できる独自の銀行システムが最適との判断に至ったとみられる。