エンベデッドファイナンスの機能別地図——組み込める「四つの動詞」で整理する

「エンベデッドファイナンスで何ができるか」という問いに対し、多くの情報は概念の説明で終わる。実務担当者が知りたいのは、どの機能が自社のサービスに組み込めるのか、そしてそれぞれに何が必要かだ。

本稿では機能を「動詞」で整理し、日本における現在地を実務の視点で描く。エンベデッドファイナンス全体の概念については金融は「業」から「機能」へで整理しているため、本稿では機能の選び方に絞る。

機能を四つの動詞で分類する

エンベデッドファイナンスで提供できる機能は、ユーザーに対して「何をするか」という動詞で整理すると見通しがよくなる。

① 受け取る（決済・収納）　最も導入件数が多い領域。クレジットカード、口座振替、コンビニ払い、リアルタイム決済を非金融事業者のプロダクトに組み込む。SaaS企業がサブスクリプション料金をプロダクト内で完結させる構成が典型例だ。

② 保つ（口座・ウォレット）　バーチャル口座やウォレット機能をアプリに埋め込む。受け取った資金を一時的に保持し、ユーザーが任意のタイミングで引き出せる仕組みを作れる。フリマアプリの売上保管や、HR系SaaSの給与前払いの原資管理がこれにあたる。

③ 貸す（融資・BNPL）　購買体験の中で与信判断を行い、後払いや分割払いを提供する。ECや業務用ソフトウェアへの組み込みが増えている。信用リスクの設計とライセンス要件の確認が前提になる。

④ 守る（保険・保証）　取引や利用行動に紐づいた保険を組み込む。旅行予約時の旅行保険、購入物の破損保証などが代表例だ。保険代理店登録や少額短期保険業登録が必要になるケースがある。

日本で実際に組み込める機能の現在地

日本では「受け取る」「保つ」の領域が先行して整備されている。資金移動業や電子決済等代行業のライセンスを持つBaaS事業者のAPIを経由することで、事業者は自社でライセンスを取得せずに機能を組み込める場合が多い。キャッシュレス化の進展が後押しし、APIの選択肢も増えている。

一方、「貸す」「守る」の領域はそれぞれ貸金業法・保険業法の規律が働く。BaaS事業者が代理店機能を提供するモデルもあるが、事業者側の法的整理は個別に必要だ。

機能を選ぶ前に、自社サービスのユーザーが「金融機能に何度・何のために接触するか」を定義することが先決になる。

この問いに答えられないまま機能を選ぶと、導入コストに対してユーザーの利用率が上がらないという結果になりやすい。

機能を選ぶための三つの判断軸

実務上、以下の三軸で機能を絞り込むと判断が速くなる。

1. 接触頻度 — ユーザーが金融機能を使う頻度。月に数回未満であれば、複雑な与信機能より単純な決済収納が先になる
2. ライセンス負担 — 代理店モデルで済むか、自社でライセンスを取得するかで時間軸が数ヶ月単位で変わる
3. 開発工数 — 決済APIの接続は数週間から着手できるが、与信ロジックの埋め込みには相応の設計期間が必要になる

なぜ銀行は「解体」されはじめたのかで示したように、金融機能の提供者と組み込む事業者の分離が進んだことで、こうした選択肢が現れた。機能の一覧を眺めるより、自社のサービスに「どの動詞が足りないか」から逆算するのが、実務での正しい問いの立て方だ。