There's a conversation I've had in almost every capital markets firm I've worked with. It sounds roughly like this.
Ask the Head of Trading Technology why the new platform isn't delivering what the business needs, and you'll hear something about requirements that changed three times during build, sign-offs that arrived late, and business stakeholders who approved a specification and then complained that the system didn't match what they imagined. Ask the COO or Head of Trading the same question, and you'll hear about a technology team that doesn't understand how the desk operates, systems that work perfectly in demos and fail under real market conditions, and a delivery process that felt like shouting into a void.
Both descriptions are accurate. Both are describing the same situation from opposite ends of the same gap.
This is the blame loop and it's not a communication problem.
What the blame loop actually is
The standard diagnosis of IT/business dysfunction in financial institutions focuses on communication. The solution offered is usually some variant of better stakeholder management, more frequent touchpoints, clearer requirements documentation, an agile process that brings both sides together earlier.
These interventions help. They rarely solve the problem.
The reason is that the blame loop isn't driven by poor communication between individuals who would otherwise collaborate well. It's driven by a structural gap, the distance between how commercial operations actually work and how technical systems are designed to support them.
Business operations in capital markets are built around judgment, speed, and context. A rates trader doesn't just execute against a model, they're continuously synthesising market signals, counterparty behaviour, risk limits, and desk strategy into decisions that happen in seconds. That synthesis is deeply contextual. It's also largely invisible to the systems that surround it.
Technical architecture, by contrast, is built around formal requirements: defined inputs, defined outputs, defined processes. It's designed to handle what it was told to handle. The problem is that "what it was told to handle" is a translation of commercial reality and that translation always loses something in the process.
The gap between these two worlds is where friction accumulates. The trader finds a workaround because the system doesn't quite fit how they work. The workaround becomes load-bearing. IT doesn't know it exists. Business normalises it. And the distance between what the technology was designed to do and what the organisation actually does grows, quietly, year by year.
Why the loop never closes
The blame loop persists because both sides have a rational incentive to maintain their position.
For business leaders, the narrative that technology failed is protective. It preserves the legitimacy of the commercial strategy while explaining why operational results don't match the investment. It also defers accountability; if the problem is technology, the solution is a technology project, and the business can wait for that project to deliver.
For technology leaders, the narrative that the business was unclear is equally protective. Requirements that kept changing aren't a delivery failure, they're a business failure. Specifications that were signed off and then disputed weren't the team's fault. The business knew what it was approving.
The political equilibrium is stable. The loop continues. And somewhere in the organisation, another workaround gets built.
What breaks the loop
I've seen the blame loop broken in a handful of organisations, and in every case the catalyst was the same: someone with enough authority and credibility to stand outside the loop and describe both sides of it accurately.
That description matters because the loop is self-reinforcing partly through each side's incomplete view of the other. Business leaders often genuinely don't know how their operational workflows look from a technical architecture perspective. Technology leaders often genuinely don't know how the desk operates under pressure, which decisions are high-stakes and time-critical, which workflows are ceremonial and which are genuinely load-bearing.
When someone maps the full picture, the real workflows, the actual decision paths, the genuine integration requirements the conversation changes. The blame loop requires incomplete information to sustain itself. It can't survive an accurate diagnosis.
The uncomfortable question this raises
If both sides of the blame loop are describing the same structural gap from different vantage points, the question is not which side is right. The question is: who owns the gap?
In most firms, nobody does. Business owns commercial operations. Technology owns the systems and the space between them, the translation layer where intent becomes architecture, belongs to both and therefore belongs to neither.
This is where transformation programmes consistently fail. They're structured to deliver a defined technical output, not to close a structural gap. Closing the gap requires genuine expertise in both the commercial domain and the technical architecture, operating together in the same team, with a shared understanding of what success actually means operationally.
The next time you're in a room where business is blaming technology and technology is blaming business, try asking a different question. Not "whose fault is this?" and not "how do we improve communication?" but "where exactly is the gap between what this operation needs and what the systems currently deliver, and why has it persisted?"
That question has a specific, observable answer. Finding it is the beginning of actually solving the problem.