For those not ‘in the know’ the Rueschlikon initiative was set up to establish a central platform for the automation of (re)insurance transaction processing post binding, in order to increase the speed, quality and transparency of transactions. This has started with a pilot focussed on ACORD accounting & settlement standards (eBot) with a limited rollout.

The goals for the Rueschlikon initiative are to:  replace paper by e-data for reasons of cost, speed and quality; avoid proprietary standards and connections and foster an industry solution for the benefit of our clients; enable the evolution of the (re)insurance business model and to enhance the reputation and attractiveness of the insurance industry for investors and other stakeholders.

The pioneers participating in the pilot phase are: Swiss Re, Munich Re, SCOR, Aon Benfield, Willis and ACORD.

Initially, Rueschlikon was to be achieved using a central service using the SWIFT (Society for Worldwide Interbank Financial Telecommunication) network; essentially a transaction hub. For various reasons SWIFT are no longer participating and with the removal of their network the pilot activities have become ‘peer to peer’.  The question ‘is peer to peer a viable option once the volume of participants grows?’ is now being raised, with proponents on both sides of the argument.

There are certainly some issues with hubs: who pays for the cost of build and ongoing maintenance? How many hubs do you have? Do you give a monopoly, like Xchanging have in London, to one provider? If competing hubs are set up, what will be the interconnectivity between hubs? If they don’t interconnect then it will be like only being able to make mobile phone calls to people on the same network as you!

In coming to a conclusion, the benefits of hubs need to be considered. What do hubs provide? They can: enforce data standards (as The Exchange does with its ACORD validation); provide a secure communications platform for the transport of messages; route data from the sender to receiver providing you correctly quote the receiver’s address; provide guaranteed delivery and non-repudiation and also a distributed architecture to deliver resilience. So, do these benefits counter-balance the issues? I don’t think so for the simple reason of cost. To build such a thing will be a large investment (hence the original reason for Rueschlikon using the SWIFT network) which will only pay off if significant transaction charges are levied. And let’s face it; does the insurance industry really need all those features? I don’t think so on that question either; we are not dealing with the critical banking transactions that traverse the SWIFT network. Clearly the pilot organisations, in removing SWIFT from the party, did not think hub functions were critical. They are operating ‘peer to peer’ using ACORD messages via their ACORD Gateways.

The advent of the concept of ‘Rueschlikon Light’ has potentially put the hub ‘in a new light’. ‘Rueschlikon Light’ was conceived as it is likely that a large number of cedants who account directly with their reinsurers, or smaller placing brokers dealing with the reinsurers, will not want to invest in a full blown ACORD infrastructure; they will want to continue to send the spreadsheets that they always have. This places a challenge on the reinsurers; having invested in an ACORD based data exchange, how to leverage that investment to process the numerous proprietary formats via a single upload process?

What is needed here is data transformation. This could conceivably be added as a ‘hub service’. If it were added as a service, is the resultant benefit sufficient to rescue the hub from ‘no business case obscurity’? Again, I don’t think so.

There are just simply other ways of achieving this data transformation without coupling it with the enormous expense of building and maintaining a hub.

For one such option watch this space……..!