LAH Life Reinsurance Standard Implementation Guide V2.0 - Acord

2 BUSINESS OBJECTIVES AND EXPECTED BENEFITS2.1 Objectives and Problem DescriptionLife reinsurance is insurance for life insurance companies. It is a business relationship between twosophisticated organizations where one party (cedent) passes risk to another party (reinsurer).Historically the primary purpose of life reinsurance was to reduce the risk exposure associated with anyone insurance claim. This was traditionally done through excess of retention arrangements (excess)where the cedent would send all risks over their corporate retention to the reinsurance community.However in the early 1990‟s reinsurance evolved from just an excess of retention facility to a capital andtax planning tool. With this evolution came first-dollar-quota-share reinsurance (first-dollar). In a firstdollar arrangement the cedent sends a percentage of every policy written to the reinsurer. 90/10 quotashareimplied the cedent would reinsure 90% of the risk and retain 10%.The move to first-dollar reinsurance increased the number of reinsured polices exponentially. It was nolonger just cases over a cedent‟s retention; it was a percentage of every case they wrote. This shift inbusiness model, and subsequent increase in the amount of reinsured policies, increased the need forimproved reporting between the reinsurance parties.Currently, reinsurance administration is unnecessarily complicated. While the business of reinsurancemay be complex, the way in which data is transferred between reinsurance partners (direct writer toreinsurer to retrocessionaire) should not be. The transfer and interpretation of data should be ashomogeneous and mechanical as possible, enabling organizations to analyze and make sound businessdecisions on that data.This guide addresses the transport and transformation issue within the life reinsurance service chain.2.2 Business Process(s) SupportedThis standard will be used to transmit data required by ceding and assuming companies to maintain therecords on reinsured cessions. The data supports the reinsurer's ability to appropriately account for,manage, study, value and meet financial and statutory reporting requirements. It also facilitates thereconciliation of the reinsurance records in order to maintain the integrity of the data between tradingpartners.2.3 Value PropositionThe inability of reinsurance organizations to generate clear reporting is an industry concern. Actualcapabilities differ significantly by organization; however, in general it is believed that life reinsurance as anindustry trails other financial services in the ability to deliver current, meaningful management information.Trends in the reinsurance industry – consolidation, new regulatory requirements, capitalizationopportunities, and increased data disclosure - have escalated the need for more effective and better© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 5ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

quality information flows between ceding parties. Some examples of the potential value ofstandardization of the information are as follows:Increased productivity on the part of both cedent and assuming company in managing commonlydefined, rather than unique, data flows between clientsImproved quality of data as source information can be passed directly to the reinsurer andretrocessionaire without layers of re-mappingCommon understanding of the data structure and meanings, resulting in more accurate and preciseinterpretationsValidation of policy records between data partners and ease of reconciliationRefocus of cost from data processing to business data analysis2.4 ScopeThe scope of this implementation is limited to the following:- Life reinsurance. Other reinsurance lines of business such as annuities, disability, and health are beingexcluded from the initial focus. The guide will eventually cover all types of business that relate to lifereinsurance.- Inforce files. This is Transaction Sub-Type 55102. See Message Catalog for additional information.Other potential files may eventually include claims, valuation, audit and securitization.- Transactions. This is Transaction Sub-Type 55101. See Message Catalog for additional information.All Policy Activity transactions as defined in the ACORD Standard.- Intent is the transmission of policy information between cedent and assuming company; includes policycharacteristics, product information, and reinsurance terms. If the reinsurer has partnered with aretrocessionaire, this information is accommodated as well.- Participants. Representatives of the Data Sub Committee of RAPA (Reinsurance AdministrationProfessional Association), as well as other interested insurance companies who are members of ACORD.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 6ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

2.4 Business Workflow DiagramsDirect WriterorReinsurerInforce FileClaim Papers and Claim DecisionBilling StatementNew Business & TransactionsPremium DollarsUnderwriting PapersReinsurerorRetrocessionaireUnderwriting DecisionClaim Payment and Claims SuggestionDividends, Cash Values, etcOther Payments – premium refunds,ERR, etc© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 7ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

3 MESSAGE PRINCIPLES AND ASSUMPTIONS3.1 Supported Business FunctionsThe message is designed to align with the scope of this implementation; which is limited to the following:1. Life reinsurance. Other reinsurance lines of business such as annuities, disability, andhealth are being excluded from the initial focus. The guide will eventually cover all types ofbusiness that relate to life reinsurance.3.2 Message ChoreographyThe guide assumes “one-way” messaging. This means that the guide will not address responsemessages or the automation of error handling. However, the guide does not prohibit these featureseither. The message documented here MAY be used in a robust request-response implementation. Inthis situation, the implementation guide leaves the coordination, handling and requirements of the variousresponses (e.g. Success, Failure, Success with Info, etc) to trading-partner negotiation.3.3 Additional ResourcesThe Implementation Guide is intended to provide additional support to the full ACORD LAH Standarddocumentation. As such, the guide does not attempt to reproduce the entire set of information availablein the ACORD LAH Standard.1. The guide assumes that implementers will have access to the full ACORD LAH Standarddocumentation.2. The full ACORD LAH Standard is available on the ACORD website at the following URL:http://www.acord.org/Standards/download_standards.aspxAdditionally, this guide assumes that the implementer understands many of the basic principles requiredby the full ACORD LAH Standard documentation. Of particular note is the “Implementation Conventions”chapter of the full documentation. Implementers are encouraged to read and understand at least thischapter of the documentation.3.4 Extending the MessageOnce an implementer begins using the messages outlined in this guide, the implementer may requireadditional business concepts not accounted for in this guide, or the full ACORD LAH Standard. This maymean, for example, that the implementer needs a new code value that is not currently included in thestandard. There are a couple ways an implementer may deal with this situation.The simplest approach is to submit a maintenance request to ACORD that suggests the addition of theneeded information to the message‟s underlying data model. To begin this process, send an emailrequest to Life@acord.org.An alternative approach is to use extensions. Extensions are most simply described as a necessary evil.They are necessary for those times that an implementer cannot submit a maintenance request to ACORD© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 9ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

(say, for confidentiality or marketing reasons), or when the implementer needs to go into productionbefore the request can be added to the standard.However, implementers must be very wary of extensions and realize that their use – by their verydefinition – runs counter to the primary objective of using a standard message in the first place. Theyrequire trading-partner negotiation; increase the development time; and significantly impact futuremaintenance. They are necessary. But they should be used with great care.For more information on using extensions, please refer to the full ACORD LAH Standard under thefollowing sections:How to handle typecodesHow to handle type code assignmentsHow to extend XML for Life Insurance for proprietary information3.5 Amounts of ZeroIf an amount is known to be zero (i.e. 0 or 0.0), then the tag MAY or MAY NOT be specified. A missingtag SHOULD be assumed to mean zero. For example, in the aggregate (shownbelow), is used to represent policy fees associated with the contract. If the Sender wishes toexpress that no policy fee was assessed, then the Sender MAY include the tag and indicatethat the value is 0.0. However, the Sender MAY also simply choose to not include the tag inthe message.3.6 Undocumented ElementsThis guide documents all expected and valued elements available in the Reinsurance messages. Inmany cases, the full ACORD LAH Standard may document that additional elements are valid. However,if an element is not documented in this guide, it must not be included in a Reinsurance message that isintended to meet the rules of this guide.If an implementer includes an undocumented element in a Reinsurance message, the resulting messageis considered outside the scope of this guide. The implementer must communicate this requirement withall potential trading partners and work with them to ensure that they are prepared to accept and processthe undocumented element.If an undocumented element is sent without establishing this trading-partner agreement, the receiver may(and probably will) reject the message.3.7 Default ValuesThis implementation guide will occasionally refer to a "default" or "default value" for an element. In thiscase, the term "default" applies to a value or setting that is assumed and used by the Receiver of themessage whenever the associated value is not present in the message. If the Sender includes theassociated tag in the XML message, the specified value is used by the Receiver, and NOT the defaultvalue.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 10ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

