At Trace Financial we’ve spent many years working on financial messaging projects with our clients. We’ve seen how, over the last couple of decades, the nature of the beast has changed, gradually but significantly.

The main challenges today are nothing like those that were faced in earlier times. Those who are not actually working at the coalface of messaging may not have registered the significance of the shift. In this article we’ll take a look at these changes, and see how a firm’s approach to messaging can be improved.

Misunderstanding financial messaging

The best way to misunderstand messaging is to think that it is a technical job concerned mainly with sending and receiving messages – the transport technology – which the IT department takes care of somewhere deep in the plumbing of the organisation.

Years ago the primary focus was indeed on transport issues – connectivity, protocols, guaranteed delivery and so forth. Today, except in the arcane world of high-frequency trading, transport issues are not the focus of attention. In the post-trade space they have, in the main, been addressed by various flavours of generic middleware which have reduced the message transport issue to a commodity. Today the problem lies elsewhere.

How financial messages have changed

Now let’s take a look at the messages themselves. In the early days, financial messaging mainly meant simple cash payments – the rest of the business communicated by hard-copy, fax and phone. Over time the range of messages expanded to cover more business areas and processes, first in treasury – FX trade confirmations for example – and then in securities, with corporate action announcements taking the prize for length and complexity.

Most recently OTC derivatives have far outstripped corporate actions as generators of long, complicated messages. Here is the core of the problem – the scope of financial messaging has expanded hugely and it now embraces immensely more complex business information than it used to. Addressing this combination of ubiquity and complexity is the critical business issue nowadays.

The people who really understand messaging in the context of complex business transactions (such as business analysts) need to have far more input into messaging projects. They need to be able to see and work directly with message standards, whether global, local or in-house.

A closer look at ‘complexity’ in financial messages

But before we go further into what may be needed as a solution, it is worth spending a minute to understand the nature of this ‘message complexity’. It is actually a product of (a) the sheer number of fields, blocks, or other intermediate ‘chunks’ in a complete message and (b) their internal structure – usually comprising numerous deeply-nested components with optional elements and alternatives at every level.

The number of fields in the message, combined with its ‘nesting depth’ can make it difficult just to know where I am in the message: to which Party in which leg of this structured product trade does this Name and Address data belong? In other words, the full meaning of a field is partly given by the individual item of data itself and partly by its position within the overall message structure. One needs as it were binoculars and a microscope working side by side.

As an aside, the widespread adoption of a common syntax – such as XML – may be a good thing in general, but it doesn’t solve the basic complexity problem. It’s rather like agreeing that henceforth everyone will communicate in English. All well and good, but I can still struggle to understand a very long and highly convoluted sentence, even though it conforms perfectly to English syntax. And of course there are still plenty of non-XML formats around, both in-house and in some very widely used third-party services – SWIFT MT messages for example.

In a final twist to the complexity story, any project that actually puts a global messaging standard to work in some specific arena will always specify a whole raft of restrictions, extensions or both. The Target2-Securities project’s use of the ISO 20022 standard is a current example of this.

Finding a solution

For a solution therefore the key to success (time to market, quality and cost control) is the possession of the strongest possible capabilities in the management of complex standards. These capabilities should ideally be delivered as a horizontal enterprise-wide service that can be called upon by any of the firm’s range of legacy middleware, and across any business unit.

Transforming and validating messages should not be seen as an obscure technical specialism of the IT team and one that changes according to whichever middleware is to be used; rather it should be viewed as a business critical strategic service that is central to the success of all projects in the post-trade arena, regardless of underlying transport technology.

So what requirements are implied here? As mentioned already, they include the ability to present complex messages and message standards in a business-meaningful way, for direct use by a business-facing analyst. This means providing the ability to replace a technical syntax with an easily-read presentation. This presentation should be the same across all underlying syntaxes.

The analyst should be able to move around a very long (in the sense of having many fields) and deep message structure rapidly and confidently, knowing where he or she is at any time.

A key point here is that there are qualitatively better and worse ways to model the same complex structure. Products for standards management typically offer a range of pre-built libraries defining various major standards, and it is important to be aware that a well-designed library will enable huge productivity gains, chiefly by maximising the re-use of components at all levels.

It should be easy to import and maintain standards. This means having tools to identify how changes to standards affect message libraries, validation rules and implemented mapping projects. Maintainability is one of the key issues in high-complexity messaging. The challenge for the enterprise is to rapidly develop durable, quality solutions that comply with changing, complex standards.

Our role at Trace Financial is to deliver technology that enables analysts to construct and maintain business rules, validations or transformations for any project, themselves. This means moving as far away as possible from the risky and time-consuming process of writing a specification (usually in a spreadsheet), passing it to a team of developers, and then hoping they will code it correctly by hand. That sort of approach may have worked in the old days, when payments were at the pinnacle of message complexity – but it won’t do any more.

In a nutshell the message of this article is: don’t think of financial messaging as a technical plumbing job for IT but as a critical business-centric aspect of nearly every post-trade project. Give your business analysts and their teams the capability to work directly with complex message standards, and master their complexity.