Tokenized Capital Markets: Issuance, Financing & Settlement

Tokenized securities issuance (Steps 1-14)
1. Company A decides to issue tokenized assets. By API or automation, or reading ISO20022 messages, Knova begins the process against the specified contract type for the asset type and provider.
2. As an example, if the contract is for Canton, Knova executes the DAML contract for this issuance against its Canton Validator, privately run for Company A. Knova handles the complexities and multiple interactions with the Canton blockchains, fees, etc.
3. Similarly for other asset types and providers, Knova executes the appropriate smart contracts/API execution. For conceptual purposes, this could be something like USYC and WisdomTree tokenized MMF, dydx, etc but various other providers can be used instead. For Company A, it is simply the same Knova API used, with a different contract type.
4. Knova keeps Company A applications updated real-time as transactions occur on-chain, and the digital twin of these assets are reflected as well, and sent to the target recipient sub wallets. Tokenized assets are now available to be leveraged for other flows.
5. For any transactions, Knova workflows can be set up so that compliance checks, disclosure and policy data collection workflows can be executed by Knova from existing Company A systems, and notifications sent to customers by preferred mechanisms.
Collateralized contracts against Canton and other providers (Steps 15-30)
1. If the contract is for tokenized repo in Canton, Knova executes the DAML contract and handles the complexities.
2. Other contract types can be enabled against other providers as well, using the same APIs with different contract types specified. e.g., Interest swap with collateral via tokenized MMF. Depending on the contract, Knova will handle the respective steps and interactions behind the scenes with the specified provider.
3. To reduce Company A engineering effort even further, Knova can also read messages from existing Company A flows, and execute tokenized contracts accordingly against various providers. As an example, ISO 20022 messages may include instructions for certain transaction types, and Knova can consume this message and execute on Broadridge’s behalf and avoid needing to call Knova APIs altogether.
4. For any transactions, Knova workflows can be set up so that compliance checks, disclosure and policy data collection workflows can be executed by Knova from existing Company A systems, and notifications sent to customers by preferred mechanisms.
Company A settles with other banks via tokenized or traditional fiat rails (Steps 31-38)
1. Company A customers need to settle in cash, and Knova can facilitate via various providers of choice. This can be on traditional rails but it could be on tokenized rails such as Fnality or equivalent.
2. Similar to above, this can be executed by API or Knova can also read messages from existing Company A flows, and execute transactions accordingly.
3. Various fiat settlement providers can be supported, again with the same API but with different contract types. Knova handles the interactions with the cash settlement provider and at all times real time updates to Company A applications as well the digital twin balances will stay up to date.
4. For any transactions, Knova workflows can be set up so that compliance checks, disclosure and policy data collection workflows can be executed by Knova from existing Company A systems, and notifications sent to customers by preferred mechanisms.