3.8 Policy vs. Coverage vs. Reinsurance TreatyWhile this guide generally strives for technical accuracy, there is a common situation where this practicetends to overly complicate the wording and thus obfuscate the meaning. Specifically, it should be notedthat the term "policy" as used in this guide generally refers to a policy as it is viewed from the perspectiveof a reinsurance treaty; not as it is more generally applied in the broader insurance community.For example, this guide covers three transactions that are called Policy Status, Policy Activity and PolicyStatus and Activity. This terminology fits with the common reinsurance terminology associated with theseprocesses. However, these messages are communicating information about the collection of policycomponents that are being reinsured – as described in a specific Reinsurance Treaty. In some cases,this is the entire policy, and the terminology would be technically correct.However, insurers commonly divide the components of a policy across multiple reinsurers. In fact, asingle component may even be covered by multiple reinsurers. Thus, terms like policy, base plan,coverage or component are not technically correct. It would be more correct to say that a given messageshares information about the portions of one or more components of a policy as it applies to a givenReinsurance Treaty.As you might imagine, a message name like "Status of Policy Component or Components CurrentlyCovered by Reinsurance Treaty" is a bit unwieldy. And though such a message name would betechnically more accurate, it does not reflect the terminology commonly used in the reinsurance industry.In the end, the reader should always assume that information in a given message is reflective of ONLYthat information that is relevant to a specific Reinsurance Treaty. Thus, where the guide might refer to apolicy's coverage – the reader assumes this is "the coverage or portion thereof as described in theReinsurance Treaty." When the guide references the policy, the reader assumes it's the collection ofpolicy coverages (or potions thereof) as described in the Reinsurance Treaty, etc...3.9 How to Communicate Multiple Policies in a Single "File"In all messages covered by this guide, a single policy is shared within each message. Thus, while is technically allowed to repeat in the ACORD LAH Messaging Standard, a single reinsurancemessage MUST only contain reinsurance information for a single policy. For example, a "Policy Status"message MUST NOT include information about multiple policies.If a Sender wishes to send multiple policies "in a single file," this may be done by repeating multiplemessages in a single TXLife aggregate (i.e. called a "document" in XML terms). As a result, a singleTXLife "file," MUST contain one reinsurance message; but it MAY include two or even hundreds ofreinsurance messages. Examples follow.3.9.1 Must Repeat the Message for Each PolicyIf we assume that a Cedent wished to send statuses on two different policies, the rough outline of themessage would be:© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 11ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Shading used to highlight split between information for each policy.3.9.2 Multiple Policies MUST NOT Repeat for Each MessageThe following is an example of WHAT NOT TO DO. This alternative may appear to be beneficial because it results in smaller files. However, Insurers (andeven reinsurers) will commonly administer policies on multiple systems. Thus sending and receivingpolicy information as shown here requires an additional step to merge or separate all related policyinformation and forward it to the correct system. It is far easier to treat each wrapper asa single, atomic unit of work.Additionally, while the guide does not currently support automated "error processing," the alternativeshown here severely complicates it. Thus, assuming this practice now significantly simplifies this addition(should the community address it in the guide later, or should individual trading partners wish to adopt it).© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 12ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

3.10 Single Transaction Type per "File"According to the full LAH Messaging Standard, a single TXLife document may theoretically containdifferent transactions in a single stream (i.e. "file"). For example, a TXLife document may contain a55101 message, a 55102 message, a 55103 message and even messages not covered by this guide.This practice is explicitly disallowed by this guide.This guide requires that, for a single TXLife document, the TransSubType of all messages MUST be thesame. For example, they must all be 55101 messages, 55102 message, etc.This requirement greatly simplifies the creation of code to handle a single TXLife message similar as "abatch."3.11 Table Ratings vs. Percentage Load3.11.1 BackgroundWhen a rider or policy is "rated," it is common for insurers (and others in the industry) to think in terms ofa "Table Rating." As such, may find it useful to have this information reported. There is also a concept ofa "Flat Extra" which might be thought of as a rating as well. But this section is focused exclusively on theconcept of a permanent or temporary rating that is commonly referred to as a "Table Rating."A "Table Rating" is nothing more than a common shorthand for an underlying "percentage load" that hasbeen assigned by an Insurer's Underwriter. Whereas a "Flat Extra Amount" specifies a load as a fixeddollar amount, "Table Rating" is used to specify a load in terms of a percentage.This is an important subtlety that must be reemphasized! When an insurer says that a person or policy is"Table Rated;" they're talking about the underlying concept of a "Percentage Load." For example, whenan insurer states that a policy or insured is "table rated" this really has NOTHING do with "tables." Theletter (or number) assigned to the rating is irrelevant. It makes for good marketing, and simplifies a prettycomplex subject. The letter or number assigned to the "table rating" is just a type of shorthand.For example, in the LAH Messaging Standard, if an insurer rates an insured as "Table A," the insurerreally means that a load of 125% applies. Thus, the industry term "Table A" (sometimes called "Table 1")is literally "translated" by receivers to an underlying load percentage. This is true of all table ratings.However, Table Rating has a problem!Underwriters (i.e. Insurers) are not limited to the set of percentage loads that may be represented by thecommon shorthand. Thus, while "Table C" translates to "175%" and "Table D" translates to "200%,"underwriters may actually assign a percentage load of "185%" or even "184.5%." In this situation, "TableRating" is useless.As a result, every "table rated" policy will have a "percentage load;" but, because of the problem justnoted, some "table rated" policies will not have a "Table Rating." The LAH Messaging Standard accountsfor this situation by allowing a message to specify BOTH the Table Rating and the Percentage Load.That is, everywhere the Sender may specify a Table Rating shorthand; the Sender may also (oralternatively) represent the percentage load. For example, a message may use on to express the rating using the table shorthand. However, ALSO exists on and may be used to express the actual, underlying percentage load.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 13ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

3.11.2 Solution Required by This GuideThe above solution works – but it left the guide authors with a bit of a problem. Which property (orproperties) should be used? Insurer 1 may use with a value of 125%" whileInsurer 2 might use with a value of Table A (tc=2). Yet, both insurers would besaying exactly the same thing!To address this problem, and to simplify the implementation of reinsurance messages, this guide requiresthat ALL table ratings MUST be specified as their underlying load percentage. The property representingthe Table Rating shorthand, will still be allowed for comparative and reporting purposes. But it isessentially ignored if a receiver needs to determine if a table rating applies.Though this information is noted in the description of the corresponding properties, a list of all propertiesapplicable to "table ratings" is shown here. Note that the properties in "Percentage Load" column MUSTBE USED to express a table rating. The "Table Rating" is optional.See details for each element in the Detailed Element Definitions shown below.3.11.3 Representing Permanent Table RatingsThe following elements are found under BOTH and . In both situations,the elements described here are used the same. Specifically, the element representing the "TableRating" is optional and the element representing the "Percentage Load" is required – when expressingtable ratings. - Optional property used to express the Table Rating Shorthand. - This property MUST be used to represent the percentage load,even if the load is expressed in .3.11.4 Representing Temporary Table RatingsLike permanent table ratings, temporary ratings can be expressed under BOTH and. In both situations, the elements described here are used the same. Specifically, theelement representing the "Table Rating" is optional and the element representing the "Percentage Load"is required – when expressing table ratings. - Optional property used to express the Table Rating Shorthand. - This property MUST be used to represent the percentage load,even if the load is expressed in . - Last date rating applies.4 MESSAGE CATALOGThis Life Reinsurance Guide automates a particular business process, within which a specific set ofmessages have been identified and addressed within this Guide. These are:Business Message (Transaction Type/Sub-Type)Reinsurance Policy Activity Message (551/55101)In some reinsurance communities, this message is known as theMessage FlowCedent -> Reinsurer© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 14ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

