ACORD LIFE & ANNUITY STANDARDS LIFE REPLACEMENT IMPLEMENTATION GUIDE V 3.1 JANUARY 2009

ACORD LIFE & ANNUITY STANDARDS LIFE REPLACEMENT IMPLEMENTATION GUIDE V 3.1 JANUARY 2009 References: ACORD Life Specification, Version 2.12 IMPORTANT NOTE: This document contains or relates to ACORD Standards Life & Annuity. You are not authorized to use the ACORD Standard contained in this document unless you have accepted the terms and conditions of the Standards License accessible at http://legal.acord.org/standards_license.htm. To gain such authorization, please go to that site and, if you agree with the terms and conditions of the Standards License, enter whatever information is called for, if any, and click on "Accept". New York Two Blue Hill Plaza 3 rd Floor PO Box 1529 Pearl River, NY 10965-8529 U.S.A. London London Underwriting Centre Suite 1 / 3 3 Minster Court Mincing Lane London EC3R 7DD United Kingdom

Table of Contents 1 BACKGROUND... 1 1.1 INTENDED AUDIENCE... 1 1.2 THE REPLACEMENTS IMPLEMENTATION GUIDE... 1 2 OBJECTIVES... 2 2.1 VISION... 2 2.2 INCREMENTAL ADOPTIONS... 2 2.3 BUSINESS CASE/VALUE PROPOSITION... 3 3 GUIDING PRINCIPLES FOR IMPLEMENTATION... 4 4 REPLACEMENT PROCESSING REQUEST/UPDATE HIERARCHY... 5 4.1 CATALOG OF REPLACEMENT MESSAGES... 7 5 REPLACEMENT OBJECT DIAGRAMS... 8 5.1 REPLACEMENT MESSAGES #1 TXLIFE CLASS DIAGRAM... 8 5.2 REPLACEMENT MESSAGES - #2 REPLACEMENT PROCESSING REQUEST: TXLIFE #127... 9 5.3 REPLACEMENT MESSAGES - #3 REPLACEMENT PROCESSING UPDATE, PENDING: TXLIFE #1128... 10 5.4 REPLACEMENT MESSAGES - #4 REPLACEMENT PROCESSING UPDATE, FINAL: TXLIFE #1128... 11 6 DETAILED ELEMENT DESCRIPTION & TYPE CODE DEFINITION... 12 <ADDRESS> OBJECT... 12 <ANNUITY> OBJECT... 12 <ARRANGEMENT> OBJECT... 13 <ARRDESTINATION> OBJECT... 14 <ARRSOURCE> OBJECT... 14 <ATTACHMENT> OBJECT... 14 <BANKING> OBJECT... 17 <CARRIER> OBJECT... 18 <FINANICALACTIVITY> OBJECT... 18 <HOLDING> OBJECT... 19 <LIFE> OBJECT... 20 <LIFEUSA> OBJECT... 20 <ORGANIZATION> OBJECT... 21 <PARTY> OBJECT... 21 <PAYMENT> OBJECT... 22 <PERSON> OBJECT... 22 <PHONE> OBJECT... 23 <POLICY> OBJECT... 23 <RELATION> OBJECT... 23 <REQUIREMENTINFO> OBJECT... 25 <SETTLEMENTDETAILS> OBJECT... 26 <SETTLEMENTINFO> OBJECT... 26 <SIGNATUREINFO> OBJECT... 27 6 SENDING A REPLACEMENT... 28 6.1 TRANSMITTAL METHOD... 28 6.2 REQUEST / RESPONSE METHOD... 29 6.3 ACORD TXLIFE TRANSACTIONS... 29 6.4 TRANSPORT AND SECURITY... 29 6.5 TXLIFE TRANSACTION ELEMENT AND TYPE CODE DETAILS... 30 6.6 TXLIFE EXAMPLES... 31 7 STANDARD USAGES... 33 7.1 REPLACEMENT PROCESSING REQUEST FOR SURRENDER... 34 7.2 REPLACEMENT PROCESSING UPDATE/POLICY SURRENDERED... 35 8 REVISION HISTORY/CHANGE SUMMARY... 38

1 BACKGROUND 1.1 Intended Audience This Implementation Guide is intended for use by Business and Technology areas to include marketers, developers, business analysts and all other interested parties. This document will explain why a replacement business message/transaction was developed, when it should be used, and how to implement it. The earlier sections are intended to describe the business case whereas the later sections focus more on the technical implementation. 1.2 The Replacements Implementation Guide This Replacements Implementation Guide is intended to define and provide examples of Model replacement business messages, which can facilitate the Replacement Notification and Replacement Processing Requests of Life Insurance business (including traditional Life and Annuities). The first phase of implementation will exclude replacements/exchanges that invoke New York State regulations and will allow for the exclusion of transactions that involve other jurisdictions that raise objections to the use of this electronic process. ACORD Standards It is important to understand that this guide is based on the ACORD Standards - XMLife and TXLife to be specific. The official ACORD Life Standard is the current version of the published XML Schema, Life Data Model and associated supporting technical specifications. Any inconsistencies or discrepancies between this guide and these core standards specification documents must be resolved using the core standards. Every effort will be made to keep this guide current and compliant with the core/base standard. 1

2 OBJECTIVES In the Industry today the process for replacements is a very manual and time-consuming effort due to the lack of automation and non-standard processes for replacements. The creation of the Replacement Processing Request the Replacement Processing Update messaging allows the Industry a standard method for the electronic sending and receiving (notification) of a well formed XML replacement message which will enhance the good order processing of replacement business, and facilitate carrier compliance with regulatory requirements. 2.1 Vision The vision of the Replacement Working Group, who developed these messages and Guide, is to create a fully electronic replacement notification and exchange process between carriers using a series of specially formatted text messages in the XMLife format. The messages allow for the exchange of information necessary to facilitate the exchange of money between carriers. Forms necessary to comply with state regulatory requirements will be sent as Attachments within the TXLife Request. Future phases will attempt to eliminate all forms. Intent of new process and disclaimers The new process is designed to provide a more expedient exchange of information between carriers participating in a replacement or exchange transaction. The intent is not to dictate or in any way require modification of a carrier s internal processes, but to provide an option to the current manual, paper replacement/exchange process that will solicit the voluntary adoption of and adaptation to the electronic process. The participation of insurance carriers in the new process is strictly voluntary, and at no time will carriers that do not participate be restricted or in any way be hindered from communicating with carriers that do participate in this digitized process. For this reason, it will be necessary for participating carriers to maintain a process to handle the receipt of paper copies of the replacement notifications and exchange/transfer requests until such time as all carriers have adopted the electronic replacement notification and exchange process. 2.2 Incremental adoptions Due to disparities in replacement/exchange requirements between the 50 states, territories and the District of Columbia, and the wide range of technical issues involved with implementation, the piloting and implementation of the new process is designed to be both incremental and flexible. Adoption of this policy allows us to move forward with implementation while we continue to develop technical solutions and gain state-by-state approval for the use of this process. The first phase of implementation will exclude replacements/exchanges that invoke New York State regulations and will allow for the exclusion of transactions that involve other jurisdictions that raise objections to the use of this electronic process. 2

