Case study
The loan book
Salary-deduction lending across three parties: the agent who originates, the lender who funds, and the co-operative that collects.
Reconciliation built inAngkasa and the bank
- Sector
- Salary-deduction lender
- Year
- 2026
- Role
- Team of three
- Stack
- Next.js, FastAPI, PostgreSQL, Celery, Redis
- Runs on
- AWS
The problem
Salary-deduction lending runs across three parties: the agent who originates, the lender who funds, and the co-operative that collects through payroll. Coordinating that on spreadsheets means reconciling by hand against both the bank and the Angkasa deduction file, and until that reconciliation is done nobody knows the true position of the book.
What we built
One system covering the whole arrangement. Agents originate, the lender approves and funds, and the co-operative side is served by a direct integration with the Angkasa system for deduction files. Reconciliation against both Angkasa and the bank runs inside the platform rather than in spreadsheets afterwards, with document handling and background processing built in.
The long version
Salary-deduction lending has an unusual shape: the borrower never really pays the lender, the employer does, through a co-operative that runs the deduction. That makes reconciliation the hard part of the business rather than an accounting afterthought, because money arrives in bulk from a third party and has to be matched back to individual loans.
Doing that on spreadsheets took two people two weeks. It is exactly the kind of work that looks like admin and is actually the control system for the whole book: until it is finished, nobody knows which loans are current. Pulling the Angkasa deduction data in directly and reconciling it against the bank inside the platform is the single change that matters here.
The rest of the system exists to keep that data honest at the point it is created, so agents originate into the same platform the lender approves in and there is one record of a loan rather than three versions of it.