💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — Synapse 2024 破綻が残したもの、そして韓国・日本の BaaS スタートライン

2024 年 4 月 22 日、Synapse Financial Technologies(サンフランシスコ、Y Combinator W14)がカリフォルニアの裁判所に Chapter 11(連邦破産法第 11 章)の申請を行った。その結果、Yotta・Juno・Copper といったフィンテックアプリのユーザーが自分の資金にアクセスできなくなる事態が発生し、FDIC・Fed の調査の末、衝撃的な結論として `$300M missing customer funds` が示された。BaaS 史上最大の台帳整合(reconciliation)失敗事件である。

Synapse 事件以降、2024-2025 年の米国 BaaS は激変期を迎えた。Federal Reserve は Evolve Bank & Trust、Lineage Bank、Choice Financial Group などのスポンサー銀行に consent order を発出し、OCC も独自のガイダンスを強化した。Treasury Prime・Unit・Synctera はスポンサー銀行のマルチプレックス(multi-bank)モデルへ舵を切り、**Stripe Treasury・Adyen for Platforms・Marqeta・Galileo のように自社ライセンスや信頼性の高いスポンサー銀行バックボーンを持つプレイヤーが市場シェアを獲得した。**

欧州では Solaris(旧 Solarisbank、ベルリン)が 2022-2023 年に ADAC・BaFin 関連の課題で停滞したが、2025 年にライセンス整備を経て回復。韓国ではフィンク(핀크)が SK テレコムと合弁で BaaS API を解放し、Toss は自前の BaaS を運用し、カカオバンクは 50 以上のオープン API を外部フィンテックに公開する。日本は GMO あおぞらネット銀行の BaaS、BANKING.JP、住信 SBI ネット銀行(NEOBANK ブランド)、J-Coin Pay、Setou Bank の組込み金融が JPY 統合 API を定義する。

本稿は BaaS の全体地図である — 何が BaaS で、スポンサー銀行とは何か、どのミドルウェアがあり、Synapse 事件が何を変え、韓国・日本がどのように違うのか。

1 章 · BaaS とは何か — スポンサー銀行 + ミドルウェア + フィンテックアプリ

BaaS(Banking-as-a-Service)は、銀行ライセンスを持つスポンサー銀行が自らのインフラ(預金・決済・カード発行・送金・KYC)を API として公開し、ミドルウェアが API を集約・抽象化してフィンテックアプリへ提供する 3-tier モデルである。

| 階層 | 役割 | 代表例 |

| --- | --- | --- |

| スポンサー銀行 | 銀行ライセンス、FDIC 保険、実際の資金保有 | Evolve、Cross River、Pathward、Coastal、Lead Bank |

| ミドルウェア(BaaS プロバイダー) | API 標準化、台帳運用、コンプライアンス自動化 | Treasury Prime、Unit、Synctera、Stripe Treasury、Galileo |

| カードプロセッサ / イシュア | カード発行・決済網 | Marqeta、Galileo、i2c、Lithic |

| フィンテックアプリ | ユーザーインターフェース、ブランディング | Mercury、Brex、Ramp、Chime、Wealthfront、Robinhood |

この 3-tier モデルには 2 つのトレードオフがある。

- **長所**: フィンテックが銀行ライセンスなしに迅速にローンチできる。資本と規制負担が小さい。

- **短所**: 台帳のずれが起きた際に責任の所在が曖昧。Synapse 事件が露呈させた点である。

核心は **「誰が資金を保有し、誰が台帳を運用するか」** である。資金は常にスポンサー銀行になければならず、台帳はスポンサー銀行の core banking system と middleware の台帳が常に一致していなければならない。Synapse はこの reconciliation が崩れた。

2 章 · 組込み金融 `$300B+` 市場 — なぜ BaaS なのか

組込み金融(Embedded Finance)とは、非金融企業が自社プロダクトの内部に決済・預金・カード・融資・保険を組み込むことである。Bain & Company、McKinsey、a16z などの推計では 2026 年の世界市場規模は `$300B+` とされる。

- 決済: Shopify Payments、Uber のドライバー支払い、Lyft Driver Account。

- 預金: Apple Cash、Apple Card Savings、Brex Cash。

- カード: Brex、Ramp、Mercury、Robinhood Cash Card。

- 融資: Affirm BNPL、Klarna、Shopify Capital、Square Loans。

- 保険: Tesla Insurance、Lemonade、Hippo(前述の記事)。

非金融企業が自前で銀行ライセンスを取得するには、資本・時間・規制負担が大きい。だから、スポンサー銀行 + ミドルウェアを経由してローンチする。**Affirm は Cross River と提携し、Mercury は Choice・Evolve・Coastal を使い、Brex は Column Bank と提携している。**

この市場のコアバリューは流通コスト(distribution cost)だ。フィンテックのユーザー獲得コスト(CAC)は `>$50/account` だが、非金融企業が自社のユーザーベース上に組込み金融を載せれば CAC は事実上ゼロになる。だからこそ BaaS は消えない — Synapse 事件にもかかわらず、市場はむしろ大きくなり、ただしスポンサー銀行ガバナンスが強化されるだけだ。

3 章 · Solaris(旧 Solarisbank)— 欧州 BaaS の復活

Solaris(ベルリン、2016)は欧州 BaaS の代表だった。BaFin(ドイツ連邦金融監督庁)のライセンスを持ち、ADAC・Samsung・Tomorrow・Vivid などの顧客に BaaS を提供していた。

2022-2023 年は厳しい時期だった。BaFin が Solaris の AML(マネーロンダリング対策)統制とガバナンスに問題を指摘し、ADAC カード発行の遅延・資本負担の増加が続いた。2023 年に KKR 主導の €100M ファンディングラウンドで回復資金を確保し、2024-2025 年にライセンス整備を完了した。

2026 年現在、Solaris は次のラインナップを提供する。

