Most systems get to approximately right and stop
Getting to the rupee took three rules that are not obvious, and they are the reason this console agrees with the terminal instead of nearly agreeing with it.
That is one window, measured against a dated report. It is how the system is built rather than a number that was tuned until it disappeared — but we would rather say “reconciled exactly on the reference window” than imply every window ever run lands on zero by itself. The full case study sets out how the three rules below were found, and what each one was worth.
None of them was visible from the requirements
-
A closing price only ever comes from the exchange
Never from an uploaded sheet. The terminal’s position export carries a market price column but no timestamp, so a mid-session export cannot be told apart from an end-of-day one, and its price is an unpublished intraday snapshot rather than a settlement figure. Using it is how a book drifts.
So: So the position file is archived, and every mark comes from the published bhavcopy.
-
An expiring option settles at intrinsic value
On its own expiry day an option is valued at what it settled for — zero if it is out of the money — not at the last price it happened to print at. Valuing one expiring out-of-the-money contract at its last trade put a four-figure error into the month.
So: That single rule is what makes the console agree with the terminal’s own position report.
-
A date window inherits the position, not the trades
A dealer long 500 lots on the 28th does not have those fills counted into a window that starts on the 29th. But the position is still there, and its P&L inside the window has to be measured from the price it was carried in at — the previous close — not from what was originally paid for it.
So: One synthetic carry-in entry is created per open position at that carry price, filtered exactly the way the window is. The trade log never shows them and nothing mistakes one for a deal.
Where a book quietly loses the last few rupees
Charges come off each dealer’s own slab
Rupees per ₹1 crore of turnover, by segment and by side, per dealer. The book figure is the sum of the per-dealer bills, never a desk-wide rate applied to a desk-wide turnover. A dealer with no slab contributes nothing rather than silently falling back to someone else’s, so the console and the invoice cannot disagree about what a dealer owes. A segment nobody traded produces no line at all, not a line of ₹0.
Every rupee is exact-decimal
There is no floating-point money anywhere in the system. On something whose entire purpose is to agree with another system to the paise, that is not fastidiousness — it is the requirement.
Daily settlement, the way the exchange sees it
Every position is squared at the close each evening and re-opened there, so today’s sell is matched against last night’s close rather than against a fill from three weeks ago.
What it deliberately does not do
We would rather you know this now. The last one is a real difference we cannot close from this side, so we name it rather than paper over it.
- It does not connect to your terminalIt reads the terminal’s exports, which keeps it out of your trading path entirely.
- It does not price anything from an uploaded sheetOnly from published exchange data. That single rule is why the book does not drift.
- It does not invent a closing priceIf the exchange has not published a day, that day is flagged as a gap rather than filled with a guess, and it resolves itself the moment the file appears.
- Open positions will not tie out to the paiseA terminal marks at the last traded price, an unpublished intraday snapshot, while this marks at the exchange settlement price. That difference is real, and we would rather name it than paper over it.
- It does not send emailSign-ups and password resets raise a request an administrator acts on inside the console.
Have a book that has to agree with someone else’s numbers?
Send us one session’s export and we will show you the book it produces.