Accounting and Settlement: Technical Information

Accounting and Settlement: Technical Information Section 2 Message Structure Version:.0 Accounting and Settlement: Technical Information Section 2 Message Structure Page of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

Contents 2. Introduction... 3 2.2 Message structure... 4 2.2. Interpreting the diagrams (Note on UML notation)... 4 2.2.2 High level business context... 6 2.2.3 General message usage rules and assumptions... 6 2.2.4 Aggregates used in the messages... 8 2.2.5 Placing message... 3 2.2.6 Technical Account Message... 4 2.2.7 Settlement Message... 5 2.2.8 Claim Movement Message... 6 2.2.9 Acknowledgement Message... 7 2.2.0 DRI Message... 20 2.3 Reference definitions... 22 2.3. Reference Code generation and uniqueness... 23 2.3.2 Reference Code usage in the Settlement message... 28 2.4 Message cross referencing... 30 2.4. Acknowledgement Message Linking... 3 2.4.2 Message Grouping... 35 2.4.3 Resend Linking... 39 2.4.4 Reversal and New Entry... 39 2.4.5 Linking of Business Transaction Messages... 42 2.5 Business sectionalisation... 49 2.5. Contract section structure... 49 Appendix A Technical Account Splits... 54 Accounting and Settlement: Technical Information Section 2 Message Structure Page 2 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2. Introduction This section provides information relating to the ACORD messages. It identifies the hierarchy in which the data is displayed for the requirements of Accounting and Settlement usage. It also provides additional information, through more detailed definition requirements, for the main reference fields and how the new business messages will cross refer to each other for a single transaction and for subsequent transactions. Information is included on how contracts and their accounting information are represented in electronic messages. In order to do this, three criteria need to be fulfilled in a way that all parties interpret the information in the same manner: The hierarchical structure of a contract, the stakeholders interests, sub-divisions and the accounting breakdown need to be conveyed clearly and unambiguously Messages, the contract, relevant sub-parts and party interests need to be assigned reference codes so they may be identified and referred to. The various links required between related messages need to be defined explicitly and implemented using appropriate reference codes. Finally within this section are provided additional information and some business examples of the way in which contract sections will be advised within Accounting and Settlement. Note on ACORD version The information in this section is based on the ACORD RLC standard version 2005-2 and ACORD DRI standard version.2. An audit and update against the target version of the ACORD standards will be required at the time of implementation. Accounting and Settlement: Technical Information Section 2 Message Structure Page 3 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2 Message structure The information represented in ACORD messages has an inherent hierarchical structure. ACORD EDIFACT messages carry this information as flat data while the XML version allows this information to be transported as a hierarchical data structure. The diagrams that follow depict the inherent logical structure of the information as defined in the ACORD standard. They do not necessarily represent the physical structure of the messages that will be used. This will follow the structure as defined by the ACORD XML Schema. The following are the main exceptions where the logical structure departs from the physical message structure (XML Schema): Contract Section is shown as a child of Contract Endorsement is shown as a child of Contract Sub Account has logical meaning within Contract Market. However, the Sub Account aggregate and Sub Account Reference data element are modelled in each case as they appear in the message since the context of the message gives meaning to these elements. o o o In the Placement message model SubaccountReference is located at Contract Market as in the XML message structure. In the Technical Account message model the Sub Account aggregate is located at the top level of the message In the Claim Movement message model SubaccountReference is located at the top level of the message The diagrams are not intended to be exhaustive in terms of the data content shown, but rather to act as a convenient reference and explanatory vehicle for visualising the data content contained within each message. No significance should be attached to the order in which elements appear in the diagram. In all cases the ACORD standard should be referred to for the definitive message specifications. 2.2. Interpreting the diagrams (Note on UML notation) UML (Unified Modelling Language) Class Diagrams are used loosely in representing the static structure of the XML messages. They are a visual representation of the message structure only and are not intended to be used rigorously for systems development. The following describes some the notation used: Multiplicity Notation at the ends of the relationship lines indicate whether an Element or Attribute is mandatory or not and whether it can be repeated. This is shown as follows: 0.. zero or one Optional. Only one allowed * zero or more Optional. Repeats allowed one Mandatory. Only one allowed..* one or more Mandatory. Repeats allowed Note that the diagrams represent what is allowable by ACORD. For details on multiplicity guidelines within Accounting and Settlement refer to the detailed data dictionary. The XML messages include the following key entities: Accounting and Settlement: Technical Information Section 2 Message Structure Page 4 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

Elements containing data An Attribute associated to an Element Elements that contain no data (structural node) <HighLevelReference>0</HighLevelReference> Market Reform <ContractSection ContractReportingLevel="section_level"> <ContractPeriod> Data elements and attributes are represented in the diagrams as individual Classes to provide a visual representation of the structure, where they contain children or use a Code List. Data elements and attributes are represented as Class Attributes for convenience and simplicity In addition, the XML Schema concepts of a Sequence or Choice of Elements are represented as a Class where this aids the structural understanding. Refer to the table below for more detail on this. Represents an ACORD XML Schema structural element or one that represents an implied grouping or choice of child elements. <<XSDSequence>> <<XSDChoice>> <<XSDAny>> Any of the child elements can co-exist. Only one child element may exist (mutual exclusivity) Open extensibility allowed at this point in the XML Schema. If the name of the XSD element is in brackets, (carrierreference), the entity does not exist in the XML message but is used merely to assist in modelling the XML Schema. The sample diagram below provides further detail on the diagram conventions. Figure : Diagram conventions Accounting and Settlement: Technical Information Section 2 Message Structure Page 5 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2.2 High level business context Market Reform The diagram below provides the context of the ACORD RLC message structure in relation to the business representation of risk cover. Figure 2 : ACORD RLC representation of high level business Risk cover details are represented at the Contract level. Each Contract is uniquely identified by a Unique Market Reference (UMR) realised with the Broker Reference. Line of business sections of the Contract and different layers are represented at the Contract Section level. Each Contract Section is uniquely identified by a Contract Section Reference made up of a High Level Reference and optionally a Low Level Reference. Identification of Underwriters and their agreed portion of the risk are represented at the Contract Market level. Each Contract Market is uniquely identified by a Sub Account Reference. 2.2.3 General message usage rules and assumptions As the context allows, the following general rules and guidelines apply: Accounting and Settlement: Technical Information Section 2 Message Structure Page 6 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2.3. Carrier level message splitting Market Reform The ACORD XML messages reflect a logical structure allowing all aspects of the contract to be represented within a single hierarchical message as indicated in Figure 3. Figure 3 : Single Message for Contract Despite this message structure capability, separate messages are sent per Carrier reflecting only those parts of the contract relevant to the recipient Carrier as shown in Figure 4. References for all Contract Sections and Contract Markets remain unique and consistent across all messages representing a contract. Further splitting of the message into discrete messages may take place based, for example, on: different contract sections different currencies different instalments These business sectionalisation splits are dealt with in this section as paragraph 5. Figure 4: Carrier specific messages 2.2.3.2 Technical Account message splitting Under A&S processes, brokers are required to provide accounting entries in separate Technical Account messages for all transaction splits marked as Fundamental (Refer business design documentation). Data making up other split types may be supplied in a single Technical Account message. Data split information may be preserved by means of: the underlying message structured data capabilities using supporting documentation Accounting and Settlement: Technical Information Section 2 Message Structure Page 7 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

separate entries at line level Refer to Appendix A Technical Account Splits for detailed information on Technical Account message splitting. 2.2.4 Aggregates used in the messages Aggregates referred to in the messages are presented below. 2.2.4. RLC Party aggregates Parties defined in ACORD RLC messages are of the type shown in Figure 5 and Figure 6. FullNameAndAddress and OperationsDescription are only applicable to parties: LossPayee, OriginalInsurerOrReinsurer and OriginalPolicyholder. For an indication of the recommended fields for use in market implementations refer to the detailed data specifications in the companion spreadsheet. Figure 5 : RLC Party Type Accounting and Settlement: Technical Information Section 2 Message Structure Page 8 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

Figure 6 : Claimant Party Type 2.2.4.2 DRI Party aggregate Parties defined in ACORD DRI messages are of the type shown in Figure 7. Figure 7 : DRI Party Type Accounting and Settlement: Technical Information Section 2 Message Structure Page 9 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2.4.3 Tax Provisions aggregate Market Reform The structure of the Tax Provisions aggregate as used in the Placing message is shown in Figure 8. Figure 8 : Tax Provisions aggregate 2.2.4.4 Tax Applications aggregate The structure of the Tax Applications aggregate as used in the Technical Account message is shown in Figure 9. Figure 9 : Tax Applications aggregate Accounting and Settlement: Technical Information Section 2 Message Structure Page 0 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2.4.5 Amt aggregate Market Reform The structure of the Amt aggregate is shown in Figure 0. Figure 0 : Amt aggregate 2.2.4.6 Validator Results aggregate External validator details are incorporated in a new aggregate that has been tabled with ACORD as a Maintenance Request for the 2006-2 release. The structure as used in the RLC Acknowledgement message and the DRI RepositoryOperationRs message is shown in Figure. Figure : Validator Results aggregate Accounting and Settlement: Technical Information Section 2 Message Structure Page of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2.4.7 RLC Supporting Document aggregate Market Reform The structure of the Supporting Document aggregate is shown in Figure 2. Figure 2 : Supporting Document aggregate 2.2.4.8 Claim Movement extension Aggregate The structure of the aggregate for use in market implementations as an extension to the Claim Movement message will be determined in a later version of this document. Accounting and Settlement: Technical Information Section 2 Message Structure Page 2 of 63

