A small percentage of your transaction reports are rejected every day and the team resubmits them the next morning. Is that acceptable?

What the gateway is and is not telling you

Transaction reporting under the European markets framework obliges an investment firm to report the details of each reportable transaction to its competent authority by the end of the following working day, either directly or through an approved reporting mechanism. Each report is a structured record identifying the instrument, the parties, the venue, the price, the quantity, the timestamps, the decision maker and the person or algorithm responsible.

The gateway validates that record. It checks that the fields are present and formatted, that the identifiers resolve, and that the report is internally consistent. What it accepts, it has accepted as a syntactically valid submission. It has not confirmed that the transaction is described correctly, that the population you sent was the whole population, or that the transactions you sent were reportable in the first place.

That is why the answer to the question is no, and why it is no for two separate reasons. The visible reason is that a stable rejection rate is a defect you have decided to staff rather than fix, and a control that depends on people clearing a queue every morning fails the morning they cannot. The more important reason is that the rejection rate is a measure of syntax, and the obligation you are actually under is accuracy and completeness.

The failures the gateway cannot see

There are three, and they are the ones that appear in enforcement action.

Under-reporting is the transaction that was never submitted at all. It generates no rejection, because nothing arrived. The causes are mundane: a new product line whose reportability nobody assessed, a venue connection whose feed into the reporting pipeline was never built, a booking model change that moved trades to an entity outside the extract, a file that failed silently. Nothing in the reporting stack will ever tell you about these, because from its point of view the day was quiet.

Over-reporting is reporting transactions that were not reportable, or reporting the same transaction twice. It is a breach in the same way as the opposite, because the authority's surveillance is looking for patterns in your activity and you have injected activity that did not happen. Duplicate reports arising from a replayed file are the commonest cause, which makes idempotency on submission a compliance control and not merely a hygiene measure.

Accepted-but-wrong is the largest category. Correct format, wrong content: the buyer and seller populated the wrong way round, a timestamp reported in the wrong precision or a shifted time zone, a price reported gross where net was required, a quantity in the wrong unit for the instrument, a decision-maker field carrying a desk identifier rather than the individual. Every one of these passes validation. Each is a misdescription of a transaction that an authority may rely on when reconstructing a market event.

Most recurring rejections are reference data wearing a costume

When you look into a steady rejection stream it is almost always identifiers rather than logic. Legal entity identifiers are the standing example: an entity counterparty must be identified by a legal entity identifier, the identifier must exist and be current at the time of the trade, and lapsed registrations are common because renewal is an administrative act somebody has to perform annually. The industry expression of the resulting rule — that you do not trade with an entity that has no usable identifier — exists precisely because the alternative is an unreportable transaction after the fact.

Natural persons bring a different problem, because they are identified through a jurisdiction-specific scheme with a defined order of preference, and the required identifier depends on nationality rather than on what your onboarding form collected. Instruments bring a third, since a reference identifier has to exist and be recognised for the instrument as at the trade date, which is awkward for newly listed and for over-the-counter instruments.

The engineering consequence is that reporting is downstream of reference data you do not control, and the right place to enforce it is upstream of the trade rather than at submission. A validation that runs at onboarding and at order entry — is this counterparty reportable today, is this identifier current, does this instrument resolve — converts a nightly rejection into a blocked order, which is inconvenient at exactly the moment when it is cheap to fix.

Fixing the report is not the whole obligation

Resubmitting a corrected report puts the record right. It does not discharge the separate obligation that attaches when you discover you have been reporting incorrectly, which generally requires notifying the authority of the error, its cause, its scope and its period, and agreeing what has to be reported again. Corrections are typically made by cancelling the incorrect report and submitting a replacement rather than by editing in place, so the authority retains a trail of what you told it and when.

That is why the eight-month mapping error in the follow-up is a materially different event from a rejected file. Scoping it requires you to identify every affected transaction over the whole period, which requires that you retained the inputs and the transformation as they were then rather than only the reports as they are now. A reporting stack that cannot reproduce what it would have submitted on a date six months ago cannot scope its own remediation, and the remediation is the part the authority is watching.

Three controls instead of one acceptance rate

Replace the gateway status as your primary measure with three tests that answer different questions.

Completeness reconciles the population. Take the trades from the front-office and booking systems for the day, apply the reportability logic independently of the reporting pipeline, and compare the resulting count against what was submitted and accepted. The independence matters: if the same code decides both what to report and what should have been reported, the comparison is guaranteed to pass. Where your authority makes the data it holds on your reports available back to you, reconciling against that is stronger still, because it is the only way to compare against what was actually received rather than what you believe you sent.

Accuracy samples the content. A rules-based check catches the mechanical cases — buyer equals seller, quantity of zero, a timestamp outside the venue's trading hours, a price implausible against the day's range — while a periodic manual review of a sample against source documents catches the semantic errors that no rule anticipates. This is the only control that finds the accepted-but-wrong category.

Timeliness measures against the deadline rather than against the batch. Reports are due by the end of the following working day, so the useful metric is the margin you had, not whether you made it. A pipeline that habitually completes shortly before the deadline has no capacity for a bad day, and the first bad day becomes a late submission.

Presenting the acceptance rate as reporting health is the trap the question is set to catch. It is a number that improves when your validation gets stricter and looks perfect on a day you report nothing at all.

A rejection is a report you know is wrong, which makes it the cheap kind: measure completeness against the front office and accuracy against source documents, because the reports the gateway accepted are where the breaches live.