Two interest methods
Simple-interest, calculated on days between the last payment and the processing date; and fixed-interest, calculated on days between instalment due dates. Both are first-class, not one emulated with the other.
Servicing suite
The ledger that keeps every loan correct
Simple- and fixed-interest accrual, fee schedules, statements, partial payments with rebate and pro-rate maths, refinances, early payoff, modifications and automated accounting entries — for every loan type on one ledger.
2interest methods: simple-interest and fixed-interest
1ledger for store, online and mobile activity
$50B+in payments processed to date
Loan maths
Where servicing systems usually go wrong
Short-term lending is not amortisation-table lending. The maths has to handle irregular payments, mid-term refinances and fee structures that differ by state.
Partial payments, properly
Partial payments carry rebate and pro-rate calculation rather than being posted as a lump against principal — so the balance and the payoff quote stay defensible.
Refinance & early payoff
Refinance capability with the old loan closed and reconciled, and early payoff with rebate computed to the day.
Schedules that match reality
Auto-computed instalments, alternate first-payment dates, end-of-month handling and configurable payment frequency.
Returns and NSF
Return-cheque and NSF handling, redeposit, bank deposit for garnishment, refunds, and time-bound rollback and void of posted transactions.
Payments →Automated GL entries
Accounting entries generated from the same events the agent posts, so the general ledger and the loan ledger cannot drift apart.
Across loan types
One servicing core, every loan type
Every one of them is worked from the same screen layout, so a CSR trained on nothing in particular can service a payday loan, an installment loan or a line of credit without learning a different application (one interface, every module).
- Payday / deferred deposit
- Full life cycle: new-loan disbursement by cash, cheque, debit card or ACH; partial payments with rebate and pro-rate; paid-in-full; deposit of borrower cheques; return-cheque and NSF; refunds; post-court-filing and post-judgment payments; write-offs; time-bound rollback and void; bank deposit for redeposit and garnishment.
- Installment
- Multiple payment schedules, simple- and fixed-interest, APR computed from amount, rate, duration, frequency and instalment count, multiple collateral types, alternate first-payment date, early payoff with rebate and refinance.
- Line of credit
- Secured and unsecured, fixed-term or revolving/non-revolving, configurable due-cycle days, auto or manual closure, statement formats and cycle days, authorisation limits, co-borrower support, monthly billing statements, default handling after a defined number of non-payments, charge-off, and annual or membership fees.
- Title / auto equity
- Vehicle condition capture driving the qualified loan amount, Title-Track qualification limits, title transfer handling, APR and fee configuration, missed-instalment notices, late-fee grace periods and collection notices, with separate customer, loan, title and collection status codes.
- Check cashing
- Any check, any mode, multi-disbursal options and a configurable fee structure on a pay-as-you-go, zero-fixed-cost model.
Each loan type holds as many loan products as you configure
The six entries above are loan types, not loan products. A lender typically services several loan products inside one of them at the same time — different terms, different fee configurations, different document sets — with each loan product enabled per brand, channel, state and store. The servicing maths, the ledger and the GL treatment are identical whichever one the borrower took. How the loan-product engine works →
Borrower self-service
Fewer calls, same ledger
- Balance, schedule and payoff quote without calling a branch
- Make a payment, set up auto-ACH or change a payment method
- Download statements and signed documents, on your own templates
- Apply for a follow-on loan against existing history
- Mobile-app-ready access on any device
Self-service that writes to the same ledger is a cost reduction. Self-service that writes to a separate online system is a reconciliation problem.
QFund Online is the borrower-facing face of the same core, so a payment made on the website at 11pm is on the branch screen — and in the GL — without a batch in between.
If you would rather build the borrower experience yourself, the same operations are available as RESTful JSON APIs — balance, schedule, payoff quote, payment posting, statement and document retrieval, follow-on loan application — so your own portal writes to this ledger too. API layer →
FAQ
Servicing questions
Can QFund service loans it did not originate?
Yes — that is the normal migration case. Existing loans, balances, schedules, payment history and documents are brought across during migration, then serviced natively. Balancing the migrated book against your current system is an explicit phase, not an assumption.
How are modifications and hardship arrangements handled?
As first-class servicing transactions with their own audit trail: re-scheduled payments, adjusted fees, deferrals and payment plans. They post to the ledger and the GL like any other event, so a hardship programme does not become a spreadsheet kept next to the system.
Does the general ledger posting really come from the same events?
Yes. Accounting entries are generated automatically from servicing transactions rather than assembled from an export. That is what removes most of the month-end reconciliation work lenders do between an origination system and a servicing system.
Bring us your hardest servicing case
A mid-term refinance with a partial payment, a rebate and an NSF in the same cycle. We will post it live and show you the ledger and the GL entries.