Detailed Project Report for Fiduciary Management System

1. Overview

This section for the PM-SETU Fiduciary Management System defines the business, functional, technical, governance, and implementation requirements for establishing a centralized digital fiduciary management platform across the PM-SETU ecosystem. The system is envisaged as a core governance and oversight mechanism that will enable transparent, accountable, and compliant management of program funds for SPVs operating across states. The platform will provide a unified digital environment for monitoring fund flows, managing budgets and AOPs, administering audit and compliance processes and supporting evidence-based decision-making through integrated dashboards and analytics.

The primary purpose of the Fiduciary Management System is to establish end-to-end visibility across the entire financial lifecycle of PM-SETU, beginning from fund receipt and allocation through utilization, verification, audit, compliance monitoring, and reporting. Given the program's multi-stakeholder implementation structure involving Central Government entities, State Governments, SPVs, AIP, IMA, banking institutions, external auditors, and MDB, the system is intended to create a single source of truth for all fiduciary information. The platform will strengthen financial governance by enabling real- time or near real-time monitoring of fund movements, automated validation against approved financial plans, milestone-linked fund release mechanisms, audit traceability, compliance monitoring, and proactive risk identification through alerts and exception management.

Scope

The PM-SETU Fiduciary Management System will provide a centralized digital platform to manage the complete fiduciary lifecycle of the scheme across Centre, State, and SPV levels. The solution will support financial planning, budget governance, fund flow monitoring, utilization tracking, compliance management, audit administration, procurement oversight, stakeholder reporting, and decision support. It will enable the digital management of SIPs and AOPs, including CAPEX and OPEX budgeting, funding contributions from Centre, State, and AIP, milestone and KPI tracking, and budget utilization monitoring. The platform will also support structured workflows for approvals, reallocations, deviations, and compliance reviews to ensure effective fiduciary governance.

The system will include a Fund Flow Tracker providing end-to-end visibility of Escrow, CAPEX, and OPEX accounts across participating SPVs and banking institutions, with monitoring of inflows, outflows, balances, utilization, contribution compliance, milestone achievements, and tranche release readiness. It will also provide a centralized Audit and Reporting Portal to manage audits, observations, mitigation actions, compliance tracking, fiduciary reporting, and procurement contract records, including vendor validation against MDB debarment databases. Additional capabilities will include configurable alerts, role-based dashboards, analytics, audit trails, reporting services, and integration with banking systems, identity and access management platforms, document repositories, communication gateways, and compliance databases. The platform will support role-based access for Centre authorities, State Governments, SPVs, auditors, Independent Monitoring Agencies, and development partners, ensuring secure and efficient collaboration across stakeholders.

Key Assumptions

• •All participating SPVs, State Governments, auditors, independent monitoring agencies, and AIP will use the PM-SETU Fiduciary Management System as the single platform for fiduciary planning, fund monitoring, utilization reporting, audit management, compliance tracking, and stakeholder reporting.
• •External systems, including escrow and commercial banks, identity management platforms, notification gateways, and MDB compliance repositories, will provide the required APIs, data exchange mechanisms, and service availability to enable seamless integration.
• •The PM-SETU fiduciary framework, including fund release conditions, utilization thresholds, milestone verification, audit requirements, approval workflows, and compliance obligations, will remain stable during implementation. Future policy or regulatory changes will be addressed through configurable business rules and change management processes.
• •Participating institutions will have the necessary digital infrastructure, connectivity, and trained users to support system adoption. Roles, approval authorities, delegation matrices, data ownership, and operational responsibilities will be defined and operationalized prior to deployment.

The table below presents the key stakeholders, and the functional requirements associated with each stakeholder group.

2. Business Requirements

The PM-SETU Fiduciary Management System digitizes and governs the end-to-end fiduciary lifecycle of the programme through four core business processes. The lifecycle commences with budgeting, covering SIP onboarding and AOP management, under which SPVs submit CAPEX and OPEX budgets, funding requirements, milestone plans, and KPIs for structured review and approval. Once budgets are approved, fund flow processes govern the receipt, custody, transfer, and utilization of contributions from the Central Government, State Governments, and AIP across Escrow, CAPEX, and OPEX accounts, with releases linked to milestone verification and utilization thresholds. Expenditure and progress are then subjected to audit and compliance, covering internal audits, external audits, IMA verification, observation tracking, mitigation closure, and validation of procurement contracts against MDB fiduciary and debarment requirements. Finally, analytics for monitoring converts transactional data into alerts, dashboards, and reports that provide actionable insights for governance and decision- making.

Tap to enlarge

