The approach
broker / dealers adopted early on in the development of application technology
was to develop product-centric systems. For example a, equity system fro
equities, a government systems for Treasury and a MBS system for mortgage backed
securities. As a result, today firm have multiple processing platforms, each supporting
specific products. The driver
behind this approach
was to create a template system that
could be cloned to support other product systems. For example if the base fixed
income system was the Treasury bond system,
it could be used as the foundation for corporate
and municipal bonds.
Extraneous or unneeded functionality
would be stripped while new functionality
unique to corporate and municipal bonds would be added. This allowed firms to avoid "reinventing the wheel" each time they introduced a new product and sped up the process as well.
The outcomes were many similar, but different processing systems, each requiring expertise, maintenance and support. For example some products settled one day after trade date, others five days after trade date while mortgage backed securities can settle up to six month after trade date. Differences were pervasive throughout the trade life-cycle as well as in reference data, trade entry, and asset servicing and reporting. This required systems developers and maintenance staff to have current and relevant expertise and knowledge of each product and the related processing functions. The bottom line is that this resulted in increased information technology costs and often delayed new functionality and updates to be applied, even today.
Firms are still struggling to find an approach to address this challenge. In the past 30+ years have seen many innovations in database design, programming languages and other advances that can provide benefits to financial services firms processing systems. But first they must reduce the number of product-centric systems to facilitate an efficient future environment. There are various alternatives; one is to build a new multi-product system to replace the product-centric systems. But the alternatives require a major effort in cost and resources. And have to be done in the current environment of keeping costs down.
What is your opinion about this?
The outcomes were many similar, but different processing systems, each requiring expertise, maintenance and support. For example some products settled one day after trade date, others five days after trade date while mortgage backed securities can settle up to six month after trade date. Differences were pervasive throughout the trade life-cycle as well as in reference data, trade entry, and asset servicing and reporting. This required systems developers and maintenance staff to have current and relevant expertise and knowledge of each product and the related processing functions. The bottom line is that this resulted in increased information technology costs and often delayed new functionality and updates to be applied, even today.
Firms are still struggling to find an approach to address this challenge. In the past 30+ years have seen many innovations in database design, programming languages and other advances that can provide benefits to financial services firms processing systems. But first they must reduce the number of product-centric systems to facilitate an efficient future environment. There are various alternatives; one is to build a new multi-product system to replace the product-centric systems. But the alternatives require a major effort in cost and resources. And have to be done in the current environment of keeping costs down.
Does this cause firms to less
competitive?
Are there other viable approaches available?