- **Banking ライセンス**: 預金・口座・送金・SEPA・SWIFT。

- **E-Money ライセンス**: カード発行・決済処理・デジタルウォレット。

- **Lending**: BNPL・個人ローン(対象パートナー限定)。

- **暗号資産保管**: 2024 年に BaFin から認可。

API の表面はこのようなものだ。

Solaris API — 口座作成、カード発行例(概念的 cURL)

1) 顧客の KYC 登録

curl -X POST https://api.solarisbank.de/v1/persons \

-H "Authorization: Bearer $TOKEN" \

-H "Content-Type: application/json" \

-d '{

"first_name": "Mina",

"last_name": "Kim",

"birth_date": "1990-04-21",

"nationality": "DE",

"address": {"line_1": "Friedrichstrasse 1", "city": "Berlin", "country": "DE"}

2) 口座の開設

curl -X POST https://api.solarisbank.de/v1/persons/$PERSON_ID/accounts \

-H "Authorization: Bearer $TOKEN" \

-d '{"type": "CHECKING_PERSONAL", "currency": "EUR"}'

3) Visa カード発行

curl -X POST https://api.solarisbank.de/v1/persons/$PERSON_ID/cards \

-H "Authorization: Bearer $TOKEN" \

-d '{"type": "VISA_BUSINESS_DEBIT", "account_id": "$ACCOUNT_ID"}'

このラインナップが欧州 BaaS の標準である。Solaris 以外に英国の ClearBank、リトアニアの Bankera、ドイツの SumUp Bank が類似の構成を運用している。

4 章 · Synapse 2024 年破綻 — `$300M missing customer funds`

本稿の重心。2024 年 4 月 22 日、Synapse は Chapter 11 を申請した。以前から問題はあったが、決定打は Evolve Bank & Trust との紛争だった。

タイムライン:

- 2014: Synapse(サンフランシスコ)が Y Combinator W14 のコホートとしてスタート。ミドルウェアとしてフィンテックをスポンサー銀行に接続。

- 2019-2022: Mercury・Yotta・Juno・Copper・Mainvest などフィンテック顧客が 100 社以上に拡大。

- 2023: 整理解雇と資本不足。Mercury が Synapse からスポンサー銀行へ直接接続するマイグレーションを開始。

- 2024 年 3 月: Evolve が Synapse との reconciliation 紛争で取引停止。

- 2024 年 4 月 22 日: Chapter 11 申請。

- 2024 年 5 月: ユーザーが資金にアクセスできなくなる。Yotta のあるユーザーで 80,000 USD が凍結。

- 2024 年 6 月: 裁判所選任のトラスティ(Jelena McWilliams 元 FDIC 議長)が調査開始。

- 2024 年 7-9 月: `$300M missing customer funds` の結論。台帳の不一致でどこにあるか追跡不可能。

原因分析:

1. **台帳の不一致**: Synapse の internal ledger と Evolve の core banking system が reconcile されない。どのユーザーがいくらを保有しているか正確に分からなくなった。

2. **FBO 口座の問題**: Synapse はスポンサー銀行に FBO(For Benefit Of)口座を運用していた。複数ユーザーの資金が 1 つの口座にプールされ、誰がいくら持っているかは Synapse の台帳にしかなかった。

3. **FDIC pass-through 保険の限界**: FDIC 保険はスポンサー銀行が破綻したときだけ適用される。Synapse(middleware)が破綻したケースは保護されない。

4. **ガバナンス不足**: 外部監査・内部統制が十分でなかった。

この事件は BaaS 全体にトラウマを残した。その後、Federal Reserve は Evolve に consent order を出し、Lineage Bank・Choice Financial Group もコンプライアンス強化命令を受けた。**Unit・Treasury Prime はスポンサー銀行マルチプレックスモデルへ再編し、Stripe Treasury・Adyen for Platforms のように自社ライセンスや信頼性の高いスポンサー銀行バックボーンを持つプレイヤーが市場を取り戻した。**

5 章 · Federal Reserve / OCC の consent order — 規制強化

Synapse 事件以降、米国の銀行監督機関はスポンサー銀行に対し強力な命令を出した。

- **Evolve Bank & Trust(アーカンソー、2024 年 6 月)**: Federal Reserve が cease and desist 命令。AML・BSA(Bank Secrecy Act)・消費者保護・third-party risk management の改善義務。

- **Lineage Bank(テネシー、2024 年 1-3 月)**: OCC consent order。フィンテックパートナー審査義務。

- **Choice Financial Group(ノースダコタ、2024 年 5 月)**: Consent order、フィンテックパートナー制限。

- **Cross River Bank(NJ、2023 年 4 月)**: 以前からの FDIC consent order。fair lending と third-party risk。

- **Sutton Bank(オハイオ、2024 年 2 月)**: コンプライアンス強化。

核心メッセージは **「スポンサー銀行はフィンテックパートナーの行動を自らの行動と見なせ」** ということ。ミドルウェアが失敗してもスポンサー銀行が責任を負う。だからスポンサー銀行はフィンテックパートナーの選定により慎重になり、一部のスポンサー銀行は新規フィンテックのオンボーディングを一時停止した。

OCC は 2024 年 7 月に「Third-Party Risk Management」ガイダンスを更新した。主要な要求事項:

1. Third-party risk assessment を四半期ごとに更新。

2. 台帳の reconciliation を毎日実施。

3. プールされた FBO 口座の sub-ledger をスポンサー銀行自身が別途保管。

4. フィンテックパートナーの関連会社・資金フローを透明化。

5. Adverse event(例: ミドルウェアの財務危機)への contingency plan。

6 章 · Treasury Prime — マルチ銀行ネットワークモデル

Treasury Prime(2017、サンフランシスコ)は Synapse・Unit と並ぶ米国 BaaS の御三家の一つだ。差別化ポイントは **multi-bank network**。つまり、フィンテックは Treasury Prime を通じて複数のスポンサー銀行から望むところを選べる。

