The Times today featured…
…an article on the status of MiFID, the European-based Markets in Financial Instruments Directive. This is but the latest of a string of regulations targeted at the Financial Services industry over the last few years, following hard on the heels of the Risk Based Capital Directive (formerly Basel II). According to the Times
The City is split on whether MiFID is another Big Bang or a damp squib
but the impact on IT has been considerable regardless.
The first problem with regulatory changes, and MiFID is a prime of example of this, is that they almost always require changes in the ways information is handled across a range of disparate back-office applications and systems. MiFID is all about taking down trading barriers between EU-zone countries, harmonising regulations and improving market integrity with measures such as ‘best execution’. To achieve its goals, there are major impacts on the way information is gathered and disclosed, how client orders are handled and how trades are reported and recorded.
The second problem is that regulatory bodies are usually committee-based, and in the case of Europe in particular there are political factors and pressures to consider as well as procedural ones. With MiFID, requirements were drawn up initially by CESR (the Committee for European Securities Regulators) and then passed to in-country regulators for discussion and refinement.
These two problems force IT organizations into a difficult position. Change must happen, and by a specified date (November 1st 2007 in MiFID’s case), and the changes will involve having to make back-end applications interact differently – but these changes are ill-defined and subject to constant change as the debates, compromises and political imperatives continue.
It seems to me that this is an ideal example of one of the much-discussed benefits of SOA. IT seems to be in a lose-lose position – if it makes changes too quickly, the ground will shift as regulations change. If too late, then the company risks penalties or even more severe punishment. Perhaps the answer is to move over to a service-oriented architecture approach, where back-end applications are converted into a pool of reusable business services. Now, it becomes much easier to respond to the latest regulatory changes, and also to modify the situation as these regulations continue to become refined.
To me, this epitomises something I feel strongly about with regard to SOA. A key role of SOA is mitigating risk, whether from regulatory or compliance pressures or from the constant need for flexibility and change.