How to Build a Lender

Modern Treasury empowers teams to make payment operations simple, scalable, and secure. The “Guides” series walks through representative businesses or payment processes and explains step by step how best to go about building them from scratch.

Introduction

The universe of lending businesses is large and diverse. Modern examples of lending organizations include student loan lenders such as SoFi and CommonBond, personal loan providers such as Marcus and Prosper, mortgage lenders such as LendingHome, and even cryptocurrency lenders such as BlockFi and SALT. At their very simplest, however, every lender looks quite similar. Lending involves offering a loan for some specific purpose in return for a promise of deferred payment, and then the collection of those payments over a set period of time. Whether it is a student loan, an auto loan, a personal loan, a small business loan, or even a government bond issue, it is possible to build a generally applicable set of mechanics that work for any lending business.

This post deals with the payment operations required to build a lender. Naturally, being a good lender requires not just great payment ops but also good credit decisions. Lending to borrowers who cannot repay their debts is never a sustainable business model. The heart of each lending company is the belief it has an edge over others because it knows something about borrowers that other lenders may not, and can find them cost effectively. Here we’ll focus on the general architecture that someone building a new lender can use to deploy their unique and special underwriting strategy.

With that caveat, let’s dive into what it takes to offer loans.

The User Experience

So, suppose you decide to build a lender. What the loan is for does not matter much, but let’s say you're planning to offer auto loans and your new company is AutoLoan, Inc..

The user experience might be something like this:

1. A user comes to the AutoLoan website and applies for a loan.
2. The credit team (or algorithm) approves the loan (or not).
3. When a loan is approved, the user enters their bank information. This is where the loan should be deposited, as well as where monthly loan payments should be withdrawn from.
4. The user receives the loan amount in their bank account.
5. On a monthly basis for the next, say, three years, the user pays a monthly amount comprised of interest and principal.
6. After 36 months of recurring payments, the loan is fully repaid.

With this user experience in mind, let’s walk through what needs to be set up on the payments side.

Payment Ops Architecture

This new auto lender needs to have a bank account. This is where the money to fund loans will come from, and where payments will be made to. But the best practice is to actually have multiple bank accounts and hold cash meant for different purposes in different accounts. Perhaps AutoLoan sets up one bank account that only holds the funds to be lent, and another that holds moneys collected. Or perhaps there is a more complicated setup that involves a bank account for every loan type, or for every investor who is funding the loans.

For the purposes of this post we’ll assume the hypothetical lender, AutoLoan Inc., sets up two bank accounts: a “Funding” account that will hold all the funds ready to fund a loan, and a “Collections” account that will hold all the monthly payments collected on an ongoing basis.

When a borrower gets their loan, AutoLoan Inc. will send funds out of the Funding account. When a borrower pays their monthly payment, AutoLoan Inc. will receive and hold it in the Collections account.

Now that the architecture is ready, we can put together the API calls required.

API Calls and Timings

Everything starts with the loan application approval. If the loan is not approved, then no money moves. But if the loan is approved, the process starts by funding a loan.

Step 1: Collect bank account details

AutoLoan first needs to collect the borrower’s bank account details. To do so, you first create a counterparty in the system, and populate it with the bank account and routing numbers you have received (more here on common methods of authenticating accounts):

In addition to the account and routing number, you might want to hold additional information about the counterparty held in metadata. This information might include a unique customer ID, the way in which they signed up, and other information.

Step 2: Fund the loan

A counterparty creation response will notify you that everything has been successfully set up. Now that a counterparty exists, you can fund the loan. Let’s say Bobbie Borrower is buying a Honda for $25,000, and AutoLoan is funding 100% of the auto purchase. Given the amount, you might choose to send that amount via ACH. Note that the amount is in cents, not dollars, so it shows up as 2500000:

Once the payment goes through, the Funding account will be $25,000 poorer but Bobbie Borrower will be able to afford their Honda. That’s it for loan funding.

Again, you may want to add metadata to the payment for future reference. In addition to metadata (eg. key value pairs such as Vehicle - Honda or LoanType - Auto) you might also choose to hold line items for future reference to distinguish between principal, interest, refunds, fees, etc. This will be useful for customer service and finance teams that might have to answer questions about this payment in the future.

Step 3: Collect monthly payments

Now, based on the terms of the loan contract, the lender is entitled to a monthly payment. Let’s suppose Bobbie Borrower has set up automatic debits and does not need to be involved in the process. That means that you have to initiate an ACH debit from Bobbie Borrower’s account for, say, $700. Note that instead of using the Funding account, AutoLoan is now using the Collections account:

Repeat 36 times, or until the loan is fully repaid.

Those are the fundamentals of running payment ops for any loan business. A 3-year car loan might be shorter term than a 30-year mortgage, and a municipal loan might be much larger than a personal loan, but with these tools, you can build any lender you wish.

What Can Go Wrong?

Of course, what was described above is the happy path. Issues with borrowers or with the payments themselves are the reason lenders have large teams dedicated to customer service, payment ops, and loan servicing.

A common issue could be that the borrower has insufficient funds in their bank account to pay the monthly loan payment. In that case, the ACH debit will fail and AutoLoan will get a notification with a return code for R01—“insufficient funds”—which is one of many possible reasons for an ACH failure. In that case, a member of the customer service team might reach out to inquire about the situation and, if Bobbie Borrower approves it, might redraft the ACH debit once the funds are in the account.

Bobbie Borrower might change banks one day. When that happens, the AutoLoan payment ops team might have to create a new bank account under the counterparty in the system for Bobbie Borrower and maybe deactivate the old one. That would require all future monthly payments to come from the new account.

Note that we assumed in this post that everything would happen over ACH. That might be loan type-dependent. Mortgages, for example, tend to be funded by wires. If that were the case, your "type" on the funding call might be "wire" instead of "ach".

This is just the basic architecture someone would use to create a new lender, but it offers a strong foundation from which to build.

To make all your payment operations simple, scalable, and secure, request a demo of Modern Treasury.