We’ve written elsewhere about how tokenization and hosted payment fields let most fintech applications avoid touching raw card data entirely, which handles the biggest share of PCI-DSS scope. What’s less often discussed is the infrastructure layer underneath that decision - the cloud architecture choices that determine whether the rest of your compliance posture is actually solid, or just looks solid on the self-assessment questionnaire.
Why infrastructure choices are a compliance decision, not just a technical one
PCI-DSS (and India’s evolving data protection and RBI compliance requirements around financial data) impose real, specific requirements on where and how data is stored, transmitted, and accessed - not just what happens inside your application code. Choosing a cloud provider, region, and infrastructure architecture without those requirements as an explicit input often produces an application that’s technically well-built but sits on infrastructure that makes genuine compliance harder or more expensive to demonstrate than it needed to be.
What actually matters at the infrastructure layer
- Network segmentation as actual infrastructure, not just application-layer logic. Payment-related systems should sit in genuinely isolated network segments - separate VPCs or subnets with strict, explicit ingress/egress rules - not just logically separated within a shared network that a misconfigured security group could accidentally expose.
- Data residency and regional compliance. For Indian fintech specifically, RBI’s data localization requirements mean payment system data needs to reside within India - a genuine architectural constraint on cloud region choice, not a detail to figure out after the infrastructure is already built elsewhere.
- Managed compliance-relevant services where they exist - using cloud providers’ own PCI-DSS-compliant managed services (managed databases with the right compliance certifications, managed key management services) rather than self-managing infrastructure that then needs to independently prove the same compliance properties.
- Infrastructure-as-code with compliance rules enforced automatically, so a network configuration that would violate segmentation requirements gets caught in a pull request, not discovered during an audit - the same discipline as automated security scanning, applied specifically to compliance-relevant infrastructure changes.
Where we’ve seen this go wrong even with good application-layer security
A well-tokenized payment flow with genuinely good application security, sitting on infrastructure where a development environment has unintentional network access to production payment systems, or where infrastructure changes happen through manual console changes with no audit trail of who changed what network rule and when. The application layer being solid doesn’t compensate for infrastructure gaps - auditors and, more importantly, actual attackers look at the whole system, not just the parts your development team directly wrote.
What we actually build first
Before writing application code for a fintech product, we architect the infrastructure’s compliance boundaries explicitly - which network segments hold payment-relevant systems, what data residency requirements apply, how infrastructure changes are tracked and reviewed. Getting this right from the start is dramatically cheaper than discovering during a compliance audit that the underlying infrastructure needs real rework to support what the application layer already does correctly.
We build compliant cloud infrastructure as part of our fintech engineering work, treating infrastructure architecture as a compliance decision from day one. Talk to us if you’re architecting or auditing a financial platform’s infrastructure against PCI-DSS or RBI requirements.