Autonomous Lending Organization on Ethereum with Credit Scoring

Chris Pollett (Presenting)

Joint work with:
Thomas Austin
Katerina Potika
May, 2023

Introduction

Modern cryptocurrencies such as Etherium have built into their infrastructure the ability to create smart contracts that can be algorithmically carried out and verified.
One important class of real-world contracts is the loaning of money from one individual or group of individuals to another.
Traditionally, a bank is used as a middle-man.
The bank profits on the difference between the interest the bank pays its depositors versus the interest the bank charges to its borrowers.
To decide the likelihood of borrower repayment and hence of the likelihood of a profit on a given loan, a bank uses a credit score.
Today, I would like to describe the ALOE system, which enables unsecured borrowing of funds on Ethereum without a bank, and describe how it handles identity verification, accesses creditworthiness, and associates borrowers to lenders.

Peer-to-peer Lending

Before I get into our system, I'd like to briefly survey the current state of online lending and blockchain-based lending.
Several companies have proposed peer-to-peer lending models not on a blockchain: Zopa (2005), Prosper Marketplace (2006), LendingClub (2007), etc.
- Roughly, clients list the loan amount they want and provide personal details, the peer-to-peer company gives it a creditworthiness grade, assigns an interest rate and makes a loan listing. Investors can choose from listings which loans to invest in and for how much.
- Investors make money on the interest, the peer-to-peer company makes money on client origination fees and investor service fees.
- Loans are often made by a real bank, then bought by the peer-to-peer company (who becomes the debt collector on a default), and the lenders essentially get a promissory note from the peer-to-peer company.
- Greater transparency could still be had...
  - There have been issues with peer-to-peer lending companies selling loans to investors that did not quite match their purported spec's (Prosper Marketplace 2008, LendingClub, 2016) and clients loans being dated so they receive less favorable interest rates than they otherwise would (LendingClub, 2016).

Blockchain-based Lending

