The request usually arrives as a short email. One account number, one date, and a line asking for the complete history of a single order. What follows tells you whether the firm bought a trading platform or a liability. The firm that can export an ordered list of events, each with a timestamp, an actor and a before and after value, answers in a day. The firm whose platform stores only current state answers with screenshots and apologies.
Audit trail obligations do not come from one source. A regulated investment firm carries record keeping duties under its own regime, and in the EU those sit inside MiFID II and the order record rules attached to it. A bank or acquirer imposes its own version through the onboarding questionnaire, because it needs to know that a disputed deposit can be traced. And a client complaint sent to an ombudsman scheme turns into a demand for evidence that the firm executed what it said it executed. Three different readers, one underlying requirement: the past must be reconstructable without trusting anyone's memory.
What an audit trail has to prove
Strip away the vocabulary and a usable trail answers four questions about any event. What changed, when in a clock you can defend, who or what changed it, and what the value was before. A log line saying "leverage updated" fails all but the first. A record saying that operator ID 41 changed account 90114 from 1:100 to 1:500 at a stamped UTC time, with the prior value retained, survives an examination.
The trade lifecycle is the obvious part: order received, validated, routed, filled or rejected, modified, closed, with the price and the reason at each step. The part firms underestimate is everything around the trade. Credit and debit adjustments made by staff. Password resets and email changes on a client record. Symbol specification edits, swap changes, margin rule changes. Withdrawal approvals and who approved them. Rule engine decisions on a prop firm evaluation. When a client alleges that a firm moved the goalposts, the defence lives in that second category, not in the order book.
Retention length, format and reporting deadlines are set by the regime the firm is licensed under, and they differ. Take your own legal advice on which records your permissions require and for how long, rather than assuming the platform default matches your obligation.
Where platforms quietly fail
Four failure modes account for most of the trouble I see, and none of them are visible in a demo.
- State without history. The panel shows the current spread, the current group, the current balance. The previous values were overwritten, so no one can say when the change happened or who made it.
- Logs that are not tamper evident. If an administrator can edit or delete log rows through the same interface used to run the business, the log proves nothing in a dispute. Append only storage and separated permissions are the difference between evidence and a spreadsheet.
- Clock drift and local time. Timestamps written in a server's local time, or drifting because nothing synchronises them, make cross referencing with a liquidity provider or a payment processor guesswork. UTC, synchronised, everywhere.
- No export. A trail you can only read on screen is unusable at volume. Supervisors ask for files, and they ask for them in a shape their own tools can read.
Fragmentation is the fifth problem and the worst one. Many firms run a trading server from one vendor, a CRM from another, a payment layer from a third, and a marketing tool that also writes to the client record. Each keeps its own log in its own format with its own clock. Reconstructing a single client's history then becomes a manual join across four exports, which is exactly the work nobody has time for during a regulatory visit.
Questions to put to a vendor before signing
Ask for a sample export, not a feature list. Give the vendor a scenario: a client deposits, trades, has a position closed by the risk desk, disputes it, and later has the account group changed by support. Ask what the file looks like afterwards. The answer separates platforms that instrument every write from platforms that log a handful of headline events.
Then ask about access. Who can read the trail, who can export it, and can an administrator suppress entries. Ask whether third parties can be given a scoped, read only view, because auditors and, in some regimes, the supervisor itself will want one that does not require handing over a full admin account. Ask how long history is kept online rather than archived, and how an archive is restored, because a retention promise you cannot execute inside a deadline is not a retention capability. Firms running on a white label arrangement should ask a further question: if the relationship ends, do the records leave with the firm. Trails held by a vendor with no export clause become someone else's asset on the day of the switch.
Prop firms have a sharper version of the same problem
An evaluation firm is not usually holding client money against a market position, but it lives or dies on the defensibility of a rule decision. Every breach call needs the equity series, the rule parameters that were live at that moment, and the evaluation itself. Change a drawdown rule mid programme and, without versioned rule history, the firm cannot show which version applied to which trader. That gap turns a routine payout dispute into a chargeback, and a pattern of chargebacks turns into an acquirer conversation. Our Prop Firm CRM and the platform behind it record rule versions and the equity that triggered a decision for that reason: the answer to a trader's complaint has to be reproducible months later.
Build the trail before you need it
The cost of retrofitting is what makes this worth deciding early. History cannot be backfilled. A firm that discovers the gap in month fourteen has fourteen months of unreconstructable activity and no way to fix it. That is also the period a first supervisory review usually covers.
Treat the audit trail as part of the platform selection rather than a compliance afterthought, and check the same points that a bank's onboarding team will check when it looks at how your firm keeps records. The firms that get through examinations calmly are not the ones with the thickest manual. They are the ones who can answer a one line email with a file.
"The question that breaks firms is never 'show me your policy'. It is 'show me what happened to this order at 14:32, and who changed the account afterwards'."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- A usable audit entry answers four things: what changed, when in synchronised UTC, who changed it and what the value was before.
- Non trade events matter as much as orders: credit adjustments, group changes, withdrawal approvals and rule edits are where disputes are won or lost.
- Ask a vendor for a sample export against a real scenario, and check whether records leave with you if a white label relationship ends.
- History cannot be backfilled, so the trail has to exist before the first request arrives rather than after it.
Frequently Asked Questions
What records does a trading platform need to keep?
At a minimum the full order lifecycle plus the administrative events around it: account and group changes, credit adjustments, withdrawal approvals, symbol and margin edits and rule engine decisions. The exact scope and retention period come from the regime the firm is licensed under, so take your own legal advice rather than relying on a platform default.
Is a database backup the same as an audit trail?
No. A backup captures state at a point in time. An audit trail captures each change with its actor, timestamp and prior value, which is what a supervisor or an acquirer asks for when a single transaction is disputed.
Why do banks and acquirers care about audit trails?
Because their own onboarding and dispute processes depend on the firm being able to evidence a transaction. A firm that cannot trace a disputed deposit raises the risk rating applied to the account, which affects pricing and, in some cases, whether the relationship is offered at all.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.