"Transaction" message or "Transaction File." This message is sent anytime activity occurs on a policy that affects reinsurance.Reinsurance Policy Status Message (551/55102)In some reinsurance communities, this message is known as the "Inforce"message or "Inforce Files." It is used to communicate the current statusand associated values of a policy; typically sent on a period schedule asrequested by the Reinsurer.Reinsurance Policy Activity or Status (551/55103)A single message that combines the processes of the Policy Activity andPolicy Status messages. The implication here is that the Policy Activityand Status message would be sent to a reinsurer as changes are made tothe policy (as in the 55101 message above) AND on a periodic schedule(see 55102) above.Cedent -> ReinsurerCedent -> Reinsurer4.1 About All Messages (TransSubType=551xx)The three messages are differentiated by their "Transaction Sub-Type" (aka TransSubType). All arebased on the ANSI/EDIFACT LREACT EDI message. As such, the structures of the XML messages arealmost identical. Refer to the Element Definitions in section 4.5 for more detail.It is important to note here that the message names are reflective of the process or timing that drives theiruse. Policy Activity (55101) and Policy Status (55102) are usually used in combination between tradingpartnersthat have negotiated their choreography. This is the most common scenario.For example, it is common for a Cedent and Reinsurer to agree that Policy Status information should beshared for ALL policies on a periodic basis (such as quarterly). This would mean that every quarter (orsome other period), the Cedent would send a relatively large number of transactions (usually in a singleTXLife document) that represent the current "book of business" placed with the Reinsurer. Additionally,the pair would exchange a Policy Activity message, as changes occur on the policy. (See details for eachmessage below.)4.2 Reinsurance Policy Activity Message (TransSubType=55101)The name of this transaction (i.e. Policy Activity) refers to the process and timing that it supports, not tothe message's contents (discussed later in this section). The Policy Activity Message is used in aprocess where policy changes are communicated as they occur. Thus, whenever a change that impactsreinsurance information is made to the policy, a Policy Activity Message is sent.It should be clarified that "as they occur" in the prior paragraph does not necessarily imply "real time." Abatch process or even an established schedule could be used to communicate these changes. Theprimary point however is that the messages are only sent as the result of policy change and the receiverwill always expect policy activity to be included in the message.Finally, though the message name is simply "Policy Activity," it is important to note that the messagecontents will also include policy status information (hence the comment above that the name refers to theprocess/timing, not the contents). The implication is that this TransSubType of 55101 notifies the receiverthat activity HAS happened and it is being reported as it occurred.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 15ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

4.3 Reinsurance Policy Status Message (TransSubType=55102)This message is used to communicate policy status, regardless of whether or not activity has occurred onthe policy. For example, reinsurer's commonly want a Policy Status message for a given policy to be senteach quarter (or some other periodic schedule), regardless of any activity during that period.As a result, a Status Message may not correspond to a change activity. That is, a change activity maynot have taken place since the last time information about the policy was exchanged. However, even ifactivity HAS occurred on the policy, that activity IS NOT communicated in this message.4.4 Reinsurance Policy Activity or Status Message (TransSubType=55103)The Policy Activity or Status message would be used in situations where this choreography has not beenestablished. This means that the Receiver of such messages (i.e. the Reinsurer in the example above),would not be able to plan on a specific time for a large number of "status" messages versus the relativelyfewer, interim "activity" messages (a.k.a. "smaller file").Further, there is no implication as to whether or not policy activity information may be expected by thereceiver. The message contents may include just policy status information (when it's being sent to reportstatus), or it may also contain policy activity information.Consequently, this message is seldom used in practice.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 16ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

5 TECHNICAL STRUCTURE5.1 Entity Relationship DiagramThe general construct of all Reinsurance messages follows the Life Data Model structure.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 17ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

5.2 Element DefinitionsThis section contains detailed element definitions for all ACORD LAH aggregates and elements used bymessages in this guide.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 18ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

5.2.1 Reading Element Definition TableThe Detailed Element Definitions table is organized to represent the XML tags expected in the ACORDLAH Reinsurance messages in the order that they are expected. However, to keep the table as conciseas possible, XML “nesting” is represented as a series of highlighted and annotated rows, with childelements that follow.As an example, consider the following XML structure:Some TextSome Text© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 19ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

This would be represented on the Detailed Element Definitions table as follows (column names havebeen removed to simplify the example):Root AggregateChild of @idNote the bolding and background highlighting. Thisindicates the beginning of an XML aggregate. The textunder the element name tells us that this element is themessage root tag.The text following the aggregate name tells us thatAddress is a child element of Message, as shown in ourXML sample.Regular (i.e. non-aggregate) elements that follow anaggregate section are assumed to be child elements ofthe current aggregate section. In this case, id is a child of. The @ character indicates that this is anattribute (see Column Definitions below). must follow in the XML message.5.2.2 Element Definition Column TerminologyThis section provides information useful for interpreting the information found in each column of theElement Definition Table.5.2.2.1 Element ColumnThis column contains the names of XML tags and attributes used in Reinsurance messages.Tags are shown in the order that they are expected to appear in an XML message.XML tags are represented as a tag name between angle brackets. For example, is anXML tag.Attributes are shown with a preceding at-sign (i.e. “@”). For example, @Version is an XMLattribute.5.2.2.2 Type ColumnThe XML type associated with the tag is shown in the Type column. The types found here are as follows:Aggregate – This indicates that the Element is an XML aggregate. In XML, an aggregate wouldbe called a complexType. In simpler terms, an XML aggregate is a tag that has child tags.Boolean – Note that this is NOT a W3C Schema type. This is a conditional indicator that isbased on an ACORD Lookup (see documentation for Lookup type below). This is documentedas a Lookup (under “Boolean”) in the full ACORD LAH Standard.Currency – ACORD name for W3C Schema type of xsd:decimal. The value is expected to be amonetary amount.Date - Based upon the W3C Schema type of xsd:date. ACORD dates are formatted as YYYY-MM-DD.ID – ACORD name for W3C xsd:ID type. This is an XML-specific construct. For moreinformation, please refer to www.w3.org/XML/.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 20ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

IDREF – ACORD name for the W3C xsd:IDREF type. This is an XML-specific construct. Formore information, please refer to www.w3.org/XML/.Integer – ACORD name for W3C xsd:integer.Lookup – Indicates that the element is an enumerated list. The full name of the enumeration willappear, following the Lookup keyword. In the ACORD LAH Standard, an enumerated list iscalled a “lookup” or a “type code.”ooLookups have a specific format. Please refer to the “How to handle typecodes” section ofthe full ACORD Standard.While the Remarks column associated with the lookup may indicate the expected orallowable values for the enumeration, the full list of enumerated values may be found inthe ACORD LAH Standard. For example, if the element type is Lookup: TransactionType, the list of enumerated values may be found be referring to the “Transaction Type”lookup in the full ACORD LAH Standard.Percent – Used for percentage values. Note that percentages are assumed to imply two decimalplaces. This means that 8.5% is represented as “8.5” in the XML stream, NOT as “0.085”.String – This is an alphanumeric representation based on xsd:string. Leading and trailing spacesof a string should be removed.System Key – ACORD type used to identify System Keys for aggregates. Please refer to DataType Conventions in full ACORD LAH Standard.Time - Based on xsd:time. Times MUST include a time zone. Refer to full ACORD LAHStandard under the “Data Type Conventions” section.5.2.2.3 Usage ColumnThis column describes how an element must be used in the message. Possible values include:Conditional – A conditional element is sometimes required under one or more specificconditions. The condition or conditions that make an element required will be described in theRemarks column. For example, the guide may state that if a “Deposit Date” is specified, then the“Deposit Amount” must be specified as well. In this case, the “Deposit Amount” element wouldbe described as conditional and the Remarks column would indicate something like, “Requiredwhen Deposit Date valued.”Additionally, the conditions must be measurable by examining other elements of the message.That is, the Receiver of the message must be able to determine if the condition has beenfollowed (or not) by only examining the message. For example, it may seem logical to documenta coverage‟s “termination date” as being conditional with a Remark of something like, “Requiredif the coverage is terminated.” However, in this case, the receiver of the message would have noway of determining if a missing termination date constituted an invalid message.Optional – This indicates that the message is considered valid even if the element is notincluded. Receivers of the message must be able to process the message without the presenceof this element; and Senders are not required to include it.In all cases, it is expected that if the Sender of the message “knows” the associated information;then the Sender SHOULD include it. Thus, it is possible to interpret almost any optional elementas being conditional. For example, almost any message will define a coverage‟s “terminationdate” as optional, since an active coverage would have no such date. However, if the Senderknows a coverage‟s termination date, the Sender SHOULD include it in the message. Failure todo so will not invalidate the message; however, it may invalidate the accuracy of the response.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 21ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

