Supervisors form a view of a firm long before anything goes wrong, and they form it mostly from submissions. A firm that files complete returns on time for three years is a firm that gets a phone call when something looks odd. A firm that files late, files amended versions, and answers data queries with a two week delay is a firm that gets a visit. The underlying business can be identical.
The obligations split into three kinds, and confusing them is what causes firms to build the wrong process. Periodic returns run on a fixed calendar. Transactional reporting runs continuously against activity. Event-driven notifications have no calendar at all and are triggered by something happening, usually at the least convenient moment.
The three shapes of obligation
| Type | Driven by | Typical examples | Failure mode |
|---|---|---|---|
| Periodic returns | The calendar | Prudential and own funds returns, audited financial statements, client money returns, complaints data | Missed deadline, or a return submitted from figures nobody reconciled |
| Transaction reporting | Activity | Trade and transaction reports, position reporting, record keeping obligations | Silent data quality decay across thousands of records |
| Event notifications | An event | Breaches, changes of control, changes to approved persons, suspicious activity reports, material outages | Nobody knew the event was reportable until later |
Each shape needs a different control. Periodic returns need an owner and a dated schedule. Transaction reporting needs reconciliation between what the firm did and what it reported, run regularly rather than at year end. Event notifications need trained staff who recognise a trigger, because the obligation usually starts when the firm becomes aware, not when it finishes investigating.
Periodic returns and the reconciliation behind them
Prudential returns tell the supervisor whether the firm still meets the capital and liquidity conditions attached to its permissions. Their frequency scales with the firm's size and permissions in most regimes. The number itself is only half the submission: a firm that reports adequate own funds but cannot explain the movement since the last return has answered the question and failed the test.
Client money returns work the same way. Where a firm holds client funds it is normally required to reconcile internally at a defined frequency and to report on that process periodically, with any shortfall funded immediately from the firm's own resources. The reconciliation is the control. The return is just the evidence that the control ran, and this is exactly where client fund segregation stops being a policy document and becomes a daily operation.
Complaints reporting is the one firms underestimate. The data feeds directly into how a supervisor sizes conduct risk, and a sudden change in volume or category invites questions the firm should be able to answer without a scramble. It is also the dataset most likely to be compared against public sources such as review platforms and ombudsman referrals.
Transaction reporting is a data quality problem
Regimes with transaction reporting obligations expect complete, accurate and timely reports of executed trades, often by the following business day. The difficulty is never the first submission. It is that reference data drifts: an instrument identifier changes, a new venue is added, a client's legal entity identifier lapses, and reports keep flowing with a defect nobody sees because nothing rejects. Firms subject to MiFIR transaction reporting in particular tend to discover the problem during a review rather than during the reporting.
The control that works is a reconciliation between the firm's own trade records and what the reporting mechanism actually received and accepted, run on a fixed cycle with someone accountable for the differences. That is a systems requirement, and it is the reason reporting capability belongs in the platform and CRM selection rather than being bolted on. A firm running the Broker CRM alongside its trading platform has one place where the trade record, the client record and the reporting extract agree, which removes the most common source of silent divergence.
Deadlines, frequencies and the exact returns required differ by regulator, permission set and firm size. This describes the categories, not your schedule. Build the calendar from your own rulebook and confirm it with your compliance adviser.
Event notifications and the clock you did not start
The obligations with no calendar cause the most damage. Material breaches usually have to be notified promptly once identified. Changes of control require prior approval in most regimes, which means the notification precedes the transaction rather than following it, a point covered in buying a licensed entity. Changes to approved function holders, significant outages, cyber incidents and suspicious activity reports all run on their own triggers.
The practical control is a register: every notification the firm has made, when the event was identified, when the notification went out, and who decided. A supervisor asking why an incident took eleven days to report is asking about the gap between those first two dates, and a firm with a register can answer it. A firm without one is reconstructing a timeline from email, which reads exactly as badly as it sounds. This is the same discipline that compliance audit trails serve elsewhere in the business.
Building a calendar that survives staff turnover
The version that holds up has a named owner and a named deputy per obligation, an internal deadline set ahead of the regulatory one, the data source recorded for each field, and a sign-off step by someone who did not prepare the file. It is reviewed after any change in permissions, because a variation of permission almost always adds returns nobody assigned to anyone.
What it should not be is a single person's knowledge. The most common cause of a first late filing in a growing firm is that the person who always did it left in the same quarter the firm added a market. Nothing failed except memory, and the supervisory record does not distinguish.
"Supervisors judge you on submissions long before they judge you on anything else. Three years of clean filings buys you a phone call instead of a visit."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Reporting obligations come in three shapes: calendar-driven returns, activity-driven transaction reports and event-driven notifications, each needing its own control.
- Transaction reporting fails quietly through reference data drift, so reconcile what was sent against what was accepted on a fixed cycle.
- Event notifications usually start their clock when the firm becomes aware, not when the investigation concludes, so keep a dated notification register.
- Rebuild the calendar after any change in permissions, since new activities add returns that nobody has been assigned.
Frequently Asked Questions
How often do prudential returns have to be filed?
Frequency depends on the regime, the permissions held and the size of the firm, and it commonly ranges from monthly to annually with larger or higher risk firms reporting more often. The requirement sits in the regulator's rulebook for your permission set, so build the schedule from that source rather than from a general guide.
What counts as a reportable breach?
Most regimes require notification of breaches that are material, and materiality is assessed against the rule breached, the client impact and whether the failure is systemic or isolated. Because the judgement is difficult under time pressure, firms usually document a materiality assessment framework in advance and record the decision either way.
Can reporting be outsourced?
Elements of it frequently are, particularly transaction reporting through an approved reporting mechanism and the preparation of financial returns. The regulatory responsibility stays with the firm regardless of who performs the work, so the outsourcing has to be governed, monitored and documented like any other critical function.
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.