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
rd
3 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
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
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
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
5
The Replacement Process
Producer : Producer
/ Distributor
New Buz Sub App + Replacement Form
Any Required Form ( 1 or more attach)
Carrier : New
Carrier
Carrier : Old
(current) Carrier
ACK
ReplacementNotif (TX 127) Replacement Form (+ 0 or more attach)
Request for Status (Inquiry)
Supply additional Info.
Status Request can be
made at any time in
during the process
One or more required forms.
The current carrier may question the order of any form or image.
Respond To Status Inquiry
Something is not in "good order‖ (TX 1128)
Request For More Info.
Replacement Request (TX 127)
Letter of Authorization
Surrender Form
Any of the below may be attachments.
Transfer Form
* Replacement Form
* Sales Materials
* Illustration
* Compliance or Policy Summary
* Surrender Form
* Exchange Agreement
* Assignment
* Letter of Authorization (annuity)
* TransfereForm
Funds beingTransferred (TX 1128)
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
Actors/ Parties
Producer -> Carrier
Distributor ->
Carrier
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.
Carrier -> Carrier
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.
Carrier -> Carrier
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
7
5
REPLACEMENT OBJECT DIAGRAMS
5.1 Replacement Messages – #1 TXLife Class Diagram
Phone
Address
Banking
OLifE
-BankAcctType : Integer
-AccountNumber : String
-AcctHolderName : String
-RoutingNumber : String
0..*
0..*
0..*
0..*
0..*
Relation
0..1
-PartyTypeCode : Integer
-FullName : String
-GovtID : String
-GovtIDTC : Integer
0..1
0..1
0..1
0..1
Holding
1
Party
-OriginatingObjectType : Integer
-RelatedObjectType : String
-RelationRoleCode : Integer
1
0..1
-HoldingTypeCode : Integer
-HoldingStatus : Integer
-AssetValue : Decimal
-LiabilityValue : Decimal
0..1
1
1
RequirementInfo
0..10..1
0..1
Person
Organization
-FirstName : String
-MiddleName : String
-LastName : String
-DTCCMemberCode : String
Policy
-ReqCode : Integer
-ReqStatus : Integer
-RequirementStatusReason : String
-ReqSubStatus : Integer
-RequirementInfoUniqueID : String
0..*
0..*
0..1
FinancialActivity
Attachment
0..1
Carrier
-CarrierCode : String
-AttachementCategoryTC : Integer
-AttachmentBasicType : Integer
-AttachmentLocation : Integer
-AttachementData : String
-MimeTypeTC : Integer
-TransferEncodingTypeTC : Integer
0..*
-PolNumber : String
-LineOfBusiness : Integer
-CarrierCode : String
-CusipNum : String
-FinActivityType : Integer
-FinActivityNetAmt : Decimal
-PreTEFRACostBasis : Decimal
-PostTEFRACostBasis : Decimal
-FinActivityStatus : Integer
-FinActivityDate : Date
-FinActivityPct : Double
-FinActivityGrossAmt : Decimal
-SettlementAmt : Decimal
-ReferenceNo : String
Annuity
-QualPlanType : Integer
0..*
0..1
Life
-QualPlanType : Integer
0..1
SignatureInfo
-SignatureRoleCode : Integer
-SignatureDate : Date
-SignaturePurpose : Integer
-SignatureText : String
LifeUSA
0..*
-MECInd : Boolean
Payment
-PaymentForm : Integer
-@PayeeID : String
-@BankHoldingID : String
ArrSource
0..*
ArrDestination
-TransferAmt : Decimal
-TransferPct : Double
Arrangement
0..*
SettlementInfo
-RelatedRefID : String
-AccountNumberSubmitter : String
-ReferenceNo : String
-ArrType : Integer
-NumOfModalOccurances : Integer
-StartDate : Date
-PaymentForm : Integer
0..*
0..*
0..*
SettlementDetails
-SettlementAmt : Decimal
-AccountCreditDebitType : Integer
-AccountNumberReceiver : String
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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}
ProposedPolicy : Holding
{HoldingStatus = OLI_HOLDSTAT_PROPOSED,
HoldingTypeCode = OLI_HOLDTYPE_POLICY}
: Relation
{RelationRoleCode = OLI_REL_REPLACED}
: Relation
{RelationRoleCode = OLI_REL_OWNER}
: Relation
{RelationRoleCode = OLI_REL_ANNUITANT}
: Relation
{RelationRoleCode = OLI_REL_OWNER}
Owner : Party
{FullName = Fickle, Benedict A.,
GovtID = 123456789}
: Policy
{CarrierCode = 12345,
LineOfBusiness = OLI_LINEBUS_ANNUITY,
PolNumber = 19-123456B}
: Relation
{RelationRoleCode = OLI_REL_ANNUITANT}
: Person
{FirstName = Benedict,
LastName = Fickle,
MiddleName = A.}
: Arrangement
{ArrType = OLI_ARRTYPE_FULLSURR,
NumOfModalOccurances = 1,
PaymentForm = OLI_PAYFORM_CLEARHSE}
: ArrDestination
DeliveringCarrier : Party
{FullName = Sadder But Wiser Life Ins. Co.,
PartyTypeCode = OLI_PT_ORG}
: Organization
: Carrier
{DTCCMemberCode = 1234} {NAICCode = 12345}
: ArrSource
ReceivingCarrier : Party
{FullName = Jolly Rodger Mutual,
PartyTypeCode = OLI_PT_ORG}
: 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}
: Policy
{CarrierCode = 98765,
CusipNum = 123456789,
LineOfBusiness = OLI_LINEBUS_ANNUITY}
: Annuity
{QualPlanType = OLI_QUALPLAN_NONQUAL}
: RequirementInfo
{ReqCode = OLI_REQCODE_REPLFULL (new),
ReqStatus = OLI_REQSTAT_OUTSTANDING,
RequirementInfoUniqueID = JRL-021761-A20F}
: SignatureInfo
{SignatureDate = 2004-10-01,
SignaturePurpose = OLI_SIGTYPE_LOSTPOLDEC,
SignatureRoleCode = OLI_PARTICROLE_OWNER,
SignatureText = Benadict A. Fickle}
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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}
: Relation
{RelationRoleCode = OLI_REL_OWNER}
: 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}
ProposedPolicy : Holding
{HoldingStatus = OLI_HOLDSTAT_PROPOSED,
HoldingTypeCode = OLI_HOLDTYPE_POLICY}
: Relation
{RelationRoleCode = OLI_REL_OWNER}
: Relation
Owner : Party
{FullName = Fickle, Benedict A., {RelationRoleCode = OLI_REL_ANNUITANT}
GovtID = 123456789}
: Person
{FirstName = Benedict,
LastName = Fickle,
MiddleName = A.}
: Policy
{CarrierCode = 98765,
CusipNum = 123456789,
LineOfBusiness = OLI_LINEBUS_ANNUITY}
: RequirementInfo
{ReqCode = OLI_REQCODE_REPLFUNDS (new),
ReqStatus = OLI_REQSTAT_ERROR,
ReqSubStatus = OLI_REQSUBSTAT_NEEDFORM (new),
RequirementInfoUniqueID = JRL-021761-A20F}
ReceivingCarrier : Party
{FullName = Jolly Rodger Mutual,
PartyTypeCode = OLI_PT_ORG}
: Organization
{DTCCMemberCode = 9876}
: RequirementInfo
{ReqCode = OLI_REQCODE_REPFORM,
: Carrier
ReqStatus = OLI_REQSTAT_OUTSTANDING,
{CarrierCode = 12345} RequirementStatusReason = Submit signed ACORD Form #208-FL}
: Carrier
{CarrierCode = 98765}
: Address
{AddressType = OLI_ADTYPE_CLIENTCSA}
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
10
5.4 Replacement Messages - #4 Replacement Processing Update, Final: TXLife #1128
TX1128 : OLifE
: SettlementInfo
: SettlementDetails
{SettlementAmount = 19319.14}
: Relation
{RelationRoleCode = OLI_REL_OWNER}
DeliveringCarrier : Party
{FullName = Sadder But Wiser Life Ins. Co.,
PartyTypeCode = OLI_PT_ORG}
: Organization
: Carrier
{DTCCMemberCode = 1234} {CarrierCode = 12345}
: Relation
{RelationRoleCode = OLI_REL_OWNER}
: Policy
{CarrierCode = 98765,
CusipNum = 123456798,
LineOfBusiness = OLI_LINEBUS_ANNUITY}
Owner : Party
{FullName = Fickle, Benedict A.,
GovtID = 123456789}
: Person
{FirstName = Benedict,
LastName = Fickle,
MiddleName = A.}
ReceivingCarrier : Party
{FullName = Jolly Rodger Mutual,
PartyTypeCode = OLI_PT_ORG}
: Organization
{DTCCMemberCode = 9876}
: Carrier
{CarrierCode = 98765}
: RequirementInfo
{ReqCode = OLI_REQCODE_REPLFUNDS (new),
ReqStatus = OLI_REQSTAT_COMPLETED}
: RequirementInfo
{ReqCode = OLI_REQCODE_REPFORM,
ReqStatus = OLI_REQSTAT_COMPLETED}
: 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}
e
: Policy
{CarrierCode = 12345,
LineOfBusiness = OLI_LINEBUS_ANNUITY,
PolNumber = 19-123456B,
PolicyStatus = OLI_POLSTAT_SURR}
ProposedPolicy : Holding
{HoldingStatus = OLI_HOLDSTAT_PROPOSED,
HoldingTypeCode = OLI_HOLDTYPE_POLICY}
: Relation
{RelationRoleCode = OLI_REL_REPLACED}
Pay
e
ReplacedPolicy : Holding
{AssetValue = 58025.19,
HoldingStatus = OLI_HOLDSTAT_INACTIVE,
HoldingTypeCode = OLI_HOLDTYPE_POLICY,
LiabilityValue = 38706.05}
: Payment
{PaymentForm = OLI_PAYFORM_CLEARHSE}
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
ID
or stream.
<AddressTypeCode>
Type Code
Type of address
LookUp Table String
Type Code Translation
―Address Type‖
17 = Mailing
<Line1>
<Line2>
<Line3>
<City>
<AddressState>
String
String
String
String
String
String
Note: This is a partial list from the current ACORD spec.
Please see current spec. for additional codes.
Used to contain an attention of additional address line.
Specific person or department to provide additional detail
First line of the address
Second line of the address
Third line of the address
City of the address
State of the address.
<AddressStateTC>
<Zip>
<AddressCountry>
<AddressCountryTC>
Type Code
String
String
Type Code
2 letter State code in US, etc
Zip code, postal code, etc. (country dependent)
Country of the address
Use nation for valid Address Country type codes
<AttentionLine>
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>
Type Code
Tax Status of the policy or plan.
LookUp Table String
“Qualified Plan Type”
Type Code Translation
1 = Non-Qualified
2 = 401k
3 = 403b
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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)
Note: This is a partial list from the current ACORD
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>
Type Code
Type of Arrangement
LookUp Table String =
―Arrangement Type‖
Type Code Translation
7 = Specified Amount Withdrawal (net)
14 = Percent of value withdrawal
31 = Full Surrender
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes.
<StartDate>
Date
<NumOfModalOccurences>
Integer
<PaymentForm>
LookUp Table String =
―Payment Form‖
Type Code
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.
TXLife Specification Guide lists this field as required! I
don‘t remember why…….discuss with Rob Marone to see if
he remembers…….
Physical Form of Payment
Type Code Translation
7 = EFT
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
13
10 = Corporate Check
11 = Clearinghouse
12 = Wire
Note: This is a partial list from the current ACORD
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>
Type Code
This describes the basic type of attachment. If it is other
LookUp Table String =
than text, you must look at AttachmentType and
―Attachment Basic Type‖
MimeType to correctly use the data.
Type Code Translation
2 = Image
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
14
XML Element Name
Type
Description
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes.
<AttachmentData>
LookUpTable String =
―Variant Types‖
Type Code
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
Type Code Translation
???
<AttachmentType>
LookUp Table String =
―Attachment Type‖
Type Code
Type of Attachment
Type Code Translation
13 = Wet signature image
65 = ACORD 759 - Important Notice Regarding
Replacement Form
73 = ACORD 951 - 1035 Exchange / Rollover / Transfer
Form
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<MimeTypeTC>
LookUp Table String =
―Mime Type‖
Type Code
Describes the format of the Imaged file despite the
contents (forms, letters, notes, etc.)
Type Code Translation
3 = Image jpeg
4 = Image gif
11 = Image tiff
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<TransferEncodingTypeTC>
LookUp Table String =
―EncodeType‖
Type Code
Transfer Encoding Type:
Type Code Translation
6 = Binary
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
15
XML Element Name
Type
Description
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<AttachmentLocation>
LookUp Table String =
―Attachement Location‖
Type Code
Indicates if the attachment is stored as inline or as a URL
reference.
Type Code Translation
1 = Inline
2 = URL Reference
3 = Mulitpart Mime
<AttachmentCategoryTypeCode> Type Code
LookUp Table String =
―Attachment Category Type‖
Form Instance Category Type Code
Type Code Translation
28 = Replacement Form
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
Type Code
In the case that the PaymentMethod is 'electronic
LookUp Table String=
funds transfer,' this is the type of account associated
'Bank Account Type'
with the bank account.
Type Code Translation
2 = Checking
<AccountNumber>
String
<RoutingNum>
String
<BankName>
String
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes.
The account number for the bank account.
The routing number for the bank account, in the case
of PaymentMethod = 'Electronic Funds Transfer'.
UML says RoutingNum
Name of the Bank in which the funds are to be or
have been depositied.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
<NAICCode>
This code uniquely represents the Insurance Carrier
NAIC Code
String
String
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
<FinActivityType>
LookUp Table String=
'Financial Activity Type'
Type Code
<FinActivityGrossAmt>
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.
The type of financial activity.
Type Code Translation
10 = Full Surrender
11= Partial Surrender
Currency
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes.
The gross amount for this financial activity.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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
<PostTefraCostBasis>
Currency
Premiums paid into an annuity contract prior to August 14,
1982. These premiums may be withdrawn under the FIFO
order of withdrawal.
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‖
Type code
Type of Holding
Type Code Translation
2 = Policy
7 = Banking
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes.
<HoldingStatus>
LookUp String =
―Holding Status‖
Type Code
Status of the Holding
Type Code Translation
<AssetValue>
Currency
<LiabilityValue>
Currency
1 = Active
3 = Proposed-pending
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.
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
Type Code
Tax Status of the policy or plan.
LookUp Table String
“Qualified Plan Type”
Type Code Translation
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)
Note: This is a partial list from the current ACORD
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.
Type Code Translation
0 = False
1 = True
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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
<PartyTypeCode>
LookUp Table String =
―PartyType‖
<FullName>
<GovtID>
<GovtIDTC>
LookUp Table String =
―Government ID Type Code‖
Type Code
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.
Type of Party
Type Code Translation
String
Integer
Type Code
1 = Person
2 =Organization
Full Legal Name of the Party.
9-digit Federal Tax ID of the Party.
Type code describing the contents of GovtID.
Type Code Translation
1 = Social Security Number
2 = Taxpayer Identification Number
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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
<PaymentForm>
LookUp Table String =
―Payment Form‖
Type Code
Refers to Banking Aggregate. Passed when PaymentForm
is EFT or Wire.
Physical Form of Payment
Type Code Translation
7 = EFT
10 = Corporate Check
11 = Clearinghouse
12 = Wire
Note: This is a partial list from the current ACORD
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>
<MiddleName>
<LastName>
<Gender>
LookUp Table String =
―Gender Type‖
<BirthDate>
String
String
String
Type Code
First name of the person
Middle name of the person
Last name of the person
Gender of the person
Date
Type Code Translation
1 = Male
2 = Female
Date of birth for the person
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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‖
<AreaCode>
<DialNumber>
<Ext>
XML Element Name
Type Code
Type of phone
String
String
String
Type Code Translation
2 = Business
Area code
Phone number Does not include country code or area code
Extension of the phone number (if any)
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>
Type Code Line of business of the insurance.
LookUp String =
Type Code Translation
―Line of Business
1 = Life
2 = Annuity
<CarrierCode>
XML Element Name
String
Issuing carrier code.
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
<RelatedObjectid>
<OriginatingObjectType>
LookUp String =
―Object Type‖
IDREF
IDREF
Type Code
Unique identifier of originating top-level object.
Unique identifier of related top-level object
Type of top-level object, within the ACORD model, of
originator.
Type Code Translation
6 = Party
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<RelatedObjectType>
LookUp String =
―Object Type‖
Type Code
Type of top-level object, within the ACORD model, of
originator.
Type Code Translation
4 = Holding
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<RelationRoleCode>
LookUp String =
―Relation Role Code‖
Type Code
Type of relationship between Originating and Related
objects
Type Code Translation
8 = Owner
32 = Insured
35 = Annuitant
87 = Carrier
187 = Surrendering Carrier
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
<ReqCode>
LookUp String =
―Requirement Code‖
String
Type Code
Used as a tracking number for the requirement
Specifies the Requirement
Type Code Translation
124 = Original Policy
127 = Replacement Form
134 = 1035 Exchange Form
156 = Absolute Assignment of Policy Ownership
165 = Signed Application
655 = Replaced Policy Funds
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<OriginatingObjectType>
LookUp String =
―Object Type‖
Type Code
Type of top-level object, within the ACORD model, of
originator.
Type Code Translation
6 = Party
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
<ReqStatus>
LookUp String =
―Requirement Status‖
Type Code
The status of the Requirement
Type Code Translation
6 = Declined
11 = Completed
4 = Outstanding
Note: This is a partial list from the current ACORD
spec. Please see current spec. for additional codes
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
25
XML Element Name
Type
<RequirementStatusReasoon>
LookUp String =
―Requirement Status‖
<ReqSubStatus>
LookUp String =
―Requirement Sub Status‖
String
Type Code
Description
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.
Type Code Translation
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
Note: This is a partial list from the current ACORD
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>
Type Code Indicates whether the Settlement is a debit or a credit.
LookUp String =
Type Code Translation
―Accounting Credit Debit Type‖
1 = Credit
2 = Debit
<AccountNumberReceiver>
XML Element Name
String
Type
The account number of the Receiving Carrier
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
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
26
XML Element Name
<ReferenceNo>
XML Element Name
Type
String
Description
Tracking Id
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
Type Code Role code describing the signors relationship to the form
Type Code Translation
18 = Owner
<SignatureRoleCode>
LookUp String =
―Participant Role‖
<SignatureDate>
<SignaturePurpose>
LookUp String =
―Signature Type‖
Note: This is a partial list from the current ACORD spec.
Please see current spec. for additional codes
Date
Date of the Signature
Type Code
Reason for Signature
Type Code Translation
1 = Lost Policy Declaration
Note: This is a partial list from the current ACORD spec.
Please see current spec. for additional codes
<SignatureText>
String
Signature Text Value
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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 Type Code 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>
<AppVer>
String
String
Name of system creating product profile (source system)
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
receiving system.
<TransSubType tc=‖###‖
Typecode
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
30
XML Element Name
<TransExeDate>
<TransExeTime>
<TransMode>
<NoResponseOk tc=―1‖>
<TestIndicator>
XML Element Name
Type
Date
Time
TypeCode
Boolean
1 = Yes
Boolean
0 = No
1 = Yes
Description
Date and time when this file or feed was created.
Time when this file or feed was created.
Indicates if a response is desired or necessary.
For a transmittal set to ―1‖ for Yes.
Indicates whether this is a test or production file/stream.
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>
<AppVer>
String
String
Name of system creating product profile (source system)
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>
<TransExeTime>
<TransMode>
<NoResponseOk tc=―1‖>
<TestIndicator>
Date
Time
TypeCode
Boolean
1 = Yes
Boolean
0 = No
1 = Yes
Date and time when this file or feed was created.
Time when this file or feed was created.
To be discussed
Indicates if a response is desired or necessary.
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
<TransMode>
<NoResponseOK tc="1">TRUE</NoResponseOK>
<OLifE>
… <!—BEGIN XMLife DATA -->
</OLifE>
…
<!—close tags -->
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 -->
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
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>
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
37
8
REVISION HISTORY/CHANGE SUMMARY
Version
Date
Description of Change
3.1
Jan. 2009
3.0 Draft
2.0 – Proposed Final
March 2005
August 2003
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.
Documentation updates to reflect TXLife 2.12
Proposed Final release for review / approval. Reformatting and
overall documentation updates.
© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.
ACORD L&A LIFE REPLACEMENT IMPLEMENTATION GUIDE – VERSION 3.1 – JAN. 2009
38