Also, during this initial phase, electronic attachments will be used in conjunction with the standard text messages, where necessary, so that images of documents with wet signatures, required comparative information, and carrier specific sales materials lists can be included in the transmission. At such time as methods are developed to standardize and electronically enable these attachments or the text contained in these attachments, the required elements will be added to the standard messages, eventually eliminating the need for the attachments. Because of the incremental nature of this project, please verify that you are in possession of the most current version of this implementation guide (www.acord.org) before any effort is expended on the design and adoption of this process. 2.3 Business Case/Value Proposition Prior to the development of these messages there were no electronic replacement business messages or transactions that carriers share point to point. That is to say carriers communicate with each other by telephone or mail. The Replacement Transaction(s) is/are the first messages to be created with the intent to communicate directly or indirectly with one another based upon the final solution. We intend to communicate with each other through the use of standardized messaging Replacement Processing Request (TXLife #127) and Replacement Processing Update (TXLife #1128) through an XML interface. XML is the leading edge in IT development and most electronic communication is based on some form of XML hence the ACORD standard. The Replacement processes as noted above are very manual, labor intensive and under increasing scrutiny and audit to ensure compliance with the State Regulators. To ensure consistency in messaging between carriers, the Replacement Transactions were created to streamline the process with a straightforward and relatively easy implementation benefiting the Business and Operations. The costs associated with handling the paper replacements would be offset by the implementation of an electronic solution. Using industry standards in the replacement process would reduce if not eliminate errors in procedures that have a negative impact operationally and cause downstream costs in phone calls, emails, mail and delays. Given that State requirements are very time sensitive for notifying the existing carrier of a replacement, the electronic solution would facilitate timely, more consistent and less costly communication between carriers. The end customer or Producer would benefit as well due to the more accurate and timely exchange of information between carriers. Many times, replacements become an impediment to doing business with a certain carrier due to the lack of a standard format of communication that eventually leads to frustration by the Producer. Overall, the high level Value Proposition is intended to: This new process will allow us to better service our customers. Reduce cost. Current method of communication is mail and it s costly. Electronic communication would reduce mail handling and postage; reduce labor costs for scanning/indexing. Increase consistency of data. Allow for individual company conservation efforts. Gain efficiencies in meeting regulatory guidelines. Eliminate re-routing of paperwork within companies due to incorrect address(es) for Replacement Processing. Provide immediate electronic confirmation of delivery of replacement information. Support automating the exchange of funds, including tax qualified and non-qualified monies. 3

3 GUIDING PRINCIPLES FOR IMPLEMENTATION The following section is intended to provide some general guidelines in implementing the model replacement messages. The list is not meant to be exhaustive. On the contrary, it is expected that the list will grow as the standard gets implemented between trading patterns over time. Suggestions and questions for this guide should be sent to the life@acord.org. 1. Keep these replacement transactions as simple as possible. 2. Users should acquaint themselves with the general guidelines and policies of ACORD, and review the current Life Standards Specifications. This Implementation Guide is built upon the ACORD Standards, and presumes a basic understanding of them. 3. This guide makes no assumption as to the messaging method. As such, it is designed to support an on demand dynamic request as well as traditional batch. The first method is called a Request/Response transaction; the second is referred to as a Transmittal transaction. 4. This guide will provide a basic understanding of the standard messages to be passed between carriers to a Life Insurance replacement. 5. This guide does not direct the specific steps to be taken by a party to a replacement, if such actions could be considered unique to the internal workflow, and value proposition provided by the Carrier. This guide does identify the specific steps to be taken, including messages that should be passed, between parties to a replacement. 6. It is intended that the use of this guide will facilitate the flow of information between parties to the extent that the efficiency of service within the Life Insurance industry will be enhanced. 7. The purpose of this guide is to facilitate the development and implementation of the ACORD Standards. 8. To the extent that the ACORD Data Model shall be updated over time, so to will this guide be updated to reflect the most current utilization of the ACORD Standards. 4

4 REPLACEMENT PROCESSING REQUEST/UPDATE HIERARCHY The general structure and hierarchy of the object elements is as follows: <OLifE> <Holding> <Policy> <Life> <LifeUSA> <Annuity> <RequirementInfo> <Attachment> <SignatureInfo> <FinancialActivity> <Payment> <Arrangement> <ArrSource> <ArrDestination> <Banking> <Party> <Person> <Organization> <Address> <Phone> <Carrier> <Relation> <SettlementInfo> <SettlementDetails> 5

The Replacement Process Producer : Producer / Distributor New Buz Sub App + Replacement Form Carrier : New Carrier ACK Carrier : Old (current) Carrier Any Required Form ( 1 or more attach) Replacement Notif (TX 127) Replacement Form (+ 0 or more attach) Request for Status (Inquiry) Status Request can be made at any time in during the process Supply additional Info. One or more required forms. Respond To Status Inquiry Something is not in "good order (TX 1128) The current carrier may question the order of any form or image. Request For More Info. Replacement Request (TX 127) Letter of Authorization Surrender Form Any of the below may be attachments. * Replacement Form * Sales Materials * Illustration * Compliance or Policy Summary * Surrender Form * Exchange Agreement * Assignment * Letter of Authorization (annuity) * Transfere Form Transfer Form Funds being Transferred (TX 1128) 6

4.1 Catalog of Replacement Messages It is our intent that the recipients/users of this document/stream would program their system(s) to receive the replacement transactions and apply a mapping of the ACORD specification (as summarized in this document) to their own system(s). One of our guiding principles is to keep this transaction simple since it is the first of its kind with carrier-to-carrier communication. This is a listing of the various ACORD Life Standard Business Messages (Transactions) appropriate or applicable to Replacements. This is a general, definitional overview. Specific details are provided for each message in the sections that follow. Replacement Messages New Business Submission (w/replacement) TXLife #103 This is the standard New Business Submission (for Life, Annuity, DI or LTC) but includes Replacement information, including 1035 Exchange information, necessary to initiate the replacement process. Replacement Processing Request TXLife #127 This is the message that the New Carrier (Replacing Carrier) sends to Existing/Old Carrier (Replaced Carrier) notifying them that the insured is purchasing a new policy and intends to cancel/replace their existing coverage. It can trigger the conservation effort (and state mandate waiting periods). Sub Transactions under this message include: 12701 Replacement Notify; this is used during Replacement Processing when the Replacing Carrier is notifying the Delivering Carrier that they have received an application to replace the existing contract. It is not a request for the Delivering Carrier to surrender the existing contract and release the funds. 12702 Replacement Request for Surrender; this is used during Replacement Processing when the Replacing Carrier is requesting the Delivering Carrier to surrender the existing contract and release the funds. 12703 Replacement Cancellation; The Receiving Carrier is notifying the Delivering Carrier to cancel the replacement for which a TX#127 was previously sent. 12704 Supplemental Information to Prior Request for Surrender; This TransSubType is used to send subsequent messages from the Receiving Carrier to the Delivering Carrier to provide any outstanding information. Replacement Processing Update TXLife #1128 This is the message that the Existing/Old Carrier (Replaced Carrier) sends to the New Carrier (Replacing Carrier) anytime the status of a processing request changes or to communicate missing requirements. For example, if additional Replacement Forms are required, the Delivering Carrier would create a new RequirementInfo Object with a Status of Outstanding. If the delivering carrier has surrendered the replaced contract, this message would be used to notify the Receiving Carrier and SettlementInfo may be provided if funds are being provided via a clearinghouse. Actors/ Parties Producer -> Carrier Distributor -> Carrier Carrier -> Carrier Carrier -> Carrier 7

5 REPLACEMENT OBJECT DIAGRAMS 5.1 Replacement Messages #1 TXLife Class Diagram Address 0..* 0..1 0..1 Phone 0..* 0..* Party -PartyTypeCode : Integer -FullName : String -GovtID : String -GovtIDTC : Integer 1 0..1 0..* OLifE Relation -OriginatingObjectType : Integer -RelatedObjectType : String -RelationRoleCode : Integer 1 0..* Banking -BankAcctType : Integer -AccountNumber : String -AcctHolderName : String -RoutingNumber : String 0..1 Holding -HoldingTypeCode : Integer -HoldingStatus : Integer -AssetValue : Decimal -LiabilityValue : Decimal 0..1 0..1 1 1 0..1 0..1 0..1 Person -FirstName : String -MiddleName : String -LastName : String 0..1 Carrier -CarrierCode : String Organization -DTCCMemberCode : String 0..* Attachment -AttachementCategoryTC : Integer -AttachmentBasicType : Integer -AttachmentLocation : Integer -AttachementData : String -MimeTypeTC : Integer -TransferEncodingTypeTC : Integer 0..* SignatureInfo -SignatureRoleCode : Integer -SignatureDate : Date -SignaturePurpose : Integer -SignatureText : String RequirementInfo -ReqCode : Integer -ReqStatus : Integer -RequirementStatusReason : String -ReqSubStatus : Integer -RequirementInfoUniqueID : String FinancialActivity -FinActivityType : Integer -FinActivityNetAmt : Decimal -PreTEFRACostBasis : Decimal -PostTEFRACostBasis : Decimal -FinActivityStatus : Integer -FinActivityDate : Date -FinActivityPct : Double -FinActivityGrossAmt : Decimal -SettlementAmt : Decimal -ReferenceNo : String 0..* Payment -PaymentForm : Integer -@PayeeID : String -@BankHoldingID : String ArrDestination 0..* 0..* 0..* Policy -PolNumber : String -LineOfBusiness : Integer -CarrierCode : String -CusipNum : String 0..1 Annuity -QualPlanType : Integer Life 0..1 -QualPlanType : Integer 0..1 LifeUSA -MECInd : Boolean ArrSource -TransferAmt : Decimal -TransferPct : Double SettlementInfo -RelatedRefID : String -AccountNumberSubmitter : String -ReferenceNo : String 0..* 0..* Arrangement -ArrType : Integer -NumOfModalOccurances : Integer -StartDate : Date -PaymentForm : Integer 0..* 0..* SettlementDetails -SettlementAmt : Decimal -AccountCreditDebitType : Integer -AccountNumberReceiver : String 8

5.2 Replacement Messages - #2 Replacement Processing Request: TXLife #127 This message alerts the Old Carrier that the Owner has indicated Replacement. It contains the detail required by NAIC Model Replacement Regulations to provide notice of replacement. TX127 : OLifE ReplacedPolicy : Holding {HoldingStatus = OLI_HOLDSTAT_ACTIVE, HoldingTypeCode = OLI_HOLDTYPE_POLICY} : Relation {RelationRoleCode = OLI_REL_REPLACED} ProposedPolicy : Holding {HoldingStatus = OLI_HOLDSTAT_PROPOSED, HoldingTypeCode = OLI_HOLDTYPE_POLICY} : Relation {RelationRoleCode = OLI_REL_OWNER} : Relation {RelationRoleCode = OLI_REL_OWNER} : Relation {RelationRoleCode = OLI_REL_ANNUITANT} : Policy {CarrierCode = 12345, LineOfBusiness = OLI_LINEBUS_ANNUITY, PolNumber = 19-123456B} Owner : Party {FullName = Fickle, Benedict A., GovtID = 123456789} : Person {FirstName = Benedict, LastName = Fickle, MiddleName = A.} : Relation {RelationRoleCode = OLI_REL_ANNUITANT} : Arrangement {ArrType = OLI_ARRTYPE_FULLSURR, NumOfModalOccurances = 1, PaymentForm = OLI_PAYFORM_CLEARHSE} DeliveringCarrier : Party {FullName = Sadder But Wiser Life Ins. Co., PartyTypeCode = OLI_PT_ORG} : Organization {DTCCMemberCode = 1234} : Carrier {NAICCode = 12345} : ArrDestination : ArrSource ReceivingCarrier : Party {FullName = Jolly Rodger Mutual, PartyTypeCode = OLI_PT_ORG} : Policy {CarrierCode = 98765, CusipNum = 123456789, LineOfBusiness = OLI_LINEBUS_ANNUITY} : Organization {DTCCMemberCode = 9876} : Phone {AddressTypeCode = OLI_PHONETYPE_AGENTCSA} : Attachment {AttachmentBasicType = OLI_BASICATTMENTTY_IMAGE, AttachmentCategoryTC = OLI_ATTACHCAT_REPFORM (new), AttachmentData = <EncodedBinaryData>, AttachmentLocation = OLI_INLINE, MimeTypeTC = OLI_MIMETYPE_TIFF, TranferEncodingTypeTC = OLI_ENCODE_BASE64} : Carrier {NAICCode = 98765} : RequirementInfo {ReqCode = OLI_REQCODE_REPLFULL (new), ReqStatus = OLI_REQSTAT_OUTSTANDING, RequirementInfoUniqueID = JRL-021761-A20F} : Annuity {QualPlanType = OLI_QUALPLAN_NONQUAL} : SignatureInfo {SignatureDate = 2004-10-01, SignaturePurpose = OLI_SIGTYPE_LOSTPOLDEC, SignatureRoleCode = OLI_PARTICROLE_OWNER, SignatureText = Benadict A. Fickle} 9

5.3 Replacement Messages - #3 Replacement Processing Update, Pending: TXLife #1128 TX1128 : OLifE ReplacedPolicy : Holding {HoldingStatus = OLI_HOLDSTAT_ACTIVE, HoldingTypeCode = OLI_HOLDTYPE_POLICY} : Relation {RelationRoleCode = OLI_REL_REPLACED} ProposedPolicy : Holding {HoldingStatus = OLI_HOLDSTAT_PROPOSED, HoldingTypeCode = OLI_HOLDTYPE_POLICY} : Relation {RelationRoleCode = OLI_REL_OWNER} : Relation {RelationRoleCode = OLI_REL_OWNER} : Relation {RelationRoleCode = OLI_REL_ANNUITANT} Owner : Party {FullName = Fickle, Benedict A., GovtID = 123456789} : Relation {RelationRoleCode = OLI_REL_ANNUITANT} : Policy {CarrierCode = 12345, LineOfBusiness = OLI_LINEBUS_ANNUITY, PolNumber = 19-123456B} DeliveringCarrier : Party {FullName = Sadder But Wiser Life Ins. Co., PartyTypeCode = OLI_PT_ORG} : Organization {DTCCMemberCode = 1234} : Carrier {CarrierCode = 12345} : Person {FirstName = Benedict, LastName = Fickle, MiddleName = A.} : RequirementInfo {ReqCode = OLI_REQCODE_REPLFUNDS (new), ReqStatus = OLI_REQSTAT_ERROR, ReqSubStatus = OLI_REQSUBSTAT_NEEDFORM (new), RequirementInfoUniqueID = JRL-021761-A20F} : RequirementInfo {ReqCode = OLI_REQCODE_REPFORM, ReqStatus = OLI_REQSTAT_OUTSTANDING, RequirementStatusReason = Submit signed ACORD Form #208-FL} : Policy {CarrierCode = 98765, CusipNum = 123456789, LineOfBusiness = OLI_LINEBUS_ANNUITY} ReceivingCarrier : Party {FullName = Jolly Rodger Mutual, PartyTypeCode = OLI_PT_ORG} : Organization {DTCCMemberCode = 9876} : Carrier {CarrierCode = 98765} : Address {AddressType = OLI_ADTYPE_CLIENTCSA} 10

5.4 Replacement Messages - #4 Replacement Processing Update, Final: TXLife #1128 TX1128 : OLifE : SettlementInfo ReplacedPolicy : Holding {AssetValue = 58025.19, HoldingStatus = OLI_HOLDSTAT_INACTIVE, HoldingTypeCode = OLI_HOLDTYPE_POLICY, LiabilityValue = 38706.05} : SettlementDetails {SettlementAmount = 19319.14} : Relation {RelationRoleCode = OLI_REL_REPLACED} ProposedPolicy : Holding {HoldingStatus = OLI_HOLDSTAT_PROPOSED, HoldingTypeCode = OLI_HOLDTYPE_POLICY} : Relation {RelationRoleCode = OLI_REL_OWNER} : Relation {RelationRoleCode = OLI_REL_OWNER} : Policy {CarrierCode = 12345, LineOfBusiness = OLI_LINEBUS_ANNUITY, PolNumber = 19-123456B, PolicyStatus = OLI_POLSTAT_SURR} DeliveringCarrier : Party {FullName = Sadder But Wiser Life Ins. Co., PartyTypeCode = OLI_PT_ORG} : Organization {DTCCMemberCode = 1234} : Carrier {CarrierCode = 12345} Owner : Party {FullName = Fickle, Benedict A., GovtID = 123456789} : Person {FirstName = Benedict, LastName = Fickle, MiddleName = A.} : FinancialActivity {FinActivityDate = 2004-10-08, FinActivityGrossAmt = 19319.14, FinActivityNetAmt = 19319.14, FinActivityStatus = OLI_FINACT_COMPLETED, FinActivityType = OLI_FINACT_FULLSURR, PostTEFRACostBasis = 40499.19, PreTEFRACostBasis = 0, ReferenceNo = 04223992867NC, SettlementAmt = 19319.14} : RequirementInfo {ReqCode = OLI_REQCODE_REPLFUNDS (new), ReqStatus = OLI_REQSTAT_COMPLETED} : RequirementInfo {ReqCode = OLI_REQCODE_REPFORM, ReqStatus = OLI_REQSTAT_COMPLETED} : Policy {CarrierCode = 98765, CusipNum = 123456798, LineOfBusiness = OLI_LINEBUS_ANNUITY} ReceivingCarrier : Party {FullName = Jolly Rodger Mutual, PartyTypeCode = OLI_PT_ORG} : Organization {DTCCMemberCode = 9876} Payee : Carrier {CarrierCode = 98765} : Payment {PaymentForm = OLI_PAYFORM_CLEARHSE} 11

6 DETAILED ELEMENT DESCRIPTION & TYPE CODE DEFINITION XML Element Name Type Description <Address> Object TXLife/TXLifeRequest/OlifE/Party/Address An address pertaining to a Party or Group. In the case of a Replacement Processing Request TXLife #127, the address would indicate where a physical check should be mailed. For a Replacement Processing Update TXLife #1128, the address would be used to communicate where outstanding requirements are expected to be sent through the mail (e.g. wet signature on a required form) Every object within the ACORD model, which can have more than one occurrence, has a unique id attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the data file <Address id> <AddressTypeCode> LookUp Table String Address Type ID or stream. Type of address 17 = Mailing spec. Please see current spec. for additional codes. <AttentionLine> Used to contain an attention of additional address line. String Specific person or department to provide additional detail <Line1> String First line of the address <Line2> String Second line of the address <Line3> String Third line of the address <City> String City of the address <AddressState> String State of the address. <AddressStateTC> 2 letter State code in US, etc <Zip> String Zip code, postal code, etc. (country dependent) <AddressCountry> String Country of the address <AddressCountryTC> Use nation for valid Address Country type codes XML Element Name Type Description <Annuity> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/Annuity If either the policy being replaced or the proposed policy is an annuity, this aggregate is passed under the appropriate Holding to indicate the Tax Qualification Type. <QualPlanType> LookUp Table String Qualified Plan Type Tax Status of the policy or plan. 1 = Non-Qualified 2 = 401k 3 = 403b 12

4 = 457 Deferred Compensation 5 = IRA 6 = Roth IRA 7 = Educational IRA 8 = SEP/IRA 13 = HR10/Keogh 33 = IRA Spousal 34 = Cash Balance Plan-Defined Contribution 35 = Cash Balance Plan-Defined Benefit 36 = Target Benefit Plan 37 = Foreign National 38 = Deferred Profit Sharing Plan 40 = 408k (SARSEP) 41 = Texas ORP 42 = 403a (Qualified Employee Annuity Plan) spec. Please see current spec. for additional codes. XML Element Name Type Description <Arrangement> Object TXLife/TXLifeRequest/OlifE/Holding/Arrangement On a TransSubType 12702 Replacement Request for Surrender, this aggregate is passed by the Receiving Carrier to indicate whether the request is for a partial or full surrender, or where a surrender on a specific date is being requested, or where specific payment instructions are being replaced. <ArrType> LookUp Table String = Arrangement Type Type of Arrangement 7 = Specified Amount Withdrawal (net) 14 = Percent of value withdrawal 31 = Full Surrender spec. Please see current spec. for additional codes. <StartDate> Date Used if a specific date (in the future) for the surrender is being requested. If this property is not passed, the requested process date should be interpreted to be ASAP. <NumOfModalOccurences> Integer TXLife Specification Guide lists this field as required! I don t remember why.discuss with Rob Marone to see if he remembers. <PaymentForm> LookUp Table String = Payment Form Physical Form of Payment 7 = EFT 13

10 = Corporate Check 11 = Clearinghouse 12 = Wire spec. Please see current spec. for additional codes. XML Element Name Type Description <ArrDestination> Object TXLife/TXLifeRequest/OlifE/Holding/Arrangement/ArrDestination Used to refer to the Receiving Carrier as the Payee on the Surrender <PaymentPartyID> IDREF Refers to the Party to be paid (Receiving Carrier) <BankingInfoID> IDREF Refers to the Banking Information when the requested PaymentForm is Wire or EFT XML Element Name Type Description <ArrSource> Object TXLife/TXLifeRequest/OlifE/Holding/Arrangement/ArrSource Used for a partial surrender to indicate amount or percent requested <TransferAmt> Currency Amount to be surrendered in the case of a partial surrender <TransferPct> Percent Percent to be surrendered in the case of a partial surrender XML Element Name Type Description <Attachment> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/RequirementInfo/Attachment Can by used on TXLife 127 - Replacement Processing Request to pass images of Replacement Forms being transmitted with the message. On a TXLife 1128 Replacement Processing Update, images of Forms needed to satisfy outstanding requirements may be sent. <Attachement id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique id attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the data file or stream. <AttachmentBasicType> LookUp Table String = Attachment Basic Type This describes the basic type of attachment. If it is other than text, you must look at AttachmentType and MimeType to correctly use the data. 2 = Image 14

XML Element Name Type Description spec. Please see current spec. for additional codes. <AttachmentData> LookUpTable String = Variant Types Attachment Data As a child of Attachment, the value of AttachmentData depends upon the value of AttachmentLocation. If AttachmentLocation is 1 (Inline), then AttachmentData will be a binary representation of the data. If AttachmentLocation is 2 (URL Reference), then AttachmentData will be the string that equates to a valid URL Reference to the file. And finally, if AttachmentLocation is 3 (Multi-part Mime) then we assume that the entire message was sent as part of a multi-part mime message and AttachmentData will be set to a reference of the Mime segment that contains the attached file??? <AttachmentType> LookUp Table String = Attachment Type <MimeTypeTC> LookUp Table String = Mime Type <TransferEncodingTypeTC> LookUp Table String = EncodeType Type of Attachment 13 = Wet signature image 65 = ACORD 759 - Important Notice Regarding Replacement Form 73 = ACORD 951-1035 Exchange / Rollover / Transfer Form spec. Please see current spec. for additional codes Describes the format of the Imaged file despite the contents (forms, letters, notes, etc.) 3 = Image jpeg 4 = Image gif 11 = Image tiff spec. Please see current spec. for additional codes Transfer Encoding Type: 6 = Binary 15

XML Element Name Type Description spec. Please see current spec. for additional codes <AttachmentLocation> LookUp Table String = Attachement Location <AttachmentCategoryTypeCode> LookUp Table String = Attachment Category Type Indicates if the attachment is stored as inline or as a URL reference. 1 = Inline 2 = URL Reference 3 = Mulitpart Mime Form Instance Category 28 = Replacement Form spec. Please see current spec. for additional codes 16

XML Element Name Type Description <Banking> Object TXLife/TXLifeRequest/OlifE/Holding/Banking On TXLife 127 Replacement Processing Request this object is required when specific payment instructions are sent to the Delivering Carrier, and the requested PaymentForm is EFT or Wire. On TXLife 1128 Replacement Processing Update this object is required after the Replacement has been processed, but only when the payment ot the Receiving Carrier was made via EFT or Wire. <Banking id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the data file or stream. <BankAccountType> LookUp Table String= 'Bank Account Type' In the case that the PaymentMethod is 'electronic funds transfer,' this is the type of account associated with the bank account. 2 = Checking spec. Please see current spec. for additional codes. <AccountNumber> String The account number for the bank account. <RoutingNum> String The routing number for the bank account, in the case of PaymentMethod = 'Electronic Funds Transfer'. UML says RoutingNum <BankName> String Name of the Bank in which the funds are to be or have been depositied. 17

XML Element Name Type Description <Carrier> Object TXLife/TXLifeRequest/OlifE/Party/Carrier Information pertaining to both the Receiving and Delivering Carrier is passed for both the TXLife 127 Replacment Processing Request and the TXLife 1128 Replacement Processing Update <Carrier id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the data file or stream. <CarrierCode> String This code uniquely represents the Insurance Carrier <NAICCode> String NAIC Code XML Element Name Type Description <FinanicalActivity> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/FinancialActivity Passed on TXLife 1128 Replacment Processing Update when surrender occurs. <FinancialActivity id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <FinActivityType> LookUp Table String= 'Financial Activity Type' The type of financial activity. 10 = Full Surrender 11= Partial Surrender spec. Please see current spec. for additional codes. <FinActivityGrossAmt> Currency The gross amount for this financial activity. 18

XML Element Name Type Description <FinActivityNetAmt> Currency The net amount for this financial activity. Gross Amount minus retained/netted commission. <FinActivityDate> Date Date financial activity was conducted <ReferenceNo> String Used as a tracking number when PaymentForm is Clearinghouse, EFT or Wire. <PreTefraCostBasis> Currency Premiums paid into an annuity contract prior to August 14, 1982. These premiums may be withdrawn under the FIFO order of withdrawal. <PostTefraCostBasis> Currency Premiums paid into an annuity contract on or after August 14, 1982 XML Element Name Type Description <Holding> Object TXLife/TXLifeRequest/OlifE/Holding A minimum of 2 Holding will be passed one for the active contract and another for the contract being proposed. If Banking information is passed an additional Holding will be passed. <Holding id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <HoldingTypeCode> LookUp String = Holding Type <HoldingStatus> LookUp String = Holding Status Type code Type of Holding 2 = Policy 7 = Banking spec. Please see current spec. for additional codes. Status of the Holding 1 = Active 3 = Proposed-pending <AssetValue> Currency Passed on a Replacement Processing Update when Holding has been surrendered. This indicates the surrender value of the contract on the date the surrender occurred. <LiabilityValue> Currency Passed on a Replacement Processing Update when Holding has been surrendered. This indicates the total outstanding loan on the contract on the date the surrender occurred. 19

XML Element Name Type Description <Life> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/Life If either the policy being replaced or the proposed policy is a life insurance contract, this aggregate is passed under the appropriate Holding to indicate the Tax Qualification Type. <QualPlanType> LookUp Table String Qualified Plan Type Tax Status of the policy or plan. 1 = Non-Qualified 2 = 401k 3 = 403b 4 = 457 Deferred Compensation 5 = IRA 6 = Roth IRA 7 = Educational IRA 8 = SEP/IRA 13 = HR10/Keogh 33 = IRA Spousal 34 = Cash Balance Plan-Defined Contribution 35 = Cash Balance Plan-Defined Benefit 36 = Target Benefit Plan 37 = Foreign National 38 = Deferred Profit Sharing Plan 40 = 408k (SARSEP) 41 = Texas ORP 42 = 403a (Qualified Employee Annuity Plan) spec. Please see current spec. for additional codes. XML Element Name Type Description <LifeUSA> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/Life/LifeUSA If either the policy being replaced or the proposed policy is a life insurance contract, this aggregate is passed under the appropriate Holding to designate if the contract qualifies as a Modified Endowment Contract MEC. <MECInd> Booleen Indicates whether a Life Contract is a MEC at the time of the Replacement. 0 = False 1 = True 20

XML Element Name Type Description <Organization> Object TXLife/TXLifeRequest/OlifE/Party/Organization This is aggregate is required if Party Type is Organization <DTCCMemberCode> String DTCC Participant Code of the Carrier. Implementation specific. This property will only be used if messages transmitted via the DTCC. XML Element Name Type Description <Party> Object TXLife/TXLifeRequest/OlifE/Party A minimum of 3 Parties must be sent; Receiving Carrier, Delivering Carrier, Owner/Annuitant/Insured. IF the owner and annuitant/insured are different parties, then a minimum of 4 parties must be sent. Additional optional Parties may be sent to correspond with the optional Relations sent. <Party id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <PartyTypeCode> LookUp Table String = PartyType Type of Party 1 = Person 2 =Organization <FullName> String Full Legal Name of the Party. <GovtID> Integer 9-digit Federal Tax ID of the Party. <GovtIDTC> LookUp Table String = Government ID Type code describing the contents of GovtID. 1 = Social Security Number 2 = Taxpayer Identification Number spec. Please see current spec. for additional codes. 21

XML Element Name Type Description <Payment> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/FinancialActivity/Payment Used to communicate how funds are being delivered to the Receiving Carrier on TXLife 1128 Replacement Processing Update <Payment id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <BankingInfoID> IDREF Refers to Banking Aggregate. Passed when PaymentForm is EFT or Wire. <PaymentForm> LookUp Table String = Payment Form Physical Form of Payment 7 = EFT 10 = Corporate Check 11 = Clearinghouse 12 = Wire spec. Please see current spec. for additional codes. XML Element Name Type Description <Person> Object TXLife/TXLifeRequest/OlifE/Party/Person The Person object is required whenever PartyType is equal to Person. Used to identify the contract Owner and the Insured/Annuitant <Person id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <FirstName> String First name of the person <MiddleName> String Middle name of the person <LastName> String Last name of the person Gender of the person <Gender> LookUp Table String = Gender Type 1 = Male 2 = Female <BirthDate> Date Date of birth for the person 22

XML Element Name Type Description <Phone> Object TXLife/TXLifeRequest/OlifE/Party/Phone On TXLife #127 Replacement Processing Request the Phone Number for the Receiving Carrier Party is passed to provide the phone number of the service center to which follow-up questions can be directed. <Phone id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <PhoneTypeCode> LookUp String = Phone Type Type of phone 2 = Business <AreaCode> String Area code <DialNumber> String Phone number Does not include country code or area code <Ext> String Extension of the phone number (if any) XML Element Name Type Description <Policy> Object TXLife/TXLifeRequest/OlifE/Holding/Policy The Policy object contains all the policy properties that are generic across insurance policy types. <PolNumber> String Policy number: Assigned by the Carrier <LineOfBusiness> LookUp String = Line of Business Line of business of the insurance. 1 = Life 2 = Annuity <CarrierCode> String Issuing carrier code. XML Element Name Type Description <Relation> Object TXLife/TXLifeRequest/OlifE/Relation The Relation object is a powerful, flexible mechanism for relating various objects in the ACORD model. This object is only obtained through a call to OLIRequestRelation() off the top-level object which you want to obtain a relationship for. Party, Activity, Group and Holding objects can be related to one another. 23

XML Element Name Type Description Once the requested relation object is returned the object operates like a top- level object and utilizes the same methods. A minimum of 6 Relations must be sent: Owner relationship to Active Holding Owner relationship to Proposed Holding Insured or Annuitant relationship to Active Holding Insured or Annuitant relationship to Proposed Holding Surrendering Carrier to Active Holding Carrier to Proposed Holding <Relation id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <OriginatingObjectid> IDREF Unique identifier of originating top-level object. <RelatedObjectid> IDREF Unique identifier of related top-level object <OriginatingObjectType> LookUp String = Object Type Type of top-level object, within the ACORD model, of originator. 6 = Party spec. Please see current spec. for additional codes <RelatedObjectType> LookUp String = Object Type <RelationRoleCode> LookUp String = Relation Role Code Type of top-level object, within the ACORD model, of originator. 4 = Holding spec. Please see current spec. for additional codes Type of relationship between Originating and Related objects 8 = Owner 32 = Insured 35 = Annuitant 87 = Carrier 187 = Surrendering Carrier spec. Please see current spec. for additional codes 24

XML Element Name Type Description <RequirementInfo> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/RequirementInfo Provides requested, outstanding and completed requirements associated with the Replacement of a Policy. TXLife 127 Replacement Processing Request will send a minumum of 1 RequirementInfo; a child of the proposed policy with a requirement for the receipt of the replaced policy funds. TXLife 1128 Replacement Processing Request will use RequirementInfo if replacement processing is suspended due to missing information, forms or other NIGO problems. In that case, use one or more RequirementInfo aggregates to indicate the missing requirements and their status. <RequirementInfo id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream. <RequirementInfoUniqueID> String Used as a tracking number for the requirement <ReqCode> LookUp String = Requirement Code Specifies the Requirement 124 = Original Policy 127 = Replacement Form 134 = 1035 Exchange Form 156 = Absolute Assignment of Policy Ownership 165 = Signed Application 655 = Replaced Policy Funds <OriginatingObjectType> LookUp String = Object Type <ReqStatus> LookUp String = Requirement Status spec. Please see current spec. for additional codes Type of top-level object, within the ACORD model, of originator. 6 = Party spec. Please see current spec. for additional codes The status of the Requirement 6 = Declined 11 = Completed 4 = Outstanding spec. Please see current spec. for additional codes 25

XML Element Name Type Description <RequirementStatusReasoon> LookUp String = Requirement Status <ReqSubStatus> LookUp String = Requirement Sub Status String Used to provide additional information regarding why the Requirement is in a specific status or could pass specific forms for missing requirements Provides a secondary level of detail on the Requirement Status giving the user the reason for the current primary status. 8 = Cancelled by Carrier 9 = Cancelled by Applicant 30 = Conservation Effort in Progress 31 = Missing Forms 33 = No Cash Value 37 = Contract not eligible for surrender 32 = Forms not in Good Order 36 = No Active Policy on Record spec. Please see current spec. for additional codes XML Element Name Type Description <SettlementDetails> Object TXLife/TXLifeRequest/OlifE/SettlementInfo/SettlementDetails Used on TXLifeRequest 1128 for Settlement of Replaced Policy Funds <SettlementAmt> Integer The dollar amount being settled <AccountCreditDebitType> LookUp String = Accounting Credit Debit Type Indicates whether the Settlement is a debit or a credit. 1 = Credit 2 = Debit <AccountNumberReceiver> String The account number of the Receiving Carrier XML Element Name Type Description <SettlementInfo> Object TXLife/TXLifeRequest/OlifE/SettlementInfo Used on TXLifeRequest 1128 for Settlement of Replaced Policy Funds <RelatedRefID> String Points to????? AccountNumberSubmitter String Settling/Bank Account Number of Delivering Carrier 26

XML Element Name Type Description <ReferenceNo> String Tracking Id XML Element Name Type Description <SignatureInfo> Object TXLife/TXLifeRequest/OlifE/Holding/Policy/RequirementInfo/Attachment/SignatureInfo Used to describe the parties (and their roles) who signed the form whose image is contained in this attachment Role code describing the signors relationship to the form <SignatureRoleCode> LookUp String = Participant Role 18 = Owner <SignatureDate> Date Date of the Signature spec. Please see current spec. for additional codes <SignaturePurpose> LookUp String = Signature Type Reason for Signature 1 = Lost Policy Declaration spec. Please see current spec. for additional codes <SignatureText> String Signature Text Value 27

6 SENDING A REPLACEMENT The ACORD XML for Life (XMLife) model provides two basic techniques for sending information between trading partners. The first technique is a Request/Response method whereby a requester sends a request transaction to a provider who receives, process and replies back with a response transaction typically containing the requested data or a result if an action was requested. The second is a Transmittal method, which is more typical of a batch send. The sender simply blasts the information to the receiving system, or perhaps creates a file for a recipient and places it in a common location (mailbox, file store, etc.). This is a simpler and more traditional method, so we ll describe it first. 6.1 Transmittal Method A Transmittal contains two basic parts: a content section and an envelope section. The content is what has been discussed thus far, all the details beginning at the <OLifE> level object element on down, including <ProductProfile>, <Party>, and so forth. First focus on the content, the details of your profile. Once you have that down, simply wrap those details with the information that follows. The basic construct of a full TXLife Transmittal is: <TXLife> <UserAuthRequest> <TXLifeRequest> <OLifE> [ all the message details, i.e. the body of your message] </OLifE> </TXLifeRequest> </UserAuthRequest> </TXLife> 28

6.2 Request / Response Method The second method for sending XML for Life transactions is based on the classic Request/Response method. The transaction is typically (though not always) reversed and the system desiring information (Receiving system) initiates the transaction by sending a Request. The sending system then Responds with the appropriate details, as specified in the initial request. The Request: <TXLife> <UserAuthRequest> <TXLifeRequest> <OLifE> [ all the message details, i.e. the body of your message] </OLifE> </TXLifeRequest> </UserAuthRequest> </TXLife> The Response: <TXLife> <UserAuthResponse> <TXLifeResponse> <OLifE> [ all the message details, i.e. the body of your message] </OLifE> </TXLifeResponse> </UserAuthResponse> </TXLife> 6.3 ACORD TXLife Transactions There are many different types of ACORD transactions. Transactions have been defined for New Business Submission, Product Inquiry, Address Change and a whole range of life insurance business process transactions (a.k.a. messages). For more details please refer to the ACORD TXLife Implementation Guide, which outlines all the transaction types available and their basic, minimum required construct. Industry Implementation Guides, like this one, add flesh-to-the-bones to the basic TXLife guide, describing what a more complete trading partner business message should look like in specific business context. 6.4 Transport and Security It is important to note that the ACORD XMLife and TXLife specifications do not define how you will physically transport the message, or issues of security. The ACORD standards are by design meant to be neutral on this point, allowing you to adopt whatever mechanisms are appropriate for your business needs. 29

Typical physical implementation methods have included: FTP Using the Internet File Transport Protocol to place an XMLife file on a FTP Server, allowing a client system to retrieve it (via FTP GET Method) at their leisure. This is generally only appropriate for a Transmittal method, since Request/Response implies a real-time communication between sender and receiver. SMTP Using Internet Mail protocol to send the file. This has been successfully used by trading partners for both Transmittals as well as Request/Response transactions. Messaging Middleware A robust solution, providing security as well as assurance that transactions are received (non-repudiation), error-recover, etc are provided in products like IBM MQSeries or Microsoft Message. Regardless of the physical transport, The ACORD XMLife/TXLife messages are the same. 6.5 TXLife Transaction Element and Details The TXLife wrapper provides information about the sender, the recipient, when the message was created and so forth. It does NOT include details about the product profile- that is in the content section beginning with the <OLifE> object. Following are all the expected fields that you should value and include in a well-formed and valid ACORD TXLife Transmittal. XML Element Name Type Description <UserAuthRequest> Object This object defines the transaction/message information about the user and the system that is sending the message. <UserLoginName> String User Login name into receiving system, if applicable <CryptType> String <Pswd> String User Password, if applicable <CryptPswd> String <UserSessionKey> String <VendorApp> Aggregate <VendorName> String Sender/creator of this file/stream <AppName> String Name of system creating product profile (source system) <AppVer> String Version of system creating product profile <ProxyVendor> String Name of third party, if there is one, sending or transmitting this message. <VendorName String Sender/creator of Product profile name (third party name) <AppName> String Name of system creating product profile (source system) <AppVer> String Version of system creating product profile <TXLifeRequest> Object This object defines the information about this particular message/transaction. <TransRefGUID> String Uniquely identifies this transaction. Use a 32-bit GUID (Globally Unique Identifier). <TransType tc= 1201 > Typecode Transaction type uniquely defines this transaction to the <TransSubType tc= ### Typecode receiving system. 30

XML Element Name Type Description <TransExeDate> Date Date and time when this file or feed was created. <TransExeTime> Time Time when this file or feed was created. <TransMode> TypeCode <NoResponseOk tc= 1 > Boolean Indicates if a response is desired or necessary. <TestIndicator> 1 = Yes Boolean 0 = No 1 = Yes For a transmittal set to 1 for Yes. Indicates whether this is a test or production file/stream. XML Element Name Type Description <UserAuthResponse> Object This object defines the transaction/message information about <UserLoginName> String User Login name into receiving system, if applicable <CryptType> String To be discussed <Pswd> String User Password, if applicable <CryptPswd> String <UserSessionKey> String <VendorApp> Aggregate <VendorName> String Sender/creator <AppName> String Name of system creating product profile (source system) <AppVer> String Version of system creating product profile <ProxyVendor> String Name of third party, if there is one, sending or transmitting this message. <VendorName String Sender/creator of Product profile name (third party name) <AppName> String Name of system creating product profile (source system) <AppVer> String Version of system creating product profile <TXLifeResponse> Object This object defines the information about this particular message/transaction. <TransRefGUID> String Uniquely identifies this transaction. Use a 32-bit GUID (Globally Unique Identifier). <TransType tc= > Typecode Transaction type <TransSubType tc= ### Typecode <TransExeDate> Date Date and time when this file or feed was created. <TransExeTime> Time Time when this file or feed was created. <TransMode> TypeCode To be discussed <NoResponseOk tc= 1 > Boolean Indicates if a response is desired or necessary. <TestIndicator> 1 = Yes Boolean 0 = No 1 = Yes For a transmittal set to 1 for Yes. Indicates whether this is a test or production file/stream. If Test then <TestIndicator>1</TestIndicator>. 6.6 TXLife Examples A basic example of a TXLife Transmittal wrapper would look like: <TXLife> <UserAuthRequest> 31

<UserLoginName/> <Pswd/> <VendorApp> <VendorName VendorCode="##">Lincoln National Life</VendorName> <AppName>Annuity Profile App Generator</AppName> <AppVer>1.24c</AppVer> </VendorApp> </UserAuthRequest> <TXLifeRequest> <TransRefGUID>938749384753ea765c87-876432</TransRefGUID> <TransType tc="1201">product Inquiry Transmittal</TransType> <TransExeDate>2002-05-31T13:47:53-05:00</TransExeDate> <TransExeTime>13:20:10</TransExeTime> <! close tags --> <TransMode> <NoResponseOK tc="1">true</noresponseok> <OLifE> <! BEGIN XMLife DATA --> </OLifE> A basic Request/Response Transactions might look like this: <TXLife> <UserAuthRequest> <UserLoginName/> <Pswd/> <VendorApp> <VendorName VendorCode="##">Lincoln National Life</VendorName> <AppName>Annuity Profile App Generator</AppName> <AppVer>1.24c</AppVer> </VendorApp> </UserAuthRequest> <TXLifeRequest> <TransRefGUID>44wa305sf345-368-93ho643-</TransRefGUID> <TransType tc="120">product Inquiry</TransType> <TransExeDate>2002-05-31T13:47:53-05:00</TransExeDate> <TransExeTime>13:20:10</TransExeTime> <OLifE> <! BEGIN XMLife DATA --> </OLifE> <! close tags --> <TXLife> <TXLifeResponse> <TransRefGUID>44wa305sf345-368-93ho643-</TransRefGUID> Note the return GUID is same as Request <TransType tc="120">product Inquiry</TransType> <TransExeDate>2002-05-31T13:47:53-05:00</TransExeDate> <TransExeTime>13:20:11</TransExeTime> <OLifE> <! BEGIN XMLife DATA --> </OLifE> <! close tags --> 32

7 STANDARD USAGES Basic Scenarios This section provides several basic scenarios of usage of the Replacement. Users are encouraged to enhance this section, by offering examples to this section in efforts to represent best practices from industry participants. 33

7.1 Replacement Processing Request for Surrender <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v2004 rel. 4 U (http://www.xmlspy.com) by Valerie Moeller (Life Investors) --> <TXLife xmlns=http://acord.org/standards/life/2 xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://acord.org/standards/life/2 TXLife2.10.90.xsd"> <UserAuthRequest/> <TXLifeRequest PrimaryObjectID="Holding_1"> <TransRefGUID/> <TransType tc="127">replacement Processing Request</TransType> <TransSubType tc="12702">replacement Request for Surrender</TransSubType> <OLifE> <!--Holding Being "Replaced"--> <Holding id="holding_1"> <HoldingTypeCode tc="2">policy</holdingtypecode> <HoldingStatus tc="1">active</holdingstatus> <Policy> <PolNumber>893ABC</PolNumber> <LineOfBusiness tc="2">annuity</lineofbusiness> <CarrierCode>12388</CarrierCode> <Annuity> <QualPlanType tc="1">non-qualified</qualplantype> </Annuity> </Policy> <Arrangement> <ArrType tc="31">full Surrender</ArrType> <NumOfModalOccurrences>01</NumOfModalOccurrences> <PaymentForm tc="11">clearinghouse</paymentform> <ArrDestination PaymentPartyID="Party_3"/> </Arrangement> </Holding> <!--Holding Being "Proposed"--> <Holding id="holding_2"> <HoldingTypeCode tc="2">policy</holdingtypecode> <HoldingStatus tc="3">proposed</holdingstatus> <Policy> <PolNumber>499CDF</PolNumber> <LineOfBusiness tc="2">annuity</lineofbusiness> <CarrierCode>15987</CarrierCode> <Annuity> <QualPlanType tc="1">non-qualified</qualplantype> </Annuity> <RequirementInfo> <ReqCode tc="655">replaced Policy Funds</ReqCode> <RequirementInfoUniqueID>TrackingReq001</RequirementInfoUniqueID> <ReqStatus tc="4">outstanding</reqstatus> <Attachment> <AttachmentCategoryTC tc="28">replacement Form</AttachmentCategoryTC> </Attachment> </RequirementInfo> </Policy> </Holding> <Party id="party_1"> <PartyTypeCode tc="1">person</partytypecode> <FullName>Roger Rabbit</FullName> <GovtID>1971971977</GovtID> <GovtIDTC tc="1">ssn</govtidtc> <Person> <FirstName>Roger</FirstName> <MiddleName/> <LastName>Rabbit</LastName> </Person> </Party> <Party id="party_2"> <PartyTypeCode tc="2">organization</partytypecode> 34

<FullName>Life Insurance Carrier A</FullName> <Organization> <DTCCMemberCode>4566</DTCCMemberCode> </Organization> <Carrier> <CarrierCode>12388</CarrierCode> </Carrier> </Party> <Party id="party_3"> <PartyTypeCode tc="2">organization</partytypecode> <FullName>Life Insurance Carrier B</FullName> <Organization> <DTCCMemberCode>4561</DTCCMemberCode> </Organization> <Carrier> <CarrierCode>15987</CarrierCode> </Carrier> </Party> <Relation id="relation_1" OriginatingObjectID="Party_1" RelatedObjectID="Holding_2"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="8">owner</relationrolecode> </Relation> <Relation id="relation_2" OriginatingObjectID="Party_1" RelatedObjectID="Holding_1"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="35">annuitant</relationrolecode> </Relation> <Relation id="relation_3" OriginatingObjectID="Party_2" RelatedObjectID="Holding_1"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="187">surrendering Carrier</RelationRoleCode> </Relation> <Relation id="relation_4" OriginatingObjectID="Party_3" RelatedObjectID="Holding_2"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="87">carrier</relationrolecode> </Relation> </OLifE> </TXLifeRequest> </TXLife> 7.2 Replacement Processing Update/Policy Surrendered <?xml version="1.0" encoding="utf-8"?> <!-- edited with XMLSPY v2004 rel. 4 U (http://www.xmlspy.com) by Valerie Moeller (Life Investors) --> <TXLife xmlns="http://acord.org/standards/life/2" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://acord.org/standards/life/2 T:\FMDALL~1\ACORDS~1.90\TXLife2.10.90.xsd"> <UserAuthRequest/> <TXLifeRequest PrimaryObjectID="Holding_1"> <TransRefGUID/> <TransType tc="1128">replacement Processing Update</TransType> <OLifE> <!--Holding Being "Replaced"--> <Holding id="holding_1"> <HoldingTypeCode tc="2">policy</holdingtypecode> <HoldingStatus tc="2">terminated</holdingstatus> <AssetValue>80000.00</AssetValue> <Policy> <PolNumber>893ABC</PolNumber> <LineOfBusiness tc="2">annuity</lineofbusiness> <CarrierCode>12388</CarrierCode> <Annuity> 35

<QualPlanType tc="1">non-qualified</qualplantype> </Annuity> <FinancialActivity> <FinActivityType tc="10">full Surrender</FinActivityType> <FinActivityGrossAmt>80000.00</FinActivityGrossAmt> <FinActivityNetAmt>80000.00</FinActivityNetAmt> <FinActivityDate>2004-10-01</FinActivityDate> <ReferenceNo>ABC444</ReferenceNo> <PostTEFRACostBasisAmt>67000.00</PostTEFRACostBasisAmt> <Payment> <PaymentForm tc="11">clearinghouse</paymentform> </Payment> </FinancialActivity> </Policy> </Holding> <!--Holding Being "Proposed"--> <Holding id="holding_2"> <HoldingTypeCode tc="2">policy</holdingtypecode> <HoldingStatus tc="3">proposed</holdingstatus> <Policy> <PolNumber>499CDF</PolNumber> <LineOfBusiness tc="2">annuity</lineofbusiness> <CarrierCode>15987</CarrierCode> <Annuity> <QualPlanType tc="1">non-qualified</qualplantype> </Annuity> <RequirementInfo> <ReqCode tc="99">replaced Policy Funds</ReqCode> <RequirementInfoUniqueID>TrackingReq001</RequirementInfoUniqueID> <ReqStatus tc="11">completed</reqstatus> </RequirementInfo> </Policy> </Holding> <Party id="party_1"> <PartyTypeCode tc="1">person</partytypecode> <GovtID>1971971977</GovtID> <GovtIDTC tc="1">ssn</govtidtc> <Person> <FirstName>Roger</FirstName> <MiddleName/> <LastName>Rabbit</LastName> </Person> </Party> <Party id="party_2"> <PartyTypeCode tc="2">organization</partytypecode> <FullName>Life Insurance Carrier A</FullName> <Organization> <DTCCMemberCode>4566</DTCCMemberCode> </Organization> <Carrier> <CarrierCode>12388</CarrierCode> </Carrier> </Party> <Party id="party_3"> <PartyTypeCode tc="2">organization</partytypecode> <FullName>Life Insurance Carrier B</FullName> <Organization> <DTCCMemberCode>4561</DTCCMemberCode> </Organization> <Carrier> <CarrierCode>15987</CarrierCode> </Carrier> </Party> <Relation id="relation_1" OriginatingObjectID="Party_1" RelatedObjectID="Holding_2"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="8">owner</relationrolecode> 36

</Relation> <Relation id="relation_2" OriginatingObjectID="Party_1" RelatedObjectID="Holding_1"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="35">annuitant</relationrolecode> </Relation> <Relation id="relation_3" OriginatingObjectID="Party_2" RelatedObjectID="Holding_1"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="187">surrendering Carrier</RelationRoleCode> </Relation> <Relation id="relation_4" OriginatingObjectID="Party_3" RelatedObjectID="Holding_2"> <OriginatingObjectType tc="6">party</originatingobjecttype> <RelatedObjectType tc="4">holding</relatedobjecttype> <RelationRoleCode tc="87">carrier</relationrolecode> </Relation> <SettlementInfo> <SettlementDetail> <SettlementAmt>80000.00</SettlementAmt> <AccountDebitCreditType tc="1">credit</accountdebitcredittype> </SettlementDetail> </SettlementInfo> </OLifE> </TXLifeRequest> </TXLife> 37

8 REVISION HISTORY/CHANGE SUMMARY Version Date Description of Change 3.1 Jan. 2009 ACORD's Standards License (formerly our Terms and Conditions of Use) has been updated. This is a documentation change only. No content changes have been made. 3.0 Draft March 2005 Documentation updates to reflect TXLife 2.12 2.0 Proposed Final August 2003 Proposed Final release for review / approval. Reformatting and overall documentation updates. 38