現場ノート

コアバンキングとBaaS:実際に何を買うのか

コアバンキングは、お金の記録システムです。すべての口座、残高、記帳を保持する台帳と、それらの間で価値を正しく移動させるルールで構成されます。Banking-as-a-Service(BaaS)は、自社でコアを運用する代わりに、他社のコアとその背後にある規制上の許可をAPI経由で借りる仕組みです。コアの所有から代理店登録に乗る形までには幅があり、どこに位置するかによって、何を構築し、何を借り、何の責任を負うかが決まります。「コアバンキング vs BaaS」は、実際にはプロダクト比較ではなく、スタックのどこまでを自社で持ちたいかという問いです。

この2つは同じ売り場で探されがちなので、整理しておく価値があります。実際は別物です。一方は正確でなければならないソフトウェアで、もう一方は、正確性をサービスとして提供し、その対価を請求する商取引上の取り決めです。自分が何を買おうとしているのか、そして実際に何が必要なのかを見極めることが、判断の大半を占めます。

「コアバンキング」が指すもの

コアバンキングシステムは、記録の台帳とそれを取り巻く仕組みです。勘定科目体系を保持し、残高を管理し、借方と貸方が常に一致するようにすべての記帳を複式簿記で記録し、保留の設定と解除を行い、利息と手数料を計上し、下流のあらゆるものが参照する明細を生成します。台帳が間違っていれば、その上に構築したものは何も信頼できなくなるため、銀行の中で最も正確さが求められる部分です。それ以外のアプリ、カードのデザイン、通知はすべて表示にすぎません。コアが真実です。

最初に押さえるべき区別は、コアはアプリではないということです。顧客にはアプリが見えますが、その裏では何らかの台帳が記録をつけています。その台帳は、所有することも、借りることも、所有者に乗ることもできます。この3つの選択肢が、先ほどの幅にあたります。

選択肢の幅:自社コア、BaaS、代理店

最も重い端では、コアを完全に所有します。自社の台帳、お金を保有または移動させる自社の許可、決済レールへの直接接続です。中間にあるのがBaaSで、認可を受けた事業者がコアと許可を保有し、皆さんはそのAPIに対して構築します。口座、IBAN、カードは先方のもので、そこに自社のブランドを載せます。最も軽い端が代理店モデルで、自社ではコアもライセンスも持たず、自分を登録した認可事業者のもとで事業を行います。一段下がるごとに、できることが減り、それに伴ってコストと義務も軽くなります。

自社コアを持つ:コントロールとその代償

コアを所有すれば、コントロールを得られます。プロダクトロードマップは、プロバイダーの都合を待たずに自分で決められます。口座を直接保有し、レールに直接接続でき、ユニットエコノミクスも他社の上乗せ分に左右されなくなります。規模が大きくなれば、BaaSプロバイダーに支払っていたはずの口座単位・取引単位の使用料が、手元に残る利益になります。意思決定と、それが反映される台帳の間に、何も挟まりません。

代償は大きく、その大半はソフトウェアではありません。規制上の許可(ソフトウェアとは別の購入で、しかも難しいのは多くの場合こちらです。分別管理、インターチェンジ、決済に関する用語は /glossary にまとめています)、その許可が求める資本、運用するためのコンプライアンスとオペレーションの人員、関わるすべてのレールとスキームとの直接連携が必要です。そして正確性の責任も自社に移ります。午前2時に台帳が間違っていても、電話できるプロバイダーはいません。真実を所有するということは、障害も所有するということです。

BaaS:コアと許可を借りる

BaaSは、その負担を月々の関係に集約します。認可を受けたパートナーが口座を保有し、IBANとカードを発行し、預かり資金を分別管理し、規制当局に対して責任を負います。皆さんはそのAPIに対してアプリを構築し、リリースするだけです。得られるのはスピードで、ライセンス申請や台帳プロジェクトの代わりに、許可を備えた稼働中のコアが初日から手に入ります。最初のプロダクトを立ち上げるほとんどのチームにとって、この取引が正解です。

