Quick Summary
When a broker fails to execute your order the way you gave it, whether that means placing the wrong order type, letting a target sit unfilled, or blocking your exit entirely, the loss that follows is the broker’s to answer for, not yours. Across five real cases below, traders lost between ₹20,000 and ₹2.5 lakh to execution failures, and in every single one, the broker’s own order logs, call recordings, or contract notes ended up proving the mismatch. One trader’s account was even closed the moment he complained. Here is exactly what happened in each case and how the evidence held up.
A broker’s one job, once you have decided on a trade, is to execute exactly what you told them.
When the order that gets placed does not match the instruction you gave, whatever follows, a bad fill, a missed target, a forced exit, is not your trading mistake.
It is the broker’s conduct, and every case below shows a different way that failure can happen.
When You Say “Market Order” and the Log Shows a Limit Order
Rohan (name changed) was not a beginner. He traded actively and understood exactly how an order was supposed to work. When his broker’s dealer called with a view, Rohan gave the obvious instruction every time: “Execute at market price.” Fast, simple, no ambiguity.
Then he started asking a basic question after every trade: at what price did it actually fill? The answers wandered. “We sold at 70,” numbers that never quite lined up with what the market was doing at the moment he gave the instruction. So he pulled the order logs.
And there it was: he had said market order on a recorded line, but the system showed a limit order sitting in his account. The instruction he gave and the order the broker placed were two different things.
When the broker stalled on handing over the call recordings, Rohan filed a complaint specifically to force them out. He got them. On the recording, you can hear him clearly say buy at market price. In the log, a limit order. The mismatch sat right there in the broker’s own records.
And then the broker did something telling: annoyed at the complaint, they closed his account. “It’s our right,” they told him. Closing an account after a complaint does not erase the underlying conduct, and the retaliation itself became worth documenting on its own.
Underneath the execution failure sat the usual motive. Rohan was trading on the order of 1,500 lots in a single day. For roughly every ₹40,000 he earned taking all the risk, the broker earned about ₹40,000 in brokerage taking none.
When a broker’s income from your account rivals your own profit, the relentless activity is not a strategy, it is the business model. Put the recording next to the order log, and the case writes itself: here is what he said, here is what they did, and they do not match.
When Your Target Is Hit but the Order Never Fires
Rohit, from Odisha, did everything a careful trader is supposed to do. He held an index option toward expiry and set a target so his profit would book automatically the moment the price arrived.
On the day it mattered, the move he was waiting for came, the price reached his target, and the order simply never executed. He sat there holding a position that should have closed in profit, unable to exit cleanly.
By the time the option expired days later, his winning trade had quietly become a loss of roughly ₹20,000 to ₹30,000.
He acted immediately, emailing and calling the same day. What followed was a week of being managed rather than helped. Every call landed with a different executive, forcing him to retell the story from scratch each time, while the broker kept repeating the same line: we are checking with our technical team.
The matter dragged from the day his target was hit, past expiry, all the way to the tenth day, until he warned he would go to a consumer forum, at which point the phone rang back within half an hour.
And then came the part that gave the game away: the broker sent him exchange data that covered only the morning, using it to claim the price movement had happened earlier than his own timestamped screenshots showed.
A broker’s core job is to execute your orders, and when the price reaches the level you set and the order still does not trigger, that is an execution failure on the broker’s side, not a risk anyone signs up for.
Dragging a documented grievance for a full week, shuffling him between executives and going quiet, is its own separate failure, not a neutral inconvenience.
Sending only half a day’s data while his own screenshots showed the full picture was the broker curating the record to fit its story rather than handing over the neutral, complete exchange data that actually settles these disputes.
Rohit had timestamped screenshots of the order sitting at his target price, the demat high and low, his complaint ticket and email trail, and the partial exchange data the broker itself had sent, which, placed against the complete day’s data, exposed the gap in the broker’s version.
When the Screen Says “Rejected” but the Order Actually Filled
Karan builds trading algorithms for a living, precise, not someone who misreads a screen. He was managing a commodity options position near expiry, buying a far call and a far put, selling closer legs, and managing each position actively. He sent the orders through the broker’s app.
The app responded: “Market rejected.” He read that, accepted it, and did what any rational trader does when an order is rejected: assumed nothing had executed and moved on.
Then he opened the actual terminal. His stomach dropped. The far call had filled at ₹7,000. The far put at ₹100. Both orders his screen had declared rejected were sitting live in his portfolio. That day there was a known technical glitch across the segment, so his positions sat open and completely beyond his reach while the clock ran.
Late that night, at 11:15 PM, the broker stepped in and squared off two legs at a brutal price, booking roughly ₹1 lakh in losses, while the ₹7,000 call was left to expire worthless. Total damage, roughly ₹2.5 lakh.
When Karan wrote to the broker, their reply was honest in the worst possible way: “Our system converts your market order into a limit order before sending it.” Then they blamed the exchange. Karan had kept everything, screenshots of the rejected message, screen recordings, same-day emails.
Three separate failures sit inside this one incident, and each one belongs to the broker.
First, when a platform shows “rejected” while an order is actually executing, it gave Karan false information, and every decision he made after seeing that message, no monitoring, no hedge, no exit plan, followed directly from that false report.
Second, the broker admitted in writing that its system silently converts market orders into limit orders before sending them to the exchange, without notifying him, without asking, without any visible indication on his screen, which is not an execution feature, it is a unilateral override of a specific trading decision.
Third, once Karan discovered the positions were live and tried to exit immediately, the platform rejected his square-off attempts repeatedly during market hours, trapping his capital in open positions while the market moved, before the broker finally stepped in hours later at a distressed price.
A trader’s ability to exit a position is non-negotiable, and being blocked from it is not routine risk management, it is the consequence of the broker’s own failed infrastructure acting on someone else’s account.
When the Broker Books Your Profit but Leaves Your Loss Running
Arjun, a schoolteacher who trades carefully on the side, protected a two-leg options spread with a “secure exit” order designed to close both legs automatically.
The next day, the system closed his profitable leg at its pre-set level but left the losing leg running completely unhedged, forcing him to manually square it off to stop the bleeding. What makes this worth pursuing is that it was the second time the exact same thing had happened to him.
When you place a protective exit on both legs of a spread, the broker’s system has to apply that instruction consistently, both legs, by the same logic, at the same standard. It does not get to pick.
Closing the profitable leg while holding the losing leg is one-sided, selective execution, and when a system honours the side that ends your gain but ignores the side that would have limited your loss, that asymmetry is the broker’s conduct, not the trade going wrong.
The entire reason a trader sets a secure-exit order is so it fires as instructed, automatically, without babysitting the screen. If it fires only on the leg that books profit and quietly skips the leg that would have protected the trader, it has done the exact opposite of its job.
A broker’s easiest defence is “system glitch, one-off, sorry,” but that defence collapses the second time the same selective behaviour repeats in the same direction. Two identical “glitches,” both freezing the loss-capping leg while clearing the profit-taking one, stop looking random and start looking like how the system is actually programmed to behave.
Two Older Cases That Follow the Same Pattern
Rahul, who traded using a broker’s app, booked a ₹96,000 profit one day, only for the app to stop working the exact moment he tried to exit. The broker called and offered him ₹7,000 to stay quiet about the missing profit, while the contract note had already confirmed the gain existed.
He noticed the same pattern repeatedly: the app worked fine when he was in a loss, but froze whenever he was in profit. When he switched brokers afterward, roughly ₹87,000 sat stuck in the old ledger balance.
Separately, Raj had reduced a ₹2.5 crore loss down to ₹55 lakh in his Kotak demat account, then took another position that produced a ₹2.34 crore profit, netting ₹1.75 crore after deducting the earlier loss and taxes.
The broker withheld the entire profit, claiming the trades were unauthorised and cancelling them, despite an NSE contract note confirming every trade had actually gone through. He was preparing to escalate through NSE and SEBI SCORES with the contract note as his core evidence.
How to Get Your Money Back?
Every case above followed the same underlying path: a written, violation-specific complaint to the broker’s compliance officer naming the exact failure (false status, silent order conversion, blocked exit, selective execution, or outright profit cancellation), followed by SEBI SCORES if unresolved, then SMART ODR, then exchange arbitration where several of the outcomes above were decided.
The full step-by-step process, timelines, and what documents to attach at each stage are covered in our complete guide: file a complaint against your stock broker.
Did your broker’s system fail to execute your order the way you gave it, or block you from exiting once you noticed?
We match your order logs against your actual instructions, isolate exactly where the broker’s system failed, and build the complaint around that gap.
Register with us and get our support.
Frequently Asked Questions
No. The broker must execute the exact instruction you gave. A different order type, or a fill price that does not match what you instructed, is a failure on the broker's side and it is claimable, especially when your call recording and the order log can be placed side by side.
No. A broker is responsible for its own platform's ability to process client instructions, regardless of whether the glitch was segment-wide or exchange-side. The broker still made the decision on how and when to resolve the resulting position, and that decision is what gets scrutinised.
No, and doing so does not erase your underlying claim. A broker shutting you out immediately after a complaint is itself worth documenting as part of your case, since it points to retaliation rather than a neutral business decision.
Yes. Partial data that conveniently supports the broker's version is not the answer. The complete, second-by-second exchange data for the entire day is the neutral record, and insisting on the full day's data is a reasonable and often decisive demand.
Yes, a single instance is still claimable on its own. But if the same selective or inconsistent behaviour repeats, document both instances specifically, since a second occurrence directly undercuts any "one-off glitch" explanation the broker offers.
Add us as a preferred source on Google »
