プラットフォームアーキテクチャ

ひとつのコア、多様なサーフェス。プラットフォームの実際の仕組み。

台帳を起点に、プラットフォームを順に見ていきます。単一の複式簿記コアを共有するアカウント、KYC、カード、暗号資産。1件の決済が作成から照合まで進む流れ。そして、アプリ層、オペレーターコンソール、規制の境界線がそれぞれどこに位置するのか。

コア

すべての基盤となる、ひとつの台帳。

プラットフォームの中心にあるのは、単一のアカウント台帳です。顧客ウォレット、加盟店残高、手数料アカウント、決済用アカウントなど、すべてのアカウントはこの台帳上のノードであり、価値の移動はすべて複式記帳として記録されます。一方を借方に、もう一方を貸方に計上し、両側は常に一致します。台帳は追記専用です。エントリは編集も削除もされず、訂正は逆向きの新しいエントリとして記録されるため、残高が現在の値に至った経緯の全履歴をいつでも再構築できます。アカウント、KYCの状態、発行済みカード、暗号資産アドレスはすべて同じアカウントモデルに紐づきます。そのため、カードのオーソリ、銀行振込、オンチェーン入金を、別々のシステムをつなぎ合わせる照合レイヤーなしに、ひとつの残高へ反映できます。

  1. 01複式簿記:すべての記帳が均衡し、借方と貸方が一致
  2. 02追記専用:訂正は新規エントリで行い、編集はしない
  3. 03法定通貨、カード、暗号資産を単一のアカウントモデルで管理
  4. 04KYCの状態は別テーブルではなくアカウントと一体で管理

決済のエンドツーエンド

1件の決済を、作成から照合まで。

決済は1回の呼び出しではなく、短いライフサイクルです。各段階は、台帳とお客様のシステムの双方から確認できる状態です。状態が変わるたびにWebhookが送信され、すべての書き込みは冪等です。同じキーでの再送は同じ結果になるため、リトライしても二重請求は起こりません。

  1. 01

    作成

    インテントを作成します。金額、通貨、関係するアカウントを指定します。この時点では資金は動かず、台帳には保留中のエントリが記録されます。

  2. 02

    オーソリ

    レールが残高とリスクを確認し、ホールドをかけます。カードの場合はオーソリゼーション、振込の場合は引き落とし額の確保にあたります。

  3. 03

    キャプチャ

    ホールドしていた金額を確定します。台帳が複式記帳を行い、2つのアカウント間で実際に価値が移動します。

  4. 04

    決済

    カードスキーム、銀行、チェーンなど基盤となるレールを通じて資金が清算され、決済用アカウントが実際の資金と照合されます。

  5. 05

    照合

    プラットフォームは、自らの記帳内容をレールの決済レポートと突き合わせます。一致しないものは、隠さずフラグを立てて示します。

このフローのあらゆる接点で、Webhookと冪等性が機能します。お客様のシステムは、ポーリングではなくイベントの受信によって決済の進行を把握できます。タイムアウト後に再送したリクエストも、idempotency keyによって同じ結果に解決されるため、再送しても二重請求は発生しません。オーソリとキャプチャを実行するサービスがペイメントゲートウェイ.

アプリ層

上にはホワイトレーベルアプリ、下にはひとつのプラットフォーム。

コアは機能を提供し、アプリ層がそれを製品に仕立てます。Webとモバイルの各顧客向けアプリは、同じアカウント、決済、カードを自社ブランドで表示するホワイトレーベルのクライアントです。テーマ設定はトークン駆動で、色、書体、角丸、余白はデザイントークンシステム(PDS)で定義されます。そのため、オペレーターはアプリをフォークせず、トークンを変更するだけで全画面のデザインを刷新できます。同じプラットフォームを、コンシューマー向けネオバンク、加盟店向けアクワイアリングアプリ、カード発行プログラム、暗号資産のオン/オフランプ、社内オペレーションツールなど、まったく異なる方向へ展開できます。5つの別製品になることはありません。ひとつのプラットフォームが異なる外観をまとい、それぞれを作り直すのではなく設定で構成します。

  1. 01共通APIの上に構築するホワイトレーベルのWeb/モバイルクライアント
  2. 02トークン駆動のテーマ設定(PDS):フォークせず、設定でデザイン変更
  3. 03想定される5つの方向性:ネオバンク、アクワイアリング、イシュイング、ランプ、オペレーション
  4. 04新しいサーフェスは作り直さず、設定で構成

オペレーション

コンソールから運用し、理由を記録に残す。

