HFT Is Not The Villain

Did someone need secret information to bend an electronic market?

Not really. That is the uncomfortable part.

The scandal was not that someone saw a secret result, a secret merger, a secret government order, or some cartoon version of insider trading.

The scandal was that some people may have seen public information first.

In HFT, that is enough.

I come from the HFT domain. A significant part of my career has been around systems where nanoseconds and microseconds matter: market data, feed handlers, order gateways, cache lines, kernel bypass, NUMA locality, CPU isolation, and the small details that make a machine either deterministic or useless.

So this is not an anti-HFT post. To be honest, I find most anti-HFT writing shallow. It usually comes from people who do not understand what is being measured.

HFT, done cleanly, is engineering. You pay for co-location. You buy better hardware. You tune your network stack. You parse feeds faster. You write better code. You manage risk. You compete inside a published rulebook.

That is not the problem.

The problem starts when the rulebook says the market is common, but the machinery makes it private in practice:

same market
-> different access path
-> different data arrival time
-> different ability to react
-> repeated private edge

That is not “alpha”. That is market structure failing.

India has a public record of this kind of failure. It is not mostly an insider-trading story. It is a story about market data architecture, exchange network paths, fallback servers, gateway design, displayed liquidity, and exchange technology governance.

The clean distinction is this:

HFT = competing on speed inside transparent rules
malpractice = getting a speed or signaling advantage because the rules, pipes, servers, or controls are unequal

That distinction matters. Without it, the conversation collapses into lazy retail anger: “algos rig everything”. That is not useful. It is not even interesting. The better question is sharper:

When does public market infrastructure stop being public in practice?

Here is the map:

Abuse type	Mechanism	Indian record
Timing edge	Same public data arrives earlier for some participants	NSE co-location / TCP-IP TBT12
Fallback abuse	Backup or secondary path becomes the preferred low-load route	OPG secondary-server access34
Private pipe	Selective lower-latency connectivity path	NSE dark fibre / Sampark / W2W / GKN56
Gateway weakness	Access-layer controls can be bypassed or poorly governed	NSE TAP settlement7
Fake liquidity	Displayed order-book depth is used as a false signal	PWAPL spoofing/layering89
Tech governance	Exchange software dependency and disclosure failures	MCX software-contract order10

The Hard-Evidence Spine

This is where I want to be careful.

Not every item in that map carries the same legal weight. Saying “rigged” is easy. Proving the machinery was unfair is the hard part.

If the bar is real HFT/electronic-market malpractice evidence, not vibes, the article stands on two order-backed examples:

Hard example	Evidence record	Why it matters
OPG secondary-server access	SEBI’s 2019 WTM order found repeated secondary-server logins and unfair advantage. SEBI’s 2025 AO order after remand imposed penalties, followed by a 2025 recovery demand against OPG.3411	A fallback route became a preferential low-load access path.
NSE dark fibre / Sampark / W2W / GKN	SEBI’s WTM and AO records cover unauthorized Sampark connectivity, differential access treatment, monetary directions, and penalties.56	A selective telecom path became an exchange-access fairness problem.

That being said, the other examples are still useful if we keep their posture clean. PWAPL is order-book manipulation based on interim and confirmatory orders. TAP is a settlement, not an adjudicated finding. MCX is a technology-governance case, not an HFT manipulation case. BSE should not be dragged into a stronger claim than the primary-source record supports.

Public Data Can Still Be Unequal

In a low-latency market, public information is not equal just because everyone is allowed to receive it.

Arrival time matters.

If two participants receive the same tick, but one receives it consistently earlier because of the exchange’s dissemination architecture, the “publicness” of that data becomes a legal fiction.

In a slow market, that difference may be noise. In an HFT market, that difference is the market.

This is the core of the NSE co-location controversy.

NSE’s tick-by-tick market data over TCP/IP became the center of a long SEBI record.¹ The basic issue was not that co-location exists. Co-location is normal. The issue was whether the architecture and controls gave certain trading members a probabilistic advantage in receiving ticks earlier.

The public SEBI record discusses several technical failure modes:¹

• sequential tick-by-tick dissemination,
• first-connect advantage,
• lack of adequate randomization/load balancing,
• lower load on secondary servers,
• weak monitoring of who connected where and why.