These processes are inherently complex to administer. They span multiple stakeholders — Central Government entities, State Governments, SPVs, AIP, the IMA, escrow and commercial banks, internal and external auditors, and multilateral development partners — each with distinct roles, approval authorities, and information needs. They also involve multi-account fund structures, source-wise contribution tracking, threshold-based triggers such as the 75% utilization condition, milestone-linked tranche releases, PRC workflows, and mandatory integrity checks against MDB debarment databases. Managing this lifecycle through manual or fragmented systems would result in delayed fund releases, weak traceability, reconciliation gaps, and elevated compliance risk. A dedicated, centralized Fiduciary Management Module is therefore required to act as the single source of truth — enforcing approved

plans, automating validations and workflows, maintaining complete audit trails, and providing real-time visibility to all stakeholders.

To address these requirements, the Fiduciary Management Module is organized into seven functional components: a Fund Flow Tracker for end-to-end visibility of Escrow, CAPEX, and OPEX accounts; Budget & AOP Management for SIP and AOP planning, approvals, and reallocations; an Audit & Reporting Portal for audit administration and observation closure; Contract Management & MDB Compliance for procurement registration and debarment validation; an Alert Engine for event-driven notifications and escalations; Analytics, Dashboards & Reports for role-based decision support; and an Integration Layer connecting banking systems, identity management, document repositories, communication gateways, and compliance databases. The table below outlines the access rights and functional permissions available to each stakeholder persona across these modules.

Budget planning user journey

Tap to enlarge

• •SPV onboarding: The SPMU creates the SPV profile, configuring State, cluster/hub assignment, AIP, ownership details, and the approved funding contribution structure; the system auto-initializes the SPV workspace and fiduciary records.
• •SIP preparation and submission: The

AIP / SPV submits the Strategic Investment Plan covering Escrow, CAPEX, and OPEX components, annual expenditure projections, budget allocations, stakeholder funding contributions, expected outputs, and supporting documents; the SIP forms the master financial baseline.

• •SIP review and approval: State and

Central authorities review the SIP and may raise observations within the prescribed window; inaction within the timeline results in deemed (automatic) approval. On approval, the system creates the authorized CAPEX/OPEX framework, locks the Centre–State–Industry funding split, and notifies stakeholders.

• •Year-1 AOP preparation: Based on the

approved SIP, the AIP/SPV prepares the Year-1 AOP defining annual CAPEX/OPEX allocations, milestones, performance indicators, and deliverables; following SPV Board approval, it is shared with State and Central authorities and becomes the operational baseline.

• •Utilization monitoring and re-planning: If

utilization stays below the prescribed 75% threshold, a non-compliance alert is issued to the SPMU and authorities, and the SPV must reassess assumptions and re-plan the AOP before further funding progression.

Tap to enlarge

• •Year-2 AOP and tranche eligibility: Once

utilization exceeds 75%, the system computes unutilized Year-1 balances and permitted carryforwards; the Year-2 AOP is reviewed by the SPMU, approved by the SSC, and activated — making the SPV eligible for the next tranche, subject to fiduciary compliance.

Fund flow management journey

• •Budget activation: On AOP approval, the authorized budget envelope is activated

and used by the system to validate all subsequent fiduciary activities against approved CAPEX/OPEX budgets, funding commitments, and performance targets.

Tap to enlarge

• •Contribution receipt and mapping:

Contributions from the Central Government, State Government, and AIP are recorded, validated against the approved funding structure in the SIP/AOP, and mapped to the appropriate Escrow, CAPEX, and OPEX accounts.

• •Fund utilization: The AIP/SPV executes programme activities — infrastructure, procurement, operations, and training — and periodically submits Utilization Certificates, invoices, payment records, and milestone evidence through the platform.
• •Utilization computation: The system

consolidates expenditure data, computes cumulative utilization against the approved budget, and continuously monitors performance against the 75% threshold that triggers tranche processing; below the threshold, execution continues with further utilization submissions.

• •IMA verification: Once utilization exceeds 75%, IMA verification is automatically initiated — validating expenditure claims, utilization evidence, milestone achievement, and KPI attainment — and the IMA report is routed to the SPMU for review.
• •PRC issuance and fund release: Based

on the verification and fiduciary review, the SPMU issues a PRC, authorizing the escrow banking system to transfer the approved tranche from the Escrow Account to the SPV CAPEX Account.

Tap to enlarge

• •Downstream payments and

carryforward: The SPV pays approved vendors, contractors, consultants, and service providers per approved plans; unspent balances are carried forward into future planning cycles under programme rules.

• •Next-tranche validation: A final fiduciary

validation

• —utilization status, KPI achievement, IMA outcomes, audit compliance, and governance requirements
• —generates a tranche eligibility signal and notifies the SPMU and SSC, initiating the next funding cycle.

Audit user journey

• •Assurance framework: Fiduciary assurance rests on three mechanisms —UC and IMA

verification, Internal Audit, and External Audit — providing continuous oversight of financial management and compliance.

• •Evidence submission: The SPV

Tap to enlarge

