現場ノート

ホワイトラベル型ネオバンクプラットフォーム購入ガイド

ホワイトラベル型ネオバンクプラットフォームとは、自社ブランドを冠して、口座、カード、送金、場合によっては暗号資産まで備えたバンキング型アプリを、コアをゼロから作らずに立ち上げられるソフトウェアです。これを購入することは、実は混同しやすい2つのものを買うことでもあります。お金を動かすコアと、顧客が目にするアプリ層です。本ガイドは、契約前にこの2つを見分けるためのものです。ホワイトラベルプラットフォームに関する難しい問いは、ほぼすべて「境目がどこにあるか」という問いに行き着くからです。ベンダーはその境界を曖昧にするのが仕事で、購入者はそれを見つけるのが仕事です。

契約前に押さえたい切り口は5つあります。コアとアプリ層、ライセンスの所在、デザインシステムの深さ、スタンドアロンか組み込みかという提供形態、そしてそのすべての根底にある内製か導入かの判断です。順に見ていきましょう。

第1の切り口:コアとアプリ層

最も有用な線引きは、正確でなければならない部分と、自社のものでなければならない部分の間にあります。コアは間違えたときの代償が大きい領域です。複式簿記の元帳、口座と残高、KYCとオンボーディング、カード発行と処理、暗号資産・ステーブルコインのレール、そしてそれらを支えるオペレーターコンソールが含まれます。アプリ層は顧客が触れる部分で、ブランド、画面、情報設計、有効化する機能の組み合わせです。購入に値するプラットフォームは、全ブランドで1つのコアを共有し、アプリをテナントごとに設定します。評価の軸は両者で異なります。コアは正確性で判断します。元帳が本物の複式簿記か、照合が成立するか、オペレーターが実際に運用できるかです。アプリ層は柔軟性で判断します。フォークが必要になるまでに、ブランドがどこまで差別化できるかです。

ライセンスの所在と、分離できるかどうか

資金の保有や移動の許可は規制対象であり、ソフトウェアとは別の購入物です。プラットフォームに規制上の許認可が含まれているのか、それとも自社で用意する前提なのかを、率直に確認してください。含まれる場合は、誰のライセンスで、どの国で有効か、そして自社が直接の顧客なのか代理店なのかも確認が必要です。購入者にとって重要なのは分離性です。単一のライセンスにソフトウェアが固く結びついていて差し替えられないプラットフォームは、管轄区域もパートナーも、知らぬ間に自社に代わって決めてしまっています。一方、ライセンスを持ち込むレールとして扱うプラットフォームなら、許認可を独立して選べ、後から入れ替えることもできます。どちらが誤りというわけではありませんが、自分がどちらを買うのかは把握しておく必要があります。Protocore Pay(/products/pay)はソフトウェア層のみを提供し、お客様が用意する規制対象のレール上で動作します。ソフトウェアはライセンスの代わりにはなりません。その話し合いで出てくる概念、EMI、決済機関、代理店、スポンサーバンクについては /glossary にまとめています。

デザインシステムの深さ

ホワイトラベルの約束は、アプリがベンダーのデモの着せ替えではなく、自社のものに見えることです。その約束は、土台となるデザインシステムの深さまでしか守られません。浅いものでは、ロゴとアクセントカラーを差し替えられる程度です。深いものは、色、タイポグラフィ、角丸、余白、密度、モーションといった実際の語彙を、すべての画面が参照するトークンとして公開します。ブランドはフォークではなく、上書きの集合になります。確認すべきは、トークンがいくつあり何を網羅しているか、同じトークンがWeb、ネイティブ、デスクトップに出力され、色がどこでも同じ色になるか、そしてデザイナーがコードに触れずに、テナントをリファレンスビルドから大きく離せるかです。Protocoreのデザインシステム(/products/pds)はその一例で、144個のトークンと889個のユーティリティクラスを備え、ダークファースト、角丸はデフォルトでゼロ、Web、.NET、ネイティブ向けに出力されます。ただし購入者が問うべきは一般的な問いです。そのデザイン層は本物のトークンシステムか、それとも固定されたアプリに塗っただけの塗装か。

スタンドアロンアプリか、組み込みレイヤーか

