SMBソフトウェア向け組み込み型金融とBaaS：バーティカルSaaSが決済、融資、カード発行を追加する方法

レストラン向けPOS（販売時点管理）プラットフォームであるToastは、昨年、金融サービスから約50億ドルを稼ぎ出しました。本来の主力製品であるソフトウェアのサブスクリプション収入は9億3,600万ドルでした。今やフィンテックという「尻尾」が、SaaSという「本体の犬」の5倍の規模になっています。

同じパターンがバーティカルソフトウェア全体で繰り返されています。Shopifyのマーチャントソリューションは売上の73%を占めています。ServiceTitanのIPO時の構成はサブスクリプション71%、フィンテック25%でしたが、純新規売上を注視するアナリストは、その比率が55対45に収束しつつあると見ています。決済機能はソフトウェアの中核部分よりも速いスピードで成長しているのです。2026年までにバーティカルSaaS企業がシリーズBに到達する頃には、投資家からの質問はもはや決済を組み込む「べきか」ではなく、どの組み込み型金融スタックを使用し、いかに迅速に融資やカード発行を導入できるかへと変わっています。

これが業界で**組み込み型金融（エンベデッド・ファイナンス）と呼ばれるもので、非金融ソフトウェア内で提供される金融製品を指します。そして、その基盤を支える仕組みがBanking-as-a-Service（BaaS）**です。チャンスは本物です。米国のプラットフォームによる組み込み型金融の収益は、2021年の約220億ドルから2026年には510億ドルに成長すると予測されており、BaaS市場は2031年まで年平均成長率（CAGR）17.8%で推移しています。しかし、そのチャンスの隣には、是正措置命令（コンセント・オーダー）、凍結されたプログラム、未実施の監査といった「墓場」も広がっています。そこに陥った創業者たちの多くは、規制当局から指摘を受けるまで、自分たちが銀行のような事業を運営していることに気づいていませんでした。

このガイドでは、組み込み型金融の正体、なぜバーティカルSaaSがその自然な拠点となるのか、2026年におけるスタックの構成、プロバイダーの選び方、そして有望な立ち上げを存亡の危機へと変えてしまうコンプライアンスの罠について解説します。

「組み込み型金融」の本当の意味

組み込み型金融とは、決済、預金口座、デビットカード、融資、保険、給与計算といった金融製品を、表向きは金融製品ではないソフトウェアの中で提供することを指す略称です。建設会社向けソフトウェアプラットフォームが、請負業者が顧客からACH決済を受け取り、その現金をサブアカウントに保持し、未払いの請求書に対して即時融資を受けられるようにしているなら、それは組み込み型金融を行っていることになります。獣医クリニックの管理システムが、備品購入のために動物看護師へブランド付きデビットカードを発行する場合も同様です。

これらの機能の多くを支える技術的エンジンがBanking-as-a-Serviceです。規制対象の銀行（「スポンサー銀行」）が、その銀行免許（チャーター）、ACHおよびカードネットワークへのアクセス、そしてFDIC（連邦預金保険公社）の対象となる元帳を、フィンテック・ミドルウェア・プロバイダーに貸し出します。プロバイダーはそれらの機能を、一般的なソフトウェア企業が呼び出せるクリーンなAPIとして公開します。ソフトウェア企業は銀行免許を保有することはありません。しかし、細則を読めば、銀行運営に酷似した膨大な運用およびコンプライアンス上の責任を負うことになります。

組み込み型金融スタックでは、主に3つの製品が支配的です。

• 組み込み型決済： SaaSプラットフォームの最終顧客に代わってカードやACHを受け付けること。これは導入が最も容易で、収益化が最も速く、他のすべての基盤となる「入り口」となる製品です。
• 組み込み型融資： プラットフォーム独自の取引データを使用して審査を行う、将来の売掛金に対する現金前貸し、与信枠（クレジットライン）製品、および期間融資。手数料率や純利ざやは、決済よりもはるかに高くなります。
• 発行済みカードと口座： ブランド付きデビットカード、バーチャルカード、およびFDIC保護対象の事業用口座（現場スタッフ向けの「支出カード」、ギグワーカー向けの「報酬口座」、購入者向けのストアクレジット・カードなど）。

