The Silo Effect

Most people agree that sharing is a good thing. Part of this means spreading your data through an organization, whether that's through a system like an investment book of record (IBOR), a data-management platform or shared feeds with common APIs. For technology, it means not developing in isolation, doubling up on the same work, and creating cross-platform inefficiencies through myopic, proprietary engineering strands.

I've spoken to many, many people about this process of breaking down silos over the past few years, for any topic that you can think of. But while everyone seems to say, yes, break down the silos, there may be a case for them in some instances.

The typical one here is the mergers and acquisitions business, which by its very nature, is heavily segmented. This is not only for resource reasons, of course, but operational and risk ones too ─ firewalls have to be in place to prevent insider trading as a start. But depending on the scale of the operation, keeping siloes in place can be beneficial too. One representative from a vendor I spoke to last week, who previously worked in compliance at major banks and small interdealer brokers, said his job was helped in some ways by the stratification of internal structure. It made it easier for his specific remit, he said, that everything was already pigeon holed neatly, and that personnel from one division didn't have access to systems or data from others ─ in essence, it provided a bottleneck.

The Plan
Assuming that a segmented approach is the way forward, though, is ridiculous. Nobody wants to return to the days where teams would double up on data feeds (and fees) to develop platforms that were broadly similar in approach, or tools that did essentially the same thing but had twice the impact on a budget sheet.

But from a risk perspective, without sufficient planning, breaking down silos also carries a danger to the business. As with most things, they key is asking what you really want to achieve from revamping infrastructure before you start doing it because enterprise is king. For example, are you attempting to save costs, are you trying to aggregate your data across various departments that could use a common feed, are you trying to create a holistic view of positions and trade information so as to better manage your exposure, or are you laying the foundations for complex counterparty risk systems that will require vast resources to run Monte Carlo simulations all day? Those are reasons why, and they have future scope in mind.

Technologists are faced with the impossible Cassandratic equation of servicing while savanting. Breaking down operational and technological siloes, while attractive, needs to be done with a clear goal in mind, lest it create more complexity and development corridors itself.

Most banks I speak to, particularly in the UK, talk about technology in the future tense. Of course they're developing now, but the budget doesn't just cover now, it has to cover years ahead, and factor in the idea that there may not be cash five years hence to undergo radical change. Technologists are faced with the impossible Cassandratic equation of servicing while savanting. Breaking down operational and technological siloes, while attractive, needs to be done with a clear goal in mind, lest it create more complexity and development corridors itself.

This week's side note: How about that Orange Business Services ─ Trading Solutions acquisition announcement, eh?