Regulatory Reports & Filings
Turn your live loan ledger into regulatory-ready reports.
Build PAR, classification, provisioning and disaggregation returns live from the loan ledger, validate and approve them, export for submission, and trace every figure back to the loan.
- PAR30 · from the live ledger
- 4.2%
- Provisioning return
- In review · pending approval
- Aug 2026 Portfolio Return
- Approved v3 · exported
One center for the whole reporting operation
Regulatory reporting is a workload, not a single number. Above the portfolio sits one view of the reporting period — what is due, what is ready for review, what needs attention, and what has been approved and exported. This is where finance, risk and compliance manage the returns, not just read the metrics.
All values are derived live from the loan ledger and payment history.
- Portfolio ReturnExported
- Classification ReturnApproved
- Provisioning ReturnReady for review
- Disaggregation ReturnNeeds attention
From a returns workbook to one approved return
Drag the slider: the same August return, rebuilt in a spreadsheet versus built from the ledger in Ustawi.
| Kijitonyama | 182M | PAR 3.8% | prov? |
| Mwanza | 241M | #REF! | 6.4M |
| Arusha | 198M | PAR 2.9% | ask Finance |
| Dodoma | ?? | PAR 4.6% | — |
Regulatory reporting workflows are built around applicable requirements. Ustawi generates reports from live portfolio and accounting data and supports validation, review and traceability; it does not, on its own, guarantee regulatory compliance, and the applicable requirements depend on your institution type and framework.
One ledger. One reporting source.
The usual regulatory return is rebuilt in a spreadsheet: export balances, age them by hand, classify, provision, and hope the arithmetic holds. Ustawi removes that gap — the same loan, payment, customer, collateral, branch and accounting data feed one reporting engine, and the report is a view of the books, not a parallel reconstruction of them.
PAR analysis, live from the ledger
PAR30 and PAR90 are calculated live from loan schedules and payment history — not aged by hand in a spreadsheet. The aging buckets below add up to the portfolio, and each figure traces back to the loans behind it.
| Aging bucket | Outstanding | Share |
|---|---|---|
| Current | TSh 820.1M | 90.9% |
| 1–30 days | TSh 44.2M | 4.9% |
| 31–60 days | TSh 18.9M | 2.1% |
| 61–90 days | TSh 9.0M | 1.0% |
| 90+ days | TSh 10.1M | 1.1% |
Classification is derived from the loan's actual condition
Classification is not typed in — it is derived from delinquency. A loan's days past due drive its band, and the band drives provisioning. The bands and rates applied follow the regulatory framework configured for your institution; the example below uses a 5-band structure.
| Band | Loans | Outstanding | Provision rate |
|---|---|---|---|
| Current | 1,192 | TSh 820.1M | configured |
| Especially mentioned | 96 | TSh 44.2M | configured |
| Substandard | 41 | TSh 18.9M | configured |
| Doubtful | 22 | TSh 9.0M | configured |
| Loss | 21 | TSh 10.1M | configured |
The band structure and provision rates are set by the applicable configured framework — not a single universal rule.
Provisioning from portfolio data and eligible security
Provisioning is derived from the exposure and the classification, and — where the framework allows — can incorporate eligible security. The calculation is not a blanket rule: how security is recognised depends on the applicable regulatory framework and the rules configured for your institution.
Gross exposure → classification → applicable provision rule → eligible security → adjusted provision. Actual rates and eligible-security rules are configured to the applicable framework.
Reporting and accounting stay connected
Provisioning does not stop at a report line — it posts back to the general ledger as a real journal. So the provision on the return is the provision in the books: the report total equals the ledger-derived value, not a separate estimate.
| Dr | Provision expense | TSh 2,000,000 |
| Cr | Allowance / provision | TSh 2,000,000 |
The exact accounts and postings depend on your configured accounting treatment — see General Ledger & Finance.
Slice the portfolio without rebuilding the report
A regulator or donor rarely wants a single portfolio number — they want it broken down. Disaggregation produces those cuts directly from the portfolio, so a sector, region, gender or branch view is a filter, not a fresh spreadsheet.
| Sector | Outstanding | Loans | PAR30 |
|---|---|---|---|
| Trade | TSh 280M | 428 | 3.8% |
| Agriculture | TSh 190M | 301 | 5.1% |
| Services | TSh 160M | 254 | 3.2% |
| Manufacturing | TSh 120M | 142 | 4.0% |
| Other | TSh 152M | 247 | 5.1% |
Every cut is derived from the same underlying loan records.
See where the reporting numbers come from
The institution total is a roll-up of its branches. Ustawi shows the same figures per branch, so management can reconcile the return — Branch → Portfolio → Loan → Classification → Provision — rather than trust one consolidated number.
| Branch | Portfolio | PAR30 | Provision | Status |
|---|---|---|---|---|
| Kijitonyama | TSh 182M | 3.8% | TSh 3.7M | Ready |
| Mwanza | TSh 241M | 5.2% | TSh 6.4M | Review |
| Arusha | TSh 198M | 2.9% | TSh 2.9M | Ready |
| Dodoma | TSh 281M | 4.6% | TSh 5.6M | Attention |
From the reporting calendar to export
Know what is due, when, and who owns it
Each return has a period, an owner and a status. Ustawi tracks the reporting calendar so a return does not quietly drift past its window — with the due date driven by the reporting requirement configured for your institution, not a single universal deadline.
| Report | Period | Due | Owner | Status |
|---|---|---|---|---|
| Portfolio Return | Aug 2026 | Per config | Finance | Exported |
| Classification Return | Aug 2026 | Per config | Risk | Approved |
| Provisioning Return | Aug 2026 | Per config | Finance | Review |
| Credit Information | Aug 2026 | Per config | Credit ops | Ready |
| Portfolio Return | Sep 2026 | Per config | Finance | Draft |
| Classification Return | Sep 2026 | Per config | Risk | Draft |
Due dates shown as "per config" follow the reporting requirement configured for your institution type and framework.
Validate the numbers before they leave the institution
Before a return is generated, Ustawi runs completeness and reconciliation checks across the portfolio and flags what needs attention — so problems are caught inside the institution, not in a regulator's query.
- All active loans have customer records
- Repayment schedules complete
- DPD calculation complete for active loans
- Classification calculated
- Provisioning calculated
- GL reconciliation complete
- 3 loans missing collateral value
- 2 loans missing sector classification
- 1 branch has an unreconciled payment
Which validations run depends on the reporting requirements configured for your institution.
Don't submit bad data — resolve exceptions first
Validation issues become exceptions with an owner and a status, so they are worked and closed before a return is exported — the difference between a reporting system and a spreadsheet.
Whether an exception blocks export is configured per institution.
Build reports from the portfolio — not spreadsheets
A report is assembled from the underlying data, with its source and freshness on show and a data-checks panel that has to be satisfied before it can move to review.
Ustawi prepares and exports returns for submission through the applicable BOT reporting channel; it does not submit directly on your behalf.
A real generated report, not a marketing card
What the prepared return looks like before it is approved and exported — institution, period, totals and the breakdowns behind them.
| Band | Loans | Outstanding |
|---|---|---|
| Current | 1,192 | TSh 820.1M |
| Especially mentioned | 96 | TSh 44.2M |
| Substandard | 41 | TSh 18.9M |
| Doubtful | 22 | TSh 9.0M |
| Loss | 21 | TSh 10.1M |
Prepared, reviewed, approved — then exported
A regulatory return is not generate-and-download. It moves through sign-off: prepared, validated, reviewed and approved before it can be exported — and who did each step is recorded.
Tap a stage to stop on it. Hover pauses the animation.
Know exactly which version was reviewed
Reports change as exceptions are resolved and figures refresh. Ustawi keeps each version — what changed, when, and who acted — so a correction, a management review or a later query can always point to the exact version that was approved.
- Version 315 Sep · 14:30Approved by compliance manager
- Version 212 Sep · 16:10Returned for correction
- Version 110 Sep · 09:30Draft
Exported for submission
Once approved, the return is exported for submission through the applicable BOT reporting channel. Ustawi records the export — the report, the period, the file version, who exported it and when, and the approval it carried — so there is a clear record of what left the institution.
Every number traceable, every action recorded
Every reported number traces back to its source
This is the signature of the app. A number on a return is not a typed figure — it is the top of a chain. Open PAR30 and you see the loans behind it; open a loan and you see the payment history behind that. For an auditor, the answer to "where did this come from?" is a drill-down, not a rebuild.
Report → Metric → Portfolio → Loan → Payment history
An audit trail for every report
Every material action on a report is captured with a timestamp and the user — the same Control → Evidence → Audit story that runs across the platform. When an examiner asks who did what and when, the trail is on one screen.
- 15 Sep · 13:403 exceptions resolved· Credit manager
- 15 Sep · 13:52Report regenerated (v3)· Finance officer
- 15 Sep · 13:55Validation checks passed· System
- 15 Sep · 14:05Report reviewed· Head of finance
- 15 Sep · 14:30Report approved· Compliance manager
- 15 Sep · 14:42Report exported· Finance manager
See your own PAR30 drill down to the loans and payments behind it.
Configured to your framework, connected to your books
Reporting depends on your institution type and framework
There is no single reporting structure that fits every lender. Tanzania regulates non-deposit-taking microfinance providers, SACCOS, community groups and deposit-taking microfinance banks under separate instruments, and Zanzibar has its own. Ustawi configures the reporting around the framework that applies to you.
Which classification structure, provision rules and reports apply follow from your institution type and framework — configured during implementation. Ustawi is designed with these frameworks in mind and is not a substitute for legal advice.
Connected across the Ustawi platform
Reporting is not a standalone module — it reads the same loan, delinquency, collateral and ledger data as the apps around it, which is exactly why the figures tie back to the books.
The loan ledger every reported number is built from.
Explore app →Delinquency data that drives PAR and classification.
Explore app →Eligible security recognised in provisioning.
Explore app →Provisioning posts here; report totals tie to the books.
Explore app →The wider control, evidence and approval layer.
Explore app →AML-related reporting on the same customer records.
Explore app →Reporting exists to show your work, plainly
A regulatory return is how an institution shows a regulator, a lender or a board that its book is what it says it is. When the numbers are built from the ledger and every figure traces to a loan, that becomes a matter of opening a screen — not defending a spreadsheet. Ustawi's job is to make the return trustworthy by construction.
Who uses Regulatory Reports & Filings
Reporting is a team effort across finance, risk, compliance and management. Each sees the part it needs.
Generate and reconcile regulatory financial data.
Review PAR, classification and provisioning.
Validate reporting requirements and approve returns.
Review branch-level reporting and exceptions.
See reporting status and portfolio exposure.
Trace reported figures back to source records.
Getting live
How we get you live
A structured rollout, from mapping your applicable framework to running reporting on live portfolio data.
- 01Discover
Map your institution type, applicable framework and required returns.
- 02Configure
Set classification bands, provision rules, reports and reporting calendar.
- 03Migrate
Bring the loan ledger, payment history and branch data onto the platform.
- 04Test
Validate PAR, classification, provisioning and exports against known figures.
- 05Train
Bring finance, risk and compliance staff up to speed on the workflow.
- 06Go live
Run reporting on live portfolio data, with support on hand.
See Regulatory Reports & Filings in a live demo
Request a DemoFrequently asked questions
Live from the loan schedule and payment history — not aged by hand in a spreadsheet.