What a Five-Year Order Audit Trail Has to Contain
The retention obligation, the fields an inspection actually asks for, and why "comprehensive logging" is not an answer to the question.
What does the audit trail obligation actually say?
NSE circular NSE/INVG/67858 of 5 May 2025 requires audit trail data to be available for at least five years, identifying the actual user and the user ID behind every order, with the exchange-assigned unique identifier present on each algorithmic order.
Two words in that sentence carry most of the weight. "Actual" rules out attributing a batch of orders to a shared integration account. And "available" is a stronger requirement than "stored": a record that exists but cannot be produced in a usable form within an inspection's timeframe has not met the obligation.
Why is "comprehensive logging" not an acceptable answer?
Because it is not an answer. Every compliance function has learned to read "comprehensive" and "full auditability" as placeholders, and a vendor evaluation typically stalls for weeks at exactly the point where those words appear.
The useful form is a field list: here are the fields written per order, here is the retention period, here is the export format, and here is what reconstructing a single order from eleven months ago looks like. That is a document a compliance officer can hand to an engineer without translating it, which turns a multi-week stall into a twenty-minute read.
The fields an inspection reconstructs an order from
| Field | What it has to be | Why it is asked for |
|---|---|---|
| order_id | The exchange order reference | The primary key an inspection works from |
| algo_id | The identifier assigned by the exchange | Establishes which registered algorithm produced the order |
| user_id | The actual end user, not a service account | Required explicitly by the circular |
| client_code | The broker's own client identifier | Ties the order to the account it was placed for |
| source_ip | The whitelisted static address it originated from | Demonstrates the access control was in force |
| ts_placed / ts_ack | Placement and acknowledgement, to the millisecond | Establishes sequence when two orders are close together |
| payload | Instrument, side, quantity, price, order type | What was actually requested, as opposed to what was intended |
Field names are illustrative of the shape rather than a specification of any particular system. What matters is that each of these facts is recoverable per order for five years.
When should the record be written?
Before acknowledgement, not after. A trail assembled from broker responses is missing precisely the orders whose responses were lost. These are the orders most likely to be the subject of a question.
This is the same reasoning that makes idempotency necessary at the order boundary. A submission can be accepted by the broker while the response never arrives. If the audit record is written on response, that order exists at the exchange and nowhere in your records, and no amount of retention fixes a record that was never created.
What does five years of retention actually cost?
Less than teams expect, because an order record is small and the volume is bounded by the rate limits the framework already imposes. The engineering difficulty is not storage. It is retrieval, schema stability and proving completeness.
Schema stability is the one that catches people. A field renamed in year two produces a five-year archive that needs two readers, and the second reader is written under time pressure during an inspection. Versioning the record format from the first day costs almost nothing and removes that failure entirely.
Completeness is the other. Being able to show that no order is missing from the trail is a different claim from being able to retrieve the ones present, and it is the claim an inspection is actually testing.
What should a broker ask a vendor about this?
For the field list, the retention period, the export format, and a worked reconstruction of one order from a date far enough back to prove the archive works. If any of the four comes back as an adjective, that is the answer.
It is a fair test to apply to any platform, including this one. The obligation sits with the broker under the circular, which means the broker is entitled to see the artefact rather than a description of it.
References
- NSE/INVG/67858, audit trail and operating standards, 5 May 2025National Stock Exchange of India
- Safer participation of retail investors in Algorithmic trading, 4 February 2025Securities and Exchange Board of India
- Idempotency keys for safe request retriesStripe API documentation
- audit trail
- compliance
- sebi
- record keeping
- engineering
- broker apis
Topics
Written by
The Stretus team writing on algorithmic trading, market structure and the systems that sit between a strategy and an exchange. Every claim about the platform links to the documentation that specifies it.
See these ideas running
The platform implements the workflow described here: strategies expressed as rules, backtested against historical data, paper traded, then executed through authorized broker APIs under platform-level risk controls.
Related reading
Where a Technology Vendor Sits in the SEBI Algorithmic Trading Framework
Who registers the algorithm, whose static IP it is, and who carries the liability, answered from the circulars, with every reference attached.
Static IP, API Keys and the Once-a-Week Rule
How authorised API access works under the framework, and why the once-per-calendar-week limit on changing an IP breaks naive failover designs.
The Architecture of an Automated Trading System
The six subsystems between a strategy definition and a filled order, what each is responsible for, and where the hard failure modes live.