Regulatory Transaction Reporting Software Problems: The 7 That Cost Firms Real Money, and How to Avoid Them

Why does eligibility get scoped as a filter?

Whether a trade is reportable, under which regime, by which entity and on which side depends on facts that live in different places. The legal entity that faced the client. Whether the counterparty is financial or non financial and whether it sits above the clearing threshold. Whether the trade is intragroup. Whether an exemption applies. Whether you have agreed to report on the counterparty's behalf under a delegation arrangement.

In most firms that determination is a function inside a reporting tool with parameters somebody set two years ago, and it behaves like a filter: reportable trades pass through, the rest disappear. Nothing records why a particular trade was excluded, or which version of the rule excluded it.

That is the wrong way round, because the exclusion is the more sensitive decision. An incorrectly reported trade generates a break and gets worked. An unreported trade generates silence, and when the question eventually arrives, answering it means reconstructing a past configuration state, which nobody can do reliably.

The fix is to treat eligibility as a versioned decision recorded per trade, capturing the rule version, the inputs used and the outcome, including the negative outcome. That single change lets you answer why a trade was not reported without asking a person, and it lets you re run an entire month against a corrected rule to size the impact before deciding how to remediate. Ask any prospective developer how they would record a decision not to report. If they describe non reporting as an absence of data, they have never worked on a remediation, and you will eventually need one.

What goes wrong when you extract from multiple booking systems?

Reporting builds fail on the extraction layer more often than on the reporting layer, and the reason is that each booking system has its own idea of what a trade is and what happens to it over time.

What you find in practice: one system that models an amendment as a new record and another that updates in place, so lifecycle events are visible in one feed and invisible in the other. Allocations creating record chains where the relationship between parent and children is implicit rather than stored. A structured product booked as three legs in one system and one instrument in another, which changes what a single report should represent. Cancel and rebook used as a routine correction by one desk, producing a termination and a new trade where the regulation expects an amendment. Timestamps recorded in local system time with no offset, which matters when the deadline runs from execution.

The failure surfaces after go live as a break population that is not really a reporting problem. Your submitted values are faithful to the extract, and the extract was faithful to a booking convention nobody documented.

The fix is to profile each source before designing the reporting logic, taking a month of trades from each system and reconciling counts and lifecycle events against front office records. Then define a canonical lifecycle the reporting layer works from, and make each extractor responsible for mapping into it rather than having the reporting layer accommodate every dialect. Cancel and rebook patterns need identifying explicitly, because reporting them literally generates large populations of terminations that pair against nothing.

Why do submission and reference data feeds break after launch?

Two categories of ongoing breakage account for most post launch incidents, and neither is a code defect.

The first is schema and validation change at the repository. The EMIR refit moved reporting to ISO 20022 XML with a significantly expanded field set when it went live in the European Union in April 2024 and in the United Kingdom in September 2024, and validation rules keep being tightened afterwards. If rejections are handled as an operational queue rather than as an alarm, a day of submissions can sit rejected while everyone assumes they went.

The second is reference data. Legal entity identifiers lapse, and a lapsed identifier breaks pairing outright rather than producing a field level break. A counterparty's classification changes when they cross a threshold and nobody tells your static data team.

The fix is to monitor the acknowledgement, not the submission. Every submitted record needs a state machine that reaches accepted, and anything not accepted within the expected window raises an alert rather than waiting for the next reconciliation. Counterparty identifier status is checked before submission rather than discovered on rejection. Treat validation rule updates as a scheduled maintenance obligation with a named owner, because they arrive on the repository's timetable and not yours.

What happens when back reporting is not covered?

Almost every build in this category is scoped forward looking. Then a defect is found, and the question becomes what to do about the records already sitting in the repository.

The failure mode is a firm that can fix the rule going forward but cannot size the historical population. Without the ability to re run a corrected rule across history, the choice is between guessing at the scale and rebuilding the historical state by hand. The first is not credible in front of a regulator and the second takes months during which the population keeps growing.

There is a subtler version. A correction is applied by editing records rather than by submitting a documented amendment with a reason, so the audit trail shows values changing with no explanation. That is a control finding on its own, independent of the original error.