periodically uploads UCs, expenditure records, payment proofs, invoices, procurement documents, and milestone evidence, forming the basis for utilization validation and compliance assessment.

• •Internal audit: The SPV-appointed

Internal Auditor reviews financial transactions, procurement, utilization records, and procedural compliance, and uploads the Internal Audit Report to the Audit & Compliance Portal.

• •External audit:

In parallel, an External Auditor independently reviews financial statements, programme expenditure, fiduciary controls, and statutory compliance, and uploads the signed External Audit Report.

• •IMA assessment: The IMA performs

desk-based and physical verification of utilization, procurement, audit reports, and milestone evidence, and uploads its verification report; discrepancies are raised as observations and routed to the SPV.

• •Observation resolution: The SPV

responds with clarifications, revised documentation, or additional evidence until all material observations are closed, with full stakeholder visibility of open issues, timelines, and closure status.

• •Compliance closure: On resolution

of all significant observations, compliance status turns "Green" and the IMA issues its final verification report confirming utilization, milestones, KPIs, and compliance.

• •PRC authorization:

The SPMU reviews the final IMA report, audit conclusions, and compliance status; where all requirements are met, it issues the PRC authorizing release of the next tranche through the escrow mechanism.

Analytics and dashboard user journey

• •Role-based access: Users authenticate via the Government Identity and Access Management framework using SSO; the system identifies role, organization, and privileges, and dynamically loads the relevant dashboard while the analytics engine consolidates the latest data across all modules and surfaces key exceptions and risks.
• •Centre-level view: A national dashboard covering fund flows, Central/State/Industry contributions, state-wise CAPEX/OPEX utilization, payment deviations, audit indicators, and comparative State/SPV performance, with drill-down from national summaries to individual States.
• •State-level view: A state-specific dashboard consolidating all SPVs in the jurisdiction — fund receipts, utilization status, contribution compliance, audit observations, milestones, and variances
• —with drill-down to individual SPVs.

Tap to enlarge

Tap to enlarge

• •SPV-level view: An execution-focused dashboard organized around four trackers — Fund Tracker, Audit Tracker, Utilization Tracker, and Deviation Tracker — covering approved budgets, balances, expenditure trends, milestone status, pending compliance actions, and AOP variances.
• •Auditor / IVA view: Compliance-focused dashboards showing pending audits, unresolved observations, verification workloads, compliance exceptions, debarment alerts, overdue responses, and contract review requirements.
• •MDB / World Bank view: A portfolio-level dashboard of programme-wide utilization, state performance trends, audit and compliance indicators, risk alerts, MDB-specific exceptions, and outcome-linked progress — without access to transaction-level operations.
• •Continuous risk monitoring: The analytics engine automatically flags delayed SPVs, unresolved observations, utilization shortfalls, contribution gaps, compliance breaches, and AOP deviations through alerts and risk indicators, enabling timely, data-driven decisions.

The table below summarizes the core functional modules and capabilities of the PM-SETU Fiduciary Management System.

3. Functional system requirements

Pillar 1: Fund flow tracker

The system shall integrate with Escrow Banks and participating commercial banks to retrieve account balances, transaction details, inflows, outflows, and fund transfers for Escrow, CAPEX, and OPEX accounts. The system should maintain source-wise visibility of Central Government, State Government, and AIP contributions and display consolidated balances through role-based dashboards. The platform shall automatically calculate utilization percentages using approved budget allocations and validated expenditure records. The solution shall continuously evaluate tranche readiness against utilization thresholds, milestone achievements, KPI achievement status, audit status, and IMA verification outcomes. Upon fulfillment of all release conditions, the system shall generate tranche eligibility recommendations and facilitate issuance of PRC.

Tap to enlarge

Functional Capabilities

Account Visibility: Explicitly requires real-time escrow and SPV account visibility, including inflow, outflow and balance, with daily basis account balance pulls.

• •View escrow account balance.
• •View SPV CAPEX and OPEX account balance.
• •View total inflow, total outflow and closing balance.
• •Fetch daily account balances from banks or banking dashboards.

Fund Source Tracking: Identifies source-wise inflow and outflow tracking for Centre, State and AIP and requires red flag alerts for missing State or Industry share.

• •Track Central Government, State Government and AIP contribution.
• •Identify missing contribution and generate alerts where contribution is overdue.

Tranche Release Monitoring: Support next tranche unlock when 75% utilization is achieved along with KPI/Milestone achievement and IMA report submission.

• •Track initial capital induction.
• •Track first tranche release.
• •Track second tranche release.
• •Track milestone-based release eligibility.
• •Track fund release conditions.

Utilization Trigger: Specifies a 75% trigger for unlocking the next tranche, subject to KPI achievement and IMA report.

• •Auto-calculate utilization percentage.
• •Check whether utilization has crossed 75%.
• •Validate KPI achievement.
• •Validate audit status.
• •Validate IMA verification.
• •Generate tranche eligibility signal.