In the above example then, the guide would simply document that a coverage‟s termination dateis optional. The guide would not include an explicit statement requiring that the Sender mustinclude the termination date if the coverage is to be considered terminated. Such a statement isassumed and would otherwise need to be included on every element defined in the guide.Prohibited – This is a rarely used indicator that means an element MUST NOT be included in amessage. For an aggregate, an undocumented child element is assumed to be prohibited.However, prohibited is still occasionally used where the guide authors believe the situationwarrants an explicit warning. For example, usage may be commonly misunderstood and/orposes unusually high potential for causing harm. As an analogy, this is similar to a flashing,speed limit sign in traffic areas where speeding has been a problem. Technically, this shouldnever be needed. But some situations warrant it.Repeating – This indicates that the specified element may appear more than once in themessage. This is a modifier that, when used, is combined with one of the other Usages. Forexample, “Required, Repeating” would indicate that the element must appear at least once in themessage, but may also repeat more than once. Thus, in this example, the repeated elements(second, third, fourth, etc) are always technically optional. If an element does not repeat, thenthe repeating keyword will not appear in the Usage column.Required – This indicates that an element is structurally required to be present. If this element isnot present, the message is considered invalid. Note that strings are allowed to be empty (a.k.a.blank or null). Thus, it is possible in this situation to send an empty tag and satisfy the requiredusage of the element. Strings are the only tags that allow this behavior. For more information onthe interpretation and use of “empty tags,” please refer to the full LAH Messaging Standard under“How to handle Empty Tags using ACORD Schema.”It is important to note that in this guide, required behaves the same as setting an element‟s“minOccurs” clause to 1 in an XML Schema. In non-technical terms, this means that if theelement‟s parent aggregate is optional or conditional and the parent aggregate is not present inthe message; the element is not required. Technically then, this makes all required elementsconditional (see “Conditional” above). However, required is a commonly accepted term todenote this specific type of structural "condition."For example, a message might define that an Organization‟s “Doing Business As” element (i.e.“DBA”) is required. However, when a Party represents a Person, it would not use theOrganization aggregate and as such, the DBA element would not be required in the message.5.2.2.4 Remarks ColumnThis column contains additional comments or usage notes regarding an element.5.2.3 Detailed Element DefinitionsElement Type Use RemarksRoot AggregateAggregate Required Starting node of all ACORD businessmessages@Version String Required Specifies the ACORD Life Standardversion used to produce this message.For this implementation this should be setto 2.18.01© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 22ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Child of Aggregate Required Required message wrapper for allACORD messagesNote: We repeat this for every policy sothat each policy will have its ownTransRefGUID. String Required This is the unique identifier created byClient application. This is provided by theapplication and it is then echoed back inany response to allow the clientapplication to match the response with therequest.Lookup:TransactionTypeLookup:TransactionSub TypeRequiredRequiredMust be 551. Indicates the LifeReinsurance Activity messageMust be one of:55101 – Reinsurance Policy Activity55102 - Reinsurance Policy Status55103 – Reinsurance Policy Activityor Status Date Required The date the transaction was transmitted. Time Required Same as but for time.Based on xsd:time representation is to beused in either of the following formats:14:53:45Z - time, in UTC14:53:45-07:00 - time, w/ time zone (+/-hh:mm) Boolean Required For this implementation set flag to TRUE. Boolean Required If set to True, indicates that this is a testfile. A test file should not be processedagainst live data. This is set to False if nota test file.Child of Aggregate Required Information regarding the specifics of thismessageDate Required Start date of the reporting period for thisrecord Date Required End date of the reporting period for thisrecord Lookup:ReinsuranceTransactionModelRequired 1 = Direct Insurance Values (source is thedirect insurer)2 = Reinsurance Values (source is thereinsurer)If code is set to 2, the request is fromreinsurer to retro and the data valuesapply to reinsurance info entities only.Child of AggregateConditionalRepeatingPolicy Activity ListUsed to report a single Policy Activity.Repeat PolicyActivitList for each activity© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 23ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

eing reported for this policy.Only used if is PolicyActivity or Policy Activity or Status. Integer RequiredMust be present if is"Policy Activity" (tc=55101). May bepresent if is "PolicyActivity or Status" (tc= 55103). Must NOTbe present if is "PolicyStatus" (tc=55102).Sequence NumberControls the sequence of Policy activitybeing reported. This field must be used torepresent the correct order of policyactivities. Note that since repeats, one mayincorrectly assume that when one entry physicallyappears before another in the XMLmessage that this implies that it should beprocessed first. However, Physical orderof in the XMLdocument does not imply the sequence ofactivity on the policy. NUST begin with 1 for the firstactivity and then increment by 1 for eachsubsequent activity (e.g.. 1, 2, 3, and 4).Lookup:ReinsurancePolicyActivityRequiredPolicy ActivityThis is a code that identifies the specificactivity. Date RequiredEnd of This corresponds directly to the PolicyActivity Indicator (or Transaction Code)Code list for element ATT-C956-9021Attribute in the EDIFACT LREACTmessage. For a complete list of activitycodes, refer to the ACORD StandardDocumentation under the ReinsurancePolicy Activity look up.Policy Activity DateThe date that the transaction waseffective.Child of Aggregate Required Beginning node of the ACORD Life Datamodel.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 24ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Child of Aggregate Required Provides information about the sender ofthe message, useful for later identificationor for sending message specific notes tothe receiver.This may be used by the sender toidentify the source file of the transaction. Date Required Creation date of the file.Based upon the W3C Schema type ofxsd:date. ACORD dates are formatted asYYYY-MM-DD. For example, to indicateMay the 31st, 1999, one would write:1999-05-31 Time Required Creation time of the file. String OptionalBased on xsd:time representation is to beused in either of the following formats:14:53:45Z - time, in UTC14:53:45-07:00 - time, w/ time zone (+/-hh:mm)The name of the source of the file. Thiscould reflect the company or productname. String Optional String OptionalThis could also be the file name of theceding company‟s block of business.Additional information specificallyregarding the source of the file.A comment supplied by the source of thefile. This could also identify the vendorsystem and release number. String Optional An identification used by processingsystems to identify this particular file.End of Child of Aggregate Required HoldingA Holding is the container for all policyinformation. For all reinsurancemessages covered by this guide, aHolding will always be used to represent aPolicy.Only one Holding is allowed per eachTXLifeRequest. TXLifeRequest may berepeated for multiple policies in a singleXML stream.@id ID Required The id must be defined and be unique for© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 25ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Lookup:HoldingTypeRequiredevery holding in this message stream.Type of Holding...Asset, Liability, Policy,etc.Holding Type Code must be set to 2 =PolicyLookup:HoldingStatusLookup:CurrencyType CodeRequiredRequiredHolding Status must be set to one of:1 = Active2 = Inactive (e.g. Terminated)It is assumed that all currency fields forthis object (including sub-objects) are ofthe same currency type. Some examplesinclude but are not limited to the following.124 = Canadian Dollar840 = United States Dollar Date RequiredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.As of date of information.This is the report date for the Holdinginformation.Child of AggregateRequiredPolicy ObjectThe key is CarrierCode, ProductCode,PolNumberIt contains all the policy properties thatare generic across insurance policy types. String Required Policy Number Lookup: RequiredLine ofLine of business of the insurance.BusinessMust be set to 1 = Life String RequiredDisability Income and Long Term Careare not supported at this time.Product CodeThis is a Direct Writer assigned codeused to uniquely identify the underlyingproduct of the policy. String Required This code uniquely represents theInsurance Carrier. For this implementationthis will be the Direct Writer‟s NAIC Code.NOTE: For non-US countries use theAMBest code as assigned by the NAIC. String Required Full name of the Plan which is supplied bythe Direct Writer. This is the complete,© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 26ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