2.2.5 Placing message Figure 3 : Placing message structure Accounting and Settlement: Technical Information Section 2 Message Structure Page 3 of 63

2.2.6 Technical Account Message Market Reform Figure 4 : Technical Account message structure Accounting and Settlement: Technical Information Section 2 Message Structure Page 4 of 63

2.2.7 Settlement Message Market Reform Figure 5 : Settlement message structure Accounting and Settlement: Technical Information Section 2 Message Structure Page 5 of 63

2.2.8 Claim Movement Message Market Reform Figure 6 : Claim Movement message structure Accounting and Settlement: Technical Information Section 2 Message Structure Page 6 of 63

2.2.9 Acknowledgement Message The Acknowledgement message may be used for responses, queries and reference updates: AcknowledgementTransactionType = "response" AcknowledgementTransactionType = "query" AcknowledgementTransactionType = "reference_update" Response and Query messages will contain references back to the original message. The message type being responded to is identified in the ReferredTransactionType. Reference update messages (AcknowledgementTransactionType = "reference_update") are standalone and do not contain the cross references back to any original message. Note that if a Response message contains Reference Update information it should not be rejected. ACORD also allows references to be updated within a response message. In this case the following applies: AcknowledgementTransactionType = "response" AND AcknowledgementStatus = "processed_with_data_modification". This mode will not be allowed in the London Market usage. The two modes (response/query and reference update are shown separately in Figure 7 and Figure 8 respectively. The aggregates Query and Response are mutually exclusive. Which is used will coincide with the value of AcknowledgementTransactionType. Insurer and Reinsurer related data items are mutually exclusive. The aggregate ValidatorResults is shown as using the Extension capability of the ACORD RLC message. It is anticipated that this aggregate will be included into the standard as a direct child of Response. Accounting and Settlement: Technical Information Section 2 Message Structure Page 7 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.2.9. Response / Query Acknowledgement Message Market Reform Figure 7 shows the data structure of the Acknowledgement message in the case of AcknowledgementTransactionType = response OR query. Figure 7 : Acknowledgement message structure Response and Query Accounting and Settlement: Technical Information Section 2 Message Structure Page 8 of 63

2.2.9.2 Reference Update Acknowledgement Message Market Reform Figure 8 shows the data structure of the Acknowledgement message in the case of AcknowledgementTransactionType = reference_update. Figure 8 : Acknowledgement message structure Reference Update Accounting and Settlement: Technical Information Section 2 Message Structure Page 9 of 63

2.2.0 DRI Message Market Reform Figure 9 : DRI message structure Accounting and Settlement: Technical Information Section 2 Message Structure Page 20 of 63

2.2.0. DRI rlc:referredobjects aggregate Market Reform The structure of the full rlc:referredobjects aggregate is shown in Figure 20. Figure 20 : DRI rlc:referredobjects aggregate Accounting and Settlement: Technical Information Section 2 Message Structure Page 2 of 63

2.3 Reference definitions Key to interoperability within the London Market is a common usage and definition of the references that define contract structure, message, party and transaction identification. This section provides clarification notes on key references that will be used in the ACORD messages in the London Market. Uniqueness limit defines the context within which the reference is guaranteed to be unique. Rules about generating the reference value and any pattern restrictions are also included. The definitions below are intended to clarify the ACORD standards not replace them. Note that the UMR, UCR and message Transaction References are case sensitive and may only include numerals [0-9] and upper case letters [A-Z]. All other references may include numerals [0-9] and letters of both cases [a-z, A-Z]. Additionally, these other references are case insensitive. In other words a code of ABC23G is the same as abc23g or any other combination of letter cases. Within A&S, the primary message linking mechanism is the message UUid. See Message Cross Referencing section for details. Accounting and Settlement: Technical Information Section 2 Message Structure Page 22 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.3. Reference Code generation and uniqueness Table : Reference code specifications Name Uniqueness Generation Data Type LM Facets ACORD Facets Data Pattern Comment UUId Universally unique Standard algorithm by message sender. GUID format (8-4-4-4-2). Generated by message originator. Transaction Reference Broker Contract Reference Other Party Contract References Transaction Originator's systems Whole market Within the Party's systems. Arbitrary code generated by the Transaction Originator Formatted code generated by Broker: - Position : Alpha (e.g. 'B' for Broker) - Positions 2-5: 4 digit Broker Code - Positions 6-7: Arbitrary alpha numeric string Arbitrary code generated by the Party. string - - [0-9A-Fa-f]{8}(-[0-9A-Fa-f]{4}){3}-[0-9A-Fa-f]{2} string len=35 len=35 Where used in Referred message aggregates usage and definition is as per referred message. string string len=7 len=35 [A-Z][0-9]{4}[0-9A- Z]{2} Refer to the tables below for further detail on the usage of this field in the case of the relationship between the Settlement message and the Acknowledgement message. Note that within DRI the term Transaction Reference is used to refer to the Claim Entry Reference and not to the message reference. Mandatory in London Market. The UMR remains the same throughout the life of the contract regardless of whether the Broker changes. Change words as per BG. Note: * Available, but not required in A&S usage of the Settlement message. len=35 len=35 Separate reference fields available for Cedent, Reinsurer, Insurer and Service Provider. Note: * Available, but not required in A&S usage of the Settlement message. ** Separate reference fields available for Cedent, Reinsuer and Insurer but not required in A&S usage of the Claim Movement, Accounting and Settlement: Technical Information Section 2 Message Structure Page 23 of 63

Name Uniqueness Generation Data Type LM Facets ACORD Facets Data Pattern Comment Broker Risk Reference Per Broker Arbitrary code generated by the Broker. Endorsement Reference Contract Section Reference - High Level Reference Contract Section Reference Low Level Reference Sub Account Reference Sequence Number (Sub Account) Broker Claim Reference Per Contract Arbitrary code generated by the Broker. string len=35 len=35 In the case of a Broker change the new Broker must use the original Broker's UMR. The new Broker may optionally include their Contract Reference the BrokerRiskReference. string Per Contract Code generated by the Broker. nonne gativei nteger Per Contract Section Code generated by the Broker. nonne gativei nteger Per Contract Market per Contract Section per Contract Per Sub Account, per Contract Market per Contract Section per Contract Whole market Arbitrary code generated by the Broker. Arbitrary code generated by the Broker Formatted code generated by Broker: - Position : Alpha (e.g. 'B' for Broker) - Positions 2-5: 4 digit Broker Code - Positions 6-7: Arbitrary alpha numeric string len=35 maxinclusi ve=99 maxinclusi ve=99 len=35 maxincl usive=9 9 maxincl usive=9 9 [0-9]{2} Start at 0 [0-9]{2} Start at 0 Used by G6 to hold a temporary Broker Reference where a UMR has not been assigned. See G6 manual Sequential in Senders for PL string len=35 len=35 Make note re sections. nonne gativei nteger string maxinclusi ve=99 maxincl usive=9 9 [0-9]{2} LM usage always = len=7 len=35 Note: * Available, but not required in A&S usage of the Acknowledgement message. Wording re Claim reference. Make international. Accounting and Settlement: Technical Information Section 2 Message Structure Page 24 of 63

Name Uniqueness Generation Data Type LM Facets ACORD Facets Data Pattern Comment Other Party Claim Reference Within the Party s system Arbitrary code generated by the Party. string len=35 len=35 Within Claim Movement separate reference fields available for Claim Settling Agent Reference, Bureau Signing Reference, Adjuster Reference, Lawyer Reference, Lloyd s Claims Office Reference, the Property Claims Office Reference and Surveyor Reference. Within Settlement message separate reference fields available for Cedent, Reinsurer, and Insurer but not required for A&S. Placing Entry Party Reference Within the Placing Entry System Arbitrary code generated by the Placing Entry system, string len=35 len=35 Claim Entry Reference Within the Party s system Arbitrary code generated by the Party. string len=35 len=35 Note: Transaction reference in the CLASS system. Separate reference fields available for Cedent and Broker Letter of Credit Reference Within Broker / Service Provider systems Arbitrary code generated by the Broker or Service Provider string len=35 len=35 Insurer / Reinsurer Contract Reference Within Insurer / Reinsurer systems Arbitrary code generated by the Insurer (or Reinsurer) string len=2 (Lloyds) len=5 (Others) len=35 Group Reference Per Message Type AND per Transaction Originator AND per Underwriter Arbitrary code generated by the Message Initiator. string len=35 len=35 For further information on Grouping refer to the Detail Business Design Document. Settlement Group Per Transaction Originator AND per Contract Arbitrary code generated by the Message Initiator. For further information on Grouping refer to the Detail Business Design Document. Party Contract Group Reference Per Broker / Cedent Arbitrary code generated by the Broker / Cedent. string len=35 len=35 Separate reference fields for Cedent and Broker and Service Provider. Accounting and Settlement: Technical Information Section 2 Message Structure Page 25 of 63

Name Uniqueness Generation Data Type LM Facets ACORD Facets Data Pattern Comment Financial Account Reference Financial Account Booking Reference Settlement Means Reference Binder Reference Per Transaction originator Uniqueness within the Financial Account Per Referencing party. Arbitrary code generated by the transaction originator. Arbitrary code generated by transaction originator, Code generated by transaction sender. Document Id Whole market Generated by Document Owner in GUID format (8-4-4-4-2) Document Reference Document Version Document originator. (May require qualification by Document Version for uniquness) Document originator AND Document Reference Arbitrary reference generated by Document Owner. Arbitrary reference generated by Document Owner. Broker Code For risks being processed in the London Market involving a London Broker the Lloyd s determined code set will be used. See BG wording. string len=35 len=35 Separate reference fields available for Cedent, Broker, Insurer, Reinsurer and Service Provider Refer to the tables below for further detail on the usage of this field in the case of the relationship between the Settlement message and the Acknowledgement message. string len=35 len=35 Refer to the tables below for further detail on the usage of this field in the case of the relationship between the Settlement message and the Acknowledgement message. string len=35 len = 35 Reference of the instrument/method to be used to settle the financial account (e.g. check number, LOC reference, etc). string len=35 len=35 string [0-9A-Fa-f]{8}(-[0-9A-Fa-f]{4}){3}-[0-9A-Fa-f]{2} Separate reference fields available for Cedent, Broker, Insurer, Reinsurer and Service Provider. Not required in the A&S usage for the TechAccount, Settlement, ClaimMovement or Acknowledgement messages. Within the Placing message only Placing Exchange Binder Reference applicable where it refers to a facultative reinsurance contract and a Placing Exchange is involved Refer section 5 string len=35 len=35 Refer Section 5 string len=35 len=35 Refer Section 5 nonne gativei nteger maxinclusi ve=9999 [0-9]{4} Completion of BrokerID Broker Agency should be a recogised LM code. Accounting and Settlement: Technical Information Section 2 Message Structure Page 26 of 63

Name Uniqueness Generation Data Type LM Facets ACORD Facets Data Pattern Comment Other Party Id Within ID Agency list Standard code. Coded reference source identified by ACORD Code Table 3055. ParentContractReferen ce string len=35 Whole market As per UMR As per UMR As per UMR Accounting and Settlement: Technical Information Section 2 Message Structure Page 27 of 63

2.3.2 Reference Code usage in the Settlement message Market Reform The following tables indicate the usage of party references in the different levels within the Settlement message and how these are referenced in corresponding Acknowledgement messages. <Settlement> <partyreference>-</partyreference> Party Transaction reference Identifies the Settlement transaction. Transaction reference assigned by the message originator. o CedentReference o BrokerReference o ReinsurerReference o InsurerReference o ServiceProviderReference <FinancialAccount> <partyreference>-</partyreference> Party Financial Account Reference Identifies the Financial Account. Where only one Financial Account exists, this reference may be the same as the Transaction reference. o CedentFinancialAccountReference o BrokerFinancialAccountReference o ReinsurerFinancialAccountReference o InsurerFinancialAccountReference o ServiceProviderFinancialAccountReference <FinancialAccountItem> <partybookingreference>-</partybookingreference> Party Booking Reference Identifies the individual Financial Account Item. Booking Reference is unique within the Party Financial Account Reference. o CedentBookingReference o BrokerBookingReference o ReinsurerBookingReference o InsurerBookingReference o ServiceProviderBookingReference Accounting and Settlement: Technical Information Section 2 Message Structure Page 28 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

<Acknowledgement> <ReferredSettlement> <partyreference>-</partyreference> Party Transaction reference Whole Settlement message being acknowledged. Mutually exclusive with Party Financial Account Reference. <partyfinancialaccountreference>-</partyfinancialaccountreference> Party Financial Account Reference Allows individual Financial Accounts to be acknowledged separately. Also provides referential context to the Booking Reference. Mutually exclusive with Party Transaction Reference. <partybookingreference>-</partybookingreference> Party Booking Reference May only be used in conjunction with Party Financial Account Reference Allows individual Financial Account Items to be acknowledged separately. (put into Table). Accounting and Settlement: Technical Information Section 2 Message Structure Page 29 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.4 Message cross referencing The linking of messages to each other within ACORD-based Accounting and Settlement follows one of the types listed below: Table 2: Cross reference types Relationship Examples Structural Technical Account links to a Placement message that defines the Contract and Market details applicable to the Technical Account. Placement message referencing a Supporting document. Referred Replacement Technical Account referencing the original Technical Account. Financial Account referencing the Technical Account it is releasing. Acknowledgement message referencing the original message it is acknowledging. Grouping Grouping of Financial Account messages for combined settlement. Grouping of Technical Account messages for combined processing. The ACORD RLC implementation guide provides information on data items to use for cross referencing. This section provides additional tabular and diagrammatic detail for clarity. Refer also to paragraph 3 - Reference Definition, in this section. The following standard data modelling principles apply to cross referencing: This section describes how messages are linked. Source and destination applications should be able to link the corresponding transactions or data structures represented in the messages identically. Only the minimum number of links required for unambiguous and consistent linking should be used for each relationship. Including additional references in the linking relationships could result in unnecessary conflicts. Information duplication across messages should be avoided. For example contract information that is available on a Technical Account is not included on the Financial Account. If this information is required it is the responsibility of the receiving party to look it up on the referred Technical Account (or its companion Placement). In the London market both the UUId and all relevant business references are mandatory in referred aggregates. Definitive linking of messages is based on the message UUId. However, where this is not possible in participant applications the business references may be used for linking. Where relevant this alternative linking is shown in the figures and tables that follow. Accounting and Settlement: Technical Information Section 2 Message Structure Page 30 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.4. Acknowledgement Message Linking Acknowledgement messages that are sent in response to or querying an original message are linked to the original message via the message UUId field. This is shown in Figure 2. Linking may be undertaken based on the Transaction references. This approach is shown in Figure 22. Original Message «messagelink» Acknowledgement Message (Response & Query)..* {response, query} acknowledgementtransactiontype acknowledgement 0.. referredtransactiontype placing uuid «messagelink» uuid referredplacing 0.. referredtransactiontype determines choice of: - referredplacing - referredtechaccount - referredsettlement - referredclaimmovement techaccount uuid «messagelink» uuid referredtechaccount 0.. 0.. «XSDChoice» ackmessagetype settlement uuid «messagelink» uuid referredsettlement 0.. claimmovement uuid «messagelink» uuid referredclaimmovement 0.. Figure 2 : Acknowledgement Message Linking UUId-based Accounting and Settlement: Technical Information Section 2 Message Structure Page 3 of 63

Original Message placing 0.. «XSDSequence» placingtransactionreference «messagelink» Acknowledgement Message (Response & Query) «XSDSequence» placingtransactionreference 0.. referredplacing Market Reform receiver in the Acknowledgement message determines w hich party transaction reference is receiver acknowledgement used: - Broker Reference - Cedant Reference acknowledgementtransactiontype - Insurer Reference - Reinsurer Reference - Service Provider Reference referredtransactiontype referredtransactiontype 0.. «messagelink» 0..*..* {response, query} 0.. determines choice of: - referredplacing - referredtechaccount - referredsettlement - referredclaimmovement techaccount «XSDSequence» techaccounttransaction Reference «messagelink»..* «XSDSequence» techaccounttransaction Reference 0.. referredtechaccount 0.. 0.. 0.. «XSDChoice» ackmessagetype settlement «XSDSequence» settlementtransaction Reference «messagelink»..* «XSDSequence» settlementtransaction Reference 0.. referredsettlement 0.. claimmovement 0.. «XSDSequence» claimmovementtransaction Reference «messagelink»..* «XSDSequence» claimmovementtransaction Reference 0.. referredclaimmovement Figure 22 : Transaction Reference-based Acknowledgement Message Linking Table 3 provides the detailed specification of the Acknowledgement message linking. A broken horizontal line indicates scenarios in which alternative relevant party transaction reference can be used in a link. Otherwise, the link comprises all of the references. Table 3 : Acknowledgement Message Link Specifications Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage PL R05 TransactionUUId /UUId R47 ReferredPlacingUUId /ReferredPlacing/UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=placing ] ACK Placement message Acknowledgement Figure 2 Accounting and Settlement: Technical Information Section 2 Message Structure Page 32 of 63

Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage PL TA TA CM R00 CedentPlacingTransactionReference /CedentReference R068 BrokerPlacingTransactionReference /BrokerReference R4 ReinsurerPlacingTransactionReference /ReinsurerReference R2 InsurerPlacingTransactionReference /InsurerReference R05 TransactionUUId /UUId R09 CedentAccountTransactionReference /CedentReference R020 BrokerAccountTransactionReference /BrokerReference R05 TransactionUUId /UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=placing ] R00 CedentPlacingTransactionReference /ReferredPlacing/CedentReference [ Acknowledgement@receiver=cedent ] R068 BrokerPlacingTransactionReference /ReferredPlacing/BrokerReference [ Acknowledgement@receiver=broker ] R4 ReinsurerPlacingTransactionReference /ReferredPlacing/ReinsurerReference [ Acknowledgement@receiver=reinsurer ] R2 InsurerPlacingTransactionReference /ReferredPlacing/InsurerReference [ Acknowledgement@receiver=insurer ] R32 ReferredTechnicalAccountUUId /ReferredTechAccount/UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=technical_account ] [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=technical_account ] R09 CedentAccountTransactionReference /ReferredTechAccount/CedentReference [ Acknowledgement@receiver=cedent ] R020 BrokerAccountTransactionReference /ReferredTechAccount/BrokerReference [ Acknowledgement@receiver=broker ] R33 ReferredClaimMovementUUId /ReferredClaimMovement/UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=claim_movement ] ACK ACK ACK ACK Placement message Acknowledgement. Relevant Transaction references are mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Figure 22 Technical Account message Acknowledgement Figure 2 Technical Account message Acknowledgement. Relevant Transaction references are mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Figure 22 Claim Movement message Acknowledgement Figure 2 Accounting and Settlement: Technical Information Section 2 Message Structure Page 33 of 63

Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage CM FA FA FA R035 CedentClaimTransactionReference /CedentReference R036 BrokerClaimTransactionReference /BrokerReference R05 TransactionUUId /UUId R056 CedentFinancialAccountTransactionReference /CedentReference R057 BrokerFinancialAccountTransactionReference /BrokerReference R05 TransactionUUId /UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=claim_movement ] R035 CedentClaimTransactionReference /ReferredClaimMovement/CedentReference [ Acknowledgement@receiver=cedent ] R036 BrokerClaimTransactionReference /ReferredClaimMovement/BrokerReference [ Acknowledgement@receiver=broker ] R3 ReferredSettlementUUId /ReferredSettlement/UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=settlement ] [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=settlement ] R056 CedentFinancialAccountTransactionReference /ReferredSettlement/CedentReference [ Acknowledgement@receiver=cedent ] R057 BrokerFinancialAccountTransactionReference /ReferredSettlement/BrokerReference [ Acknowledgement@receiver=broker ] R3 ReferredSettlementUUId /ReferredSettlement/UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=settlement ] ACK ACK ACK ACK Claim Movement message AcknowledgementRelevant Transaction references are mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Figure 22 Settlement message Acknowledgement Figure 2 Settlement message Acknowledgement. Relevant Transaction references are mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Figure 22 Acknowledgement of Settlement per Financial Account R060 CedentFinancialAccountReference /FinancialAccount/CedentReference R06 BrokerFinancialAccountReference /FinancialAccount/BrokerReference R095 ReinsurerFinancialAccountReference /FinancialAccount/ReinsurerReference R060 CedentFinancialAccountReference /ReferredSettlement/CedentFinancialAccountReference R06 BrokerFinancialAccountReference /ReferredSettlement/BrokerFinancialAccountReference R095 ReinsurerFinancialAccountReference /ReferredSettlement/ReinsurerFinancialAccountReference Specifies the Financial Account to which this Acknowledgement refers. Relevant Transaction reference to be used. Accounting and Settlement: Technical Information Section 2 Message Structure Page 34 of 63

Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage FA R9 InsurerFinancialAccountReference /FinancialAccount/InsurerReference R05 TransactionUUId /UUId R9 InsurerFinancialAccountReference /ReferredSettlement/InsurerFinancialAccountReference R3 ReferredSettlementUUId /ReferredSettlement/UUId [ AcknowledgementTransactionType={response,query}, ReferredTransactionType/DocumentType=settlement ] ACK Acknowledgement of Settlement per Financial Account Item R062 CedentBookingReference /FinancialAccount/FinancialAccountItem/CedentBookingReference R063 BrokerBookingReference /FinancialAccount/FinancialAccountItem/BrokerBookingReference R062 CedentBookingReference /ReferredSettlement/CedentBookingReference R063 BrokerBookingReference /ReferredSettlement/BrokerBookingReference Specifies the Financial Account Item to which this Acknowledgement refers. Relevnat Transaction reference to be used. 2.4.2 Message Grouping Links for grouping messages together for processing or settlement are peer to peer links (i.e. directionless). Note that messages within a group may not always have the same contract reference (UMR) such as for treaty groups. For Group Reference and Settlement Group Reference, the code is assigned by the originator and must be unique within the originator s system. Linking therefore includes the Party Id / Name of the originator (Broker or Cedent). For all message types these are:../cedent/party/id../cedent/party/name../broker/party/id../broker/party/name The tables and figures in the next sections show examples of message grouping. Refer to the Detailed Business Design for further detail on grouping principles. 2.4.2. Financial Account Message Grouping (Settlement) Where combined settlement is required this is represented on the Technical Account messages using the SettlementGroupReference and ItemsInSettlementGroupTotal. Since Financial Account messages refer back to their Technical Account message, grouping of Financial Accounts for Accounting and Settlement: Technical Information Section 2 Message Structure Page 35 of 63