これらの各レイヤーは互いに相乗効果を生みます。なぜなら、それぞれが顧客の運転資金の流れをより多く取り込むからです。

なぜバーティカルSaaSに圧倒的な優位性があるのか

水平展開（ホリゾンタル）の決済アプリは、クレジットカードの決済を単発の事象として捉えます。しかし、バーティカルSaaSプラットフォームは、その決済を生んだ契約、その契約に割り当てられた労働時間、金曜日までに支払わなければならない資材の請求書、同じ郵便番号内のすべての顧客の過去の季節性、そして当座貸越に向かっている運営者の銀行残高を把握しています。

このコンテキスト（文脈）こそが「堀（モート）」となります。それは以下の3つの要素を一度に変えます。

1. 与信審査がより安価で正確になる： 建設系SaaS企業は、どの請負業者が期限通りに支払いを受け、どの業者が常に90日分の売掛金を抱えているかを知っています。これにより、納税証明書しか見ない銀行による一般的な中小企業ローンよりも、現金前貸し製品の方がはるかに優れた賭けになります。
2. 流通コストが激減する： 顧客はすでにアプリ内にいます。新しい金融製品のための獲得チャネルは必要ありません。ユーザーがすでに開いている画面の中にバナーを表示するだけです。業界アナリストは、金融製品の組み込みに成功したプラットフォームは、顧客あたりの売上を3〜4倍に増やすことができると推定しています。
3. 継続率（リテンション）が向上する： 給与計算、決済、与信枠がソフトウェアを通じて行われるようになると、他社への乗り換えコストは莫大になります。フィンテック・レイヤーは、月額99ドルのサブスクリプションを、年間5,000ドルの金融サービス・アカウントへと変貌させます。

これが、バーティカルSaaSのフィンテック戦略が、わずか約4年の間に「実験的なサイドビジネス」から「シリーズBのデフォルトの事業計画」へと進化した理由です。

2026年のスタック：各社の役割

エンベデッド・ファイナンス（組込型金融）のベンダーマップは混雑しており、カテゴリーも重複しています。2026年に中小企業向けソフトウェアチームが候補として検討することが多いプロバイダーを簡略化して紹介します：

決済処理とオーケストレーション

• Stripe Connect および Stripe Treasury。 開発者優先のデフォルト選択肢。強力なAPI、優れたドキュメント、カード受付から残高管理、カード発行まで幅広いカバー範囲。スタックの大部分を単一のベンダーで完結させたいチームに最適です。
• Adyen for Platforms。 ボリュームに応じた価格設定で、グローバルに強みを持っています。決済処理額が5,000万ドルを超える場合に経済合理性が高まります。オンボーディングは比較的遅く、小規模なプログラムにはそれほど寛容ではありません。
• Finix および Payabli。 「PayFac-as-a-Service（サービスとしての決済代行）」 — プラットフォームが本格的な規制対応の構築を行うことなく、決済代行業者（PayFac）になる（あるいはそのように見せる）ことを支援します。

銀行業務と口座 (BaaSミドルウェア)

• Unit。 顧客の残高を保持したり、ブランドカードを発行したりしたい米国のSaaS企業にとって、プログラムを立ち上げるための最短経路。強力な製品ですが、特定の少数の提携銀行（スポンサーバンク）と密接に結びついています。
• Treasury Prime。 マルチバンクAPI — 特定のスポンサーに縛られることなく、FDICパススルーやリアルタイム決済などの銀行レベルの機能を利用したい場合に有用です。
• Synctera。 コンプライアンスを重視したミドルウェアで、開発初日からBSA/AML（銀行秘密法/アンチマネーロンダリング）ツールを開発体験に組み込むことを目指しています。
• Column。 自社のAPIを公開している銀行であり、ミドルウェアという中間層を一段階取り除いています。

カード発行

• Marqeta、Lithic、Highnote。 ブランドデビットカード、プリペイドカード、そして最近ではクレジットカードプログラムのためのカード発行インフラ。Marqetaはスケーラビリティに優れ、Lithicはよりスリムで開発者に優しいインターフェースを求めるチームに支持され、Highnoteはクレジット製品や消費者向け製品に注力しています。

