Alphian / Axial
資産運用、private wealth、DPM文脈を持つ側。顧客・投資家・商品提供の文脈を作る。
Asset managementPrivate wealthDPMProject map
誰が何をするプロジェクトなのか
この案件は、1社がすべてを作る構造ではありません。銀行、issuer、custodian、product provider、asset manager、DigiClassが役割を分けることで、金融商品として成立しやすくなります。
中心構造
DigiClass
Web3、orchestration、workflow、API、integration、reportingを実装する側。発行体や銀行そのものではない。
InfrastructureOrchestrationEngineeringBank / Custodian
HSBC、SCB、BEAなど。信頼性、カストディ、trust account、settlement credibilityを担う。
CustodyTrust accountSettlementStablecoin Issuer
Anchorpointなど。stablecoinまたはstablepointを発行し、reserveやredemptionの責任を持つ。
IssuerReserveRedemptionRWA Product Provider
Libeara、Janus Henderson MMF、Centrifugeなど。実際に投資対象となるtokenized productを提供する。
RWAMMFFixed incomeStrategic Investors / Partners
HKIC、Animoca、HSBC Ventures、SC Ventures、Hashgraphなど。資本、信頼性、導入先、技術的検証を提供する。
CapitalValidationDistributionなぜ役割分担が重要か
金融商品では「誰が責任を持つか」が曖昧だと成立しません。DigiClassが全部を持とうとするのではなく、銀行はカストディ、issuerはdigital money、product providerはRWA商品、Alphianは運用文脈、DigiClassは技術的接続という分担が重要です。
エンジニアとしての見方
| 問い | なぜ重要か | システム設計への影響 |
|---|---|---|
| 誰が発行体か | 法的責任と償還責任が決まる | issuer API、reserve status、redemption flow |
| 誰が保管するか | 顧客資産の安全性と規制対応が決まる | custody integration、wallet/account mapping |
| どの商品に投資するか | リスク、利回り、償還、レポートが決まる | product model、NAV/yield data、lifecycle events |
| どの台帳が正か | 残高差異や紛争時の基準になる | system of record、reconciliation、audit trail |
| 誰が承認するか | 金融犯罪・誤操作・不正移転を防ぐ | maker-checker、RBAC、approval workflow |