Next, let's look at the state of blockchain based lending...
Decentralized finance (DeFi) products can be offered by a decentralized autonomous organization (DAO):
- A DAO is a cryptocurrency (we'll call this the DAO coin) together with a collection of smart contracts, at least one of which allows the purchase of DAO coin with some other currency, and at least one of which allows for some kind of voting.
- DAOs use these smart contracts, with participants using governance tokens (the DAO's coin), to vote on topics such as fund allocation (here the funds include the currency funds used to purchase DAO coin).
- In the DeFi space, notable DAOs include MakerDAO (2017), Compound (2018), Aave (2020), etc.
- To obtain a "loan" in these systems roughly involves depositing some quantity `x` of ether collateral into a smart contract.
- The smart contract then issues `y = alpha times x times (mbox(US dollar)/mbox(ether))` of the DAO's coin where `alpha` << 1, say `2/3`.
- The borrower can do whatever they want with this coin, but to get their original `x` ether back, they must pay back `y` DAO coin plus interest according to the repayment terms of the loan.
- If the repayment terms are not met (which includes if ether drops too much in value versus the US dollar) the borrower loses their ether.
- Such a loan might make sense if you expected ether to go up versus the dollar but wanted access to funds like dollars to buy stuff.
Besides DAOs, blockchain lenders like Banksocial (2022) do more traditional secured and unsecured lending by letting investors purchase coins in the blockchain lender's cryptocurrency. The investments raised are then used to finance loans with terms according to the blockchain lender's credit scoring system, and the investors are paid interest accordingly.

Traditional Credit Scores

As we've seen credit scoring is important in traditional and peer-to-peer lending, so I'd like to briefly touch on it before getting to our lending system.
Computerized credit scores in the United States date to the 1950s with the pioneering work of Bill Fair and Earl Isaac whose company is now called FICO.
The FICO Score 8, often used for home loans, is one of the more popular credit scores.
It consists of the following components:
1. Payment History (PH),
2. Debt Burden (DB),
3. Length of Credit History (LoCH),
4. Types of Credit used (ToC), and
5. Recent Credit Searches (RCS).
From this, a weighted score WS is calculated as follows:
$0.35 \cdot PH + 0.3 \cdot DB + 0.15 \cdot LoCH + 0.1 \cdot ToC + 0.1 \cdot RCS$
Finally, a proprietary function $f : [0,1] \rightarrow [350, 850]$ is applied to WS to obtain a score.

Credit Scores and Identity

There has been some work on blockchain-based credit scores.
- For example, Cred Protocol is working on providing a decentralized credit score to the Aave protocol.
One crucial aspect of credit scores is the ability to correctly identify an entity:
- You don't want one entity, a person or business, being able to pretend to be many entities (Sybil resistant).
- You don't want malicious entities sabotaging the scores of well-behaving ones.
Sedlmeir, et al (2021) have proposed blockchain-based digital identities and verifiable credentials, similar to what we'll describe for our system.
Microsoft Azure has an Ethereum proof of authority system.
Hyperledger Indy is another example of a decentralized credential management system.

ALOE

We are now in a position to discuss our lending system: Autonomous Lending Organization on Ethereum (ALOE).
Some of design goals of ALOE were:
1. Allow peer-to-peer, unsecured loans on the blockchain.
2. Allow greater transparency by doing as much as possible on the blockchain, where the computations in contracts can be fully examined.
3. Have our credit-scoring mechanism also be on the blockchain so as to be equally transparent.
4. Try to ensure borrower anonymity is maintained, but make sure that a borrower credit score is publicly associated with one Ethereum address.
Our system is being developed for the Ethereum blockchain, where smart contracts execute using its virtual machine, using Solidity as the high-level language.
Ethereum has two kinds of accounts types:
1. Externally owned account (EOA), which is associated with a public key, and hence owned by an external user.
2. Contract account, which is associated with some code.
Our system has four key processes which we now describe: borrower registration, creating a loan, borrowing and lending, and credit score calculation.

Borrower Registration I

Sequence Diagram for Borrower Registration

To the right is a sequence diagram for borrower registration, it involves the following entities:
- A borrower, a real person that has a unique SSN and an Ethereum address.
- A notary, a trusted real-world entity that validates the user's identity, credit score, and Ethereum address.
- A small, fixed set of publicly known auditors, responsible for storing shares of the real-world identity associated with a borrower. (Could be more than the two in the figure.)
- The CreditBureau Smart Contract (CBSC) class, which stores a mapping between Ethereum addresses and a tuple containing: a real-world credit FICO score, a timestamp of when this association was made, as well as a point in our credit scoring space.

Borrower Registration II

To register the borrower goes to a notary for our system in the real world.
The notary collects a fee to pay for their services and for the ether needed to call the relevant contract methods.
These methods use the Solidity's tx.origin to make sure the notary's address is from an approved list of notaries.
The borrower gives their SSN, Etherium address, photo id and the notary verifies their information, then calls the CBSC's verifyUnusedAddress method to make sure that Etherium address has not already been used by a different borrower.
Assuming the address is unused, the notary does a pull of the user's FICO score, and via Shamir secret sharing creates shares of the identity-Etherium address mapping, giving one share to each auditor.
These steps are currently all off-chain, however, one could add a payment scheme for auditors, by having auditors call the CBSC to verify that they have their share for an address, and having this method return ether paid for by extra ether initially provided by the verifyUnusedAddress. This CBSC call would also make use of tx.origin to make sure the auditor was from an approved list of auditors.
The notary then calls CBSC initScoreLedger method with the borrower's Etherium Address, a FICO score, and a timestamp to set up an account.
Finally, the notary discards all real-world information it has about the borrower.

Creating a Loan

A Loan smart contract (LoanSC) object is created by calling the CBSC method:
createLoan(uint totalAmount, uint intRatePerMil, uint numPayments, uint secondsBetweenPayments, uint minCreditScore, uint fund_date) public returns (Loan)
Calling this method must be initiated by an EOA, who we'll call the loan initiator.
Since this operation requires ether from the loan initiator, the loan initiator may claim a fee from the interest of ether paid by the borrowers.
Should there be any additional ether due to a lender claiming their funds early, the additional interest also goes to the loan initiator.
Because of these fees, loan creators are incentivized to create loans with parameters that will attract enough investors and borrowers that they are likely to fund and also be paid back.
A loan initiator's role is somewhat like the role of the peer-to-peer company in our background discussion.

Borrowing and Lending

The CBSC's findLoan method can be used by borrower's and lender's to search for Loan smart contracts according to desired criteria.
To participate in a Loan smart contract the borrower or lender calls respectively the borrow(uint amount) or invest method of Loan.
For a borrower, this in turn involves a call to the CreditBureau smart contract's getScore method to verify the credit score before the borrower is allowed to add.
For a lender, invest transfers funds into the smart contract. These funds cannot be accessed until after the fund_date.
The lender whose investment causes the Loan smart contract to have totalAmount of funds, triggers the funding of the Loan, and the timestamp of this is used to determine interest owed.
Borrowers call isReady() to check if the Loan is ready, call get$$$ to get their funds once ready, and call makePayment to make a payment on their loan.
The latter two calls invoke update credit score methods of the CreditBureau smart contract.

Withdrawals and Defaults

After the fund_date, a lender can call the Loan smart contract's withdraw(uint amount) to withdraw money from the account up to the smaller of the invested amount plus interest or the amount currently held in the smart contract.
The currently owed amount to an investor is updated each withdraw() call.
The currently owed amount is based on the old currently owed amount together with the interest that would have accrued on the amount currently owed since the previous withdraw call, or if no such calls had been made, the loan fund time.
If this goes to 0, the lender no longer can receive funds from the contract.
There is also a maximum that could be owed a lender based on the loan parameters if the lender keeps their funds in the loan until the time by which all borrowers are supposed to have repaid their debts.
If an external process determines a client has failed to properly repay their loan:
1. It can invoke a CreditBureau method with the Etherium address in question,
2. The CreditBureau smart contract verifies the default and contacts the auditors with a proof of a loan default.
3. Each auditor verifies the proof and responds with their share of the user's social security number (or other real-world identification).
4. Any lender or loan intiator involved in the defaulted loan may then call the CBSC to get the shares of the user's social security number.
5. Off chain, the lender combines the identity slices to reveal the identity of the client and pursue collection.

Credit Score - Tracked Quantities

Our credit scoring system is carried out on-chain to allow the operations involved in the credit scoring to be publicly carried out and verified.
For each Etherium borrower address, we track and incrementally update a point (UPR, CDBR, CPBR, RAR, ANCL) with a label that contains a list of odds of staying current on the loan.
The coordinates of such a point are ratios motivated originally by FICO score components and stored in the smart contract using pairs of integers to avoid Ethereum dust.
Here is a brief description of the coordinates and the odds of staying current quantities:
1. Underpay Ratio (UPR) - The ratio of time that the amount an individual owes is more than the amount that they should owe versus the total time span of all loans that that individual has ever carried.
2. Current Debt Burden Ratio (CDBR) - The ratio of current outstanding debt (COB) to the average outstanding debt (AOB) plus three "pseudo" standard deviations.
3. Current Payment Burden Ratio (CPBR) - The ratio of the current payment per day not to be behind on the loan versus the user's average payment per day not to be behind on the loans (since first loan was taken) plus three "pseudo" standard deviations.
4. Repayment Age Ratio (RAR) - The loan size weighted age of all loans a user has had versus time since their first loan received.
5. Average Number of Credit Lines (ANCL) - The quantity tracks the average number of loans the user has had since the user's first loan.
6. Odds Stay Current w-day window (OSC-w) - The fraction of time that for the next window period the user never owed more than they should have if regular payments were made. Computed for `w`'s equal to $2^i$ days for i = 0,..., 14.
A getScore call for a borrower, involves first determining the `i` such that `2^i` and `2^{i+1}` bracket the duration of the loan, then looking through the list of all points for the `k` nearest neighbors by Euclidean distance, and taking the weighted-by-distance average of their OSC-`2^i` scores.

Credit Score Implementation

As a flavor of how incremental updates work, consider Underpay Ratio (UPR). To track it for a borrower:
- The CBSC keeps the timestamp of the first loan of a borrower, FLT.
- The CBSC determines NOW, the current time at which the borrower's score is being updated.
- The CBSC, each time a payment is made, updates a quantity TOT, the total time the amount owed was greater than what should have been owed.
From these, UPR is calculated as $\frac{TOT}{NOW - FLT}$.
To allow a user who has no credit history, and hence no score vector, to obtain a loan, if the loan amount is below a threshold, and the loan payment for the loan is less than a different threshold, then the score returned by getScore is just the FICO score originally associated with the account over 1000.
The choice of the k-nearest neighbor implementation is brute force: We store points in a hash table with key the borrower's address.
This means updating a score on a payment will be an O(1) operation, so not cost much gas.
However, doing a getScore involves a linear scan of the table, so is more costly.
To ensure this price is comparable to running a real world credit score, the number of points should be kept in the low tens of thousands.
To this end we keep two subsets of all points for scoring purposes: an old model and a new model. A weighted sum of the scores of these two models is the credit score. When a score is updated an entry in the new model is also updated. When the new model reaches a threshold number of scores, it becomes the old model and the new model is reset to empty.

Conclusion and Future Work

ALOE allows for lenders and borrowers to connect in order to conduct loans.
Loan credit scores are computed on-chain based on ongoing borrower behavior.
Lenders are guaranteed a minimum score for the loans they invest in so they can choose the amount of risk they are comfortable with.
We allow the identity of borrowers to be revealed should they default on a loan, while preserving the anonymity of well-behaving borrowers.
We continue to work on the system and envision trying to enhance it.
Some features we are considering are the support of computing credit scores in an encrypted fashion on-chain using a low-gas-to-compute, homomorphic encryption scheme, support for secured loan vehicles, support for connecting multiple addresses to a user, as well as looking at off-chain approaches to the credit scoring model.