TL;DR: Fintech platforms operating across India and the EU now answer to at least four overlapping regimes: the EU's Digital Operational Resilience Act (DORA) for operational resilience and third-party ICT risk, PCI DSS 4.0.1 for cardholder data, RBI's data localization and Digital Payment Security Controls directions, and India's DPDP Act for personal data broadly. Financial services already carries the highest average data breach cost of any sector in India at ₹40.9 crore, well above the national average of ₹25.5 crore — which makes this the industry where getting the architecture wrong is most expensive. This guide covers what each regime specifically requires, where RBI's absolute payment-data-in-India mandate interacts with DORA's EU-based resilience testing for cross-border platforms, and how to design a fintech data architecture that satisfies all four without building four parallel compliance systems.
Why Fintech Compliance Requires More Layers Than Any Other Industry
Most industries in this compliance series deal with two or three overlapping regimes. Fintech routinely deals with four or more at once, because "fintech" is really several distinct regulatory surfaces stacked together: payment processing (PCI DSS, RBI payment directions), lending and credit decisioning (RBI digital lending guidelines, credit bureau data rules), general personal data (DPDP Act, GDPR for EU-facing platforms), and — for any platform with EU financial-entity clients or operations — operational resilience under DORA.
Depending on business model, fintechs may need to satisfy RBI requirements, SEBI's Cybersecurity and Cyber Resilience Framework, DPDPA, PCI DSS, ISO 27001, ISO 27701, SOC 2, and increasingly NIST AI RMF or ISO 42001 for AI-driven credit and fraud models. Treating each of these as a separate compliance project, run by separate teams with separate tooling, is how fintechs end up with four audit logs that don't agree with each other and a security team that can't produce a single source of truth during an actual incident.
DORA: Operational Resilience for EU-Connected Fintech
The Digital Operational Resilience Act entered into application in January 2025 and requires banks, insurers, investment firms, and other EU financial entities — plus, critically, their ICT third-party providers — to demonstrate they can withstand, respond to, and recover from technology disruptions.
What DORA actually requires architecturally
- 24-hour major incident reporting: Financial entities must report major ICT incidents within 24 hours of classification, which means your monitoring and incident-classification pipeline needs to be fast enough to detect, classify severity, and trigger the reporting workflow inside that window — not discover the incident during a weekly log review.
- Register of Information (RoI) for third-party ICT providers: A formal, continuously maintained register of every ICT vendor and the services they provide, including concentration risk assessment. For a fintech built on a stack of API integrations — payment gateways, KYC providers, credit bureaus, cloud infrastructure — this register needs to be generated from your actual infrastructure and vendor contracts, not maintained as a static spreadsheet that drifts out of date the moment you add a new integration.
- Critical Third-Party Provider oversight: As of November 2025, the European Supervisory Authorities designated 19 Critical ICT Third-Party Providers, including AWS, Google Cloud, Microsoft, Oracle, and SAP, subjecting them to direct EU oversight. If your fintech platform runs on one of these providers, your own DORA compliance documentation needs to reference and align with that provider's oversight status, not treat them as an ordinary vendor.
- Annual resilience testing: Regular testing of ICT systems, with advanced threat-led penetration testing required for entities deemed significant. In 2026, regulators have shifted from reviewing paperwork to demanding real-time evidence of resilience and automated reporting rather than annual checkbox exercises.
For a fintech that isn't itself an EU financial entity but provides technology or data services to one, DORA still applies indirectly — your contracts with EU clients will increasingly require you to meet DORA-aligned incident reporting and resilience testing standards as a condition of the relationship.
RBI's Data Localization Mandate: The India-Specific Constraint
The Reserve Bank of India's directive on storage of payment system data is absolute for any payment system operator: domestic payment transaction data must be stored only in India, with no exceptions, covering end-to-end transaction and settlement data, customer identifiers like name, mobile number, and PAN, beneficiary details, and payment credentials including OTPs and PINs. For cross-border transactions with both a foreign and domestic leg, only a copy of the domestic component may be stored abroad.
This creates a direct architectural tension for any fintech also trying to satisfy DORA or GDPR data-flow requirements: your Indian payment data has to physically reside in India, full stop, while your broader compliance and monitoring infrastructure (which DORA and GDPR both expect to be robust and auditable) may otherwise default to a global or EU-based deployment. The fix isn't complicated in principle — region-pinned data storage for payment records, with compliance tooling and monitoring layered on top that respects the residency boundary rather than replicating raw payment data elsewhere — but it has to be a deliberate architecture decision, not an afterthought discovered during an RBI audit.
Layered on top of the payment-specific mandate, RBI's Digital Payment Security Controls Directions, 2021 require regulated entities to establish governance and security controls for digital payment products broadly, explicitly stating that payment architecture must be robust and scalable to accommodate transaction volume and customer growth — language that puts capacity planning and architecture review inside the compliance scope, not just security controls in the narrow sense.
DPDP Act and RBI's Sector-Specific Overlay
India's DPDP Act sets the general personal data framework, but RBI has issued its own advisory directing all regulated entities to prioritize customer data protection in alignment with DPDP — providing sector-specific detail on how data minimization, consent, erasure, and platform accountability should work specifically in the financial ecosystem. This means a fintech's DPDP compliance program can't just copy a generic template; RBI's advisory effectively sets the financial-sector interpretation of DPDP's general principles.
Section 8 of the DPDP Act requires every data fiduciary to implement reasonable security safeguards against breaches, with penalties up to ₹250 crore for failure — a ceiling that, combined with financial services already carrying the highest average breach cost of any Indian sector at ₹40.9 crore, makes underinvestment in this architecture one of the more expensive shortcuts a fintech can take.
PCI DSS 4.0.1: Still the Baseline for Any Card Data
Any fintech that touches card payments — even indirectly, through a payment gateway integration — still needs PCI DSS 4.0.1 compliance for the parts of its stack that store, process, or transmit cardholder data. The 2026 baseline is the full requirement set with no remaining transition relief: mandatory script inventory and integrity monitoring for anything resembling a payment page (Requirement 6.4.3), automated detection of unauthorized changes to security headers and payment content (Requirement 11.6.1), TLS 1.2 or higher everywhere cardholder data moves, and audit logs retained at least 12 months. For fintechs building embedded finance or BNPL products inside someone else's checkout flow, scope determination — exactly which parts of the joint architecture fall under your PCI assessment versus the merchant's — needs to be resolved at the API-integration design stage, not discovered during the first joint audit.
SEBI's Cybersecurity and Cyber Resilience Framework: The Fifth Layer for Capital Markets Fintech
Fintechs that touch capital markets — wealth management platforms, broking APIs, mutual fund distribution tech, algo-trading infrastructure — add a fifth regime on top of the four above: SEBI's Cybersecurity and Cyber Resilience Framework (CSCRF). CSCRF consolidates what used to be sector-specific circulars into one framework covering governance, identification of critical assets, protection controls, detection, response, and recovery, modeled loosely on the NIST Cybersecurity Framework but with India-specific reporting obligations to SEBI and CERT-In.
The practical overlap with what's already covered above is significant: CSCRF's asset-identification and vendor-risk requirements map closely to DORA's Register of Information discipline, and its incident-reporting timelines sit alongside RBI's and DPDP's own clocks. A capital-markets fintech that has already built the unified vendor-risk and incident-classification infrastructure described below for DORA and RBI compliance typically only needs to add SEBI-specific reporting templates and asset classifications on top, rather than a parallel system.
What's Actually Driving Up Breach Costs in 2026
Beyond the headline ₹40.9 crore average for financial services, IBM's 2026 data points to specific cost drivers worth designing against directly. Shadow AI — AI tools and models deployed without security team visibility or governance — added an average of ₹1.79 crore to breach costs where present, making it one of the top three cost-increasing factors in India alongside regulatory non-compliance and cloud migration activity. For fintechs racing to ship AI-driven credit decisioning, fraud and risk analytics, or customer-facing chatbots, this is a direct argument for bringing every AI integration through the same architecture review and vendor-risk process as any other data-processing component, rather than letting product teams wire up a new model API independently. Cloud migration, ironically, is also a top cost driver when it happens without the security architecture keeping pace — a reminder that the region-pinned storage and vendor-register work described above needs to happen alongside any infrastructure migration, not as a follow-up project after the migration is already live.
How the Four Regimes Interact
| Requirement | DORA (EU) | RBI (India) | DPDP Act (India) | PCI DSS 4.0.1 |
|---|---|---|---|---|
| Applies to | EU financial entities + their ICT vendors | RBI-regulated payment/lending entities | Any processor of Indian personal data | Anyone storing/processing/transmitting card data |
| Core focus | Operational resilience, ICT risk | Payment data localization, security controls | Consent, retention, breach notification | Cardholder data protection |
| Incident reporting window | 24 hours (major incidents) | Per RBI cyber-incident reporting norms | 72 hours to Data Protection Board | Per card network requirements, no fixed clock |
| Data residency requirement | No blanket EU residency mandate | Absolute: payment data stored only in India | Government can restrict transfers to notified countries | Not directly addressed |
| Third-party oversight | Formal Register of Information, CTPP designation | Vendor risk part of RBI outsourcing guidelines | Data Processor obligations flow from Fiduciary | Service provider PCI attestation required |
| Max penalty | Varies by member state, tied to global turnover | Regulatory action, license conditions | Up to ₹250 crore | Fines from card networks, loss of processing rights |
The clearest overlap is third-party risk: DORA's Register of Information, RBI's outsourcing due diligence, and DPDP's Data Processor obligations are all, functionally, the same discipline — maintaining a live, accurate inventory of every vendor touching sensitive data and verifying their security posture. Building one vendor-risk system that satisfies the strictest requirement from each regime is far more efficient than maintaining three separate vendor registers that inevitably drift apart.
A Practical Architecture Checklist
- Region-pinned payment data storage: Domestic payment transaction data physically stored in India per RBI's mandate, architecturally separated from globally-replicated compliance and monitoring data.
- Unified vendor risk register: One system of record for third-party ICT and data-processing vendors that satisfies DORA's RoI, RBI's outsourcing due diligence, and DPDP's processor documentation simultaneously.
- Incident classification pipeline fast enough for 24-hour DORA reporting: Automated severity classification, not manual triage, for any platform with EU-connected obligations.
- Segregated retention policies: PCI's 12-month minimum audit log retention kept separate from DPDP-driven personal data minimization, so a shorter privacy retention window doesn't accidentally delete data you're required to keep for card-network audits.
- API integration scope mapping for embedded finance: Clear technical and contractual boundaries for which party's PCI assessment covers which part of a joint checkout or lending flow.
- AI model governance for credit and fraud decisioning: Documentation and explainability logging for any AI-driven credit decisioning or fraud and risk analytics system, anticipating NIST AI RMF or ISO 42001-style scrutiny even before it's formally mandated in India.
- Breach cost modeling tied to actual architecture: Given financial services' ₹40.9 crore average breach cost, security investment decisions should be modeled against this sector-specific figure, not the lower cross-industry average.
Building One Architecture, Not Four Compliance Silos
The fintechs that handle this well don't run DORA, RBI, DPDP, and PCI DSS as four separate projects — they map their actual data flows once, identify where each regulation's requirements attach to that flow, and build shared infrastructure (vendor risk registers, incident classification, data residency controls) that satisfies the strictest applicable requirement at each point. Given that financial services carries the highest breach cost of any sector in India, this isn't a compliance nice-to-have; it's a direct input into how expensive your worst day gets.
If you're architecting a new fintech platform or auditing an existing one against DORA, RBI, DPDP, and PCI DSS together, Syslabs works with lending, payments, and embedded finance platforms on exactly this kind of unified compliance architecture, through both compliance and risk consulting and custom platform builds.
Sources: EIOPA and Digital Operational Resilience Act official guidance, Cloudsmith DORA compliance checklist, Medianama on RBI's 2026 data protection advisory, Leegality and SISA on RBI payment data localization, IBM Cost of a Data Breach Report 2026 (India), Accorian on India fintech cybersecurity 2026.