すべてのアプリの裏側には、オペレーターコンソールがあります。サポート担当者がアカウントを検索し、リスクアナリストがカードを凍結し、オペレーション責任者が記帳を取り消す、そのための場所です。閲覧権限は広く、特権操作は限定されます。資金の移動、限度額の変更、顧客資金に関わる操作は、実行前に理由の入力が必須で、誰が、何に対して、いつ、なぜ行ったかを改ざん不能な監査ログに記録します。アクセスは最小権限の原則に従い、各オペレーターは自分の役割で許可された範囲だけを閲覧・操作できます。これはオペレーターコンソールであるProtocore Centerのモデルであり、同じ考え方がプラットフォーム上のすべてのシステムに組み込まれています。重要な操作は意図的で、実行者が特定でき、事後に検証できます。

  1. 01閲覧は広く、書き込みは制限。特権操作は例外
  2. 02資金に関わる操作は、実行前に理由の入力が必須
  3. 03改ざん不能な監査証跡:誰が、何を、いつ、なぜ
  4. 04オペレーターの役割ごとの最小権限

暗号資産ブリッジ

暗号資産と法定通貨を、同じ台帳で。

プラットフォームにおいて、暗号資産は独立したサイロではありません。暗号資産アドレスは、同じ台帳上のひとつのアカウントにすぎません。オン/オフランプは、境界部分で法定通貨とデジタル資産を相互に変換します。顧客はカードや振込で残高に入金して暗号資産を受け取ることも、暗号資産を売却して銀行口座へ出金することもできます。オンチェーンの価値は銀行レールまで決済できます。受け取ったオンチェーン決済はアカウントに入金され、変換されたうえでIBANへ支払われるため、受取人は通常の銀行口座に通常のお金として受け取ります。両方のレッグが単一の複式簿記台帳に記帳されるので、オンチェーンで始まり銀行振込で終わる資金移動も、手作業で突き合わせる2つのシステムではなく、照合済みのひとつの履歴になります。

  1. 01暗号資産アドレスも、通常のアカウントのひとつ
  2. 02オン/オフランプ:法定通貨とデジタル資産を境界で変換
  3. 03オンチェーン決済からIBANへの出金まで一気通貫
  4. 04両レッグを通じて、照合済みのひとつの履歴

ビルド環境

APIとWebhook、そして開発用のサンドボックス。

アプリが行うことはすべて、ドキュメント化されたAPI経由で実行されます。アカウントの作成、決済の開始、カードの発行、ランプの開始など、すべて同じです。呼び出しの例としては POST /v1/wallets や POST /v1/payments があります。形式はRESTで、すべての書き込みにidempotency keyを付与します。状態の変化はWebhookで通知されるため、システム側はポーリングせず、イベントに応じて処理できます。開発は、サンドボックステナントを使って行います。これはテスト用レールを備えた、プラットフォームの分離されたコピーで、実際の資金を動かさずに作成から照合までの全フローを実行できます。各製品で何をどのティアで利用できるかは、アクセスバンドで決まります。各バンドの内容は、製品ごとのページで説明しています。

  1. 01ドキュメント化されたREST API、冪等な書き込み
  2. 02あらゆる状態変化をWebhookで通知。ポーリング不要のイベント駆動
  3. 03本番環境から分離された、テスト用レール付きのサンドボックステナント
  4. 04範囲と上限は、製品ごとのアクセスバンドで設定

率直な境界線

Protocoreが作るのはソフトウェア。規制領域を担うのはライセンス。

決済プロダクトは、2つの要素が一体になったものです。資金を保有・移動するための規制上の許認可と、それを指示し、記録し、照合するソフトウェアです。Protocoreが構築するのはソフトウェアです。顧客資金の保有、アカウントの発行、スキーム上での資金移動といった規制対象の業務は、オペレーター自身のライセンス、または銀行、EMI、決済事業者といったライセンスを持つパートナーが担います。このプラットフォームは、お客様が用意する規制対象のレールに適合し、カードデータをレール側に留めてお客様のサーバーに一切触れさせないよう設計されています。ただし、その許認可の代わりにはなりません。これはどのソフトウェアにも言えることです。規制の境界線をどこに引くかは、パートナーとともに決めていただく事項であり、アーキテクチャはどちら側の構成にも無理なく収まるよう設計されています。

  1. 01提供するのはソフトウェア層であり、ライセンスではない
  2. 02規制対象の業務は、オペレーターまたはライセンスを持つパートナーが担う
  3. 03カードデータはレール側に留まり、お客様のサーバーには置かない
  4. 04お客様の規制対象レールに適合するよう設計

お客様の開発に合わせたアーキテクチャをご提案します

開発内容をお聞かせください。システム設計と規制の境界線の位置づけを、営業資料ではなくお答えとしてお返しします。