2026 年現在、Treasury Prime のスポンサー銀行ネットワークには次が含まれる。

- BMO Harris Bank(親会社: BMO Financial Group)

- BankProv(マサチューセッツ)

- Emigrant Bank(ニューヨーク)

- LendingClub Bank(カリフォルニア)

- Mid-Penn Bank(ペンシルバニア)

- Sutton Bank(オハイオ)

このモデルの利点は、フィンテックが 1 つのスポンサー銀行に依存しないこと。あるスポンサー銀行がコンプライアンス問題でオンボーディングを止めても、別のスポンサー銀行に移したり分散したりできる。

API は RESTful で、Stripe・Plaid と似た表面を持つ。

// Treasury Prime — Node.js SDK 例(概念コード)

const tp = new TreasuryPrime({ apiKey: process.env.TP_API_KEY })

// 1) Person 登録(KYC 自動トリガー)

const person = await tp.persons.create({

first_name: 'Jiwoo',

last_name: 'Lee',

date_of_birth: '1992-07-15',

ssn: '123-45-6789',

address: { line1: '1 Market St', city: 'San Francisco', state: 'CA', postal_code: '94105' },

})

// 2) Account 作成(スポンサー銀行を選択可能)

const account = await tp.accounts.create({

person_id: person.id,

product: 'CHECKING',

bank: 'sutton',

})

// 3) ACH 送金

const transfer = await tp.transfers.create({

source_account_id: account.id,

destination_routing_number: '021000021',

destination_account_number: '4444333322221111',

amount: 50000, // 500.00 USD(セント単位)

type: 'ACH',

direction: 'CREDIT',

})

Treasury Prime のバリュープロポジションは **「スポンサー銀行のロックインなし」** である。Synapse 以降、この価値提案はより重みを増した。

7 章 · Unit — Y Combinator・Bessemer がバックする BaaS

Unit(2019、テルアビブ発、本社はニューヨーク)は Y Combinator W20 のコホートとしてスタートした。2022 年に Bessemer 主導のシリーズ C で `$100M+` を調達。2026 年現在、Unit はスポンサー銀行として Blue Ridge Bank・Choice Financial Group・Thread Bank・Pacific West Bank を使用している。

差別化ポイントは **開発者体験(DX)** だ。Unit は Stripe に最も近い DX を持つ BaaS で、ドキュメント・SDK・ダッシュボードがすべてフィンテック開発者フレンドリーだ。

主要プロダクト:

- **Deposit 口座**: Checking / Savings。

- **Debit/Credit カード**: 仮想・物理。

- **ACH・Wire・Book Transfer**: 送金チャネル統合。

- **White-label アプリ**: フィンテックブランドでの露出。

- **コンプライアンス自動化**: KYC、OFAC sanctions screening、transaction monitoring。

Unit の API は JSON:API 標準に従う。

// Unit — 口座 + カード発行のフルスタック(概念 TypeScript)

const unit = new Unit(process.env.UNIT_TOKEN!, 'https://api.s.unit.sh')

// 1) Customer 作成

const customer = await unit.customers.create({

type: 'individualCustomer',

attributes: {

fullName: { first: 'Sora', last: 'Park' },

dateOfBirth: '1991-03-12',

ssn: '999887777',

address: { street: '15 W 38th St', city: 'New York', state: 'NY', postalCode: '10018', country: 'US' },

})

// 2) Deposit 口座開設

const account = await unit.deposits.create({

type: 'depositAccount',

attributes: { depositProduct: 'checking' },

relationships: { customer: { data: { type: 'customer', id: customer.data.id } } },

})

// 3) Debit カード発行

const card = await unit.cards.create({

type: 'individualDebitCard',

attributes: { shippingAddress: customer.data.attributes.address },

relationships: { account: { data: { type: 'depositAccount', id: account.data.id } } },

})

Unit は 2024 年 Synapse 事件後、新たなスポンサー銀行へ拡張しつつ multi-bank モデルを強化した。2026 年現在、Treasury Prime とともに米国 BaaS の二強構図である。

8 章 · Galileo(SoFi 子会社)— `$50M+ accounts` を処理するバックボーン

Galileo Financial Technologies(2000、ユタ)は米国で最古参の決済処理バックボーンの一つだ。2020 年に SoFi が `$1.2B` で買収し、その後 SoFi の金融バックボーンとなりつつ、外部フィンテック顧客(Chime、Robinhood、Dave、Varo の一部)に処理サービスを提供している。

2026 年統計(Galileo 公式 + SoFi 10-K):

- 約 `$50M+ accounts` を処理(Chime、SoFi、Dave、その他フィンテック合算)

- 米国・英国・カナダ・メキシコ・コロンビアに対応

- 月間 `$200B+` を処理(TPV は Marqeta より小さいが、口座数では同規模)

Galileo は BaaS プロバイダーというよりは **カード処理・口座台帳のバックボーン** に近い。スポンサー銀行は別途(Chime の場合は The Bancorp Bank と Stride Bank)。

このモデルにおける Galileo の価値は **カード認証・決済網統合・台帳運用** だ。つまりフィンテックが Chime のようにユーザーカードを発行する際、Galileo が ISO 8583 メッセージを Visa/Mastercard とやり取りし、トランザクションを台帳に記録する。

Galileo の API は RESTful だが、isolated だ — つまりフィンテック 1 社ごとに別インスタンスがデプロイされる。マルチテナントではない。

9 章 · Marqeta — `$200B+ TPV` のカード発行スペシャリスト

Marqeta(2010、カリフォルニア・オークランド)はカード発行分野のグローバルリーダーだ。2021 年の IPO 後、2026 年現在時価総額は変動が大きいが、決済バックボーンとしての位置は揺るがない。

2026 年統計:

- TPV(Total Processed Volume): 年間 `$200B+`。2025 年は `$220B` を記録。

- 主要顧客: Block(Cash App Card)、DoorDash、Instacart、Uber、Affirm、Klarna、Coinbase(以前)、JPMorgan Chase(市販外事業)

- 発行可能なカード: Visa、Mastercard、Discover、仮想/物理、EMV chip、contactless。

- 対応市場: 米国・カナダ・英国・EU・オーストラリア・日本(2025 年進出)。

Marqeta の差別化ポイントは **JIT(Just-in-Time) Funding** だ。カード決済時にフィンテックのバックエンドに webhook を呼び、フィンテックがその場で funding 可否を判断する。このモデルのおかげでカード発行の自由度が高い。

Marqeta JIT Funding webhook 処理(Python Flask 概念コード)

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.post('/marqeta/jit')

def jit_funding():

payload = request.get_json()

Marqeta が呼び出す JIT webhook — カード決済直前にフィンテックへ funding 要求

user_id = payload['cardholder_user_token']

amount_cents = int(payload['amount'] * 100)

merchant_mcc = payload['mid'].get('mcc')

1) ユーザー残高チェック

