API バンキング & BaaS 2026 — Solaris・Synapse・Treasury Prime・Unit・Galileo・Marqeta・Stripe Treasury 徹底ガイド

プロローグ — 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 モデルである。

この 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 例(概念コード)
import { TreasuryPrime } from '@treasuryprime/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)
import { Unit } from '@unit-finance/unit-node-sdk'

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 カード発行
import stripe
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 ミドルウェア比較マトリックス

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

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 マトリックス

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 スタイル)
import hashlib
import hmac
import os

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/
• Treasury Prime — https://www.treasuryprime.com/
• Unit — https://www.unit.co/
• Synctera — https://www.synctera.com/
• Galileo Financial Technologies — https://www.galileo-ft.com/
• Marqeta — https://www.marqeta.com/
• Stripe Treasury — https://stripe.com/treasury
• Adyen for Platforms — https://www.adyen.com/platforms
• Federal Reserve Board (Evolve consent order, 2024) — 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
• FDIC Pass-Through Deposit Insurance Coverage — 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/
• Jelena McWilliams (Synapse Trustee, ex-FDIC Chair) — https://www.fdic.gov/about/leadership/mcwilliams.html
• CFPB 1033 (Open Banking, US) — https://www.consumerfinance.gov/rules-policy/regulations/1033/
• BaFin (German Federal Financial Supervisory Authority) — https://www.bafin.de/EN/
• Finnq(フィンク) — https://www.finnq.com/
• Toss — https://toss.im/
• Kakaobank(カカオバンク) — https://www.kakaobank.com/
• 韓国 金融監督院(FSS) — https://www.fss.or.kr/
• 韓国 金融決済院(KFTC、オープンバンキング) — https://www.kftc.or.kr/
• GMO あおぞらネット銀行 — https://gmo-aozora.com/
• BANKING.JP — https://corp.banking.jp/
• 住信 SBI ネット銀行 — https://www.netbk.co.jp/
• 金融庁(Japan FSA) — https://www.fsa.go.jp/en/
• Mercury — https://mercury.com/
• Brex — https://www.brex.com/
• Ramp — https://ramp.com/
• Chime — https://www.chime.com/