OSCB Scheme Data Collection System is a digital platform for cooperative banks - digitizing scheme data collection across 2,000+ unit banking hierarchies, replacing decades-old manual procedures with streamlined digital workflows.
ROLE:
Product & UX
TYPE:
SaaS / Web App
LOCATION:
India
YEAR:
2024
TOOLS:
Figma
01
OVERVIEW
This project wasn't just about digitization -
it was about rebuilding trust in a system that rural communities depend on.
Project Background
The Odisha State Cooperative Bank (OSCB) spearheads cooperative agricultural financing for millions of rural families. This project, undertaken at Mindcys Consultancy Pvt. Ltd., replaces decades-old manual procedures. By digitizing grassroots submissions at the PACS layer.
02
10 weeks,
idea to process.
The design process followed a user-centered approach: research, define, ideate, wireframe, test, and refine. Each iteration focused on simplifying complex architecture workflows, improving client approvals, and creating a seamless project management experience.
DISCOVER
I Week
DEFINE
II Week
IDEATE
III Week
DESIGN
IV-V Week
TEST
V Week
02
DESIGN PROCESS
03
RESEARCH APPROACH
Research Approach.
How I investigated the problem across stakeholders and layers.
FIVE RESEARCH VECTORS
From stakeholder requirements and system workflows to raw data audits, ground-level user sessions, and competitive benchmarking - a multi-layered investigation.
RESEARCH TIMELINE & SYNTHESIS
Requirements
Business objectives and governance scope
→
Workflow
PACS, CCB and OSCB information flows
→
Data
Excel audit, formulas and validation rules
→
Users
Ground-level operator interviews and sessions
→
Context
Competitive benchmarking and enterprise tools
LEVEL 3
OSCB (State Head Office)
LEVEL 2
30+ CCBs (District Level)
LEVEL 1
2,000+ PACS (Ground Level)
DUAL-DIRECTIONAL FLOW
↓
TOP-DOWN FLOW
Rules flow down from the State Head Office: Scheme Templates, validation parameters, policy guidelines, and strict timelines.
↑
BOTTOM-UP FLOW
Data flows up from grassroots PACS societies: Raw transactional numbers, consolidated district summaries, verification files, and final state reports.
03.1
DATA ARCHITECTURE
Understanding
the data flow.
Rules and templates cascade down from the State Head Office while raw data and consolidated reports flow upward from thousands of grassroots PACS societies - creating a continuous, dual-directional data architecture.
03.2
UNDERSTANDING HIERARCHY
Organizational Hierarchy & Tree Model
OSCB_PACS_MEMBER_RECONCILIATION.XLSX
V4.1 (DEPRECATED)
fx
=SUM(F7:K7) + AVERAGE(L8:M8)
The spreadsheets
held the rules.
The spreadsheets were more than data-entry files. They contained the business rules, calculations and taxonomy governing the cooperative banking system.
03.4
EXCEL TEMPLATE AUDIT
STRUCTURAL DISCOVERIES
Multi-Level Headers
Complex nested category definitions
Hidden Formulas
Business rules embedded as inline formulas
Scheme Metadata
Implicit currency units and undocumented headers
Structural Taxonomy
Data cells matching cooperative registry values
Current Process
Insights.
An in-depth analysis of the existing reporting flow across PACS units and the CCB hierarchy. These findings highlight operational friction points, manual overhead, and critical tracking gaps.
Manual Data Collection & Submission
The entire reporting workflow is currently managed manually. Every reporting cycle (monthly, quarterly, yearly), PACS users fill predefined Excel templates and submit them via email to their respective CCB branches. CCB branches consolidate data from multiple PACS before forwarding it to the OSCB branch.
KEY SCOPE ITEMS
Takeaway: Excel-based, email-driven process
Multi-Level Consolidation
The reporting process follows a hierarchical structure: OSCB Headquarters → Multiple OSCB Branches → Multiple CCB Branches → Multiple PACS. Each organizational level receives reports from several subordinate units, verifies the submitted data, consolidates it, and forwards a single consolidated report to the next level.
KEY SCOPE ITEMS
Takeaway: 4-level hierarchy
Repeated Manual Verification
Every submission undergoes manual validation. If discrepancies or missing information are found, correction requests are communicated through emails, phone calls, or messages. The responsible PACS or CCB user updates the Excel file and resubmits it, often resulting in several back-and-forth iterations before approval.
KEY SCOPE ITEMS
Takeaway: Multiple review iterations
Version Control & File Tracking Challenges
Since every correction results in a new Excel file being shared via email, multiple versions of the same report accumulate over time. These files often have similar or identical names, making it difficult to identify the latest version, track changes, and maintain an accurate audit trail.
KEY SCOPE ITEMS
Takeaway: No centralized tracking or audit history
PANEL 01
The Current Process
Branch officers submit Kharif season forms manually. Without central systems, the rural branch office must track all daily loan disbursements locally via scattered spreadsheets.
PANEL 02
Data Collection & Errors
Branch officers frequently encounter offline validation errors. The CCB checker is left to manually consolidate branch data into a single master Excel file under heavy time pressure.
PANEL 03
Consolidation Struggles
The consolidated file is passed up to the OSCB Admin, who faces thousands of raw rows, major version mismatches, and severe delays preparing reports for final RBI submission.
PANEL 04
Data Correction Chaos
A chaotic loop of phone calls and emails starts between the OSCB admin, CCB checker, and branch officer — causing massive loss of time, zero traceability, and repeated rework.
Pain Points Visualized
How manual Excel aggregation across PACS, CCBs, and OSCB leads to systemic operational bottlenecks.
03.5
PAIN POINT
04
RESEARCH FINDINGS
Research Findings.
Key insights from stakeholder interviews, workflow analysis, and field observation across the PACS-CCB-OSCB reporting hierarchy. These findings reveal systemic inefficiencies rooted in manual, decentralized processes.
"The reporting workflow is entirely manual - every period requires individually populating templates across all organizational levels."
10
Key Findings
04
Critical Issues
KEY RESEARCH FINDINGS
01
Data Entry
Highly Manual Reporting
The reporting workflow is entirely dependent on Excel spreadsheets and email. Every period, users manually populate templates and share them across all organizational levels - creating significant manual overhead.
02
Architecture
Complex Multi-Level Workflow
Reporting follows a four-level hierarchy: PACS → CCB Branch → OSCB Branch → OSCB HQ. Every level performs review, validation, consolidation, and forwarding before reaching the next.
03
Consolidation
Data Consolidation Bottleneck
Each CCB Branch receives reports from multiple PACS; OSCB Branches receive reports from multiple CCBs. Users spend significant time manually consolidating data before submission - often from dozens of Excel files.
04
Verification
Manual Validation & Follow-ups
No automated validation exists. Users manually verify each submitted Excel sheet and communicate discrepancies through phone calls, emails, or messaging apps - creating slow, error-prone feedback loops.
05
Corrections
Repeated Correction Cycles
Whenever errors are identified, correction requests are sent back to the previous level. The corrected Excel file is then resubmitted - often repeating this cycle multiple times before final approval is reached.
06
File Tracking
Poor Version Management
Every correction creates another copy of the same Excel sheet. Users struggle to identify the latest version due to identical filenames - leading to version confusion, outdated file risks, and difficult audit trails.
07
Monitoring
Lack of Real-Time Visibility
No centralized system exists to track submission progress. Users cannot determine which reports are pending, which require corrections, or who currently owns the task - forcing frequent manual follow-ups.
08
Storage
No Centralized Repository
Reports are scattered across emails and local folders. Document retrieval is difficult and storage is duplicated across levels - resulting in poor traceability and significant effort to locate historical records.
09
Process
Communication Dependency
The entire workflow relies on manual communication - phone calls, WhatsApp, and emails - for approvals, corrections, and status updates. This creates coordination overhead and untracked decision chains.
The existing reporting workflow is highly manual, decentralized, and dependent on spreadsheets - creating systemic bottlenecks at every organizational level.
Framing the Design Statement
How might we let a PACS Maker with inconsistent internet still submit accurate scheme data on time - while ensuring every number in the final report traces back to its source PACS, the person who entered it, and the person who approved it?
05
DESIGN STATEMENT
NDA:
Certain project details and screens have been omitted or limited due to confidentiality obligations under an NDA.
Copyright:
The design, workflow, and project materials shown are the intellectual property of Mindsys Consultancy and are shared for portfolio reference only.
Let's build something remarkable
+91-8658554107