Regimes differ in what they demand, but the shape repeats. Under the European transaction reporting regime, firms report executed transactions to their competent authority with a defined set of fields, including identifiers for the firm, the client, the instrument, the decision maker and the execution venue, plus precise timestamps. Derivative reporting regimes require both sides of a contract to be reported to a trade repository with matching identifiers. Other jurisdictions run their own versions with their own field sets. What they share is that the report is assembled from data that only exists at the moment of execution.
Capture at execution or lose it
The list of things that must be stamped onto the trade when it happens, not derived afterwards, is short and unforgiving. The instrument identifier as it stood at that moment. The client identifier, whether that is a legal entity identifier for a corporate client or the national identifier scheme the regime requires for a natural person. The identity of the person or algorithm that made the investment decision and the one responsible for execution. The venue. The capacity in which the firm acted. The timestamp, at the granularity the regime demands, from a clock synchronised to the required standard.
Every one of those degrades if you try to add it later. Instrument reference data changes. Client identifiers expire and get renewed, and a lapsed identifier is a rejected report. Staff leave and their mapping to a decision-maker code gets rewritten. A timestamp taken from a batch job is not the timestamp of the trade. This is why we treat these as execution-time fields in eTrader rather than as an enrichment step: the enrichment step is where reporting projects die.
Which reporting regime applies, which fields it requires and on what deadline is determined by a firm's own permissions and regulator. This describes the mechanism. Take your own legal and regulatory advice on scope.
Client identifiers are an onboarding obligation, not a reporting one
The rule that surprises new firms is that in several regimes a firm cannot execute for a client it cannot identify in a report. If the client is a legal entity that needs an identifier the firm does not hold, the trade should not happen. That turns identifier collection into an onboarding gate, which is a CRM problem, and it needs a renewal monitor because these identifiers lapse annually in the schemes that use them.
For natural persons, the required identifier is usually built from national identity data on a prescribed hierarchy, which means the onboarding form has to collect country-specific fields that a generic sign-up flow does not ask for. That connects reporting directly to KYC verification and to client categorisation, because the counterparty flags in a report follow the category the firm assigned.
Reconciliation is the control that actually works
The reason firms discover reporting problems late is that a submission accepted by a repository or an authority is not proof of a correct report. Acceptance means the file parsed. It does not mean every trade got reported, or that the values match the firm's books. The control that catches real problems is a three-way reconciliation run on a fixed cycle: the platform's executed trades, the reports submitted, and the acknowledgements received, compared by count and by value, with the breaks listed rather than summarised.
Firms should reconcile daily, keep the break list, and record what each break was and how it was resolved. When a supervisor examines reporting quality, the firm that can show a break register with resolutions is in a completely different position from the firm that can only show a submission log. The same logic runs through the regulatory reporting calendar: the evidence is the process, not the file.
Corrections, cancellations and the deadline
| Event | What the platform must produce | Common failure |
|---|---|---|
| New execution | A report with all execution-time fields stamped | Fields enriched later from stale reference data |
| Amendment | A correction linked to the original by its reference | A second new report instead of a linked correction |
| Cancellation | A cancellation carrying the original reference | Silent deletion in the firm's own records only |
| Rejected submission | An alert, a break entry and a resubmission within the deadline | Rejections logged to a file nobody reads |
The unique reference the firm assigns to each transaction is the thing that makes corrections possible at all. It has to be generated by the platform at execution, be unique for the lifetime the regime requires, and never be reused. Firms that generate it downstream, in the reporting layer, find that a replayed batch produces duplicate references and a repository full of records nobody can amend.
Outsourcing does not move the obligation
Most firms submit through a reporting service or a delegated arrangement rather than connecting directly. That is normal and sensible. What it does not do is transfer responsibility. The firm remains accountable for the accuracy and completeness of what is reported in its name, which means it must reconcile independently of its provider and must be able to show it did. Outsourcing arrangements themselves attract their own requirements in several regimes, covering oversight, exit planning and access to records, which we touched on in outsourcing rules for firms.
The position worth stating: a platform that cannot export a complete, timestamped, identifier-complete trade record on demand is not a platform a regulated firm should build on, whatever else it does well. Reporting is the one obligation where the firm's ability to comply is determined entirely by decisions the software vendor made before the firm ever signed a contract.
"You cannot report what you did not capture. Every reporting project that goes badly starts with someone trying to reconstruct identifiers six months after the trade."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Identifiers, capacity, decision maker and precise timestamps must be stamped at execution, because later enrichment uses reference data that has already changed.
- Where a client identifier is required to report a trade, collecting and renewing it becomes an onboarding gate rather than a reporting task.
- A submission accepted by a repository is not a correct report; daily three-way reconciliation with a break register is the control that finds real problems.
- Using a reporting provider does not move the obligation, so the firm must reconcile independently and evidence that oversight.
Frequently Asked Questions
Is an accepted submission proof that reporting is correct?
No. Acceptance usually means the file was well formed. It does not confirm that every executed trade was included or that the values match the firm's own records, which is why firms reconcile executions, submissions and acknowledgements against each other on a fixed cycle.
Why does trade reporting depend on onboarding?
Because several regimes require a valid client identifier in the report, and some identifiers must be renewed periodically. If the identifier is missing or lapsed the report is rejected, so collection and renewal have to sit in the client record rather than in the reporting layer.
Can a firm delegate reporting to a third party?
Firms commonly submit through a service provider or a delegated arrangement, but the regulated firm stays accountable for accuracy and completeness. It needs its own reconciliation and oversight evidence, and outsourcing arrangements carry their own requirements in several regimes.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.