Acceptance Criteria

• •System displays account balances at Escrow, CAPEX, and OPEX levels.
• •Daily account balances are refreshed automatically from integrated banking systems.
• •Utilization percentage is automatically calculated for each SPV.
• •Tranche eligibility is generated only after all mandatory conditions are satisfied.
• •Fund flow dashboards display source-wise contribution tracking.

Validation Rules

• •Utilization shall be calculated only using approved expenditure records.
• •Contribution sources must be tagged as Centre, State, or Industry.
• •Fund release eligibility shall require utilization ≥ 75%.
• •KPI validation status must be marked completely before tranche eligibility generation.
• •IMA verification must be available before PRC generation.

Exception Management

Pillar 2: Budget & AOP management

The system shall enable digital creation, review, approval, and management of SIPs and AOPs. The platform shall capture approved CAPEX and OPEX budgets, contribution splits, milestones, KPIs, and implementation schedules. The solution shall maintain version control and preserve all approved plan revisions. The module shall support budget reallocations within approved limits and route significant deviations through approval workflows. Annual planning cycles shall be linked with utilization outcomes and future tranche eligibility conditions.

Tap to enlarge

SIP Onboarding: The framework states that SPVs submit the initial SIP budget during onboarding and CAPEX/OPEX envelopes are captured separately.

• •Capture initial SIP budget.
• •Capture CAPEX and OPEX envelope.
• •Capture funding split by Centre, State and Industry.
• •Attach approved SIP document.

AOP Capture: The framework identifies AOP capture as a system function that sets baseline CAPEX/OPEX limits for the financial year.

• •Capture annual operation plan.
• •Capture yearly CAPEX limits.
• •Capture yearly OPEX limits.
• •Capture planned milestones.
• •Capture planned outputs and KPIs.
• •Set annual financial baseline.

Reallocation Workflow: The framework states that SPV board reallocations within approved envelope should trigger notification to SSC/NSC within 14 days, whereas AOP deviation beyond approved cap should initiate approval workflow and system lock until NSC sign-off. SPV initiates reallocation request.

• •System checks whether reallocation is within approved envelope.
• •If within cap, system notifies SSC/NSC.

Budget Deviation Controls: Budget deviation risk is identified as a core issue, especially because SPV boards may reallocate between CAPEX and OPEX, and deviations may otherwise go unnoticed until reviews.

• •Compare actual expenditure with approved AOP.
• •Flag CAPEX/OPEX deviation.
• •Track budget line-item utilization.
• •Prevent unauthorized budget changes.
• •Maintain version history of SIP and AOP.

Acceptance Criteria

• •SIP submission can be completed digitally with document upload.
• •Approved budget envelopes are automatically created after SIP approval.
• •AOP approval workflows are completed digitally.
• •Budget variance reports are generated automatically.
• •All budget revisions maintain historical versions.

Validation Rules

• •Approved SIP is mandatory before AOP creation.
• •CAPEX and OPEX values must be greater than zero.
• •Funding split must equal total approved budget.
• •Reallocation outside approved limits requires approval workflow.
• •Annual budgets cannot exceed approved SIP envelope.

Exception Management

Pillar 3: Audit & reporting portal

The module shall support Internal Audit, External Audit, and IMA Verification workflows. The system allow upload and review of audit reports, classification of observations, mitigation planning, compliance tracking, and closure management. The system shall support status monitoring for audit findings and integrate audit outcomes with tranche release decisions.

Tap to enlarge

External Audit Capture: The framework specifically requires SPV upload of annual audit report, opinion selection, audit observation entry, mitigation logging and unresolved issue flagging.

• •Annual external audit report upload.
• •Auditor opinion
• •Major audit observation entry.
• •Mitigation measure entry.
• •Timeline capture.
• •Follow-up status tracking.

Internal Audit Capture: The framework requires SPV to upload semi-annual internal audit report, observation entry and system classification of major versus minor observations.

• •Semi-annual internal audit report upload.
• •Compliance and integrity report submission.
• •Key observation entry.
• •Major/minor classification.
• •Follow-up tracking.

IMA View: IMA will receive a separate login on the platform. Central dashboard should provide state- wise audit status, opinion type, unresolved major observations and reduce the need for manual PDF reading.

• •State-wise audit status.
• •Opinion type.
• •Unresolved major observations.
• •SPV-wise audit compliance.
• •Overdue mitigation actions.
• •Fund hold cases.

Acceptance Criteria

• •Internal audit reports can be uploaded and reviewed.
• •External audit reports support opinion classification.
• •IMA reports can be submitted and tracked.
• •Observation tracking and closure monitoring are available.
• •Audit dashboards display pending and resolved observations.

Validation Rules