融資と資本

• Parafin、Kanmon、Liberis。 プラットフォームの取引データを使用して引受を行い、実行、サービシング、および（場合によっては）バランスシートの管理を行う組込型融資API。

元帳と資金移動

• Modern Treasury。 プラットフォーム内の元帳インフラのリファレンス実装。GustoやMarqetaなどの企業が、資金が銀行に到達する前に自社の帳簿を正確に保つために使用しています。
• Dwolla、Moov。 ACH（自動清算機関）に焦点を当てたプログラムによる資金移動。カードプロセッサーと併用されることが多いです。

現在稼働しているプログラムの多くは、これらを3つか4つ組み合わせています。例えば、不動産管理プラットフォームであれば、カード受付にStripe、家主の収益口座にUnit、物件管理者向けのブランドデビットカードにMarqeta、そして賃料収入を担保としたキャッシュアドバンス（資金前払い）にParafinを使用するといった具合です。

現実的な導入シーケンス計画

最もよくある間違いは、決済、融資、カードを一つの大きなリリースで同時に立ち上げようとすることです。それは避けるべきです。各レイヤーのコンプライアンス、運用、経済的複雑さは大きく異なり、ほぼすべてのケースにおいて正しいシーケンス（順序）は同じです。

フェーズ1 — 決済 (0〜6ヶ月)。 顧客のそのまた顧客のためにカード受付機能を追加します。これは最もリスクが低く、ボリュームが大きいレイヤーです。プラットフォームがすべての取引から少額の手数料（通常30〜100ベーシスポイント）を得られるように統合を構築します。このフェーズを利用して、顧客のオンボーディング、KYB（実質的支配者確認）、および不正監視を強化します。

フェーズ2 — 口座と支払い (6〜12ヶ月)。 決済が安定したら、顧客がプラットフォーム内に残高を保持し、ACHでの支払いを行い、特定の支出カテゴリーに対してバーチャルカードを発行できる機能を追加します。ブランドデビットカードは通常、最初のカード製品ではなく、二番目の製品となります。

フェーズ3 — クレジットと資本 (2年目)。 売掛金を担保としたキャッシュアドバンスが最初に来ます。これらは期間が短く、引受が容易で、入金される決済代金から自動的に回収できます。タームローン（証書貸付）やクレジットライン（融資枠）は、より深い与信判断、回収、および貸倒処理の運用が必要になるため、後回しにします。

ベイン・アンド・カンパニーのデータによると、このシーケンスに従うプラットフォームは、順序を飛ばしたプラットフォームに比べて、テイクレート（収益率）が有意に高く、貸倒率が低くなっています。融資は決済よりもユニットエコノミクスが格段に良いため、早期に立ち上げたいという誘惑は強いですが、4%の貸倒率を吸収するために必要な運用の成熟度は本物であり、1年目にはほぼ間違いなく欠けています。

誰も語りたがらないコンプライアンスの罠

2024年2月、FDIC（米連邦預金保険公社）はBaaSに関連する安全性と健全性への懸念（主に銀行秘密法（BSA）の遵守とサードパーティ監視の不備）を理由に、2つの銀行に対して同意命令（Consent Order）を発出しました。Piermont Bankの命令は、Treasury PrimeやUnitを通じて運営されているプログラムに影響を与えました。Robinhood、Square、Upgradeなどのフィンテック企業と提携しているSutton Bankも同様の指摘を受けました。2024年から2025年にかけて、さらなる命令が続きました。FDICは2025年5月だけで12件の執行命令を報告しています。通貨監督庁（OCC）も、全国銀行側で同様の措置を講じています。

スポンサーバンクが同意命令を受けると、下流のプラットフォームには単に厳しい手紙が届くだけでは済みません。プログラムが凍結され、新規顧客のオンボーディングが停止し、場合によっては既存の残高の移動が困難になることもあります。「単なるSaaSの機能」のように感じて運営していた創業者たちは、自分たちのロードマップが、会ったこともない規制当局の手に委ねられていることに突然気づくのです。

特にいくつかの具体的な義務が、ソフトウェア企業を常に悩ませています。

