Technical Account Message

Revision

Date

16/01/2013

29/05/2013

Previous

Revision

Date

Project: eAccounts

Technical Account Interface Specification for use with Release 2.0

Summary of Changes

Release: 2.0

Version: 1.1

Date: May 2013

Author: Xchanging

Changes

Marked

Version

Number

First issue for Release 2.0 No

Appendix 7 updated with validation changes agreed at EAPG – new rules M66, TB11 and LP16 and

Yes amended rules M47 and M61

R2.0 v1.0

R2.0 v1.1 eAccounts Technical Account Interface Specification

Release 2.0, Version 1.1 Page

1 of 60

Date: 16/04/2020

TABLE OF CONTENTS

1 Introduction .......................................................................................................................................................... 3

2 Technical Standards ........................................................................................................................................... 4

3 Process Description ............................................................................................................................................ 5

4 Completion of the Technical Account Message ............................................................................................ 10

5 London Market Deferred Scheme .................................................................................................................... 22

6 Operational Issues ............................................................................................................................................ 24

Appendix 1 – Technical Account Message ............................................................................................................ 25

Appendix 2 – Level 3 Acknowledgement Message ............................................................................................... 33

Appendix 3 – Level 4 Query Message .................................................................................................................... 35

Appendix 4 – Level 4 Acknowledgement Message ............................................................................................... 37

Appendix 5 – Format of XIS Signing References .................................................................................................. 39

Appendix 6 – Account Transaction Types ............................................................................................................. 40

Appendix 7 – Technical Account Validation Rules ............................................................................................... 43

eAccounts Technical Account Interface Specification


2 of 60

Date: 16/04/2020

1

Introduction

1.1 Background and Objectives

The eAccounts process will enable brokers to use ACORD Technical Account and Financial Account messages to process accounting transactions with Xchanging.

The use of these messages will remove the need for the broker to submit LPANs and Work Orders for premium submissions, as currently required in the A&S process, and will also enable Xchanging to automatically load the structured data provided by the broker into its data capture systems, reducing the need for re-keying.

1.2 Objectives of this Document

This document is intended to support the use of eAccounts Release 2.0.

It describes the use of ACORD RLC Technical Account messages to advise the details of accounting transactions for processing by Xchanging.

The additional features introduced in release 2.0 are:



The London Market Deferred Scheme



More than one instalment with the same due date



DRI Slice.

1.3 Scope and Exclusions

This delivery will enable:



ACORD Technical Account messages to provide details of the accounting transactions

 ACORD Level 3 Acknowledgement messages to advise Xchanging’s acceptance or rejection of

Technical Accounts as valid messages



ACORD Level 4 Acknowledgement messages to advise business queries and rejections, or to confirm completion of business processing by Xchanging and provide a Broker Signing Number &

Date.

The following exclusions will apply:



Business transactions that are deemed out of scope, as defined in the eAccounts Support Guide . eAccounts Technical Account Interface Specification


3 of 60

Date: 16/04/2020

2

Technical Standards

2.1 DRI and RLC Messages

2.1.1 ACORD Standards Versions

Documents will be delivered by ACORD DRI messages.

ACORD business messages (e.g. Technical Account) will be used to supply structured data.

The following combination of ACORD standards versions will be supported:



ACORD Messaging Service (AMS) Version 1.4 framework standards, Inbox Post Function



ACORD 2008.1 Reinsurance and Large Commercial (RLC) message standards



ACORD 2008.1 Code lists

No other versions or combinations will be supported at this time.

2.1.2 Reference Sources

The following ACORD documentation contains details of these standards 1 :



ACORD Messaging Service Specification and SOAP Implementation Guide (version 1.4)



Security Profiles for the ACORD Messaging Service (Version 1.0)



ACORD Reinsurance and Large Commercial (RLC) Message Specification (Version 2008.1)



ACORD Reinsurance and Large Commercial (RLC) Implementation Guidelines (Accounting and

Claims) (Version 2008.1)



ACORD Reinsurance and Large Commercial (RLC) Accounting & Settlement Quick Reference

Guide (Version 1.0)



ACORD Code manual (Version 2008.1)

1

These documents are available at the ACORD website at www.acord.org



4 of 60

Date: 16/04/2020

3

Process Description

Documents will be submitted using the ACORD Document Repository Interface (DRI) standards. Documents can be submitted using either the Upload Request or Notify & Download operations.

Further detailed technical information concerning these operations can be found in the Technical Information for London Market Implementation of ACORD DRI Messages.

The following pages describe the processing of the Technical Accounts.

3.1 Broker Submission

The broker will send a Technical Account message for each carrier line, currency and instalment (if applicable). Each message will be contained in a separate SOAP package.

N.B

. The broker will need to send one TA for each carrier line for each accounting split that they create

– be that a fundamental or a non-fundamental split:

- e.g. one per closing section if different coverage applies

- e.g. one per risk code if the broker is creating risk code splits.

If there is more than one Technical Account in the submission, each message will contain a Service Provider

Group Reference and Service Provider Items In Group Total, to indicate the number of messages that must be processed together as one business case.

Each message may also contain a separate SupportingDocument aggregate to provide the DocumentId

(containing the UUID), or Document Reference and Version, of each document that supports the Technical

Account.

Unless the broker is registered to use the “DRI Slice” operation then all supporting documents must have been supplied previously to the Market Repository.

3.2 Xchanging Gateway Processing

Upon receipt of a SOAP message XAG will apply SOAP level validation (e.g. authenticate message sender) and immediately return an ACORD synchronous Post Response (or SOAPFault) to the broker, to confirm successful receipt or to advise the reason for rejection. This completes the SOAP handshake.

XAG will validate each message for technical compliance, using the ACORD Schema. In the event of a translation failure (i.e. a schema validation error) an ACORD synchronous Post Response (or SOAPFault) will be sent to the broker.

Field level validation will then be applied, as described in Appendix 7. eAccounts Technical Account Interface Specification


5 of 60

Date: 16/04/2020

When all Technical Accounts in a Service Provider Group have been validated, if any errors have been detected then a Level 3 Acknowledgement message will be sent to the broker for each message received, to advise the reason(s) for their rejection.

Each Acknowledgement message will be sent in a separate SOAP envelope.

The reason(s) will be provided in text form, in ResponseDescription.

The completion of the Level 3 Acknowledgement message is shown in Appendix 2.

Note 1: If one message in a service provider group fails validation then all of the messages having the same ServiceProviderGroupReference will also be rejected.

If a message is rejected only because of an error in another message in that group then the reason for rejection will be given as “REJECTED BECAUSE OF ERROR IN GROUP”.

Note 2: XAG will accumulate all messages required to complete the Service Provider group.

If, after one hour, a group of messages remains incomplete then all messages relating to that group will be rejected and an ACORD Level 3 Acknowledgement will be sent to the broker for each message that has been received.

If a message is rejected only because a group is incomplete, then the reason for rejection will be given as “THIS ITEM BELONGS TO A GROUP WHICH IS NOT COMPLETE”

At this point, if all of the messages for the Service Provider Group have been received and all have successfully passed XAG validation, the Technical Account messages will be passed to the XIS processing application. eAccounts Technical Account Interface Specification


6 of 60

Date: 16/04/2020

3.3 Application Processing

3.3.1 Business Validation

The processing application will apply further business validation, as described in Appendix 7.

3.3.2 Send a Level 3 Acknowledgement

When all Technical Accounts in a Service Provider Group have been validated a Level 3 Acknowledgement message will be sent to the broker for each message received, to either confirm acceptance by the XIS system or to advise the reason(s) for their rejection.

Each Acknowledgement message will be sent in a separate SOAP envelope.

In the case of rejections, the reason(s) will be provided in text form, in ResponseDescription.

The content and format of the Level 3 Acknowledgement message is shown in Appendix 2.

Note: If one message in a service provider group fails validation then all of the messages having the same ServiceProviderGroupReference will also be rejected.

Messages being rejected only because of an error in another message in that group then the reason for rejection will be given as “REJECTED BECAUSE OF ERROR IN GROUP”.

3.3.3 Construct Premium Advices

In order to meet the processing requirements of the XIS legacy applications, Technical Accounts will be grouped into Premium Advices, based on a number of common factors:

 UMR

 Bureau (Lloyd’s, LIRMA, or ILU)

 Broker Number

 Original Currency

 Settlement Currency

 Broker Reference 1

 Broker Reference 2

 Correction Indicator

Where Technical Accounts contain the same values for all of the above elements, XIS will group them into one Premium Advice and one bureau signing.

Where any Technical Account contains a different value for any of the above elements, XIS will create a separate Premium Advice and a separate bureau signing.

Critical elements of the data supplied in, or derived from, the Technical Account will also be automatically loaded into the XIS premium database. eAccounts Technical Account Interface Specification


7 of 60

Date: 16/04/2020

3.3.4 Construct Work Orders

The Premium Advice data will also be used to construct an XIS Work Order.

The resulting Work Orders will be loaded to the Market Repository as XML documents. A style sheet will be applied to these XML documents to allow a familiar view of the data to be presented to

XIS Business Operations technicians.

When the Work order is loaded to the Market Repository it triggers the following actions:

1. A Work Package 2 view is built in the Market Repository, to allow XIS technicians to access all of the related documents for that submission.

2. An XIS workflow record is created.

3.4 Xchanging Business Processing

Each Work Package will be allocated to a technician, who will access the documentation on the IMR to carry out the normal business checks.

In the event of a business query regarding the submission, the XIS technician may contact the broker technician responsible for the submission (i.e. the contact given in the Technical Account) by telephone or email.

If the query cannot be informally resolved the technician will record the query details on the system and a

Level 4 Acknowledgement message will be sent to the broker for each Technical Account. The content and format of the Level 4 Acknowledgement message for a query response is shown in Appendix 3.

Note – There is no Level 4 rejection message for a Technical Account.

If there are no queries, or once all queries have been successfully resolved, the technician will use APIX (a new data capture system for XIS) to supplement the data that was loaded into the XIS premium database with additional data required for reporting to carriers.

Once the work package has been completed the technician will release it for bureau signing and each transaction will be given a permanent unique reference, known as the Signing Number and Date (SND) and the transaction data for those signings will be automatically loaded to POSH and/or LIDS.

Packages of work that contain transactions for both Lloyd’s and the company market will result in entries on both POSH and LIDS.

2

A Work Package is formed of a Work Order and the necessary and supporting information to enable Xchanging to carry out premium and/or policy processing activities on behalf of its customers. eAccounts Technical Account Interface Specification

Date: 16/04/2020


8 of 60

3.5 Level 4 Acknowledgement

Overnight a Level 4 Acknowledgement message will be sent to the broker in respect of each Technical

Account that formed part of the signing, to confirm the completion of business processing and to advise the broker of the Signing Number & Date.

If the Technical Account Payment Means was given as “in_cash” the Level 4 Acknowledgement will also contain the date on which the funds will be settled. This is known as the Actual Payment Date.

Note: For Technical Account submissions for the London Market Deferred Scheme the Level 4

Acknowledgement messages will contain the APD of the particular instalment to which the referred Technical Account related

The content and format of the Level 4 Acknowledgement message is shown in Appendix 4. eAccounts Technical Account Interface Specification


9 of 60

Date: 16/04/2020

4

Completion of the Technical Account Message

This section describes the completion of the individual elements within the message.

The XML for the Technical Account message is shown in Appendix 1.

4.1 Use of Group References

4.1.1 Service Provider Group Reference

This allows the broker to group Technical Accounts for XIS to process together as one business case. This is required when more than one carrier participates in a transaction and/or when more than one Technical Account is submitted for a carrier.

Grouping is done by giving the same value in <ServiceProviderGroupReference> for each of the messages to be grouped. In addition each message must also contain the number of Technical

Accounts that are included in the group, in <ServiceProviderGroupItemsTotal>

Group Reference

This allows the broker to group Technical Accounts for an individual insurer or reinsurer, for a reason other than settlement.

Grouping is done by giving the same value in <GroupReference> for each of the messages to be grouped. In addition each message must also contain the number of Technical Accounts that are included in the group, in <ItemsInGroupTotal>

Where a premium is being paid by instalments (either as APs or using the London Market Deferred

Scheme) the broker must provide this reference to link those instalment Technical Accounts for processing together. The number of instalments must also be given in <ItemsInGroupTotal>.



