📌 This is the full, unabbreviated Software Requirement Document DeX generated for Loanmind AI, continuing directly from the Sample BRD — Loanmind AI. It translates the business requirements into system architecture, infrastructure configuration, data models, API specifications, and non-functional requirements.
For the trimmed, Contractor Sync version of this document, see Specification — FSD.
| Field | Details |
|---|
| Project Name | LoanMind AI |
| Version | 1.0 |
| Created Date | June 09, 2026 |
| Last Updated | June 09, 2026 |
| Author | Senior Software Architect |
| Status | Draft |
2. Introduction
2.1 Purpose
The purpose of this document is to provide a detailed description of the requirements for the LoanMind AI platform. LoanMind AI is an intelligent, AI-driven lending assistant designed to automate and streamline the Micro, Small & Medium Enterprises (MSME) and Credit Monitoring Arrangement (CMA) business loan processing lifecycle. It aims to eliminate administrative bottlenecks, accelerate credit assessment, and reduce the high friction costs associated with traditional underwriting, thereby making formal credit more accessible to MSMEs.
2.2 Scope
The scope of the LoanMind AI system encompasses the entire pre-disbursement journey of a business loan application, from initial document submission to the generation of a final, bank-ready credit assessment report.
In Scope:
- Secure user (applicant) registration and profile management.
- Automated ingestion, OCR, classification, and data extraction from applicant-submitted documents.
- A dynamic, context-aware question-and-answer system to fill information gaps.
- An interactive voice-based interview module for conversational data collection.
- Two distinct processing workflows: a free "MSME Analyzer" for smaller loans and a premium "CMA Project" workflow for complex applications.
- Automated generation of a suite of business health and credit analysis reports in Markdown format.
- A structured Document Management System (DMS) using Alfresco for auditable storage of all application-related artifacts.
- A Flutter-based mobile application for the applicant's journey and a web-based portal for administrative/bank officer access.
Out of Scope:
- Direct integration with bank Core Banking Systems (CBS) for loan disbursement.
- Post-disbursement loan monitoring and management.
- Real-time credit bureau score fetching (e.g., CIBIL). This can be a future integration.
- Legal and compliance verification of property or asset documents.
2.3 Definitions & Acronyms
| Term | Definition |
|---|
| AI | Artificial Intelligence, referring specifically to the use of Large Language Models (LLMs) like Google Gemini. |
| API | Application Programming Interface. |
| CMA | Credit Monitoring Arrangement. A detailed financial report required by banks for large business loans. |
| DMS | Document Management System. In this project, refers to Alfresco Content Services. |
| DSCR | Debt Service Coverage Ratio. A measure of a company's available cash flow to pay current debt obligations. |
| FastAPI | A modern, fast (high-performance) web framework for building APIs with Python. |
| Flutter | Google's UI toolkit for building natively compiled applications for mobile, web, and desktop from a single codebase. |
| JSON | JavaScript Object Notation. A lightweight data-interchange format. |
| JWT | JSON Web Token. A compact, URL-safe means of representing claims to be transferred between two parties. |
| MSME | Micro, Small, and Medium Enterprises. |
| OCR | Optical Character Recognition. The process of converting images of typed, handwritten, or printed text into machine-encoded text. |
| PostgreSQL | An open-source object-relational database system. |
| RBAC | Role-Based Access Control. |
| SRD | Software Requirement Document. |
3. System Overview
3.1 System Architecture
LoanMind AI is designed with a modern, scalable, and service-oriented architecture. The system is decoupled into a frontend client and a backend API, which orchestrates various services.
- Frontend (Flutter): A cross-platform mobile application serves as the primary interface for MSME applicants. It manages the user journey, document uploads, and the interactive voice interview.
- Backend (FastAPI): A Python-based API server that acts as the system's core. It handles business logic, user authentication, data processing, and coordinates with all other services.
- Database (PostgreSQL): The primary relational database for storing structured application data, user information, and system metadata.
- Document Management (Alfresco): A dedicated DMS for storing, versioning, and managing all uploaded documents and generated reports, ensuring a clear audit trail.
- AI Service (Google Gemini): An external LLM API service used for OCR data extraction validation, dynamic question generation, and the core report generation pipeline.
- Asynchronous Task Queue (Celery with RabbitMQ/Redis): Handles long-running, resource-intensive tasks like document OCR, AI-powered analysis, and report generation without blocking the main API, ensuring a responsive user experience.
- Object Storage (AWS S3): Used as a temporary staging area for file uploads before they are processed and ingested into Alfresco.
3.2 System Context Diagram
[MSME Applicant] -- (HTTPS) --> [Flutter Mobile App]
|
v (REST API over HTTPS/JWT)
+-------------------------------------------------------------------------+
| LoanMind AI Backend |
| +---------------------+ +-----------------------------------+ |
| | API Gateway | | FastAPI Core Services | |
| | (Nginx) | <------> | (Application, User, Report Logic) | |
| +---------------------+ +-----------------------------------+ |
| | ^ | |
| +---------------------------+---------+---------+-----------+ |
| | | | | |
| v v v v |
| +-----------------+ +-----------------+ +-----------------+ +--------+
| | Task Queue | | Database | | Document Store | | AI |
| |(Celery/RabbitMQ)| | (PostgreSQL) | | (Alfresco) | | Engine |
| +-----------------+ +-----------------+ +-----------------+ +--------+
| | (Gemini)
+-------------------------------------------------------------------------+
4. System Configurations
4.1 Development Environment
| Component | Technology | Version | Purpose |
|---|
| OS | Linux (Ubuntu) / macOS | 22.04+ / Sonoma+ | Consistent developer operating system. |
| Containerization | Docker Engine | 25.0+ | To containerize services for consistency across environments. |
| Docker Compose | 2.24+ | To orchestrate multi-container local development. |
| Language (BE) | Python | 3.11.x | Backend application language. |
| Framework (BE) | FastAPI | 0.111.0 | High-performance API server. |
| Uvicorn | 0.29.0 | ASGI server for running FastAPI. |
| Language (FE) | Dart | 3.4.x | Frontend application language. |
| Framework (FE) | Flutter | 3.22.x | UI toolkit for the client application. |
| Database | PostgreSQL | 16.x | Primary relational data storage. |
| Task Queue | RabbitMQ | 3.13.x | Message broker for asynchronous tasks. |
| Celery | 5.4.x | Python distributed task queue. |
| DMS | Alfresco Community | 7.4.x | Document and content management. |
| Code Editor | VS Code | Latest | With extensions for Python, Dart, and Docker. |
| VCS | Git | 2.43+ | Version control system. |
4.2 Infrastructure Configuration
| Component | Specification | Notes |
|---|
| Cloud Provider | Amazon Web Services (AWS) | Chosen for its mature ecosystem of managed services. |
| VPC | Custom VPC | Isolated network with public and private subnets across multiple AZs for high availability. |
| Web/App Server | AWS Fargate on ECS | Serverless container orchestration for FastAPI services. Auto-scales based on CPU/Memory usage. |
| Reverse Proxy | AWS Application Load Balancer (ALB) | Manages ingress traffic, SSL termination, and distributes load to Fargate services. |
| Database Server | AWS RDS for PostgreSQL | Multi-AZ deployment for high availability and automated backups. |
| DMS Server | Alfresco on EC2/EKS | Alfresco deployed on EC2 instances or within an EKS cluster for more control over configuration. |
| Task Queue Broker | Amazon MQ for RabbitMQ | Managed message broker service. |
| Object Storage | AWS S3 | For temporary file uploads, static frontend assets, and backups. |
| CDN | AWS CloudFront | Caches and serves the Flutter web app (if built) and static assets globally for low latency. |
4.3 Third-Party Integrations
| Service | Purpose | API Version | Auth Method |
|---|
| Google AI Platform | AI-powered analysis, Q&A generation, and report writing. | Gemini API v1beta | API Key (sent in x-goog-api-key header). |
| Alfresco Content Services | Structured document storage, versioning, and retrieval. | CMIS 1.1 / REST API v1 | Basic Authentication or OAuth 2.0. |
| Twilio Media Streams | Real-time speech-to-text transcription for voice interviews. | v1 | API Key & Secret. |
| SendGrid / AWS SES | Transactional email services for user notifications. | v3 (SendGrid) | API Key. |
4.4 Environment Variables
| Variable | Description | Example Value | Required |
|---|
ENVIRONMENT | Deployment environment (e.g., dev, staging, prod) | staging | Yes |
DATABASE_URL | Connection string for the PostgreSQL database. | postgresql://user:pass@host:port/dbname | Yes |
ALFRESCO_URL | Base URL for the Alfresco repository API. | https://alfresco.loanmind.ai/alfresco/api/-default-/public/cmis/versions/1.1/browser | Yes |
ALFRESCO_USER | Username for Alfresco API authentication. | admin | Yes |
ALFRESCO_PASSWORD | Password for Alfresco API authentication. | [SECRET] | Yes |
JWT_SECRET_KEY | Secret key for signing and verifying JWTs. | [RANDOM_HEX_STRING] | Yes |
JWT_ALGORITHM | Algorithm used for JWT signing. | HS256 | Yes |
GEMINI_API_KEY | API Key for Google Gemini services. | [SECRET] | Yes |
TWILIO_ACCOUNT_SID | Account SID for Twilio services. | ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | Yes |
TWILIO_AUTH_TOKEN | Auth token for Twilio services. | [SECRET] | Yes |
AWS_ACCESS_KEY_ID | AWS access key for S3 and other services. | [SECRET] | Yes |
AWS_SECRET_ACCESS_KEY | AWS secret key. | [SECRET] | Yes |
AWS_S3_UPLOAD_BUCKET | Name of the S3 bucket for temporary uploads. | loanmind-uploads-staging | Yes |
CELERY_BROKER_URL | Connection URL for the RabbitMQ message broker. | amqp://user:pass@host:5672// | Yes |
CELERY_RESULT_BACKEND | URL for storing Celery task results (can use DB or Redis). | db+postgresql://... | Yes |
4.5 Deployment Configuration
| Environment | URL (API / App) | Server Specs | Notes |
|---|
| Development | localhost:8000 / localhost | Local Machine via Docker Compose | For local development and testing by engineers. |
| Staging | api.staging.loanmind.ai / app.staging.loanmind.ai | AWS Fargate: 2 Tasks, 1 vCPU, 2GB RAM each. RDS: db.t3.medium. | Pre-production environment for QA testing and UAT. Mirrors production setup. |
| Production | api.loanmind.ai / app.loanmind.ai | AWS Fargate: Auto-scaling from 4 to 20 Tasks, 2 vCPU, 4GB RAM each. RDS: db.m5.large (Multi-AZ). | Live environment for end-users. Monitored 24/7 with automated alerting. |
5. Functional Requirements
5.1 User & Application Management
| Req ID | Requirement | Priority | Acceptance Criteria |
|---|
| SRD-UAM-001 | User Registration | Must Have | Users can register using a mobile number and OTP verification. A user record is created in the database. |
| SRD-UAM-002 | User Authentication | Must Have | Registered users can log in using their mobile number and OTP. Upon success, a JWT is issued. |
| SRD-UAM-003 | Create New Application | Must Have | Authenticated users can start a new loan application, choosing between "MSME" or "CMA" workflow. An application record is created with a unique application_number and INITIATED status. |
| SRD-UAM-004 | View Application Status | Must Have | Users can view the status of their ongoing and past applications on a dashboard. The status reflects the Flutter State Machine. |
5.2 Document Processing Module
| Req ID | Requirement | Priority | Acceptance Criteria |
|---|
| SRD-DPM-001 | Document Upload | Must Have | Users can upload documents (PDF, JPG, PNG) for a specific application. Files are first uploaded to a temporary S3 bucket. |
| SRD-DPM-002 | Asynchronous Document Processing | Must Have | Upon upload, a background task is triggered to process the document. The API should return an immediate "processing" status to the user. |
| SRD-DPM-003 | AI-Powered Document Classification | Must Have | The system must automatically identify the type of document (Aadhaar, PAN, Bank Statement, etc.) with >95% accuracy. |
| SRD-DPM-004 | AI-Powered Data Extraction (OCR) | Must Have | The system must extract key fields from each document type into a structured JSON object. For a PAN card, this includes PAN, Name, DOB. |
| SRD-DPM-005 | Store in DMS (Alfresco) | Must Have | After successful processing, the original file and its extracted JSON data are moved from S3 to the correct folder in the Alfresco repository, following the defined schema. |
| SRD-DPM-006 | Update Application Status | Must Have | The frontend polls a status endpoint. As documents are successfully processed and verified, the UI updates a checklist to show completion. |
5.3 Interactive Interview & Analysis Module
| Req ID | Requirement | Priority | Acceptance Criteria |
|---|
| SRD-AIM-001 | Dynamic Question Generation | Must Have | After initial documents are processed, the system uses Gemini to analyze the extracted data and business context to generate a set of targeted questions to fill information gaps. |
| SRD-AIM-002 | Voice-based Interview | Should Have | The Flutter app presents the questions and allows the user to respond via voice. The system transcribes the audio to text in real-time. |
| SRD-AIM-003 | Conversation Log Upload | Must Have | The final, transcribed Q&A is compiled into a master-conversation.md file and uploaded to the application's Alfresco folder. |
| SRD-AIM-004 | Trigger Report Generation Pipeline | Must Have | The upload of master-conversation.md automatically triggers the background report generation pipeline. |
| SRD-AIM-005 | Sequential Report Generation | Must Have | The 6 MSME analysis reports are generated sequentially, with the context of each previous report being used in the prompt for the next one. |
| SRD-AIM-006 | Final Report Storage | Must Have | All generated .md reports are stored in the msme_reports subfolder within the application's Alfresco directory. |
| SRD-AIM-007 | Update Status to COMPLETED | Must Have | Once the final report (msme_loan_summary.md) is generated, the application status is updated to COMPLETED. |
5.4 Report Dashboard & Export
| Req ID | Requirement | Priority | Acceptance Criteria |
|---|
| SRD-RDE-001 | View Generated Reports | Must Have | When an application is COMPLETED, the user can view the list of generated reports in the Flutter app. |
| SRD-RDE-002 | Render Markdown Reports | Must Have | The app must correctly render the Markdown content of the reports, including headers, lists, and tables. |
| SRD-RDE-003 | Export to PDF | Should Have | Users should have an option to export all generated reports combined into a single, well-formatted PDF document. |
6. Non-Functional Requirements
| Req ID | Requirement | Metric | Target |
|---|
| NFR-P-001 | API Response Time (p95) | Milliseconds | < 400ms for synchronous endpoints. |
| NFR-P-002 | Document Processing Time | Seconds | < 90 seconds from upload to Alfresco ingestion for a typical 10-page bank statement. |
| NFR-P-003 | Full Report Suite Generation | Minutes | < 5 minutes from master-conversation.md upload to final report generation. |
| NFR-P-004 | Concurrent Users | Number | The system must support 1,000 concurrent active users during peak hours without performance degradation. |
6.2 Security Requirements
| Req ID | Requirement | Standard | Priority |
|---|
| NFR-S-001 | Data Encryption at Rest | AES-256 | Must Have |
| NFR-S-002 | Data Encryption in Transit | TLS 1.3 | Must Have |
| NFR-S-003 | Authentication & Authorization | JWT with short-lived access tokens and long-lived refresh tokens. RBAC for different user types (Applicant, Admin). | Must Have |
| NFR-S-004 | Input Validation | OWASP Standards | Must Have |
| NFR-S-005 | Secret Management | AWS Secrets Manager / HashiCorp Vault | Must Have |
| NFR-S-006 | PII Data Protection | Compliance with India's DPDP Act | Must Have |
6.3 Scalability Requirements
| Req ID | Requirement | Notes |
|---|
| NFR-SC-001 | Horizontal Scaling | The backend application services must be stateless and horizontally scalable. Using AWS Fargate enables this automatically. |
| NFR-SC-002 | Database Scalability | The database will be configured with read replicas to offload read-heavy queries from the primary instance. |
| NFR-SC-003 | Asynchronous Processing | The use of a message queue (RabbitMQ) allows for the scaling of worker nodes independently of the web-facing API servers to handle variable loads of document processing tasks. |
6.4 Reliability & Availability
| Req ID | Requirement | Target |
|---|
| NFR-R-001 | System Uptime SLA | 99.9% |
| NFR-R-002 | Recovery Time Objective (RTO) | < 1 hour |
| NFR-R-003 | Recovery Point Objective (RPO) | < 15 minutes |
| NFR-R-004 | Data Backups | Automated daily backups of the PostgreSQL database and Alfresco content store, with point-in-time recovery enabled. |
7. Data Requirements
7.1 Data Model Overview
The data model is centered around the Application, which links a User to a collection of Documents and Reports.
- User: Represents an applicant or an administrator. Identified by a mobile number.
- Application: The core entity representing a single loan application. It has a status that follows the defined state machine.
- Document: Represents a file uploaded by the user. It stores metadata, its type, its location in Alfresco, and the extracted JSON data.
- Report: Represents a markdown file generated by the AI pipeline. It is linked to an application.
7.2 Database Schema (Key Tables)
| Table | Description | Key Fields |
|---|
users | Stores user account information. | id (PK), mobile_number (UNIQUE), full_name, password_hash, role, created_at |
applications | Tracks each loan application. | id (PK), application_number (UNIQUE), user_id (FK), workflow_type (MSME/CMA), status, created_at, updated_at |
documents | Metadata for each uploaded document. | id (PK), application_id (FK), document_type, original_filename, alfresco_node_ref, status, extracted_data (JSONB), uploaded_at |
conversation_logs | Stores the master Q&A transcript. | id (PK), application_id (FK), alfresco_node_ref, content (TEXT), created_at |
8. API Specifications
8.1 API Overview
All endpoints will be versioned under /api/v1/.
| Endpoint | Method | Description | Auth Required |
|---|
/api/v1/auth/register | POST | Registers a new user via mobile and OTP. | No |
/api/v1/auth/login | POST | Authenticates a user and returns a JWT. | No |
/api/v1/applications | POST | Creates a new loan application. | Yes |
/api/v1/applications/{app_num} | GET | Retrieves the details and status of an application. | Yes |
/api/v1/documents/upload/{app_num} | POST | Uploads a document for an application. | Yes |
/api/v1/documents/status/{app_num} | GET | Gets the processing status of all documents for an application. | Yes |
/api/v1/conversation/upload/{app_num} | POST | Uploads the master-conversation.md file. | Yes |
/api/v1/reports/{app_num} | GET | Lists all generated reports for a completed application. | Yes |
/api/v1/reports/{app_num}/{report_name} | GET | Downloads a specific report file. | Yes |
8.2 API Authentication
The API will be secured using JSON Web Tokens (JWT).
- A user authenticates via the
/login endpoint.
- The server returns a short-lived access token (~15 minutes) and a long-lived refresh token (~30 days).
- The client sends the access token in the
Authorization: Bearer <token> header for all protected requests.
- If the access token is expired, the client uses the refresh token to obtain a new access token without requiring the user to log in again.
9. User Interface Requirements
9.1 UI Design Principles
- Simplicity & Clarity: The interface should be intuitive, with clear instructions and minimal clutter, guiding the user through a complex process.
- Mobile-First: The primary interface is a mobile app. All interactions must be optimized for smaller touchscreens.
- Progressive Disclosure: Show only the information and actions relevant to the user's current step to avoid overwhelming them.
- Accessibility: Adhere to WCAG 2.1 AA standards for colors, contrast, and screen reader compatibility.
9.2 Screen Inventory (Flutter App)
| Screen | Description | Key Components |
|---|
| Splash/Login | Initial screen for authentication. | Mobile number input, OTP field, Login button. |
| Dashboard | Main screen after login, shows a list of applications. | List of applications with their status, "Start New Application" button. |
| Document Upload | Interface for uploading required documents. | Dynamic checklist of required documents, upload buttons for each, progress indicators, status icons (pending, verified, error). |
| Voice Interview | Screen for the interactive Q&A session. | Display of the current question, "Record Answer" button, audio waveform visualizer, transcript preview. |
| Report Viewer | Displays the final generated reports. | List of available reports, Markdown renderer view, "Export to PDF" button. |
9.3 Responsive Design Requirements
The primary client is a Flutter mobile application designed for standard iOS and Android screen sizes. A future web portal for bank officers must be responsive and functional across major desktop browser resolutions (1280px, 1440px, 1920px).
10. Testing Requirements
| Test Type | Scope | Tools | Coverage Target |
|---|
| Unit Testing | Backend: Individual functions, classes. Frontend: Widgets, business logic. | Pytest (BE), Flutter test package (FE) | 85% line coverage |
| Integration Testing | Interaction between API services, database, and Alfresco. | Pytest with test containers, Flutter integration_test | 90% of API endpoints |
| End-to-End (E2E) Testing | Critical user flows from registration to report viewing. | Flutter integration_test, potentially Playwright for a web admin portal. | 100% of critical paths |
| Performance Testing | API load testing, document processing throughput. | Locust, k6 | Meet NFR-P targets |
| Security Testing | Vulnerability scanning, penetration testing. | OWASP ZAP, Snyk, manual penetration tests before major releases. | No critical or high-severity vulnerabilities |
11. Deployment & DevOps
11.1 CI/CD Pipeline
A CI/CD pipeline will be implemented using GitHub Actions.
- On Pull Request to
main:
- Lint code (Flake8 for Python, Dart Analyzer for Flutter).
- Run all unit and integration tests.
- Build Docker image for backend.
- Build Flutter app.
- Report status back to the PR. Merging is blocked on failure.
- On Merge to
main:
- All previous steps are re-run.
- Push Docker image to AWS ECR.
- Deploy the new image to the Staging environment on AWS Fargate.
- Run E2E tests against the Staging environment.
- On Git Tag (e.g.,
v1.1.0):
- A manual approval step is required.
- Upon approval, the validated image from Staging is promoted and deployed to the Production environment.
11.2 Monitoring & Logging
| Tool | Purpose | Configuration |
|---|
| AWS CloudWatch Logs | Centralized logging for all services (FastAPI, Celery workers, Fargate). | All application logs (stdout/stderr) will be streamed directly to CloudWatch. |
| AWS CloudWatch Metrics | Infrastructure and application performance monitoring. | Monitor CPU/Memory usage of Fargate tasks, RDS connections, ALB request counts, and 5XX error rates. |
| AWS CloudWatch Alarms | Automated alerting. | Alarms configured for high error rates (>1%), high CPU utilization (>80%), and application health check failures. Notifications sent to Slack and PagerDuty. |
| Sentry / Datadog APM | Application Performance Monitoring (APM) and error tracking. | Integrated into the FastAPI application to trace requests, identify performance bottlenecks, and capture detailed error reports with stack traces. |
12. Appendix
A. Glossary
See Section 2.3 Definitions & Acronyms.
B. Reference Documents
- LoanMind AI Project Proposal & Vision Document
- UI/UX Design Mockups (Link to Figma)
- Alfresco Content Model Definition
C. Revision History
| Version | Date | Author | Changes |
|---|
| 1.0 | June 09, 2026 | Senior Software Architect | Initial creation of the Software Requirement Document. |
What's Next
➡️ Sample FSD — Loanmind AI — See the screen-by-screen functional specifications built on top of this architecture.