balance = get_user_balance(user_id)

if balance < amount_cents:

return jsonify({"jit_funding": {"decline_reason": "INSUFFICIENT_FUNDS"}}), 200

2) MCC 制限(例: 賭博 MCC 7995 をブロック)

if merchant_mcc in ['7995', '7800']:

return jsonify({"jit_funding": {"decline_reason": "MERCHANT_NOT_ALLOWED"}}), 200

3) 自前台帳で保留処理

hold_funds(user_id, amount_cents)

4) Marqeta に承認を返却

return jsonify({

"jit_funding": {

"amount": payload['amount'],

"memo": "approved",

"tags": "consumer-debit"

}

}), 200

このモデルのおかげで Brex・Ramp のような spend management 企業がローンチできた。ユーザーがカードをスワイプすると、フィンテック自身のコンプライアンスルール(例: 規定違反 MCC のブロック、上限管理、GL カテゴリマッピング)が即座に作動する。

10 章 · Stripe Treasury — BaaS の新標準

Stripe Treasury(2020 年ローンチ)は BaaS 市場に遅れて参入したが、すぐに標準となった。Goldman Sachs と Evolve Bank & Trust がスポンサー銀行(2026 年現在)。

差別化ポイント:

- **Stripe API との統合**: 既に Stripe Connect を使うプラットフォームが大きな摩擦なく追加できる。

- **信頼性**: Goldman Sachs のスポンサー銀行は Synapse 事件で生じた懸念を相殺する。

- **API 表面**: Financial Account、Issuing、Treasury Send、OutboundTransfer など。

Stripe Treasury の主力ユーザーは **B2B マーケットプレイス・プラットフォーム** だ。Shopify Balance、Lyft Driver Direct Deposit、東南アジア Grab の一部サービスなど。

Stripe Treasury — Financial Account 作成、Issuing カード発行

stripe.api_key = "sk_live_..."

1) Connected Account に Financial Account を作成

financial_account = stripe.treasury.FinancialAccount.create(

supported_currencies=["usd"],

features={

"card_issuing": {"requested": True},

"deposit_insurance": {"requested": True},

"financial_addresses": {"aba": {"requested": True}},

"inbound_transfers": {"ach": {"requested": True}},

"outbound_payments": {"ach": {"requested": True}, "us_domestic_wire": {"requested": True}},

"outbound_transfers": {"ach": {"requested": True}, "us_domestic_wire": {"requested": True}},

stripe_account="acct_1NXY..." # Connected Account

)

2) Issuing カード発行

cardholder = stripe.issuing.Cardholder.create(

type="individual",

name="Yuna Choi",

email="yuna@example.com",

individual={"first_name": "Yuna", "last_name": "Choi", "dob": {"day": 14, "month": 6, "year": 1993}},

billing={"address": {"line1": "1234 Market St", "city": "SF", "state": "CA", "postal_code": "94103", "country": "US"}},

stripe_account="acct_1NXY..."

)

card = stripe.issuing.Card.create(

cardholder=cardholder.id,

currency="usd",

type="virtual",

financial_account=financial_account.id,

stripe_account="acct_1NXY..."

)

Stripe Treasury の弱点はスポンサー銀行依存だ。Goldman と Evolve 以外のオプションが限定的だ。Treasury Prime の multi-bank モデルと比較される。だが、Stripe のグローバル認知度と開発者体験がその欠点を相殺する。

11 章 · Adyen for Platforms — 欧州発のグローバル組込み金融

Adyen(オランダ、1998)は決済処理から始まり、組込み金融へ拡張した。Adyen for Platforms はマーケットプレイス・プラットフォームが自社の sub-merchant に決済・精算・カード発行を提供できるようにする。

差別化ポイント:

- **グローバル**: 欧州・米国・アジア・ラテンアメリカまで単一 API。

- **自社ライセンス**: Adyen は欧州銀行ライセンス(De Nederlandsche Bank)・米国 acquirer ライセンスを直接保有。スポンサー銀行は別途存在しない。

- **マーケットプレイス特化**: Uber・eBay・Etsy のようなマーケットプレイスのバックボーン。

Adyen for Platforms は 2024 年から米国でカード付き組込み金融を本格運用している。2025 年には英国 Klarna との提携が発表された。

12 章 · BaaS ミドルウェア比較マトリックス

ここで核心マトリックスを整理しよう。

| --- | --- | --- | --- | --- | --- | --- | --- |

| 状態 | 2024 年破綻 | 運用中 | 運用中 | 運用中 | 運用中 | SoFi 子会社 | NASDAQ 上場 |

| 自社ライセンス | なし | なし | なし | なし | なし | なし | なし |

| カード発行 | 統合 | 統合 | 統合 | 統合 | Stripe Issuing | 統合 | 核心価値 |

| ACH/Wire | 統合 | 統合 | 統合 | 統合 | 統合 | 統合 | 別 |