10 of 60

Date: 16/04/2020

The example shown below demonstrates how group references, and the number in each group, should be applied.

The business example here involves two reinsurers who subscribe to the same contract, for which four transactions are to be paid in three currencies that are to be settled together.

TA

Identifier

Reinsurer

Id Currency

Instalment

Number Group Reference

Items In

Group Total

Service Provider

Group Reference

Service Provider

Group Items Total

TA1

TA2

TA3

TA4

TA5

TA6

TA7

TA8

TA9

TA10

TA11

TA12

TA13

TA14

TA15

TA16

A4704

A4704

A4704

A4704

A4704

A4704

A4704

A4704

A4704

A4704

A4704

A4704

A0504

A0504

A0504

A0504

GBP

GBP

GBP

GBP

USD

USD

USD

USD

CAD

CAD

CAD

CAD

GBP

GBP

GBP

GBP

01

02

03

04

01

02

03

04

01

02

03

04

01

02

03

04

ABC-A4704-GBP

ABC-A4704-GBP

ABC-A4704-GBP

ABC-A4704-GBP

ABC-A4704-USD

ABC-A4704-USD

ABC-A4704-USD

ABC-A4704-USD

ABC-A4704-CAD

ABC-A4704-CAD

ABC-A4704-CAD

ABC-A4704-CAD

ABC-A0504-GBP

ABC-A0504-GBP

ABC-A0504-GBP

ABC-A0504-GBP

04

04

04

04

04

04

04

04

04

04

04

04

04

04

04

04

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

24

24

24

24

24

24

24

24

24

24

24

24

24

24

24

24

TA17

TA18

TA19

TA20

TA21

TA22

TA23

TA24

A0504

A0504

A0504

A0504

A0504

A0504

A0504

A0504

USD

USD

USD

USD

CAD

CAD

CAD

CAD

01

02

03

04

01

02

03

04

ABC-A0504-USD

ABC-A0504-USD

ABC-A0504-USD

ABC-A0504-USD

ABC-A0504-CAD

ABC-A0504-CAD

ABC-A0504-CAD

ABC-A0504-CAD

04

04

04

04

04

04

04

04

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

24

24

24

24

24

24

24

24

SND5

SND6

SND7

SND8

SND9

SND10

SND11

SND12

Note - The references do not require any particular format or structure (the values used here are to aid the reader’s understanding).

SN&D

SND1

SND2

SND3

SND4

SND5

SND6

SND7

SND8

SND9

SND10

SND11

SND12

SND1

SND2

SND3

SND4 eAccounts Technical Account Interface Specification


11 of 60

Date: 16/04/2020

4.2 Identification of Parties

London market company codes (i.e. stamp numbers) and Lloyd’s syndicate numbers will be provided in either <Insurer><Party><Id> or <Reinsurer><Party><Id> to identify the participating carriers.

Note that for Lloyd’s consortia, it is the consortium number that should be provided

In each case the <Party><Id Agency> will be given to identify the bureau as one of ‘lloyds’ or

‘institute_of_london_underwriters’ or ‘london_insurance_and_reinsurance_market_association’ .

XIS will validate that the party identifiers given are valid codes for the applicable agency

London market broker codes will be provided in <Broker><Party><Id> with a <Party><Id Agency> given as ‘lloyds’.

Details of either the insured or the reinsured name must also be given, in

<Insured><Party><Name> or <Cedent><Party><Name> as appropriate.

XIS will be identified in <ServiceProvider><Party><Id> with a <Party><Id Agency> given as

‘ DUNS_dun_and_bradstreet’ . The Party Id used for XIS will be ‘236196817’ .

4.3 Broker References 1 and 2

Broker References 1 and 2 are required for brokers’ reconciliations and are returned by XIS in the BSM and

IPCBSM messages that advise brokers of XIS signings.

However, these references are not explicitly provided in the Technical Account. Therefore these two fields must be concatenated in the Technical Account, in <SubAccount><Description>

This will be mapped to the XIS legacy systems as follows:



Broker Reference 1 will be set to characters 1-12 in the element <SubAccount><Description>



Broker Reference 2 will be set to characters 13-24 in the element <SubAccount><Description>

N.B. Broker Reference 1 and Broker Reference 2 can only contain characters A-Z, 0-9, / and space.

These are the only characters permitted by the XIS mainframe systems. eAccounts Technical Account Interface Specification


12 of 60

Date: 16/04/2020

4.4 Explanation

<Explanation> can be used by brokers to provide any narrative details to clarify any aspect of a transaction.

It is recommended that, where a broker submits more than one Technical Account for a carrier’s line other than for different currencies and/or due dates, a description of what the Technical Account is in respect of should be provided as narrative in <Explanation>.

In particular, XIS request that:

1. Where the broker is submitting separate closing sections due to different carrier exposures or to separate direct and reinsurance coverage, <Explanation> should contain a description of the section to which each Technical Account relates.

2. Where the broker has created non-fundamental splits and is submitting separate Technical Accounts for each non-fundamental split, <Explanation> should contain a description of the non-fundamental split to which each technical Account relates.

XIS does not require this narrative to be in any particular form, but absence of some explanation in these cases may lead to a query being raised by XIS if it is not clear what the Technical Account is in respect of. eAccounts Technical Account Interface Specification


13 of 60

Date: 16/04/2020

4.5 Defining the Type of Business

4.5.1 Treaty or Facultative Indicator

For Direct Insurance, <Contract><TreatyFac> must have a value of “direct”

For Facultative Reinsurance, <Contract><TreatyFac> must have a value of “facultative”

For Excess of Loss Reinsurance, <Contract><TreatyFac> must have a value of “treaty”

For Binding Authorities, <Contract><TreatyFac> must have a value of “direct” or “facultative”

For Bulking Lineslips, <Contract><TreatyFac> must have a value of “direct” or “facultative”

For Non Bulking Lineslips, <Contract><TreatyFac> must have a value of “direct” or “facultative” or

“treaty”

For Covers, <Contract><TreatyFac> must have a value of “direct” or “facultative”

4.5.2 Contract Nature

For Direct Insurance, <Contract><ContractNature> must have a value of “nonproportional”

For Facultative Reinsurance, <Contract>><ContractNature> must have a value of

“nonproportional”

For Excess of Loss Reinsurance, <Contract>><ContractNature> must have a value of

“nonproportional”

For Binding Authorities, <Contract>><ContractNature> must have a value of “nonproportional”

For Bulking Lineslips, <Contract>><ContractNature> must have a value of “nonproportional”

For Non Bulking Lineslips, <Contract>><ContractNature> must have a value of “nonproportional”

For Covers, <Contract>><ContractNature> must have a value of “nonproportional”

4.5.3 Cover Type

For Binding Authorities, <ContractSection><CoverType> must have a value of “binding_authority” or “limited_binder”

For Bulking Lineslips, <ContractSection><CoverType> must have a value of “lineslip”

For Non Bulking Lineslips, <ContractSection><CoverType> must have a value of “lm_facility”

For Covers, <ContractSection><CoverType> must have a value of “open_cover” eAccounts Technical Account Interface Specification


14 of 60

Date: 16/04/2020

4.6 Defining the Type of Transaction

The type of transaction will be defined in <AccountTransactionType>, using a subset of code values from the ACORD A17 code set.

Details of the code values permitted for eAccounts are provided in Appendix 6.

4.7 Use of Original Broker Signing Numbers & Dates

For AP and RP submissions, unless the AP/RP is being submitted at the same time as the original premium, the broker must provide the Original Broker Signing Number & Date (OBSND) of the relevant original premium/FDO signing in the element <Contract><ServiceProviderReference>.

Similarly, for OP declarations on non-bulking lineslips, the broker must provide the OBSND of the relevant facility FDO signing in the element <Contract><ServiceProviderReference>.

The required formats of the signing references f or Lloyd’s, ILU and LIRMA are shown in Appendix 5.

4.8 Use of Percentages

The following format conventions will apply to percentage fields given in the Technical Account:



For <ContractSection><InsurerSharePercentage> up to 7 decimal places may be given



For <ContractSection><ReinsurerSharePercentage> up to 7 decimal places may be given



For all other percentages up to 7 decimal places may be given

It should be noted that the Insurer or Reinsurer Share Percentage should be expressed such that, when applied to 100% amounts, it results in the share amount of the receiver.

The 100% amounts will represent the 100% values as seen by the originating client/cedent (i.e. without application of any sort of order etc). This is to enable the receiver to reconstitute the 100% amounts from their share percentage” eAccounts Technical Account Interface Specification


15 of 60

Date: 16/04/2020

4.9 Use of Amounts

4.9.1 Amount Types

Any amount types from the ACORD 5025 code set may be included with an AmtStatus of

“ informational ”. These amounts must not contribute to the Technical Account balance and will be ignored by Xchanging.

The non-informational amount types that may be provided in the Technical Account are limited to those that XIS have mapped to the Premium Advice. The list of amount types that can be provided, and their mapping to the Premium Advice, is shown in the table below.

Technical Account Amount Type adjustment_premium_due_by_sender adjustment_premium_due_to_sender adjustment_reinstatement_premium_due_by_sender adjustment_reinstatement_premium_due_to_sender adjustment_sliding_scale_commission_due_from_sender adjustment_sliding_scale_commission_due_to_sender brokerage deferred_premium_released_net_of_commission deferred_premium_retained_net_of_commission deposit_premium deposit_released_outstanding_losses deposit_released_outstanding_losses_original deposit_released_premium_fund deposit_retained_outstanding_losses deposit_retained_outstanding_losses_original deposit_retained_premium_fund differences_on_exchange_rate_fluctuations_due_to_sender differences_on_exchange_rate_fluctuations_due_from_sender fire_protection_charges fronting_fee gross_premium income_tax instalment_premium

Premium Advice

Field

Gross Premium

Gross Premium

Gross Premium

Gross Premium

Other Deductions

Other Deductions

Brokerage

Gross Premium

Gross Premium

Gross Premium

Gross Premium

Gross Premium

Gross Premium

Premium Reserve

Premium Reserve

Premium Reserve

Gross Premium

Gross Premium

Other Deductions

Other Deductions

Gross Premium

Taxes

Gross Premium

DR/CR to the Carrier

Credit

Debit

Debit

Debit

Debit

Credit

Debit

Debit

Credit

Debit

Credit

Credit

Debit

Credit

Debit

Credit

Debit

Debit

Credit

Debit

Credit

Credit

Credit eAccounts Technical Account Interface Specification


16 of 60

Date: 16/04/2020

Technical Account Amount Type insurance_premium_tax interest_on_premium_reserve inuring_or_common_account_ri_premium management_expenses margin_premium noclaim_bonus overriding_commission premium premium_portfolio_in premium_portfolio_withdrawal premium_tax_fet premium_tax_excl_fet profit_commission reinsurance_commission reinsurance_deductions reinstatement_premium retrospective_premium_adjustment_due_by_sender retrospective_premium_adjustment_due_to_sender tax_amount tax_on_deposit_interest taxable_interest_on_balances transfer_tax

Premium Advice

Field

IPT

Gross Premium

Gross Premium

Other Deductions

Gross Premium

Gross Premium

Other Deductions

Gross Premium

Gross Premium

Gross Premium

Taxes

Taxes

Gross Premium

Other Deductions

Other Deductions

Gross Premium

Gross Premium

Gross Premium

Taxes

Taxes

Gross Premium

Taxes

DR/CR to the Carrier

Debit

Credit

Debit

Debit

Credit

Debit

Debit

Credit

Credit

Debit

Debit

Debit

Debit

Debit

Debit

Credit

Credit

Debit

Debit

Debit

Debit

Debit eAccounts Technical Account Interface Specification


17 of 60

Date: 16/04/2020

4.9.2 XIS Calculation of Premium Advice Amounts

All amounts given in the Technical Account will be expressed as the individual carrier share amount in original currency. Where a non de-linked transaction is being advised in convertible currency, the balance amount will also be given as the carrier’s share amount in settlement currency.

However, on the Premium Advice:



Gross premium is given as the 100% amount in original currency



Total bureau share percentage is shown



Rate of exchange is shown (if applicable)



Net premium is shown as the bureau share amount in settlement currency.

