Data Mapping
Digital Loan NFT
NFT stands for “Non-Fungible Token” and is used in blockchain ecosystems to represent a unique (non-fungible) digital asset (token) whose ownership is registered and tracked on a blockchain. When it comes to the data model, an NFT can take any shape or form, as long as it provides value to the parties that own or share ownership of the asset throughout its life.
It can be as simple as the metadata associated with a JPEG, as it is in the digital art world. It can be locked down to a few specific fields, or provide space for each unique asset to grow, as needed.
Provenance NFTs are typically financial assets, such as loans or funds. However, the type of asset on Provenance is not restricted, allowing for innovation in the financial services industry.
Figure Tech has created an open-source metadata-asset-model to provide a highly extensible Google Protocol Buffer representation of an Asset. Using this model, groups of participants can model just about any use case, storing however much data they need to produce value.
When approaching a use case, it's important to balance the needs of each participant type. The model should provide space to store information that is valuable to all parties, even when that value doesn't overlap.
On the flip side, the model does not need to cover information that one single party finds useful. That information is better kept off-chain and combined with the shared asset client-side. On the same note, keeping size to a minimum is best because the object can be replicated across several Object Stores. Whenever files are involved, it can be best to store the files by themselves, and add a pointer to the file to the asset data model. You will see this pattern multiple times within the Loan Package data model.
As you will see below, the Figure Tech team has extended the base Asset data model to put together a Loan Package data model that balances the needs of loan originators, validators, servicers, investors, and eNote controllers. It's a model that has worked for Figure Lending as they record and sell loans to existing investors in the network. The model remains highly extensible and allows mortgage originators to choose whether to map each field in their own data model to the Loan Proto, or simply onboard loan data in a MISMO XML format.

Loan Package

This section builds on the Metadata Module documentation. Revisit that page for definitions of the four core state objects in p8e: Contracts, Records, Sessions, and Scopes.
Asset originators must understand the structure of the scope they are going to onboard to Provenance Blockchain, also known as the Record Specification. We will stick to the mortgage as an example of an asset that we want to represent as an asset in Provenance. The Loan Package Record Specification is one scope that includes the following six records:
Record
Description
Nullable
Asset
Core information about the loan that should not change throughout the life cycle of the loan after the loan is funded
No
Servicing Rights
Identifies the servicer and optional sub-servicer
No
Documents
List of loan documents (metadata with pointers to their actual storage location)
Yes
Loan States
List of loan states from servicing
Yes
Validation
List of validation requests and validation results (a.k.a. validation iterations in the model)
Yes
eNote
Metadata belonging to the authoritative copy of the eNote, as well as identifiers for the controller and custodian
Yes (only used when eNote is to be registered with DART)
To remain flexible the Asset record is quite loosely defined, however, the intention is for loan originators to choose from one of two options:
  1. 1.
    Map their own data model to the Loan Proto, which includes all of the fields needed to re-underwrite the loan and space to add custom fields in each section, or
  2. 2.
    Use the MISMOLoan Proto or MISMOLoanMetadata Proto, which simply require a Universal Loan Identifier (ULI) and MISMO XML file (or pointer to that file) while allowing loan originators to extend the model as needed
To help you choose, consider which format your business partners can handle. For example, if you intend to have your loan(s) validated by a third party that can handle version 3.4 of the MISMO Reference Model, then use the MISMOLoan Proto.
Both DART and Portfolio Manager can work off of either format.
See the API Usage Guide for a detailed, practical description of how each record can get generated and memorialized throughout the loan application, closing, validation, and servicing processes. It is also not uncommon for loan originators to work with document preparation vendors that may integrate directly with Figure Tech to onboard and register eNotes with DART on closing day. A separate guide is available for onboarding eNotes separately from the rest of the loan package, to ensure direct transfer between eVaults.

Proto Definitions

Each Record in a Scope is a key-value pair, where the key is a String and the value is a Protocol Buffer object. Google Protocol Buffers support code generation in many languages. The table below lists the record names and links to the Protocol Buffer definitions and documentation for each proto used in the loan scope.
Record Name
Proto Definition
Proto Documentation
Asset
asset.md
Servicing Rights
Documents
util.md
Loan States
Validation
eNote

Examples

The following examples assume the loan being recorded is a mortgage and that at the time of recording, the originator has a list of documents and eNote metadata, but has not requested validation or started servicing the loan, yet.
Example with Loan Proto
Example with MISMOLoan Proto
Copy link
On this page
Loan Package
Proto Definitions
Examples