The problem
Ugandan schools — particularly low-fee private and semi-rural public schools — struggle to access formal loans from banks and microfinance institutions (MFIs). The barrier isn't creditworthiness; it's documentation. Schools can't produce the standardised financial records lenders require.
Kupaa is a school management platform that already captures exactly this data: fee payments, attendance, income and expenditure, auditor-ready reports. The research question was simple but unexplored: could Kupaa become the bridge between schools and formal credit?
"How might we help schools access financing?"
— Core design question, Kupaa research sprintResearch questions
Before talking to any FI or school, the team mapped the questions that needed answering — not to build anything yet, but to understand the landscape well enough to design the right thing.
What do lenders actually need?
Minimum requirements vary by institution. We needed to gather and normalise them so Kupaa could present one consistent package to multiple FIs simultaneously.
Who approves the loan internally?
Loan applications require multi-stakeholder sign-off (head teacher, board, founders). Understanding approval chains was as important as document design.
How does Kupaa play in?
Could Kupaa's existing data — MM transactions, attendance, expenditure records — satisfy lender requirements with no extra school effort?
Short-term vs long-term loans?
Loan type, repayment period, and credit score improvement timelines were all unknowns. The research needed to scope which loan products were feasible first.
What banks and MFIs require
Stakeholder interviews with financial institutions produced a clear, consolidated list of mandatory requirements. Every document on this list was something Kupaa already generated — or could generate — from data schools enter in the normal course of running their institution.
6-month bank statements
Formal transactional history demonstrating cash flow stability.
Two-term payment history
Mobile money, cash, and in-kind school fees — sourced directly from Kupaa's transaction ledger.
Auditor's report
Daily attendance, performance metrics, student and teacher counts — auto-generated by Kupaa.
Asset declaration
Physical assets (land, buildings, equipment) declared by the school administration.
Income & expenditure report
Projected and actual revenue by fund type, mapped against expenditure categories.
Books of accounts
Full accounting records, exportable from Kupaa's financial ledger.
Ministry certification
Official school registration document confirming government authorisation to operate.
Completed loan application
Signed and witnessed form with school details, loan particulars, and security information.
The key insight from this mapping: six of the eight requirements were data Kupaa already held. The school's job could be reduced to providing asset declarations, Ministry certification, and signing the loan form — everything else could be generated automatically.
Concept testing
With a clear picture of FI requirements, the team moved to concept testing with two pilot schools representing different contexts: one semi-rural public school operating entirely on Mobile Money, one semi-urban private school in a dormant state with limited digital footprint.
Buzaaya Secondary School
Semi-rural · Public · All transactions via Mobile Money. Rich transactional data already present in Kupaa — ideal candidate for automated document generation.
ACTIVE DATAVictory Primary School
Semi-urban · Private · Dormant account. Limited Kupaa data. Tested the scenario where schools need to first activate record-keeping before they can access finance.
DORMANT
The concept test confirmed the two-step process: first present whatever school data existed to a selected FI, collect their feedback on gaps, then prototype the loan application pack around those exact requirements. The school and FI feedback loop was built into the research design, not bolted on afterwards.
Prototype design
The research produced a clear brief for two prototype modes: a digital online application embedded in Kupaa, and auto-filled printable forms for schools or FIs that required paper originals.
School Profile
Pre-populated from Kupaa: name, Ministry cert number, category, contact, financial summary.
Loan Particulars
Amount, purpose, cost of project, repayment period, monthly payment. Loans with other institutions declared.
Document Upload
Each required document is a step. Stepper shows % completion. Kupaa auto-attaches available reports.
Stakeholder Declaration
Multi-signatory sign-off. Schools communicate directly with the FI through Kupaa's messaging layer.
The online prototype used a progress stepper showing completion percentage — important because schools found the manual process overwhelming. Showing them they were 60% done was itself a motivational design choice.
Artefacts: what Kupaa generates
The research concluded that Kupaa needed to auto-generate three classes of document — all from data already in the system. These slides from the research deck show the actual Kupaa-generated outputs used in pilot testing.
Revenue & Expenditure Report
A dual-format document: a fund-level expenditure summary (General Fund, Meals Fund, Services) alongside a detailed revenue report showing fees collected, capitation grants, board governor income, and parental contributions by category.
Fee Payment Transaction Report
A transaction-level ledger showing every fee payment processed through Kupaa: cash, mobile money, in-kind, and others. The detailed statement includes Transaction ID, MNO (network operator), and timestamp — exactly the granularity banks require.
Pre-filled Loan Application Form
The most critical artefact: a Maybank-format school loan application form, pre-populated by Kupaa with the school's details, financial summary, and signatory information. The school no longer fills a blank form — they review, sign, and submit.
Having a real, populated loan application form as a prototype artefact — not a wireframe — was the most powerful thing the team brought to FI meetings. It made the concept tangible, testable, and easy for bank officers to evaluate against their own checklists.
The Kupaa loan application pack
The research prototyped a consolidated document pack — five auto-generated files that Kupaa produces on demand, ready to submit to any participating FI.
Mobile money transactions
6-month ledger with Transaction ID, MNO, date, amount, and payment type.
Cash transactions
6-month cash payment history across all fee categories.
Income & expenditure
Full revenue report — fees, grants, donations — against itemised expenditure by fund.
School information & certification
Student/teacher counts, attendance, performance, Ministry certification number.
Loan application form
Pre-filled from Kupaa data. School provides security details and stakeholder signatures only.
Open questions for next phase
The research deliberately surfaced the unknowns that needed FI and legal input before the product could be shipped. These are the questions the prototype testing was designed to answer in the next sprint.
- Who introduces Kupaa to the pilot MFI or bank? A warm introduction determines how fast the first school gets approved.
- How is school financial data shared with the FI — is there a data-sharing agreement, and what is the privacy framework?
- Are government (public) schools legally permitted to take institutional loans? This differs by local authority.
- Is a school bank account a mandatory prerequisite, or can Mobile Money serve as the primary repayment channel?
What this research proved
The core bet of the Kupaa loan feature is that data dignity is the product. Schools already have creditworthiness — they collect fees, pay salaries, manage assets, maintain records. What they lack is the ability to present that story in the format lenders recognise.
Kupaa doesn't make schools more creditworthy. It makes their existing creditworthiness legible to banks. The research confirmed that the gap was entirely on the documentation layer — and that Kupaa already sat on top of every data point needed to close it.
The next step was clear: get a real FI into a room with a real pre-filled application pack, observe every question they asked, and ship the feature that answers those questions before they're asked.