If you work in low latency, this is immediately understandable. A feed handler does not need a magical advantage. It just needs to see the same packet earlier, often enough, in a system where the first valid reaction wins.

The simplified version:

That is the uncomfortable part. Nothing here requires inside information. The information can be public. The edge can still be unfair.

A one-time early tick is noise.

A repeatable early tick is infrastructure alpha.

The Backup Server That Became An Edge

The OPG part of the NSE co-location matter is the strongest trading-member story in this cluster.

The issue was repeated access to secondary POP / secondary servers. A secondary server should be a fallback path. It should not become the preferred path because it is less loaded or faster.

In production systems, this pattern is familiar:

primary path = intended route, crowded, monitored
secondary path = backup route, lower load, less attention
bad incentive = use backup as primary

That is a control failure waiting to happen.

The 2019 SEBI WTM order against OPG found that OPG repeatedly logged into secondary servers and gained unfair advantage.³ Later appellate and remand proceedings changed the penalty/disgorgement posture, but the core OPG finding remained the strongest part of the co-location record. SEBI’s 2025 AO order after remand again treated OPG’s secondary-server access as a serious violation and imposed penalties.⁴

The broader NSE-side co-location record is more nuanced.

SEBI’s 2019 WTM order had made severe findings and directed NSE to disgorge Rs. 624.89 crore with 12 percent interest.¹ But the 2024 SEBI remand order records that SAT did not uphold NSE disgorgement on the theory used earlier, and SEBI disposed proceedings against NSE and certain others due to insufficient objective material to establish collusion or connivance.²

That nuance should not be hidden. It is exactly why this topic needs technical writing instead of slogan writing.

The durable point is not “every exchange official colluded”. The durable point is:

A market-data system without equalizing controls can produce unfair timing outcomes even before anyone does anything that looks like classic fraud.

That is the lesson.

The Faster Cable

The dark-fibre matter is the cleaner “network path as market advantage” case.

The public SEBI record describes point-to-point connectivity involving NSE co-location and BSE co-location / BSE building endpoints.⁵ The key names are Way2Wealth Brokers, GKN Securities, Sampark Infotainment, and NSE.

The allegation and findings were not about secret corporate information. They were about a faster path.

The structure was roughly:

According to SEBI’s 2019 WTM order, Sampark was not one of NSE’s authorized telecom service providers and did not have the requisite DoT license to provide direct telecom service to end customers.⁵ The order records that Sampark approached Way2Wealth and GKN with the promise of higher bandwidth and lower latency between NSE and BSE facilities. It also records differential treatment: some members got access or continuation, others did not.

This is where the market-structure issue becomes very concrete.

A cable is not just a cable. In a low-latency market, a cable is timing. A shorter, cleaner, less congested, or more direct path can be a trading advantage.

If everyone can buy that path under the same rulebook, fine. That is competition.

If selected participants get it, if the provider is unauthorized, if the exchange process is inconsistent, if other members are denied similar access, then the pipe becomes a private market feature.

SEBI’s 2019 WTM order directed:⁵

• NSE to deposit Rs. 62.58 crore with 12 percent interest,
• Way2Wealth to deposit Rs. 15.34 crore with 12 percent interest,
• GKN to deposit Rs. 4.9 crore with 12 percent interest,
• plus governance and access-related restrictions.

SEBI’s 2022 AO order also imposed monetary penalties on NSE, officials, Sampark, Way2Wealth, GKN, and associated individuals.⁶

Before publishing final accusations in a legal sense, one should still verify the latest appeal or settlement status of every dark-fibre direction and penalty. But as a market-structure case, the technical lesson is already clear:

The integrity of an exchange is partly the integrity of its physical and logical network paths.

That sentence sounds boring. It is not. It is the whole game.

The Gateway Matters Too

NSE’s TAP settlement is another reminder that the access layer matters.

TAP means Trading Access Point. Think of it as part of the controlled pathway through which orders and trading connectivity are supposed to flow. SEBI’s 2024 settlement order records issues around TAP architecture and network connectivity, including possible bypass concerns and governance issues. NSE and other applicants settled the matter for Rs. 643.05 crore.⁷

This must be phrased carefully: settlement is not the same as an adjudicated finding. The point is not “settlement proves guilt”. The point is that the access architecture was important enough to become a major regulatory proceeding.