XIS will accumulate those individual share amounts to arrive at the total bureau values for processing and will calculate the 100% values and rate of exchange as necessary.

4.9.3 Signs of Amounts

Amounts within the Technical Account are usually given without a positive (+) or negative (-) sign.

However, if an amount is given with a negative sign then it will have the opposite meaning to normal

– i.e. an amount that would normally represent a credit to the receiver would instead be a debit.

Please refer to the ACORD RLC Codes Manual for details of whether each amount represents a default debit or credit to the receiver of a Technical Account.

Please also note the following points:

1. The default flow of money for an Insurance Premium Tax (IPT) amount is designated by

ACORD as being from the insurer/reinsurer to the broker – i.e. it is regarded as a deduction.

In fact IPT operates in the opposite manner to this, as it is treated as an addition to the premium.

Therefore, for premium transactions an IPT amount must be sent as a negative value and for RP transactions it must be sent as a positive value.

2. For transactions where the Technical Account balance is due to the broker (e.g. an RP), although the individual amount items given in the sub account may have negative signs because the flow of money is contrary to the normal direction, the

<Subaccount><BalanceAmtItem> and <BalanceAmtItem> will in these cases be qualified as “due to the sender” and therefore those balance amounts must be sent as positive values. eAccounts Technical Account Interface Specification


18 of 60

Date: 16/04/2020

Example 1 - An Original Premium

This is an example of a transaction with:

 A Gross Premium of £1000

 Deductions of £200 Brokerage

 An addition of £60 IPT



A net p remium of £850 due to the reinsurer

In the Technical Account the amounts would be presented as follows:

Amount Type

Premium

Brokerage

Insurance Premium Tax

Balance Due By Sender

Amount Value

£1000.00

£200.00

£60.00

£860.00

Flow of Money

Due to the insurer/reinsurer

Due to the broker



Example 2 - A Return Premium

This is an example of a transaction with:

 A Gross Premium of £700

 Deductions of £140 Brokerage

 An addition of £42 IPT



A net premi um of £602 due to the broker

In the Technical Account the amounts would be presented as follows:

Amount Type

Gross Premium

Brokerage

Insurance Premium Tax

Balance Due To Sender

Amount Value

£700.00

£140.00

£42.00

£602.00

Flow of Money

Due to

Due to

Due to the broker the insurer/reinsurer the broker

Due to the broker

Note that in Example 2 the Gross Premium and Brokerage amounts are given as negative values, and the IPT amount is given as a positive amount, because the flow of money is the opposite to the normal direction.

However, the balance is given as a positive value because it is qualified as being due to the sender

(i.e. the broker). eAccounts Technical Account Interface Specification


19 of 60

Date: 16/04/2020

4.9.4 Insurance Premium Tax

Insurance Premium Tax (IPT) will be given as a <TechAccountAmtItem Type> of

‘insurance_premium_tax’

The Lloyd’s and company markets have different requirements for the presentation of UK and non-

UK IPT. XIS will deal with this internally, by using <TechAccountAmtItem Type><Description>

to differentiate between UK IPT and non-UK IPT.

Therefore a description must always be provided with an IPT amount.



For UK IPT the description must contain the value “insurance_premium_tax” .



For non-UK IPT the description may contain any other value, such as the country for which the tax applies.

In cases where a premium has been incorrectly signed without IPT and a subsequent transaction is required to process the IPT amount only, the broker must process a cancellation for the original transaction followed by a replacement transaction for the premium plus the IPT.

Due to the reporting requirements of Lloyd’s, where a transaction includes a non-UK IPT amount that exceeds the deductions, XIS is required to sign the premium and the IPT amount separately.

Therefore, where a Technical Account for a Lloy d’s carrier includes a non-UK IPT amount that is greater than the deductions, XIS will automatically create two Premium Advices.

On completion of business processing each Premium Advice will be given a separate OBSND.

Only the Broker Signing Number & Date for the premium transaction will be returned in the Level 4

Acknowledgement for each Technical Account. If the signing is an original premium then this will be the OBSND that must be provided with subsequent AP/RP submissions.

However, it should be noted that both the premium and the IPT signings will be included in the BSM.

Use of the Tax Rate Field

The Tax Percentage field in the Technical Account message is an optional field that can be used by brokers to provide the tax rate for taxes that are deducted from premiums (e.g. US Federal Excise

Tax) and/or taxes that are added to premiums (e.g. UK IPT).

Xchanging uses the figures provided by brokers within the tax amount field to calculate the figures that are displayed in boxes 17 and 20 on the system-generated Premium Advices that are loaded on to the Market Repository. eAccounts Technical Account Interface Specification


20 of 60

Date: 16/04/2020

4.10 Payment Means

Where a transaction is to be de-linked then <PaymentMeans> must contain ‘as_per_financial_account’.

The broker will then submit Financial Account messages, or use the on-line De-linking Trigger or RESETT message, to release that transaction for settlement, when ready to do so.

Where a transaction is not to be de-linked then <PaymentMeans> must contain ‘in_cash’. This will be taken as an instruction to XIS to proceed to settlement upon business agreement of the transaction. No

Financial Account will be expected.

Note - For Technical Accounts that have a nil balance (e.g. FDOs and nil adjustments) the

<PaymentMeans> must be ‘in_cash’.

Where it is known that a transaction is to be paid entirely outside of central settlement, then

<PaymentMeans> must contain ‘settled_direct’ . In this case no Financial Account will be expected.

4.11 Due Date

For premiums that are to be paid by instalments, <DueDate> must be provided as the due date of the particular instalment that is being advised in the technical Account.

<DueDate> will not be required for nil balance accounts.

For all other transactions it is recommended that the Settlement Due Date, as recorded on the slip, be provided in <DueDate>. eAccounts Technical Account Interface Specification


21 of 60

Date: 16/04/2020

5

London Market Deferred Scheme

The following pages provide additional completion instructions that are specific to submissions for premium instalments that are to be processed using the London Market Deferred Scheme.

5.1 Account Transaction Type

It will be necessary to differentiate instalments that are to be processed via the deferred scheme from instalments that are to be processed as individual APs.

Where an instalment is to be processed via the deferred scheme, the Technical Account will include a specific ACORD code value for <AccountTransactionType>.

The code value used will depend on the type of transaction as shown in the table below.

Transaction Type

Original Premium

Additional Premium

Return Premium

Account Transaction Type

“premium_deferreds_original”

“premium_deferreds_additional_premium”

“premium_deferreds_return_premium”

5.2 Grouping Requirements

Each Technical Account must include:

<GroupReference> to identify the messages for processing together and

<ItemsInGroupTotal> to define the number of instalments

5.3 Broker References 1 and 2

Each instalment that relates to the same premium transaction must have the same Broker Reference 1 and

Broker Reference 2, which is provided in the Technical Account in <SubaccountDescription>.



If the broker submits at the fundamental level then each fundamental bureau transaction will require a different Broker Reference 1 & 2 (but all splits created by XIS will then share the same Broker Reference 1 & 2).



If the broker submits at a non-fundamental level then each split bureau transaction will require a different Broker Reference 1 & 2.

5.4 Instalment Amount

Each Technical Account must include a <TechAccountAmtItem> with a type of “instalment_premium” to give the gross premium amount of the instalment eAccounts Technical Account Interface Specification


22 of 60

Date: 16/04/2020

5.5 Instalment Number

Each Technical Account must include an <InstalmentNbr> with the “instalment_premium” amount item.

This is a sequence number to uniquely identify each instalment. Therefore it must be different for each instalment.

An example of the use of the InstalmentNbr is shown here:

<TechAccountAmtItem Type="instalment_premium"

<Amt Share="receiver_share" CcyIndic="reference_currency" Ccy="-">0.0</Amt>

<InstalmentNbr>

<Count>1</Count>

</InstalmentNbr>

</TechAccountAmtItem

5.6 Instalment Due Date

Each Technical Account must include a <DueDate>. This is the settlement due date for each instalment, which must be equal to or greater than the due date of the previous instalment.

5.7 Payment Means

Deferred instalments may be submitted as:

 non de-linked ( <PaymentMeans> is “ in_cash ”), or

 de-linked ( <PaymentMeans> is “ as_per_financial_account ”),

If the first instalment is “ in_cash ” then all of the subsequent instalments must also be “ in_cash ”).

If the first instalment is “ as_per_financial_account ” then all of the subsequent instalments may also be

“ as_per_financial_account ”, or all of the subsequent instalments may be “ in_cash ”).

Note – All subsequent instalments must have the same value for Payment Means.

See the Financial Account Interface Specification for details of the impact of the choice of Payment Means on the requirements for the submission of Financial Accounts.

Regardless of the Payment Means specified in the Technical Accounts, it should be noted that, as today, when the first instalment is released for settlement each subsequent instalment will be automatically released for settlement on its due date. eAccounts Technical Account Interface Specification


23 of 60

Date: 16/04/2020

6

Operational Issues

6.1 Service Availability

XAG and the Repository, including the Direct Load facility, will generally be available 24x7 to receive submissions 3 .

However, these services are only supported during normal working hours (07:00-19:00 UK time from

Monday to Friday, excluding public holidays). Availability outside of these hours cannot be guaranteed.

6.2 Presentation Date

Presentation Date is used in a variety of situations by market firms as well as by Xchanging, including monitoring Xchanging’s performance against service levels and, in some circumstances, to establish premium payment by a broker. It is therefore important to understand how a certain Presentation Date is established. In the electronic accounts environment, although the Xchanging ACORD gateway may be available to receive brokers’ submissions outside of normal working hours, the allocation of the Presentation

Date w ill follow today’s paper procedures.

The validity of a Technical Account is determined by the return by Xchanging of a positive Level 3

Acknowledgement to the broker (which will also confirm date of receipt). Between the time when submission of a Technical Account is made and Xchanging return a Level 3 Acknowledgement there are a number of technical validation steps that need to occur. Validation may therefore occur after 5pm.

Therefore, Presentation Date will be established as follows:



Where a Technical Account is received by XIS by 5pm and that Technical Account subsequently proves to be valid, as confirmed by return of a positive Level 3 Acknowledgement, a Presentation Date of the day of receipt will be allocated.



Where a Technical Account is received by XIS after 5pm and that Technical Account subsequently proves to be valid, as confirmed by return of a positive Level 3 Acknowledgement, a Presentation Date of the next working day will be allocated.

6.3 Business Service Levels

Existing XIS business service levels will apply.

.

3

This is subject to agreed service levels.



24 of 60

Date: 16/04/2020

Appendix 1 – Technical Account Message

The following pages describe the completion of the ACORD 2008.1 RLC Technical Account.

N.B. The XML shown here includes all of the elements that XIS use. However, where a data element is not present empty XML tags should not be sent.

Acord Tag/Element Requirement Conditionality/Population Rules

Mandatory <Jv-Ins-Reinsurance Version="2008-1"

xmlns="http://www.ACORD.org/standards/Jv-Ins-Reinsurance/2008-1"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ACORD.org/standards/Jv-Ins-Reinsurance/2008-1

Jv-Ins-Reinsurance-2008-1.xsd">

<TechAccount Sender="broker" Receiver="reinsurer">

<UUId></UUId>

<BrokerReference>-</BrokerReference>

<CreationDate>-<CreationDate>

<AccountTransactionType>-</AccountTransactionType>

<Explanation>-</Explanation>

<GroupReference>-</GroupReference>

<ItemsInGroupTotal>

<Count>-</Count>

</ItemsInGroupTotal>

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Optional

Conditional

Receiver must be either "insurer" or "reinsurer" depending on which of those parties is given below

Format: CCYY-MM-DD

From ACORD codeset A17

Text to provide any additional information or instructions to the XIS technician

A reference to group instalment transactions to be processed together for this insurer/reinsurer. Only required if there is more than one in the group

Conditional

Conditonal

Conditional

The number of instalment transactions to be processed together for this insurer/reinsurer. Only required if there is more than one in the group eAccounts Technical Interface Specification

Version 2.9 Page

25 of 60 Date: 16/04/2020

<ServiceProviderGroupReference>-</ServiceProviderGroupReference>

<ServiceProviderGroupItemsTotal>

<Count>-</Count>

</ServiceProviderGroupItemsTotal>

<Cedent>

<Party>

<Id Agency="-">-</Id>

<Name>-</Name>