• •Audit reports must be digitally signed before submission.
• •Every observation must have severity classification.
• •Major observations require mitigation plans.
• •Closure requests must include supporting evidence.
• •Adverse audits automatically triggers escalation.

Exception Management

Pillar 4: Contract management & MDB compliance

The system shall enable SPVs to register procurement contracts and maintain contract records throughout their lifecycle. The platform shall validate vendors against MDB debarment lists and maintain logs of all validation activities. The system shall provide auditors with visibility of contracts and compliance exceptions while maintaining access restrictions for other stakeholders.

Tap to enlarge

Contract Logging by SPV: The framework proposes a contract management module for SPVs where SPVs log all contracts for internal records.

• •Capture contract details.
• •Capture contractor/vendor details.
• •Capture contract amount.
• •Capture procurement category.
• •Capture contract date.
• •Capture supporting documents.
• •Capture funding source and budget reference.

MDB Debarment Check: The framework proposes a real-time pop-up warning if an SPV attempts to enter a known debarred entity while logging a contract.

• •Match vendor name against MDB debarment list.
• •Show real-time warning if debarred entity is detected.
• •Require SPV acknowledgement or block submission based on policy.
• •Maintain debarment check logs.
• •Notify internal/external auditor.

Access Control Principle: The framework emphasizes zero direct visibility of contracts to Centre, with exclusive auditor access and on-demand access for Centre.

• •SPV can log and manage own contracts.
• •Centre has no routine direct visibility into contracts.
• •Centre may access on demand.

Acceptance Criteria

• •Contract records can be created and updated.
• •Debarment validation is performed automatically.
• •Contract documents are stored securely.
• •Compliance alerts are generated for debarred entities.
• •Complete audit trail is maintained.

Validation Rules

• •Vendor name is mandatory.
• •Contract value must be positive.
• •Budget reference must be mapped to approved allocation.
• •Debarment check shall be executed during contract submission.
• •Mandatory contract documents must be attached.

Exception Management

Pillar 5: Alert engine

The alert engine shall continuously monitor fiduciary events, SLA breaches, funding exceptions, compliance issues, utilization milestones, audit risks, and approval delays. Alerts shall be configurable, role-based, and capable of supporting escalation workflows.

Major Alert Types

Acceptance Criteria

The system will generate alerts within five minutes of identifying a trigger event. Users shall receive dashboard alerts, email notifications, and SMS notifications based on configured severity levels. Escalation rules shall automatically execute upon SLA breaches.

Validation Rules

Alert generation shall only occur against approved business rules. Duplicate alerts for the same unresolved issue shall be consolidated.

Exception Management

Failure of email or SMS delivery shall trigger retry attempts and escalation logging. Communication failures should not prevent alert visibility within dashboards.

Pillar 6: Analytics, dashboards & reports

The Analytics component shall provide stakeholder-specific views for financial monitoring, compliance tracking, risk management and decision support. The framework includes dashboards and analytics as part of the PM-SETU platform layer.

Tap to enlarge

Acceptance Criteria

• •Users access dashboards based on assigned roles.
• •Dashboards refresh automatically.
• •Drill-down navigation is available.
• •Reports can be exported in PDF and Excel formats.
• •Dashboard KPIs reconciles with source transaction data.

Validation Rules

• •Users shall view only authorized data.
• •KPI calculations must follow approved formulas.
• •Dashboard data must originate from validated source systems.
• •Historical reports cannot be modified.

Exception Management

Pillar 7: Integration

The Fiduciary Management Module will operate as a central platform within the PM-SETU ecosystem and will require integration with multiple internal and external systems to support fund flow monitoring, compliance management, stakeholder workflows, and programme reporting.

These integrations will enable seamless exchange of financial, operational, audit, and compliance- related data, reduce manual intervention, improve data accuracy, and facilitate real-time decision- making across national, state, and implementation levels. The integration architecture will support secure, API-driven data exchange with banking systems, government platforms, compliance databases, and enterprise support services.

4. Solution architecture

The PM-SETU Fiduciary Management System shall act as a unified digital fiduciary platform to manage fund visibility. The system architecture should enable real-time or near real-time visibility of escrow, CAPEX and OPEX accounts, track SIP/AOP adherence, monitor fund utilization, trigger tranche release readiness, and provide role-based dashboards. The architecture is organized into three layers:

• 1.Data Layer
• 2.Platform Layer — PM-SETU LOMS / Fiduciary Platform
• 3.User Access Layer

Tap to enlarge

Data layer

The Data Layer shall serve as the foundation of the fiduciary platform. It will collect, store, validate, reconcile and standardize data from multiple internal and external sources. This layer is critical because PM-SETU involves multiple SPVs operating across States with separate escrow, CAPEX and OPEX accounts.

Platform layer