提供形態は2つあります。スタンドアロンアプリは、自社ブランドで自社名義でリリースする完全なバンキングアプリで、顧客は自社の銀行をダウンロードします。組み込みレイヤーは、すでにある自社プロダクトに組み込むコンポーネントとフローの集合で、決済や残高が既存アプリの中に存在します。選択の基準は品質ではなく、お金の体験がどこにあるべきかです。バンキングそのものがプロダクトなら、スタンドアロン版が適しています。マーケットプレイスが出品者へ支払う、プラットフォームがユーザーにウォレットを提供するなど、バンキングがより大きなプロダクトの一機能であるなら、組み込みが適しています。お金が、顧客がすでにいる場所にあるからです。購入に値するプラットフォームは、1つのコアから両方を提供できます。コアにとっては、フロントエンドがスタンドアロンアプリであっても、他社アプリ内のパネルであっても関係ないからです。

内製か導入か、率直なトレードオフ

コアを自社で作れば、コントロールは得られますが、何年もかかります。正確な元帳、カード処理、KYC、照合、オペレーターコンソールは、それぞれが1つのプロジェクトです。しかもどれも、顧客が気づく機能を1つ出す前に越えておくべき最低条件にすぎません。コアを導入すれば、その年月を買い戻せますが、主導権の一部を手放します。口座、限度額、決済について、他社のモデルを受け入れることになるからです。正直な判断方法は、どの部分が自社のプロダクトで、どの部分が配管なのかを問うことです。決済、照合、コンプライアンスツールといった配管は、誰にとってもほぼ同じで、そこで差がつくことはまずありません。導入すべき領域です。顧客が実際に自社を選ぶ理由であるフロー、ブランド、既存勢力より優れた強みにこそ、自社のエンジニアが全力を注ぐべきです。プラットフォームを購入するとは、コアは配管であり、差別化はその上にあるという賭けです。

買っているのはネオバンクではありません。配管であってほしいコアと、自社のものにしたいアプリ層を買っているのです。評価とは結局のところ、ベンダーがその線を自社の引きたい場所に引いているかどうかを見極めることです。
— Protocore · プラットフォームエンジニアリング

5つのプロダクトではなく、5つの方向性

ベンダーに事例を求めると、完成したアプリがいくつか示されることがよくあります。それは、メニューから1つ選ぶ商品ではなく、同じコアが取りうる方向性として読んでください。あるプラットフォームのリファレンスコアは、取引を前面に出した控えめな取引所(Halcyon)、会話の中でお金が動くチャット中心のスーパーアプリ(Lumen)、一括支払いとルールベースの通貨変換を軸にした送金型アプリ(Fern)、給与の振り分けとチームカードを備えたステーブルコインのダークビルド(Volt)、USDC と並ぶ EUR 残高とカード特典が貯まる BTC 口座を持つマルチカレンシー口座(Meridian)のいずれにもなりえます。5つのブランド、5つの情報設計、5つの機能構成でありながら、そのすべての土台に1つの元帳、1つのKYC、1つのカードプロセッサーがあります。重要なのは5という数字ではなく、コアが何テナントまで載せられるかです。プロダクトは5つのアプリだと語るベンダーは、自社製品を理解していません。6つ目が容易であることを示すために5つを見せるベンダーは、理解しています。

ベンダーを見極める質問

短いチェックリストがあれば、売り込みの大半は見抜けます。コアは単一の共有システムですか、それとも顧客ごとのフォークですか。バグが修正されたとき、その修正はすべてのテナントに一度に届きますか。デザインレイヤーは実際のトークンを公開していますか、それともロゴを差し込む枠だけですか。プラットフォームには規制上の許認可が含まれていますか、それとも自社で用意する必要があり、後から差し替えることはできますか。同じコアで、スタンドアロンアプリと組み込みレイヤーの両方を提供できますか。どこまでを基盤部分と捉え、どこからを自社で構築すべきと考えていますか。これらの答えから、本ガイドが描いてきたマップ上のベンダーの位置が見えてきます。共有コアかフォークの乱立か、トークンシステムか塗装だけか、ソフトウェア+自社ライセンスか一体型の抱き合わせか、提供形態は一つか二つか。こうしたコアの一例について、5つの方向性、リファレンスアプリ、それらを支えるオペレーターコンソールまで詳しく解説したページは /products/pay、その土台となるデザインシステムは /products/pds、用語は /glossary にあります。

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

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