</Party>

</Cedent>

<Reinsurer>

<Party>


<Name>-</Name>

</Party>

</Reinsurer>

<Insurer>

<Party>


<Name>-</Name>

</Party>

</Insurer> eAccounts Technical Interface Specification

Version 2.9 Page

26 of 60

Conditional

Conditional

Conditional

A reference to group all of the Technical Accounts to be processed together for all transactions for all participating carriers. Only required if there is more than one in the group

The total number of Technical Accounts to be processed together for all transactions for all participating carriers. Only required if there is more than one in the group

Conditional

Conditional

Conditional

Conditional

Conditional

Conditional

Conditional

Conditional

Conditional

Conditional

From ACORD 3055 codeset

Mandatory for reinsurance business.

Optional

Conditional

Conditional

Conditional

Conditional

Conditional

Mandatory if not reinsurance business. Mutually exclusive with <Reinsurer> element.

Agency may be 'lloyds' or 'institute_of_london_underwriters' or

'london_insurance_and_reinsurance_market_association'

Id will contain the Lloyd's, ILU or LIRMA code

Optional

Conditional

Conditional


Mutually exclusive with <Insurer> element.

Agency may be 'lloyds' or 'institute_of_london_underwriters' or



Date: 16/04/2020

<Broker>

<Party>


<Name>-</Name>

</Party>

<Contact>

<PersonName>-</PersonName>

<Telephone>-</Telephone>

<Email>-</Email>

</Contact>

</Broker>

<ServiceProvider>

<Party>

<Id Agency="DUNS_dun_and_bradstreet">-</Id>

<Name>-</Name>

</Party>

</ServiceProvider>

<Insured>

<Party>

<Name>-</Name>

</Party>

</Insured>

<OriginalPolicyholder>

<Party>

<Name>-</Name>

</Party>

</OriginalPolicyholder> eAccounts Technical Interface Specification

Version 2.9 Page

27 of 60

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Agency must be 'lloyds'.

Id will contain Lloyd's broker code

The broker technician name

The broker technician telephone number

The broker technician email address

Set Agency to "DUNS_dun_and_bradstreet"

Set Id to "236196817"

Set to "XIS"

Include if applicable. Recommended for direct insurance business

Include if applicable. Recommended for facultative reinsurance business

Date: 16/04/2020

<AccountingYear>-</AccountingYear>

<AccountPeriod>

<StartDate>-</StartDate>

<EndDate>-</EndDate>

</AccountPeriod>

<ReferenceCurrency>

<Ccy>-</Ccy>

</ReferenceCurrency>

<TargetCurrency>

<Ccy>-</Ccy>

</TargetCurrency>

<AmtShareIndicator>-</AmtShareIndicator>

<CorrectionIndicator>-</CorrectionIndicator>

<ReferredTechAccount>

<UUId>-</UUId>


</ReferredTechAccount>

<Contract>

<ContractName>-</ContractName>

<TreatyFac>-</TreatyFac>

<ContractNature>-</ContractNature>


<ReinsurerReference>-</ReinsurerReference>

<InsurerReference>-</InsurerReference>

<ServiceProviderReference>-</ServiceProviderReference>

</Contract> eAccounts Technical Interface Specification

Version 2.9 Page

28 of 60

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Mandatory

Conditional

Conditional

Conditional

Mandatory

Conditional

Conditional

Conditional

The year of account. Formay CCYY

Format: CCYY-MM-DD

Format: CCYY-MM-DD

From ISO codeset 4217

Mandatory where settlement is in a different currency.

From ISO codeset 4217.

Must be a valid settlement currency for the market concerned.

Set to "receiver_share"

Set to "reversal" for a cancellation. Else omit.

The UUID of a Technical Account that is being cancelled or replaced.

Provided for cancellations and reversals but not replacements

The broker reference of a Technical Account that is being cancelled or replaced.

Conditional

Conditional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Conditional

Conditional

The broker's contract name

One of 'treaty' or 'facultative' or 'direct'

Currently this will be limited to 'nonproportional'.

When proportional treaty business is included a value of 'proportional' will also be allowed.

The UMR

Mandatory when <Reinsurer> element is included. Mutually exclusive with <Contract><InsurerReference>

Mandatory when <Insurer> element is included.

Mutually exclusive with <Contract><ReinsurerReference>

Include where the transaction is an AP or RP, or an OP declaration on a non-bulking lineslip, to provide the OBSND of the original premium/FDO

Mandatory

Date: 16/04/2020

<Subaccount>

<SequenceNbr>-</SequenceNbr>

<Description>-</Description>

<ContractSection>

<CoverType>-</CoverType>

<LayerOrSurplusNbr>-</LayerOrSurplusNbr>

<InsuredRiskOrInterestDescription>-</InsuredRiskOrInterestDescription>

<ContractPeriod>

<StartDateTime>-</StartDateTime>

<EndDateTime>-</EndDateTime>

</ContractPeriod>

<UnderwritingYear>-</UnderwritingYear>

<ReinsurerSharePercentage>

<Rate RateUnit="percentage">0.0</Rate>

</ReinsurerSharePercentage>

<InsurerSharePercentage>


</InsurerSharePercentage>

<BrokerSharePercentage>


</BrokerSharePercentage> eAccounts Technical Interface Specification

Version 2.9 Page

29 of 60

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Only a single subaccount will be provided per message.

Set to 1

Characters 1-12 will be mapped into the Broker Reference 1

Characters 13-24 will be mapped into Broker Reference 2 .

Set to 'binding_authority' or 'limited_binder' for a Binding Authority

Account, to "lineslip" for a Bulking Lineslip, to 'lm_facility' for a Non

Bulking Lineslip and to "open_cover" for a Cover.

Optional

Optional

Mandatory

Mandatory

Mandatory

Format: CCYY-MM-DDThh:mm:ss*hh:mm

Time need not be given Note

- ss can be set to 00 and * can be '+' or '-' relative to GMT

Format: CCYY-MM-DDThh:mm:ss*hh:mm

Time need not be given Note

- ss can be set to 00 and * can be '+' or '-' relative to GMT

Mandatory

Mandatory

Conditional

Conditional

Conditional

Conditional

Conditional

Conditional

Mandatory

Mandatory

Mandatory

Mandatory when <Reinsurer> element is included. Mutually exclusive with <InsurerSharePercentage>

Mandatory when <Insurer> element is included.

Mutually exclusive with <ReinsurerSharePercentage>

Used to provide the broker's slip order percentage

Date: 16/04/2020

<ContractCoverage CoverageType="-">

< Description > </ Description >

</ContractCoverage>

<Brokerage>


<BrokeragePercentage>


</BrokeragePercentage>

<BrokerageBasis>-</BrokerageBasis>

</Brokerage>

<TaxPercentage>


</TaxPercentage>

</ContractSection>

<JvClassOfBusiness>-</JvClassOfBusiness>

<NaicClassOfBusiness>-</NaicClassOfBusiness>

<RiskLocation>

<Location>

<Country>-</Country>

</Location>

</RiskLocation>



<ac:SupportingDocument>

<ac:DocumentId>-</ac:DocumentId>

<ac:DocumentReference>-</ac:DocumentReference>

<ac:DocumentVersion>-</ac:DocumentVersion>

<ac:DocumentTypeCd>-</DocumentTypeCd>

</ac:SupportingDocument> eAccounts Technical Interface Specification

Version 2.9 Page

30 of 60

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Optional

Mandatory

Mandatory

Optional

Optional

Optional

Optional

Optional

Optional

Conditional

Conditional


Include if applicable.

From ACORD codeset A67 if applicable

Include if applicable

One of "aviation", "marine" or

"nonmarine_general_and_miscellaneous_liability"


Conditional

Conditional

Conditional

Conditional

A separate <ac:SupportingDocument> aggregate must be included for each document provided in support of the Technical Account

The UUID of the document. One of <ac:DocumentId> or

<ac:DocumentReference> must be provided. Mutually exclusive with

<ac:DocumentReference>.

The sender's reference for the document. One of <ac:DocumentId> or

<ac:DocumentReference> must be provided. Mutually exclusive with

<ac:DocumentId>.

Must be given if <ac:DocumentReference> is given

From ACORD codeset A54. Must be provided if the Supporting

Document aggregate is included

Date: 16/04/2020





<TechAccountAmtItem Type="premium" >


</TechAccountAmtItem>



<TechAccountAmtItem Type="instalment_premium" >


<InstalmentNbr>

<Count>1</Count>

</InstalmentNbr>




<TechAccountAmtItem Type="premium" >





<TechAccountAmtItem Type="underlying_premium" AmtStatus="informational">





<TechAccountAmtItem Type="insurance_premium_tax" >






<TechAccountAmtItem Type="tax_amount" >



</TechAccountAmtItem> eAccounts Technical Interface Specification

Version 2.9 Page

31 of 60

Include for each amount in the Technical Account. The amount items shown below are examples of how this aggregate should be completed.

Conditional

Mandatory

Conditional

Conditional

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Conditional

Mandatory

Conditional

Conditional

Mandatory

Conditional

Conditional

Mandatory

Mandatory

InstalmentNbr is mandatory with this amount type

Description is mandatory to advise whether the amount is in respect of

UK IPT or non-UK IPT. A description of "insurance_premium_tax" means UK. Anything else means non-UK

Conditional

Conditional

Mandatory

Optional

Conditional

Description can be used where necessary to identify the specific tax.

Date: 16/04/2020



<IndividualClaimAmtitem Type="current_payment_losses_and_expenses for contract"

AmtStatus="informational">


<Claim>


</Claim>

<ClaimEntry>


</ClaimEntry>

</IndividualClaimAmtItem>

<BalanceAmtItem Type="-">


<Amt Share="receiver_share" CcyIndic="target_currency" Ccy="-">-</Amt>

</BalanceAmtItem>

</Subaccount>

<PaymentMeans></PaymentMeans>

<BalanceAmtItem Type="-">


<Amt Share="receiver_share" CcyIndic="target_currency" Ccy="-">-</Amt>

<DueDate>-</DueDate>

</BalanceAmtItem>

</TechAccount>

</Jv-Ins-Reinsurance> eAccounts Technical Interface Specification

Version 2.9 Page

32 of 60

Conditional

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Mandatory

Mandatory

Mandatory

Conditional

Conditional

The UCR of the related claim

The TR of the related claim

Mandatory

Conditional

Mandatory

Mandatory

For an RP set to

"technical_account_subaccount_balance_due_to_sender". Otherwise set to "technical_account_subaccount_balance_due_by_sender"


Set to "as_per_financial_account" if the premium is de-linked or the

Tech Account has a nil balance.

Set to "in_cash" if the premium is not de-linked.

Set to "settled_direct" if the premium is not to be paid by central settlement

For an RP set to

"technical_account_settlement_balance_due_to_sender" Otherwise set to "technical_account_settlement_balance_due_by_sender"


Format: CCYY-MM-DD

Mandatory for premiums that are to be paid by instalments, to give the due date of the instalment Not required for nil balance accounts.

Recommended that Settlement Due Date be given for all other transactions

Mandatory

Mandatory

Mandatory

Date: 16/04/2020

Appendix 2 – Level 3 Acknowledgement Message

The following pages describe the completion of the ACORD 2008.1 RLC Acknowledgement.

N.B. Empty XML tags will not be sent.

ACORD Tag/Element

<Jv-Ins-Reinsurance Version="2008-1"




<Acknowledgement Sender="reinsurer" Receiver="broker">

Requirement Conditionality/Population Rules

Mandatory May be"insurer" or "reinsurer" depending on which of those parties is given below

<UUId>-</UUId>

<CreationDate>-</CreationDate>



<AcknowledgementTransactionType>-</AcknowledgementTransactionType>

<Reinsurer>

Mandatory

Mandatory

Conditional

Conditional

Mandatory

Conditional

Format: CCYY-MM-DD

Mandatory if Sender = "reinsurer"

Mandatory if Sender = "insurer"

Set to "response"



<Party>


Conditional

Conditional Agency may be 'lloyds' or 'institute_of_london_underwriters' or



<Name>-</Name>

</Party>

</Reinsurer>

<Insurer>

Optional

Conditional

Conditional

Conditional Mandatory if not reinsurance business.

Mutually exclusive with <Reinsurer> element.

<Party>