settlement is inherited and implied. However, in order to facilitate processing and validation at the message level, the settlement grouping is repeated within the Financial Account message. Grouping of Financial Account messages must be consistent with the grouping of the Technical Account messages. In the case of discrepancies the Technical Account message grouping takes precedence. settlement settlement settlement settlement..* financialaccount..* financialaccount..*..* groupreference «messagelink» groupreference..* financialaccountitem..* financialaccountitem + itemsingrouptotal + itemsingrouptotal..*..* {itemsingrouptotal = total number of messages in group} groupreference + itemsingrouptotal «messagelink» groupreference + itemsingrouptotal Figure 23 : Financial Account Message Grouping (Settlement) {itemsingrouptotal = total number of messages in group} Accounting and Settlement: Technical Information Section 2 Message Structure Page 36 of 63

Table 4 : Message Grouping Financial Account Settlement Market Reform Msg Reference Description and usage FA Originator identification reference R058 FinancialAccountGroupReference /GroupReference Grouping the FA s for combined settlement Figure 23 FA /ItemsInGroupTotal/Count = Total num messages in group ] Originator identification reference R064 FinancialAccountItemGroupReference /FinancialAccount/FinancialAccountItem/GroupReference [ Q02 FinancialAccountItemsInGroupTotal /FinancialAccount/FinancialAccountItem/ItemsInGroupTotal/Count = Total num messages in group ] Grouping the FA s for combined settlement at the Financial Account Item Level. May also be used where multiple Underwriting Tears are settled in the same currency. Figure 23 2.4.2.2 Message Grouping for processing techaccount techaccount techaccount techaccount..*..*..*..* groupreference + itemsingrouptotal «messagelink» groupreference + itemsingrouptotal settlementgroupreference + itemsinsettlementgrouptotal «messagelink» settlementgroupreference + itemsinsettlementgrouptotal {itemsingrouptotal = total number of messages in group} {itemsinsettlementgrouptotal = total number of messages in group} Figure 24 : Technical Account Message Grouping (Processing) Accounting and Settlement: Technical Information Section 2 Message Structure Page 37 of 63

