solutions / chit fund platform

Financial systems · AAC

An entire chit funds business, running on one platform.

Every branch, group, rupee and hearing of AAC's chit funds operation - one platform from enrolment to legal recovery, with a field app at the edges.

In production at AAC
ClientAAC
DomainChit funds (NBFC)
BuildWeb platform + mobile field app
StackNode.js · React · MUI · React Native
DataPostgreSQL · Excel-migrated legacy books

Where this started

A chit funds business is a thousand small promises running on a calendar - subscriptions collected daily, groups auctioned monthly, every rupee owed to someone. AAC ran this across branches on paper registers and spreadsheets. The platform had to carry the entire lifecycle without dropping a single thread: who enrolled, who was approved, which group they landed in, what they paid, what they owe, and what happens when they stop paying.

Decision 01

The lifecycle is a state machine, not paperwork.

An enrolment moves through explicit states - proposed by the branch, allotted by SRO into a temp group, running, terminated - and every transition is recorded. Group allotment works across branches in a single action: filter eligible enrolments, pick or create a temp group, allot. Nothing lives in anyone's head.

SRO group allotment - eligible enrolments into temp groups, cross-branch

Decision 02

Nothing enters the book without approval.

Enrolments, KYC documents, payments, even requests from other branches - each has its own approval queue with named approvers. Document verification walks a checklist per customer; a rejected address proof stops an enrolment before it costs anyone money.

Approval queues - document verification with per-customer checklists

Decision 03

The day is the unit of truth.

Every branch runs a teller day: Open while entries flow in, Verified when checked, Confirmed when the books close - and confirmation generates the transactions and accounting vouchers automatically. Editing a confirmed day needs explicit permission and triggers a balance cascade with accounting re-sync. The books cannot quietly drift.

Teller business day - Open, Verified, Confirmed with denominations

Decision 04

Arrears are a workflow, not a report.

Outstanding balances split by group flag - running balances chased operationally, terminated balances escalating through proforma notices into Section 138 cases with hearing tracking. Recovery has states, owners and dates, the same as everything else on the platform.

Arrears & legal - balances, proforma, Sec 138 cases and hearings

Decision 05

One spine, modules that stand alone.

Branch scoping, permissions and approvals are middleware every module inherits - which is why the accounting suite, FD treasury, growth analytics and the field app behave like products in their own right. They share the spine, not each other's assumptions.

One spine, many modules - the platform map

The result

AAC's whole operation now lives in one system of record: branches close their books daily, enrolments cannot skip approval, allotment happens in an afternoon instead of a season, and recovery escalates on rails - from a friendly visit to a court hearing - without a single spreadsheet in between.

One lifecycle, fully recorded

Enrolment to allotment to termination as explicit states with branch scoping on every query.

Books that close every day

Teller day workflow with vouchers generated on confirm - past-day edits gated and re-synced.

Recovery on rails

Arrears split running vs terminated, escalating through proforma to Sec 138 cases and hearings.

A platform, not an app pile

Accounting, FD treasury, analytics and the field app run on one shared spine - each extractable on its own.

Under the hoodNode.js · React · MUI · React Native · PostgreSQL · AWS S3

Bring us the problem