At first sight this sounds simple enough; just get your admin system to generate a few XML messages and bung them on the SWIFT network surely? In this article Andy Smith, our architect, provides some technical insights into our experience …  

A recent project for a client required us to use SWIFT messaging via a service bureau. We set about investigating the world of SWIFT in more detail. It wasn’t long before we realised it wasn’t as straightforward as we first thought.

We divided up the task into two parts, the content and the actual generation of transmission of the message. The content was guided by the Re-Registration market practice group; all we had to do is match up the required fields with data items from our application. This had its own issues, where required message fields did not appear in the market practice (which was still in flux at this time), so suitable defaults were used to generate a valid message. And where the message standard didn’t support all the data fields we needed to send, we got around this by making use of the extension message fields.

Once we had mapped all our data fields to the message we set about creating the messages. The basic structure of a message consists of a message envelope which contains sender, receiver, network and security information, and of course the message payload itself. The details for the envelope were derived with help from the service bureau.

There were eight message types to generate of varying complexity and they are all defined by the ISO20022 message standards and schemas.

As we are a Microsoft .NET house, we use Visual Studio which contains some very useful tools for generating class structures from XSDs. Putting this to good use we obtained the message XSDs from the ISO20022 site (http://www.iso20022.org). The namespaces were altered to conform to the SWIFT namespace conventions, so for example; “urn:iso:std:iso:20022:tech:xsd:” becomes “urn:swift:xsd:”.

Through our contacts at SWIFT we were able to obtain the XSD for the message envelope, and generated its class structure. Now we have the building blocks to create the message.

To construct a message we create a message envelope and populate the ‘header’ section with sender, receiver, network, and security information. Next we create and populate the message payload and insert it into the ‘body’ section of the message envelope. The class structure is then serialized into a string. At this point we could save the string to a file and we would have a nice XML document, but it’s not quite ready to be put onto the SWIFT network. The message needs to be prefixed with the message length and LAU (Local Authentication) in the format:
+001335************************

Where ‘+’ is a unit separator character and ‘*’ is the LAU (24 characters), which is NULL if not used. The message length value is 6 characters padded with zeros and the length includes the LAU.

Now we are ready to send the message.

As a client, if a Platform does what it says on the tin, then it will give you a single view of your wealth; you can see exactly what you are worth at any given time while you and/or your Financial Adviser can easily keep on top of your portfolio and ensure it continues to meet your needs over the dramatic course of events that unfold throughout your lifetime. As an Adviser or Broker the Platform gives you the power to provide this fantastic level of service to your clients extremely cost-effectively.

Arguably, Platforms are a cornerstone of the Retail Distribution Review, apparently the FSA thinks so (see later).

But there is a problem … In-Specie Transfers aka Re-Registrations. This is the administration headache required to transfer control of the assets in a clients portfolio from a variety of different providers onto a single suitable Platform without having to sell and repurchase those assets. This can take days, weeks, months or, as legend has it, occasionally over a year! All this time, those assets are out of the market, can potentially attract Capital Gains Tax  and of course all of the parties responsible (Advisers, Brokers, Platforms etc) can suffer damage to their reputation in the market.

In terms of raw cost to an Advisory business, a recent survey from CWC Research puts the number at £600 to transfer each client onto a Platform!

Think about that again … if an Adviser has 250 Active Clients suitable for Transfer onto a Platform (this is a perfectly reasonable industry assumption) then it could cost their Firm £150,000 to Transfer those Clients onto that Platform while risking reputational damage as well! Yes, that’s £150K per Adviser. It’s equivalent to sacrificing a whole years income from each Adviser in order to reach the promised land. There’s no wonder the flow of assets onto Platforms has been somewhat slower than hoped.

Something just has to be done about Reregistration and both the industry and FSA have recognised this and are now acting.

I was even  inspired to draw a cartoon on the subject …

Eliminate the Re-Registration problem and watch legacy assets flow!

The answer is electronic messaging using the ISO 20022 standards (this steer was set by the UK Platform Group in the latter half of 2009) coupled with the automation of the various administrative processes involved.  Over the coming months, CBoxx and several of our key clients will be working at the coalface to help deliver this vision.

The industry is acting at present under the guidance of the unappealingly named but highly organised Tax Incentivised Savings Association (TISA). Last December I was privileged to attend the most recent meeting of the TISA Re-Registration Committee along with many of the great and good of the industry representing Platforms, Advisers, Fund Managers, Registrars, Third Party Administrators, Software Providers, Service Providers and Not-For-Profit Industry Organisations.

Also present was Steven Tully who stated the view of the FSA very clearly to all present:

• The FSA welcomes this initiative, and would prefer to see an industry-led solution to the re-registration issue;
• They are, however, clear that they wish to see re-registration happening across the industry as soon as practicable;
• If this does not appear to be happening, or if progress appears to be slow, they will move to take more prescriptive measures.

In short, if the industry doesn’t get on with it then the FSA will act decisively and we won’t like it! As they see it, the lack of an industry solution to Re-Registration could undermine the RDR.

Doubtless the journey ahead will be fraught but at present I can see no good technical reason why Re-Registration can’t be automated and that £600/client barrier removed. Perhaps the tricky part is that it will require a lot of co-operation between the parties concerned and there are conflicts of interest to be resolved.

When permitted and appropriate, we will continue to update this blog with updates on the progress we are involved with.

Video introducing the AIFA FFWD RDR Business Transition Academy. The CBoxx screens are about half way through (1 min 15s into it).
Play Video

For us the opportunity came out of the blue when we were contacted by NMG Consulting (who are project managing the service) to visit them and demonstrate our wares. All went well but it took a little while for us to get the green light while NMG surveyed the market to ensure they’d made the best decision, by which time we had about three weeks left to deliver what would more comfortably be a six week project.

With a firm hand on the scope we worked hard and delivered the goods bang on time. The Fee Calculations were updated, enabling us to model the most common RDR compliant Adviser Charge structures and then we worked closely with NMG, Adventis NMG and AIFA themselves to deliver a branded interface that looks great (in my modest opinion) and makes the job for the IFA about as easy and intuitive as it can be given the complexity of the task – three steps to model and transition your business.

The golden idea really came from Andy Smith one very early morning at Gatwick Airport as we sat waiting for the Edinburgh plane to visit Origo. With just three simple sliders, no keyboard necessary, the IFA is able to define and visually refine their client segments in seconds before moving onto the fun part, the What-If Analysis where they can play around and determine the best Service Proposition for both their clients and their business once the RDR lands.

We can’t claim a lot of credit for the rest of the AIFA FFWD Service which really does look like a remarkable and very valuable resource when viewed as a whole. We’d strongly urge any IFA out there who needs to get RDR-ready to take a very close look at it. And this is only the start, we’ve got a few more tricks up our sleeve for this service as it continues to mature.

Normal CBoxx projects are characterised by a steady progression from start to finish with the minimum of fuss and bother. Our client is kept informed and involved all the way through so that requirements, expectations, deadlines, budgets etc etc are agreed, documented and met. This one proved to be a little more challenging because there was not just a client to satisfy but apparently a whole industry; all of whom were tackling a single problem in their own way.

Our role was to convert a vision statement from Origo into a solid set of business and functional requirements sufficient for development of the service. We then provided key development and testing support and finally wrote the user manuals. The CBoxx industry model of the financial services world was brought into the project and withstood intense scrutiny, which is a relief.

Origo are the masters at providing structure, governance and discipline to projects of this scale and we have learnt a great deal from them. Along the way I met and worked with many great characters with a wealth of experience and strong opinions from all of the companies involved. Some of them have worked diligently at the Agency coalface for years, some are marketeers with a more strategic view, some are real detail people while others are happy to leave detail to others and simply throw gigantic curveballs straight into the midst of the debate (“So what do we need security for?”). In most cases I took on board the feedback but in some cases dug-in stubbornly so that yes, we do need security and the core communication concepts have been retained with just a little bit of sensible watering down.  

The vision was ambitious to say the least so I decided at an early stage that what everyone really needed was a visual concept to bash about. One dark night I sat down after the kids had gone to bed and created a screen mockup that drew heavily on the application of social networking ideas to the management (orchestration?) of common business processes between a large and diverse collection of co-operating companies from FTSE 100 giants down to 1 man bands. The combination of industry model and mockup worked well in providing focus and then stimulating debate and momentum for the project.

Following on from this initial creative spark was a seemingly endless series of reviews held in offices around the country and by teleconference. We produced copious amounts of very detailed documentation capturing everyones’ ideas and requirements then filtering and applying them to the core concepts, adapting them where necessary. Creativity had to give way to graft, application and attention to detail with each successive session.

After a few months the paperwork had built up alarmingly and meeting attendees were turning up with folders three or four inches thick. Some of the more diligent had even found time to read it all and then produced feedback documents nearly as thick -touche! On reflection I think we could have done this better and I am very keen to start the formal use of visual prototyping tools in future for projects of this scale. Essentially, everyone wants to see pictures and screens otherwise they get bored and start to disengage. There appear to be a number of tools out there that deliver the best of both worlds, at a price. Those after lunch sessions with twenty Use Cases left to review could become a tad tedious.  

A working compromise was found though and the specifications were nailed down shortly after Christmas. One of the really satisfying moments of the project was just after the development team had begun work. We’d had a few review sessions and the ideas were starting to stick in the heads of the developers and technical analysts. While working at my desk at Origo one afternoon I  could hear the gentle babble of breakout meetings and desk chit chat all around the office about how the service would work; how it would be transformed from the words and pictures into reality.

Towards the end there has of course been a few late nights, some tense moments and a palpable sense of relief as real people began user acceptance testing the service and approving it as fit for purpose. It’s going to be fascinating to see how the service survives, adapts and thrives out there in the wild and we’re one hundred percent confident that it will. Quite frankly, it was a buzz and I want to do it all again, now!

Presuming this to be just Hollywood trickery I was astounded to find out that it’s real, it’s called Microsoft Surface and costs about 10 grand for the table and developer license. Demos and prototypes for it are springing up all around us and you can go to Barclays ‘branch of the future’ at Piccadilly Circus and just have a play. I’m impressed.

In truth, I found the Barclays application worked well, the interface feels impressively natural to use but this app somehow lacked a little of the Wow! factor that I thought it might have.

It’s apparent to me that a table is indeed a natural environment for a financial adviser talking to his/her clients and that this kind of technology ought to really fit neatly into that space. There’s space for drinks to sit around the edge of the table and if it’s really smart the table can order the next round for you.

Accenture (Avanade) obviously think the same, have a look at the following …
.

I’m intrigued and will certainly be investigating further. A certain CBoxx product could be a great fit for an adventurous client …