Conditional




<Name>-</Name>

</Party>


Version 2.9 Page

33 of 60

Optional

Conditional

Conditional

Date: 16/04/2020

<Broker>

<Party>


<Name>-</Name>

</Party>

</Broker>

<ServiceProvider>

<Party>


<Name>-</Name>

</Party>

</ServiceProvider>

<ReferredTransactionType>

<DocumentType>-</DocumentType>

</ReferredTransactionType>


<UUId></UUId>




<Response>

<AcknowledgementLevelIndicator>-</AcknowledgementLevelIndicator>

<AcknowledgementStatus>-</AcknowledgementStatus>

<ResponseDescription>-</ResponseDescription>

<ErrorIndicator>-</ErrorIndicator>

</Response>

</Acknowledgement>


Version 2.9 Page

34 of 60

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Mandatory

Mandatory

Mandatory

Mandatory

Conditional

Conditional

Mandatory

Mandatory

Mandatory




Set Id to "236196817"

Set to "XIS"

This will be "technical_account"

Identifies the Technical Account being acknowledged

The UUID of the original Technical Account

The reference of the original Technical Account

Include where <AcknowledgementStatus> = "acknowledged".

Will contain the XIS Work Package Reference.

"application_validation"

Set to "rejected" or "acknowledged".

Include where <AcknowledgementStatus> = "rejected".

Will contain narrative description of reason for error.

Include where <AcknowledgementStatus> = "rejected".

Will contain the value "error_free_format".

Date: 16/04/2020

Appendix 3 – Level 4 Query Message

The following pages describe the completion of the ACORD 2008.1 RLC Acknowledgement for a query response.










<UUId>-</UUId>





<Reinsurer>

Mandatory

Conditional

Conditional

Mandatory

Mandatory

Conditional



Format: CCYY-MM-DD

Set to "query"



<Party>


Conditional




<Name>-</Name>

</Party>

</Reinsurer>

<Insurer>

Optional

Conditional

Conditional



<Party>


Conditional




<Name>-</Name>

</Party>

</Insurer>

Optional

Conditional

Conditional eAccounts Technical Interface Specification

Version 2.9 Page

35 of 60 Date: 16/04/2020

<Broker>

<Party>


<Name>-</Name>

</Party>

</Broker>

<ServiceProvider>

<Party>


<Name>-</Name>

</Party>

</ServiceProvider>





<UUId>-</UUId>




<Query>

<QueryDescription>-</QueryDescription>

</Query>

</Acknowledgement>


Version 2.9 Page

36 of 60

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory




Set Id to "236196817"

Set to "XIS"





This will contain the XIS Work Package Reference.

Will contain text: QUERY RAISED VIA TRACKER HAS BEEN

EMAILED TO THE BROKER CONTACT.

Date: 16/04/2020

Appendix 4 – Level 4 Acknowledgement Message

The following pages describe the completion of the ACORD 2008.1 RLC Acknowledgement to advise the Broker Signing Number & Date.










<UUId>-</UUId>





<Reinsurer>

Mandatory

Conditional

Conditional

Mandatory

Mandatory

Conditional



Format: CCYY-MM-DD

Set to "response"



<Party>


Conditional




<Name>-</Name>

</Party>

</Reinsurer>

<Insurer>

Optional

Conditional

Conditional



<Party>


Conditional




<Name>-</Name>

</Party>


Version 2.9 Page

37 of 60

Optional

Conditional

Conditional

Date: 16/04/2020

<Broker>

<Party>


<Name>-</Name>

</Party>

</Broker>

<ServiceProvider>

<Party>


<Name>-</Name>

</Party>

</ServiceProvider>





<UUId>-</UUId>




<Response>

<AcknowledgementLevelIndicator>-</AcknowledgementLevelIndicator>

<AcknowledgementStatus>-</AcknowledgementStatus>

</Response>

</Acknowledgement>


Version 2.9 Page

38 of 60

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory

Mandatory




Set Id to "236196817"

Set to "XIS"





Characters 1-15 will contain the Broker Signing Number & Date.

Additionally, if the Technical Account Payment Means was

"in_cash", characters 17-20 wil contain "APD=" and characters 21-

30 will contain the Actual Payment Date, formatted as

CCYY-MM-DD

Mandatory

Mandatory

Mandatory

Conditional

Mandatory

Mandatory

Mandatory

"business_validation"

Set to "acknowledged".

Date: 16/04/2020

Appendix 5 – Format of XIS Signing References

Lloyd’s CCYYMMDDSSSSS (13 characters)

Where CC is the Century

YY is the Year

MM

DD

SSSSS is the Month is the Day is the Serial Number

ILU TTCYYSSSSSSDDMM (15 characters)

Where TT

C

YY

SSSSSS is the Transaction Type (e.g. PM, AP, RP) is the Class of Business (A=Aviation, C= cargo, H=Hull) is the Year is the Serial Number

DD

MM is the Day is the Month

LIRMA YYMMDDPQSSSSS (13 characters)

Where YY

MM

DD is the Year is the Month is the Day

P

Q

SSSSS is the Primary Transaction Type (see table below) is the Transaction Type Qualifier is the Serial Number

LIRMA Primary Transaction Type LIRMA Transaction Type Qualifier

Code Description Code Description

4

5

6

2

3

0

1

Premium

Treaty FDO

Additional Premium

Treaty Statement (Credit balance)

Return Premium

Treaty Statement (Debit balance)

Claim

4

5

6

2

3

0

1

No modification to primary type

Cancellation of primary type

Release of reserve set up by primary type

PF rather than PM for primary type 0

Not used

Adjustment additional or return premium

Reinstatement additional or return premium eAccounts Technical Interface Specification

Version 2.9 Page

39 of 60 Date: 16/04/2020

Appendix 6 – Account Transaction Types

The table below defines the Account Transaction Types that are in scope for eAccounts and the XIS mapping of each code value to the Premium Advice values of PM, AP and RP.


adjustment_account_for_all_types_of_adjustments adjustment_premium commission commission_adjustment commission_original deposit_premium fees lm_additional_premium_ap lm_adjustable_premium lm_adjustment_ap lm_adjustment_rp lm_ap_release_of_reserve lm_ap_reserve_deferred lm_audit_fees_additional_premium lm_audit_fees_return_premium lm_cancellation_ap lm_cancellation_premium lm_cancellation_premium_fdo lm_cancellation_premium_reserve_deferred_ap lm_cancellation_premium_reserve_deferred_premium lm_cancellation_premium_reserve_deferred_rp lm_cancellation_premium_reserve_released_deferred_ap lm_cancellation_premium_reserve_released_deferred_premium lm_cancellation_rp lm_interest_ap lm_interest_premium lm_interest_rp

PM/AP/RP

AP

PM

RP

AP

PM

RP

RP

AP

PM

PM

AP

PM

RP

RP

AP

AP

AP

PM

AP

PM

AP

AP

AP

AP

AP

PM

PM eAccounts Technical Interface Specification

Version 2.9 Page

40 of 60 Date: 16/04/2020


lm_no_claims_bonus_add_premium lm_no_claims_bonus_return_premium lm_portfolio_transfer_in_additional_premium lm_portfolio_transfer_in_premium lm_portfolio_transfer_out lm_premium_fdo lm_premium_release_of_reserve_deferred lm_premium_reserve_deferred lm_profit_commission_ap lm_profit_commission_rp lm_rate_of_exchange_adj_binding_authority lm_rate_of_exchange_adjustment_listing_scheme_ap lm_rate_of_exchange_adjustment_listing_scheme_rp lm_rate_of_exchange_ap lm_rate_of_exchange_rp lm_reinstatement_ap lm_reinstatement_ap_on_adj_prem lm_reinstatement_rp lm_reinstatement_rp_on_adj_prem lm_release_of_reserve_ap lm_release_of_reserve_rp lm_release_reserve lm_replacement_ap lm_replacement_premium lm_replacement_premium_fdo lm_replacement_premium_reserve_deferred_ap lm_replacement_premium_reserve_deferred_premium lm_replacement_premium_reserve_deferred_rp eAccounts Technical Interface Specification

Version 2.9 Page

41 of 60

PM/AP/RP

AP

PM

RP

PM

AP

PM

PM

RP

RP

AP

RP

AP

RP

AP

AP

PM

PM

PM

AP

RP

AP

AP

RP

AP

RP

AP

PM

RP

Date: 16/04/2020


lm_replacement_premium_reserve_released_deferred_ap lm_replacement_premium_reserve_released_deferred_premium lm_replacement_rp lm_return_premium_rp lm_rp_release_of_reserve_deferred lm_rp_reserve_deferred lm_small_transaction_ap lm_small_transaction_rp lm_survey_fees_additional_premium lm_survey_fees_return_premium lm_tax_relief_on_life_assurance_additional_premium lm_tax_relief_on_life_assurance_premium lm_tax_relief_on_life_assurance_refund_of_premium new_business_original nonoriginal_premium portfolio_transfer premium premium_deferreds_additional_premium premium_deferreds_original premium_deferreds_return_premium profit_commission reinstatement renewal_adjustment renewal_lapse renewal_original renewal_premium renewal_reinstatement replacement_additional_premium reversal_return_premium

PM/AP/RP

AP

AP

RP

AP

PM

PM

PM

PM

RP

AP

AP

AP

PM

PM

AP

AP

RP

AP

RP

AP

PM

RP

PM

AP

PM

RP

RP

RP

RP eAccounts Technical Interface Specification

Version 2.9 Page

42 of 60 Date: 16/04/2020

Appendix 7 – Technical Account Validation Rules

1. Xchanging ACORD Gateway Validation

Main Details

Rule Check Required

M1

M2

M4

M5

M6

M7

M9

M15

M17

If one of ServiceProviderGroupReference and

ServiceProviderGroupItemsTotal are present, then both must be present

If one of GroupReference and ItemsInGroupTotal are present, then both must be present

Either Insurer/Party/Id or Reinsurer/Party/Id must be present, depending on which of those parties is given as the message receiver.

Only one occurrence of Insurer/Party/Id or

Reinsurer/Party/Id may be present

Insurer/Party/Id/@Agency or Reinsurer/Party/Id/@Agency must have one of the following values:

”lloyds”

”london_insurance_and_reinsurance_market_association”

”institute_of_london_underwriters”

If Insurer/Party/Id/@Agency exists, Insurer/Party/Id must be present

If Reinsurer/Party/Id/@Agency exists, Reinsurer/Party/Id must be present

Broker/Party/Id/@Agency must be “lloyds”

Broker/Contact/Person Name must be present

M18

M19

M24

M25

M26

M27

Broker/Contact/Telephone must be present

Broker/Contact/Email must be present

AccountPeriod/StartDate must be a valid date if sent

AccountPeriod/EndDate must be a valid date, if sent

AccountPeriod must have both of AccountPeriod/StartDate and AccountPeriod/EndDate, if either is sent

AccountPeriod/EndDate must be equal to or greater than

AccountPeriod/StartDate

Error Message

SERVICE PROVIDER GROUP

DATA MISSING

GROUP DATA MISSING

NO INSURER/REINSURER

FOUND

BOTH INSURER & REINSURER

INFORMATION FOUND

INSURER/REINSURER AGENCY

INVALID

NO INSURER IDENTIFIER

CODE FOUND

NO REINSURER IDENTIFIER

CODE FOUND

BROKER AGENCY INVALID

BROKER CONTACT PERSON

NAME MISSING

BROKER CONTACT

TELEPHONE MISSING

BROKER CONTACT EMAIL

MISSING

ACCOUNT PERIOD START

DATE INVALID

ACCOUNT PERIOD END DATE

INVALID

ACCOUNT PERIOD

INCOMPLETE

ACCOUNT PERIOD END DATE

EARLIER THEN START DATE eAccounts Technical Interface Specification

Version 2.9 Page

43 of 60 Date: 16/04/2020

Rule

M28

M30

M34

M35

M37

M38

M39

M49

M50

M57

Check Required

ReferenceCurrency/Ccy must be present

If present, CorrectionIndicator must be “reversal”

Insurer/Party/Id must be present when Contract/TreatyFac equals “direct”

Reinsurer/Party/Id must be present when

Contract/TreatyFac equals “treaty” or “facultative”

If CorrectionIndicator is present then