For a trading system engineer, that is unsurprising.

The gateway is where fairness, capacity, throttling, risk checks, session controls, and access policy become real. A rule in a circular is only a rule if the gateway enforces it.

This is why exchange technology is not back-office plumbing. It is market integrity infrastructure.

The Fake Order Book

Not all electronic malpractice is about seeing data earlier or reaching the exchange faster.

Sometimes the abuse is in the displayed order book itself.

SEBI’s PWAPL spoofing/layering orders are useful here.⁸⁹ The pattern described by SEBI is recognizable:

This is order-book manipulation as a signaling game.

The order is visible, but the intent is not genuine trading interest. The visible depth becomes bait.

SEBI’s 2025 interim order described alleged spoofing across 173 scrips and 292 scrip-contract days, with alleged unlawful gains of about Rs. 3.22 crore.⁸ SEBI’s 2026 confirmatory order maintained the core concern while modifying some directions for individuals.⁹

Again, keep the legal posture clean: interim and confirmatory directions are not the same as a final penalty order after full adjudication. But the mechanism is important enough for this discussion.

In HFT terms, the displayed book is part data structure, part battlefield. If large orders are repeatedly displayed without genuine intent, the book becomes a false signal generator.

That harms everyone who treats visible liquidity as information:

• market makers adjusting quotes,
• execution algos measuring imbalance,
• slower participants reading depth,
• surveillance systems trying to distinguish noise from intent.

This is a different category from co-location. It is not about private access to public data. It is about polluting public data itself.

MCX: Not The Same Case, Still Relevant

MCX should be handled carefully.

The strongest MCX source in this research pass is not a proven HFT manipulation case. It is a technology-governance and disclosure case around trading software contracts, 63 Moons, TCS, MCX, and MCXCCL.

SEBI’s 2025 MCX order discusses exchange software dependency, extensions, continuity risk, and disclosure lapses. Some allegations did not sustain. SEBI did establish a material disclosure lapse and imposed a Rs. 25 lakh penalty.¹⁰

That is not the same as NSE co-location or dark fibre.

But it still belongs in the wider story because exchange software is market infrastructure. If the matching, clearing, gateway, surveillance, or vendor transition stack is fragile, opaque, or poorly governed, the market inherits that risk.

The hierarchy is:

HFT abuse case? no, not on this record
exchange technology governance case? yes
market integrity relevance? yes

That is the right way to use MCX here.

BSE: Do Not Force The Evidence

BSE is also tricky.

The first research pass did not find a BSE exchange-level HFT/co-location unfair-access case comparable to NSE’s co-location and dark-fibre record.

BSE appears in the story in three ways:

• as the other endpoint or venue context in the NSE dark-fibre matter,
• as a surveillance actor in SEBI’s broader algo/HFT framework discussions,
• as a venue in many electronic-market abuse cases, especially illiquid stock-options reversal/non-genuine trade matters.

That third category is real, but it is not the same thing as HFT infrastructure abuse.

So the honest line is:

NSE has the strongest public record for unfair electronic market-access cases. BSE is present in the wider electronic market-abuse ecosystem, but I do not yet have a comparable BSE exchange-level co-location/HFT access case from primary sources.

That honesty makes the argument stronger.

What SEBI Already Knew

SEBI’s own framework documents show that these were not mysterious risks.¹²¹³

The 2018 Committee on Fair Market Conduct and related SEBI framework material discuss:

• high order-to-trade ratios,
• fleeting orders,
• excessive cancellation,
• order-pipe clogging,
• algorithm opacity,
• unequal low-latency access,
• retail disadvantage,
• need for unique algo IDs,
• exchange surveillance for HFT/algo patterns.

The 2020 OTR guidelines added daily order-to-trade ratio disincentives and possible restrictions for repeated violations.¹⁴ The commodity derivatives framework also required exchange controls around algorithm approval, order-per-second limits, dysfunctional algorithm shutdown, and co-location/proximity-hosting fairness.¹⁵

So the categories were visible:

latency asymmetry
order flooding
fake liquidity
gateway bypass
weak surveillance
opaque infrastructure

The problem is not that regulators lacked vocabulary. The problem is whether enforcement, transparency, and exchange governance kept up with the machines.

How To Find And Fix This

