Banks Adopt Digital Assets Without Core Changes

Sample sequence of a bank who wants to offer digital assets for Investor Services without changing their existing systems.

Many Investors today want to incorporate digital assets into their investment strategy but banks cannot support it. This is an example of Bank A, who needs to quickly adopt a digital asset strategy to avoid churn with their investors.

Like a typical TradFi, their systems cannot support 18 decimal places that digital assets would require and need to proceed without changing existing systems which would add further complexities and timelines. Bank A is using its existing trading systems, brokers, custody and reconciliation systems to offer BTC and ETH.

  1. Bank A has to settle on its trade, needs to send BTC or ETH to the brokers (Steps 1-12)

    1. Bank A wants to send assets to the brokers as part of the settlement process or it has reached its credit threshold and wants to increase its limit again.
    2. As part of the process, the settlement instruction arrives in a defined destination/repo in the format of a SWIFT message or similar.
    3. Knova’s SWIFT adapter parses the instruction, and prepares a request to send the specified amount along with required details to the recipient.
    4. Knova locks its digital twin equivalent to avoid double spend and reflect real time status of all Bank A assets.
    5. Transfer call is made to custodian APIs, Knova is updated with multiple onchain updates. Webhooks or equivalent mechanisms as made available will be used. Alternatively, Knova can listen in on specific BTC or ETH addresses.
    6. Knova in turn informs Bank A custody/settlement ledger systems with various status updates, which is configurable.
    7. Upon completion, Knova redeems the appropriate digital twins and informs Bank A custody with the final details and onchain hash if provided. By default this is a webhook but can be configured in the format the Bank A custody/settlement ledger requires.
  2. Bank A has executed a trade, broker sends BTC or ETH to Bank A (Steps 13-24)

    1. Broker sends BTC or ETH to Bank A’s address. By webhooks or equivalent mechanism or Knova’s blockchain listener, Knova is sent updates of such events.
    2. Digital Twins are updated and similar to above, the Bank A custody/settlement ledger system is updated with the digital asset transaction data accordingly.
    3. In the case that there are too many decimal places in the asset received, e.g., Custody/settlement ledger supports 3 decimal places but 0.123456 BTC arrives, Knova will automatically transfer the delta ‘change’ or ‘dust’ BTC digital twins to an internal system sub-wallet and send only the remainder- 0.123 BTC.
    4. The 0.000456 BTC will accumulate in the internal system sub-wallet, and by automation will be sent to the Bank A custody/settlement ledger once it gets large enough to be sent- e.g, 0.001 BTC.
    5. At any time, Bank A applications or Knova admin UI can pull balances of the DI wallet or internal system wallet to see how much BTC, ETH is held.

    *Note the above is not an exhaustive list of integrations and functionality Knova may have to do with the systems. Processes like getting network fees, pulling transaction history, updating VASP details, etc may be required as well.

Sample sequence of flows with Bank A systems and its key partner platforms and brokers