FinP2P Data Model


The FinP2P data models is based around entity profiles, where every entity on the network can be represented as a profile, examples include:

  • Organisation - Financial institutions on the network.

  • User - A legal entity such as a person or a company etc.

  • Asset - Any asset offering or managing securities on the network

  • Service Provider - Companies that are certified to provide services on the network, such as verify a user 's Accreditation status.

For each profile, we can see the following structure:

  • Profile

    • Global Identity (FinID)

    • Profile metadata

    • Certificates (such as KYC or KYA, signed by the profile’s primary node or a service provider)

      • Documents for Certificate.

    • Transactions (where relevant).

Global Identity (FinID)

Each profile in the network is identified by a global ID called FinID.

This FinID identifier is a structure containing the DER encoding of an EC PublicKey, the EC curve type and the signature from the signing entity. In the first specification only curve secp256k1 is defined. Support for other curves and algorithms can be defined in future reviews.

FinID is created by the profile’s primary node (and for primary node’s by Governance nodes, see ). Commercially, this is designed to enable a users to hold assets across the network (on different blockchains).


Any request and response sent from a Node includes the Node’s FinID and a signature to authenticate the message.

FinID validation is used to enforce ACL when requesting private data and validating the responses sources.

Profile Metadata

For each type of profile, the FinP2P specification will define the basic mandatory properties shared by all implementations as well as a way to extend the data model in a propriety way.


Certificates are properties of a profile, which are “given” to a profile by a trusted third party, aka Service Provider. All nodes are by default also service providers, but a network can host service providers who are not nodes - and only function to testify they have a proof of specific information about a profiles

Certificates are a use case of “Claims” in FinP2P, and comply with the W3C standard for Claim on the Verifiable Credentials Data Model Standard

Two Major use cases for Certificates

  • User Certificates: Provide independent verification to a User that it has certain qualities. Ex: KYC is a Certificate, a document describing a user is an “Accredited Investor” is a Certificate.

    • A User can have multiple Certificates

    • An asset or the asset’s node can define which certificates are required to invest in the asset, and also which service providers they trust for those certificates.

  • Asset Certificates: Enable the KYA (Know Your Asset) certificates for Assets 

    • KYA is a set of documents that describe the asset and the exact ownership rights of the asset token holders (such as what happens in an event of an exit, or eligibility to receive dividends, etc). KYA documents are legally binding, and adding them as Certificates to the Asset (an keeping their Hash on chain) makes them immutable on the FinP2P network - so securities holders have legal clarity of exactly what the securities entitle them to.

    • Only the primary node of each asset (or Service Providers approved on its behalf) are allowed to add KYA documents to an asset.

Documents for Certificates

Documents are binary files that can be linked through a Certificate to an Identity profile. Ex:  documents with KYC information, Documents with KYA (Know your Asset) information such as an information memorandum, pictures related to a specific asset and so on.

Asset Token Transactions

Tokens are a digital representation of ownership and related rights of real world assets. Tokens rights are linked via the Asset identity profile.

Tokens can be issued to a User, and/or transferred between Users, governed by the Regulation Verifiers (verification of regulatory / business logic) associated with the Asset.

Tokens can be redeemed.

The Primary node of the asset is required to approve token transactions for assets they manages (by using the Regulation Verifiers that are selected to the asset).