Industries
Cyber security for capital markets.
Brokers, RIAs, AMCs and market infrastructure institutions under the SEBI cyber resilience framework.
What is actually going on here
Market infrastructure has a property almost nothing else has: an outage during trading hours is itself a market event. That is why SEBI's framework is prescriptive where others are principles based, and why testing here is scheduled around market hours with a care that feels excessive until you have seen a session disrupted.
The CSCRF changed the conversation. It is specific about what has to exist, how often it is assessed, and what gets reported. For brokers and intermediaries that previously ran light governance it is a step change, and the compliance calendar is the part that catches people out.
We work with exchanges, depositories, brokers and market intermediaries across the governance, testing and audit obligations, and we schedule around your sessions rather than asking you to schedule around us.
Who regulates you, and what they want
Tick the ones that bind you and we will pull together the evidence each of them actually asks for. Nothing is sent anywhere.
Pick one or more above to see what they expect of you.
What goes wrong in this sector
Trading platform manipulation
Not the exchange matching engine, which is well defended, but the order path into it: risk checks that can be bypassed, order types that behave unexpectedly under load, and client terminals with more trust than they have earned.
Algorithmic trading abuse
Where clients run algorithms through your infrastructure, the approval process is a security control whether or not anyone calls it one. A poorly bounded algorithm is an availability incident waiting for a volatile morning.
Client and demat account takeover
Credential stuffing against retail trading accounts is constant and largely automated. The consequence is not just fraud, it is a market event if enough accounts move in the same direction at once.
Market data integrity and leakage
Feeds that can be delayed or altered, and pre-publication data reachable by staff who have no business need. Both are testable and both are the kind of finding a regulator takes seriously.
How we work in this sector
- 01
Work to the calendar
We start from your CSCRF compliance calendar and work backwards, so assessments land before submission dates instead of after them.
- 02
Test outside market hours
Anything with load or availability implications runs in a scheduled window with your operations team present and a rollback agreed in advance.
- 03
Cover the order path end to end
From client terminal through risk checks to the exchange gateway, including the interfaces between them, which is where the interesting findings sit.
- 04
Report in the regulator's language
Findings are mapped to CSCRF controls, so your submission is a matter of assembling evidence rather than translating a technical report.
What we actually keep finding here
Not a threat list copied from a report. These are the patterns that recur across our own engagements in this sector, with an honest note on how often. Where we do not have a precise number we say so rather than inventing one.
- Often
Risk checks that can be bypassed on the order path
Not the matching engine, which is well defended, but the route into it: order types that behave unexpectedly under load, or checks applied inconsistently across channels.
- Most engagements
Credential stuffing treated as a support issue
A steady rise in failed logins on retail trading accounts, handled as password resets rather than recognised as an automated campaign.
- Often
CSCRF obligations scoped to the wrong entity category
Months of work aimed at requirements that do not apply, or worse, a genuine obligation missed because the category was assumed rather than established.
- Occasionally
Client algorithms approved without a security view
The approval process is a security control whether or not anyone calls it one, and a poorly bounded algorithm is an availability incident waiting for a volatile morning.
Questions worth asking any provider in this sector
Including us. If a provider cannot answer these clearly, that tells you more than any capability slide will. We would rather you asked them than took our word for it.
- 1
How will you schedule testing around market hours, and what is the stop condition?
- 2
Which CSCRF entity category do you think we fall into, and on what basis?
- 3
Will you map findings to CSCRF controls so our submission is assembly rather than translation?
- 4
Can you do the system audit and the VAPT together so the two findings sets agree?
- 5
Will you test the full order path, including the interfaces between systems?
What we deliver in this sector
- SEBI CSCRF gap assessment & audit
- Trading platform security testing
- Algo and API surface review
- Data localisation & retention review
- Business continuity & DR testing
- Insider threat and access governance
- Vulnerability management programme
- Cyber crisis simulation
Proof
SEBI compliance protecting 1.7M+ users at Marketwolf
Work in this sector
Named engagements where the client has agreed to be named, and anonymised ones where they have not, which is most of them. Named references are available under NDA.
- Capital Markets
Protecting 1.7M+ users with SEBI compliance for Marketwolf
SEBI cyber security and cyber resilience framework compliance for a high-volume retail trading platform.
1.7 million+ users
- Client withheld
Broking platform, CSCRF alignment
- Scope
- Retail trading platform and the order path into the exchange, scheduled entirely outside market hours.
- What we found
- Risk checks applied inconsistently across channels, and credential stuffing being handled as a support issue.
- Outcome
- Checks unified, automated login abuse detection added, and findings mapped to CSCRF controls for submission.
- Client withheld
Market intermediary, system audit and VAPT together
- Scope
- System audit and penetration testing run as one engagement to avoid two contradictory findings sets.
- What we found
- Entity category had been assumed rather than established, leaving two obligations unaddressed.
- Outcome
- Category confirmed, the gap closed before the reporting date, and the compliance calendar rebuilt around it.
Questions we get asked in this sector
Can you test without any risk to a live session?
Anything that could plausibly affect a session is run outside market hours, in a window you approve, with your operations team on the call. We would rather lose testing time than be the cause of a market disruption.
Which CSCRF category do we fall into?
It depends on your registration and size, and it changes what applies to you considerably. We work that out at the start, because scoping to the wrong category wastes months in one direction or leaves you exposed in the other.
Do you handle the system audit as well?
Yes. Doing the system audit and the VAPT together removes duplicated evidence gathering, and the two findings sets then agree with each other, which they often do not when separate firms produce them.
How often does CSCRF require testing?
It varies by category and by system criticality. For most intermediaries it is at least annual with additional testing on significant change. We will map your specific obligation rather than quoting a general figure.
Not sure where to start?
Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.