claimmovement claimmovement placing placing 0.. groupreference «messagelink» 0.. groupreference..* groupreference «messagelink»..* groupreference + itemsingrouptotal + itemsingrouptotal + itemsingrouptotal + itemsingrouptotal {itemsingrouptotal = total number of messages in group} {itemsingrouptotal = total number of messages in group} Figure 25 : Placement and Claim Movement Message Grouping (Processing) Table 5 : Message Grouping Processing Msg Reference Description and usage TA TA Originator identification reference R023 AccountTransactionGroupReference /GroupReference [ Q0 AccountItemsInGroupTotal /ItemsInGroupTotal/Count = Total num messages in group ] Originator identification reference R38 AccountTransactionSettlementGroupReference /SettlementGroupReference Grouping the TA s for reasons other than settlement. Examples include instalments making up a deposit premium or entries originating from one Cedent. [See ACORD RLC Implementation Guidelines 4.2.5] Figure 24 Grouping the TA s for combined settlement processing Figure 24 CM [ Q06 AccountItemsInSettlementGroupTotal /ItemsInSettlementGroupTotal/Count = Total num messages in group ] Originator identification reference R37 ClaimMovementGroupReference /GroupReference Grouping the Claim Movement messages for combined processing. Examples include entries originating from one Cedent. Figure 25 [ Q05 ClaimMovementItemsInGroupTotal /ItemsInGroupTotal/Count = Total num messages in group ] Accounting and Settlement: Technical Information Section 2 Message Structure Page 38 of 63