This is where the blog either becomes useful or becomes another complaint.

Complaining is easy. Every losing trader can say the market is rigged. The useful audit question is not “did someone trade fast?”

The useful question is:

Did similarly situated participants face equivalent market-data, network, gateway, and order-book conditions?

That needs infrastructure telemetry, not only trade surveillance. In HFT, the truth is often upstream of the trade. It is in packet timestamps, session allocation, gateway path, failover reason, rack connectivity, and the stupid little config detail nobody thought would matter until it did.

SEBI’s own framework material already points toward algo IDs, OTR controls, exchange surveillance, and fairness in co-location/proximity hosting. The next step is to treat network paths, server assignment, timestamps, and gateway logs as market-integrity evidence too.^12131415

If I were auditing this, the pipeline would be boring and ruthless:

flowchart LR
  A["Market-data packet capture"] --> D["Time-normalized event lake"]
  B["Gateway and matching-engine logs"] --> D
  C["Network inventory and path registry"] --> D
  D --> E["Fairness metrics"]
  E --> F{"Repeated private edge?"}
  F -->|"Yes"| G["Forensic review and enforcement"]
  F -->|"No"| H["Baseline monitoring"]

1. Secondary-Server Edge

This is the OPG-type problem: a fallback path quietly becomes a trading edge.

The technical malpractice pattern is:

primary feed path = crowded / intended / normal
secondary feed path = lower load / fallback / less watched
member behavior = repeatedly prefer secondary path
market effect = earlier ticks, more first reactions, better queue decisions

What I would look for:

• Build a session timeline for every member: login time, server selected, reconnects, disconnects, failover reason, and duration.
• Compare primary vs secondary server load, packet delay, and first-tick arrival distributions.
• Measure whether one member is repeatedly first to react after market-data events beyond what its normal latency profile explains.
• Flag members whose secondary-server usage is high when no genuine primary outage exists.
• Join market-data timestamps, order-entry timestamps, and matching-engine acknowledgements into one event graph.

A simple surveillance metric:

first_reaction_share(member, symbol, event_window)
= member's first valid reactions after ticks
  / all first valid reactions after comparable ticks

That metric is not proof by itself. A good firm can be fast. The red flag is when the same member’s first-reaction share changes materially with server assignment or fallback-path usage.

What actually fixes it:

• Make feed-server assignment exchange-controlled, deterministic, logged, and auditable.
• Treat secondary servers as emergency paths only; require a machine-verifiable failover reason.
• Randomize or equalize dissemination where TCP-style feed architecture creates first-connect advantage.
• Publish the feed architecture, failover rules, and fairness controls at enough detail for members to know the game is common.
• Hardware-timestamp outbound market data at the exchange edge and retain packet-level audit trails.
• Run routine “arrival skew” audits across similarly situated co-located members.

The principle is simple:

fallback must not become a product

2. Private Network Path

This is the dark-fibre problem: the market does not become unfair at the matching engine. It becomes unfair in the cable plant. Boring? Yes. Important? Absolutely.

The technical malpractice pattern is:

authorized access path = documented, available, governed
private path = shorter / cleaner / less congested / selectively available
result = lower latency for selected participants

What I would look for:

• Maintain a live registry of every cross-connect, leased line, dark-fibre path, telecom provider, rack endpoint, switch port, and member entitlement.
• Reconcile physical cabling records with switch configs, optical-layer records, firewall rules, and member approvals.
• Measure path latency with exchange-operated probes, not member self-declarations.
• Look for unexplained latency clusters: members whose NSE-BSE or exchange-to-broker path is materially faster than the approved topology predicts.
• Audit exceptions: who approved the line, who installed it, who renewed it, who denied similar access to others.

The strongest evidence is not merely “this cable was fast”. It is the combination:

unauthorized or inconsistently approved provider
+ selective availability
+ lower-latency promise or outcome
+ exchange awareness or weak controls
+ trading-member benefit

What actually fixes it:

• Move all exchange co-location connectivity into an exchange-controlled meet-me-room model.
• Publish an approved-provider list and reject all unregistered physical/logical paths by default.
• Make every path commercially and operationally available to all similarly situated members under the same terms.
• Run periodic physical audits: port maps, patch panels, optical traces, rack access logs, and provider invoices.
• Publish a latency class matrix instead of pretending every cable is equivalent.
• Require independent sign-off for any cross-venue or cross-building connectivity.

