RegTech on a Budget: Compliance Software Architecture
Compliance software has a reputation for being enterprise software at its most bloated — long implementations, heavy platforms, pricing to match. We've spent decades building SEBI-compliance products for capital markets — insider trading and UPSI compliance, ESOP management, financial consolidation — serving hundreds of institutions with a twelve-person team. That's only possible because of architecture choices that run against the enterprise-software grain. This post is about those choices.
The constraint that defines everything: no SaaS
In regulated capital markets, the vendor cannot access client data. Full stop. That rules out the entire modern SaaS playbook — no multi-tenant cloud, no telemetry-driven product decisions, no "we'll fix it in production." Every deployment is on-premise, inside the client's infrastructure, administered by the client's people.
Most vendors treat this as a burden to engineer around. The budget insight is to treat it as the architecture: when the client runs the software, you don't build or operate cloud infrastructure at all. No DevOps team, no on-call rotation, no cloud bill scaling with customer count. The client's IT department is, structurally, part of your operations team — and they're better at their own environment than you'll ever be.
Boring stacks are a feature, not a compromise
Our products run on the Microsoft stack that enterprise IT departments in Indian financial institutions already know: Windows Server, SQL Server, .NET. Not because it's fashionable — because deployability is the product in an on-premise world. Software a bank's IT team can install, back up, and troubleshoot with skills they already have beats a technically superior stack that requires skills they don't. Every exotic dependency you add is a support ticket you'll answer for years, multiplied by every client site.
The same logic governs upgrades. You can't push updates to hundreds of on-premise sites; clients upgrade when their change-management process allows. That forces discipline modern development has largely abandoned: versions must be genuinely stable at release, database migrations must be scripted and reversible, and backward compatibility isn't a nice-to-have — old versions live in the field for years.
Regulation is the spec — and it changes on SEBI's schedule
Compliance software has an unusual property: the requirements are written by a regulator, apply to every client simultaneously, and arrive as circulars with deadlines. When SEBI updates a regulation, every client needs the change — at once, on-premise, through each client's own deployment process.
The architectural answer is to keep regulatory logic isolated and configuration-driven wherever possible, so a regulatory change is a contained, well-tested update rather than surgery across the codebase. The organizational answer matters just as much: reading circulars is engineering work here. The person who understands the regulation and the person who models the data need to be close — in a small team, sometimes the same person. That's a hidden advantage small RegTech firms have over large ones, where regulation-reading and code-writing live three departments apart.
What "on a budget" actually buys
The economics compound quietly. No cloud opex. No 24/7 operations staff. Support scoped to the software, not the infrastructure it runs on. A boring stack that new hires already know. The result is a cost structure where a small team can serve hundreds of institutional clients profitably — not by squeezing harder, but because the architecture eliminated whole categories of cost that the SaaS playbook takes for granted.
The trade-offs are real: slower feedback loops (you can't watch users in a dashboard), heavier release discipline, and revenue that grows with clients rather than exploding with usage. It's a different business, not a worse one.
The takeaway for anyone building in a regulated niche
Don't start from the modern default stack and fight your constraints — start from the constraints and let them design the system. Ours said: the client runs everything, the regulator writes the spec, and the deployment environment is conservative enterprise IT. Followed honestly, those constraints produce software that's cheap to build, cheap to run, and hard for a cloud-first competitor to displace. The constraint you can't remove is usually the moat you didn't notice.