Too Small for a Bank Core, Too Big for Spreadsheets

The gap in the market is exactly where you operate

Most lending software in the Philippines is priced and shaped for someone else. A financing or lending company with a few hundred to a few thousand accounts has real operational complexity: multiple loan products, daily collections, penalties, restructures. But it does not have a compliance department, a core banking budget, or six months to spend on implementation. The software built for banks assumes all three. The software built for sari-sari store bookkeeping assumes none of your problems exist.

So most small lenders end up on spreadsheets, not because spreadsheets are good at this, but because nothing on the shelf fits the actual shape of a Philippine lending operation.

What does a bank core sell that you do not need?

Core banking platforms are built around requirements you probably do not have: deposit taking, multi-branch general ledger consolidation, interbank settlement, BSP grade regulatory reporting. That machinery is why they cost what they cost and take as long as they take to deploy. A lending company regulated as a financing or lending company under the SEC operates under a far simpler reporting burden than a bank, and paying for bank machinery to run a lending book is buying a truck to deliver a letter.

What does a Philippine lending operation actually need?

Strip it to the operations that happen every day in a real lending office, and the list is short:

• Product setup that matches how you actually price: flat add-on rates alongside declining balance, weekly, semi-monthly aligned to the 15th and 30th, and monthly schedules, because Philippine borrowers pay on payday
• Generated amortization schedules: every loan booked produces its full schedule automatically, principal and interest split per installment
• Payment posting built for how money really arrives: GCash references, bank transfers, cash over the counter, posted against specific installments with a fixed allocation order
• Automatic penalties and aging: late charges applied by rule, and every account aged into 1 to 30, 31 to 60, 61 to 90, and 90 plus buckets daily
• Borrower statements on demand: every charge and every payment on one printable page
• The owner's numbers: collections today versus scheduled, portfolio at risk, and releases this month, visible without asking anyone to prepare a report

Notice what is not on the list: workflow engines, loan origination scoring, app store apps for borrowers. Nice eventually. Not what is bleeding you today.

Should you buy off the shelf or build for your book?

Some lenders find an off the shelf loan system that fits and should simply buy it. The honest test is how many workarounds you are maintaining. If your pricing, penalty clause, or collection flow forces you to keep side spreadsheets that correct what the software insists on, the system is not managing your book. Your staff are, again, by hand, with extra steps.

Custom software earns its cost when your lending model is specific: your own penalty base definition, your own restructure policy, co-maker arrangements, salary deduction tie-ups with employers. Those specifics are usually where your margin comes from, which is exactly why generic software handles them worst.

What building it actually involves

A focused lending system is not a moonshot. The core is a ledger that computes schedules, applies rules nightly, and posts payments in order, wrapped in the five or six screens your team uses daily: booking, posting, the collections queue, the borrower statement, the owner dashboard. Built against your real products and your real penalty clause, tested against your real book, and running on infrastructure you control, so the system holding your receivables is not a subscription that can disappear.

The measure of success is boring and specific: the day your staff stop maintaining the parallel spreadsheet, the software has won.