ReferredTechAccount/UUId must be present

PaymentMeans Payment means must be one of:

“as_per_financial_account”

“in_cash”

“settled_direct”

Broker Reference must be present

The Technical Account Sender must be “broker”

The Technical Account Receiver must be “insurer” or

“reinsurer”

Error Message

ACCOUNT REFERENCE

CURRENCY MISSING

ACCOUNT CORRECTION

INDICATOR INVALID

INSURER MUST BE PRESENT

FOR DIRECT INSURANCE

REINSURER MUST BE

PRESENT FOR REINSURANCE

REFERRED UUID NOT FOUND

PAYMENT MEANS

MISSING/INVALID

BROKER REFERENCE MISSING

TECHNICAL ACCOUNT

SENDER MUST BE BROKER

TECHNICAL ACCOUNT

RECEIVER MUST BE INSURER

OR REINSURER

GROUP REFERENCE MUST BE

PRESENT

M58

M59

If a Subaccount/TechAccountAmtItem type of

“instalment_premium” is included then Group Reference must be present

If Account Transaction Type indicates Deferred Scheme then Items In group Total must be in the range 01-24

If Account Transaction Type indicates Deferred Scheme then Payment Means must not be “settled_direct”

NUMBER OF INSTALMENTS

MUST BE IN THE RANGE 01-24

PAYMENT MEANS INVALID

FOR DEFERRED INSTALMENTS eAccounts Technical Interface Specification

Version 2.9 Page

44 of 60 Date: 16/04/2020

Contract


C1 Contract/TreatyOrFacultative must be present and one of

”direct”

”‘treaty”

“facultative”

C2

C3

C4

Contract/ContractNature must be present and equal to

“nonproportional”

Contract/BrokerReference must be present and be from 6 to 17 characters in length with the following format:

– Character 1 must be a value of ‘B’

– Characters 2-5 must numeric

– Character 6 must not be blank

– Characters 6-17 must only contain A-Z and 0-9

(plus trailing spaces).

- Characters 6-17 must not contain embedded spaces

If Insurer/Party/Id exists, Contract/InsurerReference must be present

C5

C6

Error Message

TREATY/FAC INDICATOR

MISSING/ INVALID

CONTRACT NATURE

MISSING/INVALID

BROKER CONTRACT

REFERENCE MISSING/INVALID

INSURER CONTRACT

REFERENCE MISSING

If Reinsurer/Party/Id exists, Contract/InsurerReference must not be present

If Reinsurer/Party/Id exists, Contract/ReinsurerReference must be present

INSURER CONTRACT

REFERENCE SENT WITH

REINSURER PARTY

REINSURER CONTRACT

REFERENCE MISSING

C7

C8

If Insurer/Party/Id exists, Contract/ReinsurerReference must not be present

ContractName must be present

REINSURER CONTRACT

REFERENCE SENT WITH

INSURER PARTY

CONTRACT NAME MISSING eAccounts Technical Interface Specification

Version 2.9 Page

45 of 60 Date: 16/04/2020

Contract Section


CS1

CS2

If present, Subaccount/ContractSection/CoverType must be one of “binding_authority”, “limited_binder”, “lineslip,

”lm_facility” or “open_cover”

If present,

Subaccount/ContractSection/ContractPeriod/StartDateTime and

Subaccount/ContractSection/ContractPeriod/EndDateTime must be a valid date

CS3

CS4

CS5

Subaccount/ContractSection/ContractPeriod/EndDateTime and

Subaccount/ContractSection/ContractPeriod/StartDateTime must be populated

Subaccount/ContractSection/UnderwritingYear must be present

If Insurer/Party/Id exists

Subaccount/ContractSection/InsurerSharePercentage must be present and be not greater than 100%

CS6

CS7

CS8

CS9

If Reinsurer/Party/Id exists,

Subaccount/ContractSection/InsurerSharePercentage must not be present

If Reinsurer/Party/Id exists

Subaccount/ContractSection/ReinsurerSharePercentage must be present and be not greater than 100%

If Insurer/Party/Id exists,

Subaccount/ContractSection/ReinsurerSharePercentage must not be present

If present

Subaccount/ContractSection/Brokerage/BrokeragePercenta ge/Rate must not be greater than 100%

Error Message

COVER TYPE INVALID

CONTRACT PERIOD DATES

INVALID

CONTRACT PERIOD DATES

MISSING

UNDERWRITING YEAR

MISSING

INSURER SHARE

PERCENTAGE

MISSING/INVALID

INSURER SHARE

PERCENTAGE SENT WITH

REINSURER PARTY

REINSURER SHARE

PERCENTAGE

MISSING/INVALID

REINSURER SHARE

PERCENTAGE SENT WITH

INSURER PARTY

BROKERAGE PERCENTAGE

CANNOT EXCEED 100%

CS10 If present

Subaccount/ContractSection/TaxPercentage/Rate must not be greater than 100

CS12 Subaccount/JvClassOfBusiness must be present and one of:

"aviation"

"marine"

"nonmarine_general_and_miscellaneous_liability”

CS13 If a Subaccount/TechAccountAmtItem is present with a

Subaccount/TechAccountAmtItem/@Type of

“insurance_premium_tax”, then

Subaccount/TechAccountAmtItem/Description must also be present

TAX PERCENTAGE CANNOT

EXCEED 100

JV CLASS OF BUSINESS

MISSING/INVALID

DESCRIPTION MUST BE GIVEN

WITH IPT AMOUNT

CS14 If present BrokerSharePercentage/Rate must not be greater than 100

BROKER PERCENTAGE

CANNOT EXCEED 100 eAccounts Technical Interface Specification

Version 2.9 Page

46 of 60 Date: 16/04/2020

Rule

CS16

Check Required

CS15 If present

Subaccount/ContractSection/ReinsurerSharePercentage/R ate must not contain more than 7 decimal places

If present

Subaccount/ContractSection/InsurerSharePercentage/Rate must not contain more than 7 decimal places

CS17 If present,

Subaccount/ContractSection/InsurerSharePercentage/Rate must not be zero

CS18 If present,

Subaccount/ContractSection/ReinsurerSharePercentage/R ate must not be zero

CS19 Subaccount/ContractSection/BrokerSharePercentage/Rate must be present

CS20 Subaccount/ContractSection/BrokerSharePercentage/Rate must not be zero

CS21 Subaccount/ContractSection/BrokerSharePercentage/Rate must not contain more than 7 decimal places

Error Message

REINSURER SHARE

PERCENTAGE CANNOT HAVE

MORE THAN 7 DECIMAL

PLACES

INSURER SHARE

PERCENTAGE CANNOT HAVE

MORE THAN 7 DECIMAL

PLACES

INSURER SHARE

PERCENTAGE CANNOT BE

GIVEN AS ZERO

REINSURER SHARE

PERCENTAGE CANNOT BE

GIVEN AS ZERO

BROKER SHARE PERCENTAGE

MISSING


CANNOT BE ZERO


CANNOT HAVE MORE THAN 7

DECIMAL PLACES eAccounts Technical Interface Specification

Version 2.9 Page

47 of 60 Date: 16/04/2020

Sub Account

Rule

SB1

SB2

SB3

SB4

SB5

SB6

SB7

Check Required

Subaccount/BalanceAmtItem must be present

Only one occurrence of Subaccount/BalanceAmtItem in reference currency can be included

Subaccount/BalanceAmtItem/Amt must have a numeric value

Subaccount/TechAccountAmtItem/Amt must have a numeric value

Only those Subaccount/TechAccountAmtItem types listed in section 4.9.1 can be submitted as non-informational

A Subaccount/TechAccountAmtItem type that has a status of “informational” must be a valid ACORD amount item.

The sum of all non-informational amounts given in the subaccount must equal the sub-account balance. See below for detailed rules.

The currency attribute in each of occurrence of

TechAccountAmtItem must match the value in

<ReferenceCurrency><Ccy>

TaxAmtItem must not be present

Error Message

SUB ACCOUNT BALANCE

MISSING

SUB ACCOUNT BALANCE IN

REFERENCE CURRENCY CAN

ONLY BE SENT ONCE

SUB ACCOUNT BALANCE NOT

NUMERIC

AMOUNT ITEM NOT NUMERIC

AMOUNT TYPE NOT

SUPPORTED

AMOUNT TYPE INVALID

ACCOUNT DOES NOT

BALANCE

SB8

SB9

SB10

SB11

If present, the amount in an IndividualClaimAmtItem must be “informational”

The currency attribute in each BalanceAmtItem must match the value in <ReferenceCurrency><Ccy>

AMOUNT CURRENCY NOT

EQUAL REFERENCE

CURRENCY

TAX AMOUNT ITEM NOT

SUPPORTED

CLAIM AMOUNT ITEM MUST BE

INFORMATIONAL

AMOUNT CURRENCY NOT

EQUAL REFERENCE

CURRENCY

UCR AND TR MUST BE GIVEN

TOGETHER

SB12 If either IndividualClaimAmtItem/Claim/BrokerReference or

IndividualClaimAmtItem/ClaimEntry/BrokerReference given, both must be present

SB13 The Subaccount/ac:SupportingInformation aggregate cannot be used

SB16 Subaccount/Description must only contain characters

A-Z, 0-9, / and space

USE OF SUPPORTING

INFORMATION NOT

SUPPORTED

BROKER REFERENCE 1 & 2

CONTAINS INVALID

CHARACTERS eAccounts Technical Interface Specification

Version 2.9 Page

48 of 60 Date: 16/04/2020


SB17 For ILU or LIRMA characters 1-12 of Subaccount

Description must not all be spaces

SB18 For Lloyd’s characters 1-24 of Subaccount Description must not all be spaces

SB19 For Lloyd’s, if characters 1-12 of Subaccount Description are spaces and character 13 is "-" then characters 14-24 cannot be spaces

Error Message

BROKER REFERENCE 1 MUST

BE ENTERED FOR ILU/LIRMA

EITHER BROKER REFERENCE

1 OR BROKER REFERENCE 2

MUST BE ENTERED FOR

LLOYD’S

FOR LLOYD’S, BROKER

REFERENCE 2 CANNOT BE "-"

IF BROKER REFERENCE 1 IS

BLANK

SB20 A Subaccount/TechAccountAmtItem must not have more than 2 decimal places

SB21

SB22

SB23

SB24

SB25

If Account Transaction Type indicates Deferred Scheme then Subaccount Description must be the same for all

Technical Accounts with the same Group Reference,

If Account Transaction Type indicates Deferred Scheme then a TechAccountAmtItemType of “instalment_premium” must be included

InstalmentNbr must be included with the

“instalment_premium” amount item

If Account Transaction Type indicates Deferred Scheme then Subaccount balance must not be zero

InstalmentNbr must not be greater than Items In Group

Total

AMOUNTS MUST NOT HAVE

MORE THAN 2 DECIMAL

PLACES

BROKER REFERENCE 1& 2

MUST BE THE SAME IN ALL

TAS WITH THE SAME GROUP

REFERENCE

AN AMOUNT TYPE OF

INSTALMENT PREMIUM MUST

BE INCLUDED FOR A PREMIUM

INSTALMENT

INSTALMENT NUMBER MUST

BE INCLUDED FOR A PREMIUM

INSTALMENT

SUBACCOUNT BALANCE MUST

NOT BE ZERO

INSTALMENT NUMBER

CANNOT BE GREATER THAN

NUMBER OF INSTALMENTS

Rule SB7

The sum of all non-informational amounts given in the sub-account must equal the sub-account balance

Detailed rules:

1. Exclude any amounts with a Status that is not blank

2. Apply ACORD default signs to the un-signed amounts found in the sub-account. Please refer to

Section 4.9.3.

3. Total all signed amounts obtained in Step 2 above

4. Apply the ACORD default sign to the amount found in the sub-account balance amount given in reference currency, depending on whether the balance is “due by” or ”due to” the sender

5. Check that the signed value obtained in Step 3 is identical to the signed value found in Step 4. eAccounts Technical Interface Specification

Version 2.9 Page

49 of 60 Date: 16/04/2020

Technical Amount Item

Rule

TA1

Check Required

The TechAccountItem/ac:SupportingInformation aggregate cannot be used.

Error Message

USE OF SUPPORTING

INFORMATION NOT

SUPPORTED

Technical Account Balance


