Build or buy a loan management system: what to ask a vendor

Write the product on one page. List the interest method, the repayment frequency, the fees, the penalty rule and who approves what at each loan size. Most lenders find the product sits closer to standard than they believed, and that discovery alone can save the cost of a build.

Mark what is truly yours. Be strict, because every special case you keep adds to the vendor’s quote or to the scope of a build. A weekly group loan with centre meetings differs from a monthly secured business loan, since the collection point, the surety and the default process all change with it.

Reports and screens are cheap to vary. Interest accrual and schedule regeneration are not, so if your difference sits there, look harder at a build, because that engine is the core a vendor cannot bend.

Ask for live schedules, not slides. Use one reducing balance loan, one flat rate loan and one with a broken first period, all taken from your real book.

Then change them. Make a part-prepayment, shift a due date and restructure one loan, then check that the old schedule is kept and the new one starts from the right date.

Suppose a regulator or a board decision alters the penalty rate mid-year, and ask whether the system can apply it to new loans only. A yes needs a demonstration on a loan that already has instalments posted against it, in front of your operations head.

Every lender files something. Ask for the exact file formats your regulator and bureaus accept, whether overdue ageing, provisioning, portfolio at risk or credit bureau uploads, then open a sample file yourself.

Check who maintains those formats when the regulator changes them, and who tests the new file before your next filing date falls due. Check how fast the vendor delivered earlier changes. Paid extra, or in the plan?

An audit trail should name who changed a rate, a schedule or a receipt, and when, with the old value and the new value side by side. Edit a loan and read the log. Then try to edit the log itself.

Your loan data will outlive the software. It holds borrower histories, guarantor links and years of receipts, and you may need to produce it for a court or an auditor long after the contract ends.

Request a full export in CSV or SQL form carrying schedules, receipts, charges and scanned documents, and ask what that export costs once the contract is over. Get the figure in writing.

Ask where the data is hosted and who holds the backups, and whether your team can query the database for its own reports. Otherwise every question about a borrower’s history, such as a missed instalment in March, goes through a support ticket and a wait of unknown length. Hesitation over export is itself the answer.

A build suits an unusual product. It also fits when no package offers the integrations you need, or when your volumes and rules will outgrow a configured tool within a few years.

A build costs time at the start. It needs an owner who writes rules clearly, and a plan for support after launch, since the code, the hosting and the bug fixes are now yours to maintain.

Before choosing, run the same three-loan test on a vendor demo and on a prototype scope, then list every gap you found in each. Compare the two lists. Then decide.