Msg Reference Description and usage PL Originator identification reference R48 PlacingTransactionGroupReference /GroupReference [ Q07 PlacingItemsInGroupTotal /ItemsInGroupTotal/Count = Total num messages in group ] Market Reform To group together Placing messages. e.g. in the case of multi-cedents. Figure 25 2.4.3 Resend Linking When resending a message no reference linking is required. The resent message is identical in all respects to the original message. Refer Section 5 for further details. 2.4.4 Reversal and New Entry Messages that act to reverse an original message refer to the message they are reversing via the UUId. If the Transaction Reference of the original message is also supplied it must be regarded as for information only. Only in the global market can the Transaction References be used to reference the original message. The new entry message does not require any additional linking references related to its being a new entry message. In the case of Placement messages no reversal is required. The new entry Placement message is merely sent as a re-statement of the contract. In the case of Financial Account messages no reversals are required. The new entry Financial Account messages is merely sent. Figure 26 shows the Technical Account message reversal linking. Reversal of a Claim Movement follows a similar pattern. Accounting and Settlement: Technical Information Section 2 Message Structure Page 39 of 63

TechAccount Msg being Reversed New Entry Technical Account Message techaccount «XSDSequence» techaccounttransaction Reference 0.. 0.. 0.. uuid cedentreference brokerreference serviceproviderreference «messagelink» uuid cedentreference 0.. 0.. {reversal} «XSDSequence» techaccounttransaction Reference correctionindicator 0.. 0.. 0.. techaccount referredtechaccount brokerreference 0.. London Market: May only be used for business information purposes. Link is via uuid. In the global market transaction references may be used for linking. serviceproviderreference Figure 26 : Technical Account message Reversal linking Table 6 : Message Reversal and New Entry Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage TA TA R05 TransactionUUId /UUId R09 CedentAccountTransactionReference /CedentReference R020 BrokerAccountTransactionReference /BrokerReference R42 ServiceProviderAccountTransactionReference /ServiceProviderReference [ (C073) /CorrectionIndicator = reversal ] R32 ReferredTechnicalAccountUUId /ReferredTechAccount/UUId [ (C073) /CorrectionIndicator = reversal ] R02 CedentReferredAccountTransactionReference /ReferredTechAccount/CedentReference R022 BrokerReferredAccountTransactionReference /ReferredTechAccount/BrokerReference R43 ServiceProviderReferredAccountTransactionReference /ReferredTechAccount/ServiceProviderReference TA TA Reverse of a Technical Account message. Figure 26 Reverse of a Technical Account message. Transaction references are mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Figure 26 Accounting and Settlement: Technical Information Section 2 Message Structure Page 40 of 63

Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage CM CM CM CM R05 TransactionUUId /UUId R035 CedentClaimTransactionReference /CedentReference R036 BrokerClaimTransactionReference /BrokerReference R44 ServiceProviderClaimTransactionReference /ServiceProviderReference R05 TransactionUUId /UUId R035 CedentClaimTransactionReference /CedentReference R036 BrokerClaimTransactionReference /BrokerReference R44 ServiceProviderClaimTransactionReference /ServiceProviderReference [ (C75) /CorrectionIndicator = reversal ] R33 ReferredClaimMovementUUid /ReferredClaimMovement/UUId [ (C75) /CorrectionIndicator = reversal ] R040 CedentReferredClaimTransactionReference /ReferredClaimMovement/CedentReference R04 BrokerReferredClaimTransactionReference /ReferredClaimMovement/BrokerReference /ReferredClaimMovement/ServiceProviderReference R64 PreviousClaimMovementUuid /PreviousClaimMovement/UUId R62 CedentPreviousClaimMovementReference /PreviousClaimMovement/CedentReference R60 BrokerPreviousClaimMovementReference /PreviousClaimMovement/BrokerReference R6 ServiceProviderPreviousClaimMovementReferencePrevious /ClaimMovement/ServiceProviderReference CM CM CM Reversal of a previous Claim Movement. Reversal of a previous Claim Movement. Transaction references mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Backward pointing reference to the previous Claim Movement. Backward pointing reference to the previous Claim Movement. Transaction references mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Accounting and Settlement: Technical Information Section 2 Message Structure Page 4 of 63

2.4.5 Linking of Business Transaction Messages Market Reform 2.4.5. Settlement Message Linking Technical Account Message Settlement Message techaccount uuid settlement «XSDSequence» techaccounttransactionreference 0.. 0.. brokerreference cedentreference «messagelink»..* financialaccount uuid referredtechaccount 0....* financialaccountitem London Market: May only be used for business information purposes. Link is via uuid. In the global market transaction references may be used for linking. brokerreference cedentreference 0.. 0.. 0.. «XSDSequence» techaccounttransactionreferen... Figure 27 : Financial Account message link to Technical Account message Accounting and Settlement: Technical Information Section 2 Message Structure Page 42 of 63

Table 7 : Settlement Message Linking Market Reform Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage TA R09 CedentAccountTransactionReference /CedentReference R020 BrokerAccountTransactionReference /BrokerReference R09 CedentAccountTransactionReference /FinancialAccount/FinancialAccountItem/ReferredTechAccou nt/cedentreference R020 BrokerAccountTransactionReference /FinancialAccount/FinancialAccountItem/ReferredTechAccou nt/brokerreference FA Release & Statement. Figure 27 Accounting and Settlement: Technical Information Section 2 Message Structure Page 43 of 63

2.4.5.2 Business Transaction Message Linking Context and Structure Market Reform Figure 28 shows the links between a Technical Account message and its parent Placement message. Linking a Claim Movement message to its parent Placement message follows a similar pattern. Party link on /Party/Id or /Party/Name. Linked party is either Cedent or Broker. Placing Message «messagelink» Technical Account Message placing 0.. «XSDSequence» placingparties 0.. cedent «messagelink» «messagelink» 0..* cedent 0.. «XSDSequence» techaccountparties 0.. techaccount 0.. broker broker 0.. UMR contract brokerreference «messagelink» brokerreference contract 0..* endorsement endorsementreference «messagelink» endorsementreference..* contractsection hilevelreference «messagelink» hilevelreference..* contractsection..* contractmarket 0.. subaccountreference «messagelink» subaccountreference..* subaccount Figure 28 : Technical Account message link to Placement message Accounting and Settlement: Technical Information Section 2 Message Structure Page 44 of 63

Table 8 : Business Transaction Message Linking Context and Structure Market Reform Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage PL TA PL provides TA with contract structure and reference details Figure 28 PL R008 BrokerContractReference /Contract/BrokerReference R037 EndorsementReference Endorsement/EndorsementReference C084 T003 C092 T006 /Cedent/Party/Id /Cedent/Party/Name /Broker/Party/Id /Broker/Party/Name R005 ContractSectionHighLevelReference /ContractSection/HighLevelReference R027 SubaccountReference /ContractSection/ContractMarket/SubaccountReference R008 BrokerContractReference /Contract/BrokerReference /Contract/EndorsementReference C084 T003 C092 T006 /Cedent/Party/Id /Cedent/Party/Name /Broker/Party/Id /Broker/Party/Name R005 ContractSectionHighLevelReference /ContractSection/HighLevelReference R027 SubaccountReference /Subaccount/SubaccountReference CM Always required Optional where required. Use relevant Party identification reference as required. Optional where required. Placement message provides contract and market information for the Claim R008 BrokerContractReference /Contract/BrokerReference R037 EndorsementReference Endorsement/EndorsementReference C084 T003 C092 T006 /Cedent/Party/Id /Cedent/Party/Name /Broker/Party/Id /Broker/Party/Name R005 ContractSectionHighLevelReference /ContractSection/HighLevelReference R027 SubaccountReference /ContractSection/ContractMarket/SubaccountReference R008 BrokerContractReference /Contract/BrokerReference /Contract/EndorsementReference C084 T003 C092 T006 /Cedent/Party/Id /Cedent/Party/Name /Broker/Party/Id /Broker/Party/Name R005 ContractSectionHighLevelReference /ContractSection/HighLevelReference R027 SubaccountReference /ContractSection/ContractMarket/SubaccountReference Always required. Optional where required. Use relevant Party identification reference as required. Optional as required. Accounting and Settlement: Technical Information Section 2 Message Structure Page 45 of 63

2.4.5.3 Business Transaction Message Linking Claim Accounting Market Reform Claim Movement Message Technical Account Message claimmovement contract brokerreference UMR brokerreference contract techaccount For business referencing within applicaitons...* subaccount claim 0.. brokerreference UCR brokerreference 0.. claim 0....* individualclaimamtitem 0.. uuid «XSDSequence» claimmovementtransaction Reference 0.. 0.. 0.. cedentreference brokerreference serviceproviderreference «messagelink» cedentreference brokerreference 0.. 0.. serviceproviderreference 0.. uuid «XSDSequence» claimmovementtransaction Reference 0.. 0.. referredclaimmovement London Market: May only be used for business information purposes. Link is via uuid. In the global market transaction references may be used for linking. Figure 29 : Business Transaction Message Linking Claim Accounting Accounting and Settlement: Technical Information Section 2 Message Structure Page 46 of 63