TB1 BalanceAmtItem with Amt/@CcyIndic =

“reference_currency” must be present

TB2

TB3

The Technical Account Balance in Reference Currency must equal the SubAccount Balance in Reference

Currency.

Only one occurrence of BalanceAmtItem in reference currency can be included

TB5

TB6

TB7

TB8

TB9

If a Subaccount/TechAccountAmtItem type of

“instalment_premium” is included then Due Date must be present

If Account Transaction Type indicates Deferred Scheme then Due Date must not be more than 3 years earlier than current date

TB10 If Account Transaction Type indicates Deferred Scheme then Due Date must not be more than 3 years later than current date

Error Message

TA BALANCE IN REFERENCE

CURRENCY MISSING

TA BALANCE NOT EQUAL SUB

ACCOUNT BALANCE

BalanceAmtItem/DueDate must be a valid date, if sent

If Account Reference Currency is not equal Account Target

Currency then the Technical Account Balance in Target

Currency must be sent

Only one occurrence of BalanceAmtItem in target currency can be included

TA BALANCE IN REFERENCE

CURRENCY CAN ONLY BE

SENT ONCE

TA BALANCE DUE DATE

INVALID

TA BALANCE IN TARGET

CURRENCY MISSING

TA BALANCE IN TARGET

CURRENCY CAN ONLY BE

SENT ONCE

DUE DATE MUST BE PRESENT

FOR DEFERRED INSTALMENTS

DUE DATE MUST NOT BE

MORE THAN 3 YEARS IN THE

PAST


MORE THAN 3 YEARS IN THE

FUTURE

Checking across a group of TAs that form one transaction


LP1 The value in ItemsInGroupTotal/Count must equal the number of unique occurrences of InstalmentNbr in the set of TechAccounts with an identical GroupReference,

(Re)Insurer/Id and ReferenceCurrency. See note below.

LP5 Certain fields must be consistent throughout all messages that form a group. See below for detailed rules.

Error Message

ITEMS IN GROUP TOTAL

INCONSISTENT WITH DISTINCT

INSTALMENT NUMBERS

INCONSISTENCY IN

MESSAGES RELATING TO 1

GROUP eAccounts Technical Interface Specification

Version 2.9 Page

50 of 60 Date: 16/04/2020

Rule LP1

This rule requires the following elements to be included in Technical Account submissions for all premium instalments, whether they are to be processed as APs or using the London Market Deferred Scheme:

 a TechAccountAmtItemType of “instalment_premium”

 an InstalmentNbr

Rule LP5

The table below contains those fields that must, if present, be consistent across all messages within a

Group.

The two columns SPGR & GR represent the elements that must be consistent for each of the Technical

Account groupings: o SPGR - as defined by <ServiceProviderGroupReference> o GR - as defined by <GroupReference>

Technical Account XML Element

<AccountTransactionType>

<Insured>Party>Name>

<Cedent><Party><Name>

<Broker><Party><Id>

<ServiceProvider><Party><Id>


<TargetCurrency><Ccy>

SPGR

Y

Y

Y

Y

GR

Y

Y

Y

Y

Y

Y

Y

<CorrectionIndicator>

<Contract><TreatyFac>

<Contract><ContractNature>

<Contract><BrokerReference>

<Subaccount><ContractSection><ContractPeriod><StartDateTime>

<Subaccount><ContractSection><ContractPeriod><EndDateTime>

<Subaccount><ContractSection><UnderwritingYear>

<Subaccount><JVClassOfBusiness>

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y eAccounts Technical Interface Specification

Version 2.9 Page

51 of 60 Date: 16/04/2020

2. Xchanging Application Validation

Main Details


M8

M8a

If Insurer/Party/Id exists it must be a valid company code or syndicate number for the code list of the agency given

For an AP or RP transaction, if Insurer/Party/Id exists it must be a party on the market for the Original Broker

Signing Number & Date

Error Message

INSURER IDENTIFIER CODE

INVALID

INSURER NOT INCLUDED IN

ORIGINAL PREMIUM MARKET

M8b

M10

For a Lloyd's non-bulking lineslip OP transaction, if

Insurer/Party/Id exists it must be a party on the market for the Original Broker Signing Number & Date of the FDO

If Reinsurer/Party/Id exists it must be a valid company code or syndicate number for the code list of the agency given

M10a For an AP or RP transaction, if Reinsurer/Party/Id exists it must be a party on the market for the Original Broker

Signing Number & Date of the FDO

M10b For a Lloyd's non-bulking lineslip OP transaction, if

M16

Reinsurer/Party/Id exists it must be a party on the market for the Original Broker Signing Number & Date

Broker/Party/Id must be a valid Lloyd’s broker number

INSURER NOT INCLUDED IN

FACILITY FDO

REINSURER IDENTIFIER CODE

INVALID

REINSURER NOT INCLUDED IN

ORIGINAL PREMIUM MARKET

REINSURER NOT INCLUDED IN

FACILITY FDO

M28a ReferenceCurrency/Ccy must be a valid currency code

M29 If present, TargetCurrency/Ccy must be a valid Settlement

Currency Code

M29a If TargetCurrency/Ccy is not present,

ReferenceCurrency/Ccy must be a valid Settlement

Currency Code

M37a If ReferredTechAccount/UUId is present it must match an entry on the XIS database of previously submitted

Technical Accounts

M41 If CorrectionIndicator is present then the Tech Account data must be consistent with the Referred Tech Account:

See below for detailed rules.

M42 The AccounttransactionType is not in scope for eAccounts.

Refer to Appendix 6 for the list of transaction types that are in scope.

M43

BROKER IDENTIFIER CODE

INVALID

ACCOUNT REFERENCE

CURRENCY INVALID

ACCOUNT TARGET CURRENCY

INVALID

ACCOUNT TARGET CURRENCY

INVALID

REFERRED UUID NOT FOUND

REVERSAL INCONSISTENT WITH

REFERRED TECH ACCOUNT

TRANSACTION TYPE IS NOT

SUPPORTED

If CorrectionIndicator is present and the referred Technical

Account has not been signed then all Tech Accounts in the original work package must be submitted together

NOT ALL TAS IN ORIGINAL

SUBMISSION HAVE BEEN

CANCELLED eAccounts Technical Interface Specification

Version 2.9 Page

52 of 60 Date: 16/04/2020


M44 A TA containing a <CorrectionIndicator> can only be accepted if: a) The referred Technical Account has received a Signing

Number & Date, or b) The status of the work package for the referred

Technical Account is prior to “Open-TrackedIn” or is equal to one of “Open-TrackedIn”, “Pending-Queried” or

“Open-Rejected”

Error Message

REVERSAL NOT ALLOWED

WHILE XIS PROCESSING IS IN

PROGRESS

M46

M47

M48

M51

M52

A TA containing a <CorrectionIndicator> cannot be accepted with a <PaymentMeans> of

“as_per_financial_account” if the referred Technical

Account has been settled.

An AP/RP submission that does not include a

<CorrectionIndicator> cannot be accepted with a

<PaymentMeans> of “in_cash” if the original premium is de-linked and has not been settled.

If CorrectionIndicator is present and the referred Technical

Account has been signed then all Tech Accounts for the signing must be submitted together

Reversal Technical Accounts received where original

Work Package has status of ‘Pending-Queried’ &

‘Reversals Processed’ flag is present.

CANCELLATION OF PAID

SIGNING CANNOT BE

DE-LINKED

CASH AP/RP NOT ALLOWED

UNTIL ORIGINAL PREMIUM

SETTLED

NOT ALL TAS FOR SIGNING

HAVE BEEN CANCELLED

Replacement Technical Accounts received where original

Work Package has status of status.

‘New-Received’ or any prior

REVERSAL TECHNICAL

ACCOUNTS HAVE ALREADY

BEEN SENT FOR THIS WORK

PACKAGE

REVERSAL & REPLACEMENT

TECHNICAL ACCOUNTS MUST

BE SUBMITTED TOGETHER

UNLESS IN RESPONSE TO AN

XIS QUERY

M53

M54

M55

M56

Replacement Technical Accounts received where original

Work Package has status of ‘Pending-Queried’ & no

‘Reversals Received’ flag is present.

REVERSAL TECHNICAL

ACCOUNTS HAVE NOT BEEN

RECEIVED FOR THIS WORK

PACKAGE

The ‘ReferredTechAccount.ServiceProviderReference’ field in the Replacement Technical Account will be checked against the

Technical Account database to ensure that it quotes a valid eAccounts Work Package Reference (WPR).

Where the Technical Account

‘ReferredTechAccount.ServiceProviderReference’ field quotes a

WPR, all Technical Accounts in the group must quote a WPR.

Where a group of Technical Accounts quote WPRs, these must all refer to the same original eAccounts submission. Note: where the Replacement Technical Accounts are for mixed market direct business, the quoted WPR will be different but will both refer to the same original submission.

INVALID WORK PACKAGE

REFERENCE

ALL TECHNICAL ACCOUNTS MUST

QUOTE A WORK PACKAGE

REFERENCE

ALL QUOTED WORK PACKAGE

REFERENCES MUST REFERENCE

THE SAME ORIGINAL WORK

PACKAGE eAccounts Technical Interface Specification

Version 2.9 Page

53 of 60 Date: 16/04/2020


M60

M61

M62

If Subaccount/BalanceAmtitem is not zero and Broker Number is flagged as "Non cash" then PaymentMeans must be

"settled_direct"

If Subaccount balance is zero then PaymentMeans must be “in_cash”

UUId must not already have been received

M63

M64

M65

M66

If TargetCurrency/Ccy is not = GBP, USD, CAD or EUR then ReferenceCurrency/Ccy must be the same as

TargetCurrency/Ccy

For ILU and LIRMA, if the broker is in central settlement then bank details must exist for that broker for the settlement currency

For ILU and LIRMA, if the insurer/reinsurer is in central settlement then bank details must exist for that company for the settlement currency

If <CorrectionIndicator> is present then the Referred

Technical Account cannot itself contain a


Error Message

BROKER IS NOT IN CENTRAL

SETTLEMENT

CANNOT BE DE-LINKED IF

SUBACCOUNT BALANCE IS

ZERO

A TECHNICAL ACCOUNT WITH

THIS UUID HAS ALREADY BEEN

RECEIVED

TARGET CURRENCY INVALID

FOR BUREAU SETTLEMENT OF

REFERENCE CURRENCY

BROKER DOES NOT HAVE A

CENTRAL SETTLEMENT BANK

ACCOUNT FOR THE

SETTLEMENT CURRENCY

COMPANY DOES NOT HAVE

CENTRAL SETTLEMENT BANK

ACCOUNT FOR THE

SETTLEMENT CURRENCY

A REVERSAL TA CANNOT BE

REVERSED

Rule M41

For a reversal Technical Account the following fields must be the same as those of the Referred Tech

Account: o Insurer Id or Reinsuer Id o Reference currency o Target Currency

The subaccount and technical account balance due to/by must be the opposite of the Referred Tech

Account (i.e. if the original TA balance was due by the sender then the reversal must be due to the sender and vice versa)

For the reversal Technical Account balance where the target currency is not the same as the reference currency the following rules apply:

Cancellations submitted before signing



The broker is cancelling a transaction that has not yet been processed by XIS, so the settlement amount is irrelevant.



XIS will ignore the amount provided by the broker in the cancellation and derive the settlement amount to be shown on the cancellation record from the settlement value of the original submission. eAccounts Technical Interface Specification

Version 2.9 Page

54 of 60 Date: 16/04/2020



As the original submission has not been signed there will be no BSM for either the original submission or for the cancellation.

Cancellations submitted after signing but before settlement



The broker should submit the cancellation with the same TA balance in target currency as was given in the original submission, but if the client has paid the broker’s system may have already been updated with the client settlement amount. In this scenario the broker can either release the signing for settlement and then process a post-settlement cancellation, or submit the cancellation with the updated settlement amount.



XIS must cancel the notional settlement amount that it recorded for the original de-linked signing.

Therefore XIS will ignore the amount provided by the broker in the cancellation and derive the settlement amount to be shown on the cancellation from the settlement amount of the original submission.



The XIS derived settlement amount for the cancellation signing will be shown in the BSM.

