Know which rules apply
We read your licenses, card flows and contracts, and list each obligation next to the reader who checks it.
Fintech and banking security compliance in India
Build and secure your financial product — and know which rules bind you.
For banks, NBFCs, payment and lending apps. We help you build and secure the product, and we work out which rules really apply: RBI or SEBI through your license, PCI DSS v4.0.1 through card data, SOC 2 through a bank customer's contract. Each wants different evidence, so we settle that before you buy any assessment.
- Which rules apply, settled first
- Clear about what we can't sign
- We reply within one working day.
- RBI Cybersecurity Directions, 2026
- RBI Payment Aggregator Directions, 2025
- SEBI CSCRF Version 1.0
- PCI DSS v4.0.1
- SOC 2
In brief
- Who it's for
- Banks, NBFCs, payment aggregators, payment and lending apps, SEBI-regulated firms, and software companies that sell to banks.
- What gets in the way
- Several rulebooks can bind you at once, and each wants its own evidence. Buy an assessment before you know which apply, and it may answer the wrong reader.
- How we help
- We list the rules that really apply, build and secure your product, and help you fix what matters. We say plainly which documents need another signer.
What we do
Build it, secure it, and show the right evidence.
Three kinds of help for financial companies. Start with any one, or book a call and we'll suggest the smallest piece of work that answers your question.
Build a secure product
We build payment, lending and banking apps for web and mobile, and review the design and code for security before launch.
Find and fix weaknesses
We find what is exposed, confirm each finding by hand, rank the fixes by risk and check that each fix held.
Need someone to own security and compliance with you over time? See vCISO services and managed security and compliance.
Before any assessment
A fintech can answer to more than one rulebook at once.
Regulators and customers do not ask the same questions.
Take a payment company with an RBI authorization, a checkout that touches card numbers, and a product sold to banks. It has several readers. RBI reads against its directions. Your acquirer, the bank that processes your card payments, reads against PCI DSS v4.0.1. A bank customer's vendor-risk team reads against its contract. None of them has to accept evidence written for another.
So order matters. A rule binds you when its applicability line describes your company, not when someone quotes it at you. Buy a vulnerability assessment report before that is settled, and it answers whichever reader happened to ask first. A SOC 2 report has no legal force in India, so it cannot stand in for a regulator's demand.
Three ways a rulebook reaches you
- Through a license. An RBI license can bring cybersecurity directions with it. On 31 July 2026 RBI issued separate sets for commercial banks, NBFCs, credit information companies, all-India financial institutions and several other kinds of bank. Payment aggregators have separate 2025 directions. SEBI-regulated entities answer to CSCRF Version 1.0, as modified by SEBI's Technical Clarifications circular of 28 August 2025.
- Through card data. PCI DSS v4.0.1 follows the card data, not the org chart. Any system that stores, processes or transmits account data is in scope, along with whatever connects to it. Your acquirer decides which way of proving compliance it accepts.
- Through a contract. When a bank customer wants a SOC 2 report, the request sits in an agreement or questionnaire, and that clause decides what satisfies it. If your partner is a commercial bank, RBI's 2026 directions for commercial banks bind the bank and can reach you through your contract.
Find the right help
Start with the question you need answered.
Most requests start with a rule or a customer's question. Here is the piece of work that answers each one.
- RBI's directions set vulnerability assessment minimums for us. Who runs them and checks the fixes?Vulnerability management
- Card numbers pass through our checkout. How much of PCI DSS lands on us?PCI DSS scoping
- A bank customer wants our SOC 2 report. Do we need Type 1 or Type 2?SOC 2 readiness
- We are building a payment or lending app. How do we design security in from the start?Threat modeling
- Our payment data sits in the cloud. Has anyone checked the setup against a benchmark?Cloud security review
- Could we report a cyber incident to CERT-In within six hours, and who would respond?Incident response
- We need one person to keep all of these rulebooks in view over time.vCISO services
Deciding what applies
Build your obligation list from paperwork you already hold.
Every step reads your own documents. You can start on your own, or we can work through it with you.
Start with licenses and registrations
List each RBI or SEBI authorization and the entity type it names. That type, not your product category, decides which directions address you.
Follow a card number through your systems
Trace where a card number goes after a customer enters it, including recordings and support tickets. Whether it reaches your servers sets your share of PCI DSS v4.0.1.
Pull the clauses from your contracts
Collect security clauses, questionnaires and partner agreements. Note what each one names: a report type, a covered period, a test, or a regulator's expectations passed on to you.
Give every obligation a reader
Next to each item, write who reads the evidence: RBI, SEBI, your acquirer, a bank customer or a partner. Choose assessments against that list. Anything without a reader is optional.
What each one asks
The same company, asked for different evidence by each reader.
Compare the rows that apply to you.
| Rulebook | What it asks for | Worth knowing |
|---|---|---|
| RBI Cybersecurity Directions, 2026 | Separate vulnerability assessment and testing minimums on critical systems | Also before and after go-live, and after major change |
| RBI Payment Aggregator Directions, 2025 | A PCI DSS report with both the Attestation of Compliance (AOC) and the Report on Compliance (ROC) | Where payment data is stored is tied to RBI's 6 April 2018 circular |
| SEBI CSCRF Version 1.0 | Assessment and testing findings in separate report sections | Annexure-A is filed by you, not your tester |
| PCI DSS v4.0.1 | A signed Attestation of Compliance | PCI SSC issues no compliance certificate |
| SOC 2 Type 2 report | Controls shown operating across a stated period | A Type 1 does not count as coverage |
Who signs is not up to us. No rulebook here lets whoever prepared the evidence choose whose name goes on it. SecWiz is not a QSA company, an Approved Scanning Vendor, a CPA firm or a CERT-In empanelled auditor, so any document that needs one of those signers has to come from them. Ask every provider which of these documents it will sign, and for card data, start with how PCI DSS draws its scope.
FAQ
Questions financial companies ask before choosing an assessment.
Rulebooks, report formats and who signs what. For anything else, ask us directly.
Only for the entities its rules name. RBI's cybersecurity directions of 31 July 2026 come as separate sets by entity type, and they fix vulnerability assessment and testing minimums for commercial banks, small finance banks, payments banks, NBFCs from the Middle Layer up, credit information companies and all-India financial institutions. We cover the vulnerability assessment side. Part of the required testing is work SecWiz does not perform, so that part needs another provider. Payment aggregators face similar testing demands under separate 2025 directions, and other fintechs can inherit them through a partner bank's contract.
Yes, for a SEBI-regulated entity. CSCRF Version 1.0, as modified by SEBI's Technical Clarifications circular of 28 August 2025, keeps vulnerability assessment findings and testing findings in separate report sections, and wants every tool listed by name, marked open source or commercial, with how it was run. The Annexure-A summary is filed with SEBI by the entity.
For an aggregator, PCI DSS sits inside RBI's rules as well as the card brands'. RBI's Payment Aggregator Directions, 2025 make it responsible for its merchants' infrastructure being compliant and expect a PCI DSS report carrying both the Attestation of Compliance and the Report on Compliance. Where payment data is stored falls under RBI's circular of 6 April 2018.
Some bank customers ask for one, but the requirement comes from their contract, not from a law or regulator, so the customer's clause decides which report and which period it accepts. A SOC 2 report is an opinion issued by an independent licensed CPA firm, and no SOC 2 certificate exists.
Not as a single document. The work can overlap, but each reader expects its own evidence. RBI's aggregator directions want a Report on Compliance beside the Attestation of Compliance, and only a QSA or an Internal Security Assessor signs that report. SEBI's format keeps assessment and testing findings apart. Settle who reads what before agreeing any scope.
No. SecWiz is not a CERT-In empanelled auditing organization, a PCI SSC qualified QSA Company, an Approved Scanning Vendor or a CPA firm, and it holds no approval from RBI or SEBI. Where a rulebook names one of those signers, that document has to come from them.
Let's talk
Tell us about your licenses, card flows and contracts.
Send what you know about them. We'll point out which rulebooks apply and which documents need another signer. Project work is delivered remotely from India during business hours. We reply within one working day.