official, and/or legal name used for thispolicy/coverage/option. String Optional Abbreviated or Short Name of the Plan.Note that the ShortName field typicallycontains the NAIC Marketing Name in theU.S or marketing name for non-UScountries.Lookup:PolicyStatusRequiredType code for the status of the PolicyMust be one of:1 = Active2 = TerminatedLookup:NationConditionalIndividual reinsurers may not acceptterminated policies. The sender shouldvalidate that the receiver can handleterminated policies before transmittingthem.Nation where policy was issued. Forexample, use:1 = United States of America2 = CanadaFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Lookup:StateConditionalIf IssueNation is not US or Canada thenthis information must be provided.Required if Jurisdiction is not specified.Jurisdiction of a Policy.This will contain the issue state (orCanadian province) information. Useappropriate value from the State Codetable. For example, use:1 = Alabama2 = AlaskaFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Lookup:ReplacementTypeRequiredRequired if IssueNation is US or Canada.Also required if IssueNation is notspecified.Replacement TypeIndicates if the policy is a replacement,exchange, or conversion.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 27ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Note that the ReplacementType MAY beused to specify "None" (tc=1). Thus,implementers MUST NOT assume thatthe presence of this property means thatthe policy is a replacement. Rather, thepolicy is known to be a replacement ifReplacementType is present AND itsvalue is other than "None" (tc=1). Integer Optional Date RequiredIn this context, if the value ofReplacementType is Unknown (tc=0), thisindicates that the policy IS known to be areplacement – but the type ofreplacement is unknown.Duration in years based on current pointin time.NOTE: Duration would be calculated fromthe original effective date of theCoverage, even if the Coverage wasconverted. The only exception would be ifthe Coverage number changed, then itwould be from the effective date of thenew Coverage number.This is the date the policy becameeffective.If the policy is the result of a conversion,or a continuation, EffDate represents theeffective date of the new, convertedpolicy. Note that while this is commonlyreferred to as the "converted date;"EffDate is, in all cases, interpreted tomean the effective date of the Policy. Forthe effective date of the original policy inthis situation, see PriorEffDate below. Date RequiredFor the effective date of the reinsurance,see ReinsuranceEffDate under theReinsuranceInfo aggregate discussedbelow.Policy issue dateThis is the original policy issue date of thecurrent policy number, regardless ofwhether it resulted from new business orfrom continuation (rewrite/conversion). Date Conditional Prior effective date of Policy. Holds thepolicy effective date prior to conversion orrewrite. Only used if this is a convertedpolicy.In the case of a conversion, replacement,© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 28ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

exchange or reissue, this is the originaleffective date of the policy. String Conditional Prior Policy number (immediate priorpolicy number. This does not trackseveral numbers prior). Policy numberprior to conversion or rewrite. Only used ifthis is a converted policy.Child of Aggregate Required Life uses the object for mostpolicy details.Child of AggregateRequired,RepeatingA reinsured component of a policy.Coverage defines or limits the provisionsand obligations under a life insurancepolicy.A Coverage is used to represent anycomponent of a Policy that may beindividually reinsured. Thus, a coveragemay be is represent and of the conceptscommonly referred to as benefits, riders,provisions, elections, or even the baseplan.For example, an individual Insurer MAYuse "CovOption" on the base coverage torepresent an Accidental Death Benefit(ADB) rider. This is technically allowedand could apply to New Businessmessages, Case Status messages, etc... ;However, when representing ADB in areinsurance message; it MUST bemodeled using the Coverage aggregate.This is especially important since theReinsuranceInfo aggregate (used torepresent a Reinsurance Treaty) existsonly as a child of Coverage. Thus, thestructure allows individual Coverageaggregates to be reinsured, but notCovOptions. This also greatly simplifiesthe message consumption process forreinsurers and retrocessionaires that workwith multiple insurers because only onemethod of modeling this information needbe supported. String Optional Full name of the Plan which is supplied bythe Direct Writer. This is the complete,official, and/or legal name used for thispolicy/coverage/option. If not specified,the Coverage PlanName defaults to thePlanName specified on the Policy.NOTE: This information must be provided© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 29ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

String Optional String RequiredLookup:PolicyStatusLookup:Issue TypeRequiredRequiredif the Plan Name is different from thePolicy level.Product CodeThis is a Direct Writer assigned codeused to uniquely identify the underlyingproduct of the coverage. In this case it willbe the Plan Code information. If notspecified, the Coverage ProductCodedefaults to the ProductCode specified onthe Policy.NOTE: This information must be providedif the product code is different from thePolicy level.This is a unique Internal SystemCoverage NumberStatus of CoverageFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Underwriting class for this coverage,(e.g.., Guaranteed Issue).For example, use:1 = Full Underwriting2 = Simplified Underwriting3 = Guaranteed IssueFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Lookup:CoverageType CodeRequiredType of coverage or product.For example, use:23 = Accident Death Benefit41 = Waiver on DisabilityLookup:CoverageIndicatorCodeRequiredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Coverage classification.For example, use:1 = Base2 = RiderLookup:Lives TypeRequiredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Type code indicating description of therelation between the participants and the© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 30ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

coverage.For example, use:1 = Single life2 = Joint – First To DieLookup:DeathBenefitOption TypeRequiredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Option chosen for this contract whichwould affect the death proceeds.For example, use:1 = Level2 = Increasing (DB = Face + Cash)3 = Increasing (DB = Face + Return ofCumulative Premiums)For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Integer Required The issue age used for the coverage.Used in lieu of a substandard rate onsingle life coverages and as a joint age onjoint coverages. This can also be viewedas an override for age calculations.For example:Individual - issue age is increased foradded risksJoint Age -- 2 people that are combinedwhere a single age is used. Currency Optional Initial face amount of the coveragewithout options.The amount of the coverage as initiallyissued. It does not include amountsassociated with any options. Currency Required Current Amount of coverage -- the faceamount of the base rider/benefit, withoutoptions.This may or may not be the same as theinitial coverage face amount (for example,if the face amount changes over time).This is the full amount of the coverage(including retention), usually used foraudit purposes. Note: This is NOT theNet Amount of Risk. See NetAmtAtRiskon ReinsuranceInfo. Date Required Coverage effective date.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 31ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

This is the date the coverage becameeffective.If the coverage is the result of aconversion, or a continuation, EffDaterepresents the effective date of the new,converted coverage. Note that while thisis commonly referred to as the "converteddate;" EffDate is, in all cases, interpretedto mean the effective date of theCoverage. For the effective date of theoriginal coverage in this situation, seePriorEffDate below (also on Coverage).Lookup:BenefitPeriodOptionalFor the effective date of the reinsurance,see ReinsuranceEffDate under theReinsuranceInfo aggregate discussedbelow.This indicates the period for whichbenefits are payable. For example, on a5yr term, it should indicate 5 for benefitperiod. Date ConditionalFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.The date the coverage is no longereffective.Lookup:UnderwritingClass CodeRequiredMust be specified if LifeCovStatusindicates that the coverage is terminated.Insured's underwriting class - Preferred orStandard. This is similar to EquivalentAgebut used for underwriting class. Forexample, use:1 = Standard7 = Uninsurable2 = PreferredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Integer Optional Duration in years based on current pointin time.When used on Coverage, it representsthe year number (count) that indicates theduration of time that the Coverage hasbeen in effect in whole years, starting inyear 1. For example, a Coverage that wasinitially effective on 2000-06-30 wouldhave a Duration value of 5 on 2005-03-29, but would have a Duration value of 6© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 32ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

as of 2005-07-01.Lookup:GenderTypeRequiredNOTE: Duration would be calculated fromthe original effective date of the Policy,even if the Policy was converted. The onlyexception would be if the Policy numberchanged, then it would be from theeffective date of the new Policy number.The gender rate basis under which thecoverage was issued. When at thecoverage level, it represents the genderused for issuing the coverage. It is onlyused for joint coverages, where you needto know how the coverage itself was soldregardless of the individual's issuegenders. It correlates to similar fields forEquivalentAge,EquivalentUnderwritingClass, andTobaccoPremiumBasis. For example,use:1 = Male2 = Female3 = UnisexFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. String Conditional Coverage number prior to conversion orrewrite. Used only if this is a convertedpolicy.In the case of a conversion, replacement,exchange or reissue, this is the originalcoverage number of the coverage.Required if Policy/ReplacementType isOTHER than "None" (tc=1).Lookup:Joint AgeType CodeConditionalThe method to be used to calculate thejoint age.Required if LivesType is one of the “Joint”types.For example, use:1 = Exact Age Used2 = Frasier Method3 = Joint EquivalentFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Date Conditional Holds the coverage effective date prior toconversion or rewrite. Only used if this isa converted policy.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 33ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