Cancellations submitted after settlement

 The broker’s system has been updated with the client settlement amount and the broker has already released the signing for settlement. If the broker submits a cancellation TA after that then the balance in target currency must reflect the amount that was released for settlement.



Where the broker has used Financial Account(s) to release the signing then the cancellation TA balance in target currency must be same as the settlement amount of the FA that released the original

TA.



Where the broker used the on-line trigger or RESETT message to release the signing then the sum of the related cancellation TA balances in target currency must be same as the settlement amount of the released signing

 The broker’s settlement amount for the cancellation signing will be shown in the BSM.

Contract


C3a Characters 2-5 of Contract/BrokerReference must be a valid broker number

C9

C10

Error Message

UMR BROKER NUMBER INVALID

If Contract/ServiceProviderReference is present it must be found on the XIS database as a valid Original Broker

Signing Number & Date

SERVICE PROVIDER CONTRACT

REFERENCE INVALID

If Contract/ServiceProviderReference is present it must not have been cancelled on the XIS database

THE REFERRED OBSND FOR

THE AP/RP IS CANCELLED eAccounts Technical Interface Specification

Version 2.9 Page

55 of 60 Date: 16/04/2020

Contract Section


CS5a For an AP or RP transaction, if Insurer/Party/Id exists

Subaccount/ContractSection/InsurerSharePercentage must be present and must be the same percentage as given for the Original Broker Signing Number & Date

CS7a For an AP or RP transaction, if Reinsurer/Party/Id exists

Subaccount/ContractSection/ReinsurerSharePercentage must be present and must be the same percentage as given for the Original Broker Signing Number & Date

CS22 For LIRMA, if Contract/ServiceProviderReference is present, the Insurer/Reinsurer cannot have commuted its line for the OBSND

Error Message

INSURER SHARE PERCENTAGE

DIFFERS FROM ORIGINAL

PREMIUM

REINSURER SHARE

PERCENTAGE DIFFERS FROM

ORIGINAL PREMIUM

COMMUTED LINE CANNOT BE

INCLUDED FOR ILU/LIRMA

Sub Account


SB14 A supporting document referenced in the Technical

Account cannot be found on the IMR

SB15 Amounts in this currency must be expressed as whole numbers and cannot contain decimal places

SB26 A supporting document referenced in the Technical

Account cannot be found on the Broker’s Repository

Error Message

SUPPORTING DOCUMENT NOT

FOUND ON THE IMR

AMOUNTS MUST BE IN WHOLE

NUMBERS FOR THIS CURRENCY

SUPPORTING DOCUMENT NOT

FOUND ON BROKER

REPOSITORY

SB27 The Download Response message is not received within

60 minutes of the Download Request message being sent

DOCUMENTS COULD NOT BE

DOWNLOADED FROM BROKER

REPOSITORY

SB28 The Download Request fails to deliver the message to the

Broker’s gateway

SB29 The Broker’s response contains an ID or Reference that does not match that which was originally requested

SB30 The Broker’s response contains ReferredObjects information that does not match that which was originally requested.

UNABLE TO CONTACT BROKER

REPOSITORY FOR DRI SLICE

REQUEST

INCORRECT DOCUMENT

RETURNED

RETURNED REFERRED OBJECT

DETAILS DO NOT MATCH eAccounts Technical Interface Specification

Version 2.9 Page

56 of 60 Date: 16/04/2020

Technical Account Balance

TB11 <BalanceAmtItem Type> must be consistent with

<AccountTransactionType>.and



TA BALANCE TYPE

INCONSISTENT WITH

TRANSACTION TYPE

Rule TB11

If <BalanceAmtItem><Amt> is not zero then:

1. If <AccountTransactionType>.indicates a transaction type of PM or AP and

<CorrectionIndicator> is not present then

<BalanceAmtItem Type> must be “technical_account_settlement_balance_due_by_sender"

2. if <AccountTransactionType>.indicates a transaction type of RP and

<CorrectionIndicator> is not present then

<BalanceAmtItem Type> must be "technical_account_settlement_balance_due_to_sender"

3. If <AccountTransactionType>.indicates a transaction type of PM or AP and

<CorrectionIndicator> is present then

<BalanceAmtItem Type> must be "technical_account_settlement_balance_due_to_sender"

4. If <AccountTransactionType>.indicates a transaction type of RP and

<CorrectionIndicator> is present then

<BalanceAmtItem Type> must be "technical_account_settlement_balance_due_by_sender"

The designation of each if <AccountTransactionType>.code value as a transaction type of PM, AP or RP is defined in Appendix 6. eAccounts Technical Interface Specification

Version 2.9 Page

57 of 60 Date: 16/04/2020

Checking across a group of TAs


LP3 The maximum number of distinct carriers for a set of

Technical Accounts that form one Premium Advice is 99

LP7 The total of carrier lines for a set of Technical Accounts that form one Premium Advice must not exceed 100%

Error Message

MORE THAN 99 CARRIERS

FOUND FOR ONE PREMIUM

ADVICE

TOTAL CARRIER LINES EXCEED

100% FOR ONE PREMIUM

ADVICE

INCONSISTENCY IN DATA

RELATING TO ONE

TRANSACTION

LP8 The data must be consistent for all TAs that form one business transaction.


LP09 If Account Transaction Type indicates Deferred Scheme then the carriers included for each instalment must be consistent for the set of Technical Accounts that have the same Reference Currency

LP11 If Account Transaction Type indicates Deferred Scheme then Payment Means must be consistent for the set of

Technical Accounts in the submission that form the first instalment of a Premium Advice

LP12 If Account Transaction Type indicates Deferred Scheme then Payment Means must be consistent for the set of

Technical Accounts in the submission that form the second and subsequent instalments of a Premium Advice

CARRIERS MUST BE THE SAME

FOR ALL INSTALMENTS

PAYMENT MEANS MUST BE THE

SAME IN ALL TAS FOR THE

FIRST INSTALMENT

PAYMENT MEANS MUST BE THE

SAME IN ALL TAS FOR THE

SECOND AND SUBSEQUENT

INSTALMENTS

TOTAL UK IPT EXCEEDS FIRST

INSTALMENT NET PREMIUM

LP13 If Account Transaction Type indicates Deferred Scheme then for Lloyd's the sum of the UK IPT amounts for a set of Technical Accounts in the submission that form one

Premium Advice must not exceed the sum of the target currency balance amounts for the subset of Technical

Accounts that form the first instalment of that Premium

Advice

LP14 Due Date must not be earlier than the Due Date for any other message in the submission that has the same

Group Reference and Reference Currency and a lower

InstalmentNbr

LP15 For Lloyd's, if Account Transaction Type indicates

Deferred Scheme, the sum of the Subaccount Balances in

Target Currency for a set of Technical Accounts that form one instalment must be less than 10,000,000,000

LP16 The 100% Gross Premium must be consistent for TAs that relate to the same Premium Advice Instalment



BEFORE THE DUE DATE OF

ANOTHER INSTALMENT WITH A

LOWER INSTALMENT NUMBER

INSTALMENT NET PREMIUM

MUST BE LESS THAN

10,000,000,000 FOR LLOYD’S

INCONSISTENT 100% PREMIUM

IN TAS RELATING TO ONE

PREMIUM ADVICE INSTALMENT eAccounts Technical Interface Specification

Version 2.9 Page

58 of 60 Date: 16/04/2020

Rule LP8

The criteria for Technical Accounts that form one business transaction are that they all have the same values for:



Broker Id



UMR



Reference Currency



Target Currency



Broker Reference 1



Broker Reference 2



Correction Indicator

The table below contains those fields that must, if present, be consistent across all messages that form one business transaction.

Technical Account XML Element

<AccountTransactionType>

<Broker><Contact><PersonName>

<Broker><Contact><Telephone>

<Broker><Contact><Email>

<AccountingYear>

<AccountPeriod><Description>

<AccountPeriod><StartDate>

<AccountPeriod><EndDate>


<TargetCurrency><Ccy>


<Subaccount><ContractSection><BrokerSharePercentage>

<Subaccount><ContractSection><Brokerage><BrokeragePercentage><Rate>

<Subaccount><ContractSection><TaxPercentage><Rate>

<Subaccount><BalanceAmtItem Type>

<PaymentMeans> (see note below)

<BalanceAmtItem><DueDate>

Note For Deferred Scheme submissions, if the PaymentMeans for the first instalment is

“as_per_financial_account” then the Payment Means for all of the subsequent instalments may be either “as_per_financial_account” or “in_cash”. eAccounts Technical Interface Specification

Version 2.9 Page

59 of 60 Date: 16/04/2020

Rule LP16

Where there is more than one TA that relates to the same premium advice (as defined in Section 3.3.3 of the Technical Account Interface Specification) and Instalment Number (if present).



The 100% Gross Premium amount of the first TA must be calculated. To do this the TA amounts that are mapped to Gross Premium (as defined in Section 4.9.1 of the Technical Account Interface

Specification) will be divided by the Insurer/Reinsurer Share Percentage.



The 100% Gross Premium amount of each subsequent TA must be similarly calculated and compared to the calculated value for the first TA.

If the calculated amount of any subsequent TA is not the same as for the first TA then all of the TAs relating to that premium advice must be rejected.

A tolerance of plus or minus one percent of the calculated 100% premium, with a minimum of one whole currency unit and a maximum of 10 whole currency units, is allowed when comparing the calculated values. For currencies in which amounts cannot have decimal places (e.g. Japanese Yen) the minimum tolerance will be 100 currency units and the maximum will be 1,000 currency units.

Examples:

For currencies with decimal places

 For a premium of £50 values in the range of 49 – 51 would be accepted

 For a premium of £100 values in the range of 99 – 101 would be accepted



For a pre mium of £1,000 values in the range of 990 – 1,110 would be accepted

 For a premium of £10,000 values in the range of 9,990 – 10,010 would be accepted

For currencies without decimal places



For a premium of JPY 5000 values in the range of 4,900 – 5,100 would be accepted





For a premium of JPY 10,000 values in the range of 9,900 – 10,100 would be accepted

For a premium of JYP 100,000 values in the range of 99,000 – 110,000 would be accepted



For a premium of JPY 1,000,000 values in the range of 999,000 – 1,001,000 would be accepted eAccounts Technical Interface Specification

Version 2.9 Page

60 of 60 Date: 16/04/2020

Technical Account Message

Project: eAccounts

Technical Account Interface Specification for use with Release 2.0

TABLE OF CONTENTS

Introduction

1.1 Background and Objectives

1.2 Objectives of this Document

1.3 Scope and Exclusions

Technical Standards

2.1 DRI and RLC Messages

Process Description

3.1 Broker Submission

3.2 Xchanging Gateway Processing

3.3 Application Processing

3.4 Xchanging Business Processing

3.5 Level 4 Acknowledgement

Completion of the Technical Account Message

4.1 Use of Group References

4.2 Identification of Parties

4.3 Broker References 1 and 2

4.4 Explanation

4.5 Defining the Type of Business

4.6 Defining the Type of Transaction

4.7 Use of Original Broker Signing Numbers & Dates

4.8 Use of Percentages

4.9 Use of Amounts

4.10 Payment Means

4.11 Due Date

London Market Deferred Scheme

5.1 Account Transaction Type

5.2 Grouping Requirements

5.3 Broker References 1 and 2

5.4 Instalment Amount

5.5 Instalment Number

5.6 Instalment Due Date

5.7 Payment Means

Operational Issues

6.1 Service Availability

6.2 Presentation Date

6.3 Business Service Levels

Appendix 1 – Technical Account Message

Appendix 2 – Level 3 Acknowledgement Message

Appendix 3 – Level 4 Query Message

Appendix 4 – Level 4 Acknowledgement Message

Appendix 5 – Format of XIS Signing References

Appendix 6 – Account Transaction Types

Account Transaction Type

PM/AP/RP

Account Transaction Type

PM/AP/RP

Account Transaction Type

PM/AP/RP

Appendix 7 – Technical Account Validation Rules

1. Xchanging ACORD Gateway Validation

2. Xchanging Application Validation

If Subaccount balance is zero then PaymentMeans must be “in_cash”

TB11 <BalanceAmtItem Type> must be consistent with

<AccountTransactionType>.and

<CorrectionIndicator>

See below for detailed rules.

TA BALANCE TYPE

INCONSISTENT WITH

TRANSACTION TYPE

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib