Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
The deployment architecture decision for reconciliation software — SaaS, on-premise, or private cloud — is often treated as a pure IT preference: the CTO’s existing policy, the CFO’s appetite for capital expenditure, or a legacy default inherited from the previous generation of enterprise software procurement. For Indian enterprises, the decision is more constrained than that. Regulatory requirements, data residency obligations, and the compliance implications of the DPDP Act 2023 make certain deployment models more or less appropriate depending on the type of entity.
Getting this decision right before vendor selection avoids a costly architectural reversal six months into deployment.
What Each Deployment Model Involves
SaaS (Software as a Service) delivers the reconciliation application over the internet from vendor-managed infrastructure. Data is stored and processed in the vendor’s cloud environment. The enterprise pays a subscription fee and has no infrastructure management responsibility. Updates are applied by the vendor. Security certifications are the vendor’s responsibility.
On-premise delivers the application installed on servers owned and operated by the enterprise. Data never leaves the enterprise’s physical infrastructure. The enterprise IT team manages server maintenance, security patching, database administration, backups, and disaster recovery. The vendor provides the software and support; infrastructure is entirely the enterprise’s responsibility.
Private cloud (dedicated virtual private cloud, or VPC) delivers the application on cloud infrastructure dedicated to a single enterprise tenant. The vendor manages the infrastructure, but no other customer’s data resides on the same servers. For AWS-hosted private cloud, this means a dedicated VPC within a specified AWS region. Data residency is controlled and auditable. Infrastructure management is the vendor’s responsibility, but isolation is stronger than shared SaaS.
Why Indian Regulatory Requirements Shape the Decision
RBI Data Localisation
The Reserve Bank of India’s 2018 circular on storage of payment system data requires that all data relating to payment systems operated in India be stored in systems located only in India. This applies to payment aggregators, payment system operators, and entities holding nodal accounts for payment processing.
For these entities, the deployment question is not SaaS versus on-premise — it is whether the SaaS vendor’s infrastructure is physically located in India. AWS Mumbai (ap-south-1) is an Indian data centre region. A SaaS vendor that stores and processes all customer data exclusively in ap-south-1, with no data transfer to non-India regions, satisfies the localisation requirement. A vendor whose SaaS infrastructure runs in Singapore or Ireland, with India as a secondary region, does not.
Verifying region configuration is straightforward: request the vendor’s AWS region documentation and confirm that no data processing step — including backup replication or log aggregation — routes data outside ap-south-1.
SEBI Cloud Framework for Market Intermediaries
SEBI’s cloud adoption framework for stock brokers, depositories, and other market intermediaries requires that critical systems comply with specific controls including data localisation, periodic risk assessments, and vendor due diligence. The framework does not prohibit cloud deployment — it regulates it. Market intermediaries can use SaaS or private cloud, provided the vendor can demonstrate compliance with SEBI’s prescribed controls.
For a stock broker evaluating SaaS reconciliation software, the vendor’s ISO 27001:2022 certificate and AWS Mumbai residency documentation are the baseline evidence package for SEBI compliance purposes. Additional documentation — penetration testing reports, business continuity plans, incident response procedures — should be requested as part of the evaluation.
DPDP Act 2023
The Digital Personal Data Protection Act 2023 imposes obligations on data fiduciaries processing personal digital data of Indian residents. Financial transaction records containing PAN numbers, Aadhaar-linked bank accounts, or individually identifiable transaction data fall within scope. The Act requires that data fiduciaries implement reasonable security safeguards appropriate to the nature of the data processed.
For SaaS deployments, the vendor’s ISO 27001:2022 certification provides evidence of reasonable security safeguards. The data processing agreement between the enterprise and the SaaS vendor should include DPDP compliance clauses. For on-premise deployments, the enterprise itself must implement and evidence these safeguards — typically through its own ISO 27001 certification or an equivalent internal audit.
SaaS vs On-Premise vs Private Cloud: Deployment Comparison
| Factor | SaaS (Shared, AWS Mumbai) | On-Premise | Private Cloud (Dedicated VPC, AWS Mumbai) |
|---|---|---|---|
| Deployment time | 2 to 4 weeks | 8 to 16 weeks (includes infrastructure provisioning) | 4 to 6 weeks (infrastructure provisioning + application setup) |
| Data residency | AWS Mumbai (ap-south-1) — India resident | On-site, fully enterprise-controlled | AWS Mumbai (ap-south-1) — India resident, dedicated tenant |
| Infrastructure cost | No capital expenditure; subscription only | High: servers, licensing, DR infrastructure | Moderate: no hardware but dedicated cloud cost premium |
| Security certification | Vendor’s ISO 27001:2022 covers the platform | Enterprise must certify its own infrastructure | Vendor’s ISO 27001:2022 covers dedicated infrastructure |
| Update cycle | Continuous; vendor-managed | Manual; requires IT engagement and regression testing | Vendor-managed; applied to dedicated environment |
| Regulatory compliance | Satisfies RBI localisation, SEBI framework, DPDP Act for most entities | Required for banks, PSUs with sovereignty mandates | Appropriate for regulated entities needing isolation without on-premise overhead |
| Who it suits | Mid-market enterprises, NBFCs, e-commerce, IT services, healthcare | Scheduled banks, insurance companies, government PSUs | Payment aggregators, large NBFCs, entities with audit isolation requirements |
How to Decide: A Step-by-Step Process
Step 1: Check Whether Your Regulator Mandates On-Premise
Before any other consideration, determine whether your primary regulator has a directive that requires data to be stored on infrastructure you own and operate. This applies to a narrow set of entities: scheduled banks under RBI’s IT and Cyber Security Framework, insurance companies under IRDAI guidelines with explicit on-premise mandates, and government PSUs under specific ministries with data sovereignty policies.
If no such mandate exists, on-premise is a choice — not a requirement. Most Indian enterprises that default to on-premise do so based on legacy IT policy or general caution, not a specific regulatory directive.
Step 2: Verify the Data Residency Requirement
If your regulator requires data to remain in India, confirm that the SaaS vendor’s infrastructure is India-resident. Request the vendor’s AWS region configuration documentation and verify that ap-south-1 is the only region used for data storage and processing. Ask specifically whether backup replication, log storage, and monitoring data are also confined to India.
If the SaaS vendor cannot provide this documentation, or if any processing step routes data outside India, private cloud (dedicated VPC, AWS Mumbai) or on-premise is the appropriate architecture.
Step 3: Assess Internal IT Capacity for Infrastructure Management
On-premise deployment is not free infrastructure. It requires: a server environment with sufficient compute and storage for reconciliation workloads (which spike at month-end close and quarterly filing deadlines), a DBA for the database layer, an IT team capable of applying security patches within required windows, and a disaster recovery setup that meets your RTO and RPO requirements.
For most mid-market Indian enterprises, this IT capacity does not exist or is already overcommitted to ERP maintenance. In this situation, on-premise reconciliation software creates an IT dependency that outlasts the initial deployment and grows as transaction volumes increase.
Step 4: Calculate the Total Cost of Ownership Over 3 Years
The typical TCO comparison over a 3-year period:
- On-premise: Server hardware (₹15 to 30 lakh for an enterprise-grade setup), annual hardware maintenance (15% of hardware cost per year), IT staff time for patching, updates, and monitoring (estimated at 10 to 20% of one FTE), DR infrastructure, and software licensing.
- SaaS: Annual subscription fee (no capital expenditure), zero infrastructure management cost, zero DR infrastructure cost. All updates included.
- Private cloud: No hardware cost, but a premium on the subscription fee for dedicated infrastructure. IT management cost is near-zero because the vendor manages the environment.
For organisations processing under 5 million transactions per month, on-premise TCO over 3 years is typically 2 to 4 times higher than SaaS TCO, because hardware and IT staff costs do not scale with usage. The crossover point where on-premise becomes cost-competitive requires very high transaction volumes and an existing IT infrastructure investment that can be fully allocated to the reconciliation workload.
Step 5: Ask the Vendor for Their Compliance Posture Documentation
Before finalising the deployment architecture, request the following from any shortlisted vendor:
- ISO 27001:2022 certificate with scope statement confirming the reconciliation platform is covered
- AWS region configuration documentation confirming ap-south-1 as the primary and only data region
- Data processing agreement (DPA) with DPDP Act 2023 compliance clauses
- For private cloud: dedicated VPC architecture diagram and tenant isolation documentation
- Business continuity plan with RTO and RPO commitments
A vendor who produces all of these quickly, with current versions and specific scope statements, demonstrates that compliance posture is operationally maintained rather than assembled for sales purposes.
What This Means in Practice for Indian Enterprise Segments
For mid-market manufacturers and IT services firms with SAP or Oracle and between 500,000 and 5 million transactions per month, SaaS on AWS Mumbai is the default-correct architecture. No regulatory mandate requires on-premise. The deployment is faster, the infrastructure is managed, and the vendor’s ISO 27001:2022 certification covers the compliance requirement.
For NBFCs and payment aggregators processing NACH batches and payment gateway settlements, the RBI data localisation requirement is the key filter. SaaS on AWS Mumbai satisfies it, provided the vendor’s infrastructure is fully India-resident. Private cloud is appropriate for large NBFCs that have audit isolation requirements or that process personal financial data at a scale that warrants a dedicated environment.
For healthcare providers and TPAs, SaaS on AWS Mumbai is appropriate. TPA settlement data and patient claim records are sensitive, but no specific IRDAI or MoHFW directive mandates on-premise storage for private hospitals or TPAs. ISO 27001:2022 coverage and India residency are the required evidence.
For scheduled banks and large insurance companies, the decision is driven by the regulator’s framework, not by general TCO analysis. RBI’s IT and Cyber Security Framework for banks and IRDAI’s guidelines for insurers specify controls that may require on-premise or at minimum dedicated private cloud deployment with specific audit rights.
Reconciliation software for Indian businesses is available in both SaaS (shared, AWS Mumbai) and private cloud (dedicated VPC, AWS Mumbai) configurations. Both carry ISO 27001:2022 certification. The deployment timeline for SaaS is 2 to 4 weeks; private cloud adds approximately 1 to 2 weeks for dedicated environment provisioning.
Automated TDS reconciliation runs on both deployment models. Form 26AS data, TDS receivable ledger entries, and the reconciliation output all remain within the configured AWS Mumbai region regardless of whether the deployment is shared SaaS or private cloud.
The Institute of Chartered Accountants of India publishes guidance on internal controls and audit documentation requirements that apply to financial reconciliation processes regardless of deployment model. An on-premise deployment that produces no audit trail does not satisfy ICAI’s evidence requirements any more than a poorly configured SaaS deployment does. The deployment model and the audit trail quality are separate questions.
What the Decision Should Not Be Based On
Two common factors that should not drive the deployment architecture decision:
IT department preference for on-premise. A default position that “sensitive financial data should be on our own servers” is not a regulatory requirement for most Indian enterprises. It is a preference that carries real infrastructure cost and management overhead without a corresponding compliance benefit when AWS Mumbai SaaS satisfies the applicable regulatory requirements.
Vendor pressure toward a single deployment model. A vendor that offers only SaaS cannot serve regulated entities with on-premise mandates. A vendor that defaults every customer to on-premise is likely pricing infrastructure costs into the engagement. The right vendor offers both options and helps you determine which is appropriate for your regulatory category, without assuming one answer fits every customer.