The rule should be:

if a path can affect latency, it is a market-access product

3. Gateway Or TAP Weakness

This is the TAP problem: the access layer is where rules become real. A circular does not enforce itself. The gateway does.

The technical malpractice pattern is:

rulebook says: orders pass through controlled gateway
system reality: alternate path or weak control exists
market effect: throttles, risk checks, session controls, or fairness rules can be weakened

The danger is not only a full bypass. Even inconsistent enforcement is enough. If one path has different throttles, different risk timing, different session handling, or weaker logging, then the gateway has created a hidden market structure.

What I would look for:

• Compare order counts at every layer: member gateway, TAP, risk system, matching engine, drop copy, and surveillance store.
• Alert on any order that appears at the matching engine without the expected upstream control-chain evidence.
• Check whether throttles, OTR controls, kill switches, and pre-trade risk checks are applied identically across sessions and access methods.
• Require unique session IDs, algo IDs, dealer IDs, and gateway path IDs in every order event.
• Reconcile gateway config changes with approvals and deployment records.

What actually fixes it:

• Force all order flow through a small number of audited choke points.
• Make risk checks and throttles inline, not advisory.
• Cryptographically hash or sign gateway logs so they cannot be quietly rewritten after the fact.
• Give the regulator read-only access to normalized gateway telemetry, not only end-of-day reports.
• Use production canaries: test orders that verify throttles, rejects, and kill switches are working exactly where the architecture says they work.

The test is brutal:

matching-engine order
-> must have gateway proof
-> must have risk proof
-> must have entitlement proof
-> must have timestamp proof

If any proof is missing, the market has an access-control problem.

4. Spoofing And Layering

This is the PWAPL-type problem: the public order book is polluted.

The technical malpractice pattern is:

large visible order appears
-> market reads it as intent
-> smaller opposite-side trades execute
-> large visible order disappears
-> pattern repeats across symbols/contracts

What I would look for:

• Track large displayed orders that are repeatedly cancelled after opposite-side execution.
• Compare order size, displayed quantity, distance from current market price, time-to-cancel, and fill probability.
• Measure whether the same participant’s opposite-side executions improve while the large displayed order is resting.
• Detect layering: multiple visible orders at successive price levels that vanish after the intended opposite-side trade.
• Group by beneficial owner, broker, algo ID, terminal, and strategy family. Looking only at one order ID at a time misses the pattern.

A surveillance sketch:

spoof_score =
  low_fill_probability(large_orders)
+ fast_cancel_after_opposite_fill
+ repeated_same_direction_pattern
+ price_movement_or_queue_reaction
+ cross-symbol repetition

This should not be a dumb cancellation detector. Market makers cancel constantly for legitimate reasons. If surveillance treats every cancel as suspicious, it becomes noise and everyone learns to ignore it. The difference is intent pattern: large displayed interest that systematically helps opposite-side execution and then disappears.

What actually fixes it:

• Require robust algo IDs and strategy-level tagging so surveillance can connect related orders.
• Use order-to-trade ratio controls, but do not rely on OTR alone; spoofing can be low-frequency and still abusive.
• Build pattern surveillance over event sequences, not only static thresholds.
• Escalate from alerts to full replay: reconstruct the book, participant orders, market reaction, and post-cancel behavior.
• Penalize manipulative display behavior without punishing legitimate market-making quote updates.

The principle:

visible liquidity is data
fake liquidity is data poisoning

5. Technology-Governance Failure

This is the MCX-type lesson. It is not an HFT manipulation case on this record, but it matters because exchange software is market infrastructure.

The technical malpractice-adjacent pattern is:

critical trading stack
-> opaque vendor dependency
-> weak transition governance
-> delayed or incomplete disclosure
-> market continuity risk

What I would look for:

• Map every critical dependency: matching engine, clearing, risk, market data, surveillance, member gateway, vendor support, source escrow, and DR environment.
• Treat vendor transition dates, extension contracts, and failed migrations as market-risk events.
• Require outage, latency, and capacity incident reports to be specific enough for members to understand trading risk.
• Run independent DR and failover tests with member participation.

What actually fixes it:

