Overview

Overview

eMessaging is a long term replacement for the original SICS EDI interfaces for LIMNET (London Market) and JV (predominantly continental Europe). It consolidates the best of both of these earlier systems into one powerful common interface for processing messages. It uses the xml messages designed by ACORD for Reinsurance and Large Commercial (RLC), that have become de-facto standard for electronic messages in this field. Such messages can be loaded directly into SICS without any external parsing.

The focus in eMessaging is the loading and processing of ACORD RLC messages, but is is possible to load any XML message into the SICS eMessaging archive. These messages may be viewed, but cannot be processed.

The following ACORD RLC messages can be loaded and processed:

  • Tech Account
  • Claim Movement
  • Settlement
  • Placing (Post bind flow only)
  • Acknowledgement

SICS can also generate the following ACORD RLC messages:

  • Settlement
  • Acknowledgement
  • Tech Account
  • Claim Movement

The following ACORD RCL message types may be loaded and viewed in SICS, but no processing exists to support them -

  • Bordereau

The principal purpose of the eMessaging interface is to process the message so that it creates an update in SICS. For TechAccount messages, the main update is the creation of a new technical worksheet, and the balances and bookings therein. For Settlement messages the main update is the creation of a Settlement Balance Group.

Claim Movement messages create and update claims and claim worksheets.

eMessaging can also load and process messages generated by the LORS system operated by Lloyds in London.

ACORD Versions #

The development of eMessaging has focussed on the 2008-1 version of the TechAccount message, and on version 1.0 of the RLC Accounting and Settlement Quick Reference Guide (created by the eBot working group, and published in January 2008, known generally as the eBot guidlelines). However, due to the extensible nature of XML messages, all other versions of the ACORD TechAccount and Settlement message can be loaded and processed. Messages not produced in accordance with the eBot guidelines may not process as expected (e.g. eBot specifies that only a single subaccount is permitted per message. eMessaging too only supports single subaccounts per message).

When creating ACORD Acknowledgement messages, we generate a message in the same ACORD version as the corresponding TechAccount or Settlement message. If the TechAccount message is version 2003-1, so too will be the Acknowledgement created when the message is processed.

ACORD Codes and Reference Data #

An important feature of eMessaging is that when ACORD codes are used as reference data, we refer to ACORD code tables rather than SICS reference data tables. This should make maintaining the code tables much easier, as you only need to copy the new ACORD table into place rather than updating lots of SICS reference data tables. See System Administration Guide, chapter 8.13.7 for further details on how to update the ACORD code sets.

Life Cycle #

In an ideal world, all the messages you receive would match perfectly to SICS, and would process automatically without any intervention on the part of the user. Whilst we all hope the majority of messages will process automatically, in reality some messages will not match, and will need user involvement to progress the message. For these messages in particular, the life cycle status is all-important.

Messages received into the eMessage archive will have one of the following life-cycle statuses:

  • Unprocessed
  • Error
  • Validated
  • Processed
  • Discarded
  • Examined
  • Informational
  • Waiting
  • Waiting Approval
  • Cancelled

Normally a message will progress through the first four statuses, starting out as unprocessed and ending up as processed. For messages loaded and processed automatically, you may only ever see them as processed. We never delete messages from the archive; instead, we mark unwanted messages as ‘discarded’. You can restore discarded messages, at which point they revert to ‘unprocessed’. Examined messages are messages with errors that the user has already checked, but is unable or unwilling to process at this stage.

Informational status is used for messages that will not update SICS, Waiting messages are messages which cannot be processed until some other event in SICS has occurred - usually the completion of an earlier message. Waiting approval requires an external trigger to grant approval before the message can be processed, and Cancelled is used when a message reversal message is received before the original is processed. Both are cancelled instead of updating SICS.

The processing associated with the message is based on rules. These rules make the links between a message and SICS objects such as currency, base company and insured period. The rules also verify that the message is appropriate for the referenced SICS objects, and finally there are rules to dictate how the message is to update SICS.

If one or more rules detect a problem, the message is set to error or waiting status. When all the errors are cleared, the message is set to validated, and finally, when all the apply rules have completed, the message is set to processed.

Messages that are grouped together may be processed together. When one message in the group is processed, all the other messages in the group will be reprocessed. This feature is controlled by an eMessaging system parameter - Automatically reprocessed related messages. Related messages may be grouped by:

  • Group reference
  • FGU group
  • Referred UUId/SenderReference

Message processes #

Although eMessaging is a single interface to load and process messages into SICS, there are several detail differences in the way messages can be processed depending on message sources and markets. Such detailed differences are usually managed by a combination of parameters and rules, and whilst the parameters are all described in the relevant chapters of either the P&C manual or System Administration Guide, and the rules all include a long description, this is no substitute for a general overview of how these features operate.

This section will outline some of these details for the benefit of users. Topics will include:

  • Business to Business claims
  • London Market Claims
  • Lloyds Claims
  • Bulk Claims
  • Business to business settlements and pairing
  • London Market settlements and pairing

Business to Business claims #

This is the standard approach for handling claims. Unless the rule ‘ModifyClaimBookingBehaviourRule’ is in force, this is the method by which claims will be processed.