In the case of a conversion, replacement,exchange or reissue, this is the originaleffective date of the plan.Required if Policy/ReplacementType isOTHER than "None" (tc=1).Child of AggregateRequired,RepeatingWhen Life Product, must have at leastone LifeParticipant representing theinsured off the coverage.Note the only LifeParticipant valid in thismessage is an insured participant. Whileother types of participants may beassociated with a coverage, thereinsurance messages documented bythis guide are only concerned with insuredparticipants at this time.@PartyID IDREF Required Reference to @id of Party described onthis Coverage. Party aggregate willcontain information for the Party that isindependent of the Coverage. System Key Optional Unique system key that identifies theinsured.Lookup:ParticipantRoleOptional If present, then this MUST be set to oneof the valid “Insured” codes. The codemust be one of the following:1 = Insured2 = Other Insured3 = Insured Child4 = Insured Dependent5 = Insured Spouse Integer Required Age of participant when coverage wasLookup:NationConditionalissuedResidence nation at time of issue. Forexample, use:1 = United States2 = CanadaFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Lookup:StateConditionalIf ResidenceNationAtIssue is not US orCanada then this must be specified.Required if ResidenceJurisdictionAtIssueis not specified.Residence state at time of issue. This willcontain the issue state information. Forexample, use:1 = Alabama© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 34ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

2 = AlaskaFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Required if ResidenceNationAtIssue isUS or Canada. Also required ifResidenceNationAtIssue is not specified. Currency Optional Permanent flat extra amount. Onsubstandard risks, this amount is anadditional charge to the insured for the lifeof the policy. Because the insuredrepresents a higher risk to the company,the flat extra is charged to compensate forthat risk.Lookup:TobaccoPremiumBasisRequiredThis is the actual premium rate basis.Tobacco Premium Basis. For example,use:1 = Non-Smoker2 = SmokerLookup:TableRatingsOptionalFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Mortality basis. Permanent table rating forbenefit.This is an optional field that may beincluded for comparative or informationalpurposes.A table of valuation of risk of an individualor organization. This is the permanentrating according to this table for thisindividual or organization. For example,use:Table A (tc=2)Table AA (tc=3)Table B (tc=4)For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Warning: PermTableRating is an optionalshorthand that may be included in themessage. However, if the LifeParticipanthas a "permanent rating;" the percentageload MUST be specified inPermPercentageLoading specified below.This is true, even if the Table Rating is not© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 35ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

specified here.Lookup:TableRatingsOptionalPlease see Table Ratings vs. PercentageLoad for more information.Temporary table rating for benefit.This is an optional field that may beincluded for comparative or informationalpurposes.A table of valuation of risk of an individualor organization. This is the permanentrating according to this table for thisindividual or organization. For example,use:Table A (tc=2)Table AA (tc=3)Table B (tc=4)For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Warning: TempTableRating is an optionalshorthand that may be included in themessage. However, if the LifeParticipanthas a "temporary rating;" the percentageload MUST be specified inTempPercentageLoading specified below.This is true, even if the Table Rating is notspecified here.Please see Table Ratings vs. PercentageLoad for more information. Date Conditional End date that temporary table rating is ineffect.Required if isspecified with a value other than 0. Date Conditional Temporary flat extra end date.Use either or as notedfurther down. or is required if is specified with avalue other than 0. Currency Optional Temporary flat extra amount. Onsubstandard risks. This amount is anadditional charge to the insured for apredetermined period of time, such as five© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 36ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Lookup:Flat ExtraBasis CodeOptionalyears. The idea here is the same as forthe Permanent Flat extra (compensatingfor additional risk). However, in this case,the risk is not regarded as perpetual. Ifthe insured lives beyond, say five years,he/she can be regarded as a standardrisk. A temporary flat extra might be usedwhere the insured recently had serioussurgery, yet if he/she survives thatsurgery by x amount of years, he/she canbe regarded as a standard risk.Flat Extra Basis tells what amount to useto determine the flat extra premium. Forexample, use:1 = Flat Extra based on Face Amount ofcoverage2 = Flat Extra based on amount at riskLookup:UnderwritingClassRequiredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Underwriting Class. For example, use:1 = Standard7 = Uninsurable2 = PreferredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Integer Conditional Duration of the temporary flat extra.Lookup:AgeCalculationMethodOptionalIf TempFlatExtraAmt is specified, theneither or MUST be specified.Indicates the algorithm used to determinethe Issue Age' of the insured, given theirdate of birth and the effective date of thepolicy.Examples include:1 = Age Next Birthday2 = Age Last BirthdayFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Percent Conditional Temporary Mortality basis. This is thetemporary loading for this benefitrepresented as a percentage.MUST be specified if is specified with a value other than1=None.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 37ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

MUST be specified if is specified.Warning: TempTableRating is an optionalshorthand that may be included in themessage. However, if the LifeParticipanthas a "temporary rating;" the percentageload MUST be specified with this element.This is true, even if the Table Rating is notspecified in TempTableRating.Please see Table Ratings vs. PercentageLoad for more information. Percent Conditional Mortality basis. This is the permanentloading for this benefit represented as apercentage.MUST be specified if is specified with a value other than1=None.Warning: PermTableRating is an optionalshorthand that may be included in themessage. However, if the LifeParticipanthas a "permanent rating;" the percentageload MUST be specified with this element.This is true, even if the Table Rating is notspecified in PernTableRating.End of Child of Please see Table Ratings vs. PercentageLoad for more information.Aggregate Optional Used to communicate any contractuallyobligated benefit that further describes orlimits the provisions and obligations of theparent coverage.Note that this aggregate is optional andnot commonly used. In fact, thisinformation is not exchanged by anycompany participating in the creation ofthis guide. However, it was left as anoptional aggregate to allow for possiblefuture use.An example of a CovOption would be an"Auto Increasing" benefit thatcontractually obligates the insurer toincrease the face amount of the parentcoverage each year.Even in the above example however, no© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 38ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

known Cedent (participating in thecreation of this guide) reported thisinformation to the reinsurer. The statedrationale is that this option may bechanged at any time and is notconsidered relevant to reinsurers.Instead, when the option was applied (i.e.when the face amount increased), theCedent would use a "Policy Activity"message to report the actual change.@LifeParticipantRefID IDREF Optional Only used when:A) More than one LifeParticipant on theCoverage has the role of an “Insured” (asspecified by LifeParticipantRoleCode)ANDB) The CovOption only applies to one ofthe insured‟s found on the Coverage.In this case, use @LifeParticipantRefID torefer to the LifeParticipant to which theCovOption applies. String Optional Full name of the Plan which is supplied bythe Direct Writer. This is the complete,official, and/or legal name used for thispolicy/coverage/option. If not specified,the PlanName for the CovOption defaultsto the PlanName of the Coverage.NOTE: This information must be providedif the Plan Name is different from thecoverage level. String Optional This is a Direct Writer assigned codeused to uniquely identify the underlyingproduct of the coverage option. In thiscase it will be the Plan Code information.If not specified, the ProductCode for theCovOption defaults to the ProductCode ofthe Coverage.Lookup:PolicyStatus CodeLookup:Issue TypeRequiredRequiredThis information must be provided if theproduct code is different from thecoverage levelStatus of the Coverage OptionFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Underwriting class for this coverageoption, (e.g.., Guaranteed Issue).For example, use:1 = Full Underwriting2 = Simplified Underwriting© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 39ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