• Keep source escrow, build reproducibility, and operational runbooks for critical exchange systems.
• Publish clear disclosure triggers for vendor transition risk, capacity risk, and repeated incident classes.
• Require independent technology audits before major platform migrations.
• Make exchange boards own technology risk as market-integrity risk, not procurement housekeeping.

The market does not care whether the root cause is code, contract, cable, or control room. If it changes who can trade, when they can trade, or what they can see, it belongs in market-integrity governance.

A Better Definition Of Market Malpractice

For electronic markets, “malpractice” should not be limited to insider trading or operator-style price manipulation.

A better definition:

Electronic market malpractice is any conduct or infrastructure failure that gives selected participants unfair timing, access, signaling, or control advantages in a market that is supposed to be common, transparent, and rule-bound.

That gives us a practical checklist.

1. Timing Fairness

Do all similarly situated members receive market data through equivalent paths, with controls against first-connect or lower-load advantages?

2. Access Fairness

Are co-location, telecom providers, cross-connects, leased lines, and gateway paths documented, audited, and available under equal rules?

3. Fallback Discipline

Are secondary servers and disaster/fallback routes used only as fallback, or have they become quiet primary paths for selected firms?

4. Order-book Integrity

Are large visible orders genuine trading interest, or are they repeated signals that disappear after opposite-side execution?

5. Gateway Integrity

Can any participant bypass throttles, risk checks, session controls, or access points?

6. Technology Governance

Are exchange software dependencies, vendor transitions, capacity limits, and outages disclosed and governed like market-integrity risks?

This checklist is more useful than shouting “ban algos”. Needless to say, that is a very low bar. Still, it is the bar most public discussion fails to clear.

The Engineer’s View

The hard truth is that speed markets are always unequal in some sense. One firm will have better code. Another will have a better NIC. Another will have a better FPGA team. Another will just have fewer cache misses.

That is competition.

The line is crossed when the market operator’s own infrastructure, access policy, or surveillance failure gives a selected participant an advantage that others could not obtain under the same terms.

better code = competition
better hardware = competition
better public product = competition
private pipe = problem
backup server as edge = problem
gateway bypass = problem
fake displayed liquidity = problem

This is why the NSE record matters so much. It is not a morality play about fast traders. It is a case study in how exchange microstructure can create unfairness at the exact layer most people never see.

If you want fair electronic markets, you cannot only regulate trades. You have to regulate the machinery that makes trades possible:

• market data dissemination,
• network topology,
• co-location access,
• gateway design,
• throttles and OTR controls,
• broker algorithms,
• surveillance,
• exchange software governance.

Overall, I don’t think the honest conclusion is “algos bad”. That is too easy, and mostly wrong.

The honest conclusion is more annoying: the malpractice is in the machinery.

And in a market measured in microseconds, the machinery is the market.

References

Footnotes

1. SEBI WTM order in the NSE co-location matter, 2019 ↩ ↩² ↩³ ↩⁴

2. SEBI remand order in the NSE co-location matter, 2024 ↩ ↩²

3. SEBI WTM order in the OPG Securities co-location matter, 2019 ↩ ↩² ↩³

4. SEBI AO order in the OPG co-location matter, 2025 ↩ ↩² ↩³

5. SEBI WTM order in the NSE dark-fibre matter, 2019 ↩ ↩² ↩³ ↩⁴ ↩⁵

6. SEBI AO order in the dark-fibre matter, 2022 ↩ ↩² ↩³

7. SEBI settlement order on NSE TAP architecture and network connectivity, 2024 ↩ ↩²

8. SEBI interim order in the PWAPL spoofing matter, 2025 ↩ ↩² ↩³

9. SEBI confirmatory order in the PWAPL spoofing matter, 2026 ↩ ↩² ↩³

10. SEBI order in the MCX software-contract matter, 2025 ↩ ↩²

11. SEBI notice of demand under Recovery Certificate No. 8780 of 2025 issued to OPG Securities, 2025 ↩

12. SEBI Committee on Fair Market Conduct report, 2018 ↩ ↩²

13. SEBI board memorandum on strengthening algo/co-location framework, 2018 ↩ ↩²

14. SEBI circular on OTR guidelines for algorithmic trading, 2020 ↩ ↩²

15. SEBI circular on algo trading in commodity derivatives, 2016 ↩ ↩²