In the B2B model, a claim movement message carrying a claim payment amount will create a worksheet and will book the claim payment as a liquid amount. The amount may be taken directly from the message or may be created from FGU figures on the claim. When the corresponding TechAccount message is received, this will simply update the existing balance with a reference from the TechAccount message. The TechAccount will not create a new balance.

London Market Claims #

The London Market model for booking claims is only undertaken if the rule ModifyClaimBookingBehaviourRule is in force. It is usual to assign this rule to the XIS service provider business partner, if this method is required, so it only applies to messages sent from XIS. However, this rule could be assigned to the base company or to various brokers. For a client receiving both company and Lloyds messages from XIS, it is recommended that a separate base company be set up for the Lloyds syndicate, and that the ModifyClaimBookingBehaviourRule is assigned to the company market base companies only.

In the London Model, a claim movement carrying a claim payment will create a balance with an advised paid booking. This booking can either be a liquid booking or a reserve at the client’s choice. When the corresponding TechAccount is received, it will reference the earlier booking, and create two balances on a new worksheet - one to reverse the original advised paid, and a second to rebook the amount as paid claim.

Lloyds Claims #

Lloyds have one very significant difference to the company market with regard to claim movement messages. Unlike the company market, they send claim movement messages for claims on proportional treaty business. Unless this is handled correctly, it is likely claim bookings will be made twice - once from the claim movement, and again from the Treaty statement TechAccount. To resolve this issue, it is recommended that Lloyds claims messages are booked using the B2B model, and that claim movements linked to proportional treaty business are booked to the ledger. The eMessaging, Processing Option, system parameter ‘Transfer Lloyds Proportional Claim Bookings to Ledger’ controls this, and prevents the TechAccount treaty statement message from rebooking the same item.

Bulk Claims #

One feature of London Market claim processing is the use of bulk claims. In this concept, many claims movement payments are settled by a single TechAccount claim payment. It is particularly useful for low-value claims. All the claims in one bulk claim will be linked to a single business insured period.

XIS, who provide the messages in the London Market no longer support bulk claims for LIRMA, but they do for both Lloyds and ILU. eMessaging also supports bulk claim processing for both Lloyds and ILU.

In the Lloyds case, where we are booking payments on claim worksheets created from many claim movements, the single TechAccount claim signing message needs to find and update the adjustments already created. This is done by recording the bureau signing reference from the message in the London bulk reference on the adjustment when it is created, then searching for balances where the London bulk reference matches the corresponding reference on the TechAccount. For each balance found, we move the London Reference to the RESETT reference, and the London Bulk reference to the London Reference. This is later used in the pairing process against the remittance balance.

For ILU the process is more complex. XIS used to supply a message for the bulk claim itself, but this no longer provided, though the idea remains. The TechAccount message only refers to this non-existent bulk claim, and has no other indication that it is bulk related. They key is to record this bulk claim reference on to each of the component claims when the claim movement is processed. This stored as an additional claim reference (bulk claim reference) on the SICS claim. Also, when booking claim adjustments, we store the signing reference in London bulk reference, as we do for Lloyds (though the source is from a different element in the message).

Then, when the TechAccount is referenced and validated, if it makes a link to a claim using the bulk claim reference we set the message function to ‘bulk claim signing’. Like Lloyds, we look for adjustments matching the London bulk reference, but this time we create a reversal for each advised paid booking, and rebook it as paid claim. The rebooked amount will set the London reference as the signing reference from the message, ready to match the remittance balance when pairing is attempted.

The user can manually set a TechAccount claim signing to have message function ‘bulk claim signing’, by checking a tickbox on the Edit References window. (See section “Referenced SICS Objects - Tech Account Message” in chapter 16.4.3 View Message).

For both ILU and Lloyds there is a validation that checks the sum of payments found on the matching adjustments is the same as the balance amount of the TechAccount message. This rule, CompareBulkBookedAmounts, must be in force for the bulk processing to work correctly.

Business to Business settlements and pairing #

There is a significant difference between a settlement message received for B2B compared to the London Market, which is best summarised as follows:

In B2B, the settlement message is a basis for negotiation, in London, it is a done deal.

This difference is reflected in the distinct methods provided to process these messages. For B2B messages, individual Financial Account Items may be accepted or rejected. Those that are accepted must be linked to the technical balance to which they refer before a settlement balance group is created. Any remittance is created from the settlement balance group, and pairing takes place between the newly created remittance balance and the technical balance previously identified.

London Market settlements and pairing #

In London Market settlement processing, the settlement message will tell you the amounts that have already been updated to your bank account through central settlement. There is no basis for negotiation - in monetary terms, the transaction is complete before you get the message. So for London Settlements there is no scope to reject items, and there is no requirement for individual Financial Account Items to be linked to the corresponding technical balance before the remittance is created in SICS. Instead, the settlement message is used to create a remittance worksheet without creating a settlement balance group beforehand, and it is perfectly normal for the remittance balance to exist before the technical balance is created.

In this approach, the eMessaging processing option ‘Pair all balances created by eMessaging’ should be on, so pairing is attempted each time a new balance is created, regardless of message type. Half the time no paring will actually take place as this will be the first booking of the pair. Pairing will occur if a range of balances sum to zero, and have a common currency, London Reference and due date. The range of balances may simply be two balances - one technical and one remittance, or may be several technical balances matching one remittance.