A lending platform built around one calculation engine

A specialist property lender writes bridging and development loans. Every deal has a structure behind it — how the interest is treated, when the money actually goes out, what the borrower receives on day one — and getting that structure right is the business.

All of it lived in one macro-enabled workbook. It worked, in the sense that the people who understood it could make it produce the right number. But it was copied for each new deal, passed between people, and impossible to audit. Two versions of the same case could disagree and nobody could say which was right.

So the brief was not “build us a CRM”. It was: make the calculation trustworthy first, then put the rest of the business around it.

A case starts as an enquiry and ends at redemption. In between it collects borrowers, brokers, introducers, security, valuations, fees, documents and a long tail of approvals. Those used to live in different places and only meet in someone's head.

Now a case is a single record. Security assets sit against it with their valuations and a running total of cover. The drawdown profile sits against it. Documents are generated from its data rather than typed alongside it. Approvals are recorded on it rather than in an inbox.

None of that is exotic. It is the thing that has to be true before a calculation engine is worth building — an engine is only as good as the data it is handed.

Access is role-based throughout, so an introducer, a case manager and someone in finance each see the parts of a case they are supposed to.

Lending maths is not hard so much as fiddly, and fiddly is where money leaks. Interest can be retained out of the advance, rolled up into the balance, or serviced monthly. It can accrue simple or compound, on a 365-day year or a 360-day one. The loan can be drawn in one go or in tranches, each with its own start date.

Then the fees — arrangement, exit, broker — which fall on either side of the gross-to-net line depending on how the deal was sold, and default interest for when the term runs over. Change any one of these and the net advance, the monthly interest and the redemption figure all move. We built it as one engine behind a single, well-defined interface, so the quote, the case, the documents and the reporting all call the same code and get the same answer.

Structuring a deal is a negotiation. A broker asks what happens if the term stretches to eighteen months, or if the client services the interest instead of rolling it up. The useful answer arrives in the next thirty seconds, not the next morning.

So the engine drives a comparison view: two complete loan structures on screen at once, each with its own loan type, year basis, lending entity, gross figure and start date. Change an input on one side and both resolve immediately.

This is the feature the business asked for by name once the engine existed — and the clearest argument for building the engine first. A comparison is only worth anything if both sides of it are right.

A calculator that lives on its own becomes another spreadsheet within a year. The engine only stays authoritative because the rest of the operation runs on the same record: security assets with valuations and total cover, onboarding forms for borrowers, brokers and introducers, documents generated from live case data, export into the accounting system, and an audit trail over all of it.

Each of those is unglamorous on its own. Together they are the reason nobody needs to open the old workbook.

The lender operates across two jurisdictions, and one of them requires a regulatory return every month covering every live facility. Producing that by hand from spreadsheets is the kind of job that is fine until the month you are busy.

The platform generates it from the loan book, in the format the regulator expects, with the lending entity recorded against each case so the right facilities land in the right return.

It is the sort of requirement that reads like a line item in a scope document and then quietly shapes the data model — which entity wrote the loan has to be a first-class field, not a note.

The platform is in service, and the intellectual property in it belongs to the client. Our job was to build it and then hand it over properly: documented APIs, environments written down, and a codebase their own team can carry forward.

We are not naming them here. They have a policy of not putting their name against software development, and we would rather keep the relationship than the logo. The screens on this page are from the development environment and show test data only.