How Razorpay Automates RBI Compliance on Kubernetes with Kyverno
Razorpay meets the Reserve Bank of India’s Payment Aggregator Master Directions across more than 7,000 Kubernetes nodes by writing its regulatory controls as Kyverno policies. The same policies run in CI, at admission and in periodic scans, so every change is checked against RBI requirements and auditors see live enforcement records instead of spreadsheets.
That is the short version of a CNCF case study published in June. Razorpay’s Head of Security, Ashwath Kumar, and Nirmata CEO Jim Bugwadia presented it as a keynote at KubeCon + CloudNativeCon India and again on CNCF Cloud Native Live on October 14; both recordings are below. This post covers what the regulator asks for, how Razorpay built the controls, and how to apply the same pattern to your own RBI obligations.
What does RBI require of a payment aggregator’s infrastructure?
Razorpay processes an annualized $180 billion in payments for millions of businesses and more than 300 million consumers, and powers payments for 80 of India’s 100 unicorns. As an authorized payment aggregator, it answers to RBI’s PA Master Directions. The case study names three requirements that land directly on the platform team:
| Requirement | What it means on Kubernetes |
|---|---|
| Data localization | Transaction processing systems and their logs stay inside India, within enforced boundaries |
| Zero-trust access and microsegmentation | Core transaction clusters are isolated, with least-privilege access and segregation of duties |
| Continuous auditability | Point-in-time screenshots and spreadsheet approvals no longer count; compliance must be provable at any moment |
The third requirement changes the shape of the work. A control that held on the day of the audit is no longer evidence. The question becomes whether it holds now, and whether you can show that it held last Tuesday at 3am.
Why manual review stopped working
Razorpay used to validate these requirements the usual way: architecture reviews, deployment checklists and engineering approvals. That held while the platform was smaller. It stopped holding at 7,000-plus nodes, dozens of commits a day and autoscaling that adds hundreds of nodes in minutes during festival sales.
The case study calls this the Manual Impossibility Paradox. Reviewers could not read YAML as fast as developers shipped it, and a review of a static manifest says little about ephemeral containers that spin up and down on demand. Patching on a quarterly window was its own exposure, since automated scanners now find drift and unpatched CVEs within minutes of them appearing.
Razorpay still launches more than 40 products a year. Slowing that down to satisfy the auditor was not an option, so the controls had to move into the platform itself.
How Razorpay enforces RBI controls with Kyverno
Razorpay worked with Nirmata to adopt Nirmata Enterprise for Kyverno, the enterprise distribution of the CNCF-graduated policy engine. Kyverno policies are Kubernetes resources written in YAML, so developers read them the way they read their own manifests, without learning a separate policy language.
The architecture places the same policies at three points between a git push and a running container:
| Layer | Where it runs | What it catches |
|---|---|---|
| Proactive | IaC and GitOps pipelines | Non-compliant Kubernetes manifests and cloud templates, including S3 and data-residency boundaries, before anything is provisioned |
| Preventive | Kubernetes API server (admission) | Root containers, wildcard RBAC bindings, missing compliance metadata and unsigned images, at the moment of deployment |
| Detective | Periodic cluster and cloud scans | Drift, policy bypasses, and existing resources that fall out of line when a policy changes |
Admission: validate, mutate, generate, verify
At the API server, Kyverno does more than block. It validates: a pod that runs as root or a request for a wildcard ClusterRoleBinding is rejected with an error message the developer sees in their own console. It mutates: secure defaults and compliance labels are added to workloads automatically. It generates: each new namespace gets an isolating NetworkPolicy and Istio authorization settings, which gives Razorpay microsegmentation without asking developers to write network configuration. And it verifies: only images built in Razorpay’s CI pipelines and signed with Sigstore Cosign are admitted.
Mutation and generation are what make compliance the default path rather than a gate. A developer creating a namespace does nothing extra, and the namespace arrives isolated.
Scans close the loop
Admission control only sees changes. The detective layer covers everything else: resources created before a policy existed, and configuration that moved outside Kubernetes. When Razorpay tightens a rule to meet a newer standard, the scans flag the existing resources that no longer comply. (Network policy is a good example of why this matters.)
What changed for Razorpay
The case study reports four outcomes:
- Autoscaling stays compliant. Kyverno evaluates policy at admission in milliseconds, so the thousands of containers added during a traffic spike inherit RBI zero-trust rules at creation, with no added latency in payment pipelines.
- Audit evidence is generated, not gathered. Kyverno’s policy events feed continuous compliance dashboards. When auditors ask about microsegmentation or data isolation, Razorpay shows enforcement logs instead of checklists.
- Developers stopped waiting on committees. A violation arrives as a readable message about a YAML field, inside the developer’s normal workflow.
- Only signed images run in production. Unsigned or unapproved images are rejected at admission, which narrows the window for exploits against unpatched dependencies.
Razorpay’s next steps are to contribute reusable Kyverno policy templates for financial regulation back to the community, use AI agents to test policies and gather audit evidence on a schedule, and build a multi-cluster compliance view on OpenReports.
Watch the talks
Ashwath Kumar and Jim Bugwadia’s KubeCon + CloudNativeCon India keynote is the short version of the architecture. The Cloud Native Live session is a longer conversation that also covers why Razorpay chose Kyverno and how it works with the CNCF community.
Applying the pattern to your own RBI obligations
Payment aggregators are one group of regulated entities. Banks, NBFCs and other entities fall under RBI’s IT governance and IT outsourcing directions, which have their own numbered clauses. Nirmata’s nctl CLI (v4.10.22 and later) maps Kyverno policies to two of them: the Information Technology Governance, Risk, Controls and Assurance Practices Directions, 2023, and the Outsourcing of Information Technology Services Directions, 2023.
# Scan a cluster against the RBI mapping
nctl scan compliance --standard rbi
# Pass/fail checklist by clause ID, e.g. ITGRC.19(a) need-based access
nctl compliance checklist --standard rbi
# Collect an evidence package for auditors
nctl compliance audit --standard rbiThe mapping covers 44 policies. Of the 44 controls in the checklist, 20 are checked automatically from the cluster. The other 24, such as board oversight, BCP testing and outsourcing agreements, are organisational and show up as manual rows, so the checklist is honest about what a cluster scan can prove. Cloud-layer controls such as data localisation and encryption at rest are scanned separately with nctl scan terraform.
To see the controls in a broader setting, the Zero Trust for Kubernetes with Kyverno eBook covers microsegmentation, least privilege and image verification in more depth, and our NIS2 guide applies the same approach to the EU’s rules. If you are working through an RBI audit now, talk to us about continuous compliance.
Frequently asked questions
What RBI rules does Razorpay's Kubernetes platform have to meet?
As an authorized payment aggregator, Razorpay operates under the Reserve Bank of India's Payment Aggregator Master Directions. For its infrastructure, the case study names three requirements: transaction systems and logs stay within India, core transaction clusters are isolated with least-privilege access, and compliance can be proven at any moment rather than through point-in-time screenshots.
Does Kyverno slow down deployments during traffic spikes?
Not in Razorpay's experience. The CNCF case study reports that Kyverno evaluates policies at Kubernetes admission in milliseconds, so the thousands of containers created during autoscaling inherit the same zero-trust rules at creation without adding latency to payment pipelines. That matters for a platform that runs at 99.99% availability through festival and flash-sale peaks.
How do auditors get evidence from a policy-as-code setup?
Kyverno records every policy decision as a Kubernetes event and in policy reports. Razorpay feeds those into compliance dashboards, so when auditors ask about microsegmentation or data isolation, the team shows system logs of active enforcement instead of spreadsheets. With Nirmata's nctl CLI, the command nctl compliance audit --standard rbi collects an evidence package mapped to RBI clause IDs.
Is Kyverno only for Kubernetes admission control?
No. Razorpay runs the same Kyverno policies in three places: in IaC and GitOps pipelines before anything is provisioned, at the Kubernetes API server as an admission controller, and in periodic scans of running clusters and cloud configuration. One policy language across all three is what lets a rule change propagate to new and existing resources alike.