金融機能に「ライセンスの壁」はあるか——事業会社が組み込める機能の現実的な境界線

「エンベデッド・ファイナンスで使える機能は何か」という問いへの答えは、機能の種類を列挙するだけでは完結しない。事業会社にとって実務的に意味のある問いは、「どの機能を、誰の許認可の下で、どのように使うか」である。

金融機能には業法上の規制がある。決済、送金、貸付、保険、預金——それぞれに異なる業法が適用され、事業会社が「使える」かどうかは、その機能をどの経路で調達するかによって変わる。機能の一覧を先に見るより、調達経路を先に確認するほうが、実装の現実に近い。

機能の前に「調達経路」が決まる

金融機能を組み込む経路は、実務上おおむね三つに収束する。

1. ライセンス保有事業者のAPIを利用する（BaaS経由） — 自社での許認可取得を要せず、APIを介して機能を呼び出す。導入ハードルが最も低い。
2. ホワイトラベル契約で機能を自社ブランドで提供する — 設計・運用は提供事業者に委ね、UIとブランドのみ自社化する。
3. 自社でライセンスを取得・運用する — 最大の自由度を得られるが、時間・資本・コンプライアンスの負担が大きい。

多くの事業会社が現実に選ぶのは①か②である。③は金融機能をコア事業として位置づける場合に限られ、新規事業部門が最初に選ぶ経路ではない。

「使える機能を探す」のではなく、「使える経路に合う機能を選ぶ」という順序で考えるほうが、実装の失敗を避けやすい。

ライセンスの壁は機能によって高さが違う

各機能の許認可負荷には、明確な段差がある。

負荷が低い（BaaS/APIで調達しやすい）

• 決済受け取り（収納代行・決済代行）：小売・EC・SaaSで広く使われており、決済代行事業者との契約のみで導入できる。事業会社が自前で許認可を持つ必要はない。

中程度の負荷（連携先の選定と契約設計が伴う）

• 送金・振込：資金移動業の登録を持つ事業者のAPIを経由する形であれば、事業会社側の直接登録を要しないケースがある。ただしユーザーへの説明義務と本人確認の設計は必要になる（本人確認の設計については本誌/005を参照）。
• BNPL・後払い：割賦販売法または貸金業法の対象となるかは設計次第。BNPL事業者のホワイトラベル提供を利用する形が現在の主流となっている。

負荷が高い（専用体制・深い連携が前提）

• 融資・ローン：貸金業登録を持つ事業者との連携か、自社での登録取得が前提。収益設計も複雑になる（収益モデルの類型は/009を参照）。
• 保険：保険代理店登録が必要。保険会社との代理店契約か、代理店資格を持つ事業者との再委託契約を通じた提供が一般的。
• 預金・口座開設：銀行法の対象であり、BaaS事業者との構造的なコミットメントが必要になる。最も準備期間と連携深度を要する機能に位置づけられる。

この段差を踏まえると、「組み込める機能」の現実的な範囲は、自社がどの深さの連携を結べるかによって規定される。

「使える機能」は技術より制度で決まっている

エンベデッド・ファイナンスの文脈では、技術的には多くの機能がAPIとして提供されている。しかし、技術的に呼び出せることと、法的に提供できることは別の問いだ。

事業会社が実装を検討する際に先に確認すべき問いは、三点に絞られる。

1. この機能の提供に、自社または連携先が必要な許認可を持っているか。
2. ユーザーに対する説明義務・同意取得・本人確認を誰が担うか。
3. 問題が発生したとき、事業会社・連携先・ユーザーの責任はどう分配されるか。

業種ごとの先行事例を見ると（物流・EC・人事の実装パターンは/006を参照）、実装が順調に進んだケースほど、この三点を機能選定より先に整理している。逆に、機能の「できること」から入って規制の壁に後から当たるパターンは、現在も繰り返されている。

事業会社が金融機能を選ぶとき、最初に確認するのは機能の一覧ではなく、自社の業態・ユーザー構造・連携可能な事業者の許認可範囲の三つだ。この三点が揃って初めて、「使える機能」の輪郭が見えてくる。