13 章 · BaaS 口座台帳スキーマ — コアデータモデル

BaaS 運用の核心は台帳である。Synapse 事件が示したように、台帳が正確でなければすべてが崩れる。2026 年の標準台帳スキーマは次のようになる。

-- BaaS 口座台帳スキーマ(PostgreSQL 概念)

-- double-entry ledger の原則 — すべてのトランザクションは借方/貸方の 2 行

CREATE TABLE accounts (

id UUID PRIMARY KEY DEFAULT gen_random_uuid(),

customer_id UUID NOT NULL,

sponsor_bank TEXT NOT NULL, -- 'evolve', 'cross_river', 'sutton'

external_account_number TEXT NOT NULL,

product TEXT NOT NULL, -- 'checking', 'savings', 'credit'

currency TEXT NOT NULL DEFAULT 'USD',

status TEXT NOT NULL, -- 'open', 'frozen', 'closed'

created_at TIMESTAMPTZ NOT NULL DEFAULT now()

);

CREATE TABLE ledger_entries (

id BIGSERIAL PRIMARY KEY,

transaction_id UUID NOT NULL, -- 1 トランザクションのグループキー

account_id UUID NOT NULL REFERENCES accounts(id),

direction TEXT NOT NULL, -- 'debit' or 'credit'

amount_cents BIGINT NOT NULL,

currency TEXT NOT NULL,

balance_after BIGINT NOT NULL, -- トランザクション後の残高

description TEXT,

external_ref TEXT, -- スポンサー銀行のトランザクション ID

posted_at TIMESTAMPTZ NOT NULL DEFAULT now(),

CHECK (amount_cents > 0)

);

-- 毎日の reconciliation

CREATE TABLE reconciliation_runs (

id BIGSERIAL PRIMARY KEY,

run_date DATE NOT NULL,

account_id UUID NOT NULL REFERENCES accounts(id),

internal_balance BIGINT NOT NULL, -- BaaS middleware の自前台帳残高

external_balance BIGINT NOT NULL, -- スポンサー銀行 core banking の残高

diff_cents BIGINT NOT NULL, -- internal - external

status TEXT NOT NULL, -- 'matched', 'mismatch_minor', 'mismatch_critical'

resolved_at TIMESTAMPTZ

);

CREATE INDEX idx_ledger_account_posted ON ledger_entries(account_id, posted_at DESC);

CREATE INDEX idx_recon_status ON reconciliation_runs(status, run_date DESC);

このスキーマの核心は **double-entry ledger** だ。1 トランザクションが常に借方+貸方の 2 行で入り、合計は常に 0。そして毎日スポンサー銀行の core banking system と reconcile する。mismatch が critical 水準なら即座にアラート。

OCC のガイダンスは **「この reconciliation はスポンサー銀行自身が行え」** と命令する。ミドルウェアの台帳だけを信用してはならない — Synapse 事件の最大の教訓だ。

14 章 · KYC・AML・OFAC コンプライアンス自動化

BaaS のコンプライアンス負担は大きい。ユーザー 1 人ごとに次のチェックを通過する必要がある。

1. **KYC(Know Your Customer)**: 身分証・SSN・住所・生年月日の検証。

2. **OFAC sanctions screening**: 米財務省 SDN リストとのマッチ。

3. **PEP(Politically Exposed Person)スクリーニング**: 政治的に露出した人物。

4. **Adverse media screening**: ネガティブメディア露出。

5. **CIP(Customer Identification Program)**: BSA の要求事項。

これらを自動化するベンダーが別個の市場を形成している。

- **Persona、Sumsub、Alloy**: KYC + sanction。

- **ComplyAdvantage、Refinitiv**: sanction + adverse media。

- **Socure**: ID 検証 + fraud。

- **Plaid Identity Verification**: KYC 統合。

BaaS ミドルウェアは通常、これらのベンダー 1-3 個を統合し、フィンテッククライアントに単一 API として公開する。

また取引モニタリング(Transaction Monitoring)も必須だ。AML ルールエンジンが取引パターン(例: structuring、layering)を検出し、疑わしい取引については SAR(Suspicious Activity Report)を作成する。SAR は FinCEN(米国金融犯罪取締ネットワーク)に報告する。

15 章 · 韓国の BaaS — フィンク(핀크)・Toss・カカオバンク

韓国の BaaS は米国・欧州とは異なる経路で発展した。2019 年にマイデータ・オープンバンキングが始まり、銀行 API が本格的に外部に開かれ、その流れが BaaS につながった。

**フィンク(Finnq)** — 2016 年に SK テレコム・KEB ハナ銀行が合弁で設立。マイデータベースの PFM が本業だが、2023 年から BaaS API を外部フィンテックに開放。通信キャリア結合型商品が差別化ポイント。

**Toss** — 2014 年にビバリパブリカ(Viva Republica)がスタート。Toss Bank は別途のインターネット専業銀行だが、Toss の一部 API は外部フィンテックに公開されている。自社インフラが巨大で、BaaS プロバイダーとしてよりも自社利用が多い。

**カカオバンク(Kakaobank)** — 2017 年にインターネット専業銀行。オープンバンキング以外に自社 API 50 以上を外部に公開中。外貨両替・預金・送金・カードまで。

カカオバンクのオープン API 例 — 送金 API(概念 cURL、実エンドポイントは異なる場合あり)

curl -X POST https://openapi.kakaobank.com/v2/transfer \

-H "Authorization: Bearer $ACCESS_TOKEN" \

-H "Content-Type: application/json" \

-d '{

"fromAccount": "3333-01-1234567",

"toBank": "088",

"toAccount": "110-1234-5678",

"amount": 100000,

"memo": "毎月の送金"