手放すのは所有権です。プロバイダーの収益構造が自社のコストの下限になります。口座単位・取引単位で支払い、その手数料は、自社インフラのように成長に応じて下がることはありません。プロバイダーの制限は自社の制限になり、先方のロードマップが自社のロードマップを左右します。台帳も自社のものではないため、乗り換えにはコストがかかり、移行はそれ自体が一つのプロジェクトになります。BaaSは、銀行の正確な部分を借りることです。賃料は始めるには安く、しかし払い続けることになります。

所有するコアは、規模が大きくなって回収できる資本プロジェクトです。借りるコアは、決して下がらない運営コストです。問うべきはどちらが優れているかではなく、自社の取引量と利益率が、すでにどちらに見合っているかです。
— Protocore · 決済エンジニアリング

代理店モデル:最も軽い選択肢

さらに軽いのが代理店モデルで、お金に関する部分は、ほとんど何も構築する必要がありません。決済機関の代理店、または電子マネー発行者の販売代理人として登録すると、その事業者のライセンスが自社の活動をカバーし、先方のコアが台帳を保持し、規制当局はその事業者を通じて自社を把握します。ブランド付きの金融プロダクトを最速で顧客に届けられる方法ですが、コントロールは最も小さくなります。他社のレール上の顔にすぎず、先方の条件が自社の上限になります。

自社コア上のwhitelabelプラットフォームの位置づけ

この幅には現れない4つ目の位置があります。コアは自社で持ちながら、アプリ層はゼロから構築しないという形です。規制上の許可と、それに指図を出すソフトウェアは別々の購入であり、自社ライセンスを保有したまま、顧客向けアプリ、オペレーターコンソール、テーマ設定をプラットフォームとして上に導入できます。whitelabelプラットフォームが位置づけられるのは、まさにここです。Protocore Pay (/products/pay) は、ソフトウェア層だけを提供します。ブランド付きのアプリプラットフォームとオペレーターコンソールで、自社保有でもパートナー経由でも、持ち込まれたコアとレールの上で動作し、ライセンスを販売に結び付けません。付属のコンソールは、すべての特権操作に理由が必要で、監査ログに記録されるProtocore Center (/products/center) です。

このように整理すると、2つの商品を別々に値付けできるため、考え方がはっきりします。許認可は、管轄、顧客資金の保全、契約条件で評価されます。ソフトウェアは、オンボーディングが機能するか、台帳連携が整理されているか、運用担当者が実際に回せるかで評価されます。ソフトウェアを買ってもライセンスを取得したことにはならず、ライセンスを取得してもアプリが手に入るわけではありません。この2つを混同すると、気づかないうちにプロジェクトが数か月遅れることになります。

自社に合った段階の選び方

現実的な判断基準は、取引量、マージン、コントロールの3点です。立ち上げ期で需要が読めず、スピードを優先したいなら、BaaSまたはエージェント登録で、資金調達なしにサービスを開始できます。その場合、取引ごとの利用料はスピードの対価として受け入れることになります。事業が成長し、取引量が増えて、自前のコンプライアンスとインフラにかかるコストより利用料のほうが大きくなり、さらにプロバイダーがロードマップの実現を阻むようになったとき、コア自社保有が採算に乗り始めます。多くのプロダクトは、まず借りる形で始め、自社保有へ移行するのは一度きりです。資本と人員のコストが利用料を下回ると数字が示したときです。

ここまでの内容は法的助言ではなく、区分の呼び方も管轄によって異なります。規制当局や専門家と話すときの地図として使い、代わりにはしないでください。ただし、構造はどこでも変わりません。コアバンキングは正確でなければならない台帳であり、BaaSはその正確さを月額で借りるものであり、whitelabelプラットフォームはどちらを選んでもその上に載せるソフトウェアです。取引量に見合った段階を選び、ソフトウェアと許認可は、もともとそうであった別々のものとして調達してください。

システム開発をご検討中ですか?

課題をお聞かせください。アーキテクチャと計画をご提案します。