POC flow

stablecoin / stablepoint からRWAへ

最初のPOCは「トークンを発行して終わり」ではなく、伝統的なDPM顧客指示から、銀行・issuer・RWA provider・DigiClassをまたいで投資が成立するかを検証するものです。

推奨POCの要点

狭く、銀行が関与し、カストディと規制の説明がしやすいstablecoin/stablepoint settlement flowを選ぶ。商品側はLibearaなどのthird-party tokenized product providerを使う。

取引ステップ

  1. 投資指示
    DPM clientまたはrelationship managerが投資指示を出す。
  2. fiat / stablecoin settlement leg開始
    銀行またはissuer側で決済レッグを開始する。
  3. custody / reserve control確認
    銀行、custodian、trust accountなどで裏付け資産や資金管理点を確認する。
  4. stablecoin / stablepoint発行または移転
    issuerがstablecoinを発行・移転・決済利用する。
  5. tokenized productへsubscription
    Libeara等のproduct providerが提供するRWA、MMF、fixed income、goldなどに投資する。
  6. beneficial interest / product token割当
    顧客のcustodian accountまたはwalletに投資結果が反映される。
  7. reporting / reconciliation
    銀行、issuer、product provider、DigiClass間で状態を照合し、レポートする。
  8. redemption / reverse flow
    償還時に逆方向のフローを実行する。

DigiClassが作るべき部分

Orchestration

複数の参加者をまたぐ状態遷移を管理する。投資指示、入金、発行、subscription、allocation、redemptionをつなぐ。

Integration

bank、issuer、custodian、product provider、Alphian platformとのAPI連携やファイル連携を設計する。

Reconciliation

顧客指示、入金、stablecoin残高、RWA allocation、custody recordの差異を検出する。

Reporting

投資家、DPM、管理者、銀行、監査向けに必要な履歴と状態を出せるようにする。

POCで検証すべき問い

  • 銀行はこの流れをリスク管理上説明できるか。
  • issuerとcustodianの責任分界が明確か。
  • 第三者RWA商品はprivate wealth / DPMに適しているか。
  • DigiClassのorchestration layerは全イベントを監査可能に記録できるか。
  • redemption時のreverse flowまで設計できているか。
次に読む POCを理解するための重要コンセプトを見る