The old buy-versus-build debate in trading technology has been declared dead so many times it risks becoming a cliché. But at a recent A-Team Group webinar entitled How to move to a modern, component based trading architecture using a Buy AND Build approach, sponsored by interop.io, a sharper question surfaced beneath the familiar framing: if the boundary between commodity infrastructure and proprietary IP is constantly shifting, how do you architect for instability rather than optimising for where the line sits today?
The panel – Saurabh Srivastava, principal engineer at ClearStreet; Matthew McLoughlin, co-founder and strategic advisor at Prospera Fund Partners; and Bob Myers, chief product officer at interop.io – agreed that the binary choice between buying off-the-shelf platforms and building bespoke systems has given way to a hybrid model. Audience polling confirmed this: the largest cohort of respondents said they are actively pursuing a buy-and-build approach, with relatively few now committed to building alone.
Yesterday’s alpha, today’s commodity
The more interesting discussion was about where the line between buy and build actually falls – and how quickly it moves. “What was our secret sauce yesterday is today’s commodity hardware and software,” said Srivastava. He pointed to VWAP and TWAP algorithms as an example: a few years ago, firms built these in-house as differentiators; today they are off-the-shelf. Conversely, a risk model might start as a commodity purchase, but the moment a firm needs it to span equities, FX, and commodities with proprietary margin logic, it becomes IP again.
McLoughlin, who in a previous role as head of trading at Liontrust led a full operating model redesign – scaling from £5 billion to £50 billion in AUM – framed the decision in blunter terms. “If I’m going to be building something 15 other people have already built before me, it’s probably not where time and investment is best spent,” he said. “Keep thinking: am I adding real value to the market and our business by developing this in-house?”
Myers argued that AI is accelerating the shift without fundamentally changing the calculus. “AI is making it faster and cheaper to write code,” he said. “But it’s also true that for software vendors, it’s becoming cheaper and faster to innovate. Buy versus build was never really a cost decision – it’s a time and risk decision.”
The architecture that makes modularity work
If the boundary keeps moving, the architecture needs to accommodate that movement. Srivastava described a modern component-based stack as resting on three principles: context awareness, so that selecting an instrument in one panel automatically propagates relevant data across market data, news, and positions panels sourced from different systems; real-time state propagation via technologies such as Kafka or Aeron, replacing traditional request-response patterns; and a well-defined data schema using standards like Protobuf or Avro to ensure interoperability across the mesh of services.
Myers emphasised starting from the user interface rather than the plumbing. “Most applications are walled gardens,” he said. “Take out the blank piece of paper, look at the screens and personas, and work backwards from what they need.” He cautioned against the instinct to atomise every legacy application into individual components, arguing instead for identifying the largest self-contained functional units that can be reused and recomposed.
Standards matter here. FDC3, the open standard for financial desktop interoperability, emerged as a recurring theme. Myers cited one client firm that gives preferential treatment in vendor evaluations to any product that is FDC3-enabled – a mandate that, he said, “usually gets a lot of people’s attention.” McLoughlin reinforced the point: “That standardisation is really powerful. As simple as they sound, they always take a long time to get useful and into a form that everyone can use. But once they’re there, it helps the whole ecosystem.”
Lock-in, partnership, and the human element
When polled on the biggest barrier to adopting a component-based architecture, the audience spread fairly evenly across integration complexity, vendor lock-in, governance costs, and organisational resistance – with integration complexity edging ahead.
Myers acknowledged the vendor lock-in concern but reframed it: “There’s lock-in whether it’s vendor lock-in, key person lock-in if you’re building internally, or legacy technology lock-in. Those are risks regardless.” His advice was to invest energy in the selection process and partnership alignment rather than building abstraction layers designed to make vendors interchangeable. “If you’re going to go with an abstraction layer, go with an open-source one like FDC3. Don’t build it internally.”
McLoughlin, drawing on recent experience negotiating contracts with OMS, EMS, and data providers, stressed the human dimension. “You want a partner that’s going to evolve with you,” he said. “If your needs change or their solution doesn’t live up to what you needed, you need to be able to have adult conversations to change the contract and not have to go to court.”
AI as multiplier, not replacement
On AI’s role in the buy-and-build equation, the panel converged on a consistent message: it is a productivity multiplier, not an autonomous decision-maker. Srivastava was direct: “Do not use it as Google. AI, at least right now, for front-office trading systems, is not a great component.” He cited non-determinism and regulatory explainability as the core constraints, but highlighted the Model Context Protocol (MCP) as a potential game-changer for integration – enabling large language models to query disparate systems like Datadog, Snowflake, and internal platforms in a single workflow.
McLoughlin framed AI adoption as a layered process: data platform foundations first, then internal efficiency gains, then carefully validated external applications. “You can’t suddenly jump to external hyper-personalisation without sorting out the other layers,” he said.
Build the workflow, not the application
Asked for a single piece of advice for a CTO embarking on a modernisation programme, each panellist offered a distinct perspective. McLoughlin counselled thinking beyond day one: “You might have needs now, but think about what they might be in two, three, four years’ time.” Srivastava urged a shift in focus: “Don’t build applications, build a workflow or workspace. If you build a single beautiful application, the chances are the market will change before you finish.” And Myers returned to the human element: “Spend more time up front aligning the vision internally. If you have that story concretely in place, the rest of this becomes a lot easier.”
The underlying message was consistent: in a landscape where the line between commodity and differentiator refuses to stay still, the firms that will thrive are those that architect for movement rather than for a fixed destination.
Subscribe to our newsletter
