Multi-investor loan servicing software: build or buy, and what to get right

Private lenders often fund one loan with several investors, each at a different rate. That is ordinary in the business and hard for software: every month, someone has to work out exactly what each investor is owed, what the lender keeps, and what happens when the borrower pays short or late.

This guide is for founders and lenders deciding how to run that in software. It is based on building a loan servicing and origination platform for a US private real-estate lender, with a seven-level payment waterfall, three day-count methods, six daily servicing jobs, and 169 API endpoints covered by about 498 automated tests. The examples below use made-up figures; the rules are the ones that held up in that build.

Should a private lender build or buy loan servicing software?

Buy when your loans fit the product's model; build when they don't. If each loan has one investor, or investors split everything strictly pro rata at the same rate, an off-the-shelf servicing product will usually do the job for less. Custom software pays off when the money rules are your own: investors at different rates on the same loan, a spread the lender earns only after investors are paid, or reporting your investors expect and the product can't produce.

The test is simple. Take one real loan with several investors and a short payment, and run it through the product. If someone still has to fix the numbers in a spreadsheet afterwards, the product doesn't fit, and that spreadsheet is the most fragile part of your business.

There is a middle path too. Some lenders keep the tool they already use for one half of the business and extend it rather than run two systems. That is a reasonable call, and it's the one the lender in this project eventually made for origination. Whichever way you go, the rules in the rest of this guide are what the software has to get right.

How do you split a loan payment between multiple investors?

You apply every payment through a payment waterfall: a fixed, written order of who gets paid first. A waterfall is that order. A participation is one investor's slice of a loan, with its own amount and rate. An investor's basis is the principal they still have in the loan.

The waterfall in the lending platform this guide is based on has seven levels, in this order:

1. Levels 1 and 2: interest, investors first. Each investor's interest for the period at their own rate.
2. Level 3: the lender's spread. The difference between what the borrower pays and what investors earn, released only when investors' interest for the period is paid in full.
3. Levels 4 to 6: default interest and fees.
4. Level 7: principal. It reduces each investor's basis pro rata.

Here is one month on an example $500,000 loan at 12.5%, funded by three investors:

Example figures, one month's interest, monthly accrual for simplicity.

Now the borrower pays $5,000 instead of $5,208.33. The waterfall decides the outcome, not a person: investors still receive their full $4,458.33, the lender's spread gets the remaining $541.67, and the $208.33 shortfall stays owed to the lender. Investors made whole first is a common promise to investors, and the software should make it impossible to break by accident.

Interest itself depends on a day-count convention, the rule for how many days a month or year counts as. Common ones are 30/360, Actual/360 and Actual/365, and they give different numbers for the same loan. Pick one per loan, store it on the loan, and show it on every statement.

How do you avoid rounding errors when paying investors?

Store money as exact decimals, never floating-point numbers, and hand out leftover cents by a fixed rule. Floating-point numbers drift by fractions of a cent; across many investors and many months that drift becomes books that don't reconcile.

Even with exact decimals, splits leave remainders. Split $1,000.00 equally between three investors and each share is $333.333…, which rounds to $333.33 three times: $999.99. One cent has to go somewhere, and it has to go to the same place every time the same calculation runs. One simple rule: round every share down, then give the leftover cents to the largest remainders, breaking ties in a fixed order.

from decimal import Decimal, ROUND_DOWN

CENT = Decimal("0.01")

def split(amount, shares):
    """shares: {investor: fraction of the loan}, fractions sum to 1."""
    raw = {k: amount * f for k, f in shares.items()}
    out = {k: v.quantize(CENT, ROUND_DOWN) for k, v in raw.items()}
    left = int((amount - sum(out.values())) / CENT)
    # leftover cents go to the largest remainders, ties by investor id
    for k in sorted(raw, key=lambda k: (-(raw[k] - out[k]), k))[:left]:
        out[k] += CENT
    return out

third = Decimal(1) / 3
split(Decimal("1000.00"), {"A": third, "B": third, "C": third})
# -> A: 333.34, B: 333.33, C: 333.33  (adds up to 1,000.00)

The lending platform used deterministic penny-rounding with explicit rounding rules for investor payouts, with exact decimals everywhere and reconciliation checks on every balance, so the books reconcile to the cent. Write your rounding rule down where your accountant can read it, not only in the code.

What happens when a payment bounces after investors are paid?

You reverse it with new ledger entries; you never edit or delete the original. A bank payment can be returned days after you recorded it, and by then the money may already have been split and paid out. If the system lets someone change the old payment, the history an investor or auditor relies on is gone.

An append-only ledger records every movement of money as a new entry and never changes old ones. A returned payment becomes a reversing entry for the payment and for each investor's share of it. What happens next is a business policy, and it should be decided before launch, not on the day it happens:

• Hold distributions until payments clear. A bank payment can be returned days after it was recorded, so set a holding period you are comfortable with before money goes out to investors.
• Recover or offset. If investors were already paid, decide whether the amount is clawed back or deducted from their next distribution, and show it on their statement.
• Make posting idempotent. A payment that arrives twice, or a button pressed twice, must still be applied once.
• Use maker/checker for sensitive actions. Reversals and manual adjustments need a second person's approval, so one mistake can't move money on its own.

The platform this guide draws on posts corrections as reversing entries, makes posting idempotent and requires maker/checker approval for sensitive actions. The holding period and recovery rules are yours to set with your accountant, because they change with how your investors are paid and what your agreements say.

A ledger you can edit is a ledger nobody can trust.

What should the first version of loan servicing software include?

The money core first, screens second. If the numbers are right, everything built on top of them can be trusted; if they're wrong, a better dashboard only shows the wrong number more clearly. A first version that a lender can run real loans on needs:

• Loans, investors and participations, each with its own amount and rate.
• The payment waterfall, written down and tested against loans worked out by hand.
• Daily interest accrual with the day-count convention stored on each loan.
• An append-only ledger with reversals, idempotent posting and maker/checker approval.
• Payoff quotes, and investor statements of positions and distributions.

Borrower portals, a deal pipeline and dashboards can come next. Before any of it, turn a handful of real loans your team has worked out by hand into automated tests, so a code change that moves any of those numbers fails before an investor notices.

To scope it, start with a Build Plan: from $500, ready in 2 to 3 days, credited in full toward the build. It writes down the waterfall, the money rules, the data model and a security plan, with a fixed price agreed before any code. See how this was built in the private real-estate lending platform case study, or what a custom build covers on the private lending software page. For budgets in general, read what an MVP really costs.

Questions founders and lenders ask

Written bySikandar Javid

Technical partner for real-estate and fintech founders: decides with you what to build, launches it and stays on after launch. Top Rated Plus on Upwork with 100% Job Success. Builds MVPs, rescues stalled builds and hardens AI prototypes.

See client work →