1つのコア、多数のアプリ：ホワイトレーベル・バンキングプラットフォームの仕組み
ホワイトレーベル・バンキングプラットフォームとは、フロントエンドを差し替えられる1つのバンキングコアです。コアは正確でなければならない部分で、複式簿記の元帳、顧客口座、KYC とオンボーディング、カードの発行と処理、暗号資産とステーブルコインのレール、そのすべての裏で動くオペレーターコンソールを含みます。アプリは顧客の目に触れる部分で、名前、色、画面の形、有効にする機能の組み合わせがそれにあたります。ホワイトレーベルとは、1つのコアが、作り直すことなく多くの顔を持てるということです。1つのコア、多数のアプリ。
端的に言えば、継ぎ目をどこに置くかという話です。お金に関わるものはすべて共有し、監査し、照合は一度だけ行います。顧客に関わるものは、テナントごとに設定します。重要なのは、この境界線を守り抜くことです。フロントエンドは自由に違っていてよく、それを支えるコアは決してフォークしません。ここでは、その境界線をどう引くのか、そしてフォークではなくデザイントークンで引くほうが優れている理由を分解して見ていきます。
決して変わらないもの：コア
まず、創造性が許されない側から始めます。アプリが「送金」「支払い」「出金」のどう呼んでいても、取引は同じ方法で記帳されます。複式簿記の元帳に2つの仕訳が入り、何も削除されません。元帳は追記のみなので、返金は元の取引を参照する反対仕訳であり、消去ではありません。口座、残高、オーソリ保留はここにあります。KYC とオンボーディング、カードの発行と決済、暗号資産とステーブルコインのレールも同様です。その裏には1つのオペレーターコンソールがあり、特権操作にはすべて理由の入力が必須で、監査ログに記録されます。
これらはそれぞれ1つだけ存在し、そこに意味があります。決済、照合、コンプライアンスは正しく作るのが難しく、間違えると高くつくため、一度だけ作って全アプリがその成果を引き継ぎます。テナントが顧客をオンボーディングするとき、コアが判定した KYC ティアは、どのアプリの画面で書類を取得したかにかかわらず、その顧客に付いてコンソールに届きます。コアは、上に載るアプリの名前を知りませんし、気にもしません。見ているのはブランドではなく、口座と仕訳です。
変わるもの：デザイン言語、情報設計、機能の組み合わせ
コアより上のものは、3つの軸に沿って自由に動かせます。1つ目はデザイン言語で、色、タイポグラフィ、角丸、余白、モーションといった、ブランドの視覚的な文法です。2つ目は情報設計で、ホーム画面に何を置くか、フローをどう命名し並べるか、どの操作をワンタップにしてどれを3タップにするかです。3つ目は機能の組み合わせで、どのモジュールをそもそも有効にするかです。シンプルな送金アプリも、情報量の多いスーパーアプリも、まったく同じコアの上で動き、画面は1つも共有しないことができます。
/products/pay の製品ページでは5つの実例を紹介していますが、5つから選ぶメニューというより、無数にある可能性の例として読むのが最適です。Halcyon はすっきりした取引所で、控えめで画面数が少なく、取引が中心にあります。Lumen は会話の中でお金が動くスーパーアプリで、チャット決済、サブスクリプション、earn がホーム画面を共有します。Fern は送金を前面に出し、一括出金とルールベースの FX 両替を最初に置きます。Volt はステーブルコイン中心のダークな構成で、給与の振り分け機能とチームカードを備えます。Meridian はマルチカレンシーで、EUR 口座と USDC、GBP の旅行用残高、カード特典が入る BTC 口座が並びます。5つのブランド、5つの情報設計、5つの機能の組み合わせ。そのすべての下に、1つの元帳、1つの KYC、1つのカードプロセッサーがあります。
だからといって、製品が5つのアプリということではありません。5つは同じパイプラインが取りうる方向性であり、重要なのは5ではなく、オンボーディングするテナントの数です。それぞれが、ホーム画面の形に至るまでフロントエンドが違っていても、その下のコアは何も気づかないことの証明です。
コアは再発明してはならない部分であり、アプリは制約してはならない部分です。ホワイトレーベルプラットフォームとは、この2つの文を同時に成り立たせ続ける規律のことです。
フォークよりトークンレベルのテーマ設定が優れている理由
1つの製品を多くの製品に見せる方法は2つあります。分かりやすいのはフォークです。顧客ごとにコードベースをコピーし、見た目を変えて出荷します。これがうまくいくのは最初のリリースだけです。その後は、バグ修正も規制対応もN個のコピーすべてに適用しなければならず、コピーは少しずつずれて同期を失い、検討すべきセキュリティ面は顧客数の分だけ増えます。フォークは、理解できている1つのシステムを、理解できない多数のシステムに変えてしまいます。
トークンレベルのテーマ設定は、これを逆転させます。コードベースは1つです。ブランドとは一組の値であり、色、書体、角丸、余白のトークン、コンポーネント設定、フィーチャーフラグのセットがビルド時に解決されて、ブランド付きのアプリになります。トークンを変更すれば、それを参照するすべての画面が一緒に動きます。トークンから取得すべき値をハードコードしている箇所がないからです。送金フローの修正は、直すべき送金フローが1つしかないので、全テナントに一度に届きます。ブランド間の違いは設定にあり、ソースにはありません。
デザインシステムの位置づけ
トークンは漠然とした考え方ではなく、出荷される成果物です。Protocore Design System（/products/pds）は、144個のデザイントークンと889個のユーティリティクラスで構成され、すべてのアプリのテーマ設定に使う語彙です。ダークファーストでトークン駆動、デフォルトは角丸ゼロです。同じトークンセットが Web、.NET、ネイティブ向けに出力されるため、一度定義した色は、React の画面でも、デスクトップのコンソールでも、ネイティブのモバイルビルドでも同じ色になります。テナントのブランドはこの語彙に対する上書きとして表現されるので、アプリの見た目の刷新は書き換えではなく、設定変更で済みます。
だからこそ、フロントエンドはテンプレートの範囲内ではなく、本当に自由になります。デザイン言語が、場当たり的なスタイルシートではなくトークンとユーティリティクラスにあるため、デザイナーはコアに触れることもアプリをフォークすることもなく、リファレンスビルドから大きく離れたテナントを作れます。独自のパレット、書体、密度、リズムです。塗装は深くまで及びますが、それでも塗装にすぎません。その下の配管は共有されています。
アプリはビルドではなく設定
機能の組み合わせにも同じ原則が当てはまります。チャット決済、earn、暗号資産、カード、サブスクリプション、チームカード、リファラルといったすべてのモジュールは、テナントごとに切り替えるスイッチです。フラグは、全体に広げる前に一部のユーザーだけに展開することもできます。オペレーターは、デプロイではなく設定パネルから切り替えます。つまり、最小限の送金アプリと本格的なスーパーアプリの違いは、2つのプロジェクトではなく、1つのプロジェクトの2つの設定です。すべてのテナントが出発点とするリファレンスアプリは、Protocore ブランドのニュートラルなビルドで、全メニューが揃っています。各ホワイトレーベルは、そのビルドのトークンを上書きし、モジュールをオン・オフしたものです。
率直な境界線
1つのコアに多数のアプリという仕組みが手間に見合うのは、実際に多くのアプリがある場合、あるいは、銀行を毎回作り直すことなく、1つのアプリのデザイン、構成、スコープを時間をかけて変えていく場合だけです。2つ目のブランドをまとうことのない固定のアプリを1つ出荷するだけなら、ホワイトレーベルプラットフォームは不要で、必要なのはアプリです。真価を発揮するのは、想定されたケースです。ブランド付きのバンキング製品をテナントごとに立ち上げ、それぞれが明らかに独自のもので、どれもフォークではないプラットフォームです。5つの方向性、リファレンスアプリ、その裏のオペレーターコンソールを含む詳しい分解は /products/pay に、その下のデザインシステムは /products/pds にあります。