Large consultancies bring many things to a technology engagement in capital markets. They bring methodology. They bring headcount. They bring structured delivery frameworks that have been refined across hundreds of programmes in dozens of industries. They bring presentation decks that are genuinely impressive.
The one thing they consistently fail to bring is market knowledge. And in capital markets, that absence is fatal.
Not because market knowledge is the most important element of a technology programme. But because without it, you can't ask the right questions. And if you're asking the wrong questions from the start, everything that follows, the diagnosis, the architecture, the build, is built on flawed foundations.
What market knowledge actually means
When I talk about market knowledge in this context, I'm not talking about being able to discuss macro strategy or cite current credit spreads. I'm talking about operational fluency, which is an understanding of how the work actually happens on a trading desk under real market conditions.
It means knowing that the morning routine on a rates desk starts long before the open, with a set of specific information checks that happen in a specific order, and that any system that interrupts that routine, even slightly, will be worked around regardless of how technically superior it is. It means understanding that "real-time" means something fundamentally different to a rates trader than it does to an equities desk, and that a risk system that doesn't distinguish between the two has missed something important.
It means recognising that a "simple" requirement like "traders need to see their positions consolidated across asset classes" contains embedded complexity around netting conventions, valuation timing, and credit adjustments that can take months to surface in a methodology-driven requirements process, but would be immediately apparent to anyone who's worked a multi-asset book.
Without this fluency, the questions you ask in discovery are the wrong questions. Not wrong in an obvious way, they're usually logically reasonable questions to ask. They're wrong in the sense that they're addressed to the wrong level of the operation, they miss the commercially significant details, and they elicit accurate answers that don't tell you what you need to know.
The wrong question problem in practice
Here's how this plays out. A large consultancy kicks off a discovery phase. They conduct structured interviews with business stakeholders. They build a requirements model. They document what they've heard.
The stakeholders have been entirely honest. They've described their workflows accurately. The consultancy has captured what they were told and structured it competently.
But the questions were designed by generalists following a methodology framework, not by people with operational intuition about what matters in this specific environment. So, the interviews explored the stated workflow but not the actual one. They captured the information people volunteered but not the context that would have made some of that information significant. They produced a requirements document that is technically complete and operationally shallow.
The build follows the requirements. The system works. The desk doesn't use it in the way it was designed. Workarounds emerge. The programme is declared complete, and three years later someone is commissioning the next programme to fix what the previous one didn't solve.
The other failure mode: methodology as a substitute for understanding
There's a second failure mode that's less commonly discussed but equally damaging. It's what happens when an engagement substitutes process rigour for domain understanding.
Long discovery phases. Detailed process maps. Extensive stakeholder workshops. Comprehensive documentation at every stage. The consultancy can demonstrate, at any point in the programme, that the process has been followed correctly.
And yet the diagnosis remains shallow, because the process was designed to capture what stakeholders can articulate, not what requires domain expertise to surface. The maps are accurate representations of the stated workflow. They're not accurate representations of the real one. The system that gets built against those maps will work as specified. It just won't fit how the desk actually operates.
This is analysis as a substitute for understanding, not as a foundation for it.
What's actually required
Solving complex operational problems in capital markets requires people who can sit across the table from a senior trader or a COO and ask questions that reveal the things that don't appear in process maps or requirements documents. Questions that demonstrate an understanding of what matters commercially, what carries regulatory risk, what the real constraints are versus the stated ones.
That capability can't be manufactured through a better methodology. It comes from time spent in these environments, understanding them from the inside, developing the intuition that tells you which details are load-bearing and which are incidental.
It also requires a team model where business expertise and technical capability operate in the same team, with a shared understanding of what they're building towards. Not a business analysis function handing requirements to an engineering function, a team that can hold the commercial and technical perspectives simultaneously, throughout the engagement.
In capital markets, methodology is necessary but not sufficient. Market knowledge is what turns a technically competent delivery into one that actually works for the people using it.
The question they can't ask is the question that unlocks the real problem. Finding it requires knowing what to look for and that knowledge isn't in a methodology deck.