This set of lending processes, pre-built into the L-Cloud software, has been used to process over $15 million in digital loans to small businesses since early 2017.
LendLedger's process APIs cover how the following information is exchanged:
- Business or other credit data used for credit decisions
- Loan terms and conditions
- Credit recommendations by a Credit Evaluator - Credit Evaluator - Credit Evaluators provide loan decision recommendations based on loan applications shared by Lenders.
- KYC data used for identity verification
- Identity certification by an Identity Verifier - Identity Verifier - Identity Verifiers contract with Lenders to provide verification of Borrowers’ KYC data.
Within these categories, the types of data will expand over time. For example, the process API parameters will initially cover transaction data from point-of-sale devices and mobile wallets. This data is already used by Lenders - Lenders - Lenders originate loans using credit data made available by Data Providers. Lenders sign loan contracts with Borrowers and disburse loans to them to make loan decisions. But data-driven lending is maturing steadily. As Lenders seek new sources of data (e.g. farm yields, satellite imaging) to assess loan applications, the community will be able to define further formats.
In the LendLedger Protocol, data is exchanged using transactions on the Stellar decentralized ledger. These transactions act as a messaging system. Each transaction has a memo field in which LendLedger participants embed data requests and responses. But the data itself (e.g. credit data shared between a Borrower - Borrower - Borrowers acquire their personal or business credit data from Data Providers. Identify loan offers from Lenders and apply for and receive loans. and Lender) is too large to store on the blockchain. So it is stored on IPFS (InterPlanetary File System) and referenced by a Stellar - Stellar - Stellar is the blockchain on which the LendLedger network is built. transaction. Using encrypted data on IPFS also ensures that data is only accessible by parties authorized to see it.
Borrowers apply for loans in a variety of ways. Some seek out a loan and use a mobile app or web interface to find Lenders and loan offers. Others are shown an ad or loan offer by a Lender that has pre-identified them as a prospective Borrower.
The Borrower selects a loan to apply for and notifies the Lender. The Lender responds by creating an “Escrow Account” on the Stellar ledger. This is an account that must be signed by multiple parties (“multi-sig”) that performs all transactions related to the loan. It specifies the Escrow Account signatories as itself (the Lender), the Borrower, and any relevant Service Providers. It then notifies the Borrower of the account’s location.
The Borrower supplies required information to the Lender. The first requirement is usually credit data. The Borrower requests data from a Data Provider that has relevant business or credit data for him (e.g. a PoS company that processes credit card transactions for the Borrower’s shop). The Borrower receives this data from the Data Provider, and then sends it to the Lender. (See Exchanging Data for more details on these exchanges).
If the Lender requires ID verification beyond what the Data Provider supplies, the Borrower works with an Identity Verifier - Identity Verifier - Identity Verifiers contract with Lenders to provide verification of Borrowers’ KYC data. . The Borrower sends KYC data to the Identity Verifier and receives back certification of his identity. He shares this with the Lender.
The Lender sends the credit data, KYC, and other relevant information to the Credit Evaluator. The Credit Evaluator evaluates this information and the Borrower’s existing credit profile (if any) on LendLedger to make a credit recommendation. This is either a denial, or an approval that specifies the rate, term, and amount of credit the Lender should extend to the Borrower. The recommendation is sent to the Lender.
Loans are made and recorded using transaction APIs. Loans can be structured using the template contracts provided for common loan types, or by combining the transaction APIs into new smart contracts to accommodate less common loan structures.
The Lender creates a loan agreement smart contract to govern the escrow account. This smart contract consists of all transactions related to the loan: disbursement, repayments, and potential default transactions. Embedded in these transactions are also the appropriate fee payments for the Service Provider.
The Lender signs and sends the Loan Agreement to the Borrower for his or her signature. The Borrower then signs the agreement, a pre-authorization of the transaction set. As signatories to the escrow account, the Service Providers sign off as well, after inspecting the transactions to ensure they are being compensated correctly.
The Lender funds the escrow account with the appropriate amount of LedgerCredits - LedgerCredits - LedgerCredit is the protocol’s internal accounting unit. It is denominated in terms of government-issued (fiat) currency and acts as an IOU on the part of the issuer. (loan plus fees), then submits the pre-signed loan disbursement transaction. The escrow account disburses the LedgerCredits - LedgerCredits - LedgerCredit is the protocol’s internal accounting unit. It is denominated in terms of government-issued (fiat) currency and acts as an IOU on the part of the issuer. for the loan to the Borrower, and for the fees to the Service Providers.
The repayment schedule is created as part of the loan agreement smart contract. The transaction APIs allow for a wide range of repayment structures. In signing the loan agreement, the Borrower pre-authorizes each repayment transaction needed to pay back the loan. These transactions specify an amount as well as a date for each repayment.
On each repayment date the Borrower funds the escrow account with the amount of LedgerCredits - LedgerCredits - LedgerCredit is the protocol’s internal accounting unit. It is denominated in terms of government-issued (fiat) currency and acts as an IOU on the part of the issuer. due, either directly or through a Loan Servicer - Loan Servicer - Loan Servicers collect loan repayments from Borrowers on behalf of Lenders. . When the repayment transaction is then submitted, it distributes LedgerCredits - LedgerCredits - LedgerCredit is the protocol’s internal accounting unit. It is denominated in terms of government-issued (fiat) currency and acts as an IOU on the part of the issuer. to the Lender and to any Service Providers involved in the loan.
If a Borrower has not adequately funded the escrow account, the subsequent repayment transaction will fail. If this occurs, after any grace period the Lender can pursue collections or declare default.
A default cancels all subsequent repayment transactions and hands control of the escrow account over to the Lender. This allows the Lender to structure a new repayment schedule if they and the Borrower can agree to terms on a resolution.