The Platform Layer is the core application layer where business rules, workflows, validations, dashboards, alerts, approvals and fiduciary controls will operate. The fiduciary framework identifies PM- SETU LOMS as the platform layer comprising Fund Flow Tracker, Budget & AOP Module, Audit Portal, Contract Management Module, and Analytics.

User access layer

The User Access Layer shall provide secure, role-based access to different stakeholders through tailored portals and dashboards. The framework defines user access for SPV Portal, Auditor, State and Centre. This layer must balance transparency with SPV autonomy. The framework’s design principle is maximum transparency at summary level and zero intrusion into SPV operational autonomy, with compliance enforced through auditors rather than central micromanagement.

5. Non-Functional requirements

The PM-SETU Fiduciary Management System will serve as the central digital platform for managing financial planning, fund flows, audit governance, compliance monitoring, and stakeholder reporting across multiple States, SPVs, banks, auditors, and programme management entities. Given its fiduciary significance, the platform must satisfy stringent non-functional requirements relating to performance, availability, security, resilience, auditability, and regulatory compliance.

Performance requirements

The platform shall provide responsive and reliable user experience across all stakeholder groups including Centre, State Governments, SPVs, auditors, Independent Monitoring Agencies, and MDB representatives. The system shall support concurrent access from all participating entities without degradation in performance. Dashboard pages, fund tracking screens, audit records, and workflow transactions shall load within mentioned (Table 9) response times under normal operating conditions.

The system shall support near real-time visibility of escrow, CAPEX, and OPEX account information received through banking integrations. Transaction data, fund balances, alert notifications, audit updates, and dashboard indicators shall be synchronized within predefined integration windows to ensure decision-making is based on current and reliable information. The solution shall be scalable to support expansion in the number of SPVs, users, transactions, reports, and integrations without requiring architectural redesign.

The analytics and reporting engine shall support generation of state-level, national-level, and SPV-level dashboards without impacting operational transaction processing. The system shall support scheduled and on-demand report generation and maintain performance consistency during peak periods such as fund release cycles, annual planning exercises, audit submission periods, and compliance review windows. The table below contains the ideal response times of the platform.

Security requirements

The platform shall implement a comprehensive security framework to protect financial, operational, audit, and compliance data. User authentication shall be integrated with Government Identity and Access Management or approved Single Sign-On mechanisms to provide centralized and secure user access management.

RBAC shall be enforced across all application modules to ensure users can access only information and functionality relevant to their designated responsibilities. The system shall maintain strict segregation of duties between SPVs, auditors, State Governments, Centre-level authorities, MDB stakeholders, and monitoring agencies. Sensitive information, including contract records, audit findings,

financial data, and user credentials, shall be protected through encryption at rest and encryption in transit.

The platform shall maintain complete traceability of all user activities, approval decisions, data modifications, and administrative actions. Session controls, password policies, account lockout mechanisms, API security controls, and secure document storage practices shall be implemented to prevent unauthorized access, data leakage, or fraudulent activities. The system shall also support periodic security assessments, vulnerability management, and access review exercises. The table below describes the security standard and framework required for the fiduciary management module.

Disaster recovery requirements

The PM-SETU Fiduciary Management System shall be designed for high availability and business continuity. A disaster recovery environment shall be maintained at a geographically separate location to ensure continuity of critical fiduciary operations in the event of infrastructure failure, cyber incidents, natural disasters, or other disruptive events.

The DR environment shall maintain synchronized copies of application data, configuration information, master data, documents, audit records, and transaction history. Recovery procedures shall be documented, periodically tested, and governed through defined operational protocols. Critical fiduciary functions including fund monitoring, audit management, workflow approvals, and reporting shall be restored within agreed recovery time objectives. The platform shall support failover procedures and controlled restoration processes to minimize operational disruption and prevent loss of fiduciary information.

Backup and data retention requirements

The platform shall implement automated backup mechanisms covering application databases, uploaded documents, audit reports, contracts, utilization certificates, master data, configuration settings, and system logs. Backups shall be performed at scheduled intervals and stored securely in accordance with government data protection guidelines.

The solution shall maintain multiple backup copies to support operational recovery, disaster recovery, and regulatory compliance requirements. Backup files shall be encrypted and protected against unauthorized access or alteration. Periodic backup restoration testing shall be conducted to validate recoverability and data integrity.

The system shall preserve historical financial, audit, utilization, compliance, and workflow information for the duration prescribed under applicable government record retention policies and programme governance requirements. Archived data shall remain searchable and auditable throughout the retention period.

Audit logging and monitoring requirements

Given the fiduciary nature of the programme, comprehensive audit logging shall be a mandatory platform capability. The system shall capture all user authentication events, record creation activities, data modifications, approvals, workflow transitions, report generation requests, integration transactions, exception handling actions, and administrative changes.

