The Ownera FinP2P API's

The Ownera APIs are a set of API's which are the entry point to interact with the FinP2P Network.

 Those API’s will be used by nodes and application providers to build the applications and tools around the network that will serve the ecosystem and market participants.

The API Logical models

There are 5 core models used by the API.

The first part deals with profiles of identities:

Creating users or “owners”
Creating assets
Defining entities that can attach Certificates to profiles (“Certificate providers” – explained below).

📘
The existing implementation supports the node itself to act as the Certificate provider, future releases will support the node to use Certificates issued by external Certificate providers

The second part of the API deals with “Certificates”:
Certificates are properties of an ownera profile, which are “given” to the profile by a trusted third party.

There are two major use cases for Certificates:
The first use case is to provide independent verification to an owner that it has certain qualities. For example, a KYC is a Certificate, a document that verifies that a user is an “Accredited Investor” is also a Certificate.

Owners can have multiple Certificates, even of the same type. For example, a person can get a KYC certificate from Bank A (so they can to invest in an asset distributed by that bank), but may then require a separate KYC from Bank B to buy a different asset.
The “Certificates” model replaces the “whitelist” model which many security token platform use. Instead of an asset saying which wallets can hold a token, the asset would specify which Certificates (from which providers) a user must hold in order to hold the asset's tokens.
(A “whitelist” is a less-efficient subset of the Certificates model, which can be implemented using a “belongs to whitelist” Certificate issued by the asset owner. However whitelists are much less efficient, especially when dealing with secondary trading venues – it is much more efficient to define the rules for who can hold a token, and then enforce those rules at the transaction level, regardless where the transaction is initiated.)

The second use cases for Certificates is to enable the KYA (Know your Asset) model of Ownera.

KYA is a set of documents that describe the asset and the exact ownership rights of token holders (such as what happens in the event of an exit, or eligibility to receive dividends).
According to the FinP2P model, only the primary node of each asset (or entities approved on its behalf) are allowed to add KYA documents to an asset. This means potential owners who wish to invest can always know what they are buying, and exactly who verified that information (i.e. a regulated financial node).
Each asset on FinP2P Node is expected to have a KYA Certificate.

The third part of the API deals with documents:
These APIs simply allow the upload of documents to support a specific Certificate.

📘
Underneath the API, for privacy reasons, the documents are not kept on a DLT, and may be encrypted, however a HASH is kept on-chain to validate the version provided by the API.

The fourth part of the API deals with the tokens representing the digital securities:
These APIs supports issuing new tokens for an asset, as well as executing transactions in which asset tokens are transferred between owners.

The fifth part of the API deals with the payments:
These APIs support deposit and withdraw of payment asset into and out of the FinP2P Network using external payment rails.

For more details please review the API Reference