How it works
From application to regulatory filing — one flow.
- Re-keying between systems
- None — one connected flow
- Approvals
- Ladder gated in software
- PAR & BOT reports
- Generated from the live ledger
Before, and with, Ustawi
What changes when the whole lending operation runs on one connected platform instead of a stack of disconnected books.
| Before Ustawi | With Ustawi |
|---|---|
| Client details kept in a spreadsheet | One borrower record across every app |
| Loans tracked on paper or in separate books | Every loan on one auditable ledger |
| Approvals over phone and paper | An approval ladder gated in software |
| Collections reconciled by hand | Field collections that sync automatically |
| Accounting re-keyed from spreadsheets | Accounting that posts as events happen |
| PAR & BOT reports assembled manually each month | PAR & BOT reports generated from the live ledger |
The connected lifecycle
Eight stages, one flow. A loan moves from application to regulatory filing without leaving the platform — and each stage is worked in the app that owns it, on the same record.
A client is captured or selected and a loan is raised against a product that sets the amount range, tenor and repayment method.
Affordability is assessed and, where required, a CRB check runs at intake — the results travel with the application.
Routed by amount band — branch officer → credit committee → board — with segregation of duties enforced by the system.
Requirement gates — collateral perfection, credit-life cover, employer MOU for check-off — must be green before money moves.
The schedule runs on the product's method; material changes are handled as formal restructures that preserve history.
A DPD-driven ladder — SMS → call → visit → notice → escalated recovery — with promise-to-pay capture; field agents collect offline and sync.
Every event posts automatically to a double-entry general ledger — disbursements, repayments, provisions and insurance.
PAR aging, and classification and provisioning per the applicable framework (such as the BOT 5-band model), generate from the same ledger.
Collateral perfection gates disbursement.
Employer MOU and payroll-deduction batches.
Screening at intake; STRs export to goAML.
Cover attached; premium posts as a liability.
Officers capture and collect offline, then sync.
Payments reconcile; fiscalizable receipts go through the configured fiscal service — a TRA API or an approved VFD/fiscal-service provider.
Application → Credit assessment → Approval → Disbursement → Repayment → Collections → Accounting → Regulatory reporting
Follow one loan, end to end
One loan — Loan #4021 · Amina Joseph — travels every stage below. It is the same record, carrying the same loan ID, at each step. Nothing is re-keyed between apps; each view is the same loan seen from a different desk.
Results travel with the application.
Routing by amount band is configured per institution.
- Collateral perfectedRegister updated
- Credit-life cover activePolicy attached
- Approval completeCommittee signed off
Which requirements gate disbursement is configured per product.
| # | Due date | Principal | Interest | Status |
|---|---|---|---|---|
| 1 | 18 Jul 2026 | TSh 100,000 | TSh 18,000 | Paid |
| 2 | 18 Aug 2026 | TSh 100,000 | TSh 18,000 | Paid |
| 3 | 18 Sep 2026 | TSh 100,000 | TSh 18,000 | Due · 4 DPD |
| 4 | 18 Oct 2026 | TSh 100,000 | TSh 18,000 | Scheduled |
Schedule extract on the product's repayment method.
Stages and DPD thresholds are configured per tenant and product — not a universal legal step.
| Dr | 1200 Loans receivable | TSh 1,200,000 |
| Cr | 1100 Cash & bank | TSh 1,200,000 |
Exact entries depend on your configured accounting treatment.
The same loan an officer originated is the loan that ages on the PAR report, posts to the ledger and rolls up into the filing.
Classification and provisioning follow the applicable framework; Ustawi supports traceable reporting, it does not on its own make an institution compliant.
One record, many views
There is one borrower-and-loan record. Origination, Collections, the General Ledger and Reporting are not separate copies — each is its own view of the same data, so what one desk changes, the others already see.
Who does what
Every stage has an owner. The same platform routes the work to the right role — from the loan officer at intake to compliance at the filing.
| Stage | Role | What they do |
|---|---|---|
| Application | Loan officer | Captures the client and raises the loan against a product. |
| Credit assessment | Loan officer · Credit analyst | Runs affordability and, where required, the CRB check. |
| Approval ladder | Credit committee · Board | Approves within the amount band, with duties segregated. |
| Disbursement | Finance · Operations | Releases funds once every requirement gate is green. |
| Repayment & servicing | Loan officer · Finance | Runs the schedule; restructures preserve history. |
| Collections | Collections officer · Field agent | Works the DPD queue, captures promises, collects offline. |
| Accounting | Finance | Owns the ledger, the close and the controls. |
| Regulatory reporting | Compliance · Reporting | Produces PAR, classification and the filing from the ledger. |
One system, one source of truth
Portfolio, PAR aging and the approval ladder — read from the same books every branch and head office works in.
See the whole flow in a live demo.
We'll walk your team from a loan application to a BOT-ready report on the real system.