Custody and the Investor Identity

This page describes how global investor identity, keys, and custody providers are modeled and integrated within the Ownera platform.

Identity Model

In Ownera, every investor has a User Profile ID - their legal identity across the network. Each profile can have one or more associated User FinIDs, which are standard EVM-compatible wallet addresses (similar to Ethereum wallet addresses). These are used to approve all transactions on any application, across any ledger.

Depending on the ledger technology:

• The direct signing key may be used (e.g., on EVM-based blockchains)
• A delegated signing key may be assigned if the underlying ledger requires a different cryptographic framework (e.g., Canton, Corda)

This model allows custody technology providers to deliver digital identity and signing services seamlessly across the entire FinP2P ecosystem.

Chain Access Options

Ownera supports three access models for interacting with asset registries:

These align with the broader Ownera access model:

• Direct access: Register assets you access directly via your Router - this includes assets you issue, or assets on public chains that you can access directly without going through another party
• Indirect access: Use assets that counterparties share with you - issuers or custodians share their assets, which you can then query via the Query API and operate on via intents

Custody Technology Integration

Custody providers integrate with the FinP2P network by connecting their custody key management system to the Ownera Router via a Custody Adapter, which enforces their signing policies and links applications to custodians.

Once connected, all relevant transactions from any FinP2P application are routed to the custodian's technology for validation and signature.

Before signing, custody can implement any desired policy (e.g., various authentication methods, multi-signatures, MPC, HSM, cold storage). This is all agnostic to the Router, which simply waits for a valid signed transaction to route and orchestrate.

Typical transactions are signed using EIP-712 or a minimized HashList format, covering blockchain and legacy transactions alike.

Core Verification Criteria

The key aspects to verify include:

1. Legal Possession: Verifying that the asset cannot be moved on the registry blockchain without a valid, signed transaction from the Custody Adapter, ensuring the custodian has a legally-binding, provable, undisputable record of ownership.
2. Transaction Execution: Ensuring the transaction is correctly executed on any underlying asset registry blockchain.
3. Transaction Proof: Cryptographic evidence confirms allocation of assets to the investor's User FinID on the registry ledger.

How It Works

1. Transaction Execution

The Router determines the best course of action depending on the underlying blockchain's nature:

• For EVM-compatible blockchains:

  • Custodian signs with the User FinID's signing key.
  • The Routers route the transaction into the source blockchain via the tokenization engine (Ethereum, Polygon, Besu, Quorum, etc.).
  • The signing key serves as the wallet address holding the asset, making ownership EVM-native.

• For non-EVM-compatible blockchains:

  • The signing key signature authorizes the custodian to manage a native account on the target blockchain.
  • Ownera Routers may include a built-in ledger node (such as Canton node, Corda).

• For non-blockchain assets (e.g., FIAT payments):

  • The signing key signature authorizes a traditional, non-blockchain transaction via legacy networks like SWIFT.

2. Transaction Proof

Getting proof that a transaction was properly executed depends on the asset registry blockchain:

• Public chains:

  • The custody transacts directly with the chain, receiving transaction details and verifying execution independently. The tokenization engine can also add any cryptographic proof if needed, such as signed receipts or zero-knowledge proofs where available.

• Private/permissioned chains:

  • If the custodian has a node on that private chain, it can verify the transaction independently (e.g., Canton, Besu network).
  • If the custodian does not have a node or third-party validation capability, the Router will receive cryptographic proof from the remote blockchain, signed by the financial institution's Router.

3. Possession

Ensuring that only a signed transaction by the custodian can move the asset out of the User FinID holder's account involves several practices:

• Legally:

  • A contractual agreement between the custodian and the TA using the tokenization engine as a registry specifies that only valid signed transactions by the custodian can move assets in the client's wallet or account.
  • This contract is backed by appropriate on-chain smart contracts.

• Technologically:

  • The custodian can validate the smart contracts of the tokenization engine before allowing clients access to assets.
  • On public chains, smart contracts are public and auditable.
  • On private EVM chains, smart contracts can be provided and audited.
  • The custodian's node (embedded in the Router) controls assets natively on networks like Canton or R3 Corda.
  • All tokenization partners utilize regulated TAs or other registrars to manage the registry blockchain.

Custody Services: Omnibus vs. Non-Omnibus

The Routers also support immobilization to an omnibus and reissuance of assets where it makes commercial sense, such as reissuing with CSDs or issuing DRs.

Non-Omnibus custody (also known as fully segregated or named accounts) ensures that each client's assets are held and recorded uniquely in their account. This model supports increased transparency, auditability, and direct asset ownership visibility, often preferred for clients with enhanced regulatory or fiduciary requirements. It also supports a nominee structure for holding assets.

Omnibus custody enables the aggregation of multiple client holdings under a single account per asset class, allowing for efficient immobilization, simplified settlement, and streamlined interaction with market infrastructures such as CSDs. This model supports operational efficiency and cost savings.

The Routers support both models and enable dynamic routing, reissuance, or settlement optimization depending on jurisdictional, commercial, and operational factors.