ACORD Standards Implementation Guide Template Life

Transcription

ACORD LIFE, ANNUITY & HEALTH STANDARDS
NEW BUSINESS SUBMISSION FOR LIFE (NBfL)
IMPLEMENTATION GUIDE
VERSION 2.0
JANUARY 2010
References: ACORD Life Specification, Version 2.21
IMPORTANT NOTE: This document contains or relates to ACORD Standard Life, Annuity & Health. 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
© 2008-2010 ACORD CORPORATION – ALL RIGHTS RESERVED.
Table of Contents
1
INTRODUCTION .................................................................................................................................. 1
1.1
PREFACE ....................................................................................................................................... 1
1.2
INTENDED AUDIENCE ...................................................................................................................... 1
1.3
PURPOSE OF THIS GUIDE .............................................................................................................. 1
1.4
XML STANDARD ............................................................................................................................ 1
1.5
HIGHLIGHTS OF AN INDUSTRY STANDARD BUSINESS MESSAGE ........................................................ 2
1.6
ACORD STANDARDS ..................................................................................................................... 3
1.6.1 ACORD Standards Overview .................................................................................................. 3
1.6.2 Resources Available – Getting Help ....................................................................................... 3
1.6.3 Purpose of Implementation Guides ......................................................................................... 3
1.6.4 Implementation Reporting – Tell us about it! ........................................................................... 4
1.6.5 Certification.............................................................................................................................. 4
2
BUSINESS OBJECTIVES AND EXPECTED BENEFITS ................................................................... 5
2.1
OBJECTIVES AND PROBLEM DESCRIPTION ....................................................................................... 5
2.2
BUSINESS PROCESS(ES) SUPPORTED ............................................................................................. 5
2.3
VALUE PROPOSITION...................................................................................................................... 6
2.4
SCOPE .......................................................................................................................................... 6
2.5
NEW BUSINESS SUBMISSION W ORKFLOW DIAGRAM......................................................................... 7
2.6
REGIONAL DIFFERENCES ................................................................................................................ 9
2.7
PRODUCT DIFFERENCES ................................................................................................................ 9
3
GUIDING PRINCIPLES FOR IMPLEMENTATION ........................................................................... 10
3.1
NEW BUSINESS PROCESSING DIFFERENCES FOR OTHER LINES OF BUSINESS ................................. 10
3.1.1 Life vs. Annuities ................................................................................................................... 10
3.2
HOLDINGS ................................................................................................................................... 10
3.2.1 General Guidelines for Holdings ........................................................................................... 10
3.2.2 Holding for the Proposed Policy ............................................................................................ 10
3.2.3 Holdings for Existing insurance (not being replaced) ............................................................ 11
3.2.4 Holdings for Replaced, Exchanged, or Converted Policies / Existing Policies ..................... 11
3.2.5 Holdings for pending or planned insurance (alternate or additional) .................................... 12
3.3
PARTIES ...................................................................................................................................... 12
3.3.1 General Party Modeling Guidelines ...................................................................................... 12
3.3.2 Party for Primary Proposed Insured ...................................................................................... 12
3.3.3 Identification of the Carrier for the Proposed Policy .............................................................. 12
3.3.4 All Other Parties .................................................................................................................... 13
3.4
FINANCIALACTIVITY AND ARRANGEMENT ....................................................................................... 13
3.5
CLARIFICATION FOR STATES/ADDRESSES/COUNTRIES ................................................................... 13
4
LIFE ELECTRONIC APPLICATION SUBMISSION HIERARCHY ................................................... 15
5
DETAILED ELEMENT DESCRIPTIONS & TYPE CODES DEFINITIONS ....................................... 17
5.1
IDENTIFYING OBJECTS USING IDS, CODES AND KEYS ..................................................................... 17
5.2
<ADDRESS> OBJECT.................................................................................................................... 19
5.3
<APPLICATIONINFO> OBJECT ....................................................................................................... 22
5.4
<ARRANGEMENT> OBJECT ........................................................................................................... 30
5.5
<ATTACHMENT> OBJECT FOR TEXT............................................................................................... 37
5.6
<ATTACHMENT> OBJECT FOR IMAGES ........................................................................................... 39
5.7
<ATTACHMENT> OBJECT FOR FILE ................................................................................................ 43
5.8
<AUTHORIZATION> OBJECT FOR CHANGING INVESTMENT INSTRUCTIONS ........................................ 47
5.9
<BANKING> OBJECT .................................................................................................................... 49
5.10
<BANKRUPTCY> OBJECT .............................................................................................................. 54
5.11
<COVERAGE> OBJECT (BASE COVERAGE) .................................................................................... 56
ACORD LAH STANDARDS NBFL IMPLEMENTATION GUIDE VERSION 2.0 – JANUARY 2010
5.12
<COVERAGE> OBJECT (RIDER COVERAGE)................................................................................... 60
5.13
<COVOPTION> OBJECT................................................................................................................ 65
5.14
<EMAILADDRESS> OBJECT .......................................................................................................... 69
5.15
<EMPLOYMENT> OBJECT ............................................................................................................. 70
5.16
<FINANCIALACTIVITY> OBJECT FOR INITIAL PAYMENT..................................................................... 71
5.17
<FINANCIALACTIVITY> OBJECT FOR 1035 EXCHANGE.................................................................... 73
5.18
<FORMINSTANCE> OBJECT .......................................................................................................... 75
5.19
<HOLDING> OBJECT FOR PROPOSED POLICY ................................................................................. 77
5.20
<HOLDING> OBJECT FOR EXISTING INSURANCE ............................................................................. 80
5.21
<HOLDING> OBJECT FOR EXISTING INSURANCE THAT IS BEING REPLACED ....................................... 84
5.22
<HOLDING> OBJECT FOR EXISTING INSURANCE THAT IS BEING EXCHANGED .................................... 89
5.23
<HOLDING> OBJECT FOR BANK..................................................................................................... 94
5.24
<HOLDING> OBJECT FOR LOAN .................................................................................................... 95
5.25
<INVESTMENT> OBJECT ............................................................................................................... 98
5.26
<LIFE> OBJECT ........................................................................................................................... 99
5.27
<LIFEPARTICIPANT> OBJECT ...................................................................................................... 101
5.28
<LIFEUSA> OBJECT FOR EXISTING POLICY ................................................................................. 112
5.29
<LIFEUSA> OBJECT FOR THE PROPOSED POLICY ........................................................................ 113
5.30
<MEDICALCONDITION> OBJECT .................................................................................................. 115
5.31
<MEDICALEXAM> OBJECT .......................................................................................................... 119
5.32
<MEDICALPREVENTION> OBJECT ............................................................................................... 122
5.33
<MEDICALTREATMENT> OBJECT ................................................................................................ 125
5.34
<ORGANIZATIONFINANCIALDATA> OBJECT FOR BUSINESS INSURANCE......................................... 128
5.35
<PARTY> OBJECT FOR PROPOSED INSURED(S) ........................................................................... 130
5.36
<PARTY> OBJECT FOR BENEFICIARY (PERSON) .......................................................................... 142
5.37
<PARTY> OBJECT FOR BENEFICIARY (ORGANIZATION) ................................................................ 145
5.38
<PARTY> OBJECT FOR NATURAL PERSON OWNER WHO IS NOT THE INSURED ................................. 148
5.39
<PARTY> OBJECT FOR ORGANIZATION OWNER ............................................................................ 152
5.40
<PARTY> OBJECT FOR OTHER BUSINESS INSURANCE OWNERS ..................................................... 156
5.41
<PARTY> OBJECT FOR AGENCY .................................................................................................. 159
5.42
<PARTY> OBJECT FOR PRODUCER ............................................................................................. 162
5.43
<PARTY> OBJECT FOR CARRIER ................................................................................................. 165
5.44
<PARTY> OBJECT FOR CREDITOR ON THE COLLATERAL LOAN ....................................................... 166
5.45
<PARTY> OBJECT FOR ACCOUNT OWNER .................................................................................... 168
5.46
<PARTY> FOR EMPLOYER .......................................................................................................... 170
5.47
<PARTY> PAYOR FOR PERSON OR ORGANIZATION ...................................................................... 173
5.48
<PAYMENT> OBJECT.................................................................................................................. 176
5.49
<PHONE> OBJECT ..................................................................................................................... 179
5.50
<POLICY> OBJECT FOR PROPOSED POLICY ................................................................................ 181
5.51
<PRESCRIPTIONDRUG> OBJECT ................................................................................................. 187
5.52
<RELATION> OBJECT FOR CONTRACT LEVEL (HOLDING TO HOLDING FOR
REPLACEMENTS/EXCHANGES) ................................................................................................................. 190
5.53
<RELATION> OBJECT FOR CONTRACT LEVEL (HOLDING TO PARTY)............................................... 191
5.54
<RELATION> OBJECT FOR CONTRACT LEVEL (PARTY TO PARTY) .................................................. 194
5.55
<REQUIREMENTINFO> OBJECT ................................................................................................... 196
5.56
<RISK> OBJECT ......................................................................................................................... 199
5.57
<SIGNATUREINFO> OBJECT ....................................................................................................... 215
5.58
<SOURCEINFO> OBJECT ............................................................................................................ 218
5.59
<SUBACCOUNT> OBJECT ........................................................................................................... 219
5.60
<SUBSTANDARDRATING> OBJECT .............................................................................................. 221
5.61
<W EIGHTHISTORY> OBJECT ...................................................................................................... 225
6
TRANSMITTING/SENDING A NEW BUSINESS SUBMISSION FOR LIFE INSURANCE ............ 227
6.1
<USERAUTHREQUEST> OBJECT................................................................................................. 228
6.2
<TXLIFEREQUEST> OBJECT ...................................................................................................... 229
6.3
6.4
6.5
<TXLIFERESPONSE> OBJECT FOR SUCCESS-IGO RESPONSE ..................................................... 232
<TXLIFERESPONSE> OBJECT FOR FAILURE-NIGO RESPONSE .................................................... 235
<TXLIFERESPONSE> OBJECT FOR PENDING RESPONSE (PERFORMING CHECKS)......................... 238
7
NEW BUSINESS SUBMISSION STANDARD USAGES ................................................................ 241
7.1
NBFL SAMPLE SCENARIO 1: BASIC TERM INSURANCE SUBMISSION .............................................. 241
7.2
NBFL SAMPLE SCENARIO 2: BASIC VARIABLE UNIVERSAL LIFE INSURANCE SUBMISSION ............... 249
8
INDEX ............................................................................................................................................... 257
9
REVISION HISTORY/CHANGE SUMMARY ................................................................................... 258
9.1
REVISION DETAILS FROM VERSION 1.0 TO VERSION 2.0 ................................................................ 259
9.1.1 Updated from 2.17 to 2.21 & Other Misc Updates .............................................................. 259
9.1.2 FinancialActivity & Arrangements........................................................................................ 259
9.1.3 Added Variable Life Requirements...................................................................................... 259
9.1.4 Added Replacement & Exchange Requirements ................................................................ 259
9.1.5 Updated TXLife Request & Added TXLife Response Requirements .................................. 260
9.1.6 Added Part A & B Requirements ......................................................................................... 260
9.1.7 Add Business Insurance Requirements .............................................................................. 260
APPENDIX A – HOW TO MODEL ROLES .................................................................................................. 1
CONTRACT LEVEL ROLE .............................................................................................................................. 2
COMPONENT LEVEL ROLE ........................................................................................................................... 3
OVERRIDE LEVEL ROLE ............................................................................................................................... 4
COMPARISON OF THE THREE LEVELS OF ROLES ........................................................................................... 5
APPENDIX B – SAMPLE XML FOR BENEFICIARY ROLES ..................................................................... 6
CONTRACT LEVEL: ...................................................................................................................................... 6
COMPONENT LEVEL: ................................................................................................................................. 10
OVERRIDE LEVEL: ..................................................................................................................................... 15
APPENDIX C – NEW BUSINESS POLICY STATUS TRANSITIONS ....................................................... 16
APPENDIX D – REQUIRMEMENT STATUS TRANSITIONS ................................................................... 18
1
INTRODUCTION
1.1 Preface
This Guide has been prepared by ACORD and its members to provide you with a roadmap for
implementing the New Business Submission transaction for Life Insurance (TransType = 103). This
guide identifies the problem, the reason for solving it, the risks and benefits involved, and the resolution
method utilized.
1.2 Intended Audience
This Guide is intended for business, operations and technology people. It explains why these business
messages were developed, when they should be used, the value of using them, as well as how to do it.
We have left most of the technical “how” to the end. Your input is always welcome. Please send all
feedback to the ACORD Standards Department (www.acord.org).
1.3 Purpose of THIS Guide
The purpose of this Implementation Guide is to provide the user with a consistent interpretation for
implementation of an industry-recognized solution for the need to submit new business for Life Insurance
via electronic data transfer. This guide is not intended to address in-force policy administration.
1.4 XML Standard
Why XML? XML, the eXtensible Markup Language, is not a technology, programming language,
database or magic tool. It is a markup language used to describe and organize data. XML is a very
flexible, effective method for describing information (data) in such a way that the XML document or file
provides:
Definition – a common vocabulary to identify things/information/data
Structure – a common way of organizing information (a grammar, so that we all structure information the
same way)
Precision – a common method or set of rules for structuring the data that enables automated processing
of information being sent between trading partners.
XML is not based on any one vendor but transcends and is used by them all. XML is represented as
normal, simple text using human readable symbols, which makes XML, structured information easy to
read and debug, transportable across any machine, operating system or programming language.
Another misconception about Standards, and XML, is that it is somehow the best or optimum way of
solving a specific business problem.
1
Actually, by design it is NOT the optimum solution for any singular problem, since the intent is to provide
a means for many trading/business partners to share information regardless of systems or other
technology. As a result the ACORD Standards are more a base level common agreement within the
industry of how we are all consistently going to describe insurance contract and related properties. This
common definition is likely, even intended, to be remapped and repurposed within each trading partner‟s
own organization for their own purposes, However, between organizations ACORD Standards provides a
uniform, consistent way of sharing data.
1.5 Highlights of an Industry Standard Business Message
It‟s an XML specification (with all the benefits of XML),

Based on the ACORD Standards

With implementation guidelines that define precisely what the specific fields of information should be (i.e.
XML Elements)

With well-defined organization or structure

Providing Industry defined usage examples

Using common code list definitions with agreed upon meanings

Developed by industry business and technology experts
So now instead of this:
We have this:
XML
One-To-One Sharing, All Different
One-To-Many Sharing, All Same
2
1.6 ACORD Standards
1.6.1 ACORD Standards Overview
It is important to understand that this guide is based on the ACORD Life Standards – XMLife, XTbML 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 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.6.2 Resources Available – Getting Help
In addition to this Guide, ACORD provides many additional resources to aid implementation including:

ACORD Web site and File Areas where archives of Specification development and Working Group
determinations are available

Technical support from ACORD Implementation Service Team via telephone or email

Training Services from ACORD staff
And never underestimate the networking opportunities provided to attendees at ACORD meetings where
you can ask peers how they have handled various implementation issues.
In addition, each ACORD Standards Program provides many specific resources including:
* Life Standard Schema (XMLife, TXLife, XTbML, Base)
* Life Data Model and Browser – Complete Life Standard Data Model and Dictionary
* XMLife Specification Guide –Life Standard Guidelines, Rules and Principals
* TXLife Specification Guide – Transaction/Business Messages Guidelines
And much, much more... All can be found on the ACORD web site at www.acord.org.
* Please Note - Only the Life Standard Schemas are in the public domain, available for anyone‟s use. All
other tools and resources, like these Guides, are for the benefit of ACORD members only.
1.6.3 Purpose of Implementation Guides
Implementation Guidelines published under the ACORD Standards Program are not to be regarded as
Industry Standards. They contain information regarding practices and suggestions (as of their publication
date) of Standards users regarding a particular subject. Implementation Guidelines are published in order
to provide practical assistance to Standards users based upon the experience of earlier users. It is
intended that no conflict exist between information contained in any ACORD Standards and
Implementation Guidelines. In the event of any such conflict, the applicable Standard wording will prevail.
ACORD Standard Implementation Guidelines are designed to help developers of systems using ACORD
Standards familiarize themselves with the Standards process and how Standards are being used in
actual systems.
The Guidelines represent the consensus of ACORD„s standards participants on how the ACORD
Standards are meant to be used. They originate in response to specific questions or issues that surface
in the process of developing or implementing Standards.
3
1.6.4 Implementation Reporting – Tell us about it!
Standards aren‟t truly relevant until they are used. To help drive the use of Standards, and to let those
organization who have adopted Standards know who else has too, ACORD publishes a regularly updated
schedule of all the organizations using Standards and which Business Messages/Transactions they
support. This report can be found on the ACORD web site – www.acord.org.
As you develop and implement your messages, please report them to ACORD. The website includes an
Implementation Survey to indicate the ACORD Standard (Life, P&C, Reinsurance) and messages which
you have in development, pilot or production.
1.6.5 Certification
Beyond reporting who has implemented Standards, which is by definition a self-reporting exercise,
ACORD offers a Certification Process for all its messages. This provides members with the added
acknowledgement of their use of Standards and furthermore notifies other potential clients/trading
partners of their ability to support well-formed, compliant ACORD messages.
Having all trading partners certify their messages makes implementation much easier, faster and allows a
third, neutral party (ACORD) to provide reconciliation of implementation ambiguities (and resolve these in
future versions of the Standards).
To get certified, or to get more information, visit the ACORD web site, Members Area for more details – or
feel free to contact an ACORD for assistance (www.acord.org).
4
2
BUSINESS OBJECTIVES AND EXPECTED BENEFITS
2.1 Objectives and Problem Description
The objective of this guide is the establishment of a standard message set content for the New Business
Submission process. Although, as stated in section 1.4, one of the purposes of the ACORD Standards is
to provide a uniform, consistent way of sharing data between organizations, the standard itself is open to
interpretation and flexibility. The intent of this guide is to provide a standard interpretation of the model for
the exchange of new business submission information to enable the exchange of messages in a
consistent manner. All trading partners that adhere to the standard interpretation set out here should be
able to depend on information presented in a consistent manner and not have the burden of building
systems to receive messages that are specific to certain senders or receivers.
One of the fallacies of the use of the ACORD standard without the direction of an implementation guide is
that if you create an ACORD message that validates against the ACORD schema, you should be able to
exchange messages with any other company using that same message. Though the ACORD message
does set out standard vocabulary and structures, the interpretation of the standard can vary. For
example, some implementations use the Relation Object where other implementations use an ID/IDREF
structure to represent a relationship. The purpose of this guide is to limit the individual interpretation and
specifically detail what vocabulary and structures should be used in the new business submission
process.
The exchange of new business submission messages has been at the forefront of implementations. It is
usually the first implementation that ACORD members attempt – as it represents the very purpose of
using a standard – to be able to exchange information with several trading partners using the same
format – and avoid the need for proprietary messages. Cost savings should be apparent immediately.
Rather than creating multiples messages and negotiating with multiple companies on the content of a
new business message, companies should be able to follow the standard set out by ACORD and
exchange the information needed by all in a consistent manner. Unfortunately that goal was not realized
without a guide. Each company that created a new business submission message did so by going down a
different path. Companies were forced to create specific ACORD messages for each trading partner thus
negating the value of using a standard. The purpose of this guide is to enable companies to realize the
benefits of using a standard.
This guide sets out the best practices for the use of the ACORD standard in the new business submission
process. It contains the details needed at the message level and the explanation of terms. It provides
expansion of the definitions of terms established by the standard and how that term is used for new
business submission.
2.2 Business Process(es) Supported
This guide addresses the application submission to carrier from agent/agency or third party aggregators
and does not address a separate policy number request. Implementers should refer to the 106 New
Business Policy Number Request transaction for details. This guide does not address underwriting
processes, except for underwriting requirements that may be included in the new business application.
These would be considered for the internal carrier underwriting workflows or for info sharing during new
business and underwriting process between the carrier and external trading partners.
The content of the 103 new business submission described in this guide is not based on any standard or
proprietary new business form.
5
Please note: The future scope would be to include the ACORD standard new business forms as an input
to the new business process supported by this guide.
2.3 Value Proposition
Adopting the techniques and message formats presented in this Guide provides the following benefits:
Defining a consistent automated method for new business submission reduces numerous errors and
ambiguities within applications submitted through manually intensive process. This will provide great cost
savings to companies while providing a consistent method for exchanging information with trading
partners. Other benefits include improved cycle time, improved efficiencies at carrier service centers, and
provides for improved auditing capabilities.
2.4 Scope
The ACORD Life Standards are wonderfully broad in scope. Its breadth provides the industry, and all
participants within it, a consistent „view‟ of their products, processes and partners. The scope of the
ACORD model is all-inclusive of three broad complimentary spectrums.
Product – The ACORD Life Standards provide a data model and business messages intended to support
all human mortality or morbidity risk based products. This expansive definition would include: Traditional
Life Products (Term, Whole Life, Universal Life, Adjustable Life, etc.), Annuities, Long-Term Care,
Disability Income and other products which have a significant pricing component based on the risk of a
person or persons dying or becoming disabled.
Partner/Party Role – The ACORD Life Standards encompass all participants in the insurance value
chain including the customer (Insured, Beneficiary, Payer, etc.), Agent, Distributor/Agency, Carrier,
Reinsurer, Retrocessionaire, Third-Party Providers (MIB, Labs, ParaMeds, etc.), Software/Solutions
Providers and even to an increasing degree Regulators & other reporting/monitoring authorities.
Note that we refer to “role” here since we also recognize that in any given scenario a given entity may
play one (or more) different roles. What you are doing (role) is more important than who you are.
Process – The purpose of the ACORD unified insurance data model is to provide a consistent “view” and
definition of the data relating to insurance products and parties. But this view may have different meaning
depending on the context, or business process, which you are describing. The ACORD TXLife
Transaction Specification, leverages the details in the Life Data Model to define which elements should
be provided for any given business process. TXLife provides the basic message structure. This
Implementation Guide goes one step further and defines with as specific detail as possible exactly what
content is required, desirable or optional for any given scenario for a given business process (e.g. new
business submission for Annuities between Agent/Distributor and Carrier).
Scope of this Implementation Guide / Business Message
The New Business for Life message (NBfL), TransType 103, is designed to provide a producer, agent,
agency, or any third party provider with the ability to electronically submit the contents of an application to
the carrier. This message is assumed to be a complete message, with all data elements necessary to
create a new business case at the carrier. It is understood, even expected, that additional requirements
may be generated as a result of this message.
The NBfL message may be used by the writing agent, general agent and/or others within the agent
appointment hierarchy (as appropriate), the carrier, and any vendors (i.e. paramed service or lab service).
Other users may include intermediaries appropriate for the specific distribution channel or
marketing/sales organization.
6
This version of the Guide is limited to:
Formal and new applications that are directed to the carrier
United States only
Excludes conversions
Includes replacements and 1035 Exchanges specific to the 103 transaction
Includes insurance purchased for business purposes
Includes the Part B/2 Medical Questions and laboratory results
Excludes questions from supplemental questionnaires (e.g. Hazardous Sports, Aviation, etc.)
2.5 New Business Submission Workflow Diagram
Starts:
When a consumer express an interest in a life insurance purchase to an agent.
Ends:
Upon receipt of the new business application at the insurance carrier. A receipt notification (TXLife response)
may or may not be sent back to the submitting party.
7
Excludes:
Policy changes (e.g. 6-month exchange, Free looks)
Internal Carrier workflow
BGA to Agent workflow
BGA/Agent to Consumer workflow
Pending Case Status
Delivery requirements
Consumer
Agent
Agency or
Third Party
Aggregator
Insurance
Company
8
2.6 Regional Differences
Regional differences may occur in the processing of New Business transactions. ACORD encourages
and supports variations that are based upon jurisdictional rules and conventions. ACORD standards will
occasionally vary based on commonly accepted regional differences. In these instances, the ACORD
Life STANDARD will provide guidance on the use of terms, Objects, Properties, Attributes and Code Lists
that may be used specifically by a jurisdiction.
The New Business Submission transaction described in this Implementation Guide is based upon
currently accepted business rules for jurisdictions within the United States. Future versions of this
Implementation Guide may include business rules and conventions of other jurisdictions.
2.7 Product Differences
This guide provides implementation best practices for new business submission messages for all life
insurance products including term, universal life, variable universal life and whole life. To the extent
possible, products are represented in the same way. However, product-specific information may be
represented when necessary and is clearly noted in the guide.
9
3
GUIDING PRINCIPLES FOR IMPLEMENTATION
The New Business for Life (NBfL) transaction was developed to be an XML standard for transmitting
electronic application information between Distributors and Insurance Carriers along with their other
trading Partners.
The following section is intended to provide some general guidelines in implementing the ACORD XML
standard for New Business Submission and to support validation of new applications. The list is not
meant to be exhaustive. On the contrary, it is expected that the list will grow as the standard gets
implemented across the industry over time. Suggestions for inclusion should be sent to ACORD to give
to the Policy Lifecycle Working Group.
This version of the guide does not represent all possible business cases or product types. See Section
3.4 for detail about the Scope of the transaction addressed in this Guide. However, some of these
Guiding Principles may extend beyond the scope of the current Guide.
For additional detail about any of the Objects addressed in the Guiding Principles, refer to Section 5 titled
Detailed Elements Descriptions and Type Code Definitions.
3.1 New Business Processing Differences for other Lines of Business
3.1.1 Life vs. Annuities
This section will be further developed in the next version of this guide. In the mean time, please
reference the LAH NBfA Implementation Guide V4.2 for specific details concerning annuity new
business processing.
3.2 Holdings
3.2.1 General Guidelines for Holdings
A new business submission message may contain multiple Holding objects. In addition to the proposed
policy, other Holding objects may be needed to represent:
Existing insurance policies that also cover the insured
Policies that are to be replaced, exchanged or converted by the proposed policy
Other pending policies
Bank Account used to pay premium
Other assets or liabilities
There is no requirement for the sequence in which Holding objects appear. The Holding object that
represents the proposed Policy can appear anywhere in the message.
3.2.2 Holding for the Proposed Policy
Basic rules for defining Holdings in the message are:
10
There will be one and only one Holding for the proposed Policy in a TXLifeRequest. To identify
this Holding, there are 2 constructs that MUST be included in the new business submission
message.
1. The attribute PrimaryObjectID MUST be present in the XML message. A PrimaryObjectID
is a pointer (IDREF attribute) to the primary Holding in the 103 message (in this case the
Holding representing the proposed Policy). By following the “@PrimaryObjectID” IDREF
the TXLife receiver has a predictable place to begin interpretation of the message
2. The DataRep attribute MUST appear on all Holdings that do not represent the proposed
Policy. DataRep attribute set to Read-Only indicates that this Holding is being included
for informational purposes only.
The example below illustrates the use of PrimaryObjectID and DataRep constructs. The second Holding
represents a policy that is being replaced.
<TXLifeRequest PrimaryObjectID="Holding1">
<OLifE>

<Holding id="Holding1">
<HoldingTypeCode tc="2">Policy</HoldingTypeCode>
<HoldingStatus tc="3">Proposed - Pending - Not yet inforce</HoldingStatus>
</Holding>

<Holding id="Holding3" DataRep="ReadOnly">
</Holding>
3.2.3 Holdings for Existing insurance (not being replaced)
For existing insurance, that is not being replaced, converted or exchanged, there is no
relation set up between the existing and applied for policies. To represent existing
policies, create a Holding object for the existing insurance, create a Relation object
relating the proposed insured to this Holding as however, you shall define relationships
between Insureds, Owners and Beneficiaries, as appropriate.
3.2.4 Holdings for Replaced, Exchanged, or Converted Policies / Existing Policies
Replacement is defined as all transfers of value between contracts except for Sec. 1035
exchanges. To represent replacement policies, create additional Holding objects for each
policy that is to be replaced. Create Relation objects to relate each replacement Holding
object to the same Party that represents the proposed insured with a RelationRoleCode
of „32‟ (insured) . An additional Relation object is needed to define the relationship
between the two Holdings with a RelationRoleCode of ReplacedBy (64). The originating
object is the Holding for the policy applied for.
For exchanges (exchanges are defined as tax qualified transfers between contracts, such
as Sec. 1035), internal or external, follow the same logic for Replacements, with a
RelationRoleCode (67), Exchanged.
For conversions, follow the same logic as Replacements, with a RelationRoleCode,
ConvertedTo (167).
11
3.2.5 Holdings for pending or planned insurance (alternate or additional)
If may be necessary to represent other insurance that is pending at the time of submission. Most
applications request information about pending insurance. The information is mapped as follows:
When there is any pending or planned insurance on the primary insured, an additional
Holding may be created for information only. To represent the additional “applied for”
insurance, create a Holding object with a HoldingStatus of tc = 3, Proposed, and a
PolicyStatus of tc = 8, Pending. The PrimaryObjectId and DataRep is needed to
distinguish additional “applied for” policies from the policy that is being applied for in this
message.
On
the
primary
proposed
Holding,
ApplicationInfo.AlternateInd
and
ApplicationInfo.AdditionalInd are used when more than one application is submitted to
the same carrier at the same time and are intended to be underwritten together. If either
of these indicators are set to „true‟, this indicates that there is another, separate
application(s) that must be considered when reviewing this one.
If a pending application has been submitted to a different carrier or the same carrier at an earlier time, the
Risk.HHFamilyInsurance object is used to capture some information about that pending application.
3.3 Parties
3.3.1 General Party Modeling Guidelines
For modeling Parties in the New Business transaction, follow these general guidelines:
Party represents the current state of the person or organization.
Must have a Person or Organization Object
FullName – May be left blank if you have the parsed names. Provide if you don‟t have the
parsed names or it‟s an Organization name.
3.3.2 Party for Primary Proposed Insured
Every new business transaction for life insurance will identify a primary proposed insured. For life
insurance, a primary proposed insured is always an individual person represented by a Party.
Therefore, the Party must include the Person Object. To relate the primary proposed insured to the entire
Holding, use a Relation Object with a RelationRoleCode type code of 32 (Insured).
3.3.3 Identification of the Carrier for the Proposed Policy
Every new business transaction will identify a carrier for the proposed policy. There is more than one way
to represent the carrier on the proposed Policy, to be mutually agreed trading partners during
implementation.
If using a unique identifier for the CarrierCode, then only Holding.Policy.CarrierCode is
required. In the United States, the best practice is to use the NAIC code for the
CarrierCode.
The carrier is alternately represented with a Party Object that has specific carrier
information modeled in its child Carrier Object. This Carrier Party is referenced using the
Policy.CarrierPartyID attribute. Note that this attribute alone is sufficient to represent the
relationship between the Holding and the Carrier. The RelationRoleCode of carrier
(tc=87) cannot be used in this situation because it represents a party-to-party relationship
rather than a party-to-holding relationship.
12
3.3.4 All Other Parties
For modeling other parties and roles on the new business message, see Section 4.16 of the ACORD
Help File. These instructions will give you direction on how to use the LifeParticipant vs. the Relation
Object when modeling roles such as beneficiaries, owners and agents.
3.4 FinancialActivity and Arrangement
Initial Premium
The FinancialActivity object is used to capture the source(s) and amount(s) of funding for any
initial payment amount (CWA, lump sum payment, 1035). Additionally, an initial premium
(tc=19) Arrangement Object would be used to define how initial payments are allocated for a
variable product.
Inforce Premium
The Arrangement object is used for ongoing premium.
This guide previously recommended the use of FinancialActivity to specify ongoing premium. However
the guide was updated to recommend that the best practice for modeling ongoing premium is to use
the Arrangement object. Due to the reversal of that decision, ACORD will continue to certify
implementations that use FinancialActivity for ongoing premium but recommends that the Arrangement
object be used as a best practice. Please refer to the Arrangement object for modeling details.
3.5 Clarification for States/Addresses/Countries
There are a number of different approaches used to represent geographical location. Some may be
interchangeable and some are not. Care should be taken to use the appropriate property.
Situations which require a specific value for the geographic location must use a property that is based on
either one of the following:
1. OLI_LU_NATION
This table provides an extensive list of countries. It includes values for both old and new country
names, and for nations that no longer exist. This is the table that must be used when the
information need is to represent a country.
2. OLI_LU_STATE
This table provides a list of the geographical sub-divisions of a number of nations; however, all
nations are not represented. Those included are Australia, Canada, Japan, Mexico, South Africa,
the various countries that comprise the United Kingdom, and the United States. This table should
only be used when the information need is to represent a geographical sub-division, not a
country. Do not use the sublist table and the state table to indicate a country.
Geographical locations within the United Kingdom need to be handled differently.
• Most members are not considered sovereign nations and therefore do not appear in
OLI_LU_NATION.
• Those that are listed are Ireland (TC=353), Isle of Man (TC=1035), and Jersey (TC=1034).
• For all others, the appropriate choice would be the United Kingdom (TC=44).
• For any geographical sub-division of members of the United Kingdom, OLI_LU_STATE
should be used, even though in doing so you may lose the intermediate designation for
places like Scotland, Wales, etc. While the sublist will include reference to them, the TC
values will reflect one of their respective geographical sub-divisions, such as shire or city.
13
The following documents which properties use which of these tables. The two tables are not mutually
exclusive: an XML message may require the use of both a nation and its corresponding sub-divisions to
represent a specific geographical location.
OLI_LU_NATION
AddressCountryTC
ApplicationCountry
ApptCountry
BirthCountry
Citizenship
ConvictionCountry
DeathCountry
DriversLicenseCountry
IssueNation
Nation
PhoneCountryTC
ResidenceNationAtIssue
SignatureCountry
TaxNation
TravelCountry
ViolationCountry
OLI_LU_STATE
AddressStateTC
ApplicationJurisdiction
ApptState
ApplicationSignedState
BirthJurisdictionTC
ConvictionJurisdictionTC
DeathJurisdictionTC
DriversLicenseState
Jurisdiction
Jurisdiction
ResidenceJurisdictionAtIssue
SignatureState
TaxJurisdiction
ViolationJurisdiction
ResidenceState
MuniStateofIssuance
There are also situations that simply require a free-form character string to represent geographical
location. Among the properties used for this purpose are AddressCountry and AddressState.
14
4
LIFE ELECTRONIC APPLICATION SUBMISSION HIERARCHY
The general structure and hierarchy of the Life Electronic Application Submission object elements is as
follows:
<OLifE>
<SourceInfo>
!__Holding for Proposed Policy
<Holding>
<Policy>
<Life>
<Coverage>
<CovOption>
<LifeParticipant>
<SubstandardRating>
<AssocParticipantObjectInfo>
<LifeUSA>
<ApplicationInfo>
<SignatureInfo>
<IdentityVerification>
<Identification>
<VerifierParticipant>
<RequirementInfo>
<StatusEvent>
<Attachment>
FinancialActivity>
<Payment>
<Attachment>
<Investment>
<SubAccount>
<Intent>
<Arrangement>
<ArrSource>
<ArrDestination>
<Attachment>
<Authorization>
!__Holding for Bank Account
<Holding>
<Banking>
<PriorName>
!__Holding for existing, replaced, or exchanged policy
<Holding>
<Policy>
<Life>
15
<LifeUSA>
<Annuity>
<DisabilityHealth>
<Party>
<Person>
<Height2>
<Weight2>
<Organization>
<OrganizationFinancialData>
<Address>
<Phone>
<Carrier>
<Producer>
<CarrierAppointment>
<EMailAddress>
<Risk>
<CriminalConviction>
<SubstanceUsage>
<MedicalCondition>
<MedicalTreatment>
<MedicalPrevention>
<MedicalExam>
<PrescriptionDrug>
<LifeStyleActivity>
<ForeignTravel>
<Violation>
<FamilyIllness>
<HHFamilyInsurance>
<Bankruptcy>
<WeightHistory>
<Employment>
<Relation>
<FormInstance>
<FormResponse>
16
5
DETAILED ELEMENT DESCRIPTIONS & TYPE CODES DEFINITIONS
5.1 Identifying Objects using IDs, Codes and Keys
As you look at the various objects within the ACORD Life Model you will notice a need to be able to
uniquely identify objects, in the context of a message like New Business Submission. There are very
three specific ways of identifying each individual object within the ACORD Life Model and each has its
own specific use. These three are Object ID‟s, Keys SysKeys and codes.
IDs – On every repeating object in the model there is always a special attribute called „ID.‟ The purpose
of this attribute is to uniquely identify Objects within the context of the message. These Object attributes
are created at the source of the transaction and provide a mechanism within XML to associate one object
with another. The only purpose for this reference is to link Objects just within the context of this single
message. These links or associations do NOT persist (or remain) beyond the life of the message. An
example is the „ID‟ on the Party object and the associated reference to it from a Policy using the
„CarrierPartyID‟ attribute. In this example the „CarrierPartyID‟ on Policy is a pointer or reference to the
“Party” that represents the Insurance Carrier to whom the submission is being sent. The important point to
remember is that this link does NOT persist and it is therefore the responsibility of the receiver to make
whatever association they need to and to create their own internal, private links between these objects
however they store the information in their system.
Since IDs must be unique throughout the transaction, the common convention is to generate an ID based
upon the Object name combined with a sequential counter. For example, Party_7 or Holding_2.
For further information please refer to section 4.3 (How to handle Object IDs) of the ACORD Help File.
Codes – On repeating objects that need to have a more permanent reference to them we use „Code‟
fields, typically CarrierCode and TrackingID (A code field is not always named with the term “code” in the
name). The combination of CarrierCode + TrackingID does persist across transactions. Since these
codes are assumed to be unique we can use them to associate objects with one another on a more
permanent basis.
Keys/SysKeys – A third method of identifying objects is through the use of special properties we call
“Keys”. All repeating objects have these properties available to them. They have no meaning within the
context of the message itself, nor are they ever used to create references between objects. They also
have no meaning to the receiver of the object. What they are for are handy tags that the sender of the
message can use to uniquely identify the object. One common use is where the Key field on an object
may be a database key that the sender used to store this object in their database. It has no inherent
meaning to the receiver, and would not be used by them. The receiver may store and pass back the Key
when communicating about this object to the original sender. Similarly, for anyone who needs or wants to,
the SysKey properties allow them to store their private key values for future reference.
There is only one Key, but as many SysKeys as necessary; functionally they do the same thing. SysKey
is used when multiple Key values apply to an object. SysKey specifies a secondary reference.
17
Note that in all three examples we refer to repeating objects. There are a few objects in the model which
do not repeat.
These by definition can only exist once, and because of that they do not need their own special
identifiers. They inherit the identifiers (id‟s, Codes, Keys) from their parent object. So to refer to a child
non-repeating object you reference its parent.
For example, New Business submissions may involve several partners. A General Agent may send the
information to a data aggregator, who in turn forwards the message to a carrier. Each of the partners may
have a unique code to identify the application. The TrackingID can be used to uniquely identify the
application for only one of the partners. The HoldingSysKey can be used to carry the unique identifier for
the others. The VendorCode attribute allows the identification of owner of that unique id. The ability to
provide the unique identifier for each partner is helpful when testing or with problem production cases.
<HoldingSysKey VendorCode="0101">12345678</HoldingSysKey>
<HoldingSysKey VendorCode="0121">22345678</HoldingSysKey>
<Policy>
<ApplicationInfo>
<TrackingID>123-28-4448720</TrackingID>
</ApplicationInfo>
</Policy>
</Holding>
Please note that the required tags listed throughout the Detailed Element Description refer to a formal
New Business Submission.
18
XML Element Name
Type
Usage
Description
5.2 <Address> Object
TXLife/TXLifeRequest/OLifE/Party/Address
The Address object includes addresses pertaining to the Party or Group. The collection of addresses
represents the various addresses a party or group may have.
For new business transactions, addresses are applicable for the insured, owner, payor and the employer
parties.
<Address>
<AddressTypeCode tc="1">Residence</AddressTypeCode>
<Line1>1328 East Turkey View Drive</Line1>
<City>Ogden</City>
<AddressStateTC tc="52">UT</AddressStateTC>
<Zip>84041</Zip>
</Address>
<Address id>
ID
Optional
<AddressTypeCode>
LookUp Table String=
'Address Type'
TypeCode Required
OLI LU
ADTYPE
See the description at the beginning of
this chapter for usage & meaning
Identifying Objects using IDs, Codes
and Keys
Type of address
Type Code Translation
1 = Residence
2 = Business
3 = Vacation
11 = Temporary
12 = Previous
15 = Individual Work Location
17 = Mailing
19 = Overnight Mail Address
20 = Policy Mailing Address
26 = Billing Mailing
<AttentionLine>
String
Optional
<Line1>
<Line2>
<Line3>
<Line4>
<Line5>
<City>
String
String
String
String
String
String
Required
Optional
Optional
Optional
Optional
Conditional
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.
First line of the address.
Second line of the address.
Third line of the address.
Fourth line of the address.
Fifth line of the address.
City of the address. The city may be
derived from the zip code.
19
XML Element Name
Type
Usage
<CityCode>
String
Optional
<AddressStateTC>
'State'
TypeCode Conditional
OLI LU
STATE
Sublist
=„United
<AddressCountryTC>
String
Conditional
TypeCode Optional
OLI LU
NATION
<PrefAddr>
<YearsAtAddress>
Boolean
0 = False
1 = True
Real
Required if the zip code is not provided.
A numeric representation or
alphanumeric abbreviation of the city in
question. This code is assigned by the
governing jurisdiction of which the city is
a member. For example, in the US,
CityCode would be assigned by the
State.
State/Province of residence for the
party. The state may be derived from
the zip code.
Required if the zip code is not provided.
States‟
<Zip>
Description
Please see the ACORD Help File for a
complete list of type codes.
US zip codes should have at least 5
digits. When zip + 4 is available the
total number of digits should be 9. For
example, the code 92660-6397 should
be sent as 922606937. Zeroes should
never be sent for the “+4” portion of the
zip code.
Required if any of the primary address
information that can be used to derive a
zip code is missing (Line1, City and
AddressStateTC) is missing.
Country of residence for the party.
1 = United States of America
Optional
Optional
Preferred address indicator. Only one
preferred address per role should be
specified.
0 = FALSE meaning address
information currently being provided is
NOT preferred
1 = TRUE meaning address information
currently being provided IS preferred
Number of years lived or living at this
20
XML Element Name
<CountyName>
<CountyCode>
Type
String
String
Usage
Optional
Optional
Description
address
County
A numeric representation or
alphanumeric abbreviation of the county
in question. This code is assigned by
the governing jurisdiction of which the
county is a member. For example, in the
US, CountyCode would be assigned by
the State.
21
XML Element Name
Type
Usage
Description
5.3 <ApplicationInfo> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/ApplicationInfo
The Application Info object provides information pertaining to the submission process.
<ApplicationInfo>
<TrackingID>ABCC0000002036</TrackingID>
<ApplicationType tc="1">New Application</ApplicationType>
<ApplicationJurisdiction tc="5">Arkansas</ApplicationJurisdiction>
<ApplicationCountry tc="1">United States</ApplicationCountry>
<SignedDate>2008-04-14</SignedDate>
<CWAAmt>200</CWAAmt>
<ClientMaterialsInd tc="1">True</ClientMaterialsInd>
<HIVConsentAuthInd tc="1">True</HIVConsentAuthInd>
<ReplacementInd tc="0">False</ReplacementInd>
<SalesMaterialInd tc="1">True</SalesMaterialInd>
<AgentRelatedInd tc="0">False</AgentRelatedInd>
<IdentityVerification VerifiedPartyID="Primary_Insured_Party_1">
<Identification>
<IdentificationNum>F12345</IdentificationNum>
<IdentityVerificationType tc="1">Driver's License</IdentityVerificationType>
<IdentificationExpDate>2010-02-02</IdentificationExpDate>
<Jurisdiction tc="5">AR</Jurisdiction>
<IssuingAgency>AR</IssuingAgency>
</Identification>
<VerifierParticipant VerifierPartyID="Agent_Party_1">
<VerifierRoleCode tc="3">Agent</VerifierRoleCode>
</VerifierParticipant>
</IdentityVerification>
</ApplicationInfo>
<TrackingID>
String
Required
<TrackingIDVendorCode
String
Optional
<HOAppFormNumber>
<ApplicationType>
String
TypeCode
Optional
Required
OLI LU
APPTYPE
Unique ID of application used for
tracking purposes of a holding until a
policy number is assigned. Created by
application initiator. If available, the
policy number could be used for the
tracking ID.
An ACORD assigned unique vendor
code that represents the creator of the
TrackingID, which could be a vendor or
a carrier.
Number assigned to the application form
1 = New
8 = For Quote Purposes Only
22
XML Element Name
<ApplicationJurisdiction>
'State'
Type
TypeCode
Usage
Required
OLI LU STATE
Sublist =
United States
<ApplicationCounty>
<FormalAppInd>
<SignedDate>
String
Boolean
0 = False
1 = True
Date
Optional
Required
Conditional
Description
This establishes the legal jurisdiction of
the application which is usually where
the application was signed. If application
was signed in a different state other
than the jurisdiction refer to the
ApplicationSignedState property.
County where Application was taken.
Many companies require as Florida
insurance law applies at the county
level.
Defines if this application is a formal or
not.
On ApplicationInfo, if multiple
applicants, then use the date the
'primary' applicant or annuitant (the
"primary person") signed the application
for SignedDate here and then record
remaining additional signature dates in
ApplicationInfo.SignatureInfo.Signature
Date.
If additional information is needed about
the primary person's signature such as
the city where the application was
signed, then use the SignatureInfo
object to capture the additional details.
The ApplicationInfo.SignedDate and the
SignatureInfo.SignatureDate must both
be valued with the same date when the
SignatureRoleCode corresponds to the
role represented by
ApplicationInfo.SignedDate.
Required if FormalAppInd is TRUE
If SignatureInfo.SignatureDate is
present then ApplicationInfo.SignedDate
is required if it pertains to the primary
applicant/insured.
<SubmissionType>
'App Submission Type'
TypeCode
OLI LU
APPSUBMITT
Optional
Indicates how the form was sent in or
where it can be obtained. On
application info, this relates to how
23
XML Element Name
Type
Usage
YPE
Description
forms were submitted to the carrier.
Refer to the help file.
<AgentCWADate>
<RequestedPolDate>
Date
Date
Optional
Optional
<CWAAmt>
Currency
Optional
<TotalCWAAmt>
Currency
Optional
<CaseOrgCode>
String
Optional
<PrefLanguage>
TypeCode
Optional
OLI_LU_CLIE
NTLANGUAGE
S
<ClientMaterialsInd>
Boolean
0 = False
1 = True
Optional
<ConsumerInfoInd>
Boolean
0 = False
1 = True
Optional
<DisclosureInd>
Boolean
0 = False
1 = True
Optional
Date agent received initial payment.
Requested Policy Effective Date. This
date is different than the “issue date”
and is specifically requested by the
proposed insured. Refer to the help file
for more detail.
Amount of payment that accompanied
application.
Total payment received while
application is pending
Internal organization code used to
identify case location. Can be used to
route the transaction.
On ApplicationInfo, this is the language
of the application itself when it was
printed or displayed. It is generally used
in situations where the carrier offers an
application in multiple languages and
the applicant is allowed to choose the
one they prefer to use. One may
generally expect this to be the same as
Client.PrefLanguage; but this is not
always the case. For example, a client
may have a preferred language of
French, but use English on an
application for a Policy that was offered
through their company.
A Boolean that indicates whether or not
the Consumer Privacy Notice and other
materials, such as the life insurance
buyer's guide have been given to the
potential insured.
A Boolean that indicates whether the
Consumer Information Statement has
been filed with the selling Broker/Dealer
for this Activity.
A Boolean that indicates the Carrier's
prospectus and/or disclosure was used
in the sale.
24
XML Element Name
Type
Usage
<HIVConsentAuthInd>
Boolean
0 = False
1 = True
Optional
<HIVTestedInd>
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Optional
<ReplacementInd>
<SalesMaterialInd>
<SuitabiltyPerformedInd>
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Optional
Optional
Optional
Description
the proposed insured was given a copy
of the HIV Informed Consent
Authorization.
Indicates if person has been tested for
HIV
This is the agent‟s response to a
replacement question, usually from the
agent‟s report. The client‟s response to
a comparable question is reflected
under Risk.
The value in this tag should not be
relied upon to determine if there is
replacement data in this message
stream.
the Carrier's approved sales materials
were used for the sale.
Indicator of whether suitability questions
have been asked and answered.
Use SuitabilityInd to specify the results
of the suitability review.
<SuitabilityInd>
<FundingDisclosureInd>
Boolean
0 = False
1 = True
Optional
Boolean
0 = False
1 = True
Optional
<ProducerReplacementDisclosureI Boolean
nd>
0 = False
1 = True
Optional
The characteristics of the application,
(for example face amount) have been
deemed suitable for the applicant(s).
On ApplicationInfo, a value of TRUE for
this property indicates that the coverage
has been deemed suitable for the
applicant. Use SuitabiltyPerformedInd to
specify that the suitability questions
have been asked and answered.
Indicates that a policy being applied for
will be financed by existing insurance.
On ApplicationInfo the AGENT is
indicating the Client is using funds from
an existing contract. On Risk, the
CLIENT is indicating replacement
funding.
Producer verifies Replacement
Disclosure Made. Indicator that the
Producer has discussed the advantages
/ disadvantages of Replacement with
the applicant.
25
XML Element Name
Type
Usage
Description
<ProducerReplacementAppropriat Boolean
enessInd>
0 = False
1 = True
<AgentRelatedInd>
Boolean
0 = False
1 = True
Optional
<IllustrationConfirmationNum>
String
Optional
Used to insure that the illustration was
run and can be confirmed. The purpose
of "Illustration Confirmation Number" is
to correlation a sales illustration report
with the New Business Application.
<IllustrationProvidedInd>
Boolean
0 = False
1 = True
Optional
TRUE indicates the producer attests
that an illustration was provided to the
applicant.
<BackDateType>
TypeCode
Optional
Optional
OLI LU
BACKDATE
<QuotedPremiumAmt>
Currency
Optional
<HOAppFormType>
TypeCode
Optional
OLI LU
ATTACHMENT
Indicator that the Producer has
determined whether replacement
financing is appropriate for the applicant
Indicator if the agent/producer is related
to the insured. If the specific relationship
between parties is gathered/known, it
should be expressed via the Relation
object.
Use IllustrationConfirmationNum to
provide the illustration confirmation
number. When used on ApplicationInfo,
IllustrationProvidedInd reflects whether
the agent attests to providing an
illustration.
This property is a request from the
applicant for the carrier to back date the
policy effective date by calculating the
policy effective date using their
procedures & rules (and likely date of
birth, etc.); the carrier has not
necessarily agreed to do so. This
property is mutually exclusive to
RequestedPolDate. Used when carriers
allow clients to backdate their policy
effective date if the application is dated
within 6 months (generally) of that date.
If the quoted premium amount provided
to applicant is different than the actual
premium amount (and known) then
specify actual premium amount in
PaymentAmt and specify the quoted
premium in QuotedPremiumAmt
Refers to the type of application/form
that the data represents. The most
frequently used for a 103 new business
26
XML Element Name
Type
Usage
TYPE
Description
transaction are expected to be:
252 = Preliminary Application (Short)
253 =Carrier-Specific Application (Full
application packet)
<ApplicationCountyTC>
TypeCode
Optional
OLI LU
COUNTY
<CreditCardOffered>
<CashOnDeliveryInd>
<ApplicationSignedState>
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
TypeCode
Optional
Optional
Optional
OLI LU STATE
<SignatureInfo>
Object
Optional
SignatureInfo
SignatureInfo
SignatureInfo
Required in Florida. The county of the
state in which the application was
signed.
Document whether credit card was
offered as an option for the payment of
premium.
Indicates whether or not the payment for
the policy is Cash On Delivery. Cash on
delivery means the applicant expects to
pay the entire initial premium when the
policy is delivered.
Use of this indicator has several
implications:
1. No partial CWA premium payments
will be made prior to delivery
2. When the CashOnDeliveryInd is True,
CWAAmt must be zero or not present in
the message.
Physical location (state) where the
application was signed.
ApplicationSignedState is only used
when the application is signed in a
different state other than the legal
jurisdiction.
Needed if information on more than one
signature is needed or if more
information is needed on the primary
signature, such as location
27
XML Element Name
<IdentityVerification>
Type
Usage
Object
Optional
@VerifiedPartyID
IDREF
Optional
<Identification>
Object
Optional
<IdentificationNum> String
Optional
<IdentifyVerificationT TypeCode
OLI LU
ype>
Required
IDVERIFICATI
ON
<IdentificationExpDat Date
e>
Optional
<Jurisdiction>
Optional
TypeCode
OLI LU STATE
Description
Please reference the SignatureInfo
Object Section.
<SignatureInfo> Object
This object is used to document that a
person's identity has been verified. It
includes the information relating to the
type of identification used in the
verification, audit information relating to
the verification (date, verifying party,
etc.). It does NOT imply that the
information on the identification has
been verified.
and Keys
This object describes a particular form
of identification presented by an
individual.
Contain the actual number or string from
the identification presented as part of an
identity verification.
Type code property that indicates the
type of identification presented for
verification of a person's identity.
Specifies the expiration date of a form of
identification as it appears on that
artifact.
Use the state property when the form of
identification relates to a state (e.g.
driver's license).
Sublist =
United States
<Nation>
TypeCode
Optional
OLI LU
NATION
<IssuingAgency>
String
Optional
Use the nation property when the form
of identification relates to a nation (e.g.
passport, birth certificate).
This is the agency within the specified
Nation or Jurisdiction that issued the
identification that is being used for
verification. E.g.. DMV.
28
XML Element Name
<VerifierParticipant>
Type
Usage
Object
Optional
@VerifierPartyID
IDREF
Required
<VerifierRoleCode>
TypeCode
Required
OLI LU
VERIFIERROL
E
Description
This object describes the party or
parties who verified the identity of a
person.
and Keys
1 = Paramedical Examiner
2 = MD Examiner
3 = Agent
4 = Identity Verification Vendor
29
XML Element Name
Type
Usage
Description
5.4 <Arrangement> Object
TXLife/TXLifeRequest/OLifE/Holding/Arrangement
Arrangement Object contains information about a planned financial activity that can be applied to either
investments or collection of premiums. The most common Arrangement for life insurance applications will
be for Subsequent (inforce) Premiums (tc=39). For cash value products other common Arrangements are:
Asset Rebalancing (tc=3), Asset Allocation (tc=21), Systematic Withdrawal (tc=38) and Dollar Cost
Averaging (tc=2).
The FinancialActivity object is used to capture the source(s) and amount(s) of funding for any initial
payment amount (CWA, lump sum payment, 1035). Additionally, an Initial Premium (tc=19) Arrangement
Object would be used to define how initial payments are allocated for a variable product.
For more information please refer to: FinancialActivity and Arrangement
Subsequent Premium, AKA Inforce Premium Example:
<Arrangement id="A9f95740c-94c1-491e-b7b3-e7f9a06fce20">
<ArrMode tc="4">Monthly</ArrMode>
<ArrType tc="39">Subsequent premium, AKA inforce premium</ArrType>
<DayOfMonth>15</DayOfMonth>
<ModalAmt>750.00</ModalAmt>
<PaymentForm tc="7">Electronic Funds Transfer</PaymentForm>
<PaymentMethod tc="7">Electronic Funds Transfer</PaymentMethod>
<ArrSource BankingInfoID="Bank_Holding_1"/>
</Arrangement>
Initial Premium Example:
<Arrangement id="Arrangement_Initial_Allocation">
<ProductCode>IA</ProductCode>
<ArrType tc="19">Initial Premium</ArrType>
<PlanName>Initial Premium</PlanName>
<DestTransferAmtType tc="3">Percentage</DestTransferAmtType>
<ArrDestination id="Arrangement_IA_Destination" SubAcctID="Proposed_Holding_SubAccount_3">
<TransferPct>100</TransferPct>
</ArrDestination>
</Arrangement>
Standing Allocation Example:
<Arrangement id="Arrangement_Standing_Allocations">
<ProductCode>SA</ProductCode>
<ArrType tc="37">Standing Allocations</ArrType>
<PlanName>Monthly Premium</PlanName>
<DestTransferAmtType tc="3">Percent</DestTransferAmtType>
<ArrSource id="Arrangement_SA_Source" BankingInfoID="Bank_Holding_1"/>
<ArrDestination id="Arrangement_SA_Destination_1" SubAcctID="Proposed_Holding_SubAccount_1">
30
XML Element Name
Type
Usage
Description
</ArrDestination>
<ArrDestination id="Arrangement_SA_Destination_2" SubAcctID="Proposed_Holding_SubAccount_2">
</ArrDestination>
</Arrangement>
Asset Rebalancing Example:
<Arrangement id="Arrangement_Asset_Rebalancing">
<ProductCode>AR</ProductCode>
<ArrMode tc="1">Annually</ArrMode>
<ArrType tc="3">Asset Rebalancing</ArrType>
<ArrSubType tc="17">Standard Asset Rebalancing</ArrSubType>
<StartDate>2009-01-01</StartDate>
<PlanName>Rebalancing Program</PlanName>
<ArrDestination id="Arrangement_Asset_Rebal_Dest_1" SubAcctID="Proposed_Holding_SubAccount_1">
</ArrDestination>
</ArrDestination>
</ArrDestination>
</Arrangement>
Dollar Cost Averaging Example:
< Arrangement id="Arrangement_Dollar_Cost_Averaging">
<ProductCode>DCA</ProductCode>
<ArrType tc="2">Dollar Cost Averaging</ArrType>
<EndDate>2020-12-31</EndDate>
<NumOfModalOccurrences>60</NumOfModalOccurrences>
<ModalAmt>500</ModalAmt>
<SourceTransferAmtType tc="2">Amounts</SourceTransferAmtType>
<DestTransferAmtType tc="2">Amounts</DestTransferAmtType>
<ArrSource SubAcctID="Proposed_Holding_1_SubAccount_4">
<TransferAmt>200</TransferAmt>
</ArrSource>
<ArrSource SubAcctID="Proposed_Holding_1_SubAccount_3">
</ArrSource>
<ArrDestination SubAcctID="Proposed_Holding_1_SubAccount_1">
</ArrDestination>
</ArrDestination>
31
XML Element Name
Type
Usage
Description
</ArrDestination>
</ArrDestination>
</Arrangement>
Integer
<Arrangement id>
Optional
<ProductCode>
String
Optional
<ArrMode>
TypeCode
Conditional
OLI_LU_PAYM
ODE
and Keys
Identifies the ArrangementProduct from
the carrier. This is the carrier identifier
for a particular version of arrangement
rules for this product.
This denotes the frequency of future
financial transactions associated with
the arrangement.
Required when the ArrType='39'.
<ArrType>
TypeCode
Required
OLI_LU_ARRT
YPE
Defines the type of investment options
selected.
2 = Dollar Cost Averaging
3 = Asset Rebalancing
19 = Initial Premium
Note: This is used for the allocation of
initial premium
21 = Asset Allocation
37 = Standing Allocations
38 = Systematic Withdrawal
39 = Subsequent Premium, AKA Inforce
Premium
52 = Charge Deduction
If fund and fund percentage for Initial
and Standing Allocations are the same,
pass both.
<StartDate>
<DayOfMonth>
Date
Integer
Optional
Optional
StartDate is inclusive
Stated day of month for processing this
arrangement.
32
XML Element Name
Type
Usage
<NumOfModalOccurrences>
Integer
Optional
<ModalAmt>
Currency
Conditional
Description
Number of occurrences of this
arrangement.
The amount that applies to each modal
occurrence.
When the Arrangement object is used
for Subsequent (inforce) Premiums
(tc=39), ModalAmt represents the
current modal premium for inforce
payment amount. It may also be known
as billed premium amount. ModalAmt is
to be used in place of
Policy.PaymentAmt to represent inforce
premium.
<PaymentMethod>
TypeCode
Optional
OLI_LU_PAYM
ETHOD
<PlanName>
<SourceTransAmtType>
<DesTransAmtType>
String
Required when the ArrType='39'.
Payment Method
PaymentMethod under Arrangement
can only be used when the start date is
in the future.
Optional
Full name of plan. This is the complete,
official, and/or legal name used for this
policy/coverage/option.
OLI_LU_TRNS
FRAMTTYPE
If the PPfL is used on a life policy, the
source of the value for PlanName
should be the
ArrangementOptProduct.Name.
Source transfer amount type
To be used when the source transfer
amount type is implicit.
1 = Units
2 = Amounts
3 = Percentage
TypeCode
The combination of transfer amount
sources and destinations allowed for
this arrangement.
TypeCode
OLI_LU_TRNS
FRAMTTYPE
Optional
Optional
33
XML Element Name
Type
Usage
Description
1 = Units
2 = Amounts
3 = Percentage
<FeatureName>
<ArrSource>
String
Object
Optional
Optional
@id
ID
Optional
@SubAcctID
IDREF
Optional
@PaymentPartyID
IDREF
Optional
@BankingInfoID
IDREF
Optional
<TransferAmt>
Currency
Conditional
Feature Name
If the PPfL is used on a life policy, the
source of the value for FeatureName
should be the
ArrangementProduct.Name.
Within an Arrangement, this aggregate
contains the collection of subaccounts
which are the SOURCE of monies
funding this arrangement.
Use the @SubAcctID to reference the
actual details of the SubAccount, this
aggregate simply contains the details of
the contract funding arrangement.
and Keys
When on Arrangement, SubAccount ID
refers to the SubAcct that the money is
coming from.
Payment Party ID
The ID of the payor party
Pointer/Foreign Key to a Holding
containing a Banking Object with the
Banking Information.
Provides details of the bank or financial
institution account that is the source of
the funds for this Arrangement.
Amount of transfer, when
TransferAmtType is 'amount'.
This is the portion of the
Arrangement.ModalAmt that will be
drawn from this particular source.
If Arrangement.SourceTransAmtType is
34
XML Element Name
<TransferUnits>
<TransferPct>
<ArrDestination>
Type
Real
Percent
Object
Usage
Conditional
Conditional
Optional
@id
ID
Optional
@SubAcctID
IDREF
Optional
@BankingInfoID
IDREF
Optional
<TransferAmt>
Currency
Conditional
Description
(Amounts) tc=2, this field is required.
Otherwise this propery is out of scope.
Number of units to be transferred, when
TransferAmtType is units.
(Units) tc=1, this field is required.
Percentage to be transferred, when
TransferAmtType is percentage.
(Percentage) tc=3, this field is required.
Within an Arrangement, this aggregate
contains the collection of destinations
which are the DESTINATION of monies
funding this arrangement. Depending on
Arrangement one or more
ArrDestination's may be specified.
This is where you would indicate the
initial payment and standing allocations.
and Keys
When on Holding this is the SubAccount
ID that the money is going to.
Provides details of the bank or financial
institution account that is the destination
for the funds for this Arrangement.
Amount of transfer, when
TransferAmtType is 'amount'.
This is the portion of the
Arrangement.ModalAmt that will be
transferred to this particular destination.
<TransferUnits>
Real
Conditional
If Arrangement.DestTransferAmtType is
(Amounts) tc=2, this field is required.
Number of units to be transferred, when
35
XML Element Name
Type
Usage
Description
TransferAmtType is units.
<TransferPct>
Percent
Conditional
(Units) tc=1, this field is required.
Percentage to be transferred, when
TransferAmtType is percentage.
(Percentage) tc=3, this field is required.
36
XML Element Name
Type
Usage
Description
5.5 <Attachment> Object for text
The Attachment Object can be used for three purposes, as indicated in the AttachmentBasicType
property:
To include a free-form comment
To include an image
To include a file
Each purpose is documented separately in this guide to distinguish between the specific properties needed
for each distinct purpose.
The Attachment Object, when used to include free-form comments, can be used on any object on the 103
for which the Attachment object is available.
For comments on the application as a whole, attach to the proposed Holding Object. For comments that
are directly associated with an Object, such as comments on a RequirementInfo or Bankruptcy, attach to
the appropriate RequirementInfo or Bankruptcy Object.
This contains a collection of attachments. Each attachment could contain any of the attachment Types
defined. Specifically, it will contain comments
New Business uses: free-form comments
<Attachment>
<AttachmentBasicType tc="1">text</AttachmentBasicType>
<AttachmentData>free form comment</AttachmentData>
<AttachmentType tc="12">Underwriting Note</AttachmentType>
<AttachmentLocation tc="1">Inline</AttachmentLocation>
</Attachment>
<Attachment id>
Integer
Optional
<AttachmentKey>
String
Optional
<DateCreated>
Date
Optional
<AttachmentBasicType
TypeCode
Required
OLI_LU_BASI
CATTACHMEN
TTYPE
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.
and Keys
Date on which the object was created.
Used for comments, notes, etc.
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.
37
XML Element Name
Type
Usage
<AttachmentSource>
String
Optional
<Description>
String
Optional
<AttachmentData>
TypeCode
Required
OLI_LU_VARI
ANT
<AttachmentType>
TypeCode
TypeCode
OLI_LU_ATTA
CHLOCATION
1 = Text
Can be used by the client application to
indicate the application that inputted the
attachment.
Description of the object.
Description/Comment.
The data in the attachment.
For text attachment types, the text goes
here.
Required
OLI_LU_ATTA
CHMENTTYPE
<AttachmentLocation>
Description
Type of attachment.
2 = Comment
3 = Letter
4 = E-Mail
12 = Underwriting Note
14 = General Note
15 = Exception Note
249 = Internal Comment
250 = Instructions/Reminders
325 = Examiner Note
326 = Teleinterview Note
Optional
Indicates how an attachment is stored,
such as inline or URL Reference.
1 = Inline
38
XML Element Name
Type
Usage
Description
5.6 <Attachment> Object for images
While Attachment Objects can be included on many Objects in the ACORD model, it is recommended that
Attachments for images be limited to two Objects in the New Business for Life transaction – Holding and
RequirementInfo. For example, a file containing the application form would be attached to the proposed
Holding or a file containing an MIB Authorization would be attached to the RequirementInfo.
<Attachment>
<AttachmentBasicType tc="2">Image </AttachmentBasicType>
<Description>APS</Description>
<AttachmentData>http://www.insuranceco.com/files/attachimage.tiff</AttachmentData>
<AttachmentType tc="163">Attending Physician Statement</AttachmentType>
<ImageType tc=”3”>TIFF</ImageType>
<AttachmentLocation tc=”2”>URL Reference</AttachmentLocation>
<Sequence>1</Sequence>
</Attachment>
<Attachment id>
Integer
Optional
<AttachmentKey>
String
Optional
<DateCreated>
<AttachmentBasicType>
Date
TypeCode
Optional
Required
OLI_LU_BASI
CATTACHMEN
TTYPE
<AttachmentSource>
String
Optional
<Description>
String
Optional
<AttachmentData>
TypeCode
Required
OLI_LU_VARI
ANT
and Keys
and Keys
2 = Image
attachment.
On Attachment, the value of
AttachmentData depends upon the
value of AttachmentLocation. Please
see the ACORD Help File for additional
information.
For images, URL Reference (tc=2) is
the most likely AttachmentData type.
39
XML Element Name
Type
Usage
Description
1 = Inline
2 = URL Reference
3 = Multi-Part Mime
<AttachmentType>
TypeCode
OLI_LU_BASI
CATTACHMEN
TTYPE
Optional
Required Usage Note: Need to have
AttachmentData because
AttachmentReference (associated with
tc=4) is not common practice. Please
see the ACORD Help Guide if you think
AttachmentReference may apply for
your scenario.
Type of attachment.
1 = Document
3 = Letter
5 = Form
6 = Pre-Candidate Illustration
10 = Original Application
13 = Wet signature image
98 = Conditional Receipt
100 = Limited Insurance Agreement
103 = Paramed Exam
104 = Signed Tele-Med
108 = Disclosure
109 = Transmittal
110 = Correspondence from GA
111 = Correspondence from agent
120 = PAC Authorization
121 = PAC Authorization/Voided Check
122 = Premium Check – Initial Premium
(COD)
123 = EFT Form
130-146 = various underwriting
questionnaires
147 = Trust Agreement
148 = Income Statement
149 = Financial Report – personal
150 = Financial Report – business
161 = Supplementary Application –
Child
163 = Attending Physician Statement
239 = Authorization
241 = Independent Medical Examiner
40
XML Element Name
Type
Usage
Description
Report
251 = Publicly Disclosable Information
252 = Preliminary Application
253 = Carrier-specific Application
<MimeTypeTC>
Type Code Optional
OLI LU
MIMETYPE
Describes the format of the Imaged file
despite the contents (forms, letters,
notes, etc.)
3 = image/jpeg
4 = image/gif
5 = image/G3fax
11 = image/tiff
17 = image/PDF
<TransferEncodingTypeTC>
Type Code Optional
OLI LU
ENCODETYPE
Type of Encoding. For example, tc=4 is
Base64.
<ImageType>
TypeCode
Optional
OLI_LU_IMAG
EFORMAT
Describes the format of the Imaged file
despite the contents (forms, letters,
notes, etc.) Allows the user to see what
type of Image format the attachment
was sent as so they know what open it
up as.
1 = JPEG
2 = GIF
3 = TIFF
4 = PDF
TypeCode
OLI_LU_ATTA
CHLOCATION
Required
Indicates if the attachment is stored as
inline or as a URL reference.
41
XML Element Name
Type
Usage
Description
1 = Inline data
2 = URL Reference
3 = Multi-Part MIME
4 = Attachment IDREF
<FileName>
String
Optional
<Sequence>
Integer
Optional
<OrginatingSourceType>
TypeCode
Optional
OLI LU
ORIGSOURCE
This is name of the file included in the
attachment aggregate.
This element is used for ordering and
sorting purposes. This is an integer field.
Sequencing should start with "1". Nodes
within the same object should not
duplicate a Sequence, and should be
consecutive.
Nature of scanned paper document
(such as original versus a copy).
1 = Original
<CreationTime>
Time
Optional
On Attachment, this is the time the
Attachment was created. One usage of
CreationTime is to capture the time the
Attachment may have been scanned for
storage in an imaging database.
42
XML Element Name
Type
Usage
Description
5.7 <Attachment> Object for file
While Attachment Objects can be included on many Objects in the ACORD model, it is recommended that
Attachments for file be limited to two Objects in the New Business for Life transaction – Holding and
RequirementInfo. For example, a file containing the application form would be attached to the proposed
Holding or a file containing an MIB Authorization would be attached to the RequirementInfo.
New Business uses: free-form comments as a file, document files
<Attachment>
<AttachmentBasicType tc="3">File</AttachmentBasicType>
<Description>APS</Description>
<AttachmentData tc=‟2‟>http://www.insuranceco.com/files/attachimage.doc</AttachmentData>
<AttachmentType tc="163">Attending Physician Statement</AttachmentType>
<AttachmentLocation tc=”2”>URL Reference</AttachmentLocation>
</Attachment>
<Attachment id>
Integer
Optional
<AttachmentKey>
String
Optional
<DateCreated>
<AttachmentBasicType>
Date
TypeCode
Optional
Required
OLI_LU_BASI
CATTACHMEN
TTYPE
and Keys
and Keys
3 = File
<AttachmentSource>
String
Optional
<Description>
String
Optional
<AttachmentData>
TypeCode
Required
OLI_LU_VARI
ANT
attachment.
On Attachment, the value of
AttachmentData depends upon the
value of AttachmentLocation. Please
see the ACORD Help File for additional
information.
43
XML Element Name
Type
Usage
Description
For files, Multi-Part Mime (tc=3) is the
most likely AttachmentData type.
1 = Inline
2 = URL Reference
3 = Multi-Part Mime
<AttachmentType>
TypeCode
OLI_LU_BASI
CATTACHMEN
TTYPE
Optional
Required Usage Note: Need to have
AttachmentData because
AttachmentReference (associated with
tc=4) is not common practice. Please
see the ACORD Help Guide if you think
AttachmentReference may apply for
your scenario.
Type of attachment.
1 = Document
3 = Letter
5 = Form
6 = Pre-Candidate Illustration
10 = Original Application
13 = Wet signature image
98 = Conditional Receipt
100 = Limited Insurance Agreement
103 = Paramed Exam
104 = Signed Tele-Med
108 = Disclosure
109 = Transmittal
110 = Correspondence from GA
111 = Correspondence from agent
120 = PAC Authorization
121 = PAC Authorization/Voided Check
122 = Premium Check – Initial Premium
(COD)
123 = EFT Form
130-146 = various underwriting
questionnaires
147 = Trust Agreement
148 = Income Statement
149 = Financial Report – personal
150 = Financial Report – business
44
XML Element Name
Type
Usage
Description
161 = Supplementary Application –
Child
163 = Attending Physician Statement
239 = Authorization
241 = Independent Medical Examiner
Report
251 = Publicly Disclosable Information
252 = Preliminary Application
253 = Carrier-specific Application
<MimeTypeTC>
Type Code Conditional
OLI LU
MIMETYPE
Describes the format of the file despite
the contents (forms, letters, notes, etc.)
2= text/richtext
6 = video/mpeg
7 = audio/basic
8 = application/postscript
10 = application/ODA
12 = multipart/mixed
Required if AttachmentData is typecode
3 (multi-part mime).
<TransferEncodingTypeTC>
Type Code Optional
OLI LU
ENCODETYPE
Type of Encoding. For example, tc=4 is
Base64.
TypeCode
OLI_LU_ATTA
CHLOCATION
Required
Indicates if the attachment is stored as
inline or as a URL reference.
1 = Inline data
2 = URL Reference
3 = Multi-Part MIME
4 = Attachment IDREF
45
XML Element Name
Type
Usage
<FileName>
String
Optional
<Sequence>
Integer
Optional
Description
This is name of the file included in the
attachment aggregate.
This element is used for ordering and
sorting purposes. This is an integer field.
Sequencing should start with "1". Nodes
within the same object should not
duplicate a Sequence, and should be
consecutive.
46
XML Element Name
Type
Usage
Description
5.8 <Authorization> Object for changing investment instructions
TXLife/TXLifeRequest/OLifE/Holding/Authorization
New business submission provides ability to pass instructions regarding authorization privileges granted by
the policy owner. For example, authorizes agent to perform telephone fund transfers, address changes or
could authorize annuitant to provide DCA instructions.
<Authorization>
<BusinessMethodCC>
<BusinessMethod tc = “4”>phone</BusinessMethod>
</BusinessMethodCC>
<AuthorizationTransaction>
<AuthorizationMappingCodeInd tc=”0”>Financial</AuthorizationMappingCodeInd>
<AdministrativeTransaction tc=”102”>Fund Transfer</AdministrativeTransaction>
</AuthorizationTransaction>
</Authorization>
<AuthorizationID>
ID
Optional
<AuthorizationKey>
PERSISTKE Optional
Y
<AuthorizationSysKey>
SYSKEY
Optional
<BusinessMethodCC>
<BusinessMethodCC>
Object
TypeCode
Required
Required
OLI_LU_APPS
UBITTYPE
and Keys
and Keys
and Keys
A collection of BusinessMethod
List/collection of ways transactions may
be initiated within the contract.
1 = Mail
3 = Fax
4 = Phone
10 = Voice Response Unit
12 = Internet/Electronic
13 = All methods permitted by the
Company
<AuthorizationTransaction>
Object
Optional
This object describes Financial and
Non-Financial transactions that may be
performed by authorized entities.
47
XML Element Name
Type
Usage
<AuthorizationMappingCodeI Boolean
nd>
0 = False
1 = True
Required
<AdministrativeTransaction> TypeCode
Required
OLI_LU_TRAN
S_TYPE_COD
E
Description
Identifies the transaction as being
Financial or Non-Financial.
True indicates Administrative
transaction. False indicates the activity
is a Financial Activity
Transactions that may be performed by
authorized entities.
102 = Fund Transfer
105 = Withdrawals
181 = Address Change
212 = Values Inquiry
48
XML Element Name
Type
Usage
Description
5.9 <Banking> Object
TXLife/TXLifeRequest/OLifE/Holding/Banking
This object contains the banking information associated with a Holding. This is primarily used to capture
detailed information for purposes such as paying premium.
<HoldingTypeCode tc="7">Banking</HoldingTypeCode>
<Banking id="Banking_2" AppliesToPartyID="Party_1">
<CreditDebitType tc=”1”>Credit</CreditDebitType>
<BankAcctType tc="3">Credit Card</BankAcctType>
<CreditCardType tc="2">Visa</CreditCardType>
<CreditCardExpDate>2009-09-01 </CreditCardExpDate>
<AccountNumber>4820999883</AccountNumber>
<AcctHolderName>Marion K Jones</AcctHolderName>
<BankName>Wells Fargo</BankName>
<PriorName>
<NameType tc="6">As appears on card</NameType>
<FullName>Marion K Smith</FullName>
</PriorName>
</Banking>
</Holding>
<Banking id>
ID
Required
<FinancialInstitutionPartyID>
IDREF
Optional
@AppliesToPartyID
IDREF
Optional
<Banking Key>
PERSISTKE Optional
Y
Default:
PERSIST_SES
SION
<BankingSysKey>
SYSKEY
Optional
and Keys
Reference ID to party object of Financial
Institution.
Party associated to the information
On Banking this attributes refers to the
Holder of the account. The primary
holder of the account (the one who
actually applied for the account) is
considered to be fully liable for all
charges on the account, including those
made by any authorized users. This is
needed to support credit card billing in
order to obtain the accountholder's
billing address.
and Keys
49
XML Element Name
<CreditDebitType>
Type
TypeCode
Usage
Conditional
OLI LU
ACCTDBCRTY
PE
Description
and Keys
Indicates if associated object is a Credit
or Debit type of object.
1 = Credit
2 =Debit
Required if BankAccountType
represents credit or debit.
<BankAcctType>
'Bank Account Type'
TypeCode
Required
OLI_LU_BANK
ACCTTYPE
In the case that the PaymentMethod is
'electronic funds transfer,' this is the
type of account associated with the
bank account.
1 = Savings
2 = Checking
3 = Credit Card
4 = Debit Card
<CreditCardType>
'Credit Card Type'
TypeCodeO Conditional
LI_LU_CREDC
ARDTYPE
This is required when a Credit Card is
used to pay some form of premium,
Default:
OLI_UNKNOW
N
<CreditCardExpDate>
Date
Type of credit card.
1= Discover
2 = Visa
3 = Master Card
4 = American Express
5 = Diner's Club
6 = Bank Card
Conditional
Credit Card expiration date.
50
XML Element Name
<AccountNumber>
<RoutingNumber>
Type
String
String
Usage
Conditional
Conditional
Description
This is required when a credit card is
used to pay some form of premium.
The account number for the bank
account or credit card.
This is required when either a credit
card or bank account is used to pay
some form of premium.
The routing number for the bank
account, in the case of PaymentMethod,
please use the type codes below:
PaymentMethod Type Code
Translation
2 = Checking
7 = Electronic Funds Transfer
26 = Preauthorized Check
This is required when a bank account is
used to pay some form of premium.
<AcctHolderName>
String
Optional
<BankName>
String
Optional
<BankBranchName>
String
Optional
<CardVerificationNum>
String
Optional
<PriorName>
Object
Optional
On Banking, when the AcctHolderName
is the same as the Name As It Appears
on Card, then the name should be
specified in both AcctHolderName and
PriorName on Banking.
Name of parent bank associated with
this account.
The name of the branch of the bank
where the account is established.
Also known as “CVC” which
represents the last three numbers on
the back of a credit card.
A number printed on the credit or debit
card used for security reasons. It
provides additional confirmation that the
person providing the card is in actual
possession of the card. Hence, it is
commonly required for phone or
electronic transactions. This number is
typically three to four positions.
Any other name of the party
Originally, this object was time-bound
51
XML Element Name
Type
Usage
Description
and reflected only prior names for the
associated Party. It has since evolved,
and is now being used to capture any
alternative name for the Party, such as a
Legal Name, etc.
A collection that represents all the prior
names used by a party, such as maiden
names, aliases, previous business
names, etc.
<PriorNameId>
ID
Optional
<PriorNameKey>
PERSISTKE Optional
Y
Default:
PERSIST_SES
SION
<PriorNameSysKey>
SysKey
Optional
<NameType>
TypeCode
Required
OLI_LU_NAME
TYPE
On Banking, when used for credit card,
it represents the Name as it appears on
the card. Note that the
PriorName.FullName property should
contain the name exactly as it appears
on the credit card without any
formatting.
and Keys
and Keys
and Keys
The type of prior name (e.g., maiden,
previous, alias).
6 = As it appears on card
<FullName>
String
Optional
<FirstName>
String
Optional
Full Name
When PriorName is used on Banking,
FullName should contain the name
exactly as it appears on the credit card
without any additional formatting.
First name of the person
52
XML Element Name
Type
Usage
Description
<MiddleName>
String
Optional
Middle name of the person
<LastName>
String
Optional
Last name of the person
<Suffix>
String
Optional
Suffix for the person.
For all persons, all suffixes (Jr., Sr.,
M.D., J.D., etc.) should be stored, in a
comma delimited format, in this
property.
For an insurance producer, put
insurance specific designations (FLMI,
CLU, ChFC, CFP, etc.) in the
Party.Producer.Certification property.
53
XML Element Name
Type
Usage
Description
5.10 <Bankruptcy> Object
TXLife/TXLifeRequest/OLifE/Party/Risk/Bankruptcy
Information about the bankruptcy experience of a party. There could be multiple bankruptcy objects on a
given case.
<Bankruptcy id=”Bankruptcy1_1”>
<Applicability tc=”1”>Applies</Applicability>
<BankruptcyReason>Medical Bills</BankruptcyReason>
<BankruptcyStatus tc=”2”>Discharged</BankruptcyStatus>
<BankruptcyStatusDate>2000-06-15</BankruptcyStatusDate>
<ChapterFiled tc=”7”>Chapter 7</ChapterFiled>
<FilingDate>1999-10-15</FilingDate>
</Bankruptcy>
<Bankruptcy id>
ID
Optional
<BankruptcyKey>
String
Optional
<Applicability>
TypeCode
Optional
OLI_LU_APPLI
CABILITY
and Keys
and Keys
Indicates state of applicability of the
parent aggregate. Since the parent
aggregate is Bankruptcy, this indicates if
a bankruptcy event is applicable.
If this parent is present it is a suggested
best practice that this property be
included.
This property documents the response
to the specific yes/no questions.
0 = Unknown
1 = Applies
2 = Does not apply
3 = Stated as Not Known
Definition: May or may not apply.
This status is slightly different than
"Unknown." If a question was asked
and not answered - or if a question
was never asked, then the
Applicability Response is
"Unknown." Use OLI_UNKNOWN
(NOT this code) in this case.
54
XML Element Name
Type
Usage
Description
However, if a question was asked,
and the response provided is
"Unknown" (or some equivalent),
then the answer is known and
modeled using this code value.
<BankruptcyReason>
String
Optional
<BankruptcyStatus>
TypeCode
Optional
OLI_LU_BANK
RUPTCYSTAT
US
Background information regarding what
caused the need to file for bankruptcy.
Identifies where in the bankruptcy
process a particular filing is at.
1 = Petition Filed
2 = Bankruptcy Filing Discharged
3 = Bankruptcy Filing Dismissed
<BankruptcyStatusDate>
Date
Optional
<ChapterFiled>
TypeCode
Optional
OLI_LU_
BANKRUPTCY
CHAPTER
Date on which current BankruptcyStatus
was attained.
Bankruptcy Chapter that was filed.
7 = Chapter 7
9 = Chapter 9
11 = Chapter 11
12 = Chapter 12
13 = Chapter 13
15 = Chapter 15
<FilingDate>
Date
Optional
<Attachment>
Object
Optional
Repeating
This represents the date on which the
bankruptcy was filed.
Used to provide a way to model generic,
unparseable details such as Comments.
<Attachment> Object for text
<Attachment> Object for images
<Attachment> Object for file
55
XML Element Name
Type
Usage
Description
5.11 <Coverage> Object (Base Coverage)
TXLife/TXLifeRequest/OLifE//Holding/Policy/Life/Coverage
Every New Business for Life transaction will include at least one Coverage Object for the base coverage.
Coverage defines or limits the provisions and obligations under a life insurance policy
<Coverage id="Coverage1_1">
<IndicatorCode tc="1">Base</IndicatorCode>
<DurationDesign >15</DurationDesign>
<CovOption>…
</CovOption>
<CovOption>…
</CovOption>
<LifeParticipant id="LP_1" PartyID="Party1_1">
</LifeParticipant>
</LifeParticipant>
</LifeParticipant>
<LifeParticipant id="LP_4">
</LifeParticipant>
</Coverage>
<CoverageID>
ID
<CoverageKey>
PERSISTKE Optional
Y
<CoverageSysKey>
SYSKEY
Optional
<PlanName>
String
Optional
<ShortName>
String
Optional
Optional
and Keys
and Keys
and Keys
official, and/or legal name used for the
base Coverage.
If the PlanName is identical to the
PlanName for the parent Policy, it does
not need to be specified here. If the
PlanName is different from the
PlanName for the parent Policy, then
provide the PlanName for clarification.
The base coverage will usually be
identified by the IndicatorCode.
Abbreviated or short name
56
XML Element Name
<MarketingName>
Type
String
Usage
Optional
<ProductCode>
String
Optional
<ProductVersionCode>
String
Optional
<CovNumber>
String
Optional
<LifeCovTypeCode>
TypeCode
Optional
OLI_LU_COVT
YPE
Description
The marketing name given by the carrier
for this item.
On Coverage, MarketingName indicates
the version marketing name associated
with a product. MarketingName is the
carriers marketing name associated with
the ProductVersionCode.
If the ProductCode is identical to the
ProductCode for the parent Policy, it
does not need to be specified here. If
the ProductCode is different from the
ProductCode for the parent Policy, then
provide the ProductCode for
clarification. The base coverage will
usually be identified by the
IndicatorCode.
ProductVersionCode defines the version
of a product, particularly when a
company uses the same ProductCode
across versions.
Business users require the ability to vary
product information without creating a
new product codes. The varied
information can include, but is not
limited to, product information such as
fees related to expenses, surrender
charges or premium loads. Version also
enables members to define versions of
bundled products. This enhanced
functionality allows the user to fulfill their
requirements for multiple versions of an
insurance product without creating
multiple product codes.
This applies when products are
versioned, but the same ProductCode is
used across versions.
Note that PolicyProduct would repeat for
each version.
Internal System Coverage Number
This element is to support systems
where coverages are stored in different
systems or as other policies each with
unique numbers
Type of coverage. Type codes with a
sublist referring to life insurance
57
XML Element Name
Type
Usage
Description
products may apply.
Default:
OLI_UNKNOW
N
<IndicatorCode>
TypeCode
Refer to the ACORD Help file for the
Required
OLI_LU_COVI
NDCODE
Default:
1 = Base
OLI_UNKNOW
N
<DurationDesign>
<LivesType>
Integer
Default: 0
TypeCode
Optional
Optional
OLI_LU_LIVES
TYPE
Duration for renewable, level and
decreasing terms and duration of limited
pay and graded premium whole life represented in years as integer; if
coverage is for life or not applicable,
integer will = 0.
This directly relates to 'Term' coverage
types and limited pay and limited
premium related coverage types. In
such cases, this is the number of years
the coverage is for. e.g. for a 20-year
term life coverage, the duration design
would be valued as 20.
Type code indicating whether the
coverage is Single, Joint, or Multi-life.
1 = Single Life
10 = Joint
Default:
OLI_UNKNOW
N
<TIAInEffectInd>
Coverage classification - e.g. base,
rider, etc. This field identifies the
coverage as Basic endorsement.
Optional
<TIAInEffectDate>
<TIAAmount>
Boolean
0 = False
1 = True
Date
Currency
<CurrentAmt>
Currency
Do Not Include
<LevelPremiumPeriod>
Integer
Optional
Optional
Optional
Indicates that a temporary insurance
indicator is in effect.
Temporary Insurance Effective Date
Temporary Insurance Agreement
amount
Recommendation is to use
Life.FaceAmt
Period of time that the premium will
remain level.
58
XML Element Name
<LevelPremiumPeriodUnits>
Type
TypeCode
Usage
Optional
OLI LU
MEASUNITS
Description
If the LevelPremiumPeriod is specified,
denote the time units of measure.
68 = Years
<CovOption>
Object
Optional
<LifeParticipant>
Object
Optional
Please reference the CovOption Object
section.
<CovOption> Object
Please reference the LifeParticipant
Object Section.
<LifeParticipant> Object
59
XML Element Name
Type
Usage
Description
5.12 <Coverage> Object (Rider Coverage)
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage
The Coverage Object also provides the rider information for the New Business transaction. The
IndicatorCode denotes what the Coverage Object is for a base coverage or rider. The Coverage Object for
rider is optional as the proposed policy may not include any riders.
<Coverage>
<PlanName>Children's Benefit Rider</PlanName>
<ProductCode>CR01</ProductCode>
<LifeCovTypeCode tc="116">Child Term Rider</LifeCovTypeCode>
<IndicatorCode tc="2">Rider</IndicatorCode>
<LivesType tc="11">Multi-Life - Undefined</LivesType>
<CurrentAmt>20000</CurrentAmt>
<LifeParticipant PartyID="Coverage_CBR_1_Insured_Party_1">…
</LifeParticipant>
<LifeParticipant PartyID="Coverage_CBR_2_Insured_Party_1">…
</LifeParticipant>
</Coverage>
<PlanName>
String
Optional
<ShortName>
String
Optional
<MarketingName>
String
Optional
<ProductCode>
String
Optional
String
Optional
Abbreviated or short name.
When at policy level, in O/JLife, Readonly from PolicyProduct.ShortName.
for this item.
This is a carrier assigned code used to
uniquely identify the object that contains
this property. Because the code is
assigned by a carrier, it needs to be
used in conjunction with a CarrierCode
to create a unique reference. There are
exceptions to this rule however. That is,
there are instances where the
ProductCode is actually used as a
foreign key to another object/product.
Those cases are noted in their usage
notes.
across versions.
60
XML Element Name
Type
Usage
Description
<Purpose>
TypeCode
Optional
OLI_LU_HOLD
PURPOSE
Default:
OLI_UNKNOW
N
<LifeCovTypeCode>
TypeCode
Required
each version.
Code showing purpose / goal of client
for which this was sold.
Indicate here if the purpose for this
Coverage differs from the Holding
Intent.
Type of coverage.
OLI_LU_COVT
YPE
Default:
OLI_UNKNOW
N
<IndicatorCode>
TypeCode
Required
OLI_LU_COVI
NDCODE
This field identifies the coverage as
Basic endorsement.
Default:
OLI_UNKNOW
N
<DurationDesign>
Integer
Default: 0
Coverage classification - e.g. base,
rider, etc.
2 = Rider
4 = Integrated Rider
Optional
Duration for renewable, level and
decreasing terms and duration of limited
pay and graded premium whole life represented in years as integer; if
coverage is for life or not applicable,
61
XML Element Name
Type
Usage
Description
integer will = 0.
<PremFreezeDate>
Date
Optional
<BeneDesignationWording>
String
Optional
<CurrentAmt>
Currency
Conditional
<CurrentNumberOfUnits>
Real
Conditional
This directly relates to 'Term' coverage
types and limited pay and limited
premium related coverage types. In
such cases, this is the number of years
the coverage is for. e.g. for a 20-year
term life coverage, the duration design
would be valued as 20.
The date in which the premium freezes.
This is applicable when coverage is for
income protection.
It is a date in which premium freezes
and in OLifE model it applies only when
the payment structure is "stepped".
In the case that the participant is a
beneficiary, this is the exact wording of
how the beneficiary was designated.
Amount of coverage -- the face amount
of the rider/benefit, without options.
Either CurrentAmt or
CurrentNumberOfUnits must be present
if there is a coverage amount
associated with this Coverage. If no
coverage amount is associated with this
Coverage, neither property is used. For
example: Waiver of Premium.
Do not include InitCovAmt on a new
business transaction because both the
initial coverage amount and the current
coverage amount are identical at that
point in time.
Current Number Of Units of this
coverage
Either CurrentAmt or
CurrentNumberOfUnits must be present
associated with this Coverage. If no
Coverage, neither property is used. For
example: Waiver of Premium.
Do not include InitialNumberOfUnits on
a new business transaction because
both the initial coverage units and the
62
XML Element Name
<ValuePerUnit>
Type
Currency
Usage
Conditional
Description
current coverage units are identical at
that point in time.
The value per unit of the Face units on
the basic coverage on the policy.
For coverages that are defined as units,
the total value can be calculated if
ValuePerUnit is present.
<ModalPremAmt>
Currency
Optional
<BenefitPeriod>
Date
Optional
<BenefitMode>
TypeCode
Optional
OLI_LU_PAYM
ODE
<MonthlyBenefitAmt>
Currency
Optional
<MonthlyBenefitEffDate>
Date
Optional
<BenefitPeriodAcc>
TypeCode
Optional
OLI_LU_BENE
PERIOD
Current amount of payment
Current modal premium/ payment
amount. May also be known as billed
premium amount. Represents the
amount that the carrier expects to be
paid.
The benefit period that an option is
guaranteed for, using Benefit Period
lookup table. For instance, a benefit
period could apply to a disability rider on
a life product.
Payout mode - same for accident and
sickness. For instance, a benefit mode
could apply to a disability rider on a life
product.
The maximum amount of benefits that
can be accelerated in a given month.
Long Term Care claim payments in a
given month cannot exceed this
amount. The figure is 'As Of' the
Monthly Benefit Effective Date.
The date for which the Monthly Benefit
Amt was effective.
Benefit Period for accident
lookup table. For instance, this could
apply to a disability rider on a life
product.
Default:
OLI_UNKNOW
N
<BenefitPeriodSick>
TypeCode
OLI_LU_BENE
PERIOD
Optional
Benefit Period for sickness
63
XML Element Name
Type
Usage
Description
lookup table. For instance, this could
apply to a disability rider on a life
product.
Default:
OLI_UNKNOW
N
<ElimPeriodAcc>
TypeCode
Optional
OLI_LU_ELIM
PERIOD
Period of time after accident claim onset
date before benefits are paid. For
instance, this could apply to a disability
rider on a life product.
Default:
OLI_UNKNOW
N
<ElimPeriodSick>
TypeCode
Optional
OLI_LU_ELIM
PERIOD
OLI_UNKNOW
N
<BenefitAmtSick>
Currency
Default: 0
Currency
Default: 0
Elimination Period for sickness
Period of time after sickness claim onset
date, before benefits are paid. For
instance, this could apply to a disability
rider on a life product.
Default:
<BenefitAmtAcc>
Elimination Period for accident
Optional
Benefit Amount Accident - $$ amount
Optional
Benefit amount paid for disabilities due
to accidents
Benefit Amount Sickness - $$ amount.
<CovOption>
Object
Optional
<LifeParticipant>
Object
Conditional
Benefit amount paid for disabilities due
to sickness
Please reference the CovOption Object
section.
<CovOption> Object
This object represents the different
participants that are associated with a
particular coverage
Required for riders where it‟s necessary
to relate a party directly to the coverage.
For example, the child rider insured
needs to be related to a child rider with
a LifeParticipantRole code with
typecode of 3, Insured Child.
<LifeParticipant> Object
64
XML Element Name
Type
Usage
Description
5.13 <CovOption> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage/CovOption
CovOption is used to describe all „components‟ of a policy that define or limit the provisions and obligations
of a superior/parent Coverage (Life) or Rider (Annuity or Disability Health). A CovOption further describes
or modifies its parent.
<CovOption>
<PlanName>Accidental Death Benefit</PlanName>
<ProductCode>ADR01</ProductCode>
<LifeCovOptTypeCode tc="2">ADB</LifeCovOptTypeCode>
<OptionAmt>50000</OptionAmt>
</CovOption>
<CovOptionlD>
ID
Optional
<CovOptionKey>
PERSISTKE Optional
Y
Default:
and Keys
and Keys
PERSIST_SES
SION
<CoverageSysKey>
SYSKEY
Optional
<ShortName>
String
Optional
<MarketingName>
String
Optional
<PlanName>
String
Optional
<ProductCode>
String
Optional
and Keys
When at policy level, in O/JLife, Readonly from PolicyProduct.ShortName.
for this item.
This is a carrier assigned code used to
uniquely identify the object that contains
this property. Because the code is
assigned by a carrier, it needs to be
used in conjunction with a CarrierCode
to create a unique reference. There are
exceptions to this rule however. That is,
there are instances where the
ProductCode is actually used as a
foreign key to another object/product.
Those cases are noted in their usage
65
XML Element Name
Type
String
Usage
Optional
Description
notes.
across versions.
<LifeCovOptTypeCode>
TypeCode
Required
OLI_LU_OPTT
YPE
Benefits selected on an insurance
policy, such as accelerated benefit,
death benefit, etc.
Default:
OLI_UNKNOW
N
<OptionAmt>
<OptionNumberOfUnits>
Currency
Default:0
Real
each version.
Benefit Type
Conditional
Face amount of benefit.
Conditional
Either OptionAmt or
OptionNumberOfUnits must be present
associated with this CovOption, neither
property is used. For example: Waiver
of Premium.
Number Of Units for this Option
Either OptionAmt or
OptionNumberOfUnits must be present
associated with this CovOption. If no
CovOption, neither property is used.
66
XML Element Name
Type
Usage
<ValuePerUnit>
Currency
Conditional
<OccupRating>
TypeCode
Optional
OLI_LU_OCC
UPRATING
Description
For example: Waiver of Premium.
The value per unit of the Face units on
the coverage option on the policy
For coverages that are defined as units,
the total value can be calculated if
ValuePerUnit is present.
Rating Sub Type (Occupational Rating
Code)
This table contains sub types for rating
types such as Occupational or Aviation.
The rating information on CovOption is
used to override any individual ratings
on the coverage participants for that
particular CovOption. The individuals
are NOT rated again. Rather, it's
indicating what ratings apply, if any, to
the CovOption itself.
On CovOption, OccupRating essentially
serves as a sub type for the
PermRatingType property.
<TempRatingType>
TypeCode
OLI_LU_RATI
NGTYPE
Optional
Temporary Rating Type
Use the OccupRating property to further
clarify TempRatingType. For example, if
TempRatingType = Aviation, the type of
Aviation rating is specified in
OccupRating.
1 = Impairment
2 = Aviation
3 = Temporary Extra
4 = Occupation
5 = Avocation
67
XML Element Name
<PermRatingType>
Type
TypeCode
OLI_LU_RATI
NGTYPE
Usage
Optional
Description
Permanent Rating Type
Use the OccupRating property to further
clarify PermRatingType. For example, if
PermRatingType = Aviation, the type of
Aviation rating is specified in
OccupRating.
1 = Impairment
2 = Aviation
3 = Temporary Extra
4 = Occupation
5 = Avocation
68
XML Element Name
Type
Usage
Description
5.14 <EMailAddress> Object
TXLife/TXLifeRequest/OLifE/Party/EMailAddress
The EMail Address object provides a collection point for details on Party email addresses.
<EMailAddress>
<EMailType tc="1"/>
<AddrLine>[email protected]</AddrLine>
</EMailAddress>
<EMailAddress id>
ID
Optional
<EMailType>
'Email Type'
TypeCode
Optional
OLI_LU_EMAI
LTYPE
1 = Business
2 = Personal
5 = Primary Email Address
6 = Secondary or Alternate Email
Address
<AddrLine>
String
Required
<PrefEMailAddr>
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Optional
<SolicitationInd>
and Keys
Type of e-mail address.
Optional
String representing complete, usable email address. This is correctly defined
as the 'SMTP' address.
Preferred e-mail address indicator.
True indicates that this party wants
(consents) to be solicited by this contact
point.
69
XML Element Name
Type
Usage
Description
5.15 <Employment> Object
TXLife/TXLifeRequest/OLifE/Party/Employment
On a new business transaction, the current employment information on the proposed insured is often
included. Can also be used when the policy purchased is a business insurance policy.
<Employment EmployerPartyID="Employer_Party_1">
<Occupation>Store Manager</Occupation>
<EmployerName>K-Mart</EmployerName>
<YearsAtEmployment>12</YearsAtEmployment>
<EmploymentDuties>Management</EmploymentDuties>
</Employment>
<EmploymentID>
ID
Optional
@EmployerPartyID
IDREF
Optional
<Occupation>
String
Optional
and Keys
References the Party of the employer
associated with the employment details.
Occupation for the person.
Can include values such as 'Doctor,'
'Lawyer,' etc.
<EmployerName>
<YearsAtEmployment>
<EmploymentDuties>
String
Real
String
Optional
This is taken into consideration for most
underwriting. Some carriers ask for
occupation on their application.
Name of Employer
Optional
If the only information you have is the
employer name then use this property.
If you have more information than the
full name (such as the address), then
put the name of the Employer in the
FullName of the employer Party Object.
Number of years at employment
Optional
Measures how long a party has been
with this employer in terms of years as
reported on the application.
Duties associated with employment
A list of the various duties the applicant
performs in the course of their
employment. Used to help the
underwriter assess the risk(s) inherent
in the job.
70
XML Element Name
Type
Usage
Description
5.16 <FinancialActivity> Object for initial payment
TXLife/TXLifeRequest/OLifE/Holding/Policy/FinancialActivity
The FinancialActivity represents the information for payment of the initial premium. The initial payment
may not fully satisfy the minimum requirement to put the policy inforce (initial premium). Most commonly,
there will be just one initial payment which would be represented by a single FinancialActivity with a single
Payment. If you are trying to represent a different scenario, please see the Payment Object definition on
FinancialActivity in the ACORD Help File. Each FinancialActivity business event will trigger one set of
accounting activities. Additionally, this means that if a financial activity is reversed, then all accounting
activities (and associated payments) must be reversed at the same time.
<FinancialActivity>
<FinActivityType tc="7">Initial Payment</FinActivityType>
<FinActivityDate>2008-01-23</FinActivityDate>
<Payment BankHoldingID="Holding6">
<PaymentForm tc="7">EFT</PaymentForm>
<PaymentAmt>100</PaymentAmt>
<SourceOfFundsTC tc="11">income</SourceOfFundsTC>
</Payment>
</FinancialActivity>
<FinancialActivity id>
ID
Optional
@DataRep
Attribute
Optional
<FinancialActivityKey>
PERSISTKE Optional
Y
<FinancialActivitySysKey>
SYSKEY
Optional
<FinActivityType>
'Financial Activity Type'
TypeCode
Required
<Description>
String
OLI_LU_FINA
CTTYPE
Optional
and Keys
and Keys
and Keys
and Keys
The type of financial activity.
7 = Initial Payment
Used to store human readable text that
names, references or describes the
object that hosts the property. In some
cases this information may actually print
or be displayed on a statement or form.
In others, it is nothing more than an
internal description
71
XML Element Name
Type
Usage
<FinActivityDate>
Date
Optional
<TransConfirmNum>
String
Optional
<Payment>
Object
Required
Description
Date financial activity was conducted e.g. trade date, date payment was
made. For checks, include the check
date.
Business Transaction Confirmation
Number
A unique confirmation identifier
associated with a business transaction.
Provides the assigned confirmation ID to
a financial activity.
On FinancialActivity, this is commonly
provided when an electronic payment is
received by a company. It provides the
customer with a unique identifier
associated with the transaction.
The Payment object is required for an
initial payment, and may be a collection,
but ordinarily would not be unless
several checks are involved in a
financial activity.
Most commonly, there will be just one
initial payment which would be
represented by a single FinancialActivity
with a single Payment. Since carriers
typically process initial payments
separately and do not reverse them as a
group, multiple checks for the initial
payment are not included in a single
FinancialActivity.
<Payment> Object
72
XML Element Name
Type
Usage
Description
5.17 <FinancialActivity> Object for 1035 Exchange
TXLife/TXLifeRequest/OLifE/Holding/Policy/FinancialActivity
This FinancialActivity represents the information present on the Proposed Holding for an anticipated 1035
exchange. It is anticipated that the actual funds/payments will be transacted at a time subsequent to the
submission of the New Business Transaction. There maybe one or more FinancialActivity objects present
indicating the exchange of multiple existing policies for this single new one.
<FinancialActivity>
<FinActivityType tc="210">1035 Exchange</FinActivityType>
<FinActivityGrossAmt>250000</FinActivityGrossAmt>
<PaymentForm tc="13">Funds to Follow</PaymentForm>
</Payment>
<FinancialActivity id>
ID
@DataRep
Data
Optional
Representati
on Type
<FinancialActivityKey>
Optional
Default:
Partial
PERSISTKE Optional
Y
<FinancialActivitySysKey>
SYSKEY
Optional
<FinActivityType>
'Financial Activity Type'
TypeCode
Required
<Description>
String
Optional
<FinActivityGrossAmt>
Currency
Optional
OLI_LU_FINA
CTTYPE
and Keys
and Keys
and Keys
and Keys
The type of financial activity.
210 = 1035 Exchange
Text describing this 1035 Financial
Transaction.
The anticipated gross amount for this
financial activity.
Note that this represents the amount
available from the policy represented by
73
<Payment>
<PaymentForm>
Object
Required
TypeCode
Required
OLI_LU_PAYM
ENTFORM
the Holding that is parent to this
FinancialActivity. If there is only this
single source, this gross amount will
represent the total being used to fund
the exchange. However, if there are
multiple sources involved, this amount
will not represent the total that is being
used to fund the exchange.
Since the transaction that will make the
actual payment will likely not occur until
later in the process, the sole purpose of
the Payment Object in this scenario is to
indicate that the funds will follow.
<Payment> Object
Form of Payment
13= Funds to Follow
Note: In the case of a 1035 Exchange,
on the 103 used to submit the proposed
application, this is the only Type Code
that would be valid.
74
XML Element Name
Type
Usage
Description
5.18 <FormInstance> Object
TXLife/TXLifeRequest/OLifE/FormInstance
Top level object representing an instance of a form
Used to denote or capture answers to questions on a form. The FormInstance provides for capturing
information that cannot otherwise be captured as data with the ACORD model. Use of FormInstance does
not preclude attaching an image of the form.
<FormInstance RelatedObjectID="Holding1" id="FI_001">
<FormName>Pru Short Form</FormName>
<ProviderFormNumber>ORD 113034</ProviderFormNumber>
<FormVersion>4/2005</FormVersion>
<FormResponse>
<QuestionNumber>Existions Ins b</QuestionNumber>
<ResponseCode>1</ResponseCode>
</FormResponse>
<FormResponse>
<QuestionNumber>Additional Coverage Indicator</QuestionNumber>
<ResponseCode>1</ResponseCode>
</FormResponse>
<FormResponse>
<QuestionNumber>Additional Coverage Policy Number</QuestionNumber>
<ResponseText>polnum123</ResponseText>
</FormResponse>
</FormInstance>
@id
ID
Required
@RelatedObjectID
IDREF
Optional
<FormName>
String
Conditional
<PrimaryFormInd>
<ProviderFormNumber>
Boolean
0 = False
1 = True
String
Optional
Conditional
and Keys
Indicates the relationship of this form to
any object in the model.
Name of form.
Required if neither
FormInstanceCategory nor
ProviderFormNumber are provided.
TRUE if this is a primary form, FALSE if
it is attached to or inserted into another
form.
Form number assigned by provider.
Represents the filed form number that
appears at the bottom of the form.
Required if neither
FormInstanceCategory nor FormName
are provided.
75
XML Element Name
<FormVersion>
<FormInstanceCategory>
<FormResponse>
<QuestionNumber>
<QuestionText>
<ResponseCode>
<ResponseData>
<ResponseText>
<SectionIdentifier>
<Attachment>
Type
String
String
Usage
Optional
Conditional
Description
Form version assigned by provider.
Indicates the version of the underlying
form used in the FormInstance.
The Carrier defined category of the
document
Object
Required
String
Conditional
Required when neither FormName nor
ProviderFormNumber are provided.
Details about individual questions and
their associated responses.
Identifier of the question on the form.
Conditional
Required when QuestionText is not
provided.
Exact wording of the question
Conditional
Required when QuestionNumber is not
provided.
Response to a multi-choice question.
String
Integer
String
String
String
Object
Conditional
Conditional
Optional
Optional
Required if neither ResponseData nor
ResponseText is provided.
A response taken from a structured set
of codes. The values of the codes may
be expressed as any alphanumeric
string.
Required if neither ResponseCode or
ResponseText is provided.
Response to a fill-in-the-blank or essay
question.
Required if neither ResponseData or
ResponseCode is provided.
Identifier of the section on the form.
Attachment of the form
76
XML Element Name
Type
Usage
Description
5.19 <Holding> Object for proposed policy
TXLife/TXLifeRequest/OLifE/Holding
The Holding object is a top-level object that contains basic information about any purchased or about to be
purchased financial product such as an insurance policy or a mutual fund. The type of holding will indicate
which secondary-level objects pertain.
For the new business transaction, one and only one Holding will represent the proposed policy.
<HoldingSysKey Persist="Permanent" VendorCode="0181">12345</HoldingSysKey>
<HoldingStatus tc="3">Pending</HoldingStatus>
<CurrencyTypeCode tc=”840”>US Dollar</CurrencyTypeCode>
<HoldingForm tc="1">Individual</HoldingForm>
<RestrictionCode tc=”1”>None</RestrictionCode>
<Policy …
</Policy>
<Attachment>,,,
</Attachment>
<Intent>
<ExpenseNeedTypeCode tc="18">Mortgage</ExpenseNeedTypeCode>
</Intent>
<Intent>
<ExpenseNeedTypeCode tc="10">Estate Planning</ExpenseNeedTypeCode>
</Intent>
</Holding>
<Holding id>
ID
Required
<HoldingSysKey>
SYSKEY
Optional
Repeating
and Keys
The general intention of SYSKEY is that
it is used to store and exchange
internal, database keys. As such, the
format is unrestricted.
Use the (ACORD) VendorCode attribute
to identify the associated vendor.
<AccountDesignation>
TypeCode
OLI_LU_ACCT
DES
Optional
Refer to additional information in
section 7.1.
Account Designation Choice Collection
This aggregate defines the available
valid Account Designations for the
parent object. Identifies how the
contract is registered and the owner
classification/designations for this policy.
77
XML Element Name
Type
Usage
Description
This also provides entity recognition for
the owner.
1 = Nominee name
2 = Intermediary
3 = Owner
4 = Self Directed
5 = Custodial
7 = Trust
8 = Joint
9 = Estate
<HoldingTypeCode>
LookUpTable String=
'Holding Type'
TypeCode
Required
OLI_LU_HOLD
TYPE
2 = Policy
Default:
OLI_UNKNOW
N
<HoldingStatus>
'Holding Status'
TypeCode
<Purpose>
TypeCode
Required
OLI_LU_HOLD
STAT
Optional
OLI_LU_HOLD
PURPOSE
Default:
OLI_UNKNOW
N
<CurrencyTypeCode>
TypeCode
Optional
OLI_LU_CURR
ENCYTYPE
Default:
Server.BaseCu
rrencyType
<HoldingForm>
TypeCode
OLI LU
HOLDINGFOR
M
Since this is a proposed policy holding,
only one HoldingTypeCode applies.
Required
Holding Status.
3 = Proposed - Pending - Not yet in
force
Applicant‟s purpose for purchasing
insurance.
Due to the possibility of the need to
capture more than one purpose, the
preferred location for the policy purpose
is in the IntentExpenseNeedTypeCode
(below).
It is assumed that all currency fields for
this object (including subobjects) are of
the same currency type.
Optional if US dollars, else specify
Form of the holding
1 = Individual
78
XML Element Name
<RestrictionCode>
Type
TypeCode
Usage
Optional
OLI_LU_REST
RICT
<Policy>
Object
Required
<Attachment>
Object
Optional
Repeating
<Intent>
Object
Optional
Repeating
<BusInterestID>
IDREF
Optional
<NeedName>
String
Conditional
<IntentCategory>
TypeCode
Optional
OLI LU
INTENTCATE
GORY
Description
Tells whether the holding has some
restriction
Required object to represent the details
of the proposed policy.
<Policy> Object for Proposed Policy
Attachment that is directly related to the
proposed Holding. For example, an
image of the application may be
attached.
It is preferred that Intent, rather than
Purpose, be used at the Holding level.
The object can support single or multiple
purposes because it repeats. If a
coverage is being purchased for a
different reason than the Holding Intent,
Purpose should be used on the
Coverage.
Identifies the business whose interests
are protected by the pending Holding.
Used to point to the Party.Organization
object.
Name of the expense Need
Required if ExpenseNeedTypeCode is
not provided
On Intent, this property provides a
category for the intent purpose as
expressed in ExpenseNeedTypeCode.
3 = Business
4 = Personal
<ExpenseNeedTypeCo TypeCode Conditional
OLI LU NEED
de>
Type of Expense Need
Required if name is not provided.
79
XML Element Name
Type
Usage
Description
5.20 <Holding> Object for existing insurance
In general, the Holding object is a top-level object that contains basic information about any purchased or
about to be purchased financial product such as an insurance policy or a mutual fund. In this case, the
Holding will represent an existing or other pending policy for an applicant.
The Holding object for exisiting insurance must be related to the proposed insured via a Holding to Party
Relation object. Note: only one Relation object is needed to denote exisiting insurance. To denote
Replaced or Exchanged insurance, an additional Holding to Holding Relation is needed. For replaced and
exchanged policies see the Holding for existing insurance – replaced.
If there is existing insurance, but no policy detail is available, the Holding is omitted. However, the related
indicator at Risk.ExistingInsuranceInd will still be set to “Yes.”
If the applicant has applied for life insurance within the past 90 days or has reinstated another policy,
repeat additional Holding objects to cover each instance with a status of pending.
<HoldingForm tc="2">Group</HoldingForm>
<Policy CarrierPartyID="Party7_1" id="Policy2_1">
<PolNumber>met123</PolNumber>
<LineOfBusiness tc="1">Life</LineOfBusiness>
<IssueDate>2000-01-01</IssueDate>
<Life>
<FaceAmt>100000</FaceAmt>
</Life>
</Policy>
</Holding>
<Holding id>
ID
Required
@DataRep
Attribute
Required
<HoldingTypeCode>
LookUpTable String=
'Holding Type'
TypeCode
Required
OLI_LU_HOLD
TYPE
and Keys
and Keys
Type of Holding
2 = Policy
Default:
OLI_UNKNOW
N
<HoldingStatus>
'Holding Status'
TypeCode
OLI_LU_HOLD
STAT
Optional
Holding Status
For existing insurance this would always
80
XML Element Name
Type
Usage
Description
be set to Active.
1 = Active
2 = Inactive (terminated, lapsed or
expired)
3 = Proposed (Pending)
<HoldingForm>
TypeCode
Optional
OLI LU
HOLDINGFOR
M
Form of holding
Designates the basic form (legal) of the
policy. A group policy would be in a
group master contract, an individual
policy is on an insurance form filed with
the jurisdiction.
Some carriers may exclude group
insurance during the underwriting
process and therefore would require the
HoldingForm on their application.
0 = Unknown
1 = Individual
2 = Group
<Policy>
@CarrierPartyID
Object
Required
IDREF
Required
The details of the existing insurance
policy are included in Policy.
This is a reference to the Party
Aggregate of the Carrier of this item.
<PolNumber>
String
Optional
If any information is known about the
carrier of the existing insurance, a
carrier Party should be created and
referenced by the CarrierPartyID.
Policy Number
<LineOfBusiness>
TypeCode
Optional
Line of business of the insurance
OLI LU
LINEBUS
0 = Unknown
1 = Life
81
XML Element Name
Type
Usage
Description
2 = Annuity
3 = Disability Insurance
<ProductType>
TypeCode
Optional
OLI LU
POLPROD
<PolicyStatus>
TypeCode
Optional
OLI LU
POLSTAT
<IssueDate>
Date
<ExchangeReasonCod TypeCode
OLI
e>
<Life>
Status of the existing or pending policy.
0 = Unknown
1 = Active
12 = Proposed
Optional
Optional
EXCHGREAS
ON
<ExchangeReason>
Type of the existing or proposed
insurance policy.
Object
Optional
Object
Conditional
Date at which an insurance policy was
issued. Most application forms to refer
to this as the year issued.
Since only the year is typically collected,
determination of month and day is
based on carrier rules. A formal
resolution is in progress.
On Policy, use the
ExchangeReasonCode property when
only a single exchange reason is
needed. If multiple reasons for the
exchange must be expressed, use
ExchangeReason aggregate instead.
Exchange Reason Code Collection
On Policy, use ExchangeReason when
multiple reasons for the exchange must
be expressed. If only a single exchange
reason is needed, use the
ExchangeReasonCode property on
Policy instead.
You must have one of the three objects:
Life, Annuity or DisabilityHealth.
82
XML Element Name
Type
Usage
Description
<Life> Object
<FaceAmt>
Currency
Required
Face Amount on the base coverage.
<NetSurrValueAmt>
Currency
Optional
<CashValueAmt>
Currency
Optional
<DeathBenefitAmt>
Currency
Optional
Cash Surrender value (NET) available
to the client if they were to surrender
their contract. This is the net of
surrender charges, loans, cash value
adjustments and termination dividend
amount.
For existing Holdings, this is the cash
value (account value) before surrender
charges.
Total death benefit.
<SurrenderChargeAmt Currency
>
Optional
<NetDeathBenefitAmt> Currency
<Annuity>
<DeathBenefitAmt>
<DisabilityHealth>
<IncomeAmtCov>
Optional
Object
Conditional
Currency
Required
Object
Conditional
Currency
Required
The SurrenderChargeAmt is the
difference between the accumulation
value and the surrender value,
*assuming that there are no loans on
the policy.
In other words, it is the surrender charge
that would be assessed if the policy
were completely surrendered on the
AsOfDate of the Holding.
This is the total death benefit (net of
loans) that would be paid upon the
primary insured‟s death.
When on policy, it represents the death
benefit for the primary insured on the
base coverage.
The amount of income covered by the
existing policy.
83
XML Element Name
Type
Usage
Description
5.21 <Holding> Object for existing insurance that is being replaced
Holding will represent an existing policy that will be replaced by this proposed policy.
The Holding object for replaced insurance must be related to the proposed insured via a Holding to Party
Relation object. In addition, a second Holding to Holding Relation Object is needed to denote the
replacement. Note: only one Relation object is needed to denote exisiting insurance. For existing insurance
that is not being replaced see the Holding for existing insurance.
In addition one or ApplicatonInfo.ReplacementInd and/or Risk.ReplacementInd may be set to TRUE.
replacement indicator may still be set to “Yes.”
<Policy CarrierPartyID="Party7">
<PolicyStatus tc=”1”>Active</PolicyStatus>
<Life>
</Life>
</Policy>
</Holding>
<Holding id>
ID
Required
@DataRep
Attribute
Required
<HoldingTypeCode>
LookUpTable String=
'Holding Type'
TypeCode
Required
OLI_LU_HOLD
TYPE
and Keys
and Keys
Type of Holding
2 = Policy
Default:
OLI_UNKNOW
N
<HoldingStatus>
'Holding Status'
TypeCode
OLI_LU_HOLD
STAT
Optional
Holding Status
84
XML Element Name
Type
Usage
Description
be set to Active.
1 = Active
expired)
<HoldingForm>
TypeCode
Optional
OLI LU
HOLDINGFOR
M
Form of holding
the jurisdiction.
0 = Unknown
1 = Individual
2 = Group
Object
Required
@CarrierPartyID
IDREF
Optional
<PolNumber>
String
Optional
Policy Number
<LineOfBusiness>
TypeCode
Optional
<Policy>
OLI LU
LINEBUS
0 = Unknown
1 = Life
2 = Annuity
85
XML Element Name
Type
Usage
Description
<ProductType>
TypeCode
Optional
OLI LU
POLPROD
<PolicyStatus>
TypeCode
Optional
OLI LU
POLSTAT
<ReplacementType>
TypeCode
insurance policy.
0 = Unknown
1 = Active
Optional
OLI_LU_REPL
ACETYPE
ReplacementType denotes the kind of
replacement when the applied for policy
is replacing an existing contract.
When used on the old or
replaced/exchanged policy it reflects the
ReplacementType for that specific
contract. This usage is applicable in the
context of the current transaction. It is
not intended to reflect any historical
replacement information for the
replaced/exchanged policy.
2 = Internal (Same Company Group)
3 = External
9 = Internal (Same Company)
10 = Intra-statutory
<PolicyValue>
Currency
Optional
Only used for existing insurance.
This is the total gross value of the
contract before any fees or charges are
applied. Any outstanding loan balances
have not been subtracted from this
86
XML Element Name
Type
Usage
Description
value.
<IssueDate>
Date
OLI
e>
Optional
Optional
EXCHGREAS
ON
<ExchangeReason>
Object
Optional
Object
Conditional
<FaceAmt>
Currency
Required
<NetSurrValueAmt>
Currency
Optional
<CashValueAmt>
Currency
Optional
<DeathBenefitAmt>
Currency
Optional
<Life>
For a Life Policy, use also the
NetSurrValueAmt, CashValueAmt,
DeathBenefitAmt, SurrenderChargeAmt,
NetDeathBenefitAmt to fully specify and
clarify the values available under the
policy.
it is customary to use a default month
and day of January 1st.
On Policy, use the
Policy instead.
<Life> Object
amount.
charges.
Total death benefit
87
XML Element Name
Type
Usage
>
Optional
Optional
<Annuity>
<DeathBenefitAmt>
<DisabilityHealth>
<IncomeAmtCov>
Object
Conditional
Currency
Required
Object
Conditional
Currency
Required
Description
the policy.
When on policy, it represents the death
benefit for the primary insured on the
base coverage.
The amount of income covered by the
existing policy.
88
XML Element Name
Type
Usage
Description
5.22 <Holding> Object for existing insurance that is being exchanged
Holding will represent an existing or other pending policy that will be exchanged in what is considered a
1035 exchange.
The Holding object for existing insurance that is being exchanged must be related to the proposed insured
via a Holding to Party Relation object. To denote Replaced or Exchanged insurance, an additional Holding
to Holding Relation is needed.
Note: only one Relation object is needed to denote existing insurance policies that are not being replaced
or exchanged. For existing insurance - see the Holding for existing insurance
indicator at Risk.ExistingInsuranceInd will still be set to “Yes.”
<Policy CarrierPartyID="Party7">
<PolicyStatus tc=”1”>Active</PolicyStatus>
<Life>
<LifeUSA>
<MECInd tc=”1”>TRUE</MECInd>
</LifeUSA>
</Life>
</Policy>
</Holding>
<Holding id>
ID
Required
@DataRep
Attribute
Required
<HoldingTypeCode>
LookUpTable String=
'Holding Type'
TypeCode
Required
OLI_LU_HOLD
TYPE
Default:
and Keys
and Keys
ReadOnly
Type of Holding
2 = Policy
89
XML Element Name
Type
Usage
Description
OLI_UNKNOW
N
<HoldingStatus>
'Holding Status'
TypeCode
Optional
OLI_LU_HOLD
STAT
Holding Status
be set to Active.
1 = Active
expired)
<HoldingForm>
TypeCode
Optional
OLI LU
HOLDINGFOR
M
Form of holding
the jurisdiction.
0 = Unknown
1 = Individual
2 = Group
<Policy>
@CarrierPartyID
<PolNumber>
Object
Required
IDREF
Optional
Optional
Policy Number
String
90
XML Element Name
<LineOfBusiness>
Type
TypeCode
Usage
Optional
OLI LU
LINEBUS
<ProductType>
TypeCode
Optional
OLI LU
POLPROD
<ReplacedPolicyPhysic TypeCode Optional
OLI_LU_POLI
alStatus>
CYREPLPYST
AT
<PolicyStatus>
TypeCode
Optional
OLI LU
POLSTAT
<ReplacementType>
TypeCode
OLI_LU_REPL
ACETYPE
Description
1 = Life
insurance policy.
This indicates who/where the actual
policy contract is, or whether its
lost/stolen.
May be used to indicate when a
replacement policy is lost/stolen, or
given to an agent/distributor to send to
carrier for exchange/replacement.
1 = Active
Optional
replacement when the applied for policy
is replacing an existing contract.
When used on the old or
replaced/exchanged policy it reflects the
ReplacementType for that specific
contract. This usage is applicable in the
context of the current transaction. It is
not intended to reflect any historical
replacement information for the
replaced/exchanged policy.
3 = External
10 = Intra-statutory
91
XML Element Name
<PolicyValue>
Type
Currency
Usage
Optional
Description
Only used for existing insurance.
This is the total gross value of the
contract before any fees or charges are
applied. Any outstanding loan balances
have not been subtracted from this
value.
<IssueDate>
Date
OLI
e>
Optional
Optional
EXCHGREAS
ON
<ExchangeReason>
Object
Optional
Object
Conditional
<FaceAmt>
Currency
Required
<NetSurrValueAmt>
Currency
Optional
<Life>
For a Life Policy, use also the
NetSurrValueAmt, CashValueAmt,
DeathBenefitAmt, SurrenderChargeAmt,
NetDeathBenefitAmt to fully specify and
clarify the values available under the
policy.
it is customary to use a default month
and day of January 1st.
On Policy, use the
Policy instead.
<Life> Object
92
XML Element Name
Type
Usage
Description
amount.
<CashValueAmt>
Currency
Optional
<DeathBenefitAmt>
Currency
Optional
>
Optional
Optional
<LifeUSA>
Optional
Object
charges.
Total death benefit
the policy.
<LifeUSA> Object for existing policy
93
XML Element Name
Type
Usage
Description
5.23 <Holding> Object for bank
This Holding object represents a bank or other financial institution associated with premium payments that
are represented in FinancialActivity.Payment Objects. Each bank Holding includes a Banking Object that
contains details about the account including the routing number, account number, etc.
<Banking id="Banking_2">
<BankAcctType tc="2">checking</BankAcctType>
<RoutingNum>789</RoutingNum>
<BankName>Wells Fargo</BankName>
</Banking>
</Holding>
<Holding id>
ID
Required
@DataRep
Attribute
Required
<HoldingTypeCode>
LookUpTable String=
'Holding Type'
TypeCode
Required
OLI_LU_HOLD
TYPE
7 = Banking
Default:
OLI_UNKNOW
N
<HoldingStatus>
TypeCode
Optional
OLI_LU_HOL
DSTAT
<Banking>
Object
and Keys
and Keys
Type of Holding...Asset, Liability, Policy,
etc.
Required
Holding Status
1 = Active
Account details of the bank Holding
<Banking> Object
94
XML Element Name
Type
Usage
Description
5.24 <Holding> Object for Loan
This Holding object represents information on the loan that is purchased as collateral for business
insurance. Each loan Holding includes a Loan Object that contains details about the loan.
<HoldingTypeCode tc="10">Business Loan</HoldingTypeCode>
<Loan FinancialInstitutionPartyID="Party_LoanCreditor1">
<LoanType tc=”0”>Unknown </LoanType>
<LoanStatus tc=”3”>Taken </LoanStatus>
<LoanStatusReason>Reason why the loan was not committed would go here</LoanStatusReason>
<LoanReason tc=”2147483647”>Other</LoanReason>
<LoanReasonDesc>Startup cash for business</LoanReasonDesc>
<LoanAmt>125000.00</LoanAmt>
<CommitmentDate>2007-01-06</CommitmentDate>
<RepaymentScheduleDesc>Qrtrly payments due Apr,July,Oct,Jan on the 25 day
</RepaymentScheduleDesc>
</Loan>
</Holding>
<Holding id>
ID
Required
@DataRep
Attribute
Required
<HoldingTypeCode>
LookUpTable String=
'Holding Type'
TypeCode
Required
<Loan>
FinancialInstitutionPartyID
<LoanType>
OLI_LU_HOLD
TYPE
Object
Attribute
Required
Conditionally
Required
TypeCode
Optional
OLI_LU_LNTY
PE
and Keys
and Keys
Type of Holding...Asset, Liability, Policy,
etc.
10=Business Loan
Used to hold information about a loan.
Pointer to the Banking object. Required
if the information on the bank account
providing the loan is available
References the bank providing the loan
Loan Type
As a best practice the type should
always be included when available on
an entity. In this case, the loan is a
business loan as noted in the
HoldingTypeCode. The specific types of
business loans have not yet been
95
XML Element Name
Type
Usage
Description
identified. A value of unknown is
acceptable until the specific type of
business loans are added to the
LoanType table
0=Unknown
<LoanStatus>
TypeCode
Optional
OLI_LU_LOAN
STAT
2=Requested
3=Taken
<LoanStatusReason>
String
<LoanReason>
Type Code Optional
Optional
OLI_LU_LOAN
REASON
<LoanReasonDesc>
String
Optional
String
String
<LoanPaymentMethod>
Type Code Optional
Optional
Optional
OLI_LU_PAYM
ETHOD
Type Code Optional
OLI_LU_PAYM
ODE
<CommitmentDate>
Date
current ACORD spec. Please see the
Help File for additional codes.
Reason for loan status – for example,
the reason why the loan was not
committed by the time of this application
Loan reason or purpose
2147483647=Other
<LoanAmt>
<LoanPaymentAmt>
<LoanPaymentMode>
Status of Loan
Optional
Loan Reason Description
On Loan, may be used when the
LoanReason property is set to "Other".
Loan Amount
The amount of each modal loan
repayment
Payment Method for this loan
Payment Mode for this loan.
Commitment Date
96
XML Element Name
Type
<RepaymentScheduleDesc> String
Usage
Optional
Description
Repayment Arrangement Description
Use this tag to identify loan repayment
arrangements presented as a string,
rather than the discreet data items:
LoanPaymentAmt,
LoanPaymentMethod,
LoanPaymentMode, and other pertinent
information. This is not intended to be
an alternative method of supplying the
arrangement details. If the specific
properties are known, they should be
used.
97
XML Element Name
Type
Usage
Description
5.25 <Investment> Object
TXLife/TXLifeRequest/OLifE/Holding/Investment
If a holding is an investment, this object pertains.
If a holding is an insurance policy that has investment options, such as a variable life insurance product,
this object contains the investment information associated with that policy as well.
The purpose of the Investment object for Life Variable products is to get to the SubAccount. No properties
were identified as needed for the 103 new business transaction.
98
XML Element Name
Type
Usage
Description
5.26 <Life> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life
This is required for life applications.
<Life>
<Coverage id="Coverage1_1">
</Coverage>
<Coverage>
</Coverage>
</Life>
<LifeKey>
PERSIST Optional
KEY
<LifeSysKey>
SYSKEY Optional
<NonFortProv>
TypeCode Optional
OLI_LU_NO
NFORTPRO
V
and Keys
and Keys
The various ways in which a
policyowner may apply the cash value
of a life insurance policy if the policy
lapses.
2 = Extended Term
Note: To take extended term
insurance instead of the cash
surrender value.
3= Reduced Paid Up
Note: To take reduced paid up
insurance instead of the cash
surrender value.
4 = Automatic Policy Loan (APL)
5 = APL then Extended Term
6 = APL then Reduce Paid Up
9 = Cash Surrender
Note: To forfeit the policy for its cash
surrender value.
<QualPlanType>
TypeCode Optional
Tax status of the policy or plan
OLI_LU_QU
99
XML Element Name
Type
ALPLAN
Usage
Description
Qualification plan type for this life
policy. Life products can be sold as
Tax Qualified products.
1 = Non-Qualified
2 = 401 (k)
34 = Defined Contribution
35 = Defined Benefit
50 = Keogh/HR10
69 = 412 (i) Plan
<FaceAmt>
<Coverage>
Currency Required
When on Life, this represents the
Default: 0
Base Policy Face Amount.
Recommendation is to use this
FaceAmount property to indicate base
face amount rather than any Coverage
Amount property on the base
Coverage object.
Object
One Required, Optional Please see the Coverage Object
Repeating
Section, at least one instance is
required for the base coverage.
<Coverage> Object (Base Coverage)
100
XML Element Name
Type
Usage
Description
5.27 <LifeParticipant> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage/LifeParticipant
This object represents the different participants that are associated with a particular coverage. It contains
properties that are unique to the issuance of life insurance. A party ID is utilized to obtain the party
information for the particular coverage.
A collection of participant objects is utilized to represent all the participants in a particular coverage.
Relationships between Holdings, Coverages and Parties can be modeled with the LifeParticipant or a
Relation. For further information, please refer to Section 4.16 of the ACORD Help File.
For ratings on a Coverage, you should be using the equivalent properties of the LifeParticipant object
(which is used to associate the Coverage with the insured Party). For example, if you had a simple Whole
Life policy with a Table B rating, you would have a single Coverage with a Coverage.IndicatorCode of "1"
(Base) and LifeCovTypeCode of "1" (WL Ordinary); and under that, a LifeParticipant with a
LifeParticipantRoleCode of "1" (Primary Insured) and a PermTableRatingAlphaCode of "B" (indicating
Table B).
Due to the constraints of the Data Model, the first instance of a rating (either permanent or temporary) are
included in LifeParticipant. Subsequent ratings of either type would go on SubstandardRating.
<LifeParticipantRoleCode tc="1">Primary Insured</LifeParticipantRoleCode>
<IssueAge>45</IssueAge>
<OccupRating tc="3">Construction</OccupRating>
<PermFlatExtraAmt>10</PermFlatExtraAmt>
<TobaccoPremiumBasis tc="1">non smoker</TobaccoPremiumBasis>
<PermTableRating tc="6">175%</PermTableRating>
<UnderwritingClass tc="1">Standard</UnderwritingClass>
<UnderwritingSubClass tc="2">Better</UnderwritingSubClass>
<PermRatingType tc="4">Occupation</PermRatingType>
<ClassName>Standard Better</ClassName>
<PermTableRatingAlphaCode>5</PermTableRatingAlphaCode>
<SubstandardRating id="SSR_001">…
</SubstandardRating>
</LifeParticipant>
@id
ID
Optional
PartyID
IDREF
Required
<LifeParticipantKey>
PERSIST Optional
KEY
and Keys
and Keys
and Keys
101
XML Element Name
Type
Usage
<LifeParticipantSysKey>
SYSKEY Optional
<LifeParticipantRoleCode>
TypeCode Required
OLI_LU_PA
RTICROLE
Default:
Description
and Keys
Role of the participant with respect to
this coverage. If this is the base
coverage, then this is the role with
respect to the entire policy.
The most common roles to find in
LifeParticipant are the insured and
beneficiary. Owners, payors, and
agents could be modeled here if they
differ from the contract level, but it
would be far less common.
OLI_UNKNO
WN
1 = Primary Insured
2 = Other Insured
3 = Insured Child
4 = Insured Dependent
5 = Insured Spouse
7 = Beneficiary – Primary
9 = Beneficiary – Contingent
<ParticipationPct>
Percent
Optional
<IssueAge>
Integer
<OccupRating>
TypeCode Optional
OLI_LU_OC
CUPRATING
Default:
OLI_UNKNO
WN
Optional
The percentage of participation the
Participant has in the overall relation
which it participates.
For example, the percentage of
ownership. Note that the participation
percentage for beneficiaries and
agents is typically modeled in a
Relation Object at the contract level in
InterestPercent.
Age of participant when coverage was
issued
Code).
types such as Occupational or
Aviation.
On LifeParticipant, OccupRating
essentially serves as a sub type for
102
XML Element Name
Type
Usage
Description
the PermRatingType property. For
example civilian and military could be
sub types of an aviation rating.
<PermFlatExtraAmt>
Currency Optional
Permanent flat extra amount
Default: 0
<SmokerStat>
TypeCode Optional
OLI_LU_SM
OKERSTAT
Default:
OLI_UNKNO
WN
On substandard risks, this amount is
an additional charge to the insured for
the life of the policy. Because the
insured represents a higher risk to the
company, the flat extra is charged to
compensate for that risk.
Indicates the client's tobacco usage
status at the time of policy purchase.
Party.Person.SmokerStat (and
TobaccoType and TobaccoFree)
represent the person's current
tobacco habits. This is not to be used
to determine the premium for the
policy but rather simply to reflect the
actual smoker status of the individual.
1 = Never Used Tobacco
2 = Prior Tobacco User
3 = Current Tobacco User
<TobaccoPremiumBasis>
TypeCode Optional
OLI_LU_TO
BPREMBASI
S
Tobacco usage factor that was used
to determine the premium.
TobaccoPremiumBasis is one of three
components used to represent a
carrier‟s unique rate class. The other
two properties are UnderwritingClass
and UnderwritingSubClass. The
carrier‟s full name of the class can be
designated in ClassName.
1 = Non-Smoker
2 = Smoker
3 = Non-Tobacco User
4 = Tobacco User
103
XML Element Name
Type
Usage
Description
5 = Blended
<RatingReason>
String
Optional
<PermTableRating>
TypeCode Optional
OLI_LU_RA
TINGS
Default:
OLI_UNKNO
WN
This element contains the reason that
the coverage/option was rated by the
underwriter. The reason can also be
used for field underwritten cases.
Permanent table rating for benefit
A table of valuation of risk of an
individual or organization. This is the
permanent rating according to this
table for this individual or organization.
This type code is only used to denote
the percentage mark-up of the
premium. The
PermTableRatingAlphaCode will
designate the text name for the table
rating such as “A”, or “AA”.
Due to the constraints of the Data
Model, the first instance of a
permanent rating are included here.
Subsequent ratings of either type
would go on SubstandardRating.
<TempTableRating>
TypeCode Optional
OLI_LU_RA
TINGS
Default:
OLI_UNKNO
WN
Temporary table rating for benefit.
individual or organization. This is a
temporary rating according to this
premium. The
TempTableRatingAlphaCode will
Due to the constraints of the Data
Model, the first instance of a
temporary rating are included here.
Subsequent ratings of either type
would go on SubstandardRating.
104
XML Element Name
<UnderwritingClass>
Type
Usage
OLI_LU_UN
WRITECLAS
S
Default:
OLI_UNKNO
WN
Description
Underwriting Class
Underwriting Class is one of three
two properties are TobaccoPremium
Basis and UnderwritingSubClass. The
Required for Insured types of
LifeParticipants and when
ClassName is not provided
1 = Standard Risk
2 = Preferred Risk
3 = Rated/Substandard Risk
4 = Aerobic (Super Preferred)
6 = Standard Plus (represents level
between standard and preferred)
19 = Preferred Plus (between
Preferred and Aerobic)
<UnderwritingSubClass>
TypeCode Optional
OLI_LU_UN
WRITESUB
CLASS
Default:
OLI_Unknow
n
Underwriting SubClass – used to
further classify the underwriting class
UnderwritingSubClass is one of three
two properties are TobaccoPremium
Basis and UnderwritingClass. The
1 = Best
2 = Better
3 = Worse
4 = Worst
105
XML Element Name
<BeneficiaryDesignation>
Type
Usage
OLI_LU_BE
NEDESIGNA
TION
Default:
OLI_UNKNO
WN
Description
Note that the BeneficiaryDesignation
is typically modeled in a Relation
Object at the contract level in
BeneficiaryDesignation.
BeneficiaryDesignation is used to
identify whether this beneficiary is
specifically "named" or if a beneficiary
will be identified as a class or group of
beneficiaries without specifically
naming the individual(s) or
organizations. For example, a named
beneficiary may be "Joe Smith" versus
an unnamed beneficiary of "All natural
children of insured."
If a beneficiary is named, information
about that person or organization is
represented in Party.
Unnamed beneficiaries are not further
qualified other than
BeneficiaryDesignation; unnamed
beneficiaries are modeled using
Relation RoleCode = Beneficiary and
Relation.BeneficiaryDesignation but
does not reference a Party.
In the case that the beneficiary
designation is 'Named' (tc=1), PartyID
(if on Participant or LifeParticipant) or
RelatedObjectId (if on Relation) and
BeneficiaryRoleCode is used to
describe whoever the beneficiary is.
All other values in this lookup are
applicable only when the beneficiary is
unnamed.
designation is 'Named', PartyID and
unnamed.
106
XML Element Name
Type
Usage
Description
1 = Named
2 = Estate
11 = Children of Marriage
12 = Children Born of Marriage
13 = Children of Insured
29 = All natural children of the insured
Required when the LifeParticipant
type represents a beneficiary.
<ClassName>
String
<PermTableRatingAlphaCode> String
Optional
Optional
Carrier's nomenclature (or marketing
name') for this underwriting class.
The underwriting class is typically
identified with a combination of
UnderwritingClass, TobaccoPremium
Basis and UnderwritingSubClass.
However, the carrier‟s full name of the
class can be designated in
ClassName and must be present if the
combination of identifying properties is
not used.
The value associated with a
percentage for a Permanent Rating
Table.
The PermTableRatingAlphaCode will
rating such as “A”, or “AA”. The
related PermTableRating code is used
to denote the percentage mark-up of
the premium.
<TempTableRatingCode>
String
Optional
Note that despite the name of the tag,
the code associated with a table may be
a numeric value. For example,
occupation tables may be numbered
with values 1 through 8 rather than A
through Z.
percentage for a Temp Rating Table.
The TempTableRatingAlphaCode will
107
XML Element Name
<Occupation>
<TempRatingType>
Type
String
Usage
Optional
TypeCode Optional
OLI_LU_RA
TINGTYPE
Description
rating such as “A”, or “AA”. The
related TempTableRating code is
used to denote the percentage markup of the premium.
Occupation for the person
'Lawyer,' etc.
This is taken into consideration for
most underwriting. Some carriers ask
for occupation on their application.
Temporary means the rating will be on
the policy for a specified period of
time. The reasons for rating a policy
which could include occupation risk,
aviation risk, or an impairment.
On LifeParticipant, use the
OccupRating property to further clarify
TempRatingType. For example, if
TempRatingType = Aviation, the type
of Aviation rating is specified in
OccupRating.
1 = Impairment
2 = Aviation
3 = Temporary Extra
4 = Occupation
5 = Avocation
<EmploymentClass>
TypeCode Optional
OLI_LU_EM
PLOYMENT
CLASS
The occupational rating for the policy,
coverage or rider to which this object
is attached.
Defines the rating applied to a
disability coverage. The rating affects
the calculation of the premium for the
policy, coverage, or rider.
108
XML Element Name
<PermRatingType>
Type
Usage
TypeCode Optional
OLI_LU_RA
TINGTYPE
Description
A permanent rating is never removed.
The reasons for rating a policy which
could include occupation risk, aviation
risk, or an impairment.
On LifeParticipant, use the
PermRatingType. For example, if
PermRatingType = Aviation, the type
OccupRating.
1 = Impairment
2 = Aviation
3 = Temporary Extra
4 = Occupation
5 = Avocation
<LivesWithPrimaryInsInd>
<SubstandardRating>
Boolean Optional
0 = False
1 = True
Object
Optional
Lives with the primary insured
TRUE = Lives with primary insured.
FALSE = Lives elsewhere.
The purpose of this object is to contain
tables 2 through x that are needed to
handle substandard cases. The first
rating, table, etc should be stored on
the respective parent Life Participant
or Participant object.
The first permanent rating type and
the first temporary rating type are
denoted here in
PermanentRatingType and
TemporaryRatingType, respectively.
If there are additional rating types,
they are designated here.
<AssocParticipantObjectInfo>
Object
Optional
<SubstandardRating> Object
Other objects associated to this
LifeParticipant object
This is used to identify other objects
that relate to the context of this
109
XML Element Name
Type
Usage
Description
LifeParticipant.. Examples include:
Identify succeeding beneficiaries for a
specific primary beneficiary
Identify the specific primary
beneficiary for a specific succeeding
beneficiary.
<BeneficiaryIncomeOptionInfo> Object
Conditional
Repeating
Other examples may apply.
Contains information about the
beneficiary income option.
On LifeParticipant,
BeneficiaryIncomeOptionInfo only
applies if the LifeParticipantRoleCode
is a type of beneficiary (e.g.
Beneficiary, Beneficiary - Contingent,
etc).
<BeneficiaryPaymentType TypeCode Optional
OLI_LU_BE
>
NEPAYMEN
TTYPE
<PaymentAmt>
<PaymentMode>
Currency Optional
TypeCode Optional
OLI_LU_PA
YMODE
Required if the object is present. As
a best practice, it is necessary to know
which option the other information in
this object is referring to.
A list of different payment types used
for beneficiary payments.
1 = Initial
2 = Final
3 = Periodic
Current amount of payment
On BeneficiaryIncomeOptionInfo, this
is the payment made to the
Beneficiary as defined by the
BeneficiaryPaymentType.
The frequency of a payment. Typically
annual, monthly, weekly, etc.
On BeneficiaryIncomeOptionInfo, this
is the mode of the PaymentAmt. If
BeneficiaryPaymentType is Initial or
Final then PaymentMode MUST be
'Single.'
110
XML Element Name
Type
Usage
Description
1 = Annually
2 = Semi-Annually
3 = Quarterly
4 = Monthly
9 = Single Payment
<Duration>
Integer
Optional
Duration in years based on current
point in time.
On BeneficiaryIncomeOptionInfo,
Duration only applies if
BeneficiaryPaymentType is "Periodic."
111
XML Element Name
Type
Usage
Description
5.28 <LifeUSA> Object for existing policy
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/LifeUSA
If the policy is issued within the USA, this object contains the properties that are unique to that
marketplace.
<LifeUSA>
<MECInd tc=”1”>TRUE</MECInd>
</LifeUSA>
<MECInd>
Boolean Optional
0 = False
1 = True
<Loan1035>
Currency Optional
The TAMRA Act of 1988 (see
TAMRA_AMT) created a new class of
life insurance called a Modified
Endowment Contract or MEC. A
contract becomes an MEC when it
exceeds a "7- Pay Test" established
by the Federal government. Once a
policy becomes an MEC, loans and
withdrawals are taxed as income first
and premium second. Also a 10%
penalty applies to loans and
withdrawals taken before age 59 and
a 1/2. However, the policy cash value
still accumulates tax-free and the
death benefit still goes to the
beneficiary tax free like a regular life
insurance policy.
Set this value to TRUE if some
determination has been made that this
policy is a MEC
The portion of LifeUSA.Amount1035
that is 'impaired'; i.e., borrowed by the
policy owner. If the source of the 1035
exchange policy is 'external' (not the
same Carrier), then this value will
typically be 0.0, because the external
Carrier will require that the loan be
repaid at the time the policy is
exchanged (and Amount 1035 will be
appropriately reduced). In the case of
an exchange within the same Carrier,
it may be permitted that the loan be
transferred to the newly issued policy.
Definition: Loan1035 is the amount of
the old policy's loan, if any. (Usually
only applicable if Internal1035 is
TRUE.)
112
XML Element Name
Type
Usage
Description
5.29 <LifeUSA> Object for the proposed policy
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/LifeUSA
If the policy is issued within the USA, this object contains the properties that are unique to that
marketplace.
<LifeUSA>
<DefLifeInsMethod id="1">
</LifeUSA>
<DefLifeInsMethod>
TypeCode Optional
OLI_LU_LIF
ETEST
Cash Value or Guideline Annual
Premiums - definition of life insurance
test.
1 = Guideline Premium Test
2 = Cash Value Test
<MECInd>
Boolean Optional
0 = False
1 = True
The TAMRA Act of 1988 (see
TAMRA_AMT) created a new class of
life insurance called a Modified
Endowment Contract or MEC.
A contract becomes an MEC when it
exceeds a "7- Pay Test" established
by the Federal government. Once a
policy becomes an MEC, loans and
withdrawals are taxed as income first
and premium second. Also a 10%
penalty applies to loans and
withdrawals taken before age 59 and
a 1/2. However, the policy cash value
still accumulates tax-free and the
death benefit still goes to the
beneficiary tax free like a regular life
insurance policy.
<Amount1035>
Currency Conditional
Set this value to TRUE if some
determination has been made that this
policy will be a MEC
The 1035 exchange amount of the
policy or policies being exchanged
upon issue of this 'proposed' or
'pending' policy.
113
XML Element Name
Type
Usage
Description
Amount1035 is the surrender value of
old policy, or policies, that are being
used to fund the 1035 exchange.
Required when there is one or more
1035 exchanges and the amount is
known. For new business
transactions, this value is typically
estimated.
<MEC1035>
<Loan1035>
Boolean Optional
0 = False
1 = True
Currency Optional
This property is only valued on the
proposed policy.
TRUE if any of the policies to be
exchanged for this policy is a MEC,
FALSE otherwise. 'MEC' means
'Modified Endowment Contract, as
defined by TAMRA (Technical
Adjustments and Miscellaneous
Revenue Act of 1988). By law, if an
exchanged policy is a MEC, then the
'proposed' or 'pending' policy will also
be issued as a MEC. This field applies
to both pending and inforce policies.
This property is only valued on the
proposed policy
The portion of LifeUSA.Amount1035
that is 'impaired'; i.e., borrowed by the
policy owner. If the source of the 1035
exchange policy is 'external' (not the
same Carrier), then this value will
typically be 0.0, because the external
Carrier will require that the loan be
repaid at the time the policy is
exchanged (and Amount 1035 will be
appropriately reduced). In the case of
an exchange within the same Carrier,
it may be permitted that the loan be
transferred to the newly issued policy.
Definition: Loan1035 is the amount of
the old policy's loan, if any. (Usually
only applicable if Internal1035 is
TRUE.)
114
XML Element Name
Type
Usage
Description
5.30 <MedicalCondition> Object
TXLife/TXLifeRequest/OLifE/Party/Risk/MedicalCondition
When used on the 103 New Business Transaction, information about a party's existing or prior medical
conditions as admitted to by the Proposed Insured during the application completion process and
paramedical/physician exam
<MedicalCondition id=”MedicalCondition_1”
<Applicability tc =”1”>Applies</Applicability>
<ConditionType tc=”578”>Disorders of lipoprotein metabolism and other lipidemias</ConditionType>
<ConditionOnsetDate>2000-06-01</ConditionOnsetDate>
<ConditionStatus tc=”2”>Under Doctor‟s Care</ConditionStatus>
<DateLastSeen>2009-09-15</DateLastSeen>
<MedicalTreatment>
<TreatmentType tc=”5”>Medication</TreatmentType>
<TreatmentStartDate>2000-06-15</TreatmentStartDate>
<TreatmentFrequencyMode tc=”1”>Per day</TreatmentFrequencyMode>
<TreatmentAmt>1</TreatmentAmt>
<Medication>Simvastatin</Medication>
</MedicalTreatment>
</MedicalCondition>
<MedicalCondition id=”MedicalCondition_2”>
<Applicability tc=”2”>Does Not Apply</Applicability>
<ConditionType tc=”3009”>Diabetes</ConditionType>
</MedicalCondition>
@id
ID
Conditional
<MedicalConditionKey>
String
Optional
<MedicalConditionSysKey>
String
Optional
<Applicability>
TypeCode Optional
OLI_LU_AP
PLICABILIT
Y
and Keys
Required if MedicalCondition is
referenced from another object
and Keys
and Keys
parent aggregate. For example, if the
parent aggregate is MedicalCondition,
this indicates if a Medical Condition is
known to apply or not apply to a Party.
If this parent is present it is a
115
XML Element Name
Type
Usage
Description
suggested best practice that this
property be included.
0 = Unknown
1 = Applies
2 = Does not apply
This status is slightly different
than "Unknown." If a question was
asked and not answered - or if a
question was never asked, then
the Applicability Response is
<DateLastUpdated>
Date
Optional
<ConditionType>
TypeCode Optional
OLI_LU_ME
DCOND
<ConditionDescription>
<ConditionOnsetDate>
<ConditionStatus>
String
Optional
Date
Optional
TypeCode Optional
OLI_LU_CO
NDSTATUS
Date that risk information was last
updated.
Diagnosis Medical condition of client.
Description of the condition.
Date the condition started.
Status of condition
1 = Recovered
2 = Under Doctor‟s Care
3 = Pending
4 = Ongoing
5 = Completed
<DateLastSeen>
Date
Optional
<RecurrencesInd>
Boolean Optional
0 = False
Date last seen for treatment of this
condition or for medical prevention.
Have you had any recurrences of this
condition? TRUE, if you have, FALSE
116
XML Element Name
Type
Usage
<TimeOffWork>
1 = True
Boolean Optional
0 = False
1 = True
Integer
Optional
<NumberEpisodesLastYear>
Integer
Optional
<NumberEpisodesTotal>
Integer
Optional
<LastEpisodeDate>
<RecoveryDate>
Date
Date
Optional
Optional
<ExamineeDesc>
String
Optional
<WeightChange>
Real
Optional
<DisabilityInd>
<TreatmentStartDate>
Date
<NumberEpisodesAverageYear> Integer
Optional
Optional
<ConditionLocation>
String
Optional
<ConditionStage>
String
Optional
<Cause>
TypeCode Optional
OLI_LU_CO
NDCAUSE
Description
if not.
Did you receive disability benefits as a
result of this injury? Yes/No
Time off work associated with this
condition, expressed in days.
The number of episodes of this
condition last year. Useful for
conditions such as asthma, epilepsy,
etc.
The total number of episodes of this
condition. Useful for conditions such
as asthma, epilepsy, etc.
Date of last episode of this condition.
Date of recovery of illness. If
ConditionType is TC=1551 (Now
Pregnant), RecoveryDate represents
the Expected Delivery Date.
Comments of the party for whom
treatment is being provided.
Weight change resulting from this
condition. Loss/Gain indicated by +/-.
Weight in kilograms.
Date first treatment started.
Average number of episodes of this
condition per year. Useful for
conditions such as asthma, epilepsy,
etc.
Location on the body where the
condition exists. Useful for conditions
that involve a tumor, mass, lump, etc.
The current stage of the condition.
Useful for conditions such as cancer.
Cause of Condition
1 = Situational
2 = Caffeine Induced
3 = Death of Family Member
4 = Divorce
5 = Stress
6 = Exercise
7 = Mitral Value Prolapse/MVP
8 = Job
9 = Job Loss
10 = Kidney Stones
11 = Anxiety
117
XML Element Name
Type
Usage
Description
12 = Pregnancy
<Severity>
TypeCode Optional
OLI_LU_SE
VERITY
1 = Mild
2 = Severe
3 = Moderate
<FirstDiagnosisDate>
Date
Optional
<MedicalConditionDuration>
<DurationDescription>
Integer
String
Optional
Optional
<DurationUnitMeasure>
TypeCode Optional
OLI_LU_
MEASUNITS
<MedicalTreatment>
<CardiacMurmur>
Object
Object
Measurement of Severity
Optional
Repeating
Optional
Repeating
Date when condition was first
diagnosed.
Length of time condition persisted
A length of time specified in a freeform format.
Unit of measurement used to define
the duration of time.
This collection will contain information
about a person's medical treatments,
but the presence in and by itself does
not denote which medical condition
the treatment applies to.
about a person's medical treatments
as they pertain to a defined medical
condition.
7.21 <MedicalTreatment> Object
Describes the heart murmurs that a
proposed insured may have. A person
can have several types of heart
murmurs.
118
XML Element Name
Type
Usage
Description
5.31 <MedicalExam> Object
TXLife/TXLifeRequest/OLifE/Party/Risk/MedicalExam
Medical Exam is used to capture findings from the pre-insurance examination done by either a paramedical
examiner or a physician. It is primarily used for the physical measurements. It can also be used to capture
which of the (other) required tests or observations may not have been satisfied during the examination and
any comments of the examiner. Use should be limited to representing information from the pre-insurance
examination.
<MedicalExam id=”MedicalExam_1” ExaminerPartyID=”Party_10”>
<CommentsIncompleteInd tc=”0”>False</CommentsIncompleteInd>
<ExaminerComments>Urine specimen not collected</ExaminerComments>
<Height2>
<MeasureUnits tc=”2”>US Standard System</MeasureUnits>
<MeasureValue>66</MeasureValue>
<HeightMeasuredInd tc=”1”>True</HeightMeasuredInd>
</Height2>
<Weight2>
<MeasureUnits tc=”2”>US Standard System</MeasureUnits>
<WeightMeasuredInd tc=”1”>True</WeightMeasuredInd>
</Weight2 >
</MedicalExam>
@id
ID
Conditional
@ExaminerPartyID
IDREF
Optional
@ExaminerCompanyID
IDREF
Optional
@InterpreterPartyID
IDREF
Optional
@RequirementInfoID
IDREF
Optional
<MedicalExamKey>
String
Optional
<MedicalExamSysKey>
String
Optional
<CommentsIncompleteInd>
Boolean Optional
0 = False
1 = True
and Keys
Reference to party, which is the
examiner.
This is the PartyID of the company the
examiner is employed by.
Reference to party that is the
interpreter.
Associates the parent object to a
particular RequirementInfo object.
and Keys
and Keys
A value of True indicates that not all
requirements associated with this
exam were satisfied.
If requirements were not completed,
119
XML Element Name
<ExaminerComments>
<Height2>
<MeasureUnits>
Type
Usage
String
Object
Optional
Optional
Repeating
TypeCode Optional
OLI_LU_ME
ASUREUNIT
S
Description
ExaminerComments should indicate
the reason. Use Attachment to capture
the actual comments.
General comments from the examiner.
The height of the person as measured
or stated.
Measure Units
1 = Metric System
Definition: Lengths are measured in
centimeters, weights are measured in
Kilograms
2 = US System Standard
inches, weights are measured in
pounds
3 = Alternate US Format
in feet with decimal being inches
Weights are measured in pounds with
decimal being ounces
<MeasureValue>
<HeightMeasuredInd>
<Weight2>
<MeasureUnits>
Real
Optional
Boolean Optional
0 = False
1 = True
Object
Optional
Repeating
TypeCode Optional
OLI_LU_ME
ASUREUNIT
S
4 = Another US Method
feet with decimal being decimal
fraction of feet. Weights are
measured in pounds with decimal
being decimal fraction of pound
Test Value
Measured
Was the MeasureValue obtained by
the Examiner actually measuring the
height of the Proposed Insured?
The weight of the person as measured
or stated.
Measure Units
1 = Metric System
Kilograms
120
XML Element Name
Type
Usage
Description
pounds
<MeasureValue>
<HeightMeasuredInd>
<Attachment>
Real
Optional
Boolean Optional
0 = False
1 = True
Object
Optional
Test Value
Measured
Was MeasureValue obtained by an
actual weighing of the Proposed
Insured by the Examiner?
Use to capture the actual comments if
the CommentsIncompleteInd is set to
True
121
XML Element Name
Type
Usage
Description
5.32 <MedicalPrevention> Object
TXLife/TXLifeRequest/OLifE/Party/Risk/MedicalPrevention
Information about medical tests performed on a Party for the purpose of prevention, diagnosis, or to
capture additional detail about a medical condition.
Notes:
This would be used to account for tests or diagnostic measures that result in normal findings. It can also
denote that a basic test resulted in a found (other than normal) condition. The details about the condition
would be noted in the MedicalConditions collection.
<MedicalPrevention id=”MedicalPrevention_1” MedConditionID=”MedicalCondition_1”>
< TestType tc=”9”>Cholesterol Test</TestType>
<TestDate>2000-06-01</TestDate>
<Results tc=”1”>True</Results>
<ConditionDescription>High Lipids</ConditionDescription>
<VisitReason tc=”2”>Routine visit</VisitReason>
<DateLastSeen>2009-09-15</DateLastSeen>
</MedicalPrevention>
@id
ID
Conditional
@LastTestFacility
IDREF
Optional
@LastTestPhysician
IDREF
Optional
@MedConditionID
IDREF
Optional
<MedicalPreventionKey>
String
Optional
<MedicalPreventionSysKey>
String
Optional
<TestType>
TypeCode Optional
OLI_LU_TE
STTYPE
and Keys
Required if MedicalPrevention is
referenced from another object
PartyID of the last test facility that
performed this test.
PartyID of last physician responsible
for this test.
If a condition is found, this is the
Reference to the actual condition.
and Keys
and Keys
Type of test performed
1 = Mammogram
2 = X-Ray
3 = Electrocardiogram
4 = Routine examination
122
XML Element Name
Type
Usage
Description
5 = Annual/Bi-Annual Pap Smear
6 = Pregancy Test
7 = Multiple Biochemical Analysis
8 = Prostate Test
9 = Cholesterol Test
10 = Liver Function Test
11 = HIV Screening
12 = Hemoccult
13 = Barium Enema
14 = Cat Scan
15 = Colonoscopy
16 = CBC (Complete Blood Count)
17 = Diagnostic Test
18 = DRE (Digital Rectal Examination)
19 = Doppler
20 = Flexible Sigmaoidoscopy
21 = Hemoglobin A1C
22 = Labwork/Blood
23 = Lower GI (Gastrointestinal)
24 = MRI (Magnetic Resonance
Imaging)
25 = PSA (Prostate-Specific Antigen)
26 = Pulmonary Function Test
27 = Treadmill EKG/Stress test
28 = Ultra Sound
30 = Upper GI (Gastrointestinal)
<TestDate>
<Results>
<ConditionDescription>
<VisitReason>
Date
Optional
Boolean Optional
0 = False
1 = True
String
Optional
TypeCode Optional
OLI_LU_
DRVISITRE
ASON
Date the test occurred.
Results were positive - TRUE
(indicating a condition was found) or
negative - FALSE.
Description of the condition.
Reason for doctor visit
1 = Accident
2 = Routine visit
3 = Consultation
4 = Sickness
5 = Prevention
6 = Sports Exam
7 = Department of Transportation
Exam
8 = Employment Exam
123
XML Element Name
Type
Usage
Description
9 = FAA Exam
10 = Insurance Exam
11 = Marital Exam
12 = OB/GYN Exam
13 = Diagnostic Exam
14 = School Physical
15 = Eye Exam
16 = Pregnancy Exam
17 = Annual Physical Exam
18 = Infertility Workup
19 = Chiropractic Exam
<TestDuration>
Integer
Optional
<DurationUnitMeasure>
TypeCode Optional
OLI_LU_
MEASUNITS
<DateLastSeen>
Date
Optional
The duration of time for the test in unit
measurements.
Define the type of unit measurement
using the DurationUnitMeasure
property.
Units of measure. The Description
field of this table should contain the
printed symbol or abbreviation as it
would appear when displayed or
printed.
124
XML Element Name
Type
Usage
Description
TXLife/TXLifeRequest/OLifE/Party/Risk/MedicalCondition/MedicalTreatment
This collection will contain information about a person's medical treatments, but the presence in and by
itself does not denote which medical condition the treatment applies to. However, when MedicalTreatment
is subordinate to MedicalCondition, the treatment is for the condition defined in the parent object.
<MedicalTreatment id=”MedicalTreatment_1” TreatmentPhysicianPartyID=”Party_10”>
<TreatmentType tc=”5”>Medication</TreatmentType>
<TreatmentStartDate>2000-06-15</TreatmentStartDate>
<TreatmentFrequencyMode tc=”1”>Per day</TreatmentFrequencyMode>
<TreatmentAmt>1</TreatmentAmt>
<Medication>Simvastatin</Medication>
</MedicalTreatment>
@id
ID
Conditional
@TreatmentPhysicianPartyID
@TreatmentFacilityPartyID
<MedicalConditionKey>
IDREF
IDREF
String
Optional
Optional
Optional
<MedicalConditionSysKey>
String
Optional
<TreatmentType>
TypeCode Optional
OLI_LU_TR
EATMENTT
YPE
and Keys
Required if MedicalTreatment is
referenced by another object
Party ID of primary treating Physician
Party ID of primary treatment location
and Keys
and Keys
Type of treatment received or being
received.
1 = Test
2 = Surgery
3 = Examination
4 = Advice (Recommendation)
5 = Medication
6 = Rehabilitation
7 = Hospitalization
8 = Chemotherapy
9 = Radiation
10 = Convalescence (bed rest)
11 = Chiropractic
12 = Myotherapy
125
XML Element Name
Type
Usage
Description
13 = Physiotherapy
14 = Podiatry
15 = Psychiatric
17 = CPAP (Continuous Positive
Airway Pressure)
18 = N-CPAP
20 = Insulin – Pump
21 = Insulin – Injections
22 = Oral Medications
23 = Diet
24 = Immunosuppressants Therapy
<TreatmentStartDate>
<DateLastSeen>
Date
Date
<TreatmentCompletionInd>
Boolean Optional
0 = False
1 = True
TypeCode Optional
<TreatmentFrequencyMode>
Optional
Optional
OLI_LU_PA
RTFREQ
Date first treatment started.
Indicates if treatment is completed.
Yes if completed, no if not.
Frequency mode TreatmentAmt is
based on.
1 = Per day
2 = Per week
3 = Per month
4 = Per year
5 = Single
6 = Random
<TreatmentAmt>
Integer
Optional
<Medication>
String
Optional
<ComplicationsInd>
<PatientID>
Boolean Optional
0 = False
1 = True
String
Optional
<ExamineeDesc>
String
Optional
<TreatmentDesc>
String
Optional
Amount of treatment, based on
frequency mode.
Medication associated with Treatment,
if any.
Any complications? TRUE if there
were complications, FALSE if no.
Number used by medical provider to
ID patient.
Comments of the party for whom
treatment is being provided.
To capture the detailed findings of the
126
XML Element Name
Type
Usage
<TreatmentDuration>
Integer
Optional
<TreatmentReason>
String
Optional
Description
examiner/treatment provider.
The duration of time for the treatment
in unit measurements.
Reason for which treatment was
provided.
When the TreatmentType is 'Advice
(tc=4)', then TreatmentReason should
contain the advice, but it can also be
used to describe the treatment reason
for other TreatmentTypes.
127
XML Element Name
Type
Usage
Description
5.34 <OrganizationFinancialData> Object for Business Insurance
TXLife/TXLifeRequest/OLifE/Party/Organization/OrganizationFinancialData
If the proposed owner is an organization, for example a corporation or a trust, a Party object with an
Organization aggregate is required along with this object to include the financial information about the
organization.
The OrganizationFinancialData object should be repeated if there is a need to represent more than one
year‟s financial data. If the TaxYrEndDate is not known then only one occurrence of the
OrganizationFinancialData object is needed and the previous year‟s properties should be used.
<OrganizationFinancialData>
<CurrentAssetsAmt>250000.0</CurrentAssetsAmt>
<CurrentLiabilitiesAmt>50000.0</CurrentLiabilitiesAmt>
<NumEmployees>50</NumEmployees>
<PrevYrEndGrossSalesAmt>205000.0</PrevYrEndGrossSalesAmt>
<EstMarketValueAmt>3000000.0</EstMarketValueAmt>
<YrEndNetProfitAmt>200000.0</YrEndNetProfitAmt>
<YrEndNetWorthAmt>8000000.0</YrEndNetWorthAmt>
</OrganizationFinancialData>
<OrganizationFinancialData id>
ID
Optional
<TaxYrEndDate>
Date
Optional
<CurrentAssetsAmt>
Currency
Optional
<FixedAssetsAmt>
Currency
Optional
<CurrentLiabilitiesAmt>
Currency
Optional
<LongTermLiabilitiesAmt>
Currency
Optional
<TotalCapitalAmt>
Currency
Optional
<NumEmployees>
Integer
Optional
<NumBoardMembers>
Integer
Optional
<PrevYrEndGrossSalesAmt>
Currency
Optional
<PrevYrNetIncomeAmt>
Currency
Optional
<PrevYrTaxableEarningsAmt>
Currency
Optional
and Keys
The organization‟s tax year end date
Total current assets of the
organization as of the TaxYrEndDate
Total amount of fixed assets of the
Total current liabilities of the
Total long term liabilities of the
Total capital of the organization as of
the TaxYrEndDate
Total number of people the
organization employees as of the
TaxYrEndDate
Total number of board members of the
Total amount of gross sales at the last
year end.
Total amount of net income for the
previous year.
Total amount of taxable earnings for
the previous year.
128
XML Element Name
<AvailFinancialInd>
<EstMarketValueAmt>
<YrEndNetProfitAmt>
<YrEndNetWorthAmt>
<InfoSourceTC>
Type
Boolean
0 = False
1 = True
Currency
Currency
Currency
TypeCode
OLI_LU_INFO
SRC
Usage
Description
Optional
Indicates whether the financial
statements are available or not.
Optional
Optional
Optional
Optional
Estimated market value amount
Year end net profit amount
Year end net worth amount
Indicates the source of the financial
information.
1 = Proposed Insured
2 = Account Reps
Estimate/Producer‟s Estimate
129
XML Element Name
Type
Usage
Description
5.35 <Party> Object for Proposed Insured(s)
TXLife/TXLifeRequest/OLifE/Party
Each NBfL transaction will have at least one proposed insured Party Object. The Party represents the
basic information that applies to the proposed insured(s).
<Party id="Primary_Insured_Party_1">
<PartyTypeCode tc="1">Person</PartyTypeCode>
<GovtID>111222333</GovtID>
<GovtIDTC tc="1">SSN</GovtIDTC>
<ResidenceState tc="1">Alabama</ResidenceState>
<ResidenceCountry tc="1">USA</ResidenceCountry>
<EstNetWorth>500000</EstNetWorth>
<Person>
<FirstName>Elmer</FirstName>
<MiddleName>T</MiddleName>
<LastName>Simpson</LastName>
<Occupation>Belly dancer</Occupation>
<MarStat tc="1">Married</MarStat>
<Gender tc="1">Male</Gender>
<BirthDate>1974-03-24</BirthDate>
<Citizenship tc="20">Egypt</Citizenship>
<EstSalary>35000</EstSalary>
<TobaccoFree>2004-02-02</TobaccoFree>
<SmokerStat tc="2">Prior Tobacco User</SmokerStat>
<Height2>
<MeasureUnits tc="2">inches</MeasureUnits>
</Height2>
<Weight2>
<MeasureUnits tc="2">pounds</MeasureUnits>
</Weight2>
<DriversLicenseNum>VA7932981</DriversLicenseNum>
<NoDriversLicenseInd tc="1">false</NoDriversLicenseInd>
<DriversLicenseState tc="55">VA</DriversLicenseState>
<DriversLicenseCountry tc="1">United States</DriversLicenseCountry>
<BirthCountry tc="1">US</BirthCountry>
<BirthJurisdictionTC tc="55">Virginia</BirthJurisdictionTC>
<DriversLicenseExpDate>2009-02-01</DriversLicenseExpDate>
</Person>
<Address>..
</Address>
<Phone>..
</Phone>
<EMailAddress>..
</EMailAddress>
<Risk>..
</Risk>
<Employment EmployerPartyID="Primary_Insured_Employer_Party_1">…l
130
XML Element Name
Type
Usage
Description
</Employment>
</Party>
@id
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
1 = Person
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
String
Conditional
<GovtID>
<GovtIDTC>
'Government ID Type Code'
String
TypeCode
OLI LU
GOVTIDTC
and Keys
and Keys
Type of party existing in the collection.
Conditional
Conditional
and Keys
and Keys
Full name of the object or party. On
Party, when Party.Type='Person',
FullName is formatted '%L, %F %M,
%S' where %L is LastName, %F is
FirstName, %M is MiddleName and
%S is Suffix.
Required when the parsed elements
of the name (Person.FirstName,
Person.LastName) are not available.
String that represents the government
ID. For example, a social security
number or tax identification number.
The government ID is required for the
primary proposed insured. It may not
be available for child rider insureds.
Type code describing the contents of
GovtID.
131
XML Element Name
Type
Usage
Description
1 = Social Security Number US
9 = Tax ID for US non-resident alien
18 = Green Card US
Required whenever GovtID is
provided.
<ResidenceState>
'State'
TypeCode
<ResidenceCountry>
TypeCode
Required
OLI LU STATE
Required
OLI LU
NATION
<ResidenceCounty>
String
Optional
<EstNetWorth>
Currency
Optional
<EstTotLiabilitiesAmt>
Currency
Optional
<PrefComm>
TypeCode
Optional
OLI LU
PREFCOMM
<BestTimeToCallFrom>
State of residence for the party.
Time
Residence or Domicile Country
For individuals/persons the Country of
residence...
Residence or Domicile County
For individuals/persons the County of
residence. For organizations this is the
domicile county.
Estimated net-worth as of date record
was created.
Estimated total liabilities as of date
record was created.
Preferred means of communication
1 = Phone
2 = Fax
3 = Email
4 = Regular Mail
5 = Don‟t contact
Optional
Preference to be called at or after this
specific time. E.g. if best time to call is
between 9am and 5pm, this would
represent 9am. For schema purposes,
9am Eastern should appear in the
format 09:00:00-05:00.
132
XML Element Name
Type
Usage
<BestTimeToCallTo>
Time
Optional
<ResidenceCountyTC>
TypeCode
Optional
OLI LU
COUNTY
Description
Indicates the preference to be called
before this time. E.g. if best time to
call is between 9am and 5pm, this
would represent 5pm. For schema
purposes, 5pm Eastern should appear
in the format 17:00:00-05:00.
County of residence
The county of the state in which the
party resides.
May be used if the system provides a
drop down list
@id
Object
ID
Required
Optional
<PersonKey>
String
Optional
<PersonSysKey>
String
Optional
<FirstName>
<MiddleName>
<LastName>
<NickName>
String
String
String
String
Required
Optional
Required
Optional
<Initials>
String
Optional
<Prefix>
String
Optional
Details about the proposed insured
and Keys
and Keys
and Keys
A nickname (or preferred name) that a
party uses instead of the given
name(s).
Initials of the person
This includes the initial(s) of the
surname and should include no
punctuation or formatting. This is
needed to reflect names where initials
cannot be easily derived and would be
manually entered.
Prefix for the person
Optional
Can include values such as 'Mr.',
'Mrs.', 'Ms.', 'Dr.', etc..
<Person>
<Suffix>
String
133
XML Element Name
Type
Usage
Description
property.
<Title>
<Occupation>
<MarStat>
String
String
TypeCode
Optional
Person's professional title
Optional
Can include values such as
'President', etc. This can be used to
store the job title for a person. It may
also be used to store the title used
when addressing a letter.
Occupation for the person
Optional
'Lawyer,' etc. For underwriting
purposes, the occupation is
represented on
LifeParticipant.Occupation.
Marital Status of the Person
OLI LU
MARSTAT
0 = Unknown
1 = Married
2 = Single
3 = Divorced
4 = Widowed
<Gender>
TypeCode
Optional
OLI LU
GENDER
<BirthDate>
<Age>
<Citizenship>
Date
Integer
TypeCode
Gender of the person
1 = Male
2 = Female
Required
Optional
Optional
Date of birth for the person
Age of the person
Citizenship of person
OLI LU
134
XML Element Name
Type
Usage
NATION
<OccupClass>
TypeCode
Optional
OLI LU
OCCUPCLASS
<EstSalary>
Currency
Optional
<EstGrossAnnualOtherI Currency
ncome>
Optional
<TobaccoType>
TypeCode
Optional
OLI LU
TOBACCOTYP
E
<TobaccoFree>
<SmokerStat>
Date
TypeCode
OLI LU
SMOKERSTAT
Description
General class of occupation of the
person for use rate look ups and
underwriting. For underwriting
purposes, the occupation class is
represented on
LifeParticipant.OccupClass.
Estimated annual salary of participant
In the U.S., this is defined as earning
subject to FICA including salary, tips,
bonuses, self-employment income,
other employment income, and net
earned business income. All income is
before qualified retirement plan
contributions (401K, etc.).
Estimated non-salary (in the U.S. this
is non-W2) income.
Defined as all income from sources
not included in salary field, including
interest, dividends, pension income,
alimony, and other non-FICA income.
Indicates the type(s) of tobacco used
by the client.
Note that it is recommended to include
the tobacco types on
Risk.SubstanceUsage which is
repeating.
Optional
Optional
The date since the client has ceased
all tobacco use.
Note that it is recommended to the
use the
Risk.SubstanceUsage.SubstanceEnd
Date rather than TobaccoFree here on
Person.
Indicates the client's history of tobacco
use.
135
XML Element Name
Type
Usage
Description
the SmokerStat on LifeParticipant for
this proposed insured instead.
<SmokingFrequencyMo TypeCode
OLI LU
de>
Optional
PARTFREQ
Mode of frequency of smoking for the
person. E.g. Per day, per week, per
month, etc.
the smoking frequency on
SubstanceUsage.SubstanceMode
instead.
<SmokingFrequencyNu Integer
mber>
<Height2>
Object
<MeasureUnits> TypeCode
OLI LU
MEASUREUNI
TS
Optional
Optional
Optional
Number of times person smokes,
based on mode. (Number of units e.g. # of cigarettes, cigars)
the smoking frequency on
SubstanceUsage.SubstanceAmt
instead.
This is the stated height of the
applicant
Meausre Units
1 = Metric System
Kilograms
pounds
136
XML Element Name
Type
<MeasureValue> Real
<
Boolean
HeightMeasuredI 0 = False
nd>
1 = True
Usage
Required
Optional
<WeightHistory>
Object
Optional
<Weight2>
Object
Optional
< MeasureUnits> TypeCode
Optional
OLI LU
MEASUREUNI
TS
Height in the units of measure
reported in MeasureUnits. For
example, “62” for 62 inches.
The ACORD standard only provides
for one measurement value; therefore
measurement for feet/inches should
be stated in inches for transmission,
and, if necessary translated back into
feet and inches by the recipient.
Boolean to indicate if the height was
determined by measuring the
proposed insured or not. Indicate
false if the height was self-reported.
Weight at a prior point in time.
Requests for this information will vary
by carrier. Weight gain/loss can be
derived by comparing different Weight
History over time, or to the current
weight expressed under Person or
MedicalExam.
<WeightHistory> Object
This is the stated height of the
applicant
Measure units
< MeasureValue> Real
Required
<
Boolean
WeightMeasuredI 0 = False
nd>
1 = True
Optional
<DriversLicenseNum> Optional
Description
Optional
Height in the units of measure
reported in MeasureUnits. For
example, “62” for 62 inches.
Boolean to indicate if the height was
determined by measuring the
proposed insured or not. Indicate
false if the weight was self-reported.
String representing the driver's license
number of the person. Use of this
property does not imply that the
137
XML Element Name
Type
Usage
Description
individual's identity has been verified.
<NoDriversLicenseInd> Boolean
0 = False
1 = True
Optional
When true, this property indicates that
a person does not have a driver's
license. It should only be set to true if
it is known explicitly that the Person
does not have a driver's license. Its
intended use is to determine that a
Motor Vehicle Report is not required.
No assumptions should be made
regarding driver's license information
left blank on a form.
<NoDriversLicenseRea String
son>
<DriversLicenseState> TypeCode
Optional
Conditional
OLI LU STATE
Note that this indicator should NOT be
set to true if the person has a driver's
license that is suspended or revoked.
Text description of the reason a
person does not have a drivers license
On Person, NoDriversLicenseReason
is used when NoDriversLicenseInd is
set to "True".
State in which the driver's license was
issued.
Required when DriversLicenseNum is
provided.
<DriversLicenseCountr TypeCode
OLI LU
y>
Optional
NATION
<DriversLicenseStatus TypeCode Optional
OLI_LU_DLST
>
ATUS
<BirthCountry>
TypeCode
Country in which the driver's license
was issued.
The current status of a drivers license
1 = Active
2 = Suspended
3 = Revoked
4 = Expired
Conditional
Country of birthplace
OLI LU
138
XML Element Name
Type
Usage
NATION
<BirthJurisdiction>
String
Description
Required if the person was born
outside the US, unless the question is
prohibited by state regulations.
Optional
State/province of birthplace
Modeled like Address.State
This may be more than two
characters, plus formatting, to
accommodate all countries. For U.S.
states, this should be the official twoletter upper case abbreviation.
<BirthJurisdictionTC>
TypeCode
Conditional
The preference is to use
BirthJurisdictionTC for US birth
places.
The jurisdiction of birth
OLI LU STATE
Required when BirthCountry = 1 for
United States.
<GovImmigrationNo>
String
Conditional
<ImmigrationStatus>
TypeCode
Conditional
OLI LU
IMMSTAT
If person is not a citizen of the country
for which he/she is applying for
insurance, this would be the ID
number used by the government for
identification purposes. In the US, this
is the alien registration receipt card
number (green card) for permanent
residents, and their Visa number for
temporary residents.
Conditional, if they are not a US
Citizen (Citizenship) then this field is
required.
Indicates the immigration/citizenship
status of the person with respect to
the nation indicated in the
Party.ResidenceCountry property.
Conditional, if they are not a US
Citizen (Citizenship) then this field is
required.
1 = Permanent Resident
139
XML Element Name
Type
Usage
Description
2 = Visitor
3 = Student
4 = Employee
5 = Refugee/Claimant
6 = Application for landing immigration
7 = Landed immigrant
8 = The party is a citizen (by either
birth or naturalization) of the nation
indicated by the
Party.ResidenceCountry
<ImmigrationEntryDate Date
>
Optional
<VisaExpDate>
Date
<GuestLengthOfStayYe Integer
ars>
Optional
Optional
<GuestLengthOfStayM Integer
onths>
Optional
<GuestLengthOfStayD Integer
ays>
Optional
The date on which the applicant first
entered the country in which they now
reside. Used in conjunction with
ImmigrationStatus
Date the Person's visa expires
Length of stay in guest country,
expressed in years
On Person, length of stay can be
expressed variously as days, weeks,
months, or combinations such as
years & months, years & days, months
& days. Use this property in
conjunction with
GuestLengthOfStayMonths and
GuestLengthOfStayDays, as
appropriate.
expressed in months
conjunction with
GuestLengthOfStayYears and
GuestLengthOfStayDays, as
appropriate.
expressed in days
140
XML Element Name
Type
Usage
<Address>
Object
Required
<Phone>
Object
Required
<EmailAddress>
Object
Optional
<Risk>
Object
Optional
<Employment>
Object
Optional
Description
conjunction with
GuestLengthOfStayYears and
GuestLengthOfStayMonths, as
appropriate.
An address pertaining to the proposed
insured.
<Address> Object
Phone information for the proposed
insured.
<Phone> Object
Email address information for the
proposed insured.
<EMailAddress> Object
Risk information for the proposed
insured.
<Risk> Object
Employment for the proposed insured.
<Employment> Object
141
XML Element Name
Type
Usage
Description
5.36 <Party> Object for Beneficiary (Person)
The Party object represents entities involved with this New Business transaction. It includes data and
aggregates that provide more detailed information about the Party. For example, the Person Object
contains more detailed information about an individual person.
At least one beneficiary Party, either a Person or Organization, must be represented in a New Business
transaction. Please reference appendix C “Sample XML for Beneficiary Roles” on how to relate the
beneficiary to the Holding.
<Party id="Party2_1">
<GovtIDTypeCode tc="1">SSN</GovtIDTypeCode>
<Person>
<FirstName>James</FirstName>
<MiddleName>P</MiddleName>
<LastName>Jones</LastName>
<Suffix>III</Suffix>
<Age>25</Age>
</Person>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
String
Conditional
OLI_LU_PART
Y
and Keys
and Keys
1 = Person
and Keys
and Keys
Full name of the beneficiary.
On Party, when Party.Type='Person',
142
XML Element Name
Type
Usage
Description
%S is Suffix. If the data entry system
does not segregate elements of the
name, it may not be possible to format
the FullName in this manner.
<GovtID>
String
Optional
<GovtIDTC>
TypeCode
Conditional
OLI LU
GOVTIDTC
ID, for example, a social security
GovtID.
18 = Green Card US
Required if the GovtID is provided.
@id
Object
ID
Required
Optional
<FirstName>
<MiddleName>
String
String
Required
Optional
Details about the beneficiary.
and Keys
Required
Optional
This field is not necessarily just a
middle initial. If only a middle initial is
used by a program, that program
should be careful to put back the
entire middle name, unless it is
changed.
Optional
'Mrs.', 'Ms.', 'Dr.', etc..
Suffix for the person
<Person>
<LastName>
<Prefix>
<Suffix>
String
String
String
143
XML Element Name
Type
Usage
Description
property.
<Title>
<BirthDate>
<Age>
String
Optional
<Address>
Date
Integer
Object
Optional
Optional
Optional
<Phone>
Object
Optional
<EmailAddress>
Object
Optional
Age of the person
An address pertaining to the
beneficiary
<Address> Object
Phone information for the beneficiary
<Phone> Object
proposed insured
144
XML Element Name
Type
Usage
Description
5.37 <Party> Object for Beneficiary (Organization)
The Party object represents entities involved with this New Business transaction. It includes data and
aggregates that provide more detailed information about the Party. For example, the Organization Object
contains more detailed information about an organization.
At least one beneficiary Party, either a Person or Organization, must be represented in a New Business
transaction. Please reference appendix C “Sample XML for Beneficiary Roles” on how to relate the
beneficiary to the Holding.
<Party id="Party11_1a">
<PartyTypeCode tc="2">Organization</PartyTypeCode>
<FullName>name of organization</FullName>
<Organization>
<OrgForm tc="16">Trust</OrgForm>
<TrustType tc="111">Family Trust</TrustType>
<IrrevokableInd tc="1">True</IrrevokableInd >
<EstabDate>2001-02-01</EstabDate>
</Organization>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
<Organization>
@id
String
Object
ID
Required
Required
Optional
OLI_LU_PART
Y
and Keys
and Keys
2 = Organization
and Keys
and Keys
Name of the organization
A Type of Party
and Keys
145
XML Element Name
<OrgForm>
Type
TypeCode
Usage
Required
OLI LU
ORGFORM
Description
Organization Form
Common law provides for nonpersons to have a legal existence and
have various legally enforceable
rights, such as owning property, etc.
This field defines the various nonperson legal entities that are legally
recognized.
0 = Unknown
1 = Sole Proprietorship
2 = Partnership
11 = Charitable Organization
12 = Non-Profit Organization
16 = Trust
23 = Corporation, General
24 = Estate
26 = Religious Organization
For some beneficiaries, the OrgForm
may not be identifiable. In this case
use a type code of 0 – Unknown.
Some examples include creditors and
educational institutions. More
information, if known, can be
represented with a Relation Object or
the NatureCategory of the
Organization.
<TrustType>
TypeCode
Optional
OLI LU
TRUSTTYPE
Defines the formal legal structure of a
trust.
When OrgForm=Trust this further
describes the type of trust.
<IrrevokableInd>
Boolean
0 = False
1 = True
Optional
If this organization beneficiary is a
trust, indicates whether it is
irrevocable or not. To indicate
whether the beneficiary is designated
as irrevocable for this policy, see
Relation.IrrevokableInd or
LifeParticipant.IrrevokableInd.
146
XML Element Name
<NatureCategory>
Type
TypeCode
Usage
Optional
OLI__LU_NAT
URECAT
Description
The Nature Category is used to define
the fundamental and distinct classes
to which an organization belongs.
For example, a type code of 32
represents an educational institution.
<EstabDate>
String
Conditional
<Address>
Object
Optional
<Phone>
Object
Optional
<EmailAddress>
Object
Optional
Date the organization was
established.
Required if OrgForm=Trust and
IrrevokableInd is true.
beneficiary
<Address> Object
Phone information for the beneficiary
<Phone> Object
proposed insured
147
XML Element Name
Type
Usage
Description
5.38 <Party> Object for natural person owner who is not the insured
If the owner of the proposed insurance in the 103 New Business transaction is a natural person Height2
owner (an individual) other than the insured, a separate party object is required.
<GovtIDTC tc="1">US SSN</GovtIDTC>
<Person>
<MiddleName>P</MiddleName>
<Suffix>sr</Suffix>
<Citizenship tc="1">USA</Citizenship>
<ImmigrationStatus tc="8">citizen</ImmigrationStatus>
</Person>
<Address>
<Line1>12 State St</Line1>
<City>Ogden</City>
<AddressStateTC tc="52">UT</AddressStateTC>
<Zip>84041</Zip>
</Address>
<Risk>
<TotalInforceAndAppliedIns>10000000</TotalInforceAndAppliedIns>
</Risk>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
and Keys
and Keys
The natural owner is a person rather
than an organization.
<PartyKey>
String
Optional
1 = Person
148
XML Element Name
Type
Usage
<PartySysKey>
String
Optional
<FullName>
String
Optional
<GovtID>
String
Required
<GovtIDTC>
TypeCode
Required
OLI LU
GOVTIDTC
Description
and Keys
and Keys
Full name of the object or party. On
Party, when Party.Type='Person',
%S is Suffix.
GovtID.
18 = Green Card US
<EstNetWorth>
Currency
Optional
<Person>
@id
Object
ID
Required
Optional
<FirstName>
<MiddleName>
<LastName>
<Prefix>
String
String
String
String
Required
Optional
Required
Optional
Estimated net-worth as of date record
was created
and Keys
Optional
'Mrs.', 'Ms.', 'Dr.', etc..
<Suffix>
String
149
XML Element Name
Type
Usage
Description
property.
<Title>
<Gender>
String
TypeCode
Optional
Optional
Gender of the person
OLI LU
GENDER
<BirthDate>
<DOBEstimated>
<Age>
<Citizenship>
Date
Boolean
0 = False
1 = True
Integer
TypeCode
1 = Male
2 = Female
Optional
Optional
Optional
Optional
OLI LU
NATION
<EstSalary>
Currency
<EstGrossAnnualOtherI Currency
ncome>
<ImmigrationStatus> TypeCode
Optional
Optional
Optional
OLI LU
IMMSTAT
Indicates whether the date of birth for
the person is estimated.
Age of the person
Citizenship of person
Estimated annual salary of the person
Estimated non-salary (in the U.S. this
is non-W2) income.
Indicates the immigration/citizenship
status of the person with respect to
the nation indicated in the
Party.ResidenceCountry property.
Recommended if the owner is not a
US Citizen (Citizenship).
<Address>
Object
Required
An address pertaining to the proposed
insured
150
XML Element Name
Type
Usage
Description
<Phone>
Object
Optional
<EmailAddress>
Object
Optional
<Risk>
Object
Optional
<TotalInforceAndAppliedIns>
Currency
Optional
<Address> Object
Phone information for the proposed
insured
<Phone> Object
proposed insured
Risk information for the natural owner
who is not the insured.
<Risk> Object
Total Inforce and Applied Insurance
Optional
An amount indicating the total dollar
amount of insurance that is in force
and applied for pending approval for
the individual.
Total Inforce Insurance
<TotalInforceIns>
Currency
amount of insurance that is in force for
the individual.
<TotalAppliedForIns>
Currency
Optional
To be used if the individual amount of
in force Insurance is known. If the
individual amounts of insurance in
force and applied for insurance are
unknown, then continue to use
TotalInforceAndAppliedIns.
Total Insurance Amount Applied
amount of insurance that is applied for
and pending approval for the
individual.
Insurance that has been applied for
and not yet approved is known. If
force and applied for are unknown,
then continue to use
151
XML Element Name
Type
Usage
Description
5.39 <Party> Object for organization owner
If the proposed owner is an organization, like a corporation or a trust, a Party object with an Organization
aggregate is required. Can also be used when the Organization represents the business in a business
insurance policy.
<Organization>
<TrustType tc="111">Family Trust</TrustType>
<IrrevokableInd tc="1">True</IrrevokableInd >
</Organization>
</Party>
<Party id>
ID
Required
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
<GovtID>
String
String
Required
Optional
<GovtIDTC>
TypeCode
Conditional
OLI LU
GOVTIDTC
and Keys
This party is an organization owner.
2 = Organization
and Keys
and Keys
ID. In the USA, this is the Social
Security Number for a person or TIN
for an organization.
GovtID.
2 = Taxpayer Identification Number
8 = US Employer Identification
Number
152
XML Element Name
<Organization>
@id
<OrgForm>
Type
Usage
Object
ID
Required
Optional
TypeCode
Required
OLI LU
ORGFORM
Description
A Type of Party
and Keys
Organization Form
recognized.
0 = Unknown
2 = Partnership
16 = Trust
24 = Estate
<TrustType>
TypeCode
Optional
OLI LU
TRUSTTYPE
Defines the formal legal structure of a
trust.
When OrgForm is a trust (tc=16) this
further describes the type of trust.
<IrrevokableInd>
Boolean
0 = False
1 = True
Optional
If this organization beneficiary is a
trust (OrgForm tc=16), indicates
whether it is irrevocable or not.
To indicate whether the beneficiary is
designated as irrevocable for this
policy, see Relation.IrrevokableInd or
LifeParticipant.IrrevokableInd.
153
XML Element Name
<NatureCategory>
Type
TypeCode
Usage
Optional
OLI LU
NATURECAT
Description
The Nature Category is used to define
the fundamental and distinct classes
to which an organization belongs.
For example, a type code of 32
represents an educational institution.
<EstabDate>
String
Conditional
<OrganizationFinan Object
cialData>
Conditional
<BusinessInsPurpo Object
seInfo>
Optional
<BuyInsPurpose TypeCode Optional
OLI LU NEED
Type>
<Address>
<BuySellAgreem Boolean
entInd>
0 = False
1 = True
<MultiPartyCover Boolean
edInd>
0 = False
1 = True
Optional
<MultiPartyCover String
edDesc>
Optional
<KeyManDesc> String
Optional
Object
Optional
Optional
Date the organization was
established.
Required if OrgForm=Trust and
IrrevokableInd is true.
Finanical information about the
organization.
Required for Business Insurance.
Refer to the object link below for
details.
<OrganizationFinancialData> Object
for Business Insurance
Used to specify information about a
business as it pertains to business
insurance.
This is how a business would indicate
the types of business insurance it is
allowed to buy.
Indicates that there is a Written Buy
Sell agreement in place. Used where
BusInsPurposeType=BuySell.
Used to indicate that multiple parties
are covered by business insurance
and that all have comparable amounts
of coverage.
If MultiPartyCoveredInd is set to true,
this property may be used to
document the details of the other
parties covered.
Description of why a person is key to
the organization. Details of the special
skills/ knowledge/ ability needed by
the organization.
organization owner.
<Address> Object
154
XML Element Name
Type
Usage
<Phone>
Object
Optional
<EmailAddress>
Object
Optional
Description
Phone information for the organization
owner.
<Phone> Object
organization owner.
155
XML Element Name
Type
Usage
Description
5.40 <Party> Object for other business insurance owners
For business insurance, this Party Object represents the information requested for the other owners of the
business, if any. Percent of ownership is found in the relation object.
<Person>
<FirstName>Charles</FirstName>
<MiddleName>B</MiddleName>
<LastName>Officer</LastName>
<Age>50</Age>
</Person>
<Risk>
</Risk>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
and Keys
and Keys
The natural owner is a person rather
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<Person>
@id
Object
ID
Required
Optional
<FirstName>
String
Required
1 = Person
and Keys
and Keys
and Keys
156
XML Element Name
Type
Usage
<MiddleName>
<LastName>
<Prefix>
String
String
String
Optional
Required
Optional
<Suffix>
String
Optional
Description
'Mrs.', 'Ms.', 'Dr.', etc..
property.
<Title>
String
Optional
<Risk>
Integer
Object
Optional
Optional
Currency
Optional
Age of the person
Risk information for the natural owner
who is not the insured.
<Risk> Object
Optional
the individual.
Optional
the individual.
<Age>
<TotalInforceIns>
Currency
Currency
157
XML Element Name
Type
Usage
Description
individual.
158
XML Element Name
Type
Usage
Description
5.41 <Party> Object for agency
A party object represents the agency for the proposed insurance. The agency‟s appointment information
for the carrier of the proposed insurance is included.
<Party id=”Party4_1”>
<PartyTypeCode tc‟”2”>Organization</PartyTypeCode>
<PartyKey>AGCYKEY</PartyKey>
<PartySyskey>AGCYSYSKEY</PartySysKey>
<FullName>Agency name</FullName>
<GovID>123456789</GovtID>
<GovIDTC tc=”2”>Taxpayer Identification Number</GovtIDTC>
<Organization id>=”Org4_1”>
<ResidenceState tc=”1”>Alabama</ResidenceState>
<OrganizationKey>ORGAGCY</OrganizationKey>
<OrganizationSysKey>ORGSYSAGCY</OrganizationSysKey>
<AbbrNam>Agency Nam Incorporated</AbbrName>
<OrgCode>AGCY</OrgCode>
</Organization>
<Producer>
<NIPRNumber>34995433</NIPRNumber>
<CompanyProducerID>ABC123</CompanyProducerID>
<CarrierCode>INSCO</CarrierCode>
</CarrierAppointment>
</Producer>
</Party>
<Party id>
ID
Required
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
and Keys
The agency is an organization
(corporation, etc.).
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
2 = Organization
and Keys
and Keys
159
XML Element Name
Type
Usage
<FullName>
<GovtID>
String
String
Optional
Optional
<GovtIDTC>
TypeCode
Conditional
OLI LU
GOVTIDTC
Description
Full name of the agency.
ID. In the USA, this is typically the
Social Security Number for a person
or TIN for an organization.
GovtID.
2 = Taxpayer Identification Number
8 = US Employer Identification
Number
<ResidenceState>
'State'
TypeCode
<Organization>
Object
Required
@id
ID
Optional
<OrganizationKey>
String
Optional
<OrganizationSysKey> String
Optional
<AbbrName>
<OrgCode>
String
String
Optional
Optional
Object
Optional
String
Optional
<Producer>
<NIPRNumber>
Optional
State of residence for the party.
OLI LU STATE
An organization object is necessary
for an agency
and Keys
and Keys
and Keys
Abbreviated name of the Organization.
Defined as a short code assigned by
the organization to internally identify
the organizational unit. For example,
this is where the office code would go.
An agent, agency, broker, broker
dealer or distributor
This captures the additional
information you have on a commission
earning party
The agency‟s National Insurance
Producer Registry Number (or other
160
XML Element Name
Type
Usage
Object
Optional
<CompanyProducerID> String
Optional
<CarrierCode>
Optional
String
Description
authorizing authorities id number).
The information for each appointment
for a producer. Defines the agency‟s
appointment information with this
carrier for this new business
transaction.
The company producer ID represents
the agency‟s appointment number with
the carrier for the proposed holding.
This code uniquely represents the
insurance carrier for which this carrier
appointment applies. The NAIC code
is recommended as the CarrierCode.
161
XML Element Name
Type
Usage
Description
5.42 <Party> Object for Producer
A party object represents the agent(s) for the proposed insurance. The agent‟s appointment information for
the carrier of the proposed insurance is included.
<Person>
<FirstName>Robert</FirstName>
<LastName>Bush</LastName>
</Person>
<Producer>
<Certification>CLU</Certification>
<CompanyProducerID>ABC123</CompanyProducerID>
</Producer>
</Party>
<Party id>
ID
Required
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
and Keys
The agent is a person rather than an
organization.
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
String
Conditional
1 = Person
and Keys
and Keys
Full name of the agent
162
XML Element Name
Type
Usage
Description
<GovtID>
String
Optional
<GovtIDTC>
TypeCode
Conditional
OLI LU
GOVTIDTC
GovtID.
18 = Green Card US
<Person>
@id
Object
ID
Required
Optional
<FirstName>
String
Conditional
<MiddleName>
<LastName>
<Prefix>
String
String
String
Optional
Conditional
Optional
Details about the agent
and Keys
First name of the person. May not be
required when the transaction relies
on the
Producer.CarrierAppointment.Compan
yProducerID.
If parsed name is available use this, if
not use FullName.
Last name of the person. May not be
required when the transaction relies
on the
Producer.CarrierAppointment.Compan
yProducerID.
not use FullName.
'Mrs.', 'Ms.', 'Dr.', etc..
163
XML Element Name
<Suffix>
Type
String
Usage
Optional
Description
property.
<Title>
<Producer>
String
Object
Optional
Optional
<Certification>
String
Optional
<NIPRNumber>
String
Optional
Object
Optional
<CompanyProducerID> String
Optional
<CarrierCode>
Optional
String
An agent, agency, broker, broker
dealer or distributor
This captures the additional
information you have on a commission
earning party
Insurance specific designations (FLMI,
CLU, ChFC, CFP, etc.) for this
producer. Multiple designations are
separated by commas.
The Producers National Insurance
Producer Registry Number (or other
authorizing authorities id number).
The information for each appointment
for a producer. Defines the agent‟s
appointment information with this
carrier for this new business
transaction.
The company producer ID represents
the agent‟s appointment number with
the carrier for the proposed holding.
This code uniquely represents the
insurance carrier for which this carrier
appointment applies. The NAIC code
is recommended as the CarrierCode.
164
XML Element Name
Type
Usage
Description
5.43 <Party> Object for carrier
A Party Object representing an insurance carrier. Carrier parties on a new business transaction include
the carrier for the proposed and/or existing insurance. The Party Object for carrier is optional. See section
3.3.3 Identification of the Carrier for the Proposed Policy.
<FullName>Prudential Insurance Co</FullName>
<Organization>
</Organization>
<Carrier>
<CarrierCode>97195</CarrierCode>
</Carrier>
</Party>
<Party id>
ID
Required
<PartyTypeCode>
'Party Type'
TypeCode
Required
<FullName>
<Organization>
String
Object
Required
Required
<Carrier>
Object
String
Optional
Required
<CarrierCode>
OLI_LU_PART
Y
and Keys
The carrier is an organization.
2 = Organization
Full name of the carrier.
Though no properties of the
Organization are utilized, the
aggregate is required by the schema.
Detail about the insurance carrier
Uniquely represents the manufacturer
of the financial product, such as an
insurance company or fund manager.
The NAICCode is recommended.
If all you need is CarrierCode you can
use the CarrierCode tag that is
required in Policy, if you need
additional information then create a
Carrier Party object.
165
XML Element Name
Type
Usage
Description
5.44 <Party> Object for creditor on the collateral loan
Used to represent the information needed for the creditor on the collateral loan for business insurance.
<Party id="Party_Creditor1">
<FullName>Bank of America</FullName>
<Organization>
<OrgForm tc="0">Unknown</OrgForm>
</Organization>
</Party>
<Party id>
ID
Required
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
String
Conditionally
Required
<Person>
Object
<FirstName>
<MiddleName>
<LastName>
<Organization>
@id
String
String
String
Object
ID
and Keys
This party is an organization owner.
Conditionally
Required
Conditionally
Required
Optional
Conditionally
Required
Required
Optional
2 = Organization
and Keys
and Keys
Required if the creditor is an
organization.
Required if the creditor is a person
Required if the creditor is a person.
Required if the creditor is a person.
A Type of Party
166
XML Element Name
<OrgForm>
Type
TypeCode
OLI LU
ORGFORM
Usage
Required
Description
and Keys
Organization Form
recognized.
0 = Unknown
2 = Partnership
167
XML Element Name
Type
Usage
Description
5.45 <Party> Object for account owner
A party object on a new a business transaction represents the account owner of the bank account
associated with a Banking Object for funding the initial or inforce premiums. This particular party object is
optional on a new business transaction.
If the only information that is needed is the account holders full name, use the tag AcctHolderName on
Banking. If any other information on the account holder is needed, including the parsed name, then a Party
object must be created which can be referenced from Banking @AppliesToPartyID.

<Person>
<FirstName>Mary</FirstName>
<MiddleName>S</MiddleName>
<Suffix>I</Suffix>
</Person>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
OLI_LU_PART
Y
and Keys
and Keys
The account owner may be a person
or an organization.
<PartyKey>
String
Optional
<PartySysKey>
String
Optional
<FullName>
String
Optional
1 = Person
2 = Organization
and Keys
and Keys
Full name of the object or party.
168
XML Element Name
Type
Usage
Description
<Person>
Object
Conditional
@id
ID
Optional
<FirstName>
<MiddleName>
<LastName>
<Suffix>
String
String
String
String
Required
Optional
Required
Optional
A type of party. Required if the
account owner is an person rather
and Keys
property.
<Organization>
Object
Conditional
<Address>
Object
Optional
Required if the account owner is an
organization rather than an individual
person.
Maybe utilized for credit card address.
<Address> Object
169
XML Element Name
Type
Usage
Description
5.46 <Party> for Employer
This optional Party represents the employer of the proposed insured party. The Employer Object is related
to the proposed insured Party with the EmployerPartyID on the Employment Object.
<Party id="Primary_Insured_Employer_Party_1">
<FullName>ABC Corporation</FullName>
<Organization>
<OrgForm tc="23">Corporation</OrgForm>
</Organization>
<Address>
<AddressTypeCode tc="2">business</AddressTypeCode>
<Line1>2350 Corporate Park Drive</Line1>
<City>Herndon</City>
<AddressStateTC tc="55">Virginia</AddressStateTC>
<Zip>22101</Zip>
</Address>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
<FullName>
<Organization>
String
Object
Optional
Required
TypeCode
Required
<OrgForm>
OLI_LU_PART
Y
OLI LU
ORGFORM
and Keys
and Keys
2 = Organization
Full name of the employer.
An organization object is necessary
for a party with PartyTypeCode of 2.
Organization Form
recognized.
0 = Unknown
170
XML Element Name
Type
Usage
Description
2 = Partnership
16 = Trust
24 = Estate
<Address>
<AddressTypeCode>
Object
Optional
TypeCode
Required
OLI LU
ADTYPE
<Line1>
String
Required
<Line2>
String
Optional
<City>
String
Conditional
<AddressStateTC>
TypeCode
Required
OLI LU STATE
<Zip>
<AddressCountryTC>
String
Required
TypeCode Optional
An address pertaining to the party or
group.
<Address> Object
Address of the employer
2 =Business
27 = Headquarters
First line of the address
Should not include city, state, or zip
code.
Second line of the address
code.
City of the address
In some cases where a zip code
database is utilized, conditionally
required only if the Zip is not provided.
Provides a numeric integer value for
the address state.
Zip code, postal code, etc. (country
dependent)
This may include formatting
characters to accommodate all
countries. U.S. zip codes should be 5
digits, zip + 4 should be 9 digits, and
not include the separating hyphen
(i.e.111112222).
Country of residence for the party.
OLI LU
NATION
171
XML Element Name
Type
Usage
Description
1 = United States of America
172
XML Element Name
Type
Usage
Description
5.47 <Party> Payor for Person or Organization
The payor on a new business transaction is the individual or corporation that is expected to pay the
ongoing premiums. The Payor Party will exist only when the payor is not the same as an existing Party
such as the proposed insured or owner. The Payor is related to the proposed Holding with a Relation
Object and a RelationRoleCode of 31 (payer).
<Party id="Payor_Party_1">
<Person>
<MiddleName>S</MiddleName>
<Suffix>I</Suffix>
</Person>
<Organization/>
<Address>
<AddressTypeCode tc="2">Business</AddressTypeCode>
<Line1>2350 Corporate Park Drive</Line1>
<City>Herndon</City>
<AddressStateTC tc="55">Virginia</AddressStateTC>
<Zip>22101</Zip>
<AddressCountryTC tc="1">US</AddressCountryTC>
</Address>
</Party>
<Party id>
ID
Required
@DataRep
Attribute
Optional
<PartyTypeCode>
'Party Type'
TypeCode
Required
<FullName>
String
OLI_LU_PART
Y
Conditional
and Keys
and Keys
1 = Person
2 = Organization
Full name of the organization or
person.
%S is Suffix.
173
XML Element Name
Type
Usage
Description
@id
Object
ID
Conditional
Optional
<FirstName>
String
Conditional
Required if the payor is an individual
and Keys
Optional
Conditional
not use FullName.
Optional
not use FullName.
<Person>
<MiddleName>
<LastName>
<Suffix>
String
String
String
property.
<Organization>
Object
Conditional
<Address>
Object
Optional
TypeCode
Required
<AddressTypeCode>
OLI LU
ADTYPE
<Line1>
String
Required if the payor is an
organization
An address pertaining to the payor
Party.
<Address> Object
Type of address
Please see the ACORD Help file for a
Required
First line of the address
code.
<Line2>
<City>
<AddressStateTC>
String
String
TypeCode
OLI LU STATE
Optional
Required
Required
Second line of the address
code.
City of the address
Provides a numeric integer value for
the address state
174
XML Element Name
<Zip>
Type
String
Usage
Required
Description
Zip code, postal code, etc. (country
dependent)
This may include formatting
characters to accommodate all
countries. U.S. zip codes should be 5
digits, zip + 4 should be 9 digits, and
not include the separating hyphen
(i.e.111112222).
175
XML Element Name
Type
Usage
Description
5.48 <Payment> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/FinancialActivity/Payment
The Payment object is required for an initial payment, and may be a collection, but ordinarily would not be
unless several checks are involved in a financial activity.
Most commonly, there will be just one initial payment which would be represented by a single
FinancialActivity with a single Payment. Since carriers typically process initial payments separately and do
not reverse them as a group, multiple checks for the initial payment are not included in a single
FinancialActivity.
<PaymentForm tc="7">EFT</PaymentForm>
<PaymentAmt>100</PaymentAmt>
<SourceOfFundsTC tc="11">income</SourceOfFundsTC>
</Payment>
<Payment id>
ID
Optional
@BankHoldingID
IDREF
Optional
<PaymentKey>
PERSISTKE Optional
Y
<PaymentSysKey>
SYSKEY
Optional
<PaymentForm>
TypeCode
Conditional
OLI_LU_PAYM
ENTFORM
and Keys
For credit card payments and
electronic funds transfer, the bank
holding will include the account
information. Some carriers request
the account information in a separate
transaction for security purposes.
and Keys
and Keys
Physical form of payment
2 = Credit Card
5 = Certified Check
6 = Personal Check
10 = Corporate Check
176
XML Element Name
Type
Usage
Description
13 = Funds to Follow (1035
Exchange)
25 = Debit Card/Check Card
26 = Payment is made from another
Policy
Required on the initial payment when
FinancialActivity.FinActivityType = 7.
PaymentForm is optional on on-going
premium.
<CheckNo>
String
Optional
<CheckDescription>
String
Optional
<PaymentAmt>
Currency
Conditional
Individual check number, not including
the routing number or account
number.
Anything the payer wrote on the
check.
For initial premium it‟s the current
amount of payment.
For a 1035 Exchange, payment
amount reflects the expected cash
value to be exchanged.
<SourceOfFundsTC>
TypeCode
Optional
OLI_LU_SOUR
CEOF FUNDS
<SourceOfFundsDetails>
String
Optional
<PaymentMethod>
TypeCode
Conditional
OLI LU
PAYMETHOD
Required for all initial payments
except Cash On Delivery policies.
Indicates where the funds originated
for this Payment; indicates if from a
death benefit or 1035 exchange.
SourceOfFundsDetails is a string field
that provides additional information
about the Payment.
The business process by which
payment is made which influences
how the payment is billed. To express
it in the reverse, there are internal
business rules around each allowable
Payment Method that usually define
the acceptable or expected Payment
Forms.
For example, a Payment Method of
"Credit Card Billing" indicates that a
177
XML Element Name
Type
Usage
Description
credit card is billed for the payment. In
this example, one would expect
PaymentForm and PaymentMethod to
both indicate "Credit Card" and seem
redundant. However, if
PaymentMethod were "List Bill" the
PaymentForm could be any number of
suitable forms of payment as defined
by internal business logic.
PaymentMethod is optional for the
initial payment.
1 = No Billing
2 = Regular Billing
6 = Payroll Deduction
8 = Government Allotment
9 = Credit Card Billing
26 = Pre-authorized Check
<CheckDate>
Date
Optional
<Attachment>
Object
Optional
This does not necessarily reflect the
date the check was written. For
example, it could be post dated.
This contains a collection of
attachments. Each attachment could
contain any of the AttachmentTypes
defined.
178
XML Element Name
Type
Usage
Description
5.49 <Phone> Object
TXLife/TXLifeRequest/OLifE/Party/Phone
The Phone object provides the telephone information associated with a Party on the New business
application.
<Phone>
<PhoneTypeCode tc="1">Home</PhoneTypeCode>
<AreaCode>555</AreaCode>
<DialNumber>1234567</DialNumber>
<PrefPhone tc="1"/>
<BestTimeToCallFrom>15:00:00</BestTimeToCallFrom>
<BestTimeToCallTo>17:00:00Z</BestTimeToCallTo>
</Phone>
<Phone>
<PhoneTypeCode tc="2">Work</PhoneTypeCode>
<PrefPhone tc="0"/>
<Ext>1205</Ext>
</Phone>
<Phone id>
ID
Optional
<PhoneKey>
String
Optional
<PhoneSysKey>
String
Optional
<PhoneTypeCode>
'Phone Type'
TypeCode
Required
OLI_LU_PHON
ETYPE
and Keys
and Keys
and Keys
Type of phone
1 = Home
2 = Business
3 = Vacation
4 = Business Fax
6 = Marine
7 = Corporate Office
9 = Regional Office
11 = Temporary
12 = Mobile
13 = Pager (beeper)
14 = Modem/data line
179
XML Element Name
Type
Usage
Description
15 = Home Fax
16 = "General" voice number
unspecified as to location
26 = Primary Phone
27 = Secondary or Alternate Phone
<AreaCode>
<DialNumber>
<Ext>
String
String
String
Required
Required
Optional
<PrefPhone>
Boolean
0 = False
1 = True
Optional
<BestTimeToCallFrom>
<BestTimeToCallTo>
<BestDayToCall>
Time
Time
Object
Area code
Phone number
Extension of the phone number (if
any).
Preferred phone indicator
FALSE = meaning phone information
currently being provided is NOT
preferred
Optional
Optional
Optional
TRUE = meaning phone information
currently being provided IS preferred
This is optional for the primary insured
and not needed for the other roles.
Preference to be called at or after this
specific time. E.g. if best time to call is
between 9am and 5pm, this would
represent 9am. For schema purposes,
9am Eastern should appear in the
format 09:00:00-05:00.
Indicates the preference to be called
before this time. E.g. if best time to
call is between 9am and 5pm, this
would represent 5pm. For schema
purposes, 5pm Eastern should appear
in the format 17:00:00-05:00.
Client's preferred day of week to be
called, collected during apply process
180
XML Element Name
Type
Usage
Description
5.50 <Policy> Object for Proposed Policy
TXLife/TXLifeRequest/OLifE/Holding/Policy
The Policy object contains all the policy properties that are generic across insurance policy types.
The recommendation for ongoing premium is to model the mode, method, and amount in an Arrangement
object rather than in the associated properties and objects of Policy. Account information for credit cards
and electronic funds transfers will be modeled in a Banking object related to the Arrangement via
ArrSource or ArrDestination, rather than in a Banking object related to Policy or directly in the properties of
Policy.
<Policy CarrierPartyID="Party6_1" id="Policy1_1">
<PolNumber>AB12345678</PolNumber>
<ProductType tc="2">Term</ProductType>
<PlanName>SuperTerm 15Yr Level Term</PlanName>
<ShortName>ST 15</ShortName>
<PolicyStatus tc="12">Proposed</PolicyStatus>
<IssueNation tc=”1”>U.S.</IssueNation>
<Jurisdiction tc=”1”>Alabama</Jurisdiction>
<PaymentDraftDay>15</PaymentDraftDay>
<Life>…
</Life>
<ApplicationInfo>…
</ApplicationInfo>
<RequirementInfo>…
</RequirementInfo>
<RequirementInfo AppliesToPartyID="Party1_1">…
</RequirementInfo>
<Arrangement>…
</Arrangement>
<FinancialActivity>…
</Policy>
<Policy id>
ID
Optional
<@CarrierPartyID>
ID
Conditional
and Keys
When Policy - Company issuing the
Product. The party that is the carrier
for this policy.
Required when specific carrier
information modeled in a Carrier
Object is needed.
Note: This is the only accepted
method to relate a policy to a carrier.
181
XML Element Name
Type
Usage
<PolNumber>
String
<LineOfBusiness>
'Line of Business'
TypeCode Required
<ProductType>
'Policy Product Type'
TypeCode Required
<ProductCode>
String
Optional
OLI_LU_LIN
EBUS
OLI_LU_PO
LPROD
String
Conditional
Optional
Description
A Relation Object is not used.
Policy number: This is generally
assigned by the Carrier except in the
case of field issued contracts.
1 = Life
Product type
2 = Term
3 = Universal Life
4 = Variable Universal Life
5 = Indexed Universal Life
Insurance Carriers‟ internal code for
the product.
Required if PlanName is not provided
ProductVersionCode defines the
version of a product, particularly when
a company uses the same
ProductCode across versions.
Business users require the ability to
vary product information without
creating a new product codes. The
varied information can include, but is
not limited to, product information
such as fees related to expenses,
surrender charges or premium loads.
Version also enables members to
define versions of bundled products.
This enhanced functionality allows the
user to fulfill their requirements for
multiple versions of an insurance
product without creating multiple
product codes.
<CarrierCode>
String
Required
<PlanName>
String
Conditional
versioned, but the same ProductCode
is used across versions.
This is the code used to represent the
carrier for this policy. Recommended
Usage: Carriers‟ NAIC Number.
Full name of plan. This is the
complete, official, and/or legal name
used for this policy/coverage/option.
182
XML Element Name
Type
Usage
<ShortName>
<MarketingName>
String
String
Optional
Optional
<PolicyStatus>
TypeCode Required
OLI_LU_PO
LSTAT
Description
Required if ProductCode is not
provided
On Policy, MarketingName indicates
the version marketing name
associated with a product.
MarketingName is the carriers
marketing name associated with the
ProductVersionCode.
Type code for the status of the
contract
12 = Proposed
<IssueNation>
TypeCode Optional
OLI_LU_NA
TION
For a detailed description of
PolicyStatus and StatusReasons, refer
to Appendix C - New Business Policy
Status Transitions.
Nation policy was issued in and where
it will be delivered.
1 = USA
<Jurisdiction>
TypeCode Optional
OLI_LU_ST
ATE
Jurisdiction of a Policy - Since this is a
new application, the
ApplicationJurisdiction on
ApplicationInfo and the residence
state of the primary proposed insured
are expected to represent the same
state as the Policy Jurisdiction.
<BillNumber>
<ReplacementType>
String
Optional
TypeCode Optional
OLI_LU_RE
PLACETYP
E
The unique billing reference number to
a block of business.
Used in List Bill, Government
Allotment, and for family groups where
payments are grouped together.
replacement when the applied for
policy is replacing an existing contract.
183
XML Element Name
Type
Usage
Description
The proposed policy
ReplacementType reflects in
aggregate the ReplacementType(s) of
all existing contracts that are being
replaced.
3 = External
4 = Internal & External
11 = Both internal and intra-statutory
<CommissionOptionSelected>
TypeCode Optional
OLI_LU_CO
MMOPTION
current ACORD spec. For additional
codes and directions for usage, please
see the current spec.
The code for showing which
commission compensation plan the
original writing agents choose to be
compensated by.
1 = Full First Year Commission rate
with no Persistency or Expense
Allowance payments from this policy.
2 = Reduced First Year Commission
rate plus the policy counting for
Persistency payment
rate plus the policy is included in the
Expense Allowance plan.
rate with no Persistency or Expense
allowance payments included.
5 = Heaped (Levelized) Commission
Option
6 = Full first year commission (no
trails)
7 = Trails Only (High Trail)
8 = Level (cash flow and trails)
9 = No Commissions (i.e. wrap)
10 = Reduced front end commission
with trails
184
XML Element Name
Type
Usage
Description
<AnnualPaymentAmt>
<SpecialHandling>
Currency Optional
TypeCode Optional
OLI_LU_SP
ECIALHAND
LING
<JuvenilePolicyInd>
Boolean Optional
0 = False
1 = True
<ReplacedPolicyPhysicalStatus> TypeCode Optional
OLI_LU_PO
LICYREPLP
HYSTAT
Annualized payment/premium amount
AnnualPaymentAmt on Policy does
include all coverages.
Indicates the type of special handling
required for this policy.
Policy which is issued on the life of a
child. The policy may be owned by the
child or, in most cases, by an adult. If
the policy is owned by a child no rights
could be exercised while he/she is a
minor without the appropriate
guardianship papers/court order.
The RestrictionCode must be used in
conjunction with the JuvenilePolicyInd
and it should be set to '3' for 'This
Contract is on a Juvenile and is
restricted‟. If the policy is owned by an
adult, it is not considered restricted as
the adult can make changes to the
policy.
The physical status or state of a
contract when it is a replacement
This indicates who/where the actual
policy contract is, or whether it‟s
lost/stolen.
May be used to indicate when a
replacement policy is lost/stolen, or
given to an agent/distributor to send to
carrier for exchange/replacement.
5 = Lost, Stolen or otherwise
Destroyed
6 = Attached
7 = Policy Included with Physical
Application Package
<Life>
Object
Required
Please reference the Life Object
185
XML Element Name
Type
Usage
<ApplicationInfo>
Object
Required
<RequirementInfo>
Object
Optional Repeating
<Arrangement>
Object
Required Repeating
<FinancialActivity>
Object
Required Repeating
Description
section.
<Life> Object
Please reference the ApplicationInfo
Object section.
<ApplicationInfo> Object
Please reference the Requirement
Info Object section.
<RequirementInfo> Object
Please reference the Arrangement
Object section.
<Arrangement> Object
At least one Arrangement is required
to represent ongoing premium.
Please reference the FinancialActivity
Object section.
<FinancialActivity> Object for initial
payment
FinancialActivity instances may be
included to represent initial payments.
186
XML Element Name
Type
Usage
Description
5.51 <PrescriptionDrug> Object
TXLife/TXLifeRequest/OLifE/Party/Risk/PrescriptionDrug
When used on the 103 New Business Transaction, PrescriptionDrug is used to capture the personal drug
information admitted to by the proposed insured during the application completion process.
<PrescriptionDrug id=”PrescriptionDrug_1”>
<Applicability tc=”1”>Applies</Applicability>
<PrescriptionDrugType tc=”0”>Unknown</PrescriptionDrugType
<PrescriptionLabel>Simvastatin</PrescriptionLabel
<PrescriptionDosageUnit tc=”1”>Milligrams</PrescriptionDosageUnit>
<PrescriptionDosageStrength>20</PrescriptionDosageStrength>
<DrugSource tc=”1”>Prescription</DrugSource>
</PrescriptionDrug>
<PrescriptionDrug id>
ID
Optional
<PrescriptionDrugKey>
String
Optional
<PrescriptionDrugSysKey>
String
Optional
<Applicability>
TypeCode
Optional
OLI_LU_APPLI
CABILITY
and Keys
and Keys
and Keys
0 = Unknown
1 = Applies
2 = Does not apply
187
XML Element Name
Type
Usage
Description
<PrescriptionDrugType>
TypeCode
Required
OLI_LU_DRU
GTYPE
Type of code used to identify the
pharmaceutical.
1 = Universal Product Code
2 = Health Related Item
3 = National Drug Code
4 = Universal Product Number
5 =Department of Defense
6 = Drug Use Review
7 = Drug Use Professional Pharmacy
Service
8 = National Pharmaceutical Product
Interface Code
9 = Drug Identification Number
<PrescriptionLabel>
<PrescriptionDosageUnit>
String
TypeCode
Required
Optional
OLI_LU_PRES
CDOSUNIT
In the most likely scenario, when drug
information is being captured to
complete the application, this
information will not be known.
Name of the pharmaceutical
Indicates the units to measure the
strength of the pharmaceutical (e.g.
milligrams)
1 = Milligrams
<PrescriptionDosageStrength>
<PrescriptionDosageForm>
Integer
TypeCode
OLI_LU_PRES
CDOSEFORM
Optional
Optional
Prescription dosage strength
Indicates the form in which the
pharmaceutical is dispensed (e.g.
188
XML Element Name
Type
Usage
Description
tablet)
<DrugSource>
TypeCode
Optional
OLI_LU_DRU
GSOURCE
<PrescriptionFill>
Object
1 = Tablet
How was the drug obtained
1 = Prescription
2 = Over the Counter
3 = Self-Medicated
4 = Illegally
Optional
Repeating
A prescription fill object
189
XML Element Name
Type
Usage
Description
5.52 <Relation> Object for contract level (Holding to Holding for Replacements/Exchanges)
TXLife/TXLifeRequest/OLifE/Relation
The Relation Object defines a relationship between two top-level objects. In a new business transaction,
common Relation Objects describe the relationships between the Holding and another Holding. Each
Relation describes an originating Object and a related Object. The two objects are each defined by an ID
reference and its associated top-level Object type. A RelationRoleCode defines how the related Object is
related to the Originating Object. For example, the Replaced By relation role code (tc=64) is used when
“the Related Object is being replaced by the contract being applied for.”
<Relation id="Relation_1" OriginatingObjectID="Proposed_Holding_1"
<RelatedObjectID="Holding_1">
<OriginatingObjectType tc="4">Holding</OriginatingObjectType>
<RelatedObjectType tc="4">Holding</RelatedObjectType>
<RelationRoleCode tc="64">ReplacedBy</RelationRoleCode>
</Relation>
<Relation RelatedObjectID="Holding_2" OriginatingObjectID="Holding2" id="Relation2_1">
<RelatedObjectType tc="4">Holding</RelatedObjectType>
<RelationRoleCode tc="68">ExchangedFor</RelationRoleCode>
</Relation>
<Relation id>
ID
Required
<OriginatingObjectID>
IDREF
Required
<RelatedObjectID>
IDREF
Required
<OriginatingObjectType>
'Object Type'
TypeCode Required
<RelatedObjectType>
'Object Type'
TypeCode Required
<RelationRoleCode>
'RelationRoleCode'
OLI LU
OBJECTTYP
E
OLI LU
OBJECTTYP
E
TypeCode Required
OLI LU REL
and Keys
Unique identifier of originating toplevel object.
Unique identifier of related top-level
object.
Type of top-level object of originator.
4 = Holding
The type of object you are relating the
Originating Object to.
4 = Holding
Role Code of Relationship. This type
code represents the answer to the
following question “What is the
relationship of the Related Object to
the Originating Object?”
64 = Replaced By
68 = Exchanged For
190
XML Element Name
Type
Usage
Description
5.53 <Relation> Object for contract level (Holding to Party)
common Relation Objects describe the relationships between the Holdings and Parties (proposed insured
to proposed holding, owner to proposed holding, etc.) Each Relation describes an originating Object and a
related Object. The two objects are each defined by an ID reference and its associated top-level Object
type (Party, Holding, etc.). A RelationRoleCode defines how the related Object is related to the Originating
Object. For example, the owner relation role code (tc=8) is used when “the related owner Party is the
owner of the originating Holding.”
Note the inclusion of BeneficiaryDesignation on this Relation Object. This Relation Object is where
additional beneficiary information would be included, such as BeneficaryShareMethod, which is an
exception to the rule that the LifeParticipant Object holds role specific information. See the 2 appendices,
How to Model Roles and Sample XML for Beneficiaries, for further information.
Appendix A – How to Model roles
APPENDIX B – Sample XML for beneficiary roles
<Relation id="Primary_Insured_1_to_Policy" OriginatingObjectID="Proposed_Holding_1"
<RelatedObjectID="Primary_Insured_Party_1">
<RelatedObjectType tc="6">Party</RelatedObjectType>
<RelationRoleCode tc="32">Primary Insured</RelationRoleCode>
</Relation>
<Relation RelatedObjectID="Party2_1" OriginatingObjectID="Holding1" id="Relation2_1">
<RelationRoleCode tc="34">Primary Beneficiary</RelationRoleCode>
<InterestPercent>70</InterestPercent>
<BeneficiaryDesignation tc="1">Named</BeneficiaryDesignation>
</Relation>
<Relation id>
ID
Required
IDREF
Required
<RelatedObjectID>
IDREF
Required
'Object Type'
TypeCode Required
<RelatedObjectType>
'Object Type'
TypeCode Required
OLI LU
OBJECTTYP
E
OLI LU
OBJECTTYP
E
and Keys
object.
4 = Holding
191
XML Element Name
<RelationRoleCode>
'RelationRoleCode'
Type
Usage
TypeCode Required
OLI LU REL
Description
6 = Party
Role Code of Relationship. This type
code represents the answer to the
following question “What is the
relationship of the Related Object to
the Originating Object?”
8 = Owner
31 = Payor
32 = Insured
33 = Coverage Insured
34 = Beneficiary
36 = Contingent Beneficiary
37 = Primary Writing Agent
48 = General Agent
52 = Additional Writing Agent
189 = Joint Insured
<InterestPercent>
<BeneficiaryDesignation>
Percent
Conditional
OLI LU
BENEDESIG
NATION
Percent of interest related object has
in contract - Use this for beneficiary
Distribution and commission splits
Required for beneficiary and agent
relationships.
BeneficiaryDesignation is used to
identify whether this beneficiary is
specifically "named" or if a beneficiary
will be identified as a class or group of
beneficiaries without specifically
naming the individual(s) or
organizations. For example, a named
beneficiary may be "Joe Smith" versus
an unnamed beneficiary of "All natural
children of insured."
If a beneficiary is named, information
about that person or organization is
represented in Party.
Unnamed beneficiaries are not further
qualified other than
BeneficiaryDesignation; unnamed
beneficiaries are modeled using
Relation RoleCode = Beneficiary and
192
XML Element Name
Type
Usage
Description
Relation.BeneficiaryDesignation but
does not reference a Party.
designation is 'Named' (tc=1), PartyID
(if on Participant or LifeParticipant) or
RelatedObjectId (if on Relation) and
unnamed.
designation is 'Named', PartyID and
unnamed.
Required when the RelationRoleCode
represents a beneficiary or contingent
beneficiary.
Type Code Translation:
1 = Named
2 = Estate
13 = Children of Insured
193
XML Element Name
Type
Usage
Description
5.54 <Relation> Object for contract level (Party to Party)
common Relation Objects describe the relationships between parties (owner to proposed insured,
proposed insured to beneficiary, etc.). Each Relation describes an originating Object and a related Object.
The two objects are each defined by an ID reference and its associated top-level Object type (Party,
Holding, etc.). A RelationRoleCode defines how the related Object is related to the Originating Object. For
example, the owner relation role code (tc=8) is used when “the related owner Party is the owner of the
originating Holding.” In business insurance relates the other officers to the organization.
<Relation RelatedObjectID="Party2_1" OriginatingObjectID="Party1_1" id="Relation3_1">
<OriginatingObjectType tc="6">Party</OriginatingObjectType>
<RelationRoleCode tc="2">Child</RelationRoleCode>
<RelationDescription tc="5">Son</RelationDescription>
</Relation>
<Relation id>
ID
Required
IDREF
Required
<RelatedObjectID>
IDREF
Conditional
'Object Type'
TypeCode Required
<RelatedObjectType>
'Object Type'
TypeCode Required
<RelationRoleCode>
'RelationRoleCode'
OLI LU
OBJECTTYP
E
OLI LU
OBJECTTYP
E
TypeCode Required
OLI LU REL
and Keys
object.
Required for all party to party
relationships except when it
represents the relationship of an
unnamed beneficiary.
6 = Party
6 = Party
Role Code of Relationship. What is
the "relationship" of the Originating
Object to the Related Object.
1 = Spouse
2 = Child
194
XML Element Name
Type
Usage
Description
3 = Parent
4 = Sibling
210 = Designated/Responsible
Officer/Director (for business
insurance)
<RelationDescription>
'Relation Description'
TypeCode Optional
OLI LU
RELDESC
Description code used to further
define the role of the relationship.
Used when gender specific
information is needed.
1 = Husband
2 = Wife
3 = Father
4 = Mother
5 = Son
6 = Daughter
7 = Brother
8 = Sister
<InterestPercent>
Percent
Conditional
current spec. for additional codes
Percent of interest related object has
in contract - Use this for beneficiary
Distribution and commission splits
For business insurance, used to
define the percentage of ownership for
the primary proposed insured.
<Duration>
Integer
Optional
Required for beneficiary and agent
relationships.
Duration in years based on current
point in time.
When used on Relation, it provides an
interval of time or duration that the
relationship is effective for.
195
XML Element Name
Type
Usage
Description
5.55 <RequirementInfo> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/RequirementInfo
This object is used during the new business process for a policy and contains any requirements including
underwriting and home office fulfillment requirements for issuing a policy. The most notable example used
today on a NBfL transaction is the status of the MIB Authorization.
<RequirementInfo AppliesToPartyID="Party1_1">
<ReqCode tc="23">MIB Authorization</ReqCode>
<ReqStatus tc="11">Completed</ReqStatus>
<StatusEvent>
<StatusEventCode tc="114">Signatures Received</StatusEventCode>
</StatusEvent>
</RequirementInfo>
<Requirement id>
ID
Conditional
<AppliesToPartyID>
IDREF
Required
<ReqCode>
'Requirement Code'
TypeCode Required
OLI_LU_RE
QCODE
Refer to the ACORD Help File for the
Default:
OLI_UNKNO
WN
<FormVersion>
<ReqStatus>
Lookup Table String=
'Requirement Status'
String
Optional
TypeCode Required
OLI_LU_RE
QSTAT
Default:
and Keys
Required when there is a
FormInstance associated with the
RequirementInfo.
This is the Party ID of the party for
whom this requirement is (e.g. the
primary insured).
Code specifying the policy issue
requirement.
On RequirementInfo, this is the
version of the form associated with the
FormNo (also on RequirementInfo).
This is typically assigned by the
creator of the form and preprinted on
the form. This is similar to
FormVersion on FormInstance.
Note: On some applications, the
version is part of the form number.
This field would only be used if it is
separate.
Status of this underwriting
requirement.
196
XML Element Name
Type
Usage
OLI_UNKNO
WN
<ResponsiblePartyType>
'Responsible Party Type'
TypeCode Optional
OLI_LU_RE
SPARTY
Default:
OLI_UNKNO
WN
Description
1 = Pending
2 = Submitted
3 = Waived
4 = Outstanding
5 = Approved
6 = Declined
7 = Received
8 = Cancelled
11 = Completed
This indicates who is responsible for
following up and ensuring that this
item gets fulfilled. If the requirement is
not already ordered, this is the party
type of the party responsible for
ordering the requirement.
1 = Agent
3 = Field Office
5 = Home Office
<LanguageInterpreterNeeded> Boolean Optional
0 = False
1 = True
<InterpretedLanguage>
TypeCode Optional
OLI LU
CLIENTLAN
GUAGES
On RequirementInfo, this property is
used to indicate that the parent
requirement (for example, a teleinterview) requires a language
interpreter. The language that must be
translated TO (when known) is
specified in InterpretedLanguage.
On RequirementInfo, this property is
used when
LanguageInterpreterNeeded is set to
true. The "translated from" language is
assumed to be the language in which
the application is produced or printed.
This is specified in
ApplicationInfo.PrefLanguage. If
ApplicationInfo.PrefLanguage is not
provided, the "translated from"
language is defaulted to English.
197
XML Element Name
<StatusEvent>
Type
Object
Usage
Optional
<StatusEventCode> TypeCode Optional
OLI LU
STATEVENT
CODE
<Attachment>
Object
Description
Requirement Event Collection Object
This object is used during a specific
process depending on the parent.
Identifies the action or event
114 = To indicate signatures on
authorization form were completed.
Optional
Attachment that is directly related to
this requirement. For example, an
image of the EFT authorization may
be attached.
198
XML Element Name
Type
Usage
Description
5.56 <Risk> Object
TXLife/TXLifeRequest/OLifE/Party/Risk
This contains the information that is captured on an application to help an insurance company determine
risk associated with insuring an applicant.
<Risk>
<ExistingInsuranceInd tc="1">true</ExistingInsuranceInd>
<RejectionInd tc="1">true</RejectionInd>
<RejectionReason>Declined for health insurance in 2002 due to exposure to bedrock dust</RejectionReason>
<BankruptcyInd tc="1">True</BankruptcyInd>
<RecentHospitalizationInd tc="0">False</RecentHospitalizationInd>
<SeriousIllnessInd tc="0">False</SeriousIllnessInd>
<TobaccoInd tc="1">true</TobaccoInd>
<CrimeDescription>Misdemeanor</CrimeDescription>
</CriminalConviction>
<SubstanceUsage>
<TobaccoType tc="1">Cigarettes</TobaccoType>
<SubstanceEndDate>2006-01-01</SubstanceEndDate>
</SubstanceUsage>
<SubstanceUsage>
<TobaccoType tc="8"/>
</SubstanceUsage>
<LifeStyleActivity>
<LifeStyleActivityType tc="29">Foreign Travel</LifeStyleActivityType>
<ActivityFrequencyMode tc="4">Per year</ActivityFrequencyMode>
<ActivityFrequency>1</ActivityFrequency>
<ActivityDuration>3</ActivityDuration>
<DurationUnitMeasure tc="69">Weeks</DurationUnitMeasure>
<ForeignTravel>
<PleasureTravelInd tc="1">True</PleasureTravelInd>
<TravelCountry tc="86">China</TravelCountry>
<DateLastTrip>2008-06-20</DateLastTrip>
</ForeignTravel>
</LifeStyleActivity>
<Violation>
<ViolationType tc="32">Unspecified Moving Violation</ViolationType>
<ViolationDescription>License suspended 6 months for speeding - 2nd offense</ViolationDescription>
</Violation>
<HHFamilyInsurance PartyID="Party_12">
<RoleCodeDesc tc="3">Father</RoleCodeDesc>
<AmtOfIns>200000</AmtOfIns>
<AppPendingInd tc="1">True</AppPendingInd>
<LineOfBusiness tc="1">Life Insurance</LineOfBusiness>
<RoleCode tc="3">Parent</RoleCode>
</HHFamilyInsurance>
<HHFamilyInsurance PartyID="Party_13">
<RoleCodeDesc tc="7">Brother</RoleCodeDesc>
199
XML Element Name
Type
Usage
Description
<AmtOfIns>200000</AmtOfIns>
<AppPendingInd tc="0">False</AppPendingInd>
<RoleCode tc="4">Sibling</RoleCode>
</HHFamilyInsurance>
<SubstanceUsage/>
</Risk>
<Risk id>
ID
Optional
@LastPhysicianVisitID
IDREF
Optional
<AutoViolationPoints>
Integer
<AutoViolationPointsAsOfDate> Date
<AutoLicenseSuspension>
Boolean
0 = False
1 = True
<AutoLicenseReinstatementDate Date
>
Optional
Optional
Optional
Optional
<KnownFamilyHistoryInd>
Boolean Optional
0 = False
1 = True
<ExistingInsuranceInd>
Boolean Optional
0 = False
1 = True
Boolean Optional
0 = False
1 = True
<ReplacementInd>
and Keys
The risk information associated with
insuring a party. The
LastPhysicianVisitID will reference an
object also under the same Risk
aggregate. This will be either
MedicalCondition, MedicalTreatment,
MedicalPrevention, MedicalExam or
SubstanceUsage.
Number of points received.
Date reflecting points information.
Has this person's auto license ever
been suspended or revoked? TRUE if
it has been suspended or revoked.
In the event the license was
suspended or revoked, this will be the
date that it was most recently
reinstated. If person‟s license is
currently suspended, this date should
not be valued.
Is family history known? For instance,
this would be used to indicate if a
person was adopted and did not know
his family history. TRUE if family
history is known, FALSE if not.
This is used to communicate the
applicant‟s response to the Existing
Insurance Question.
This is used to communicate the
applicant‟s response to a
Replacement Question.
Indicates whether policy is replacing
existing insurance.
The value in this tag should not be
relied upon to determine if there is
replacement data in this message
stream.
200
XML Element Name
<RejectionInd>
Type
Usage
<RejectionCompanyName>
Boolean Optional
0 = False
1 = True
String
Optional
<RejectionLineOfBusiness>
TypeCode Optional
OLI_LU_LIN
EBUS
Description
For the agent‟s response, see
ApplicationInfo.
Has this person ever been rejected for
life or health insurance before? TRUE
if rejected, FALSE if not.
If person has been rejected for
insurance, this is the (most recent)
company that rejected him/her.
The Line Of Business of the insurance
that was most recently rejected.
1 = Life
2 = Annuity
4 = Health Insurance
5 = Long Term Care
7 = Critical Illness
8 = Property and Casualty
9 = Medicare Supplement
<RejectionReason>
String
Optional
<DateLastRejected>
Date
Optional
<BankruptcyInd>
Boolean Optional
0 = False
1 = True
<RecentHospitalizationInd>
Boolean Optional
0 = False
1 = True
<SeriousIllnessInd>
Boolean Optional
0 = False
1 = True
The reason for the rejection, if person
was rejected (most recently) for
insurance.
Most recent date person was rejected
for insurance.
True indicates Party has filed for
bankruptcy or had liens or judgments
filed against them. False indicates that
the Party has neither filed for
bankruptcy nor had liens or judgments
filed against them.
TRUE indicates the person reported a
recent hospitalization. Time period
and exact wording vary by carrier.
Commonly used to qualify for
temporary life insurance.
TRUE indicates the person reported a
serious illness. Specific illness, time
period and exact wording vary by
carrier definitions.
Commonly used to qualify for
201
XML Element Name
Type
Usage
Description
temporary life insurance.
<TobaccoInd>
Boolean Optional
0 = False
1 = True
<FundingDisclosureInd>
Boolean Optional
0 = False
1 = True
Currency Optional
<AnyOtherImpairmentsInd>
Boolean Optional
0 = False
1 = True
<ChildExpectedInd>
Boolean Optional
0 = False
1 = True
<Applicability>
Object
Optional Repeating
TypeCode Optional
OLI_LU_AP
PLICABILIT
Y
Prior or Current tobacco user
True indicates that the party ever used
or is currently using tobacco or any
other product that contained nicotine.
SubstanceUse Object contains more
details about tobacco usage.
TobaccoInd is used in combination
with SubstanceEndDate to determine
previous tobacco usage.
On Risk, TRUE signifies that the
CLIENT has indicated, in response to
a question, that funding is coming all
or in part from a replacement. FALSE
signifies no such disclosure was made
by the CLIENT.
the individual.
Indicates if there is any other
impairment(s) or medical conditions
other than those specifically listed in
the Risk object.
A Dependent Child is Expected
As governed by carrier rule, when
true, the party is expecting a child that
may be considered eligible for
additional coverage. For example, this
indicator may be true if the insured
were pregnant or the insured's wife
were pregnant.
This is used for an as yet unnamed
child on a child rider, not necessarily
to be used in calculating the mortality
of a pregnant proposed insured.
Information about a party's criminal
conviction record.
202
XML Element Name
Type
Usage
Description
0 = Unknown
1 = Applies
2 = Does not apply
<CrimeType>
TypeCode Optional
OLI_LU_CRI
METYPE
<CrimeDescription>
<ConvictionDate>
<ConvictionCountry>
String
Optional
Date
Optional
TypeCode Optional
Type of crime committed.
Detailed description of the crime.
Date crime conviction occurred
Country of conviction
OLI_LU_NA
TION
<ConvictionJurisdiction TypeCode Optional
OLI_LU_ST
>
ATE
<ProbationInd>
<ProbationEndDate>
Boolean Optional
0 = False
1 = True
Date
Optional
<ChargeCategory>
TypeCode Optional
OLI_LU_CH
ARGECATE
GORY
State/province of conviction
Is person currently on probation?
TRUE if on probation, FALSE if not.
If person is on probation; this is the
date probation is expected to end.
Categories of criminal or other
violation charges.
1 = Felony
2 = Misdemeanor
203
XML Element Name
Type
Usage
<ProceedingOutcome> TypeCode Optional
OLI_LU_
PROCEEDI
NGOUTCO
ME
<CriminalSentenceDes String
c>
<SubstanceUsage>
Object
<Applicability>
Will indicate what the court findings
are with respect to the charge(s)
1 = Guilty
2 = Not Guilty
3 = Dismissed
4 = Pending
Optional
Optional Repeating
TypeCode Optional
OLI_LU_AP
PLICABILIT
Y
Description
Criminal sentence applied by the
court.
Information about a party's usage of
substances.
0 = Unknown
1 = Applies
2 = Does not apply
204
XML Element Name
Type
Usage
Description
<SubstanceType>
TypeCode Optional
OLI LU
SUBSTANC
ETYPE
<TobaccoType>
TypeCode Optional
OLI LU
TOBACCOT
YPE
<SubstanceDesc>
String
Optional
<SubstanceStartDate> Date
<SubstanceEndDate> Date
<SubstanceLastUseDat Date
e>
Optional
Optional
Optional
<SubstanceDuration>
Optional
Integer
<DurationUnitMeasure> TypeCode Conditional
OLI_LU_ME
ASUNITS
Type of substance taken and in use
On SubstanceUsage, either
SubstanceType or TobaccoType
should be used but not both in the
same instance.
Indicates the type(s) of tobacco used
by the client.
On SubstanceUsage, either
SubstanceType or TobaccoType
should be used but not both in the
same instance.
On SubstanceUsage, this would be
the actual drug or alcohol type used
when SubstanceType is specified.
This property can be used to specify
details when TobaccoType is used
and set to Other.
Date use started
Date use ended
Date client reports as the last date the
substance was used.
On SubstanceUsage, this is distinct
from SubstanceEndDate. MUST NOT
be valued. This property only reflects
the date that the client reported last
using the substance, it DOES NOT
IMPLY that usage has ceased. If the
client has positively indicated
substance usage has ceased, then
use SubstanceEndDate instead.
The duration of time that the
substance was used in unit
measurements.
If SubstanceDuration is used,
DurationUnitMeasure should be
present.
Required if SubstanceDuration is used
205
XML Element Name
Type
Usage
<MedicalCondition>
Object
Optional
Repeating
<MedicalTreatment>
Object
Optional
Repeating
<PrescriptionDrug>
Object
<LifeStyleActivity>
Object
Optional
Repeating
Optional
Repeating
<Applicability>
TypeCode Optional
OLI_LU_AP
PLICABILIT
Y
Description
Information about a party's medical
conditions.
7.21 <MedicalCondition> Object
about a person's medical treatments,
but the presence in and by itself does
not denote which medical condition
the treatment applies to.
about a person's medical treatments
as they pertain to a defined medical
condition.
A prescription drug object
<PrescriptionDrug> Object
Information about a party's lifestyle
activities.
This section captures details
surrounding the activities a party
engages in that may be considered
risky by insurance companies.
0 = Unknown
1 = Applies
2 = Does not apply
206
XML Element Name
Type
Usage
Description
<LifeStyleActivityType>
TypeCode Required
OLI LU
LIFEACTIVI
TYTYPE
1 = Aviation
2 = Military
29 = Foreign Travel
<ActivityDesc>
<ActivityFrequency>
String
Integer
Optional
Optional
<ActivityCountTotal>
Integer
Optional
<ActivityCountLastYear> Integer
<ActivityCountNextYear> Integer
Type of the activity engaged in
Optional
Optional
Activity description
Frequency activity engaged in, based
on period.
The total number of times the activity
has been engaged in.
For AviationExp, this would be the
total solo flight hours.
For UnderwaterDivingExp, this would
be the total number of dives.
The number of times the activity was
engaged in during the last 12 months.
For AviationExp, the number of solo
flight hours in the last 12 months. For
UnderwaterDivingExp, the number of
dives in the last 12 months.
The number of times the activity is
expected to be engaged in during the
next 12 months.
For AviationExp, the expected number
of solo flying hours. For
UnderwaterDivingExp, the number of
dives anticipated in the next 12
months.
<ActivityDuration>
Integer
Optional
Length of activity expressed in
appropriate unit
Used in conjunction with
207
XML Element Name
Type
Usage
<DurationUnitMeasure> TypeCode Optional
OLI LU
MEASUNITS
<ForeignTravel>
Object
Optional
<BusinessTravelInd> Boolean Optional
0 = False
1 = True
<PleasureTravelInd> Boolean Optional
0 = False
1 = True
<TravelCountry>
TypeCode Optional
OLI LU
NATION
<TravelLocation>
String
Optional
<DateLastTrip>
Date
Optional
Object
Optional Repeating
<Violation>
<Applicability>
TypeCode Optional
OLI_LU_AP
PLICABILIT
Y
Description
DurationUnitMeasure to denote the
specific length of an activity
Unit measurement defining duration
Information about a party's foreign
travel experience.
Do I travel internationally for
business? TRUE if I do, FALSE if not.
Do I travel internationally for
business? TRUE if I do, FALSE if not.
Country you plan to visit most or have
visited most.
Freeform field that lets you enter city
and/or state where a person plans to
travel to most or has traveled most.
Date of last trip (Due to the lack of any
other date property in this object, this
element is often used to represent the
date of future travel as well.)
On Risk, the Violation object captures
information about motor vehicle and
boating moving violations.
Alternatively, to capture information
related to violations for life style
activities such as aviation use the
LifeStyleViolation object.
208
XML Element Name
Type
Usage
Description
0 = Unknown
1 = Applies
2 = Does not apply
<ViolationType>
OLI LU
VIOLATION
TYPE
<ViolationDescription> String
Type of violation
Required if the ViolationDescription is
not provided
Conditional
Type of violation
Required if ViolationType is not
provided
<ViolationDate>
Date
Optional
<ViolationJurisdiction> TypeCode Optional
OLI_LU_ST
ATE
<ChargeCategory>
TypeCode Optional
OLI_LU_CH
ARGECATE
GORY
Please see the ACORD Help file for a
list of type codes.
Date violation occurred
State/province where violation was
committed.
Categories of criminal or other
violation charges.
1 = Felony
2 = Misdemeanor
209
XML Element Name
Type
Usage
<ProceedingOutcome> TypeCode Optional
OLI_LU_
PROCEEDI
NGOUTCO
ME
<CriminalSentenceDes String
c>
<FamilyIllness>
Object
Will indicate what the court findings
are with respect to the charge(s)
1 = Guilty
2 = Not Guilty
3 = Dismissed
4 = Pending
Optional
Optional Repeating
<FullName>
String
<DateOfOnset>
<Diagnosis>
Date
Optional
TypeCode Optional
Optional
OLI LU
MEDCOND
<AgeAtDeath>
Integer
Optional
<AgeIfLiving>
Integer
Optional
<DiagnosisDesc>
String
Optional
<RelationRoleCode>
TypeCode Optional
OLI LU
REL
Description
Criminal sentence applied by the
court.
Information about a party's family
illness history.
This captures a full name for a party in
whatever is the agreed upon format
and/or in which it has been captured.
On some applications, questions are
asked about the health of specific
members of the applicant's family. In
this situation, on FamilyIllness,
FullName may be used to either
include the name of the sibling, if
known, or capture a proprietary
temporary identifier for that person.
For example, a sibling might be
identified as Sibling 1, Brother 1,
Sister 1.
Date of onset of illness (month/year).
Diagnosis of family member
Family member‟s age at death, if died
from this illness.
If family member is still living, what is
their age?
Description of diagnosis/impairment
as described by interviewee.
On FamilyIllness, this element
describes the relation between the
Family member and the insured for
the family illness information.
210
XML Element Name
Type
Usage
Description
1 = Husband
2 = Wife
3 = Mother
4 = Father
7 = Brother
8 = Sister
<MilitaryExp>
<MilitaryStatus>
Object
Optional Repeating
TypeCode Optional
OLI LU
MILITARYS
TAT
1 = Active Duty
2 = Inactive
3 = Retired
4 = Active Reserve
5 = Inactive Reserve
6 = R.O.T.C. (Reserve
OfficersTraining Corps)
<MilitaryOrganizationTy TypeCode Optional
OLI LU
pe>
MILITARYO
RGTYPE
Type of Military organization
1 = Army
2 = Navy
3 = Marines
4 = Air Force
5 = Coast Guard
6 = National Guard
<TransferAlertInd>
Boolean Optional
0 = False
1 = True
<TransferDetails>
String
Optional
Object
Optional Repeating
<HHFamilyInsurance>
Information about a party's Military
experience.
Current Military status
Indicates whether the proposed
insured has been alerted to a transfer
or is leaving the country within the
next year.
Information about a pending military
transfer to another location. Used
when the TransferAlertInd is activated.
Information about the insurance
211
XML Element Name
Type
Usage
@PartyID
IDREF
Optional
<RoleCodeDesc>
TypeCode Optional
OLI LU
RELDESC
Description
applied for by family members in your
household.
and Keys
Role code describing family members
relationship to the proposed insured.
Role code describing family member‟s
relationship to the proposed insured.
Can be used alone or in conjunction
with RoleCode to describe the role of
the related Party.
RoleCodeDescription provides a more
detailed level of description than
RoleCode.
Household familial relationships only,
including self
1 = Husband
2 = Wife
3 = Mother
4 = Father
7 = Brother
8 = Sister
91 = Self
<AmtOfIns>
<AppPendingInd>
<LineOfBusiness>
Currency Optional
Boolean Optional
0 = False
1 = True
TypeCode Optional
OLI LU
LINEBUS
<ReplacementInd>
Boolean Optional
0 = False
1 = True
<RoleCode>
TypeCode Optional
OLI LU REL
Amount of insurance received.
Does this family member have an
application pending? TRUE if so,
FALSE if not.
Line of business of the insurance.
On HHFamilyInsurance, this is a place
to store the answer to a question on
the application about replacement
insurance for other members of the
household.
Role code describing family member's
relationship to the proposed insured at
212
XML Element Name
Type
Usage
Description
a general classification (e.g. Spouse,
Sibling). Use RoleCodeDesc for
specific relationships (e.g. brother,
mother).
Household familial relationships only,
including self
1 = Spouse
3 = Parent
4 = Sibling
168 = Self
<FinancialExperience>
<InvestmentType>
Object
Optional Repeating
TypeCode Required
OLI LU
INVESTPRO
D
<YearsOfInvestmentEx Integer
perience>
<Bankruptcy>
Object
Required
<WeightHistory>
Optional
Repeating
<TotalInforceIns>
Object
Optional
Repeating
Currency Optional
Answers to suitability questions
regarding investment experience.
Type of Investment product in which
Party has experience.
Years of Investment experience in this
investment type.
Information about the bankruptcy
experience of a party.
<Bankruptcy> Object
Weight at a prior point in time.
Requests for this information will vary
by carrier. Weight gain/loss can be
derived by comparing different Weight
History over time, or to the current
weight expressed under Person or
MedicalExam.
7.38 <WeightHistory> Object
the individual.
213
XML Element Name
Type
Usage
Currency Optional
<TotalPendingReinstatementIns Currency Optional
>
Description
individual.
Total Amount of Insurance Pending
Reinstatement
To be used to represent the total face
amount of Insurance that is pending
reinstatement.
214
XML Element Name
Type
Usage
Description
5.57 <SignatureInfo> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/ApplicationInfo/SignatureInfo
This Optional Object is used in OLifE to provide details about a signature. It is recommended as a best
practice that a SignatureInfo object be included to provide details for each signature.
<SignatureInfo id="APPLICANT_1_SIG" SignaturePartyID="APPLICANT_1_PARTY">
<SignatureRoleCode tc="1">Primary Insured</SignatureRoleCode>
<SignatureDate>2009-11-11</SignatureDate>
<SignatureTime>09:30:10-06:00</SignatureTime>
<SignatureCity>Ft. Lauderdale</SignatureCity>
<SignatureState tc="12">Florida</SignatureState>
<SignatureZip>33323</SignatureZip>
<SubmissionType tc="4">Phone</SubmissionType>
<SignaturePurpose tc="7">Application Signature</SignaturePurpose>
</SignatureInfo>
<SignatureInfo id>
ID
Optional
<@SignaturePartyID>
ID
Optional
<SignatureCode>
<SignatureRoleCode>
String
Optional
TypeCode Optional
OLI_LU_PAR
TICROLE
and Keys
Party ID of the Party object for the
signer.
Identifier for signature on the form
Role code describing signer‟s
relationship to the form.
1 = Primary Insured
2 = Other Insured
3 = Insured Child
4 = Insured Dependent
5 = Insured Spouse
7 = Beneficiary – Primary
9 = Beneficiary – Contingent
15 = Primary Agent
18 = Owner
50 = Joint Owner
<SignatureDate>
Date
Required
<SignatureTime>
Time
Optional
Date of signature
On SignatureInfo, documents the date
on which the signature party
performed the signature.
Time of signature
On SignatureInfo, documents the time
215
XML Element Name
Type
Usage
<SignatureCity>
String
Optional
<SigantureState>
TypeCode Optional
OLI_LU_STA
TE
<SignatureZip>
<SignatureCountry>
String
Optional
TypeCode Optional
Description
at which the signature party performed
the signature.
City where signed
State where signed
Signature zip code
Country where signed
OLI_LU_NATI
ON
<SubmissionType>
TypeCode Optional
OLI_LU_APP
SUBMITTYPE
Submission type or source
On SignatureInfo, this defines how
signature was obtained.
Indicates how the item was sent,
submitted, or where it can be
obtained.
1 = Mail
2 = Electronic
3 = Fax
4 = Phone
5 = Document can be recovered from
data present
6 = Document is on file
7 = Document is associated with but
not part of the OLifE data stream
8 = Document is attached in an
Attachment object.
10 = Voice Response Unit
11 = In response to the receipt of this
electronic app, the carrier will provide
the applicant with a paper app to be
completed at a later time.
12 = Internet
<SignaturePurpose>
TypeCode Optional
OLI_LU_SIG
NATURETYP
E
Categorizes the type of signature
1 = Lost Policy Declaration
2 = Applicant Replacement Verbal
Notice Disclosure
3 = Producer Application Signature
216
XML Element Name
Type
Usage
Description
4 = Producer Replacement
Certification
5 = Medical Exam Attestation
Signature
7 = Application Signature
8 = Blanket Authorization
<SignatureText>
String
Optional
<SignatureOK>
Boolean
Optional
0 = False
1 = True
<ElectronicAuthenticationType> TypeCode Optional
OLI_LU_ELE
CAUTH
<Attachment>
Object
The text representation for the
signature (typically person's name).
The signature on the form is present
and verified.
Electronic Authentication Type
1 = Click Wrap
2 = Password
Optional
Repeating
Note that when this is used as a part
of SignatureInfo, it is singular.
217
XML Element Name
Type
Usage
Description
5.58 <SourceInfo> Object
TXLife/TXLifeRequest/OLifE/SourceInfo
This Optional Object is used in OLifE to identify the most recent source of the data.
<SourceInfo>
<CreationDate>2004-08-03</CreationDate>
<CreationTime>15:06:35</CreationTime>
<SourceInfoName>The Technology Group</SourceInfoName>
</SourceInfo>
<CreationDate>
<CreationTime>
<SourceInfoName>
Date
Time
String
Optional
Optional
Optional
<SourceInfoDescription>
String
Optional
<SourceInfoComment>
String
Optional
Creation date
Creation time
The name of the source of the file.
This could reflect the company or
product name.
Additional information specifically
regarding the source of the file.
A comment supplied by the source of
the file
218
XML Element Name
Type
Usage
Description
5.59 <SubAccount> Object
TXLife/TXLifeRequest/OLifE/Holding/Investment/SubAccount
A SubAccount is an individual account associated with an investment. The SubAccount Object represents
all investments that were chosen for this new business application.
The investment SubAccount object contains information about the individual accounts associated with an
investment.
Each investment should have one or more SubAccount objects associated with it. A collection of
SubAccount objects is utilized to represent all the SubAccounts an investment may have.
If an investment is a single account and does not contain multiple accounts, you should still have one
Subaccount object populated to reflect those details about the account.
The Entity Recognition is CarrierCode and ProductCode.
<Investment>
<SubAccount id="Proposed_Holding_1_SubAccount_1">
<ProductCode>ABC Fund Manager</ProductCode>
<CarrierName>Fidelity</CarrierName>
<ProductFullName>ABC Fund</ProductFullName>
</SubAccount>
<ProductCode>DEF</ProductCode>
<ProductFullName>DEF Fund</ProductFullName>
</SubAccount>
<ProductCode>GHI</ProductCode>
<CarrierName>John Hancock</CarrierName>
<ProductFullName>GHI Fund</ProductFullName>
</SubAccount>
<ProductCode>FIX</ProductCode>
<ProductFullName>Fixed Account</ProductFullName>
</SubAccount>
<ProductCode>STP</ProductCode>
<ProductFullName>STP Fund</ProductFullName>
</SubAccount>
<ProductCode>XYZ</ProductCode>
219
XML Element Name
Type
Usage
Description
<CarrierName>Transamerica</CarrierName>
<ProductFullName>XYZ Account</ProductFullName>
</SubAccount>
</Investment>
@id
ID
Optional
<ProductCode>
String
Required
<CarrierCode>
String
Required
<CarrierName>
String
Optional
<ProductFullName>
String
Optional
<CusipNum>
String
Optional
and Keys
On SubAccount, this is the carrier
assigned code used to identify the
SubAccount, which is the
InvestProduct or fund.
When CarrierCode is used on
SubAccount, it should contain either
the code of the firm managing the fund
or the insurance company that‟s
representing it.
On SubAccount, CarrierName is the
name of the Investment (Fund)
Manager. It also references the name
on the Prospectus and refers to the
organization which manages the fund.
Full name of SubAccount. This is the
complete, official, and/or legal name
used for this investment product.
Provide if the fund has a CUSIP.
CusipNum is the 'Underlying Fund
Identifier which identifies the Fund
CUSIP of the underlying mutual for
externally managed funds.
CUSIP NUMBER [is a] number
identifying all stocks and registered
bonds, using the COMMITTEE ON
UNIFORM SECURITIES
IDENTIFICATON PROCEDURES
(CUSIP)...The CUSIP system makes it
easier to settle and clear trades.
Foreign securities use a similar
identification system called the CUSIP
International Numbering Systems
(CINS).
220
XML Element Name
Type
Usage
Description
5.60 <SubstandardRating> Object
TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage/LifeParticipant/SubStandardRating
The purpose of this object is to contain tables 2 through x that are needed to handle substandard cases.
The first rating, table, etc should be stored on the respective parent LifeParticipant object.
The first permanent rating type and the first temporary rating type are denoted here in
PermanentRatingType and TemporaryRatingType, respectively. Although it is possible to represent both
a Permanent Rating and a Temporary Rating in one instance of SubstandardRating, it is a best practice to
only include one rating per SubstandardRating instance
<SubstandardRating id="SSR_002">
<PermFlatExtraAmt>10</PermFlatExtraAmt>
<PermRatingType tc="2">Aviation></PermRatingType>
<SubstandardRating id="SSR_003">
<TempFlatExtraAmt>10</TempFlatExtraAmt>
<TempFlatExtraDuration>5</TempFlatExtraDuration>
<TempRatingType tc="3">Temp Extra</TempRatingType>
<SubstandardRatingID>
ID
Optional
<RatingReason>
String
Optional
<PermTableRating>
TypeCode Optional
OLI_LU_RA
TINGS
and Keys
This element contains the reason that
the coverage option was rated by the
underwriter. The reason can also be
used for field underwritten cases.
individual or organization. This is the
permanent rating according to this
premium. The
PermTableRatingAlphaCode will
rating such as “A”, or “AA”
<TempTableRating>
TypeCode Optional
OLI_LU_RA
TINGS
individual or organization. This is a
temporary rating according to this
221
XML Element Name
Type
Usage
Description
premium. The
TempTableRatingAlphaCode will
<PermFlatExtraAmt>
Currency Optional
<PermTableRatingAlphaCode> String
Optional
On substandard risks, this amount is
an additional charge to the insured for
the life of the policy. Because the
insured represents a higher risk to the
company, the flat extra is charged to
compensate for that risk.
percentage for a Permanent Rating
Table.
PermTableRating, which holds the
percentage.
<TempTableRatingCode>
String
<TempRatingType>
TypeCode Optional
OLI_LU_RA
TINGTYPE
Optional
Note that despite the name of the tag,
the code associated with a table may
be a numeric value. For example,
occupation tables may be numbered
with values 1 through 8 rather than A
through Z.
percentage for a Temp Rating Table.
TempTableRating which holds the
percentage.
On SubstandardRating, use the
TempRatingType. For example, if
TempRatingType = Aviation, the type
OccupRating.
222
XML Element Name
Type
Usage
Description
1 = Impairment
2 = Aviation
3 = Temporary Extra
4 = Occupation
5 = Avocation
<PermRatingType>
TypeCode Optional
OLI_LU_RA
TINGTYPE
On SubstandardRating, use the
PermRatingType. For example, if
PermRatingType = Aviation, the type
OccupRating.
1 = Impairment
2 = Aviation
3 = Temporary Extra
4 = Occupation
5 = Avocation
<Occupation>
String
<OccupRating>
TypeCode Optional
OLI_LU_OC
CUPRATING
Optional
Occupation for the person that
impacts the substandard rating.
Can include values such as 'Pilot,'
'Construction,' etc.
Code)
types such as Occupational or
Aviation.
On SubstandardRating, OccupRating
essentially serves as a sub type for
the PermRatingType property.
223
224
XML Element Name
Type
Usage
Description
5.61 <WeightHistory> Object
TXLife/TXLifeRequest/OLifE/Party/Risk/WeightHistory
Weight at a prior point in time. Requests for this information will vary by carrier. Weight gain/loss can be
derived by comparing different WeightHistory Objects over time, or to the current weight expressed under
Person or MedicalExam.
<WeightHistory>
<Weight2>
<MeasureUnits tc=”2“>US System Standard</MeasureUnits>
<WeightMeasuredInd tc=”1”>True</WeightMeasuredInd>
</Weight2>
<HistoryDuration>1</HistoryDuration>
<HistoryDurationQualifier tc=”68”>Years</HistoryDurationQualifier>
</WeightHistory>
<WeightHistory id>
ID
Optional
<Weight2>
Object
Optional
<MeasureUnits>
TypeCode Optional
OLI_LU_ME
ASUREUNIT
S
and Keys
The weight of the person as measured
or stated.
Meausre Units
1 = Metric System
Kilograms
pounds
225
XML Element Name
<MeasureValue>
<WeightMeasuredInd>
Type
Usage
<HistoryDuration>
Real
Optional
Boolean Optional
0 = False
1 = True
Integer
Optional
<HistoryDurationQualifier>
TypeCode Optional
OLI_LU_ME
ASUNITS
Description
Test Value
Indicates the value was measured.
1/TRUE = Measured
0/FALSE = Stated
On WeightHistory, HistoryDuration, in
combination with
HistoryDurationQualifier, is used to
indicate "how far back" the weight is
being reported. For example, if
WeightHistory is reporting the Party's
weight "one year ago;" then
HistoryDuration would be set to "1"
and HistoryDurationQualifier would be
set to "Years" (68).
On WeightHistory, HistoryDuration, in
combination with
HistoryDurationQualifier, is used to
indicate "how far back" the weight is
being reported. For example, if
WeightHistory is reporting the Party's
weight "one year ago;" then
HistoryDuration would be set to "1"
and HistoryDurationQualifier would be
set to "Years" (68).
226
6
TRANSMITTING/SENDING A NEW BUSINESS SUBMISSION FOR
LIFE INSURANCE
The ACORD XMLife model is based on a Request/Response methodology. Each message is considered
to be an atomic business operation representing a logical unit of work to be performed. The request is
submitted, the work is performed, and the appropriate response is sent back to the requestor. Generally
this request and response are handled synchronously with the response indicating the work is completed.
But the model may also be used asynchronously where the request is accepted and acknowledged but
the work is performed off-line. In some cases the work will be performed without an electronic response
message being sent after completion. Completion can be indicated in other fashions such as an email
message, a phone call, or by the original requestor submitting an inquiry.
The New Business Submission for Life is most frequently implemented in an asynchronous fashion. The
requestor uses a one-way communication, which is often simpler to implement.
A full request message 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 <Holding>, <Policy>, 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 TXLife “wrapper” provides information about the sender, the recipient, when the message was
created and so forth. It does NOT include details about the Electronic Application Submission- 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 message.
There are many different types of ACORD transactions. The one that is of interest in this context is the
New Business Submission Transaction, transaction type 103.
The basic construct of a full TXLife Transmittal is:
<TXLife>
<UserAuthRequest>
<TXLifeRequest>
<OLifE>
[all the Electronic Application Submission details]
Following are descriptions of each element.
TX Life Wrapper
<UserAuthRequest> Object
<TXLifeRequest> Object
Descriptions
This object contains the information related to the user
This object contains the information related to the
message/transaction itself
227
XML Element Name
Type
Usage
Description
6.1 <UserAuthRequest> Object
This object defines the transaction/message information about the user and the system that is sending
the message.
<UserAuthRequest>
<UserLoginName>ABCAGENCY</UserLoginName>
<VendorApp>
<VendorName VendorCode="5">Vendor</VendorName>
<AppName>AppEnter</AppName>
</VendorApp>
</UserAuthRequest>
<UserLoginName>
String
Optional
<UserPswd>
<CryptType>
<Pswd>
Object
String
String
Optional
Optional
Conditional
User Login name into receiving system, if
applicable.
User Password Aggregate
Encryption type
User Password, if applicable.
Conditional
Optional
Optional
Required
Optional
Required if CryptPswd not provided
Required if Pswd not provided
Date that User makes request.
Details about the vendor
Name of the vendor
Name of the application
<CryptPswd>
<UserDate>
<VendorApp>
<VendorName>
<AppName>
String
Date
Object
String
String
228
Choreography of New Business Submission Request and Response Message
Upon submission of a New Business Submission Request to a carrier, several responses, or
combination of responses are possible:
1. If the carrier needs additional time to determine if a New Business Submission request
meets its In Good Order (IGO) requirements, but wants to acknowledge immediately
that it did receive the request, the carrier may respond immediately with a
TXLifeResponse containing a ResultCode of „3‟ (Received Pending) See the object
definition for Object for Pending Response (Performing Checks). The carrier can then, at
a later time, follow with a subsequent TXLifeResponse that informs the sender whether
or not the New Business Submission met their IGO requirements. See objects for
Object for Success-IGO Response or Object for Failure-NIGO Response
2. If the carrier can respond immediately on the success or failure of the New Business
Submission, the Pending TXLifeResponse step can be skipped and the carrier can
respond with either the response described in the Object for Success-IGO Response or
the Object for Failure-NIGO Response
3. Note: Though customary, it is not required to send a Policy Number in a successful
response (Object for Success-IGO Response). Some carriers assign the Policy Number
before submission and some may have a process where it is assigned at a later time.
XML Element Name
Type
Usage
Description
6.2 <TXLifeRequest> Object
This object defines the information about this particular message/transaction. It provides a container for
a TXLife message request's details. Its complement is TXLifeResponse
<TXLifeRequest PrimaryObjectID="Holding1">
<TransRefGUID> 20040803030635</TransRefGUID>
<TransType tc="103">New Submission</TransType>
<TransExeDate>2004-08-03</TransExeDate>
<TransExeTime>15:06:35</TransExeTime>
<TransMode tc="2"> Original</TransMode>
<PendingResponseOK tc="1">Yes</NoResponseOK>
<TestIndicator tc="0">No</TestIndicator>
</TXLifeRequest>
@id
ID
Optional
<@PrimaryObjectID
IDREF
Required
<TransRefGUID>
String
Required
<TransType>
Typecode
Required
OLI LU
TRANS TYPE
CODES
See the description at the beginning of this
chapter for usage & meaning
Identifying Objects using IDs, Codes and Keys
This identifier tells you where to start when
parsing a new business transaction. It must
represent the id of the proposed Holding that is
the target of this new business submission.
Uniquely identifies this transaction. Use a 32-bit
GUID (Globally Unique Identifier).
Transaction type uniquely indicates that this is
an ACORD New Business Submission
transaction to the receiving system.
229
XML Element Name
<TransExeDate>
<TransExeTime>
<TransMode>
Type
Date
Time
TypeCode
Usage
Optional
Optional
Optional
TRANS MODE
CODES
<PendingResponseO
K>
Boolean
0 = False
1 = True
Optional
Description
103 = New Business Submission for a Policy
Note: This is a partial list from the current
ACORD spec. Please see current spec. for
additional codes.
Date and time when this transaction was
created.
Use full Schema DateTime format:
ccyy-mm-ddThh.mm.ss-hh.mm
For example, to indicate 1:20 pm on May the
31st, 1999 for Eastern Standard Time which is
5 hours behind Coordinated Universal Time
(UTC), one would write: 1999-05-31T13:20:0005:00.
Time when this transaction was created.
Indicates the mode this transaction type is
being processed as. Applies to transactions
that initiate a business process that takes time
to complete, (e.g. NB submission).
2 = Original request. Sent by sender.
Support Pending Response Indicator
True Indicates that it is ok to send a pending
Response. False indicates that it is not
acceptable to pend the transaction. If it cannot
immediately be processed, a failure Response
should be sent.
<NoResponseOk>
Boolean
0 = False
1 = True
Optional
<TestIndicator>
Boolean
0 = False
1 = True
Optional
<OLifE>
Object
Required
Note: SupportMultipleResponseInd is not
needed in this business case as the transaction
is still only between 2 parties and the delay in
response is due to an IGO check
Indicates if a response is desired or necessary.
True indicates that a response is not needed to
the message. This is particularly useful for the
Transmittal request messages. Default is
False, you must provide a response. This is
sometimes referred to as the "fire and forget
flag".
True indicates that this is a test file. A test file
should not be processed against live data. It is
used to identify transactions that are in a test
mode.
This is the OLifE Server object or "Root"
element.
230
XML Element Name
Type
Usage
Description
Provides a known fixed starting location for the
Life Data Model which must always be present
in all ACORD messages.
231
XML Element Name
Type
Usage
Description
6.3 <TXLifeResponse> Object for Success-IGO Response
This object defines the information about the response to the TXLife Request. It indicates to the receiver
of the response that the request for a new business submission was successfully received. Some
carriers use this opportunity to let the sender know that the request passed their In Good Order (IGO)
processing rules. They can take advantage of this opportunity to return the assigned policy number.
<TXLifeResponse>
<TransRefGUID>181007A007-9991022</TransRefGUID>
<TransType tc="103">New Business Submission</TransType>
<TransMode tc="2">Original</TransMode>
<PendingResponseOK tc="1">YES</PendingResponseOK>
<NoResponseOK tc="1">YES</NoResponseOK>
<TestIndicator tc="1">YES</TestIndicator>
<TransResult>
<ResultCode tc="2"> Success with info</ResultCode>
<ResultInfo>
<ResultInfoCode tc="3028">Policy Number Assigned</ResultInfoCode>
</ResultInfo>
</TransResult>
<OLifE>
<Holding id="holding_id">
<Policy>
<PolNumber>L1234567</PolNumber>
<ApplicationInfo>
<TrackingID>9991022</TrackingID>
</ApplicationInfo>
</Policy>
</Holding>
</OLifE>
</TXLifeResponse>
@id
ID
Optional
<@PrimaryObjectID
IDREF
Required
<TransRefGUID>
String
Required
<TransType>
Typecode
Required
OLI LU
TRANS TYPE
CODES
<TransExeDate>
Date
Optional
parsing a new business transaction. It should
represent the ID for the proposed Holding
Object.
232
XML Element Name
Type
Usage
Description
created.
<TransExeTime>
<TransMode>
Time
TypeCode
Optional
Optional
TRANS MODE
CODES
To be determined. Not used for initial
implementation.
<PendingResponseO
K>
Boolean
0 = False
1 = True
Optional
Not required, but it is a best practice to echo
back the request information.
should be sent.
<NoResponseOk>
Boolean
0 = False
1 = True
Optional
<TestIndicator>
Boolean
0 = False
1 = True
Optional
<TransResult>
<ResultCode>
Object
Required
TypeCode
Required
RESULT
CODES
<ResultInfo>
Object
Optional
flag".
mode.
Transaction Result Details
This aggregate provides the details in a TXLife
Response regarding a transactions result.
A result code returned by the receiving system.
1 = Success
2 = Success with information
Result Details/Information
233
XML Element Name
<ResultInfo
Code>
Type
TypeCode
Usage
Optional
Result Info
Codes
<OLifE>
Object
Required
<Holding>
Object
<Policy>
Object
Conditionally
Required
Conditionally
Required
Conditionally
Required
<PolNumber>
<ApplicationInfo>
<TrackingID>
String
Object
Optional
String
Optional
Description
Under TransResult, absence or presence of
ResultInfo is determined by the type code value
in the ResultCode property. See ResultCode
values for an indication of when ResultInfo
should appear in the response.
element.
Required if ResultInfoCode tc="3028"(Policy
Number Assigned)
Number Assigned)
Number Assigned)
Assigned Policy Number
This is the Case/Tracking Number used to
identify the application to reference the Holding
until a policy number is assigned. Once a policy
number is assigned, the reference to the
Holding should be identified using the policy
number.
234
XML Element Name
Type
Usage
Description
6.4 <TXLifeResponse> Object for Failure-NIGO Response
This object defines the information about the response to the TXLife Request. It indicates to the receiver
of the response that the request for a new business submission failed. Some carriers use this opportunity
to let the sender know that the request failed their „In Good Order‟ (IGO) processing rules. They can
return the reason for the failure.
<TXLifeResponse>
<TransRefGUID>A007-90-9647096</TransRefGUID>
<PendingResponseOK tc="1">YES</PendingResponseOK>
<TransResult>
<ResultCode tc="5">Failure</ResultCode>
<ResultInfo>
<ResultInfoCode tc="200">General Data Error</ResultInfoCode>
<ResultInfoDesc>Error description</ResultInfoDesc>
</ResultInfo>
</TransResult>
</TXLifeResponse>
</TXLife>
@id
ID
Optional
<@PrimaryObjectID
IDREF
Required
<TransRefGUID>
String
Required
<TransType>
Typecode
Required
OLI LU
TRANS TYPE
CODES
<TransExeDate>
Date
Optional
Object.
created.
235
XML Element Name
<TransExeTime>
<TransMode>
Type
Time
TypeCode
Usage
Optional
Optional
TRANS MODE
CODES
<PendingResponseO
K>
<NoResponseOk>
<TestIndicator>
<TransResult>
<ResultCode>
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Optional
Optional
Optional
2 = Original request. Sent by sender
should be sent.
flag".
Object
Required
TypeCode
Required
mode.
Optional
5 = Failure
Result Details/Information
RESULT
CODES
<ResultInfo>
Description
implementation.
Object
Under TransResult, absence or presence of
ResultInfo is determined by the type code value
in the ResultCode property. See ResultCode
values for an indication of when ResultInfo
should appear in the response.
236
XML Element Name
<ResultInfo
Code>
<ResultInfo
Desc>
<OLifE>
Type
TypeCode
Usage
Optional
Result Info
Codes
Description
String
Optional
Object
Required
Explanatory text associated with the cause of
the result. It should be as specific as possible.
This is used to help a human reader identify the
problem in the request and thus should provide
as much guidance as reasonable.
element.
237
XML Element Name
Type
Usage
Description
6.5 <TXLifeResponse> Object for Pending Response (Performing Checks)
This object defines the information about the response to the TXLife Request. This response it usually
used when there is a delay in processing the In Good Order (IGO) processing rules and the carriers want
to return an immediate response. This message is used for the immediate response. It will be followed by
an IGO –Success Response or an NIGO – Failure response within a reasonable timeframe.
<TXLifeResponse>
<TransRefGUID>12346578900987654321</TransRefGUID>
<PendingResponseOK tc="1">Yes</PendingResponseOK>
<TransResult>
<ResultCode tc="3">Received Pending</ResultCode>
</TransResult>
<OLifE>
<Holding id="holding_id">
<Policy>
<ApplicationInfo>
<TrackingID>9991022</TrackingID>
</ApplicationInfo>
</Policy>
</Holding>
</OLifE>
</TXLifeResponse>
@id
ID
Optional
<@PrimaryObjectID
IDREF
Required
<TransRefGUID>
String
Required
<TransType>
Typecode
Required
OLI LU
TRANS TYPE
CODES
<TransExeDate>
Date
Optional
Object.
created.
238
XML Element Name
<TransExeTime>
<TransMode>
Type
Time
TypeCode
Usage
Optional
Optional
TRANS MODE
CODES
<PendingResponseO
K>
<NoResponseOk>
<TestIndicator>
<TransResult>
<ResultCode>
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Boolean
0 = False
1 = True
Optional
Optional
Optional
Object
Required
TypeCode
Required
RESULT
CODES
<OLifE>
Object
Required
Description
implementation.
should be sent.
flag".
mode.
3 = Received Pending (transaction in queue)
element.
239
XML Element Name
Type
Usage
Description
240
7
NEW BUSINESS SUBMISSION STANDARD USAGES
Basic Contract Scenarios
The section provides basic scenarios of usage of the Electronic Application Submission standard for life
insurance contracts. The only example represented is for term insurance. Additional scenarios will be
represented as they are defined.
Users are encouraged to enhance this section, by offering examples that represent best practices from
industry participants to the Policy Lifecycle Working Group.
7.1 NBfL Sample Scenario 1: Basic Term Insurance Submission
The following XML data stream represents a complete New Business Transaction for a term life insurance
policy. This scenario reflects all of the required data elements, additional elements may optionally be
provided. Please note that this sample does not cover all scenarios presented throughout this
implementation guide. Please refer to the individual sections/Objects for sample XML modeling.
<?xml version="1.0" encoding="UTF-8"?>
<TXLife Version="2.20" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ACORD.org/Standards/Life/2"
xsi:schemaLocation="http://ACORD.org/Standards/Life/2 C:\ACORD\Standards\ACORDX~1.21\TXLife2.21.00.xsd">
<UserAuthRequest>
<VendorApp>
<VendorName VendorCode="86">EbixExchange</VendorName>
</VendorApp>
</UserAuthRequest>
<TXLifeRequest PrimaryObjectID="Proposed_Holding_1">
<TransRefGUID>9e59098a45f549e8943128918da9de62</TransRefGUID>
<TransType tc="103"/>
<TransExeTime>12:15:54-04:00</TransExeTime>
<NoResponseOK tc="1">True</NoResponseOK>
<OLifE>
<SourceInfo>
<CreationTime>12:15:54-04:00</CreationTime>
<SourceInfoName>XYZ Vendor</SourceInfoName>
</SourceInfo>
<Holding id="Proposed_Holding_1">
<HoldingStatus tc="3">Proposed</HoldingStatus>
<HoldingForm tc="1"/>
<Policy CarrierPartyID="Carrier_Party_1">
<ProductType tc="2">Term</ProductType>
<ProductCode>ABC_TERM</ProductCode>
<PlanName>ABC First American Term Life</PlanName>
<ShortName>1st American Term</ShortName>
<Life>
<Coverage>
<PlanName>ABC First American Term</PlanName>
<ProductCode>BASE</ProductCode>
<LifeCovTypeCode tc="6">Term Level Death Benefit</LifeCovTypeCode>
<LivesType tc="1">Single life</LivesType>
241
<CovOption>
<PlanName>Accidental Death Benefit Rider</PlanName>
<LifeCovOptTypeCode tc="2">Accidental Death Benefit</LifeCovOptTypeCode>
</CovOption>
<CovOption>
<PlanName>No lapse Guarantee Option</PlanName>
<ProductCode>NLP</ProductCode>
<LifeCovOptTypeCode tc="9">No Lapse Guarantee Option</LifeCovOptTypeCode>
</CovOption>
<CovOption>
<PlanName>Disability Waiver of Premium Rider</PlanName>
<ProductCode>WPR02</ProductCode>
<LifeCovOptTypeCode tc="17">Waiver of Premium</LifeCovOptTypeCode>
</CovOption>
<LifeParticipant PartyID="Primary_Insured_Party_1">
<TobaccoPremiumBasis tc="1">non-Smoker</TobaccoPremiumBasis>
</LifeParticipant>
</Coverage>
<Coverage>
<PlanName>Child Rider</PlanName>
<ProductCode>CR1</ProductCode>
<LifeCovTypeCode tc="116">Child Term Rider</LifeCovTypeCode>
<CurrentAmt>15000</CurrentAmt>
<LifeParticipant PartyID="Coverage_CBR_1_Insured_Party_1">
<LifeParticipantRoleCode tc="3">Insured Child</LifeParticipantRoleCode>
</LifeParticipant>
</Coverage>
<Coverage>
<PlanName>Terminal Illness Rider</PlanName>
<ProductCode>TI1</ProductCode>
<LifeCovTypeCode tc="2147483647">Other</LifeCovTypeCode>
</Coverage>
</Life>
<ApplicationInfo>
<FormalAppInd tc="1">true</FormalAppInd>
<Identification>
</Identification>
</ApplicationInfo>
242
<RequirementInfo AppliesToPartyID="Primary_Insured_Party_1">
<StatusEvent>
</StatusEvent>
</RequirementInfo>
<ReqCode tc="11">APS</ReqCode>
<ReqStatus tc="4">Outstanding</ReqStatus>
<ResponsiblePartyType tc="5">Home Office</ResponsiblePartyType>
</RequirementInfo>
<FinancialActivity>
<FinActivityType tc="7">Initial Payment</FinActivityType>
<Payment BankHoldingID="Bank_Holding_1">
<PaymentAmt>200.00</PaymentAmt>
<PaymentMethod tc="7">Electronic funds transfer</PaymentMethod>
</Payment>
</Policy>
<Attachment>
<AttachmentBasicType tc="2">Image</AttachmentBasicType>
<Description>Application</Description>
<AttachmentData>http://www.insuranceagency.com/files/attachimage.tiff</AttachmentData>
<AttachmentType tc="10">Original Application</AttachmentType>
<ImageType tc="3">TIFF</ImageType>
<AttachmentLocation tc="2">URL Reference</AttachmentLocation>
</Attachment>
<Intent>
<ExpenseNeedTypeCode tc="18">Mortgage</ExpenseNeedTypeCode>
</Intent>
<Intent>
<ExpenseNeedTypeCode tc="10">Estate Planning</ExpenseNeedTypeCode>
</Intent>
<Arrangement id="A9f95740c-94c1-491e-b7b3-e7f9a06fce20">
<ArrType tc="39">Subsequent premium, AKA inforce premium</ArrType>
<ArrSource BankingInfoID="Bank_Holding_1"/>
</Arrangement>
</Holding>
<Holding id="Existing_Holding_1" DataRep="ReadOnly">
<HoldingStatus tc="1">Active Inforce</HoldingStatus>
<Policy CarrierPartyID="Existing_Holding_1_Carrier_Party">
<EffDate>2000-01-01</EffDate>
<Life>
</Life>
</Policy>
</Holding>
<Holding id="Bank_Holding_1" DataRep="ReadOnly">
<Banking FinancialInstitutionPartyID="EFT_Bank_Party_1">
<BankAcctType tc="2">Checking</BankAcctType>
<AcctHolderName>Slate Rock and Gravel</AcctHolderName>
<BankName>Washington Mutual Bank, Federal Savings Bank</BankName>
</Banking>
243
</Holding>
<FullName>Slate Rock and Gravel Company</FullName>
<GovtIDTC tc="2">Tax Identification Number</GovtIDTC>
<ResidenceState tc="5">Arkansas</ResidenceState>
<Organization>
</Organization>
<Address>
<Line1>555 Slate Ave.</Line1>
<City>Bedrock</City>
<AddressStateTC tc="5">Arkansas</AddressStateTC>
<Zip>77201</Zip>
<AddressCountryTC tc="1">United States</AddressCountryTC>
</Address>
<Phone>
<PhoneTypeCode tc="2">Business</PhoneTypeCode>
</Phone>
</Party>
<Party id="Agent_Party_1">
<Person>
<FirstName>George</FirstName>
<LastName>Adams</LastName>
</Person>
<Phone>
</Phone>
<Phone>
<PhoneTypeCode tc="19">Fax</PhoneTypeCode>
</Phone>
<Producer>
<CompanyProducerID>007</CompanyProducerID>
</Producer>
<EMailAddress>
<EMailType tc="1"/>
</EMailAddress>
</Party>
<Person>
<FirstName>Sam</FirstName>
</Person>
<Phone>
</Phone>
<Phone>
</Phone>
<Producer>
</Producer>
244
<EMailAddress>
<EMailType tc="1"/>
</EMailAddress>
</Party>
<GovtIDTC tc="1">Social Security Number</GovtIDTC>
<Person>
<FirstName>Fred</FirstName>
<MiddleName/>
<LastName>Flintstone</LastName>
<Citizenship tc="1">United States</Citizenship>
<SmokerStat tc="2">prior tobacco user</SmokerStat>
<Height2>
</Height2>
<Weight2>
<MeasureValue>250.00</MeasureValue>
</Weight2>
<DriversLicenseNum>F12345</DriversLicenseNum>
<DriversLicenseState tc="5">Arkansas</DriversLicenseState>
<BirthCountry tc="1">United States</BirthCountry>
<BirthJurisdictionTC tc="5">Arkansas</BirthJurisdictionTC>
</Person>
<Address>
<Line1>343 Bedrock Ct.</Line1>
<Zip>72201</Zip>
<YearsAtAddress>4.00</YearsAtAddress>
</Address>
<Phone>
</Phone>
<Phone>
<PhoneTypeCode tc="2147483647">Other</PhoneTypeCode>
</Phone>
<EMailAddress>
</EMailAddress>
<Risk>
<RejectionInd tc="0">false</RejectionInd>
<RejectionReason/>
<ActivelyAtWorkInd tc="1">True</ActivelyAtWorkInd>
245
<CrimeDescription>Minor in Possession when 20 years old</CrimeDescription>
<SubstanceUsage>
<SubstanceType tc="8">Alcohol</SubstanceType>
</SubstanceUsage>
<SubstanceUsage>
<TobaccoType tc="2">Cigars</TobaccoType>
</SubstanceUsage>
<LifeStyleActivity>
<ForeignTravel>
</ForeignTravel>
</Risk>
<Employment EmployerPartyID="Primary_Insured_Employer_Party_1">
<Occupation>crane operator</Occupation>
<EmployerName>Slate Rock and Gravel Company</EmployerName>
<EmploymentDuties>heavy construction</EmploymentDuties>
</Employment>
</Party>
<Organization/>
<Address>
<Zip>72201</Zip>
</Address>
</Party>
<Party id="Coverage_CBR_1_Insured_Party_1">
<Person>
<FirstName>Pebbles</FirstName>
<MiddleName/>
<Gender tc="2">Female</Gender>
<Height2>
</Height2>
<Weight2>
</Weight2>
</Person>
<Risk>
<ExistingInsuranceInd tc="0">false</ExistingInsuranceInd>
</Risk>
</Party>
246
<Party id="Coverage_Base_Primary_Beneficiary_1">
<Person>
<FirstName>Wilma</FirstName>
<MiddleName/>
</Person>
</Party>
<Organization>
<OrgForm tc="23">Corporation, General</OrgForm>
</Organization>
</Party>
<Party id="Coverage_Base_Contingent_Beneficiary_1">
<Person>
</Person>
</Party>
<Party id="Carrier_Party_1">
<FullName>ABC Life Assurance Co.</FullName>
<Organization>
<OrgCode>ABCL</OrgCode>
</Organization>
<Carrier>
<CarrierCode>ABCL</CarrierCode>
<NAICCode>12345</NAICCode>
<NAICGroupCode>678</NAICGroupCode>
</Carrier>
</Party>
<Party id="Existing_Holding_1_Carrier_Party">
<FullName>Bedrock Life Insurance Company</FullName>
<Organization/>
</Party>
<Party id="EFT_Bank_Party_1">
<FullName>Washington Mutual Bank, Federal Savings Bank</FullName>
<Organization/>
<Address>
<Line1>987 Main St.</Line1>
<Zip>72201</Zip>
</Address>
</Party>
RelatedObjectID="Primary_Insured_Party_1">
<RelationRoleCode tc="32">Insured</RelationRoleCode>
</Relation>
<Relation id="Coverage_CBR_1_Insured_1_to_Policy" OriginatingObjectID="Proposed_Holding_1"
RelatedObjectID="Coverage_CBR_1_Insured_Party_1">
247
<RelationRoleCode tc="33">Coverage Insured</RelationRoleCode>
</Relation>
<Relation id="Primary_Beneficiary_1_to_Policy" OriginatingObjectID="Proposed_Holding_1"
RelatedObjectID="Coverage_Base_Primary_Beneficiary_1">
<RelationRoleCode tc="34">Beneficiary</RelationRoleCode>
<InterestPercent>55.00</InterestPercent>
</Relation>
</Relation>
<Relation id="Contingent_Beneficiary_1_to_Policy" OriginatingObjectID="Proposed_Holding_1"
RelatedObjectID="Coverage_Base_Contingent_Beneficiary_1">
<RelationRoleCode tc="36">Contingent beneficiary</RelationRoleCode>
</Relation>
<Relation id="Agent_to_Policy_1" OriginatingObjectID="Proposed_Holding_1" RelatedObjectID="Agent_Party_1">
<RelationRoleCode tc="37">PrimaryWritingAgent</RelationRoleCode>
</Relation>
<Relation id="Agent_to_Policy_2" OriginatingObjectID="Proposed_Holding_1" RelatedObjectID="Agent_Party_2">
<RelationRoleCode tc="52">AdditionalWritingAgent</RelationRoleCode>
</Relation>
<Relation id="Owner_to_Policy" OriginatingObjectID="Proposed_Holding_1" RelatedObjectID="Primary_Insured_Party_1">
<RelationRoleCode tc="8">Owner</RelationRoleCode>
</Relation>
<Relation id="Coverage_CBR_1_Insured_1_to_Primary_Insured_Party_1" OriginatingObjectID="Primary_Insured_Party_1"
RelatedObjectID="Coverage_CBR_1_Insured_Party_1">
<RelationDescription tc="6">Daughter</RelationDescription>
</Relation>
<Relation id="Primary_Beneficiary_1_to_Primary_Insured_Party_1" OriginatingObjectID="Primary_Insured_Party_1"
<RelationRoleCode tc="1">Spouse</RelationRoleCode>
<RelationDescription tc="2">Wife</RelationDescription>
</Relation>
<Relation id="Primary_Beneficiary_2_to_Primary_Insured_Party_1" OriginatingObjectID="Primary_Insured_Party_1"
<RelationRoleCode tc="7">Employer</RelationRoleCode>
</Relation>
<Relation id="Contingent_Beneficiary_1_to_Primary_Insured_Party_1" OriginatingObjectID="Primary_Insured_Party_1"
</Relation>
<Relation id="Existing_Holding_1_to_Primary_Insured_Party_1" OriginatingObjectID="Existing_Holding_1"
248
</Relation>
<Relation id="Payor_to_Policy_1" OriginatingObjectID="Proposed_Holding_1" RelatedObjectID="Payor_Party_1">
<RelationRoleCode tc="31">Payor</RelationRoleCode>
</Relation>
</OLifE>
</TXLifeRequest>
</TXLife>
7.2 NBfL Sample Scenario 2: Basic Variable Universal Life Insurance
Submission
The following XML data stream represents a complete New Business Transaction for a variable universal
life insurance policy. This scenario reflects all of the required data elements, additional elements may
optionally be provided. Please note that this sample does not cover all scenarios presented throughout
this implementation guide. Please refer to the individual sections/Objects for sample XML modeling.
<?xml version="1.0" encoding="UTF-8"?>
<TXLife Version="2.20" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ACORD.org/Standards/Life/2"
xsi:schemaLocation="http://ACORD.org/Standards/Life/2 C:\ACORD\Standards\ACORDX~1.21\TXLife2.21.00.xsd">
<UserAuthRequest>
<VendorApp>
<VendorName VendorCode="86">EbixExchange</VendorName>
</VendorApp>
</UserAuthRequest>
<TXLifeRequest PrimaryObjectID="Proposed_Holding_1">
<TransRefGUID>9e59098a45f456ea1da8918da9de62</TransRefGUID>
<TransType tc="103"/>
<TransExeTime>12:15:54-04:00</TransExeTime>
<NoResponseOK tc="1">True</NoResponseOK>
<OLifE>
<SourceInfo>
<CreationTime>12:15:54-04:00</CreationTime>
<SourceInfoName>ABC Vendor</SourceInfoName>
</SourceInfo>
<Holding id="Proposed_Holding_1">
<HoldingSysKey Persist="Permanent" VendorCode="0132">12345</HoldingSysKey>
<Policy CarrierPartyID="Carrier_Party_1" BankHoldingID="Bank_Holding_1">
<ProductType tc="4">Variable Universal Life</ProductType>
<ProductCode>VUL-001</ProductCode>
<PlanName>American Variable Life</PlanName>
<ShortName>American VUL</ShortName>
<Life>
<Coverage>
<PlanName>American Universal Life</PlanName>
<ProductCode>VUL_BASE</ProductCode>
<LifeCovTypeCode tc="11">Variable Universal Life</LifeCovTypeCode>
<LivesType tc="1">Single life</LivesType>
<CovOption>
249
<PlanName>Accidental Death Benefit Rider</PlanName>
<LifeCovOptTypeCode tc="2">Accidental Death Benefit</LifeCovOptTypeCode>
</CovOption>
<CovOption>
<PlanName>No lapse Guarantee Option</PlanName>
<ProductCode>NLP</ProductCode>
<LifeCovOptTypeCode tc="9">No Lapse Guarantee Option</LifeCovOptTypeCode>
</CovOption>
<CovOption>
<PlanName>Disability Waiver of Premium Rider</PlanName>
<ProductCode>WPR02</ProductCode>
<LifeCovOptTypeCode tc="17">Waiver of Premium</LifeCovOptTypeCode>
</CovOption>
<LifeParticipant PartyID="Primary_Insured_Party_1">
<IssueAge>46</IssueAge>
<TobaccoPremiumBasis tc="2">Smoker</TobaccoPremiumBasis>
</LifeParticipant>
</Coverage>
<Coverage>
<PlanName>Terminal Illness Rider</PlanName>
<ProductCode>TI1</ProductCode>
<LifeCovTypeCode tc="2147483647">Other</LifeCovTypeCode>
</Coverage>
</Life>
<ApplicationInfo>
<FormalAppInd tc="1">true</FormalAppInd>
<Identification>
</Identification>
</ApplicationInfo>
<StatusEvent>
</StatusEvent>
</RequirementInfo>
<FinancialActivity>
<FinActivityType tc="7">Cash with Application</FinActivityType>
<FinActivityDate>2008-04-14</FinActivityDate>
250
<Payment BankHoldingID="Bank_Holding_1">
<PaymentAmt>200.00</PaymentAmt>
<SourceOfFundsTC tc="11">Income</SourceOfFundsTC>
</Payment>
</Policy>
<Investment>
<SubAccount id="Proposed_Holding_SubAccount_1">
<ProductCode>Growth Fund</ProductCode>
<ProductFullName>Fidelity Growth Fund</ProductFullName>
</SubAccount>
<ProductFullName>Ford Motor Co Common Stock</ProductFullName>
<CusipNum>345370860</CusipNum>
</SubAccount>
<ProductCode>GHI</ProductCode>
<ProductFullName>Fixed Account</ProductFullName>
</SubAccount>
</Investment>
<Attachment>
<AttachmentBasicType tc="2">Image</AttachmentBasicType>
<Description>Application</Description>
<AttachmentData>http://www.insuranceagency.com/files/attachimage.tiff</AttachmentData>
<AttachmentType tc="10">Original Application</AttachmentType>
<ImageType tc="3">TIFF</ImageType>
<AttachmentLocation tc="2">URL Reference</AttachmentLocation>
</Attachment>
<Intent>
<ExpenseNeedTypeCode tc="46">Employee Benefit</ExpenseNeedTypeCode>
</Intent>
<Arrangement id="Arrangement_Initial_Allocation">
<ProductCode>IA</ProductCode>
<ArrType tc="19">Initial Premium</ArrType>
<PlanName>Initial Premium</PlanName>
<ArrDestination id="Arrangement_IA_Destination" SubAcctID="Proposed_Holding_SubAccount_3">
</ArrDestination>
</Arrangement>
<Arrangement id="Arrangement_Standing_Allocations">
<ProductCode>SA</ProductCode>
<ArrType tc="37">Standing Allocations</ArrType>
<PlanName>Monthly Premium</PlanName>
<DestTransferAmtType tc="3">Percent</DestTransferAmtType>
<ArrSource id="Arrangement_SA_Source" BankingInfoID="Bank_Holding_1"/>
<ArrDestination id="Arrangement_SA_Destination_1"
SubAcctID="Proposed_Holding_SubAccount_1">
</ArrDestination>
<ArrDestination id="Arrangement_SA_Destination_2"
</ArrDestination>
</Arrangement>
<Arrangement id="Arrangement_Asset_Rebalancing">
<ProductCode>AR</ProductCode>
251
<ArrMode tc="1">Annually</ArrMode>
<ArrType tc="3">Asset Rebalancing</ArrType>
<ArrSubType tc="17">Standard Asset Rebalancing</ArrSubType>
<PlanName>Rebalancing Program</PlanName>
<ArrDestination id="Arrangement_Asset_Rebal_Dest_1"
</ArrDestination>
</ArrDestination>
</ArrDestination>
</Arrangement>
</Holding>
<Holding id="Bank_Holding_1" DataRep="ReadOnly">
<Banking FinancialInstitutionPartyID="EFT_Bank_Party_1">
<BankAcctType tc="2">Checking</BankAcctType>
<AcctHolderName>Slate Rock and Gravel</AcctHolderName>
<BankName>Washington Mutual Bank, Federal Savings Bank</BankName>
</Banking>
</Holding>
<Organization>
</Organization>
<Address>
<Zip>77201</Zip>
</Address>
<Phone>
</Phone>
</Party>
<Person>
<FirstName>George</FirstName>
</Person>
<Phone>
</Phone>
<Phone>
252
</Phone>
<Producer>
</Producer>
<EMailAddress>
<EMailType tc="1"/>
</EMailAddress>
</Party>
<Person>
<FirstName>Fred</FirstName>
<MiddleName/>
<Citizenship tc="1">United States</Citizenship>
<SmokerStat tc="2">prior tobacco user</SmokerStat>
<Height2>
</Height2>
<Weight2>
</Weight2>
<DriversLicenseNum>F12345</DriversLicenseNum>
<DriversLicenseState tc="5">Arkansas</DriversLicenseState>
<BirthCountry tc="1">United States</BirthCountry>
<BirthJurisdictionTC tc="5">Arkansas</BirthJurisdictionTC>
</Person>
<Address>
<Line1>343 Bedrock Ct.</Line1>
<Zip>72201</Zip>
<YearsAtAddress>4.00</YearsAtAddress>
</Address>
<Phone>
</Phone>
<Phone>
<PhoneTypeCode tc="2147483647">Other</PhoneTypeCode>
</Phone>
<EMailAddress>
253
</EMailAddress>
<Risk>
<RejectionReason/>
<ActivelyAtWorkInd tc="1">True</ActivelyAtWorkInd>
<CrimeDescription>Minor in Possession when 20 years old</CrimeDescription>
<SubstanceUsage>
<SubstanceType tc="8">Alcohol</SubstanceType>
</SubstanceUsage>
<SubstanceUsage>
<TobaccoType tc="2">Cigars</TobaccoType>
</SubstanceUsage>
<LifeStyleActivity>
<ForeignTravel>
</ForeignTravel>
</Risk>
<Employment EmployerPartyID="Primary_Insured_Employer_Party_1">
<Occupation>crane operator</Occupation>
<EmployerName>Slate Rock and Gravel Company</EmployerName>
<EmploymentDuties>heavy construction</EmploymentDuties>
</Employment>
</Party>
<Organization/>
<Address>
<Zip>72201</Zip>
</Address>
</Party>
<Person>
<FirstName>Wilma</FirstName>
</Person>
</Party>
<Party id="Coverage_Base_Contingent_Beneficiary_1">
<Person>
<MiddleName/>
254
</Person>
</Party>
<Party id="Carrier_Party_1">
<FullName>ABC Life Assurance Co.</FullName>
<Organization>
<OrgCode>ABCL</OrgCode>
</Organization>
<Carrier>
<CarrierCode>ABCL</CarrierCode>
<NAICCode>12345</NAICCode>
<NAICGroupCode>678</NAICGroupCode>
</Carrier>
</Party>
<Party id="EFT_Bank_Party_1">
<FullName>Washington Mutual Bank, Federal Savings Bank</FullName>
<Organization/>
<Address>
<Line1>987 Main St.</Line1>
<Zip>72201</Zip>
</Address>
</Party>
</Relation>
</Relation>
<Relation id="Contingent_Beneficiary_1_to_Policy" OriginatingObjectID="Proposed_Holding_1"
<RelationRoleCode tc="36">Contingent beneficiary</RelationRoleCode>
</Relation>
<Relation id="Agent_to_Policy_1" OriginatingObjectID="Proposed_Holding_1"
RelatedObjectID="Agent_Party_1">
<RelationRoleCode tc="37">PrimaryWritingAgent</RelationRoleCode>
</Relation>
<Relation id="Owner_to_Policy" OriginatingObjectID="Proposed_Holding_1"
<RelationRoleCode tc="8">Owner</RelationRoleCode>
</Relation>
<Relation id="Primary_Beneficiary_1_to_Primary_Insured_Party_1"
OriginatingObjectID="Primary_Insured_Party_1" RelatedObjectID="Coverage_Base_Primary_Beneficiary_1">
<RelationRoleCode tc="1">Spouse</RelationRoleCode>
<RelationDescription tc="2">Wife</RelationDescription>
</Relation>
<Relation id="Contingent_Beneficiary_1_to_Primary_Insured_Party_1"
255
OriginatingObjectID="Primary_Insured_Party_1" RelatedObjectID="Coverage_Base_Contingent_Beneficiary_1">
</Relation>
<Relation id="Payor_to_Policy_1" OriginatingObjectID="Proposed_Holding_1"
RelatedObjectID="Payor_Party_1">
<RelationRoleCode tc="31">Payor</RelationRoleCode>
</Relation>
</OLifE>
</TXLifeRequest>
</TXLife>
256
8
INDEX
AccountHolderName ............. 50
AccountNumber..................... 50
Address .................................. 19
AddressCountryTC ........ 20, 170
AddressStateTC ..................... 20
AddressTypeCode ................. 19
AddrLine................................ 68
ApplicationCollectionDate .... 24
ApplicationCounty................. 23
ApplicationJurisdiction .......... 22
ApplicationSignatureType ..... 24
AppliesToPartyID ................ 195
AppOwnerSignatureOK ........ 24
AreaCode ............. 179, 186, 187
AttachmentData ... 37, 38, 42, 54
AttachmentID .32, 36, 38, 42, 53
AttachmentKey ... 32, 36, 38, 42,
53
AttachmentLocation .. 37, 40, 44
AttachmentType .. 37, 39, 43, 54
AttentionLine ......................... 19
BankAccountType ................. 49
Banking.................................. 48
CarrierCode ....... 46, 55, 64, 181
City ........................................ 19
CommissionOptionSelected 183
CompletionDate ..................... 75
CreditCardExpDate ............... 49
CreditCardType ..................... 49
CryptPswd ........................... 227
CryptType ............................ 227
Description ................ 37, 38, 42
DialNumber ......................... 179
EmailAddress ........................ 68
EMailType ............................. 68
ExistingInsuranceInd ........... 199
Ext ....................................... 179
FinActivityDate ..................... 71
FinActivityType .............. 70, 72
Financial .......................... 70, 72
FinancialInstitutionPartyID ... 48
FormName ............................. 74
FormVersion .......................... 75
FullName .... 130, 141, 144, 148,
151, 159, 161, 164, 165, 167,
169, 172
GovtID 127, 130, 142, 148, 151,
159, 162
GovtIDTC ... 130, 142, 148, 151,
159, 162
Holding .... 76, 79, 83, 88, 93, 94
HoldingStatus....... 77, 79, 83, 89
HoldingTypeCode77, 79, 83, 88,
93, 94
HomeOfficePurchaseInd ........ 24
IDReferenceNo ... 132, 142, 144,
148, 152, 155, 159, 162, 165,
168, 173
InterestPercent ............. 191, 194
IssueType ............................. 182
LineOfBusiness .................... 181
MimeType .................. 40, 44, 54
NoResponseOk ... 229, 232, 235,
238
OriginatingObjectID ... 189, 190,
193
OriginatingObjectType 189, 190,
193
Party .... 127, 141, 144, 147, 151,
155, 158, 161, 164, 165, 167,
169, 172
Payment ............................... 175
Phone ........................... 178, 186
PhoneTypeCode ... 178, 186, 187
PolNumber ........................... 181
PrefAddr................................. 20
PrefEMailAddr ....................... 68
PrefPhone ............................. 179
PrimaryFormInd ..................... 74
ProductCode......................... 181
ProductType ......................... 181
ProviderFormNumber ............ 74
Pswd ..................................... 227
QuestionNumber .................... 75
RelatedObjectID ... 189, 190, 193
RelatedObjectType ...... 189, 190,
193
Relation ........ 189, 190, 193, 224
RelationDescription .............. 194
RelationRoleCode 189, 191, 193
ReplacementInd .............. 24, 199
ReqCode ............................... 195
ReqStatus.............................. 195
Requirement ......................... 195
ResidenceState ............. 131, 159
ResponseCode ........................ 75
ResponseText ......................... 75
ResponsiblePartyType .......... 196
Risk ...................................... 199
RoutingNumber ...................... 50
Signature .............................. 217
SignatureCode98, 101, 214, 217,
219
SignatureRoleCode. 98, 215, 217
SignedDate ............................. 23
SolicitationInd ........................ 68
SubmissionType ..................... 23
SubmitDate ............................. 75
SuitabilityPerformedInd ......... 24
TrackingID ............................. 22
TransExeDate ...... 229, 231, 234,
237
TransExeTime ..... 229, 232, 235,
238
TransferEncodingTypeString 40,
44
TransMode ... 229, 232, 235, 238
TransRefGUID .... 228, 231, 234,
237
TransType .... 228, 231, 234, 237
TXLifeRequest ..................... 226
UserAuthRequest ................. 226
UserDate ............................... 227
UserLoginName ................... 227
Zip .......................................... 20
257
9
REVISION HISTORY/CHANGE SUMMARY
Version
Date
Description of Change
2.0
January 2010
Update to version 2.21 and added variable, replacement, TXLife
response, risk information for part A and B, and business insurance
requirements. Also includes updates to how ongoing premiums
are mapped. Please see below for a detailed listing of changes:
1.0
Sept. 2008
1.0 – Proposed Final
May 2008
Official release. Published to the ACORD Web site and
teams.acord.org. No content changes. Documentation and
formatting changes only.
Proposed Final release for review / approval. Reformatting and
overall documentation updates.
258
9.1 Revision Details from version 1.0 to version 2.0
9.1.1 Updated from 2.17 to 2.21 & Other Misc Updates
A.
B.
C.
D.
E.
F.
G.
H.
I.
J.
K.
L.
M.
N.
Multiple updates based on approved MR‟s
Updated Authorization Object:
<Authorization> Object for changing investment instructions
Added AccountDesignation to Holding Object for Proposed Policy:
<Holding> Object for proposed policy
Updated Holding Object for existing insurance Object description and updated the
description for IssueDate: <Holding> Object for existing insurance
Updated Party Object for Proposed Insured: <Party> Object for Proposed Insured(s)
Updated Payment Object: <Payment> Object
Updated PhoneTypeCode on Phone Object: <Phone> Object
Updated RelationRoleCode and InterestPercent values on Relation:
<Relation> Object for contract level (Holding to Party)
Updated RequirementInfo Object: <RequirementInfo> Object
Multiple updates to Risk Object: <Risk> Object
Added SignatureInfo Object: <SignatureInfo> Object
Updated: APPENDIX C – New Business Policy Status Transitions
Updated: Life electronic application submission hierarchy
Added APPENDIX D – Requirmement Status Transitions
9.1.2 FinancialActivity & Arrangements
A.
B.
C.
Deleted FinancialActivity Object for ongoing premiums
Added Arrangement Object and details: <Arrangement> Object
Updated section 3.3 FinancialActivity and Arrangement
9.1.3 Added Variable Life Requirements
A.
B.
Added Investment Object (without properties): <Investment> Object
Updated ProductType values, object description and added PolicyValue on Policy Object:
C.
Added SubAccount Object and details:<SubAccount> Object
D.
Added VL Sample XML: NBfL Sample Scenario 2: Basic Variable Universal Life
Insurance Submission
9.1.4 Added Replacement & Exchange Requirements
A.
B.
C.
D.
E.
Added FinancialActivity Object for 1035 Exchange:
<FinancialActivity> Object for 1035 Exchange
Added Holding Object for Existing Insurance That Is Being Replaced
<Holding> Object for existing insurance that is being replaced
Added Holding Object for Existing Insurance That Is Being Exchanged
<Holding> Object for existing insurance that is being exchanged
Updated Life Object to include, NetSurrValueAmt, CashValueAmt, DeathBenefitAmt,
SurrenderChargeAmt & NetDeathBenefitAmt as well as other misc updates:
<Life> Object
Added LifeUSA Object for existing policy:
259
F.
G.
H.
<LifeUSA> Object for existing policy
Added LifeUSA Object for proposed policy:
<LifeUSA> Object for the proposed policy
Updated Payment.PaymentForm to include tc=13 Funds to Follow for 1035 Exchanges,
and tc=26 Payment is made from another policy: <Payment> Object
Added Relation Object for contract level (Holding to Holding):
<Relation> Object for contract level (Holding to Holding for Replacements/Exchanges)
9.1.5 Updated TXLife Request & Added TXLife Response Requirements
A.
B.
C.
D.
Updated TXLife Request Object: <TXLifeRequest> Object
Added TXLife Response Object for Success:
<TXLifeResponse> Object for Success-IGO Response
Added TXLife Response Object for Failure:
<TXLifeResponse> Object for Failure-NIGO Response
Added TXLife Response Object for Pending:
<TXLifeResponse> Object for Pending Response (Performing Checks)
9.1.6 Added Part A & B Requirements
A.
B.
C.
D.
E.
F.
G.
Added Applicability property to various places within the guide
Added MedicalCondition Object: <MedicalCondition> Object
Added MedicalExam Object: <MedicalExam> Object
Added MedicalPrevention Object: <MedicalPrevention> Object
Added MedicalTreatment Object: <MedicalTreatment> Object
Added PrescriptionDrug Object: <PrescriptionDrug> Object
Added WeightHistory Object: <WeightHistory> Object
9.1.7 Add Business Insurance Requirements
A.
B.
C.
D.
E.
F.
G.
Updated Employment Object description: <Employment> Object
Added Holding for Loan Object: <Holding> Object for Loan
Added OrganizationFinancialData Object:
<OrganizationFinancialData> Object for Business Insurance
Added Party Object for other business insurance owners:
<Party> Object for other business insurance owners
Updated Party Object for organizational owner: <Party> Object for organization owner
Added Party Object for creditor on collateral loan:
<Party> Object for creditor on the collateral loan
Added additional RelationRoleCode value on Relation Object:
<Relation> Object for contract level (Party to Party)
260
APPENDIX A – HOW TO MODEL ROLES
Contract Level
Component Level
Override Level
Role applies to entire contract.
Role must be specified for each
component.
Role is inherited by every component
unless specified.
Must Have Relation Object
May Have Relation Object
May Have Relation Object
May Have Life Participant Object
Must Have Life Participant Object on
Every Coverage
Must Have Life Participant Object on Any
Override Coverage
1
Contract Level Role
Holding
Relation
RelRoleCode=
32
Party
(Insured)
If Insured is the Owner
Relation
RelRoleCode =
8
Relation
RelRoleCode=34
Includes additional
information about the
beneficiary
relationship
If Insured is
not the Owner
Party
(Owner)
Party
(Bene)
2
Component Level Role
Relation
RelRoleCode=32
Holding
Party
(Insured)
Coverage
(Base)
LifeParticipant
Coverage
Child Rider
LifeParticipant
Party
Child
Coverage
ADB
LifeParticipant
3
Override Level Role
Holding
Relation
RelRoleCode=32,189
Party
(Insured -Husband)
Coverage
(Base)
Party
(Insured - Wife
LifeParticipant
LifeParticipant
Coverage
ADB
Coverage
Waiver of Premium
LifeParticipant
4
Comparison of the Three Levels of Roles
Component
Level
Contract Level
Holding
Relation
RelRoleCode=
32
Party
(Insured)
Relation
RelRoleCode
=8
Party
(Owner)
Relation
RelRoleCode
=34
Relation
RelRoleCode=
32
Holding
Override Level
Party
(Insured)
Relation
RelRoleCode=
32
Holding
Coverage
(Base)
Coverage
(Base)
LifeParticipant
LifeParticipant
Party
(Bene)
LifeParticipant
Coverage
Child Rider
Party
Child
Coverage
ADB
LifeParticipant
Coverage
Waiver of
Premium
Coverage
ADB
LifeParticipant
LifeParticipant
5
Party
(Insured Joint)
Party
(Insured Joint
APPENDIX B – SAMPLE XML FOR BENEFICIARY ROLES
Contract Level:
In most cases, there will be 2 Relations:
- a Holding to Party Relation that denotes who the beneficiary is
- a Party to Party Relation that denotes the relation of the beneficiary to the insured
1. The beneficiary is a named person

<Holding id="Holding_1" >
<HoldingStatus tc="3">Pending</HoldingStatus>
</Holding>

<Party id="Party_1">
<Person>
</Person>
</Party>

<Person>
</Person>
</Party>

<Relation RelatedObjectID="Party_1" OriginatingObjectID="Holding_1" id="Relation1_1">
<RelationRoleCode tc="6">Primary Insured</RelationRoleCode>
</Relation>

<Relation RelatedObjectID="Party_2" OriginatingObjectID="Holding_1" id="Relation2_1">
© 2008-2010 ACORD CORPORATION – ALL RIGHTS RESERVED
6
</Relation>
If the only properties needed are InterestPercent and BeneficiaryDesignation for a beneficiary, place them
on Relation. If additional properties are needed, they also go on Relation. (This is different than any of the
other policy roles. See Help File 4.16 for additional information.).

<Organization>
<OrgForm tc="1">Sole Proprietorship</OrgForm>
</Organization>
</Party>

<Relation RelatedObjectID=" Party_11 " OriginatingObjectID="Holding_1" id="Relation2_1">
7
</Relation>
4. The beneficiary is a trust
The trust may have a trustee. The trustee is never the beneficiary. There will be one Relation to denote
the bene. There will not be a Relation from the insured to the trust to describe the relation of the trust to
the insured. The can be a Party to Party Relation for the Relation of the Trustee to the Trust.

<FullName>name of trust</FullName>
<Organization>
</Organization>
</Party>

<Person>
<FirstName>Joe</FirstName>
<LastName>Black</LastName>
</Person>
</Party>

<Relation RelatedObjectID=" Party_12" OriginatingObjectID="Holding_1" id="Relation2_1">
</Relation>

<Relation RelatedObjectID="Party_13" OriginatingObjectID ="Party_12" id="Relation15a_1">
<RelationRoleCode tc="69">Trustee</RelationRoleCode>
</Relation>
5. The beneficiary is a creditor and the creditor is an organization
Where the organizations listed above ( in example 3) do not have a Relation from the insured to the bene,
when the organization is a creditor, there is a relation from the insured to the bene. There is no OrgForm
for this organization since creditor is not an OrgForm.
8

<FullName>Creditor name</FullName>
<Organization></Organization>
<OrgForm tc=”0”>Unknown</OrgForm>
</Party>

<Relation RelatedObjectID=" Party_14" OriginatingObjectID="Holding_1" id="Relation2_1">
</Relation>

<Relation RelatedObjectID="Party_14" OriginatingObjectID="Party_1" id="Relation3_1c">
<RelationRoleCode tc="109">Creditor</RelationRoleCode>
</Relation>
9
Component Level:
There is no need for Relation objects, both the designation of the beneficiary class and the relation to the
insured can be described in the LifeParticipant object. The beneficiary must explicitly denoted for each
coverage (base and all riders) where appropriate as nothing can be assumed about who the beneficiary
is.
1. The beneficiaries are named persons
<Holding id="Holding1" >
<Policy>
<Life>
<Coverage>
<LifeParticipant PartyID="Party2_1">
<LifeParticipantRoleCode tc="7">PrimaryBeneficiary</LifeParticipantRoleCode>
<ParticipationPct>100</ParticipationPct>
<BeneficiaryRoleCode tc="2">Child</BeneficiaryRoleCode>
<BeneficiaryRoleCodeDesc tc="5">Son</BeneficiaryRoleCodeDesc>
</LifeParticipant>
</Coverage>
<Coverage>
<LifeCovTypeCode tc="23">Accidental Death Benefit</LifeCovTypeCode>
</LifeParticipant>
</Coverage>
<Coverage>
<LifeCovTypeCode tc="116">Child Term</LifeCovTypeCode>
</LifeParticipant>
</Coverage>
</Life>
</Policy>
</Holding>
10

<Person>
</Person>
</Party>

<Person>
<FirstName>Phil</FirstName>
</Person>
</Party>
2. The beneficiaries are unnamed
Both the beneficiary for the contract and the beneficiary for the rider are unnamed.
<Policy>
<Life>
<Coverage>
< LifeParticipant>
<BeneficiaryDesignation tc="13">Children of insured</BeneficiaryDesignation>
</LifeParticipant>
</Coverage>
<Coverage>
<LifeParticipant>
<BeneficiaryDesignation tc="2">Estate</BeneficiaryDesignation>
</LifeParticipant>
</Coverage>
</Life.
</Policy>
</Holding>
11
3. The beneficiaries are organizations
There may not be a BeneficiaryRoleCode to describe the relationship of the organization to the insured.
(See example 5 for exception) The Party object OrgForm describes the type of organization.
<Policy>
<Life>
<Coverage>
<LifeParticipant PartyID=" Party11_1a ">
</LifeParticipant>
</Coverage>
<Coverage>
<LifeParticipant PartyID=" Party11_1b ">
</LifeParticipant>
</Coverage>
</Life>
</Policy>
</Holding>

<Organization>
</Organization>
</Party>

<Party id="Party11_1b">
<Organization>
</Organization>
</Party>
12
4. The beneficiaries are trusts
The trusts may have a trustees. A trustee is never the beneficiary. LifeParticipant will denote the bene
class . A Party to Party Relation is used to denote the Relation of the Trustee to the Trust.
<Policy>
<Life>
<Coverage>
<LifeParticipant PartyID=" Party11_1c ">
</LifeParticipant>
</Coverage>
<Coverage>
<LifeParticipant PartyID=" Party11_1d ">
</LifeParticipant>
</Coverage>
</Life.
</Policy>
</Holding>

<Party id="Party11_1c">
<Organization>
</Organization>
</Party>

<Party id="Party11_1d">
<Organization>
</Organization>
</Party>

13
<Person>
<FirstName>Joe</FirstName>
<LastName>Black</LastName>
</Person>
</Party>

<Relation RelatedObjectID="Party12_1" OriginatingObjectID ="Party11_1c" id="Relation15a_1">
</Relation>

<Relation RelatedObjectID="Party12_1" OriginatingObjectID ="Party11_1d" id="Relation15b_1">
</Relation>
5. The beneficiaries are creditors and the creditors are organizations
Where the organizations listed above ( in example 3) may not have a BeneficiaryRoleCode, this
organization does have a relation from the insured to the bene that is represented by the
BeneficiaryRoleCode but does not have an OrgFrom.
<Policy>
<Life>
<Coverage>
<LifeParticipant PartyID=" Party11_1e ">
<BeneficiaryRoleCode tc="109">Creditor</BeneficiaryRoleCode>
</LifeParticipant>
</Coverage>
<Coverage>
<LifeParticipant PartyID=" Party11_1f ">
<BeneficiaryRoleCode tc="109">Creditor</BeneficiaryRoleCode>
</LifeParticipant>
</Coverage>
</Life.
14
</Policy>
</Holding>

<Party id="Party11_1e">
</Party>

<Party id="Party11_1f">
</Party>
Override Level:
There is no need for Relation object, both the designation of the beneficiary class and the relation to the
insured can be described in the LifeParticipant object. The sample XML is the same for Component Level
beneficiary role except that the beneficiary does not need to be denoted for every coverage – just the
base coverage and if there are any overrides.
15
APPENDIX C – NEW BUSINESS POLICY STATUS TRANSITIONS
POLICY STATUS TRANSITIONS – FORMAL APPLICATION
(Applies to new business, but not to reissues, reinstatements or conversions)
Status is a milestone in the fulfillment process
A
G
E
N
T
/
V
E
N
D
O
R
LEGEND
1. Green shaded Statuses represent normal (positive) flow
2. Text imbedded on flow lines represents Status Reasons for why
application is moving to next Status
3. Items in black are existing TC values, in red are proposed values.
4. Numbers in parentheses are existing Type Codes
5. Italicized blue text is additional information
6. Square loop connectors show Status
Reasons that are keeping application
from moving to next Status
PROPOSED (12)
Unapproved licensing
or appointment (40),
Producer not approved
to sell (39)
Wrong company
PENDING
TRANSMISSION (22)
APPLIED FOR
(21)
Request accepted
by carrier
REQUEST REFUSED
(109)
A
Missing information/requirements,
Pre underwriting review not
complete
Application accepted
for processing
Missing information/
Requirements
not provided
PENDING (8)
INCOMPLETE (23)
Application complete
and IGO
Missing information/requirements,
Underwriting review ,
Unapproved licensing /
appointment(40),
Appeal(38),
Changes Requested
Missing information/requirements
Unapproved licensing or appointment (40)
SUBMITTED TO
UW (954)
INCOMPLETE (23)
Lack of suitablity, Medical history,
Life style, Financial reasons,
Not eligible
DECLINE (27)
(Final Status)
DEFERRED (29)
C
A
B
CANCELLED (39)
(Applicant)
(Final Status)
APPROVED
TENTATIVE OFFER
(58)
PRODUCER
WITHDREW (60)
(Final Status)
R
R
Effective date not reached,
Issue pending
I
E
◄
R
HO WITHDREW (59)
(Final Status)
APPROVED (24)
◄
Issued as applied for
Delivery
Requirements
Pending(46)
ISSUE WITH
REQUIREMENTS
(44)
ISSUED WITH
CHANGES (43)
(Non-material)
Policy
Addition/
Change
in Progress
(33)
Material changes requested
ISSUED (25)
A
Delivery Requirements not Satisfied,
Not Paid
COUNTER OFFER
(26)
(Material changes)
Delivery Requirements
Satisfied(47)
ACTIVE (1)
(Final Status)
B
NOT PLACED (51)
Placed, In-Force
Applicant declined
offer(35)
Applicant declined
offer (35)
NOT TAKEN (7)
16
Policy Status Transitions – Formal Application
(Applies to new business, but not to reissues, reinstatements or conversions)
Status is a milestone in the fulfillment process
Process for adding new values to the PolicyStatus and StatusReason lookup tables:
1. Review latest version of PolicyStatus and StatusReason lookup tables.
2. If the status that is to be added is not represented in the lookup table
a. Create a definition for the status or reason that is to be added to the lookup table
b. Compare the new definition to existing status and reason definitions - the new
status may already exist but may be named differently than expected
c. Check both PolicyStatus and StatusReason tables - many requests to add new
statuses are really StatusReasons. A StatusReason is the explanation as to why
the status has not moved to the next expected status.
d. If the new status definition does not align with any existing status or reason
definition, then determine the placement of the new status or reason in the Policy
Status diagram
e. If the new status or reason can be placed on the diagram without duplicating an
existing status, create an MR to update the lookup table and the Policy Status
diagramNote: The Policy Status diagram should be incorporated into both the
Pending Case Status Guide and the New Business Submission guide.
17
APPENDIX D – REQUIRMEMENT STATUS TRANSITIONS
Please refer the 3.3 Underwriting Requirements Status and Status Events section of the ACORD
Underwriting Requirements Implementation Guide for further details.
Start
ReqStatus Transitions
ReqStatuses typically
assigned by Requester
Systems
Outstanding
(4)
Submit (192)
Submitted (2)
Acknowledge (182)
Acknowledged
(19)
Error (12)
Error (186)
Error (186)
Provider Accepts Order (75)
Resume (191)
Pending (1)
Warn (193)
Cancelled (8)
Cancel (184)
Complete (185)
Completed
with Warnings
(13)
assigned by Fulfilling
Systems
Completed
(11)
Resume (191)
Publish (188)
Publish (188)
Published (20)
Resume (nn): When a requirement is
in ReqStatus Unable to Evaluate (10),
it may remain in that state while corrective
action occurs, or transition to Pending via
Resume (nn)
Receive (189)
Received (7)
Evaluation
Failed (190)
Unable to
Evaluate (10)
Evaluate (187)
Evaluated (21)
assigned by Status/Results
Receiver Systems
End
Author:
Version:
Created:
Updated:
jbielak
1.3
06/06/2004
11/06/2004
18

ACORD Standards Implementation Guide Template Life

Transcription

Similar documents

Mac Survey - McCreery Aviation Co., Inc

MARQ Comparison Sheet - Marq Packaging Systems

R3310 POS Series

SEP 8x8

The Jasper IV atThe Woodlands at Bear Creek

FluorPen Features FluorPen Applications

iROAR Meal Plan Sign Up Instructions

402KL Mechanical Beam Scale Advantages

portico - Epcon Communities