Zero Downtime. Four Years. No Exceptions.
What does bank-grade infrastructure look like in India’s Account Aggregator ecosystem? Here is ours — always up and designed for UPI scale
0 downtime incidents across 4 years of live AA operations <100ms API P95 latency, maintained consistently in production 30-minute RPO — the maximum data exposure window in a worst-case failure
Most infrastructure conversations happen after something breaks. We are writing this one before it does — because in four years of live operations in the AA ecosystem, nothing has.
That record is not luck. It is the output of deliberate architectural decisions made before a single line of customer-facing code was written. This post documents what those decisions are, how they hold together, and why anything short of this standard is a liability for any organisation operating in regulated financial infrastructure.
Reliability & Uptime Built for zero downtime — not recovery from it
Most systems are built to recover fast. We built ours to not need recovery. The architecture is JAMstack at the edge: the customer-facing layer is pre-rendered and decoupled from backend state, which means a backend hiccup has zero impact on what your users experience. The two layers are independent by design.
Behind the frontend, backend services are stateless — horizontally scalable without state conflicts. They run with replicas across at least two AWS Availability Zones. If one AZ goes dark, the other carries the load. This is not a fallback. This is the baseline.
- JAMstack architecture — decoupled, pre-rendered frontend; inherently resilient to backend state changes
- Stateless backend services — horizontal scaling with no state conflicts, on demand
- Multi-AZ deployment — replicas across ≥2 Availability Zones for continuous fault tolerance
- HA Kubernetes clusters — autoscaling infrastructure that responds to load in real time
- Zero-downtime deployments — all upgrades are backward compatible and go to production without interrupting live traffic
On database continuity: the database is replicated from Mumbai to Hyderabad with Point-in-Time Recovery (PITR) enabled. Critical data is never lost. Database migrations themselves use blue-green deployments — the migration-related downtime that most engineering teams accept as inevitable does not occur here.
Security Certifications that mean something. Testing cycles that keep them honest.
Compliance is a floor, not a ceiling. We hold ISO 27001 certification and SOC 2 compliance since our first year of operation — the two standards most demanded by enterprise buyers in financial services. But certifications are point-in-time assessments. What keeps them meaningful is the discipline applied between audits.
We run VAPT — Vulnerability Assessment and Penetration Testing — twice a year. Not because it is mandated. Because a financial data infrastructure that tests its own attack surface only when externally required is not a serious security posture.
- ISO 27001 Certified
- SOC 2 Compliant
- Bi-annual VAPT Cycles
Observability: You cannot fix what you cannot see. We see everything.
Observability is not a dashboard. It is the ability to ask any question about your system’s behaviour at any point in time and get a precise answer. That requires three distinct data types operating in concert: logs, metrics, and distributed traces.
Our stack is built on LGTM: Loki for log aggregation, Grafana for unified dashboards, Tempo for distributed tracing, and Mimir/Prometheus for metrics. The result is full-stack observability — a single pane that gives our engineering team complete visibility from a user-facing API call down to the database query it triggers, at every hop in between.
When something behaves unexpectedly — even briefly — we see it before you do. Incident investigation that might take hours in a system with siloed monitoring takes minutes when logs, traces, and metrics are unified.
Disaster Recovery RTO and RPO are commitments, not estimates
The industry has a habit of publishing recovery metrics without publishing what backs them. Here are ours, and what makes them credible.
RTO — Recovery Time Objective: 4 Hours Maximum time to restore full service.
RPO — Recovery Point Objective: 30 Minutes Maximum data loss window in a worst-case failure.
These numbers are backed by cross-region database replication — Mumbai to Hyderabad — and PITR. In the event of a catastrophic failure, recovery does not require human heroics. It requires activating a process that has already been designed, tested, and validated.
API Reliability & Versioning: Fast, stable APIs. No surprises.
API latency is a product decision disguised as an engineering metric. At P95 under 100ms — consistently — our APIs do not become the bottleneck in your user journey. That consistency matters more than a headline number: a system that hits 50ms on average but spikes to 800ms under load is not a reliable system.
Every API follows semantic versioning. Breaking changes do not land in existing versions. Customers are never surprised by an integration that stops working because we shipped a new release. This is how APIs should work. In practice, it is rarer than it should be.
- P95 latency <100ms — consistent, not just average
- Semantic versioning — all APIs, no exceptions
- Backward compatibility guaranteed — breaking changes never silently introduced
Configurability: Control without custom builds
Workflow flexibility is usually sold as a professional services engagement: a custom integration, a separate build, weeks of scoping. That model serves the vendor, not the customer.
Our platform is built differently. Clients have request-level control over workflow behaviour — both UI experience and backend output can be adjusted by toggling flags in the request body. Different workflow variants, same integration. No separate builds. No additional timelines..
Need 100 flows for 100 business lines – configured within days with zero engineering. Powered by Finarkein’s proprietary Workflow Orchestration platform – one of the handful ones built across the world
This is the standard. Anything less is a trade-off.
Every architectural decision was a deliberate trade-off made in favour of reliability, security, and customer control — at the cost of shortcuts that would have made our engineering team’s life easier in the short term. Four years of zero downtime suggests those trade-offs were correct.
If your current AA infrastructure cannot produce equivalent commitments at the least — that gap is a risk that belongs in your infosec scorecard.