韓国の差別化ポイントは **インターネット専業銀行の存在** だ。カカオバンク・ケイバンク・Toss Bank は自社で銀行ライセンスを保有しており、スポンサー銀行依存度が低い。米国の BaaS ミドルウェア市場はスポンサー銀行の不足がトリガーだが、韓国はフィンテック自身が銀行になる経路が開かれている。

**主要規制**: 金融委員会・金融監督院・金融決済院が統治の主体。マイデータ導入(2022)以降、ユーザー同意に基づくデータ共有が標準となった。

16 章 · 日本の BaaS — GMO あおぞら・BANKING.JP・住信 SBI・J-Coin

日本は保守的だが BaaS が加速中だ。主要プレイヤー:

**GMO あおぞらネット銀行** — 2018 年に GMO インターネットグループとあおぞら銀行が合弁設立したインターネット銀行。BaaS の先頭走者。子会社の BANKING.JP で外部フィンテックに API 提供。

**BANKING.JP** — GMO あおぞらの BaaS ブランド。口座・送金・カードを API として。振込専用口座 API が強み。日本の決済慣行(振込)に最適化。

**住信 SBI ネット銀行** — NEOBANK ブランドで BaaS を運用。JAL Pay、Yamada NEOBANK、T NEOBANK などの外部ブランドをバックしている。

**J-Coin Pay** — みずほ銀行主導の QR 決済。外部フィンテックが J-Coin を使い決済処理を組み込める。

**Setou Bank Embedded** — 仮想の事例としてしばしば言及されるが、日本の地方銀行が組込み金融に挑戦する流れの象徴。

JPY 統合 API の特徴:

- 振込(furikomi、口座振替)がカードよりも重要。ATM・インターネットバンキングともに振込が中心。

- 振込専用口座(バーチャル口座)が核。1 事業者がユーザー数だけ振込専用口座を作り、ユーザーがそこへ送金すると事業者は自社の台帳にマッピングする。

- マイナンバー連携の KYC が標準化されてきた。

// BANKING.JP — 振込専用口座の作成 + マッチング(概念 TypeScript)

// ユーザーごとに振込専用口座を作り、入金が来たらユーザーへマッピングする

interface VirtualAccount {

virtualAccountId: string

customerId: string

bankCode: string // GMO あおぞら: '0310'

branchCode: string // 支店コード

accountNumber: string // 8 桁の振込専用口座番号

accountHolderName: string // 漢字 / カタカナ

createdAt: string

}

