Investigate why an order was allowed, blocked, filled or paused

What is wrong with logging as it is usually done?

It records events without recording decisions. A log that shows an order was rejected but not which check rejected it, or shows a strategy paused without the state that caused it, cannot answer the only question an investigation asks.

The gap becomes expensive at exactly the wrong moment. During an exchange inspection or a client complaint, the requirement is to reconstruct a specific order's path, and a system that can list events but not explain them turns a twenty-minute answer into a multi-week reconstruction.

What has to be retained, and for how long?

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 user ID behind every order, with the exchange-assigned identifier present on each algorithmic order.

Two words in that requirement carry the weight. "Actual" rules out attributing a batch of orders to a shared integration account. And "available" is stronger than "stored": a record that exists but cannot be produced in usable form inside an inspection's timeframe has not met the obligation.

What is observed

Why does evidence have to be connected rather than collected?

Because the question is always about a relationship. Which approval permitted this strategy; which check blocked this order; which credential submitted it; which indicator version it referenced. Separate logs hold all of those facts and none of the links between them.

Connected evidence is also what makes a rejection useful. A refused order carries the reason it was refused, so a pattern of refusals becomes a diagnosis, a limit set too tightly, a data feed going stale before the open, a segment permission that was never granted, rather than a mystery.

What does a broker's operations team see?

Order monitoring with latency and exceptions, strategy health, risk and exposure by dimension, and the approval and rejection record, inside the broker and admin control plane, scoped by role.

Module availability depends on tenant configuration, plan entitlements, connector readiness and deployment policy, so what a given deployment exposes is what that deployment enables rather than a fixed set.

What an investigation actually asks, and what answers it

How are exceptions handled rather than merely recorded?

An exception carries enough context to be actionable: what was attempted, which stage raised it, what the state was, and whether the condition is transient or terminal. Latency is tracked alongside it, because a slow path and a failing path present identically to a user.

The distinction between transient and terminal is what determines whether a human needs to be woken. A rejected order because a segment permission is missing is terminal and needs a person; a timeout on a retryable submission is transient and needs an idempotent retry rather than an alert.

Strategy health rolls those up per strategy, so a strategy quietly failing every evaluation is visible as a degraded strategy rather than as an absence of trades. This is the failure mode that otherwise goes unnoticed for weeks.

What does a broker have to be able to produce?

A reconstruction of specific orders, on request, within an inspection's timeframe. That is the real test, and it is a stronger requirement than having stored the data.

Two properties make it achievable. The record is written before acknowledgement, so an order accepted by the broker whose response was lost still exists in the trail. And the schema is versioned from the first day, so a five-year archive does not require two readers because a field was renamed in year two.

Completeness is the claim an inspection is really testing: being able to show that no order is missing is different from being able to retrieve the ones present, and only the first satisfies the obligation.