All logs shall include user identification, timestamp, action performed, affected entity, previous value, updated value, and source of transaction where applicable. Audit logs shall be tamper-resistant and accessible only to authorized administrators and auditors. The platform shall support centralized log monitoring, exception detection, activity tracing, and forensic investigation capabilities. Log retention periods shall align with programme audit requirements and statutory governance obligations.

Compliance requirements

The platform shall adhere to the fiduciary governance principles and operational controls defined under the PM-SETU programme. The solution shall support compliance with Government of India digital governance standards, approved cybersecurity guidelines, data protection requirements, and applicable procurement and financial management policies.

The system shall also support MDB fiduciary requirements, including contract compliance monitoring, debarred entity validation, audit traceability, utilization verification, and transparency of fund utilization.

The platform shall maintain immutable audit trails for all governance decisions and fiduciary transactions to support internal audits, external audits, and independent verification activities.

All workflows related to fund releases, utilization monitoring, audit reviews, contract management, and compliance assessments shall be digitally recorded and retained to ensure accountability, transparency, and regulatory adherence across the PM-SETU ecosystem. The solution shall provide evidence-based reporting capabilities to support governance reviews by Centre, State Governments, auditors, Independent Monitoring Agencies, and MDB stakeholders.

6. Testing strategy and deployment approach

The PM-SETU Fiduciary Management System shall adopt a structured testing and deployment framework to ensure that all fiduciary, financial, audit, compliance, reporting, and integration-related functionalities operate as intended prior to production rollout. Given the system's role in managing programme funds, tranche releases, compliance monitoring, and audit governance, the testing approach shall focus on functional correctness, data accuracy, security, scalability, and business process validation.

Testing strategy

The testing lifecycle shall include Unit Testing, SIT, UAT, Performance Testing, Security Testing, and Production Validation Testing.

System Integration Testing shall verify end-to-end business workflows including SIP and AOP approvals, fund flow tracking, utilization monitoring, audit management, contract compliance checks, alert generation, dashboard reporting, and integrations with banks, DMS, SSO, email and SMS gateways. All interfaces shall be validated for data accuracy, reconciliation, and error handling before progressing to UAT.

User Acceptance Testing shall be conducted with nominated representatives from SPMU, State Governments, SPVs, auditors, IMAs, and programme administrators. UAT shall validate actual business scenarios such as budget creation, fund release workflows, utilization tracking, audit submissions, PRC issuance, contract registration, compliance monitoring, and management reporting. Successful completion of UAT shall constitute formal business sign-off for production deployment.

Performance Testing shall validate the platform's ability to support concurrent users, large transaction volumes, dashboard refreshes, report generation, document uploads, and real-time integration loads without degradation of service. Stress and load testing shall be performed to validate scalability during peak operational periods such as annual planning cycles, audit submission periods, and tranche release exercises.

Security Testing shall include VAPT, authentication and authorization testing, API security validation, role-based access verification, data encryption testing, session management validation, and audit trail verification. All critical and high-risk vulnerabilities identified during testing shall be resolved prior to go- live approval.

Acceptance criteria

Production deployment approval shall be granted only after successful completion of all planned testing activities. The solution shall achieve 100% execution of critical business process test cases covering fund flow, budget management, audit management, compliance tracking, contract management, alerts, dashboards, and integrations. All critical and high-severity defects shall be resolved and retested prior to production rollout.

The platform shall demonstrate successful integration with all identified external systems, including participating banks, escrow banks, DMS, SSO, notification gateways, and MDB compliance databases. UAT sign-off shall be obtained from designated business stakeholders, and all application security findings categorized as critical or high risk shall be closed before deployment approval.

CI/CD and deployment approach

The solution should adopt a CI/CD approach to support controlled, repeatable, and auditable software releases. Source code repositories, automated build pipelines, quality checks, automated testing scripts, and deployment workflows shall be integrated into a centralized DevSecOps framework.

The deployment lifecycle shall follow a phased environment promotion model comprising Development, Testing, UAT, Pre-Production, and Production environments. All releases shall pass through automated code validation, build verification, security scanning, and testing gates before promotion to the subsequent environment.

Production deployment shall be executed through controlled release windows with rollback procedures defined for critical failures. Post-deployment validation shall be conducted to verify application availability, health integration, user access controls, dashboard functionality, and transaction processing. This approach will ensure minimal deployment risk, faster release cycles, improved software quality, and complete traceability of changes throughout the lifecycle of the PM-SETU Fiduciary Management System.

7. Process designs and mockups

Fund flow process design and mockups

