For District Central Cooperative Banks
Built for DCCBs running payments across 10–50 affiliated societies (PACS, dairy, sugar, weavers) with seasonal lending cycles that don't fit the usual NACH retry assumptions.
Typical impact at your federation
20+ societies onboarded in 3 weeks — each isolated, each branded, centrally overseen
Your members don't earn in equal monthly tranches.
Kisan Credit Cards, PACS crop loans, gold-against-produce — these follow kharif (June–October) and rabi (November–April) cycles. Forcing a farmer onto a fixed 5th-of-the-month EMI is why bounces cluster in January and July. BQT's mandate engine supports seasonal presentation schedules: one lump sum at harvest, bi-monthly during kharif, interest-only in off-season. All NPCI-compliant, all within the same NACH spec — no custom file format, no sponsor-bank pushback.
Kharif presentation (Jun–Oct)
Bulk collection Oct 15 post-paddy harvest. Interest accrued, principal collected, one file to sponsor bank.
Rabi presentation (Nov–Apr)
Bulk collection Apr 20 post-wheat/rabi harvest. Retry window tuned to mandi settlement dates, not calendar month-end.
What's broken today
- Every society's paperwork comes to the DCCB ops desk — no distinguishable by-society view
- Seasonal (kharif / rabi) lending cycles don't match default retry schedules
- Society secretaries can't answer member queries without calling the DCCB
- Consolidated NACH file has no inherent society breakdown — reconciliation is manual
- Reporting to NABARD / state cooperative registrar is hand-assembled per quarter
- Multi-society RBAC not supported by typical single-bank platforms
How BQT solves it
True multi-tenant isolation per society
Each society is its own namespace — own users, own members, own branded URL, own mandate queue. Data from one society invisible to another. DCCB supervisors see everything; society admins see only their scope.
Seasonal mandate windows as a first-class concept
Configure a mandate with kharif (Oct–Nov) or rabi (Mar–Apr) window. Batch scheduler automatically only presents it inside its season. No more manual pause / resume cycles.
Society-level member portal
Each society gets its own branded URL on the member portal. Members enter a society code + mobile number to log in. Cross-society identity isolation guaranteed.
Central oversight, local control
Five distinct staff roles cover every level — bank administrator, supervisor, operator, read-only auditor, society administrator — each with strictly-enforced access boundaries. DCCB staff see across all societies; society staff see only their own members.
Regional language operations
Tri-lingual UI and notifications — society staff often work in Marathi / Hindi natively. Number + date formats in Indian standards everywhere.
Single platform, many federations
One BQT instance can host the DCCB + its 20–50 affiliated societies cleanly. No duplicate infrastructure to maintain.
Central DCCB view
Your ops desk sees the entire federation: every PACS, every affiliated society, every outstanding mandate. Roll-up dashboards. Per-society P&L.
Per-society workspace
Kolhapur PACS secretary logs in and sees only Kolhapur's members. Their own branding. Their own mandate approvals. Cannot see Sangli or Satara's data — enforced by the platform.
NABARD-ready audit
Every cross-society action the central DCCB takes is logged with society, user, IP and timestamp — exactly the trail NABARD's IS auditor asks for during a cooperative inspection.
Ready to see it with DCCB-specific flows?
Our demo includes a seeded Kolhapur DCCB tenant with 3 affiliated societies, kharif + rabi seasonal mandates, and a federation roll-up dashboard — end-to-end walkthrough.