3 = Guaranteed IssueLookup:Option TypeLookup:TobaccoPremiumBasisLookup:TableRatingsRequiredOptionalOptionalFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Benefit TypeFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Tobacco Premium Basis. For example:1 = Non-Smoker2 = SmokerFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Permanent table rating for an option.This is an optional field that may beincluded for comparative or informationalpurposes.A table of valuation of risk of an individualor organization. This is the permanentrating according to this table for thisindividual or organization. For example,use:Table A (tc=2)Table AA (tc=3)Table B (tc=4)For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Warning: PermTableRating is an optionalshorthand that may be included in themessage. However, if the LifeParticipanthas a "permanent rating;" the percentageload MUST be specified inPermPercentageLoading specified below.This is true, even if the Table Rating is notspecified here.Lookup:TableRatingsOptionalPlease see Table Ratings vs. PercentageLoad for more information.This is an optional field that may beincluded for comparative or informationalpurposes.A table of valuation of risk of an individual© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 40ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

or organization. This is the permanentrating according to this table for thisindividual or organization. For example,use:Table A (tc=2)Table AA (tc=3)Table B (tc=4)For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Warning: TempTableRating is an optionalshorthand that may be included in themessage. However, if the LifeParticipanthas a "temporary rating;" the percentageload MUST be specified inTempPercentageLoading specified below.This is true, even if the Table Rating is notspecified here.Please see Table Ratings vs. PercentageLoad for more information. Date Optional End date that temporary table rating is ineffectLookup:UnderwritingClassOptionalUnderwriting Class. For example, use:1 = Standard7 = Uninsurable2 = Preferred String RequiredFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.Carrier's nomenclature (or marketingname') for this underwriting class. Currency Optional Temporary flat extra amount. Onsubstandard risks, this amount is anadditional charge to the insured for apredetermined period of time, such as fiveyears. The idea here is the same as forthe Permanent Flat extra (compensatingfor additional risk); however, in this casethe risk is not regarded as perpetual, but ifthe insured lives beyond, say five years,he/she can be regarded as a standardrisk. A temporary flat extra might be usedwhere the insured recently had serioussurgery, yet if he/she survives thatsurgery by x amount of years, he/she canbe regarded as a standard risk.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 41ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

MUST be specified if is specified. Date Optional Temporary flat extra end date. Use eitherthis or . or is required if is specified with avalue other than 0. Currency Optional Permanent flat extra amount. Onsubstandard risks, this amount is anadditional charge to the insured for the lifeof the policy. Because the insuredrepresents a higher risk to the company,the flat extra is charged to compensate forthat risk.Lookup:Flat ExtraBasis CodeOptionalFlat Extra Basis tells what amount to useto determine the flat extra premium. Forexample, use:1 = Flat Extra based on Face Amount ofcoverage2 = Flat Extra based on amount at riskFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.. Date Required Option effective date.The date the option became effective. Date Conditional The Date No Longer AvailableLookup:BenefitPeriodOptionalThe date the option is no longer in force.Must be specified if CovOptionStatusindicates that the option is terminated.Provide when coverage has adeterminate benefit period.For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Integer Optional Duration of the temporary flat extra. Usethis and/or Integer Optional Duration in years based on current pointin time Currency Conditional Amount of option.OptionAmt MUST be specified ifOptionPct is not specified. Percent Conditional Percent of option.OptionPct MUST be specified ifOptionAmt is not specified.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 42ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

End of Child of AggregateRequired,RepeatsInformation about the reinsurance on thisCoverage as it applies to a singlereinsurer. This would be theReinsuranceInfo as it applies to thereinsurer's participation in the transactionand would repeat only in situations wherethere is more than one cession record forthe reinsurer.All messages in this guide require at leastone ReinsuranceInfo aggregate. String Required A unique identification number assignedby Cedent String OptionalA unique identifier assigned by thereinsurerLookup:ReinsuranceRisk BasisRequiredThe basis the risk was evaluated whenthe business was assumed.For example:1 = Automatic4 = Facultative5 = Facultative Excess6 = Facultative Obligatory, Jurisdictionunspecified11 = Special Case Consideration14 = European Facultative Obligatory…..For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Date Required The date the reinsurance is effectiveGenerally the same as the AddedDateexcept for reinsurance affected en masseon an already existing inforce block ofbusiness such as could occur when areinsurer is replaced by another.Lookup:ReinsurancePurchaseMethodLookup:PaymentModeRequiredRequiredThe method used to purchasereinsuranceFor example:1 = Yearly Renewable term2 = Coinsurance……For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation.The mode the reinsurance premium ispaidFor example:1 = Annually4 = Monthly© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 43ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

For a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. Date Optional The date to which reinsurance premiumshave been paid. This may be associatedwith policy status among others. Currency Required The amount reinsured Currency OptionalThe amount of coverage face that theceding company is retaining. Currency OptionalCurrencyOptional Currency OptionalCurrencyOptional Currency Required Currency Optional Currency Optional Currency Optional Date Optional Integer OptionalFor coverages that have an increasingrisk amount, this is the maximum amountthat will ever be reinsured. Conditionalbased on increasing products.This is the reinsurer's portion of the stateor province premium tax.Expense allowance for policy fee when"coinsurance" reinsurance is in effect.This is the reinsurer's amount of thiscoverage's premium to be waiver (whenwaiver is in effect), calculated based onthe proportion of the Waiver of Premiumcoverage that was reinsured.The net amount of risk for this coverage.Reinsured cash surrender value to bepaid when the policy is surrendered.Reinsured policy dividend amount to berecovered upon termination.For Life policies, this is a flat amountadded to the basic premium rate to reflectthe cost of issuing a policy, establishingthe required records, sending premiumnotices, and other related expenses.The beginning date of the current periodfrom which the reinsurance Premium ispaid.Duration of reinsuranceCould differ from the coverage issue datewhen added after issue or on aconversion. String Conditional This is the reinsurer‟s NAIC code whenthe cedent is the reinsurer. Otherwise, thedirect writer‟s carrier code is already© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 44ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

