Borrower Tier Scoring for Private Lenders: A Deal Engine Built Over One Weekend

A private lender that wants to reward repeat borrowers needs a rule for moving them up a tier, and this lender did not have one written down. Its deal analysis also still ran on manual file uploads, so the analysis was only as good as the files someone remembered to hand over.

The client is an executive at a private real estate lender. We built a deal analysis scoring engine over a weekend, then used a working call to design the borrower scoring system around it. If you run lending for investors, our page for mortgage loan officers and private lenders covers the wider work.

The situation

The call was set up to test a deal analysis bot on 5 active borrower deals. We walked the executive through the scoring engine on active deals, because a scoring engine only proves itself on deals the lender actually knows.

That conversation also exposed a bigger gap. Scoring one deal is useful. Scoring the borrower across deals, and deciding when that borrower earns better terms, is what turns a one-time analysis into a program.

What was missing

Three things were missing, and they were connected:

• Deal analysis ran on manual uploads. Nothing pulled documents from the systems where they already lived.
• Borrower tier advancement had no codified logic. Whether a borrower moved up a tier depended on judgment, not on a rule anyone could read or test.
• The returning-customer pipeline in the CRM had been planned. The executive confirmed the full plan was documented, but it was never implemented, so there was no place in the CRM where a repeat borrower's progress lived.

What we built

We worked in a deliberate order: engine first, borrower system second, access third.

• The deal analysis scoring engine, built over a weekend and walked through on active deals.
• The full borrower performance scoring system, designed on the call, including the tier advancement logic. This is the rule set that decides when a borrower moves from one tier to the next.
• A refinement pass on the engine using a real rehab scope the executive had sent, so the scoring gets tuned to a deal the lender recognizes.
• Skill files being made accessible from the executive's own Claude account, so the lender can test the engine independently instead of waiting on us.
• A list of data connectors, sorted into immediate and future, so the engine can move beyond manual uploads in a planned order.

What changed

The record of this call states no result, so there is no accuracy figure to report. The change is structural. Borrower advancement went from a judgment call to a designed rule set, and the deal engine was on its way from the builder's side to the lender's own Claude account for independent testing.

The tier logic is not finished, and the reason is useful to anyone building the same thing. It needs the actual rate differences between tiers, which come from the lender's tier rate card, plus the pre-approval documentation. A tier system with no price attached to each tier cannot tell a borrower what they are working toward. So the next inputs were the rate card and the documents, not more code.

What to take from this

If you want to build tiers for repeat borrowers, write down what each tier is worth before you write down how to earn it. Gather the rate differences first. Then define the behaviors that earn a move, such as how past loans performed, and test the rule on borrowers you already know.

Sort your data connections the same way we did. Decide which ones the engine needs now and which can wait. A shorter immediate list gets you off manual uploads sooner.

Frequently asked questions

What is borrower tier scoring for a private lender?

It is a written set of rules that places each repeat borrower in a tier and decides when they move up. The tier advancement logic in this build is designed to replace judgment calls with rules a lender can read, test and change as the business learns.

Why does tier logic need the rate differences between tiers?

Because a tier means something only when it has a price. The engine needs the real rate differences from the lender's tier rate card to build advancement logic, plus pre-approval documentation, so a borrower can see what a better tier is worth.

Can a deal analysis engine really be built over a weekend?

A working first version can. This one was built over a weekend and then walked through on active deals. Refining it still needed a real rehab scope from the lender, which is why we treat the weekend build as a starting point, not a finished product.

Why sort data connectors into immediate and future?

A deal engine fed by manual uploads is slow, but connecting every system at once is how builds stall. Sorting connectors by when you need them lets the engine move off file uploads one source at a time, starting with the ones that matter most.

If your repeat borrowers are treated like new ones, book a 30-minute AI follow-up and reporting audit. We look at what your loan data can already support and where the first scoring rule should go.