async function createVirtualAccount(customerId: string): Promise<VirtualAccount> {

const res = await fetch('https://api.banking.jp/v1/virtual-accounts', {

method: 'POST',

headers: {

'Authorization': `Bearer ${process.env.BANKING_JP_TOKEN}`,

'Content-Type': 'application/json',

body: JSON.stringify({

customer_id: customerId,

purpose: 'DEPOSIT',

currency: 'JPY',

}),

})

if (!res.ok) throw new Error(`virtual account creation failed: ${res.status}`)

return res.json()

}

// 入金 webhook の処理

async function handleIncomingTransfer(payload: {

virtual_account_id: string

amount: number

sender_name: string

received_at: string

}) {

const va = await db.virtualAccounts.findById(payload.virtual_account_id)

if (!va) {

// マッチ不成立 — 未紐付け入金として処理、24 時間後に返却または手動マッチ

return enqueueUnmatchedDeposit(payload)

}

await db.ledgerEntries.create({

accountId: va.customerId,

direction: 'credit',

amount: payload.amount,

currency: 'JPY',

externalRef: payload.received_at,

})

}

**規制**: 金融庁(FSA、Financial Services Agency)がガバナンスの主体。2024 年の資金決済法改正で BaaS 事業者も直接の規制対象となった。また銀行代理業のライセンスが別途必要なケースもある。

17 章 · 米国 vs EU vs KR vs JP — BaaS マトリックス

| 項目 | 米国 | EU | 韓国 | 日本 |

| --- | --- | --- | --- | --- |

18 章 · BaaS のリスク — Synapse 以後の教訓

Synapse 事件は複数のリスクを可視化した。

1. **台帳整合性**: ミドルウェアの台帳とスポンサー銀行の core banking system が reconcile しなければ終わり。

2. **FBO 口座の本質的リスク**: プールされた資金で誰がいくら持つかが不明確。

3. **FDIC pass-through の限界**: ミドルウェアが破綻すると FDIC は助けてくれない。

4. **ガバナンス不在**: 外部監査・内部統制が弱かった。

5. **スポンサー銀行の責任拡大**: Fed/OCC はスポンサー銀行にフィンテックパートナーの行動への責任を命じる。

2026 年の標準 BaaS プロバイダーのコンプライアンス姿勢:

- 毎日の台帳 reconciliation。カウンターパートのスポンサー銀行 core banking system と照合。

- ユーザー単位の sub-ledger はスポンサー銀行が別途保管。

- Adverse event の contingency plan(例: ミドルウェアまたはスポンサー銀行の財務危機時のユーザー資金保護シナリオ)。

- 外部監査(Big 4)四半期単位。

- 取締役会ガバナンス委員会。

19 章 · ACH・Wire・RTP・FedNow — 送金網の統合

米国の送金網は 4 つが核心だ。

- **ACH(Automated Clearing House)**: 1970 年代から。翌日または同営業日決済。手数料が安価。バルク取引。

- **Wire Transfer(Fedwire、CHIPS)**: 営業時間中リアルタイム。大口金額。手数料が高い。

- **RTP(Real-Time Payments)**: The Clearing House が運営。2017 年スタート。24/7。

- **FedNow**: Federal Reserve が運営。2023 年 7 月にローンチ。24/7 リアルタイム。

BaaS プロバイダーは 4 つすべてを統合し API として公開する。2025-2026 年は FedNow の採用率が急速に上昇した。

BaaS — ACH vs RTP vs FedNow のルーティング(概念コード)

def route_payment(amount_cents: int, urgency: str, recipient_routing: str) -> dict:

"""送金チャネルを自動で選択する"""

if urgency == 'instant' and supports_rtp(recipient_routing):

return {'channel': 'RTP', 'fee_cents': 25, 'eta_seconds': 10}

if urgency == 'instant' and supports_fednow(recipient_routing):

return {'channel': 'FedNow', 'fee_cents': 25, 'eta_seconds': 10}

if amount_cents >= 100_000_00: # 100,000 USD 以上は wire

return {'channel': 'WIRE', 'fee_cents': 1500, 'eta_seconds': 7200}

return {'channel': 'ACH', 'fee_cents': 5, 'eta_seconds': 86400} # 翌日

韓国はオープンバンキングの即時振替(BANK_TRAN)が標準であり、日本は全銀システムの ZEDI・全銀 EDI がコアで、近年は「ことら」24/7 送金が導入された。

20 章 · カード発行 — physical vs virtual、JIT funding パターン

カード発行は BaaS の主力プロダクトだ。2 つの形態:

- **Virtual Card**: 即時発行、即時利用可能。Apple Pay・Google Pay にプッシュ。

- **Physical Card**: 郵送で 7-10 日。EMV チップ + コンタクトレス。

発行パターン:

1. **prefund**: フィンテックがユーザー単位の残高を事前にスポンサー銀行で保有する。カード決済時に自動で差し引く。

2. **JIT funding**: カード決済時点でフィンテックの webhook を呼ぶ。フィンテックがその場で funding を判断する。

JIT funding の利点は資本効率だ。ユーザーがカードを使うときだけ資金が動くので、事前 prefund が不要だ。Brex・Ramp の中核技術である。

JIT funding のセキュリティ — webhook 署名検証(Marqeta スタイル)

def verify_marqeta_webhook(payload_raw: bytes, header_signature: str) -> bool:

secret = os.environ['MARQETA_WEBHOOK_SECRET'].encode()

expected = hmac.new(secret, payload_raw, hashlib.sha256).hexdigest()

return hmac.compare_digest(expected, header_signature)

処理ロジック

def handle_jit_request(request):

raw = request.body

sig = request.headers.get('X-Marqeta-Signature', '')

if not verify_marqeta_webhook(raw, sig):

return 401, 'invalid signature'

... 以後ユーザー残高・MCC を検証

webhook 署名検証は核心だ。検証しなければ、攻撃者が JIT レスポンスを偽造して資金を抜くことができる。

21 章 · sandbox とテスト環境 — フィンテック開発者の出発点

BaaS プロバイダー選定の最初のステップは sandbox の品質だ。Stripe Treasury・Unit・Treasury Prime は sandbox が優れている。

- **テスト ABA routing 番号、テスト SSN**、**テストカード番号** が提供される。

- **イベントシミュレーション**: ACH return、chargeback、dispute、fraud alert。

- **時間加速**: T+1 ACH を即時シミュレーション。

// Unit sandbox — ACH return のシミュレーション(概念 TypeScript)

// 本番運用では ACH return は R01(Insufficient Funds)などのイベントとして到着する

await unit.simulations.simulateAchReturn({

paymentId: 'payment_xxx',

reason: 'R01', // Insufficient Funds

})

// 自前 webhook ハンドラで R01 を処理

async function handleAchReturn(event) {

const payment = await db.payments.findById(event.paymentId)

await db.payments.update(payment.id, { status: 'returned', returnCode: event.reason })

await db.ledgerEntries.create({

transactionId: payment.transactionId,

accountId: payment.accountId,

direction: 'debit', // 再び差し引く

amountCents: payment.amount,

description: `ACH Return: ${event.reason}`,

})

}

sandbox であらゆるエッジケースをシミュレーションしてこそ本番事故を防げる。

22 章 · リアルタイム台帳更新と冪等性(idempotency)

BaaS API 運用のコアは idempotency だ。同じリクエストが二度来ても一度だけ処理しなければならない。webhook の再試行やネットワークタイムアウトがあれば常に重複の可能性がある。

- **Idempotency Key**: すべての mutating リクエストにクライアント生成の UUID をヘッダで。

- **サーバ側保存**: キーとレスポンスを DB に保存。同じキーの再リクエスト時にキャッシュしたレスポンスを返す。

- **TTL**: 通常 24-48 時間。

// Idempotency パターン — Express + PostgreSQL(概念 TypeScript)

app.post('/transfers', async (req, res) => {

const key = req.headers['idempotency-key'] as string

if (!key) return res.status(400).json({ error: 'missing Idempotency-Key' })

const cached = await db.idempotency.findUnique({ where: { key } })

if (cached) return res.status(cached.statusCode).json(cached.response)

// 新規リクエストを処理

const transfer = await createTransfer(req.body)

const response = { id: transfer.id, status: transfer.status }

await db.idempotency.create({

data: { key, statusCode: 200, response, expiresAt: new Date(Date.now() + 24 * 3600 * 1000) },

})

res.status(200).json(response)

})

このパターンが抜けると、ユーザーが 1 回送金しようとして 2 回送金される事故になる。BaaS の最大級の運用事故の一つだ。

23 章 · 韓国・日本市場の未来 — 次は何か

韓国:

- インターネット専業銀行が強い。BaaS ミドルウェアより、直接銀行になる経路が開かれている。

- フィンク・Toss・カカオバンク・ケイバンクの API 標準化が進行中。

- マイデータ(2022)とオープンバンキング(2019)がインフラ。

- 2025-2026 年のトピックは外為・海外送金の組込み化(Wirebarley、Sentbe、Moin との連携)。

日本:

- 資金決済法 2024 年改正で BaaS が明確に規制対象となった。

- GMO あおぞら・住信 SBI・みんなの銀行(Minna Bank)が BaaS バックボーンの座を競う。

- マイナンバー・マイナポータル連携でデジタル KYC が加速。

- 2026 年のトピックは J-Coin Pay・ことら(Cotra)など 24/7 送金の組込み。

米国:

- Synapse 以降、スポンサー銀行ガバナンス強化の流れは 2027-2028 年まで続く見込み。

- Fed の master account 政策が鍵となる変数。フィンテックが直接 Fed 口座を持てるか。

- バンクチャーター申請が増えている(SoFi、Square は取得済み)。ミドルウェアの自社ライセンス化の流れ。

欧州:

- Solaris・Railsr の回復後に市場は安定。Klarna・Revolut の自社ライセンス化が加速。

- PSD3(2024-2026 年に協議中)が次の標準。AISP・PISP の責任が明確化される。

24 章 · 統合チェックリスト — BaaS プロバイダーを選ぶ前に

最後に実務チェックリスト。

1. **スポンサー銀行の安定性**: 自己資本比率(Tier 1)、規制レーティング(CAMELS)、直近の consent order の有無。

2. **Multi-bank 対応**: 1 つのスポンサー銀行が停止してもマイグレーションできるか。

3. **台帳モデル**: double-entry、毎日の reconciliation、sub-ledger の保管場所。

4. **コンプライアンス自動化**: KYC、OFAC、transaction monitoring、SAR の自動化。

5. **API 品質**: ドキュメント、SDK、sandbox、webhook の安定性、idempotency 対応。

6. **カード発行**: virtual/physical、JIT funding 対応、Apple/Google Pay プッシュ。

7. **送金チャネル**: ACH、wire、RTP、FedNow をすべて対応。

8. **グローバル対応**: 米国以外への進出計画がある場合。

9. **コストモデル**: per-account、per-transaction、月額ミニマム。

10. **データ抽出**: account・transaction を API/Webhook/CSV で取得できるか。

11. **Adverse event のシナリオ**: ミドルウェアまたはスポンサー銀行の危機時の対処マニュアル。

12. **法的構造**: FBO 口座 vs sub-account、FDIC pass-through 適用可否。

13. **外部監査**: Big 4 監査、SOC 2 Type II 保有の有無。

14. **カスタマーサポート**: 24/7 運用、エスカレーション経路、postmortem の公開方針。

15. **共同責任(Synapse の教訓)**: ミドルウェア vs スポンサー銀行の責任分担の契約条項の明確化。

この 15 項目が 2026 年の BaaS プロバイダー評価の標準だ。Synapse 事件が残した最大の教訓は、**「BaaS は単なる API ではなく、資金の安全と信頼のインフラ」** ということだ。素早くローンチできるという利点の陰に、深いガバナンス負担がある。その負担を正確に理解できないフィンテックは、Yotta のユーザーたちのように、自社ユーザーへ謝罪する日が来るかもしれない。

References

- Solaris — [https://www.solarisgroup.com/](https://www.solarisgroup.com/)

- Treasury Prime — [https://www.treasuryprime.com/](https://www.treasuryprime.com/)

- Unit — [https://www.unit.co/](https://www.unit.co/)

- Synctera — [https://www.synctera.com/](https://www.synctera.com/)

- Galileo Financial Technologies — [https://www.galileo-ft.com/](https://www.galileo-ft.com/)

- Marqeta — [https://www.marqeta.com/](https://www.marqeta.com/)

- Stripe Treasury — [https://stripe.com/treasury](https://stripe.com/treasury)

- Adyen for Platforms — [https://www.adyen.com/platforms](https://www.adyen.com/platforms)

- Federal Reserve Board (Evolve consent order, 2024) — [https://www.federalreserve.gov/newsevents/pressreleases/enforcement20240614a.htm](https://www.federalreserve.gov/newsevents/pressreleases/enforcement20240614a.htm)

- OCC Third-Party Risk Management — [https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html](https://www.occ.gov/news-issuances/news-releases/2023/nr-ia-2023-53.html)

- FDIC Pass-Through Deposit Insurance Coverage — [https://www.fdic.gov/resources/deposit-insurance/brochures/insured-deposits/](https://www.fdic.gov/resources/deposit-insurance/brochures/insured-deposits/)

- Synapse Bankruptcy Court Filings (US Bankruptcy Court, Central District of California) — [https://www.pacer.gov/](https://www.pacer.gov/)

- Jelena McWilliams (Synapse Trustee, ex-FDIC Chair) — [https://www.fdic.gov/about/leadership/mcwilliams.html](https://www.fdic.gov/about/leadership/mcwilliams.html)

- CFPB 1033 (Open Banking, US) — [https://www.consumerfinance.gov/rules-policy/regulations/1033/](https://www.consumerfinance.gov/rules-policy/regulations/1033/)

- BaFin (German Federal Financial Supervisory Authority) — [https://www.bafin.de/EN/](https://www.bafin.de/EN/)

- Finnq(フィンク) — [https://www.finnq.com/](https://www.finnq.com/)

- Toss — [https://toss.im/](https://toss.im/)

- Kakaobank(カカオバンク) — [https://www.kakaobank.com/](https://www.kakaobank.com/)

- 韓国金融監督院(FSS) — [https://www.fss.or.kr/](https://www.fss.or.kr/)

- 韓国金融決済院(KFTC、オープンバンキング) — [https://www.kftc.or.kr/](https://www.kftc.or.kr/)

- GMO あおぞらネット銀行 — [https://gmo-aozora.com/](https://gmo-aozora.com/)

- BANKING.JP — [https://corp.banking.jp/](https://corp.banking.jp/)

- 住信 SBI ネット銀行 — [https://www.netbk.co.jp/](https://www.netbk.co.jp/)

- 金融庁(Japan FSA) — [https://www.fsa.go.jp/en/](https://www.fsa.go.jp/en/)

- Mercury — [https://mercury.com/](https://mercury.com/)

- Brex — [https://www.brex.com/](https://www.brex.com/)

- Ramp — [https://ramp.com/](https://ramp.com/)

- Chime — [https://www.chime.com/](https://www.chime.com/)