This process diagram illustrates the end-to-end funding and utilization lifecycle for OPEX and CAPEX contributions managed through an escrow mechanism and subsequently released to an SPV. The process begins when the funding cycle is initiated and stakeholders deposit OPEX and CAPEX contributions. While OPEX funds are transferred directly to the SPV account, CAPEX funds are first received and held in an escrow account. The escrow manager continuously tracks fund release conditions and milestone verifications. If the predefined conditions are not met, the CAPEX funds remain in escrow; otherwise, the approved amount is released to the SPV CAPEX account. The SPV then utilizes both OPEX and CAPEX funds for approved purposes such as vendors, salaries, and operational expenses. Following fund utilization, a Utilization Certificate (UC) is generated and reviewed against a utilization threshold (75%). If the utilization level is below the threshold, fund utilization continues to be monitored. Once the threshold is achieved, KPI achievements, audit status, M&A validations, and other required verifications are conducted. If all validations are successfully completed, a tranche eligibility signal is generated, enabling the submission of the next tranche release request and initiating the subsequent funding cycle. This process ensures controlled fund disbursement, compliance with governance requirements, and accountability through continuous monitoring and validation.

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge

Budget and AOP process design and mockups

This process diagram outlines the budget reallocation approval process within the SPV funding framework. The process begins when the SPV owner submits a CAPEX/OPEX funding request along with supporting business and financial documents and an annual operating plan containing CAPEX/OPEX limits, milestones, and KPIs. Based on these inputs, an annual financial baseline is established, and actual expenditure is periodically compared against the approved annual operating plan. If a budget deviation is identified, a reallocation request is raised and submitted to the SPV Board for review. The request is then assessed to determine whether the proposed reallocation falls within

approved thresholds. If it does, the relevant governance body is notified within the prescribed timeline, the reallocation is logged and the budget history updated, after which the system releases the approval and updates the annual operating plan. If the reallocation exceeds the permitted threshold, an approval workflow is initiated, followed by a detailed review of the deviation request. Depending on the outcome of the review, the request is either approved and incorporated into the updated operating plan or rejected and returned for revision. This process ensures that budget reallocations are controlled, transparent, compliant with governance requirements, and properly documented before financial plans are updated.

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge

Audit process design

Tap to enlarge

This process illustrates two interconnected governance processes that ensure CAPEX funds are released only after milestone achievement verification and ongoing audit compliance checks. In the Milestone-Based CAPEX Release Mechanism, the process starts when the milestone period ends and the SPV submits evidence of KPI and milestone achievement. An IMA verifies fund utilization and KPI attainment and submits a verification report to the SPMU within the prescribed timeline. The SPMU reviews the findings to determine the eligible release amount. If the findings are satisfactory, the SPMU issues a PRC to the Escrow Bank, which then releases the approved CAPEX funds from the escrow account to the SPV CAPEX account. The SPV subsequently uses the released funds to make payments to vendors, contractors, and staff, completing the fund release cycle. If the verification findings are not satisfactory, the report is returned for clarification and rework before re-verification is conducted, ensuring accountability and compliance before any disbursement occurs.

Tap to enlarge

In parallel, the Annual Audit and Compliance Monitoring Process provides continuous oversight of fund utilization and governance compliance. At the end of each audit cycle, the SPV uploads internal or external audit reports and classifies the audit opinion as unmodified, modified, disclaimed, or adverse. Audit observations and mitigation measures are recorded and categorized based on severity. If an adverse opinion or significant compliance concern is identified, a fund release hold is triggered, and relevant State or Centre authorities are notified. Audit reports, observations, and compliance status are then reviewed, while mitigation actions are tracked through follow-up activities. If major observations remain unresolved beyond prescribed timelines, red-hold alerts are raised and communicated to stakeholders. Audit status, trail records, and compliance dashboards are continuously updated,

enabling transparent monitoring of unresolved issues, audit opinions, and fund release eligibility. Together, these processes establish a strong control framework that links fund disbursement to verified performance outcomes, audit compliance, and effective risk management.

Tap to enlarge

Tap to enlarge

Contract management process design

This process flow depicts the Contract Logging and MDB Debarment Compliance Process,

designed to ensure that contracts awarded by the SPV comply with MDB debarment requirements before registration and execution. The process begins when the SPV initiates contract logging and captures the contractor or vendor details. These details are automatically screened against the MDB debarment list to identify whether the proposed vendor has been sanctioned or restricted. If no match is found, the contract record is registered and proceeds through the normal compliance workflow. However, if a potential debarment match is identified, the system generates a real-time warning and evaluates whether the applicable policy requires the contract submission to be blocked. Where blocking is mandated, the contract submission is prevented, the event is recorded in debarment check logs, and the SPMU is notified for further review. If policy permits continuation despite the alert, the contract can still be registered while maintaining an audit trail of the screening outcome. The SPMU reviews contract information and compliance details, while authorized Centre/MDB authorities can access contract data on demand for oversight purposes. Upon successful completion of all compliance checks and reviews, the contract is registered as compliant, ensuring transparency, regulatory adherence, and effective risk management through systematic vendor screening and monitoring.

Tap to enlarge

Tap to enlarge

Tap to enlarge

Tap to enlarge