The issue reached me through our CEO after HighLow questioned an unexpected DTCC bill. By then, commodity reporting had been running in production without the kinds of signals that normally sent us looking for a defect: the files were arriving, DTCC was accepting them, and the reports were coming back without validation errors. Yet DTCC was still treating some of those transactions as open.
HighLow was an Australian regulated trading provider running on our platform. We handled much of the technology and operational machinery required to report activity to ASIC through DTCC’s Global Trade Repository.
When valid reports still meant the wrong thing
Commodity reporting was relatively new for us. HighLow had introduced oil-based instruments, which moved those trades into a different DTCC reporting model from the FX and equity flows we already supported. We had to work through a new reporting specification, determine the combination of fields that applied to the instrument, regulatory context and operating model, test the resulting messages, and build the operational flow around them. The implementation went through DTCC testing, the validation problems were resolved, and the new reports went into production.
That process had done what we expected it to do: make the reports valid. It had not exposed a separate question—whether DTCC interpreted the state of the trade in the same way we did.
When we traced the billing back to the affected transactions, we found that several fields we had not needed in order to pass validation carried an important piece of meaning. They indicated that a transaction had matured. Without them, DTCC could accept and acknowledge the message while continuing to regard the trade as open, which in turn made those transactions billable.
Once we understood the mismatch, the remediation had to deal with both the past and the future. Existing transactions were already represented incorrectly inside DTCC, while every new report would continue creating the same state unless we changed the reporting logic. We worked out how to close the existing transactions retrospectively, identified the additional information DTCC needed, changed the reporting flow and took the revised behavior back into production. Six additional fields turned out to be necessary to represent completion correctly. The existing population of billable open transactions dropped sharply, and new commodity reports stopped recreating it.
The incident changed what we treated as proof that the integration was healthy. File delivery mattered. Validation mattered. An acknowledgement mattered. But none of those signals, by itself, proved that DTCC had arrived at the business state we intended to communicate.
From regulatory wording to system behavior
A later ASIC reporting change exposed essentially the same problem at an earlier point in the chain. This time, instead of discovering a semantic mismatch after production, we encountered ambiguity before there was even a clear implementation requirement.
The regulatory instruction referred to moving from snapshot reporting toward lifecycle reporting. DTCC used those same terms within its own reporting model, but they did not map neatly onto the regulatory wording. Our existing reports already contained lifecycle-event information, and we were already sending snapshot messages, so simply replacing one concept with another would not have answered the real question: which stages of a transaction did ASIC now require HighLow to report?
Before there could be an implementation plan, that question had to be separated from the technical one. HighLow’s compliance side was responsible for determining what ASIC required of the business. I could compare that interpretation with our current implementation, understand DTCC’s reporting model and make the consequences explicit, but I was not the legal authority for the customer’s regulatory position. Once that determination was clear, my responsibility was to translate it into system behavior that engineering could implement and operations could rely on.
The resulting change required us to represent more of the transaction’s lifecycle rather than only its final state. That exposed another constraint in DTCC’s processing model: multiple records submitted together were not guaranteed to be processed in the order in which we sent them. For some state transitions, that meant the correct records in the correct file were still not enough. The integration itself had to enforce the sequence.
We therefore separated dependent submissions and used DTCC acknowledgements to determine when the next state could safely be sent. The change was implemented and taken into production.
What correctness came to mean
By then, I had a different standard for what it meant for regulatory reporting to be correct. Getting a file successfully into DTCC was only one part of it. The customer’s regulatory interpretation had to map cleanly to system behavior, our messages had to preserve that meaning through DTCC’s own processing rules, and the state DTCC recorded had to be the one we intended.
The commodity incident had made that distinction concrete. The reports were valid, accepted and acknowledged. What they meant to DTCC was something we had to learn to verify separately.