• KYCおよびKYB (顧客確認 / 実質的支配者確認)。 残高を保持したり、カードを受け取ったり、融資を受けたりするすべてのエンドユーザーは、製品チームが十分だと考える基準ではなく、スポンサーバンクが要求する基準で本人確認を行わなければなりません。
• 受益所有権とCIP。 顧客識別プログラム（CIP）の規則は法人顧客に適用され、25%以上の所有権閾値で実質的支配者の情報を収集するという規則は厳格に適用されます。
• 取引監視とSAR（疑わしい取引の届出）の提出。 疑わしい取引の報告は任意ではありません。通常、プラットフォームが第一線の監視を行い、スポンサーバンクが届出を行います。監視が不十分であれば、銀行が規制上の打撃を受け、プラットフォームは契約解除を突きつけられます。
• マーケティングと開示。 FDIC保険、利息、クレジット条件に関する文言は規制されています。注釈なしの「FDIC insured（FDIC保険加入済み）」という文言は、他のどのフレーズよりも多くの停止勧告書（Cease-and-desist letter）の原因となっています。
• 苦情処理とレギュレーションE。 消費者向け金融製品には、紛争取引の処理に関する特定のタイムラインを含む、消費者保護の義務が伴います。

有用な経験則：もしその機能を自分たちで行う場合にライセンスが必要になるのであれば、たとえ自社のプロダクトマネージャーがそう思っていなくても、スポンサーバンクのコンプライアンスチームはそのように扱っています。

自社構築、購入、または提携の選択

3つの正当な道筋があり、最適な答えは資本、規制への意欲、そして長期的なロードマップにおいて金融サービスがどの程度中心的な役割を果たすかによって決まります。

純粋な提携 / リフェラルモデル。 プラットフォームが顧客を金融プロバイダーに紹介し、定額の手数料または少額のレベニューシェアを得るモデルです。リスクが最も低く、アップサイドも最小限ですが、最も迅速に立ち上げることができます。金融が中核ではなく、隣接する機能であるSaaS企業に適しています。

BaaSミドルウェアによる埋め込み型。 顧客からはプラットフォームが金融プロバイダーのように見えますが、規制対象となる活動はスポンサーバンクとミドルウェアパートナーが担います。ほとんどのバーティカルSaaSプログラムがここに該当します。テイクレートは実質的で、コンプライアンスの負担も現実のものとなりますが、中規模のスケールからユニットエコノミクスが機能し始めます。

チャーター、ライセンス取得、または直接PayFac。 少数のプラットフォームは、最終的に資金移動業ライセンスを取得したり、登録済みの決済ファシリテーター（PayFac）になったり、あるいは銀行憲章（チャーター）を追求したりします。これは高コストで時間がかかります。プログラムが数千万ドルの金融サービス収益を上げ、ミドルウェアを排除することによる節約額が規制コストを上回る場合にのみ意味をなします。

簡単なテスト：現在または計画中の金融サービス収益が年間500万ドル未満であれば、提携するかミドルウェアを使用してください。500万ドルから5,000万ドルの間であれば、ほぼ常にミドルウェアが有利です。5,000万ドルを超える場合は、スタックのより多くを内製化するのにかかるコストを少なくともモデリングすべきです。

数字のゲーム：現実的な経済性の姿

経済性は製品によって大きく異なります。財務計画を立てる際は、2026年の大まかなベンチマークを起点として使用し、それぞれの垂直市場（バーティカル）に合わせて調整してください。

• カード決済受け入れ： スポンサーバンクとミドルウェアが取り分を差し引いた後、処理量の30〜100ベーシスポイント（bps）がプラットフォームに残ります。
• ACH： 数セントから数ドルの低額な固定手数料に加えて、付加価値フローに対する少額のパーセンテージ・テイクレート。
• 発行済みデビットカード / プリペイドカード： インターチェンジ・スプリットにより、通常は利用額の50〜100ベーシスポイントがプラットフォームの純収益となります（カード製造およびプログラム管理コストを除く）。
• 売掛債権の現金化（キャッシュアドバンス）： 実効年利（APR）は30〜60%の範囲で、適切に審査されたポートフォリオであれば貸倒率は2〜6%です。資本コスト差し引き後の純利益は、実行額の8〜15%に達することがあります。
• 期間融資（タームローン）： APRはより低く、期間はより長く、運営コストはより高くなります。利益率は資本コストと回収業務に大きく依存します。