available under the policy information.Required when used between thereinsurer and the retro. Real Optional The percentage of the face amount of aninsurance contract ceded by theinsurance company to the reinsurer. If apercentage is indicated the agreement isquota share, if not the agreement isexcess. String Conditional This should hold the reinsurer‟s plan codeinformation. Otherwise, the direct writersproduct code is already available underpolicy and coverage informationRequired when used between thereinsurer and the retro. String Optional The unique identifier or set of identifiersthat links this block of business to thespecific reinsurance terms. This may be apool, layer, or statement name or numberand is usually a subset of the treaty. Currency Conditional The gross (i.e. before reinsuranceexpense allowance) premium paid bycedent to reinsurer for standard risks.This is based on the mode that the cedentis paying the reinsurance company (notthe policy owner's mode). Either net orgross premium must be supplied. Currency Conditional The net premium amount (i.e. afterreinsurance expense allowance) paid bycedent to reinsurer for standard risks.Either net or gross premium must besupplied.Currency Optional The gross amount payable to the cedingcompany by the reinsurer in lieu of actualcommissions and expenses incurred bythe ceding company. Use for standardrisks. Currency Optional The net amount payable to the cedingcompany by the reinsurer in lieu of actualcommissions and expenses incurred bythe ceding company. Use for standardrisks. Currency Optional The gross premium paid by cedent toreinsurer coverage for substandard risks,not including flat extras Currency Optional The net premium amount paid by cedentto reinsurer for substandard risks, notincluding flat extras.CurrencyOptionalThe gross amount payable to the cedingcompany by the reinsurer in lieu of actual© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 45ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

commissions and expenses incurred bythe ceding company. Use for substandardrisks, not including flat extras.Currency Optional The net amount payable to the cedingcompany by the reinsurer in lieu of actualcommissions and expenses incurred bythe ceding company. Use for substandardrisks, not including flat extras. Currency Optional The net extra premium paid by cedent toreinsurer charged to cover any extrahazard or special risk such as aviation orhazardous activities.End of End of Currency Optional The net amount payable to the cedingcompany by the reinsurer. in lieu ofactual commissions and expensesincurred by the ceding company, to coverextra risks.Currency Optional The gross extra premium paid by cedentto reinsurer, charged to cover any extrahazard or special risk such as aviation orhazardous activities.Currency Optional The gross amount payable to the cedingcompany by the reinsurer, in lieu of actualcommissions and expenses incurred bythe ceding company, to cover extra risks.Child of Aggregate Optional The Application Info object containsinformation about the application itself aswell as the application process Lookup: State Optional Application StateStringOptionalApplication CountyLookup:NationOptionalCountry where application was signed.DateOptionalDate the application was signed by theApplicant(s)On ApplicationInfo, if multiple applicants,then use the date the 'primary' applicant orannuitant (the "primary person") signed theapplication for SignedDate here and thenrecord remaining additional signature datesinApplicationInfo.SignatureInfo.SignatureDate.If additional information is needed aboutthe primary person's signature such as the© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 46ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

city where the application was signed, thenuse the SignatureInfo object to capture theadditional details. The SignedDate and theSignatureDate must both be valued withthe same date when theSignatureRoleCode corresponds to the rolerepresented by ApplicationInfo.SignedDate.End of Child of AggregateOptionalRepeatingAttachment is used to represent billingcomments associated with activities.Attachment is optionally used only for thePolicy Activity transaction(TransSubType=55101) or the PolicyStatus and Activity transaction(TransSubType=55103).If TransSubType is 55102 thenAttachment must not be used.Lookup:AttachmentType CodeRequiredThis is data type of the attachment.Must be:1 – Text OnlyStringRequiredRepresents the text of the comment.Lookup:AttachmentTypeRequiredIndicates type of attachment.Must be:2 - CommentLookup:AttachmentLocationRequiredIndicates where the physical attachment islocated.Must be:1 – Inline DataEnd of End of Child of AggregateRequired,RepeatingThe party object represents the basicinformation that applies to an insured onthe policy.The properties of Party represent thecurrent state of the Person, whereas theproperties in LifeParticipant (under© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 47ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Coverage) represent the state of the Partyat the time the Coverage was issued.@id Required RequiredLookup:Party TypeOptional String Required String OptionalEvery Party must be referenced by aLifeParticipant aggregate (underCoverage).ID A unique XML ID used as a referencefor a given XML documentIf specified, must be set to “1” for Person.The Reinsurance messages in this guideare only concerned with parties that areinsured by one or more coverages of thepolicy. For this reason, it is expected thatany Party included in this message mustbe a Person.Full NameOn Party, this captures a full name inwhatever format in which it has beencaptured by the sending application.Government Provided IdentificationNumber.Data should be stored as a string with NOformatting. For instance, in the USA, asocial security number is stored as123554321.

2 = CanadaFor a complete list of valid codes, pleaserefer the full ACORD LAH Standarddocumentation. String OptionalRequired if ResidenceCountry is not USor Canada.Residence zip code for US or postal codefor non-US countriesAggregate Required A type of Party.Child of String Required First name of the person String Optional Middle name of the person String Required Last name of the person String Optional TitleLookup:GenderTypeRequiredGender of the person MUST be one of:1 = Male2 = Female Date Required Date of birth for the personEnd of End of End of End of End of © 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 49ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

6 GLOSSARY & INDEX6.1 IndexACORD Standard or Standard: Refers to the applicable ACORD Life, P&C/Surety, or ReinsuranceStandards. These are the official specifications.ACORD Standards Program or Program: Refers to the ACORD Standards Operating Procedures,Guidelines and Polices used by ACORD in the governance of a particular Standard. These rules governhow the Standards are developed and managed.6.2 Glossary of TermsAccidental Death Benefit (ADB) –A rider that provides an additional death benefit above the face amount of a policy if aninsured‟s death occurs as the result of an accident.Allowance –A proportionate share of the agent commissions, underwriting costs, policy issue costs,premium taxes, and other expenses an insurer incurred in acquiring a policy.Automatic –A type of reinsurance in which a reinsurer agrees to assume a certain level of risk on allpolicies of a certain type from a ceding company.Cedent –A cedent contractually cedes a portion of their risk to a reinsurer. A cedent may be aprofessional reinsurer ceding to a retrocessionaire or may be the reinsurance department of adirect company ceding to a professional reinsurer.Coinsurance –A type of proportional reinsurance plan in which a ceding company and an assuming companyshare both the risk and the responsibility for establishing the reserves.Direct Writer –An insurance company that writes policies directly for customers.Facultative –A type of reinsurance in which a ceding company chooses which insurance risk it wants to cedeto a particular reinsurer and an assuming company decides whether or not to accept the risk.Facultative-Obligatory –A reinsurance agreement in which a ceding company may choose to submit cases to areinsurer, and the reinsurer must accept the cases up to the amount of the reinsurer‟s retentionlimit.Guaranteed Issue –© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 50ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

Insurance products designed so that each applicant who meets certain conditions establishedby the insurer is automatically issued a policy.Joint First To Die Policy –A life insurance policy that is written on more than one life. The policy proceeds are payable onthe first death.Joint Last to Die Policy –A life insurance policy that is written on more than one life. The policy proceeds are payable onthe last death.Net Amount of Risk (NAR) –For reinsurance purposes, a policy‟s face value, also known as the death benefit, minus thepolicy‟s cash value or reserve.Preferred –A risk class generally used to designate proposed insureds whose anticipated mortality issignificantly lower than average and who represent the least degree of risk.Reinsurance –Insurance that transfers risk from one insurer to another.Reinsurance Treaty –A written statement that specifies the terms and conditions for risks to be submitted forreinsurance.Reinsurer –A reinsurer contractually accepts a portion of the cedent‟s risk. A professional reinsurer whoseprincipal business is reinsurance, as opposed to the reinsurance department of a directcompany.Retention –The dollar amount or % of each loss retained by the cedent under a reinsurance agreement.Retrocessionaire –A reinsurer that contractually accepts from another reinsurer a portion of the underlyingreinsurance risk. The transfer is known as a retrocession.Rider –a supplementary coverage added to an insurance policy that expands the insurance protectionprovided by the policy. Riders provide additional policy benefits without the expense of rewritingthe insurance contract.Standard –An insured who represents an average likelihood of loss within the context of an insurer‟sunderwriting practices.Substandard –An insured who represents a significantly greater-than-average- likelihood of loss within thecontext of an insurer‟s underwriting practices.*Treaty –© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 51ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010

A reinsurance agreement covering a block of business accepted by a reinsurer. A treatycontains common contract terms with a specific risk definition, data on limits and retention andprovisions for premiums and duration.Underwriting Class –a group of insureds who represent a similar level of risk to an insurance company.Uninsurable –A class of proposed insureds whose impairments and anticipated extra mortality are so greatthat the underwriter cannot justify issuing coverage for them.Waiver on Disability -In a life insurance policy, a rider which provides that, in the event an insured is totally disabledas defined in the rider, the insurance company will waive the payment of all premiums thatbecome due during the period of disability.7 REVISION HISTORY/CHANGE SUMMARY7.1 Release 1 – August 23, 2007 - changed the description as indicated by italics in the following paragraph:“Amount of coverage -- the face amount of the base rider/benefit, without options.This may or may not be the same as the initial coverage face amount (for example, if the faceamount increases changes over time).”7.2 Release 2 – January, 2010Changed required minimum ACORD LAH Standard to 2.18.01Significant additions to Section 3 (Message Principles and Assumptions), & re-wrote section 3.2.1Added new version of diagram in section 3 of entity relationshipsChanged to be “Required”Added documentation and updates to support Transaction Message (55101 & 55102) – see MessageCatalog,Replaced ApplicationInfo/ApplicationType & ApplicationInfo/ReplacementInd withPolicy/ReplacementType (which is now required), ApplicationInfo is no longer required.Added sections 5.2.1 & 5.2.2 for guidance on how to read the Detailed Element DefinitionsFormatting changes to Detailed Element Definitions table for readability,Numerous clarifications and adjustments to documentation.© 2001-2010 ACORD CORPORATION – ALL RIGHTS RESERVED. 52ACORD LIFE REINSURANCE INFORCE IMPLEMENTATION GUIDE – V2.0, 01-JAN-2010