The fix is to build the historical re run capability as part of the core rather than as a remediation project bolted on later. If eligibility and enrichment are versioned rules over a stored trade population, sizing an impact is a query. Corrections then flow as documented amendments with a reason code, a link to the root cause and evidence of who approved them. Treat the back reporting exercise itself as a project separate from the forward looking build, because its scale depends on how long the error persisted rather than on your current volumes, but make sure the forward build gives you the tools to run it.

Should you build custom or configure what you already own?

If you are a smaller firm with modest volumes of vanilla trades under a single regime, do not build. Delegated reporting through a dealer, or a managed service, is cheaper and shifts most of the operational burden, and no board should spend seven figures to report a few thousand plain trades. Note the qualification, because it catches firms out: delegation moves the work, not the accountability. You still need reconciliation of what was reported on your behalf against your own records, a record of exceptions and their resolution, and periodic testing. Firms that delegate and then look away are the ones who find multi year discrepancies during an examination.

Keep a vendor for connectivity and submission routing regardless of what else you decide. DTCC Report Hub, LSEG UnaVista and S&P Global Cappitech all maintain repository connections and schema versions, which is ongoing work with no strategic value to your firm. Kaizen Reporting and Droit do different work again on independent testing and eligibility logic.

Build the layer underneath: eligibility, enrichment, identifier custody and reconciliation. That layer encodes your product set, your counterparty classifications and your booking model, which no vendor can see inside. Build when you report under more than one regime and maintain separate logic for each, when your break population is flat or growing quarter over quarter, when you cannot answer why a specific trade was not reported without asking a person, or when you report for clients under delegation.

How do hidden costs get into the quote?

• Regime count. Each regime has its own field set, deadlines and validation rules, and they disagree with each other deliberately. The second regime costs far less than the first only if the core layers were built to be reusable.
• Product breadth. Exotic and structured products need bespoke classification and valuation sourcing, and a single unusual product family can consume as much effort as a whole vanilla asset class.
• Booking system count. Each is a separate extraction with its own lifecycle dialect, and the profiling exercise that reveals the dialect is work before the work.
• Delegated reporting for clients. This adds an onboarding, permissioning and client reporting surface, plus a support obligation when a client disputes something you reported.
• Back reporting. Its scale depends on how long an error persisted, so it cannot be estimated alongside the forward build. Budget the capability, not the exercise.
• Control evidence. Testing artifacts, attestation packs and management reporting are a deliverable in their own right, and they are what an examination looks at.

What separates a build that works from one that fails here?

The ones that work make provenance explicit on every field. Reports demand values your front office never captures because they carry no economic meaning to a trader: venue identifiers, product classifications, clearing indicators, collateralisation categories. Somewhere in the pipeline defaults fill them, and a wrong default is worse than a blank because it reports confidently. Tag every outbound value as booked, derived by a named rule, referenced or defaulted. Running that report on day one produces an uncomfortable meeting and is the fastest route to better quality, because it shows which upstream system needs to capture which field.

They also own identifier lifecycle as a first class function: deterministic generation where you are the generating party, a register of received identifiers with source and timestamp, persistence across amendments and compressions, and monitoring of counterparty identifier status before submission. Most pairing failures are identifier problems rather than disagreements about economics, so fixing this first removes a large share of the break population.

And they give the break queue a memory. Cluster breaks by signature, meaning field, product, desk, counterparty and rule version, so forty items present as one cause with forty instances. The workflow becomes fix the cause, mass correct the instances, record the remediation. This is also the honest place for machine assistance: clustering, triage suggestions and drafting the remediation note for the file. The correction itself stays deterministic and reviewable, because you are amending regulatory records, and any tool proposing to fill missing report fields by inference should be refused outright.

The ones that fail work breaks as items forever. The same booking pattern from the same desk produces the same break shape every week, gets corrected individually, and reappears, so the queue rolls forward and grows. When a firm tells us its break count has been flat for a year, that is not stability. It is a cause nobody has been given the tools to find.