Table 9 : Business Transaction Message Linking Claim Accounting Market Reform Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage CM R008 BrokerContractReference (UMR) /Contract/BrokerReference R03 BrokerClaimReference (UCR) /Claim/BrokerReference R035 CedentClaimTransactionReference /CedentReference R036 BrokerClaimTransactionReference /BrokerReference R44 ServiceProviderClaimTransactionReference /ServiceProviderReference R008 BrokerContractReference (UMR) /Contract/BrokerReference R03 BrokerClaimReference (UCR) /Subaccount/IndividualClaimAmtItem/Claim/BrokerReferenc e R035 CedentClaimTransactionReference /Subaccount/IndividualClaimAmtItem/ReferredClaimMoveme nt/cedentreference R036 BrokerClaimTransactionReference /Subaccount/IndividualClaimAmtItem/ReferredClaimMoveme nt/brokerreference R44 ServiceProviderClaimTransactionReference /Subaccount/IndividualClaimAmtItem/ReferredClaimMoveme nt/serviceproviderreference TA Reference to CM that provides the Technical Account with Claim details. Figure 29 Not usually used. 2.4.5.4 Business Transaction Message Linking Referred messages Table 0 : Business Transaction Message Linking Referred messages Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage TA R09 CedentAccountTransactionReference /CedentReference R020 BrokerAccountTransactionReference /BrokerReference R034 RelatedCashCallTechnicalAccountReference /Subaccount/IndividualClaimAmtItem/ReferredTechAccount[ AccountTransactionType='cash_loss']/CedentReference R034 RelatedCashCallTechnicalAccountReference /Subaccount/IndividualClaimAmtItem/ReferredTechAccount[ AccountTransactionType='cash_loss']/BrokerReference TA Cash loss contra entries: Cross reference back from the periodic account to the previous cash call. Transaction references mandatory. Usage: London Mkt: For business information usage only Global Mkt: May be used for linking Accounting and Settlement: Technical Information Section 2 Message Structure Page 47 of 63

Target (msg being referenced) Source (msg doing the referencing) Msg Reference Reference Msg Description and usage PL R008 BrokerContractReference /Contract/BrokerReference R008 BrokerContractReference /Contract/BrokerReference PL For Endorsements no explicit reference to a particular previous Placement message is required. All Placements uniquely associated via the common UMR. PL R008 BrokerContractReference /Contract/BrokerReference R0 BrokerParentContractReference /Contract/BrokerParentContractReference PL Multi-lineslip: Cross-reference back to the parent contract under which a risk declaration falls (e.g. the master cover reference when this placing transaction relates to a declaration under that master cover) Accounting and Settlement: Technical Information Section 2 Message Structure Page 48 of 63

2.5 Business sectionalisation The A&S Business Design gives information relating to methods for sectionalising risks for accounting purposes. This part of the document describes how section references are to be used. Business examples are given. 2.5. Contract section structure A section is a group of repeating contract fields. These are typically grouped together because there are extra or different terms which only apply to a specific part of the risk, An example of a sectioned contract is as below: Reference: Type: Class: Location of Risk: ABC23 Treaty Non-Proportional Non-Marine property Section A: Worldwide excluding USA Section B: USA Fire & Flood Perils: Premium: Section A: EUR,000,000 Section B: USD 2,500,000 It is also possible for sections themselves to contain sections: these sub-sections are dealt with in a similar manner. An example of when this may be necessary is where a contract is divided into sections (covering, for example, different classes of business) and then each of these sections is subdivided into sub-sections (each covering, for example, a different location). Elements associated with section references are as below: Contract reporting level High level and low level references Contract Market 2.5.. Contract Reporting Level Contract Reporting Level is carried as an attribute of Contract Section and is used by Contract Section as a flag to indicate the contents. <ContractSection ContractReportingLevel=" _level"> There are three possible values: contract_level (containing all unsectioned fields) insurance_contract_level (as per contract_level but used in the case of large commercial or original insurance policies) section_level (containing data from sectioned or sub-sectioned fields) There must only be one instance of Contract Section per message with a Contract Reporting Level of contract_level or insurance_contract_level. This element should contain all contract data which is not contained in a section that is, the fields that are un-sectioned or apply across all sections. All other Contract Sections should be set to section_level, with the appropriate high and low level references. 2.5..2 High and Low Level References All Contract Section groups in the Placing message must contain a High Level Reference element. Accounting and Settlement: Technical Information Section 2 Message Structure Page 49 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

In the case of Contract Sections where Contract Reporting Level is set to contract_level or insurance_contract_level, the High Level Reference must be set to 00. For all other sections, the High Level Reference must contain a sequentially-incremented positive integer, starting from 0. LowLevelReference must only be used when the contract requirements mean that information within a section_level Contract Section needs be split further into separate sub-sections. For each subsection, a Low Level Reference must be supplied together with the High Level Reference of the parent section. Low Level References must be numbered sequentially from 0 for each group of subsections. 2.5..3 Contract Market There are two scenarios regarding usages of the Contract Market element: The same market (and percentage lines and/or reinsurer references) applies to all sections Each section has a separate market or unique lines In the first case, Contract Market must be placed at the whole contract level: that is, within the first Contract Section where the Contract Reporting Level is set to contract_level or insurance_contract_level. No other Contract Sections must contain Contract Market elements. In the latter case, Contract Market must be placed within each Contract Section where Contract Reporting Level is section_level. It must be in every section and cannot be omitted. Contract Markets cannot be placed into subsections (i.e. Contract Sections containing a Low Level Reference. See section on high and low level references). 2.5..4 Sample scenarios This section provides generic scenarios of section usage. Business examples are presented in the next section. Figure 30 and Figure 3 illustrate the sectionalisation described in the preceding sections. Contract Contract Section contract_level OR insurance_contract_level HighLevelReference=00 Contract Section 2 section_level HighLevelReference=0 Contract Section 5 section_level HighLevelReference=02 Contract Section 6 section_level HighLevelReference=03 Contract Market (Carrier A) Contract Market 2 (Carrier B) Contract Market 3 (Carrier C) Contract Section 3 section_level HighLevelReference=0 LowLevelReference=0 Contract Section 4 section_level HighLevelReference=0 LowLevelReference=02 Contract Section 7 section_level HighLevelReference=03 LowLevelReference=0 Contract Section 8 section_level HighLevelReference=03 LowLevelReference=02 Figure 30 : Contract section structure Common market Accounting and Settlement: Technical Information Section 2 Message Structure Page 50 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

Contract Contract Section contract_level OR insurance_contract_level HighLevelReference=00 Contract Section 2 section_level HighLevelReference=0 Contract Section 5 section_level HighLevelReference=02 Contract Section 6 section_level HighLevelReference=03 Contract Market (Carrier A) Contract Market 3 (Carrier A) Contract Market 6 (Carrier B) Contract Market 2 (Carrier B) Contract Market 4 (Carrier B) Contract Market 7 (Carrier C) Contract Section 3 section_level HighLevelReference=0 LowLevelReference=0 Contract Section 4 section_level HighLevelReference=0 LowLevelReference=02 Contract Market 5 (Carrier C) Contract Section 7 section_level HighLevelReference=03 LowLevelReference=0 Contract Section 8 section_level HighLevelReference=03 LowLevelReference=02 Figure 3 : Contract section structure Section specific markets 2.5..4. Contract with No Sections Note that High Level Reference is mandatory in the London Market even for un-sectioned contracts. <ContractSection ContractReportingLevel="contract_level"> <HighLevelReference>00</HighLevelReference> : <ContractMarket> : </ContractMarket> </ContractSection> 2.5..4.2 Contract with Two Sections, Single Market Contract Market must not be placed in any other Contract Section as it is present at the contract level Contract Section. <ContractSection ContractReportingLevel="contract_level"> <HighLevelReference>00</HighLevelReference> : <ContractMarket> : </ContractMarket> </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>0</HighLevelReference> : </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>02</HighLevelReference> : </ContractSection> 2.5..4.3 Contract with Two Sections, Different Markets per Section Contract Market cannot be placed in the first Contract Section as it is present at the section level Contract Sections. Also, Contract Market must be placed in both section level Contract Sections. It cannot be present in just one. Accounting and Settlement: Technical Information Section 2 Message Structure Page 5 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

<ContractSection ContractReportingLevel="contract_level"> <HighLevelReference>00</HighLevelReference> : </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>0</HighLevelReference> : <ContractMarket> : </ContractMarket> </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>02</HighLevelReference> : <ContractMarket> : </ContractMarket> </ContractSection> 2.5..4.4 Contract with Two Sections, Each with Two Subsections Market Reform Low Level Reference is only displayed in the subsection itself. The count should restart from 0 for each parent section. Contract Market cannot be contained at the subsection level (that is, in a Contract Section which contains a Low Level Reference). <ContractSection ContractReportingLevel="contract_level"> <HighLevelReference>00</HighLevelReference> : </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>0</HighLevelReference> : <ContractMarket> : </ContractMarket> </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>0</HighLevelReference> <LowLevelReference>0</LowLevelReference> : </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>0</HighLevelReference> <LowLevelReference>02</LowLevelReference> : </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>02</HighLevelReference> : <ContractMarket> : </ContractMarket> </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>02</HighLevelReference> <LowLevelReference>0</LowLevelReference> : </ContractSection> <ContractSection ContractReportingLevel="section_level"> <HighLevelReference>02</HighLevelReference> <LowLevelReference>02</LowLevelReference> : </ContractSection> Accounting and Settlement: Technical Information Section 2 Message Structure Page 52 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