特にB2Bの埋め込み型ACH決済については、業界予測によると、2026年までにプラットフォームが付加価値サービスから約40億ドルの純収益を獲得し、埋め込み型カードのボリュームがさらに約8億ドルのプラットフォーム収益を加えるとされています。これらの数字が積み上がるのは、収益を獲得するのが「レール（インフラ）を所有する銀行」ではなく、「顧客関係と取引の文脈を所有するプラットフォーム」だからです。

避けるべき5つの間違い

失敗した、あるいは問題を抱えたプログラムの事後分析（ポストモーテム）で繰り返し見られるパターンは以下の通りです。

1. コンプライアンス担当を配置する前に構築を開始する。 埋め込み型金融プログラムの最初の採用者は、エンジニアでもプロダクトマネージャーでもありません。BSA/AML（銀行秘密法/アンチマネーロンダリング）の確かな経験を持ち、理想的にはスポンサーバンクとの関係構築経験がある人物であるべきです。
2. スポンサーバンクを規制当局ではなくベンダーとして扱う。 スポンサーバンクのコンプライアンスチームは、ロードマップに対して実質的な拒否権を持っています。必要がないと思われる段階から、早めに彼らを巻き込んでください。
3. 「小規模」顧客のKYBを省略する。 小規模だからという例外はありません。「この顧客は知っているから」という例外もありません。ルールはすべての口座保有者に適用されます。
4. 融資における資本コストを過小評価する。 キャッシュアドバンスの純金利マージン（NIM）は、スプレッドシート上では美しく見えますが、クレジットファシリティのコスト、貸倒損失、サービシングコスト、そして失敗したコホートの定期的な減損処理を加味すると、見え方は一変します。
5. マーケティングが法務を追い越してしまう。 消費者金融サービスの法執行措置の多くは、たった一つの広告、一つのウェブページ、あるいは一つのアプリ内バナーに起因しています。金融商品のマーケティングコピーには、審査プロセスと記録の保持が必要です。

プレーンテキスト会計の役割

埋め込み型金融は、問題が顕在化するまで誰も語りたがらない技術的な問題を生み出します。それが**「元帳の爆発的増大（ledger explosion）」**です。顧客の残高、カードの読み取り、支払いの実行、ローンの実行、回収、そしてチャージバックのすべてが、銀行のシステム内だけでなく、自社のシステムにおける会計イベントになります。帳簿を、スポンサーバンクの明細書、カードプロセッサーの決済ファイル、そしてローンサービサーのレポートと、多くの場合毎日照合する必要があります。

Modern Treasuryのようなベンダーが存在するのは、まさに従来の元帳が資金移動の速度に追いつけないからです。自社の財務（CFOが証明しなければならない帳簿）においても、同じ原則が当てはまります。純粋なSaaSサブスクリプションビジネスだった頃よりも、金融サービスがプラットフォームを流れ始めた後の方が、元帳の透明性、監査証跡、および外部ソースに対する照合をスクリプト化できる能力が、はるかに重要になります。

自社製品と同じくらい透明な帳簿管理を

組み込み型金融（Embedded Finance）は、ソフトウェア企業を「資金を動かす企業」へと変貌させます。そして、ビジネスを支える会計基盤は、顧客に提供している金融製品と同等、あるいはそれ以上に優れたものである必要があります。Beancount.io は、完全に透明でスクリプト操作が可能、かつバージョン管理に対応したプレーンテキスト会計を提供します。これは、フィンテック的な性質を持つSaaSビジネスが求める高速な照合（リコンシリエーション）作業のために構築されています。ブラックボックスやベンダーロックインは存在しません。帳簿はテキストファイルとして管理され、1行ずつ詳細に監査することができます。無料で開始 して、財務スタックが複雑化する中で、なぜ多くの開発者や財務チームがプレーンテキスト会計へと移行しているのか、その理由を確かめてください。