The following is a fictional use case, which is used across the documentation for examples of functionality.
BlueSky Space, a private company, wants to raise capital.
Bob, BlueSky’s CEO, contracts with his investment bank, BankUS to distribute thecompany on the network.
Registers BlueSky on the network, and upload its KYA (Know your Asset) docs, suchas a placement memorandum.
Sets up the regulatory requirements for the raise (Reg D 506c).
Authorizes other network institutions to bring their investors.
BR Capital is a client of BankUK (which already verified it for KYC/AML, Accreditation.)
Alice, Managing Partner of BR Capital, logs into her BankUK dashboard looking for Space sectoropportunities, where she finds and explores BlueSky.
Alice decides to invest $10m in BlueSky, and makes the investment.
Transaction is verified by BankUS’s node for compliance, and settles instantly.
Alice now has $10m in BlueSky shares on her BankUK dashboard.
BlueSky’s CEO, Bob, receives a notification, and opens his BankUS mobile app.
He can see the updated cap table, including BR Capital’s shares, value of $10m.
His bank account now shows an additional $10m (minus fees).
Bank US received its fees for managing the asset.
Bank UK received its fees for managing the investor.
In terms of the BlueSky transaction, the simplified flow will be as follows:
Alice approves the transaction.
The transaction is routed via FinP2P to BankUS’s node.
Transaction is executed on the Distributed Ledger of Bank US (the Primary node of the asset).
FinP2P of BankUS sends back a Confirmation Record.
Confirmation Record is stored on the Distributed Ledger of BankUK (the Primary node of the user).
BankUS and BankUK’s apps only talk to FinP2P, so under FinP2P they may be on the same DL or on different DLs, and may use the same or different DL Technology.