2.5..5 Facultative Reinsurance Containing Original Risk Sectioned facultative contracts should also be dealt with using the above guidelines. However, if both the reinsurance and original contracts contain complex sections, or if there is a need to link separate reinsurance contracts to particular parts of the original risk, then implementors should utilise separate messages linked together by a common set of references. Accounting and Settlement: Technical Information Section 2 Message Structure Page 53 of 63 Dated: October 2006 Authors/Owners: MRPO / A&S Team

Appendix A Technical Account Splits Split Narration Lld s LPC Frequency Split type Comments & Recommendations P P2 P3 P4 Different Original or Closing Currencies Different Settlement Currencies Placement Participation Differing Markets Placement - Different Risk Codes It is current practice for brokers to present separate LPANs for differing closing currencies even when the amounts are settled in one settlement currency. Risks can attract different settlement currencies that must be separated to facilitate the correct transfer of funds. For each settlement currency within a risk a separate signing must be generated. Different underwriters can participate on different aspects of the risk (e.g. on package risks). NOT AN ACCOUNTING SPLIT. On the Lloyd's side different exposures are identified by Risk Code and occasionally Underwriter reference. On the Company side Risk Type is used in combination with Underwriter reference The Lead Underwriter allocates codes/references at the time of writing the line. The allocation of premium for each is agreed between Broker and Underwriter. Following underwriters should follow risk codes applied by the leader Y Y Common Fundamental Brokers will continue to record information at this level to enable monitoring of their own inward payments. ACORD standards enforce a single original currency for each TA Y Y Common Fundamental Brokers will continue to record information at this level to enable monitoring of their own outward payments. ACORD standards enforce a single settlement currency for each FA and thereby imply the same degree of breakdown for premiums at the TA stage. Y Y Common Fundamental ACORD message standards mean that the Broker will be accounting at the line level per contract section. The market for each section will be set up via the Placement message. The Broker will then send in TAs and FAs per carrier line per contract section; each carrier will receive the appropriate signing reference for their line(s). Y Y Common Statistical Where differing market lines are required (as above section differing participation) or where the basis on which business is written differs (e.g. conditions, brokerage, orders, profit commissions applicable...), then the Broker will be required to submit separate Placement sections. Subsequent TA and FA messages will need to be allocated to a specific placement section. Lloyd s syndicates must follow the Lead for risk codes. Occasionally syndicates use UW reference to flag cover/confiscation. Increasingly company underwriters will also follow the sections identified by Lloyd s and will use different underwriter References. Refer Lloyd s Bulletin on risk codes Y3347 Data to be supplied by Broker: Accounting and Settlement: Technical Information Section 2 Message Structure Page 54 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P5 Terrorism Terrorism risks e.g. TRIA, ATIA, GAREAT must be identified separately. P6 P7 P8 P P2 Mixed contracts: Facultative Mixed contracts: Facultative Binding Authority and Bulking Lineslip Partial Processing: Multiple Insureds MTMC multiple effective markets XOL protection optional by layer or by insurer Facultative risks may contain a mixture of direct and reinsurance exposures, with different Assureds/Reassureds Facultative risks may contain a mixture of direct and reinsurance exposures, with different Assureds/Reassureds Multiple Insureds on the risk, but payment is in respect of just one insured Mid term changes can occur in the underwriter participation on a risk. Subsequent endorsements can span the two effective markets On some proportional treaty reinsurance, optional Excess of Loss Protection is available on certain layers which syndicates/companies can accept or decline, thereby resulting in a number of entries being required for both FDO and subsequent statements Y Y Fairly common Fundamental Pool Re was withdrawn as at //2003 On the Lloyd s side the Terrorism splits can be identified by specific Risk Codes. On the LPC side specific narrative entries must be made in agreed fields Y Y Rare Fundamental Separate Placement sections are required for the direct and reinsurance elements of facultative cover. Subsequent TAs must be presented separately against these sections. Y Y Rare Structured TA Direct and re-insurance elements can be submitted under the same Placement section. Currently separate LPANs are required for the direct and reinsurance premiums, however the ACORD message structure would support a combined message with direct and reinsurance amounts advised separately in the appropriate fields Y Y Fairly common Fundamental TA must clearly identify insured covered by the payment Y Y Rare Fundamental Under ACORD Brokers will submit TAs at the line level and will be required to reference the specific placement market being used. Y Y Rare Fundamental This type of protection is provided for on the slip and is usually taken up by the whole market. However, companies have the option to state under their underwriting stamp that the XOL protection is not required. If this occurs then separate Placement Sections must be submitted for signing. When statement TAs are submitted for processing they should include R/I costs and Recoveries. Data to be supplied by Broker: Description of cover for each section must be clearly stated in SLIP documentation Broker supplies structured data in TA monetary amount fields. X-referencing to appropriate sub-account market included in TA/FA Stated in slip text Underwriters authorisation to participate in XOL layers Accounting and Settlement: Technical Information Section 2 Message Structure Page 55 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P3 P5 P6 P7 Amounts for Settlement at different times: T-O-T Different Brokerage or Deductions Portfolio transfers XOL reinstatements Underwriters can specify that the premium due on different aspects of a risk is settled on different dates. The Lead Underwriter determines settlement dates at the time of writing the line, calculated by presentation date plus the terms of credit applicable to that type of business. This occurs particularly on terrorism business where money must be in the 'pool' within a set time Following Underwriters can apply differing rates of deductions from those agreed by the leader/rest of the Market. When this happens different Signing references are set up for each different rate of deduction In the Company market these are defined as the transfer of premiums and claims from one insurer to another. They are, accounted for as a portfolio withdrawal by the transferring insurer; and as a portfolio assumption by the accepting insurer. In the Lloyd s market these are used on FDOs (e.g. YOA facilities, Binders, bulking l/s, open covers) to set-up some premium for run-off years of account subsequent to the initial FDO's period. They are mainly for long-tail risks (e.g. liabilities) where the claims need to be allocated to subsequent YOAs They are identified by a Qualifying Category code of E. Certain excess of loss contracts require reinstatement premiums to be paid across GBP / USD / CAD settlement currencies, irrespective of the currency of loss (e.g. if the claim is in USD it must be apportioned and converted equally across the other currencies);currency of Loss or Premium Paid Y Y Rare Fundamental Timing of notification issue, not splits issue. Y Y Fairly common (esp Aviation) Fundamental As different FAs will be required to release the payments at different times, this implies that TAs must be submitted at the same level. A breakdown of deductions is included in ACORD standard messages. Thus forcing separate TAs. Y Y Rare Fundamental Separate TAs will be required to transfer premium from each old carrier and to each new carrier. Subsequent claims (and endorsements) could potentially require splitting across the transfer point. ACORD processing enforces carrier line level submissions so if there were any differences in the market then a fundamental split would be required. Y Y Rare Fundamental Low priority. Brokers handle using existing market mechanisms e.g. agreed wording that settlement is in currency of loss This is a specific case of a settlement currency accounting split Data to be supplied by Broker: TOT for each premium should be clearly stated Number of reinstatements, Claim information, formula for calculating premium Accounting and Settlement: Technical Information Section 2 Message Structure Page 56 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P8 P9 P20 P2 Different Brokers Tax: different rates of IPT Tax: FET payable /non FET Tax: VAT coding From April 997, UK business may attract different rates of Insurance Premium Tax (IPT) based on the inception date of the risk and the type of business which is covered; The last increase was from 4% to 5% and to 7.5% for travel insurance. N Y Fairly Common Structured TA Y Y Fairly Structured TA Common NOT AN ACCOUNTING SPLIT Completion rules and use of UMR when business changes from one broker to another need to be agreed. Subject to further clarification of process The Tax Applications aggregate is repeatable. This allows for the different rates identified. Premium Tax is a valid Tax Class. Differentiation of types can be specified by Tax Type Description. As P9 above. The differentiation of FET payable/non FET can be specified by Tax Type Description.?? Rare Structured TA Use the repeatable Tax Applications aggregate. VAT is a valid Tax Class. Differentiation of the types can be specified by Tax Type Description. Data to be supplied by Broker: New Broker details, agreement to change Broker supplies structured data in TA. Location of Business UK (DTI code) Inception date of risk (for original premium) Effective date (AP/RP). Broker supplies structured data in TA. Broker supplies structured data in TA. Accounting and Settlement: Technical Information Section 2 Message Structure Page 57 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P22 P23 Amounts for Settlement at different times: Reserves See section.4 in main design report Separation of fees from other transactions Business emanating from certain countries can require part of the premium to be held in reserve in the country as a safeguard against the insurer becoming insolvent; Reserve Accounts. XIS technicians refer to the Lloyd s Taxation Department web site for requirements. Miscellaneous Accounting Expenses i.e. Brokerage & Commission, Fees & Expenses accounted separately from the original premium. P24 WAR War amounts are already collected alongside the premium where WAR forms a proportion of the total amount within the same signing for both Lloyd s and LPC. Splitting has only ever been required where something else is different, e.g. Market. Y N Fairly Common Structured TA Reserve processing is under review as there is a different Business Process for Lloyd s and the company market. (Lloyd s) Currently on LIDS the reserve is set up as an advice only endorsement. A contra advice endorsement and a release to cash endorsement are processed as separate new transactions. (Company) On PoSH the Reserve is processed as a deferred instalment (i.e. on the same signing), but is marked as a Reserve and for advice only. The release is processed as an endorsement If no changes to these different business/systems approaches are undertaken then could process as follows: Reserve: Not a Fundamental split Broker should submit a single entry with formatted data. Splitting procedure then required for Lloyd s only. XIS split to create Reserve entry Release: Not a Fundamental split Broker should submit a single endorsement with formatted data. Splitting procedure required for Lloyd s only. XIS to split to create contra reserve and release Y Y Rare Structured TA Confirm if Tax adjustments to be considered as part of review of Taxes. Structured TA Applicable to both Premium and claim transactions NOT AN ACCOUNTING SPLIT If War risk only, indicate by using WAR as the Class of business. If INCLUDING WAR, the required elements will be repeated with the status informational and war for the amount description. Data to be supplied by Broker: Country of origin Agreed in slip text Broker supplies structured data in TA. For reserves: Reserve Amt And at the time of release: Reserve Released Amt Reserve Interest Tax on Reserve Interest Broker supplies structured data in TA monetary amount fields. Broker supplies structured data in TA monetary amount fields. Accounting and Settlement: Technical Information Section 2 Message Structure Page 58 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P25 Premium Transfer In the Lloyd s market these are used on facultative slips (i.e. one-off direct or facultative RI slips) All the premium for a Long Tail Risk is signed up-front to the initial YOA, so to get the right YOAs underwriters agree to Premium Transfers for each year They are identified by a Qualifying Category code of T. P26 DTI reporting Lloyd's provide the DTI with statistics to enable completion of the 'balance of payments'. The DTI code allocated to a risk classifies it into type of business and monetary area from which the business emanates Y Y Fairly common on facultative Statistical PT is normally undertaken as an internal arrangement by the carrier. However, where PT is required by the Client and there are carrier changes for an original premium covering more than 2 months, separate TAs are required to debit the first original and to credit the new original Y N Rare Statistical For the most part DTI code is driven from the country; thus it is not often the prime driver for a split. However splits can occur and are predominantly for reinsurance: for example 0/2 Reinsurance of Lloyd s Vs Companies requested Note LPC and Lloyd s DTI codes are not currently consistent. Data to be supplied by Broker: Broker supplies backup documentation. Insurers need to agree in advance what their requirements are. Specific agreement needs to be obtained to move funds or leave monies in initial year. Funds for movement into subsequent years should be specified within the slip terms either as amounts or statement of pro-rata basis & amendment date. Re-referencing for a different YOA line needs to be identified. Broker supplies backup documentation. List of Insured/Reinsured required Split of orders, limits and premium to be identified. Where different DTI codes reflect reinsurance of both Lloyd's Syndicates and Companies, premium split between each reassured must be defined within DTI codes allocated Country of origin Domicile of Reassured Type of business Accounting and Settlement: Technical Information Section 2 Message Structure Page 59 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P27 Country reporting FIL Codes Foreign Insurance Legislation codes have the following usage: Information for overseas Governments Calculation of foreign tax payments Calculation of Underwriters double taxation relief Calculation of Underwriters deposits abroad Calculation of Underwriters technical reserves required by overseas Governments Calculation of Underwriters contributions to Lloyd's General reps & their offices Y N Common Statistical This section covers Country/jurisdiction compliance needs / US compliance and trust fund needs/ Canadian compliance and trust fund needs On the company side, business may pertain to different countries or states. However these are not split but shown as Various N.B. Some of the data requirements listed are only relevant for specific business types. Data to be supplied by Broker: Broker supplies backup documentation. Country of origin. Name/address of overseas Broker. USB, NUS or US Currency and amount of Gross premium. Address of assured/reassured Location of risk/geographical limits Rate of tax (if applicable) Levy (if applicable) Fire brigade charges Any other special deductions Co-reinsurers involved Registration numbers/flag of vessel Settlement currency Accounting and Settlement: Technical Information Section 2 Message Structure Page 60 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P28 P29 US/Canadian Trust Fund US Reporting: Surplus Line State breakdown US dollar premium is paid into the Lloyd's Dollar Trust fund, certain US business is regulated (surplus lines and reinsurance) by the NYID. Dollar premium signed on business that is not in the US is not regulated. These regulated businesses must be reported on separately. Under new US arrangements (incepting on or after August 995) PANS must be submitted for each single trust. US reinsurance Surplus Lines o Illinois Surplus Lines o Taxable Surplus Lines o Non Taxable Surplus Lines (Guam, American Samoa, Puerto Rico) Illinois Licensed Kentucky Licensed US Virgin Islands Licensed Non Regulated (and any for old LATF) Canadian Regulated business must be processed via the Canadian Regulated Bank Accounts for CAD and USD United States surplus lines risks that incept post to August 995 can contain business from states where Lloyd's is required to collect information for statutory reporting purpose. Y N Common Statistical NOT AN ACCOUNTING SPLIT Y Y Common for Lloyds, Rare for Company market Trust Fund is basically driven from FIL code. In practice therefore it is not an Accounting Split in its own right Backup information is gained from same sources as those for FIL codes Market Reform Data to be supplied by Broker: Broker supplies backup documentation. Information: Country of origin. Name/address of overseas Broker. USB, NUS or US Currency of Gross premium. Address of assured/reassured Location of risk/geographical limits Co-reinsurers involved Registration numbers/flag of vessel Settlement currency US classification State of origin Statistical Broker supplies backup documentation. Where splitting required: State Premium amount US Intermediary Additional information for Lloyd s New Jersey items: Transaction no and policy no with premium amt Accounting and Settlement: Technical Information Section 2 Message Structure Page 6 of 63

