POC flow
stablecoin / stablepoint からRWAへ
最初のPOCは「トークンを発行して終わり」ではなく、伝統的なDPM顧客指示から、銀行・issuer・RWA provider・DigiClassをまたいで投資が成立するかを検証するものです。
推奨POCの要点
狭く、銀行が関与し、カストディと規制の説明がしやすいstablecoin/stablepoint settlement flowを選ぶ。商品側はLibearaなどのthird-party tokenized product providerを使う。
取引ステップ
- 投資指示
DPM clientまたはrelationship managerが投資指示を出す。
- fiat / stablecoin settlement leg開始
銀行またはissuer側で決済レッグを開始する。
- custody / reserve control確認
銀行、custodian、trust accountなどで裏付け資産や資金管理点を確認する。
- stablecoin / stablepoint発行または移転
issuerがstablecoinを発行・移転・決済利用する。
- tokenized productへsubscription
Libeara等のproduct providerが提供するRWA、MMF、fixed income、goldなどに投資する。
- beneficial interest / product token割当
顧客のcustodian accountまたはwalletに投資結果が反映される。
- reporting / reconciliation
銀行、issuer、product provider、DigiClass間で状態を照合し、レポートする。
- 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まで設計できているか。