Compliance isn't a testing problem

That's exactly why it's a problem. 

It's one of the most reasonable things a compliance officer can say: "Compliance isn't a testing problem." They're right. Compliance isn't about whether a test script ran last Tuesday. It's about whether the transaction report you filed was correct, whether the position you held sat inside its limit, whether the number in your accounts can be trusted. Those are outcomes, not test cases.

But follow that thought one step further and it turns into a problem that's surprisingly easy to leave unexamined.

The outcomes you own come from a system you don't

Every one of those regulated outcomes is produced, at least in part, by your trading platform. The EMIR or REMIT submission, the limit utilisation, the valuation that feeds the close: they originate in Endur, Findur or Allegro, or a system like them. And that system changes constantly. Upgrades, patches, configuration tweaks, migrations. Each change is routine. Each one can also alter how an output is produced, without anyone deciding it should.

So, the integrity of a compliance outcome rests on a technical event that the compliance function never sees, and the technology function doesn't own the consequences of. That's the gap. It isn't a lack of testing. It's a lack of anyone treating the system layer as their responsibility.

Three lines of defence, one blind spot

Regulated firms typically organise responsibility along three lines. The first line trades and runs the systems. The second line, compliance and risk, owns the regulatory outcome. The third line, internal audit, assures that the controls work. It's a sound model, and it has one blind spot sitting right in the middle.

The change that can break a regulated output lives in the first line's plumbing. The accountability for that output lives in the second. And the evidence that a given change left the output intact tends to live nowhere at all. Everyone is doing their job, and the risk still falls between the desks.

"We test it" isn't the same answer

Ask how a change gets checked and you'll often hear "we test it." Usually that means someone worked through the screens after an upgrade and confirmed the system still opened and ran. That answers a different question. It tells you the software functions. It doesn't tell you that the reportable field is still populated the same way, or that the position still aggregates as it did last week. The logic that produces the regulated output sits below the screen, and that's exactly where a quiet change hides.

The reframe that closes the gap

The fix isn't more diligence from people who are already diligent. It's a change of framing. Stop treating assurance over the trading platform as discretionary IT housekeeping and start treating it as a standing regulatory exposure that the accountable owner manages, like any other risk on the register.

That turns one unhelpful question into one useful one. Not "did we test the upgrade?" but "when the system changed, what independently told us the output we're accountable for is still unchanged?" The first question belongs to IT and is easy to wave through. The second belongs to the person whose name is on the regulatory outcome, and it's much harder to answer with a shrug.

So yes, compliance isn't a testing problem. It's an outcomes and evidence problem. But the outcomes come from a system that changes, and until someone owns the evidence that change didn't break them, "it's not a testing problem" is precisely the sentence that lets the risk slip through. The firms that handle this well aren't the ones that test the most. They're the ones who decided the question was theirs to answer.

We explore that shift in full, and what it means for the people who carry the accountability, in our whitepaper: 'The cost of finding out later' by Jed Dalton.