Split Narration Lld s LPC Frequency Split type Comments & Recommendations P30 P3 P32 P34 US Reporting: NAIC Reinsurance breakdown Canadian Province Breakdown Multiple Years of Account Insolvent cedants United States Reinsurance risks with Lloyd s require a breakdown by NAIC code Business such as proportional treaty and binding authority bordereaux can contain business over different years of account On reinsurance contracts, certain of the reassureds could be insolvent (e.g. English & American stamp) Market Reform Data to be supplied by Broker: Y N Common Statistical Broker supplies backup documentation. Y? N in futur e Common Y Y Fairly Common P36 FSA Reporting NOT AN ACCOUNTING SPLIT All business P37 Audit Code splits NOT AN ACCOUNTING SPLIT Y N Should not be processed via ACORD NAIC Code Premium Amount Statistical Broker supplies backup documentation. Statistical Subsequent claims and endorsements can pertain across the different Years of account. Y Y Rare Fundamental Broker responsible for resolving situation with cedant. If market to be advised, separate TAs would be required, one payable, one to establish debt Not specifically mentioned in Draft Design Document Old risks can contain multiple audit codes signifying different underwriting markets (e.g. marine /non-marine). But only Equitas entries would still be using Audit Code Canadian province Premium amount Year of account split to be identified Inception date of risk Risk code Declaration attachment dates to be specified Premium applicable Accounting and Settlement: Technical Information Section 2 Message Structure Page 62 of 63

The following additional areas do not entail Accounting splits, and are covered by line level fundamental technical accounts. Market Reform Split Narration Lld s LPC Frequency Comments P9 P0 P33 P35 Partial Processing: Reinstatement Premiums Partial Processing: Part Markets Open Market Vs Lineslip Insolvent reinsurer Reinstatement premium is payable when claim is settled. But agreement of claim can occur at different times for insurers on risk Payment is in respect of only one part of the risk, e.g. partial markets on statements where only some of the proportional insurers have agreed the claim i.e. separation of premiums & claims A mixture of open market and lineslip underwriters can subscribe risks. The Broker can prepare a slip that caters for both open market and lineslip. Where Underwriters will not provide the cover required on the lineslip the Broker places the remainder on the open market cover. The need for a split can be reinforced by the fact that the lineslip will have a pre-defined YOA, which may be different from that on the open market lines. N Y Fairly common Y Y Fairly common Y N Fairly Common Y Y Rare TA and FA submissions are made at the carrier level under the ACORD process, thus Brokers must be responsible for identifying syndicate/company involvement. NB There is high Query Rate on treaty part markets. This is an area that Brokers currently find difficult. Lineslips usually attract different amounts of commissions and therefore require different contract sections. Where a Lineslip and Open Market cover is present on the same Slip Placement section, then they must be presented as different sub accounts (see example in Draft Design Document). Subsequent TAs must then refer to the appropriate Sub account. Under ACORD there is an issue relating to the signed line percentages when using a lineslip. The signed lines on a lineslip always add up to 00%. Currently these signed line %ages are used for any transaction written against the lineslip, with an order applied to the premium. Under ACORD it is proposed that the signed line %ages presented by the Broker will already take into account the Order, i.e. the broker must supply the lines signed down Data to be supplied by Broker: At the placement stage Brokers will need to clearly identify when a sub account constitutes a lineslip. The lineslip will need to have separately registered as a YOA and Ops will need to be advised its reference (OSND is the current paper reference, moving forward the Facility UMR and Sub account reference will be required) Accounting and Settlement: Technical Information Section 2 Message Structure Page 63 of 63