acord lah ppfa implementation guide v2.2 jan 2009

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.

ACORD LIFE, ANNUITY & HEALTH STANDARDS PRODUCT PROFILE FOR ANNUITIES (PPFA)

IMPLEMENTATION GUIDE VERSION 2.2, JANUARY 2009

(*DOCUMENTATION CHANGE ONLY. NO CONTENT CHANGES MADE.)

Based on ACORD Life Standards ACORD Public Life Specification 2.11.02 ACORD Revisions 2.11 (indicated by *)

ACORD Release Candidate for 2.12 (indicated by +)

*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 3rd 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

http://legal.acord.org/standards_license.htm

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Table of Contents CHAPTER 1 – BACKGROUND .............................................................................................................................. 1

THE ANNUITY PRODUCT PROFILE ........................................................................................................................ 1 ACKNOWLEDGEMENTS ........................................................................................................................................ 1

CHAPTER 2 – PRODUCT PROFILE OBJECTIVES .............................................................................................. 2 INDUSTRY INITIATIVE ........................................................................................................................................... 2 XML STANDARD................................................................................................................................................. 2 PROFILE HIGHLIGHTS.......................................................................................................................................... 2 DISTRIBUTION & USE OF THE PROFILE ................................................................................................................. 3 THE ROLES OF ACORD & NAVA ....................................................................................................................... 3 USE & UPDATE OF THE ACORD STANDARD........................................................................................................ 4

CHAPTER 3 – GUIDING PRINCIPLES FOR IMPLEMENTATION ........................................................................ 5 CHAPTER 4 – OBJECT HIERARCHY, DETAILED ELEMENT DESCRIPTIONS & TYPE CODES...................... 9

<ADDRESS> OBJECT ........................................................................................................................................ 12 <ALLOCTYPEPRODUCT> OBJECT ..................................................................................................................... 14 <ALLOWEDRELATIONSHIP> OBJECT ................................................................................................................. 16 * <AMOUNTPRODUCT> OBJECT (04-1.01.AN246)............................................................................................. 18 <ANNUITYPRODUCT> OBJECT........................................................................................................................... 19 <ANNUITYPRODUCTEXCLUDE> OBJECT ............................................................................................................ 21 <AUTHORIZATION> OBJECT .............................................................................................................................. 22 <AUTHORIZATIONTRANSACTION> OBJECT......................................................................................................... 23 <BREAKPOINT> OBJECT ................................................................................................................................... 24 <BUSINESSPROCESSALLOWED> OBJECT.......................................................................................................... 25 <CARRIER> OBJECT ......................................................................................................................................... 26 <CARRIERAPPOINTMENT> OBJECT ................................................................................................................... 27 <CHARGEPCTSCHEDULE> OBJECT ................................................................................................................... 28 <COMMISSIONPRODUCT> OBJECT .................................................................................................................... 29 <COMMFORMULA> OBJECT .............................................................................................................................. 30 <COMMOPTIONAVAILABLE> OBJECT ................................................................................................................ 31 <COMMREMITTANCE> OBJECT.......................................................................................................................... 32 <COMMSCHEDULE> OBJECT............................................................................................................................. 34 <DESTINVESTPRODUCT> OBJECT ..................................................................................................................... 35 <DISTRIBUTIONAGREEMENT> OBJECT............................................................................................................... 36 <DISTRIBUTIONAGREEMENTINFO> OBJECT ....................................................................................................... 37 <ENTITYTYPE> OBJECT .................................................................................................................................... 38 <EXCLUSIONINVESTPRODUCT>OBJECT............................................................................................................. 39 <FEATURECONFLICT> OBJECT ......................................................................................................................... 40 <FEATUREOPTCONFLICT> OBJECT................................................................................................................... 41 <FEATUREOPTPRODUCT> OBJECT ................................................................................................................... 42 <FEATUREOPTREQUISITE> OBJECT .................................................................................................................. 48 <FEATUREPRODUCT> OBJECT.......................................................................................................................... 49 <FEATUREREQUISITE> OBJECT ........................................................................................................................ 53 <FEE> OBJECT................................................................................................................................................. 54 * <FREELOOKINVESTRULEPRODUCT> OBJECT (04-1.01.AN216) ...................................................................... 57 <FUNDINGSOURCEMETHODSALLOWED> OBJECT .............................................................................................. 58 <INCOMEOPTCONFLICT> OBJECT ..................................................................................................................... 60 <INCOMEOPTREQUISITE> OBJECT .................................................................................................................... 61 <INCOMEOPTIONINFO> OBJECT ........................................................................................................................ 62 <INCOMEPAYOUTPRODUCTOPTION> OBJECT.................................................................................................... 63 <INFORMATIONSERVICE> OBJECT..................................................................................................................... 67 <INVESTPRODUCT> OBJECT ............................................................................................................................. 68

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

<INVESTPRODUCTINFO> OBJECT ...................................................................................................................... 73 * <INVESTRULEPRODUCT> OBJECT (04-1.01.AN216)....................................................................................... 75 <JURISDICTIONAPPROVAL> OBJECT ................................................................................................................. 76 * <NUMINVESTPRODUCT> OBJECT (04-1.01.AN247) ........................................................................................ 79 <ORGANIZATION> OBJECT................................................................................................................................ 80 <OWNERSHIP> OBJECT .................................................................................................................................... 81 <PARTY> OBJECT ............................................................................................................................................ 84 <PAYMENTMODEMETHPRODUCT> OBJECT ....................................................................................................... 85 <PERIODCERTAINCC> OBJECT......................................................................................................................... 88 <POLICYPRODUCT> OBJECT............................................................................................................................. 89

Indicates the nation in which the product will be sold. .......................................................................................................................... 91 <POLICYPRODUCTINFO> OBJECT...................................................................................................................... 94 < PRODUCER > OBJECT .................................................................................................................................... 96 <QUALIFIEDPLANENTITY> OBJECT ................................................................................................................... 97 * <RATINGAGENCYINFO> OBJECT (04-1.01.AN252) ........................................................................................ 98 <RATEVARIATION> OBJECT.............................................................................................................................. 99 <SOURCEINVESTPRODUCT> OBJECT .............................................................................................................. 100 <SURRENDERCHARGESCHEDULE> OBJECT .................................................................................................... 101

CHAPTER 5 – TRANSMITTING PPFA............................................................................................................... 102 COMMON ELEMENTS ....................................................................................................................................... 102

CHAPTER 6 – XTBML SPECIFICATION FOR A PRODUCT PROFILE FOR ANNUITY .................................. 103 <XTBML> OBJECT......................................................................................................................................... 104 <TABLE> OBJECT........................................................................................................................................... 105 <AXIS> OBJECT ............................................................................................................................................. 106 <AXISDEF> OBJECT ....................................................................................................................................... 107 <CONTENTCLASSIFICATION> OBJECT ............................................................................................................. 110 <KEY> OBJECT .............................................................................................................................................. 111 <KEYDEF> OBJECT ........................................................................................................................................ 112 <METADATA> OBJECT ................................................................................................................................... 114

Indicates the nation in which the product will be sold. ........................................................................................................................ 114 <VALUES> OBJECT......................................................................................................................................... 115

CHAPTER 7 - TRANSMITTING/SENDING A PRODUCT PROFILE FOR ANNUITY........................................ 116 <USERAUTHREQUEST> OBJECT ..................................................................................................................... 117 <VENDORAPP> OBJECT ................................................................................................................................. 118 <PROXYVENDOR> OBJECT ............................................................................................................................. 119 <TXLIFEREQUEST> OBJECT........................................................................................................................... 120

APPENDIX A - PRODUCT PROFILE FOR ANNUITY OBJECT DIAGRAMS .................................................... 122 Diagram IA: TXLife Wrapper............................................................................................................................................................... 122 Diagram IB: TXLife OLifE Overview ................................................................................................................................................... 123 Diagram II: InvestProduct .................................................................................................................................................................. 124 Diagram III: PolicyProduct ................................................................................................................................................................. 125 Diagram IV: AnnuityProduct .............................................................................................................................................................. 126 Diagram V: Ownership....................................................................................................................................................................... 127 Diagram VI: Commission ................................................................................................................................................................... 128 Diagram VII: XTbML – Commission Profile for Annuity ...................................................................................................................... 129

APPENDIX B - TERMINOLOGY......................................................................................................................... 130 APPENDIX C....................................................................................................................................................... 135 INDEX.................................................................................................................................................................. 141 REVISION HISTORY .......................................................................................................................................... 143

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 1 Chapter One – Background

CHAPTER 1 – BACKGROUND

ACORD and NAVA, The National Association of Variable Annuities, through the ACORD Annuity Enhancements and Implementations Working Group (formerly known as Product Profile for Annuity Working Group) have developed this Product Profile for Annuity Implementation Guide to define how companies can provide detailed annuity product information to their trading partners, in particular to sales platforms intended to gather annuity new business applications and subsequent premium detail (a.k.a. annuity trades), so systems receiving this information have all the detail necessary to produce well-formed information for electronic processing.

The Annuity Product Profile

This Guide defines the basic Product Profile for Annuity (officially referred to as a PolicyProduct Transmittal #1201 in the ACORD TXLife Specification, and abbreviated PPfA) and includes details necessary to prepare a well-formed annuity sales application as well as supporting details such as investment (fund) information and information on the selling agreements/commissions necessary to fully support commission calculations at the point of sale.

A companion Guide, the New Business for Annuities Implementation Guide (or NBfA) details the resulting well-formed annuity sales application and subsequent premium transactions supported and enabled by the PPfA.

The NBfA Guide includes further information regarding the mapping between the Product Profile for Annuities and the New Business for Annuities, including product to new business sample “snippets” of messages.

The Product Profile for Annuities Implementation Guide (the “Guide”) has been produced to direct and assist development teams in building systems that use sections of the ACORD Life Standard (the “ACORD Standard) related to annuity products. This guide provides a comprehensive, field-by-field definition of all data elements covered in the standard and the associated type codes as they pertain to an annuity product profile. It is intended to serve as a reference document to specify what information a Product Profile for Annuity definition should have as well as how the information should be structured and how the standard can be used in support of different basic contract and feature scenarios.

Acknowledgements

This guide, and the expansion of the ACORD Life Standards to support it, was the culmination of several years' work and the commitment and dedication of over one hundred volunteers representing every facet of the insurance industry. It was initiated and is strongly supported by NAVA and its members who have made this their reference standard and an integral part of their overall vision for straight-thru-processing of annuities. ACORD is very appreciative of the excellent on-going working relationship between NAVA and ACORD.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 2 Chapter Two – Product Profile Objectives

CHAPTER 2 – PRODUCT PROFILE OBJECTIVES

Today, the sharing of annuity product information and specifications is a laborious, time-consuming and error-prone process. This is due primarily to the lack of automation, non-standard processes and reliance on non-uniform paper products. The information exchange between two trading partners is highly varied – it may be in glossy brochure, an Excel spreadsheet, a WordPerfect document, email, fax or even verbally over the phone or at a meeting. Typically it is a combination of all the above. This is one of the reasons that in many instances there are numerous errors and ambiguities within applications, as well as needless delays within the policy issuance process. The anticipated expansion of automated annuity order entry systems lent urgency to developing an automated process for carriers to use in efficiently communicating product-related information. The addition of pre-sale commission information provides a better way to exchange information critical to annuity commission processing, thereby reducing overhead, redundancy, and constant format changes. Commission information critical to annuity order entry such as available commission options are exchanged.

Industry Initiative

The annuity industry, led by NAVA and ACORD has developed a standard definition of a Product Profile for Annuities. The primary objective is to define the basic set of information and business rules necessary to complete and submit a well-qualified, fully formed, complete application for an annuity product, either variable or fixed. The result is a common industry standard for what information should be shared between all trading partners. With this as the base, the standard can also be extended to include product-related information in support of the marketing and product selection processes.

XML Standard

XML provides an effective way of specifying data in support of electronic data exchange between organizations. By definition, it is extensible, meaning additional data can be added to an XML file with minimal effort. Its self-describing characteristic makes it easy to read and parse for programming. Perhaps most importantly, it is based on a stateless protocol (HTTP), thus allowing transmission of data real-time over the Internet to any platform. These are just three of many advantages XML provides as a standard format for product profile of annuity contracts.

Profile Highlights

• It’s an xml specification (with all the benefits of xml), • Based on the ACORD industry standard XML for life schema, • With implementation guidelines from Nava that defines 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 lists with agreed upon meanings (e.g. dca program types, etc.), • Developed by annuity industry and technology experts within Nava and ACORD.


So now instead of this: You have this: The Product Profile messages are based on the ACORD XML for Life Schema, which provides the structure and syntax for all the agreed to elements (fields) along with their assigned values (type codes). Currently this is XMLife 2.9. Those items indicated with a ‘’ were added in the 2.9 version. Those items indicated with a ‘(*)’ were being requested and approved in November 2003 for inclusion in the next version, 2.10.

Distribution & Use of the Profile

One can either manually (using a text editor or other tool) create the XML text file for distribution to trading partners or use an ever-growing arsenal of commercial tools to programmatically create an XML document (or “stream” as its called when it is just sent between machines). There are Financial Services/Insurance/Annuity specific tools or generic tools available.

Recipients/users of this document/stream would program their databases to receive these files and apply a mapping of the ACORD specification to their own proprietary database data model. The elegance of this approach is everyone knows what to expect – what to send, and what they will receive. Each sender/provider of this information only needs to develop their formats one time. It becomes one document, one source, one place to fix errors or omissions, and one document to update. Recipients/users know exactly what to expect, they get information they can use programmatically. They receive it from a single source and always in a consistent form from all providers. The same is true for updates – which dramatically reduces the workload.

The Roles of ACORD & NAVA

These two industry trade associations have joined forces to providing the structure and forum for this effort. ACORD will continue, as it has for over 30 years, to maintain and extend the overall data model for insurance, this effort being a subset of the overall ACORD Life, Health, Disability and Annuity XML for Life Data Model. NAVA will continue to drive the development of more annuity industry improvements, to provide the forum for developing implementation guides, real-life case studies, and peer support.

XML PPfA

One-To-One Sharing, All Different One-To-Many Sharing, All Same


Use & Update of the ACORD Standard

The strength in the standards ACORD supports for the life insurance industry lies in the data model. A significant effort has gone into modeling the data the life insurance industry needs to communicate with one another. This model, represented in a data object hierarchy form, has already been applied to a variety of software applications by a large number of carriers across the globe. By applying this data model to all the standards ACORD supports, the industry receives three major benefits:

• REUSABILITY – NO NEED TO REINVENT THE WHEEL. ACORD HAS LEAPFROGGED OTHER INDUSTRIES IN THE ABILITY TO DEFINE XML-BASED STANDARDS – WITH A REUSABLE DATA MODEL.

• EXPANDABILITY –CAN EASILY 'PLUG IN' NEW DATA REQUIREMENTS OF THE STANDARDS-SETTING EFFORTS TO THE DATA

HIERARCHY, EXPANDING ON PREVIOUS WORK RATHER THAN BREAKING AND STARTING OVER. ACORD CAN SUPPORT CRITICAL FUNCTIONS LIKE BACKWARD COMPATIBILITY AND INTEROPERABILITY.

• INTEROPERABILITY – KEEPING THE DATA MODEL INTACT IS CRITICAL TO ACHIEVING INTEROPERABILITY WITHIN THE LIFE

INSURANCE INDUSTRY. BACK OFFICE SYSTEMS THAT PROCESS TRANSACTIONS AND SEND DATA FEEDS BACK AND FORTH TO DESKTOPS CAN USE A STANDARD THAT IS BASED DIRECTLY OFF THE ACORD LIFE DATA MODEL, PROVIDING 100% INTEROPERABILITY BETWEEN THE COMPONENTS THAT MAKE UP THE ENTERPRISE AND ENSURING THAT ALL THE PIECES FIT TOGETHER.

How the Model Works Each of the boxes in the data model represents an object. For each of these objects, a comprehensive set of data requirements is defined. The result is hundreds of pages of documentation defining the details within the data model. The model follows a data object hierarchy. This approach is highly portable to today's technologies and provides the most flexibility when implementing. Furthermore, ACORD modeled the data in such a fashion that as additional product lines are added, the model can easily be expanded to include those product lines.

Data outside the model As ACORD builds out the model, there will always be data elements that do not end up within the model. This could be because of the phased development approach, or more likely because an element is a proprietary requirement that does not belong in a standard. In all implementations of the data model, a way to extend the model to support unique requirements is provided. This allows the standard to be applied for cross-application communication, and still be functional within a proprietary implementation, allowing the standard to be fully adopted across the enterprise.

There are two ways to extend XMLife for proprietary information:

KeyedValues

Use of OLifEExtension element

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 5 Chapter Three – Guiding Principles for Implementation

CHAPTER 3 – GUIDING PRINCIPLES FOR IMPLEMENTATION

The following section is intended to provide some general guidelines in implementing the NAVA/ACORD XML standard for Product Profile for Annuities (PPfA) and to support validation of new applications and subsequent premiums. 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. General

• The PPfA is intended to communicate annuity product specifics related to anew business (order entry) and subsequent premiums. More complex or comprehensive product definition to enable post-issue processing has not been undertaken.

• There are fields in the ACORD model that are required fields only for usage and implementation of a Product Profile for Annuities. For example, <CusipNum> in the <PolicyProduct> object is required in the PPfA XML. If a field is not a required field for PPfA usage and the value of the field is unknown, an empty tag should not be used and the field should simply not be included. An empty tag is used when the value of a field is known to be blank.

• Use the schema to determine the order of objects and properties. Neither this Guide nor the UMLs claim to represent the technical ordering requirements of the schema.

• Systems should process on the type code value, not the literal text values in the XML. Text is optional, but it is recommended for readability. For example, <jurisdiction tc= “52”/>, is all that is needed. The text 'UT' corresponding to tc= “52” is not necessary.

• A parent object can have none, one or many child objects. Specific PPfA usage regarding the relationships between parent and children objects, and, if applicable, how many children are allowable, is available in the UMLs in the Diagrams section of this guide.

• If the relationship between parent object and child object is one-to-many, a new instance of the child object does not need a new instance of the parent object. For example, given the one-to-many relationship between <AnnuityProduct> and <FeatureProduct>, additional features can be included under the same instance of <AnnuityProduct>. If the relationship between parent object and child object is one-to-one, a new instance of child object does need a new instance of the parent object.

• Use of type codes to communicate ‘All’ or ‘Any’ is not recommended. Data should be explicit and should not require the receiver to infer meaning.

• If an element with the same name appears in both the higher and subordinate level objects, such as ‘MaxIssueAge’ which appears in <Ownership> and <FeatureOptProduct>, the value of the element in the subordinate object <FeatureOptProduct> would always further limit that of the higher level object <Ownership>. The element within the subordinate object cannot supersede the higher level limits; subordinate objects can restrict but not expand definition. (For example, if the MaxIssueAge for the product within Ownership is 80, the MaxIssueAge for a particular Feature Option such as a Stepped Up Death Benefit could be 75, but cannot exceed 80.).

• XTbML is used within the Product Profile for Annuities to model commission rates and interest rates. • “Array” data types will never be used in reference to PPfA rates. • The Y node will never repeat. • JurisdictionCC on Metadata will not be used to vary commission rates by state. The

DistributionAgreement.PolicyProductInfo.JurisdictionApproval node will be used to vary commission rates by state.

• On AxisDef.ScaleType, type code 2 (Ordinal Date) is used to communicate Duration. The mode is assumed to be Annual, and the first value for this element is 1 (never 0).


Carriers & Distributors

• There must be one and only one <Party> object representing the product manufacturer (i.e. the carrier writing company) for each <PolicyProduct>. This <Party> object contains a<Carrier> element providing carrier information applicable to all its applicable products within the XML document. Multiple carrier-type parties may be present in a file.

• There may be multiple <Party> objects representing producers/distributors for each <PolicyProduct>. Each of these <Party> objects contains a <Producer> element providing the individual producer/distributor information. If no <Party> elements for producers/distributors are present, then the message is silent on the producer/distributor that can sell the product. The product is not assumed to apply to all producer/distributors.

• One <PolicyProduct> may be offered to one or multiple producer(s)/distributor(s). A carrier may have multiple selling arrangements for a product associated to different distributors. Association of products to producer/distributors is defined using the DistributionAgreement and Party.Producer.CarrierAppointment.DistributionAgreementInfo objects. More information is discussed under the Commissions heading of this section. The Relation object is no longer used to associate products to producers/distributors.

Product

• The standard requires a single <PolicyProduct> object be uniquely identified by a single CUSIP. For carriers that use more than one CUSIP to support multiple variations of the same product, they must send multiple <PolicyProduct> objects, one for each CUSIP.

• If a file comprising multiple <PolicyProduct> objects with a common CUSIP is sent from a carrier: • Each <PolicyProduct> must have a unique <CarrierCode> / <ProductCode> combination to enable

successful entity recognition. Note that, this includes situations where a CUSIP is repeated across multiple PolicyProduct objects; each PolicyProduct must have a unique ProductCode.

• In the context of products, the combination of <CarrierCode> and <ProductCode> are intended to uniquely identify a given <PolicyProduct>. <CarrierCode> and <ProductCode> are used for entity recognition of a specific product profile, so it is therefore critical the combination is unique.

• Where <JurisdictionApproval> and <JurisdictionCC> are both present on an object, the <JurisdictionApproval> element should be used only if dates must be communicated.

• Elements present on child or complementary objects should be used only if the definition is different from that of the parent or higher level object. For example, jurisdiction should not be specified on FeatureProduct, FeatureOptProduct, InvestProduct, InvestProductInfo, etc. if the definition of availability is the same as that specified on PolicyProduct.

• Some carriers practice an administrative procedure where initial premium is actually allocated to a ‘safe harbor,’ fixed or money market fund for a specified timeframe following policy issue in order to prevent gain/loss in the event of a free look or cancellation transaction. In these cases, the NBfA message should still pass the ‘real’ fund allocations or actual funds requested by the client. Following the specified timeframe, the carrier will transfer the funds to the allocations as directed on the NBfA transactions. For those implementations where the Product Profile for Annuities (PPfA) is used to designate available funds for premium allocation, this ‘free look’ fund would not be included if it is available only as a free look fund (i.e. it cannot be allocate to aside from this free look usage). In summary, the ‘free look’ fund is deemed to be an internal carrier administrative procedure and should not be reflected in the PPfA or NBfA transactions exchanged for order entry.

• The terms “subpay,” “subsequent premium” and “add on” are used interchangeably in this Guide. • Fees are additive across the model. If Fees are specified at the policy and feature level, for example, the

total fee for the contract is the sum of the policy and all features on the policy. • PaymentModeMethProduct is not utilized in the Product Profile for Annuities as a child of PolicyProduct

since it is not explicit to what event or activity the PaymentModeMethProduct node refers. If specific frequencies, durations, days, etc characteristics regarding a rider or arrangement (such as billing/systematic investment, systematic withdrawal or other scheduled events) need to be specified, they should be explicitly described under that Feature using IncomePayoutProductOption. PaymentModeMethProduct or FeatureProduct.FeatureOptProduct.PaymentModeMethProduct.


Arrangements & Riders

• Each product requires at least one <FeatureProduct>. <FeatureProduct> is used to model service programs/arrangements, riders and payouts. The annuity product usage of the ACORD standard requires that, for a <FeatureProduct> to exist, there must be at least one related <FeatureOptProduct>. When there is more than one feature option available for selection, one and only one <FeatureOptProduct> can be chosen for each <FeatureProduct>. In cases when there are multiple feature options to be selected, a new composite feature can be created to make up the <FeatureOptProduct> in question.

• If SourceInvestProduct and DestInvestProduct are not present, this implies all funds described by <InvestProductInfo> are available (this is a higher level object). If there are restrictive funds applicable (e.g. If 8 out of 10 funds are applicable), then all eight would have to be explicitly stated using SourceInvestProduct and DestInvestProduct.

• With regard to any objects that repeat, if there is one option/element specified, the information is intended for display purposes only. The user will not have to select/input information if there is only one option.

• PaymentMode element is assumed to describe dates using the policy effective date, not modes applicable to calendar dates.

• Every product will include a FeatureProduct node with complementary child nodes for an Initial Premium arrangement (ArrType, type code 19) if the product is available for new business, to specify the funds and requirements for the initial premium deposit. If a product allows subsequent deposits, a FeatureProduct node with applicable child nodes will be included to specify funds and requirements for subsequent premium deposits (type code 39).

• Regarding the Initial Premium arrangement, no comment is made on whether initial allocations will become standing if a Standing Allocation arrangement isn’t present. A Standing Allocation FeatureProduct (type code 37) will be included if a product allows the owner to define different premium allocations than are currently stated on the contract for future deposits.

Funds and Interest Rates • RateVariation is to be used to indicate the XTbML table where interest rates are stored. InvestRate on

RateVariation will not be used. If the rates vary by anything (except product), including duration and/or volume or anything else, XTbML will be used to store rates. RateVolumeByDuration and RateVolumeByVolume will never be used. If a single rate applies but doesn’t vary by anything (but fund number, for example), use Date within the XTbML table. If rates vary by product and the same InvestProduct.ProductCode must be shared, RateVariationCode is used to reference a different XTbML node.

Sparse Updates

• It is anticipated that, initially, trading partners will exchange full product profiles. Sparse updates are currently not supported.

Access Method

• The standard makes no assumption as to the access method. As such, it is designed to support an on demand dynamic request for a single specific product profile as well as a mass download of an entire product profile batch and subsequent maintenance refresh. The first method is called “Request/Response” transaction; the second is referred to as a “Transmittal” transaction. <Key> values are persistent identifiers used in “Request/Response” transactions. For “Transmittal” transactions <Key> values would not be used.


Commissions • The model is designed to enable a distributor to determine the amount of total dealer concession

payable on an annuity. It does not break the gross dealer concession down into hierarchies that may exist within a distributor. It also does not reflect additional compensation that may be due because a producer has met a certain production level.

• A carrier may send an abbreviated file called a Commission Profile for Annuities (CPfA) Transmittal to notify distributors of commission specials. This transmittal consists only of the CommissionSchedule and CommFormula objects. (??what is the message number?? Is this really a transaction??)

• The effective dates referencing rates and/or in the rate tables are assumed not to overlap. • When communicating commission-related information, each CarrierAppointment object must have at

least one DistributorAgreementInfo object beneath it to link the producer to the applicable selling agreement.

• Within the ACORD data model, PolicyProduct and its siblings describe the various attributes and features of an annuity product. To describe which producers may sell a particular product, associate a Producer (which may be either a Distributor and/or an individual Agent) with a product via their appointment with the Insurance Carrier (i.e. the CarrierAppointment object). Within each CarrierAppointment is listed the one or several distribution agreements (i.e. selling agreements, contracts) the Producer has via the DistributionAgreementInfo object. The DistributionAgreementInfo object references an agreement established in the DistributionAgreement object. The DistributionAgreement object describes specifically which events are commissionable, which products (via PolicyProductInfo) may be sold under that distribution agreement, and provides for exclusions, definition of commission option information, etc. While this may at first sound a bit convoluted, the structure allows for great flexibility and variability between which distributors (and which of potentially many contracts with a carrier) can sell which products.

• The NettingAllowedInd and AdvancingAllowedInd elements are present on a variety of commission-related objects: DistributionAgreement, CommRemittance, PolicyProductInfo and DistributionAgreementInfo. The BackDatingAllowedInd is present on the DistrbutionAgreement and DistributionAgreementInfo objects. Using the principle that lower level objects may restrict/limit but not expand definition, assuming the NettingAllowedInd is present on all four objects; if any of the applicable Netting elements indicate False (no) then netting is not allowed for that scenario. If an indicator is not used/present, no inference can be assumed (i.e. it is not assumed to be No nor Yes, and therefore is not used).

• If (commission) rates vary by jurisdiction, a different table structure should be created via PolicyProductInfo.JurisdictionApproval. Standard usage for PPfA does not utilize JurisdictionCC within Metadata for Commission Rates.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 9 Chapter Four – Descriptions & Definitions <AllocTypeProduct>

CHAPTER 4 – OBJECT HIERARCHY, DETAILED ELEMENT DESCRIPTIONS & TYPE CODES

This guide reflects: • All items within the current Official Public Standard (2.10.01)) • Those items denoted by ‘’ were approved in June, 2004 for publication in 2.11.00. • Those items denoted by (+) which are proposed for inclusion in the 2.12 publication of

the official public standard. The general structure and hierarchy of the Product Profile for Annuities object elements is as follows, with detailed descriptions and type code definitions appearing in alphabetical order. Note: this document does not represent the order in which elements appear in the schema. <TXLife> <UserAuthRequest>

<UserPswd> <VendorApp> <ProxyVendor> <TXLifeRequest> <OLifE>

<Party> <Organization> <Carrier> <Producer> <CarrierAppointment> <DistributionAgreementInfo> *<RatingAgencyInfo> 04-1.01.AN252 <Address> 04-1.01.AN254

<DistributionAgreement> <PolicyProductInfo>

<CommOptionAvailable> <JurisdictionApproval> <AnnuityProductExclude>

<CommRemittance>

<CommSchedule> <CommFormula>

<InvestProduct>

<JurisdictionApproval> <Fee>


<JurisdictionApproval> *<FreeLookInvestRuleProduct> (04-1-AN2??)

*<JurisdictionApproval> (04-1-AN2??) *<InvestRuleProduct> (04-1-AN2??)

Identifying objects As you look at the various objects within the ACORD Life Model you will notice a need to be able to uniquely identify objects, both in the context of a message like PPfA or later for an update. 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 objects id’s, Key’s (& SysKeys) and Codes. Id’s – On every repeating object in the model there is always a special attribute called ‘id.’ These are of a special reference that is specific to XML. These object attributes 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 PolicyProduct using the ‘PartyId’ attribute. In this example the ‘PartyId’ on PolicyProduct is a pointer or reference to the “party” that represents the Insurance Carrier that produces the product. 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. Code’s – On repeating objects that need to have a more permanent reference to them we use ‘Code’ fields, typically CarrierCode and ProductCode. These two fields represent the company that owns or produced the object along with the code they assign to it. The combination of CarrierCode + ProductCode is assumed to be permanently unique. Since these codes are assumed to be unique we can use them to associate objects with one another on a more permanent basis. For example, we associate funds available for a Variable Annuity by creating InvestProducts for each fund. Each fund has its own CarrierCode & ProductCode. Then under each annuity (PolicyProduct) we list the fund(s) available using the InvestProductInfo object. Each fund available in the annuity is listed in its own InvestProductInfo, which is a child under PolicyProduct. In each InvestProductInfo each CarrierCode + ProductCode pair uniquely points to one and only one fund. Another use for ‘code’ fields is to later on be able to send partial updates and identify to the receiver which thing it is you are updating. Each thing is referenced by its CarrierCode + ProductCode pair. Key’s/SysKey’s – A third method of identifying objects is through the use of special properties we call “Key’s”. All repeating objects have these properties. 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 the Key field on an object may be a database key that the sender uses to store this object in their database. It has no meaning to you, and shouldn’t be used by the receiver in anyway except stored and passed back whenever communicating about this object with the original sender of the object. Similarly, the SysKey properties allow anyone who needs/wants can store their private key values for future reference. (There is only one Key, but as many SysKey's as necessary – functionally the do the same thing). The important thing to note about Key’s is they should never be interpreted by the receiver (they only have meaning to the sender). If provided they should be stored and when communicating about this object you should return all the Keys you were previously given. SysKey is used when multiple Key values apply to an object. SysKey specifies the second reference. Note that in all three examples we refer to repeating objects. There are a few objects in the model which do not repeat (not many). 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.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 12 Chapter Four – Descriptions & Definitions <AddressObject>

XML Element Name Type Description

<Address> Object

The Address object includes addresses pertaining to the Party. The collection of addresses represents the various addresses a party or group may have. Within the context of the PPfA, this object may be used to communicate customer service and mailing addresses for the carrier, distributor, etc.

<Address id> ID Every object within the ACORD model, which can have more than one occurrence, has a unique "id" attribute. It uniquely identifies each occurrence/instance of the object for processing. It has no meaning or context outside the date file or stream.

<AddressTypeCode> LookUp Table String= 'Address Type'

Type Code Type of address. Type Code Translation 2 = Business 3 = Vacation 9 = Regional Office 12 = Previous 16 = Business Shipping Address 17 = Mailing Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AttentionLine> String Used to contain an attention of additional address line.<Line1> String First line of the address. <Line2> String Second line of the address. <Line3> String Third line of the address. <City> String City of the address. <AddressState> String State of the address. < AddressStateTC> LookUp Table String= ‘State’ LookUp TableCode= ‘OLI_LU_STATE’

Choice Collection

Collection or list of all jurisdiction(s) where the option can legally be offered or sold. Type Codes 1 = AL 2 = AK 4 = AZ 5 = AR 6 = CA 7 = CO 8 = CT 9 = DE 10 = DC 12 = FL

30 = MO 31 = MT 32 = NE 33 = NV 34 = NH 35 = NJ 36 = NM 37 = NY 38 = NC 39 = ND 41 = OH 42 = OK 43 = OR 45 = PA 47 = RI 48 = SC

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 13 Chapter Four – Descriptions & Definitions <AddressObject>


13 = GA 15 = HI 16 = ID 17 = IL 18 = IN 19 = IA 20 = KS 21 = KY 22 = LA 23 = ME 25 = MD 26 = MA 27 = MI 28 = MN 29 = MS

49 = SD 50 = TN 51 = TX 52 = UT 53 = VT 55 = VA 56 = WA 57 = WV 58 = WI 59 = WY Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<Zip> String 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.

<AddressCountryTC> Type Code Country of residence for the party. Type Code Translation 1 = United States of America

<PostalDropCode> String Postal Drop Code for address.



<AllocTypeProduct> Object

AllocTypeProduct object gives flexibility to define the allowable means by which source funds and/or destination funds and/or the combination of source and destination funds may be allocated to, or elected for, the associated feature option. Attribute: AllocTypeProduct id= “ ”

String See the description at the beginning of this chapter for usage & meaning.

<AllocTypeProductKey> String See the description at the beginning of this chapter for usage & meaning.

<AllocTypeProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<SourceTransferAmtTypeCC> <SourceTransferAmtType> LookUp Table String= ‘Transfer Amount Type’

LookUpTableCode= ‘OLI_LU_TRNSFRAMTTYPE’

Choice Collection

Types of allocations allowed for source funds. This element describes the means by which money may be allocated to the source fund(s). Type Code Translation 1 = Units 2 = Amount 3 = Percentage 4 = Pro Rata based on relative amount of selected funds (funds are specified, but no amount or percentage will be provided/gathered) 5 = Pro Rata across all Variable funds 6 = Pro Rata across ALL funds 7 = Transfer, No Amount Type Specified (funds are specified, but no amount or percentage is provided - such as with Interest Only options) * 8 = Granular Level Specification (04-1.01.AN246) 9 = All Allocations Acceptable

<DestTransferAmtTypeCC> <DestTransferAmtType> LookUp Table String= ‘Transfer Amount Type’ LookUp Table Code= ‘OLI_LU_TRNSFRAMTTYPE’

Choice Collection

Types of allocations allowed for destination funds. This element describes the means by which money may be allocated to the destination fund(s). When the SourceTransferAmtType is also used, this element describes the means by which money may be allocated to the destination funds considering how money is allocated to the source funds. Type Code Translation 1 = Units 2 = Amount 3 = Percentage 4 = Pro Rata based on relative amount of selected funds (funds are specified, but no amount or percentage will be provided/gathered) 5 = Pro Rata across all Variable Funds 6 = Pro Rata across ALL funds 7 = Transfer, No Amount Type Specified (funds are


XML Element Name Type Description specified, but no amount or percentage is provided- such as with Interest Only options) * 8 = Granular Level Specification (04-1.01.AN246) 9 = All Allocations Acceptable

<MarketingName> String The name given by the carrier for this combination.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 16 Chapter Four – Descriptions & Definitions <AllowedRelationship>


<AllowedRelationship> Object

This AllowedRelationship object describes all relationships allowed between all policy entities. The object is interpreted as follows: “the (OriginatingRole) is the (Relationship) of the (RelatedRole).” For example, the beneficiary is the brother of the annuitant. <OriginatingRole> LookUp Table String= ‘Relation RoleCode’ LookUp Table Code= ‘OLI_LU_REL’

TypeCode The originating contract entity that the relationship being described is based upon. Type Code Translation 8 = Owner 34 = Beneficiary Primary 35 = Annuitant 36 = Contingent Beneficiary 56= Tertiary Beneficiary 153 = Contingent Annuitant 177 = Contingent Owner 183 = Joint Annuitant 184 = Joint Owner 191 = Owner Beneficiary (03-2.01.AN07) 192= Owner Contingent Beneficiary (03-2.01.AN07) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<RelatedRole>

LookUp Table String= ‘Relation RoleCode’ LookUp Table Code= ‘OLI_LU_REL’

TypeCode The related contract entity that the relationship being described is based upon. This value will generally match that of the ParticipantBasedOn value on the PolicyProduct object. Type Code Translation 8 = Owner 35 = Annuitant Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 17 Chapter Four – Descriptions & Definitions <Allowed Relationship>

XML Element Name Type Description <RelationshipCC> <Relationship>

LookUp Table String= ‘Relation RoleCode’

LookUp Table Code= ‘OLI_LU_REL’

Choice Collection

Relationships allowed between the Originating and Related Role. Type Code Translation 1 = Spouse 2 = Child 3 = Parent 4 = Sibling 5 = Family 6 = Employee 7 = Employer 14 = Friend 15 = Domestic Partner 27 = Legal Guardian 40 = Dependent 54 = Plan Sponsor 69 = Trustee 92 = Grandparent 93 = Grandchild 94 = Step-Child 111 = Fiancee 131 = Step-Parent 134 = Foster Child 135 = Foster Parent 137 = God Child 138 = God Parent 168 = Self 169 = All but Self 170= Half Sibling 172 = Step Sibling 174 = Former Spouse 999 = Any Relationships Acceptable 1000 = All Relationships Acceptable Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 18 Chapter Four – Descriptions & Definitions <AmountProduct>


* <AmountProduct> Object (04-1.01.AN246)

This object describes details about the amount which may be transferred or associated with a feature option.

Attribute: AmountProductId = “”


<AmountProductKey> String See the description at the beginning of this chapter for usage & meaning.

<AmountProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<AmountContext> LookUp Table String= ‘Amount Context’ LookUp Table Code= ‘OLI_LU_AMTCONTEXT’

TypeCode Provides the meaning for the specified amount. Type Code Translation 1 = Face Amount 2 = Rider Amount 3 = Modal Amount 4 = Annualized Amount 5 = Total Program Amount

<TransferAmtType> LookUp Table String= ‘Transfer Amount Type’

LookUpTableCode= ‘OLI_LU_TRNSFRAMTTYPE’

TypeCode Types of allocations allowed for transfer funds. This element describes the means by which money may be allocated. Type Code Translation 1 = Units 2 = Amount 3 = Percentage 4 = Pro Rata based on relative amount of selected funds (funds are specified, but no amount or percentage will be provided/gathered) 5 = Pro Rata across all Variable funds 6 = Pro Rata across ALL funds 7 = Transfer, No Amount Type Specified (funds are specified, but no amount or percentage is provided - such as with Interest Only options) * 8 = Granular Level Specification (04-1.01.AN246) 9 = All Allocations Acceptable

<EnumeratedValue> String ????? <MinAmt> String Minimum amount. <MaxAmt> String Maximum amount <MinPct> Percentage Minimum percentage <MaxPct> Percentage Maximum percentage.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 19 Chapter Four – Descriptions & Definitions <AnnuityProduct>


<AnnuityProduct> Object

The AnnuityProduct element contains all the “annuity specific” information relating to this product. Note that characteristics of the product which are applicable across product lines, such as name and CUSIP number, are defined on PolicyProduct. <PremType> LookUp Table String= ‘Annuity Premium Type’ LookUp Table Code= ‘OLI_LU_ANNPREM’

TypeCode Annuity Premium Structure. Type Code Translation 1 = Single 2 = Flexible Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PayoutType> LookUp Table String= ‘Annuity Payout Type’ LookUp Table Code= ‘OLI_LU_ANNPAYOUT’

TypeCode Annuity Payout Structure. Type Code Translation 1 = Immediate 2 = Deferred Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<NewMoneyAllocationRule> LookUp Table String= ‘Allocation Option’

LookUp Table Code= ‘OLI_LU_ALLOCATIONOPTION’

TypeCode Indicates whether electronic processing is permitted for distributing funds to standing or current allocations for subsequent premium payments. Type Code Translation 1 = Explicit allocation instructions must accompany subsequent premium payment transactions 2 = Standing Allocations * 3 = Current Allocations – Use the ratio of current account balances to allocate * 4 = Either specific instructions or use standing allocations (04-1.01.AN169) (i.e. the client can chose either alternative)

<LoadingType> LookUp Table String= ‘Loading Type’ LookUp Table Code= ‘OLI_LU_LOADINGTYPE’

TypeCode Describes how the initial load on a policy is withdrawn. Type Code Translation 1 = No Load 2 = Front-End Load 3 = Back-End Load 4 = Contingent Deferred Sales Charge Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 20 Chapter Four – Descriptions & Definitions <AnnuityProduct>

XML Element Name Type Description <LOIROAType> LookUp Table String= ‘Letter of Intent or Rights of Accumulation’ LookUp Table Code= ‘OLI_LU_LOIROA’

TypeCode Identifies if a Letter of Intent or Rights of Accumulation apply to the product. LOI applies to a single contract: letter of intent would indicate the initial dollars and the dollars intended within the carriers guarantee period. ROA is determined on the assets held with the carrier across multiple contracts and LOBs. Based upon the Total Amount of the LOI/ROA, the customer would get the sales charge rate, or the accumulation rate bonus, for the intended amount.

Type Code Translation 1 = Letter of Intent 2 = Rights of Accumulation 3 = Both Letter of Intent and Rights of Accumulation Note: If neither applies, the element should not be sent.

<AnnuitizationDateRequired> LookUp Table String= ‘Required Data Field’ LookUp Table Code= ‘OLI_LU_DATAREQ’

TypeCode Indicates whether annuitization date information should be collected during Order Entry. Type Code Translation 1 = Data Collection Optional 2 = Data Collection Required 3 = Data Not To Be Collected Industry Comment: If annuitization date information is collected, it should be sent in StartDate within the Payout Object for NBfA.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 21 Chapter Four – Descriptions & Definitions <AnnuityProductExclude>


<AnnuityProductExclude> Object

Provides a means to exclude feature availability from a product for a distributor.

AnnuityProductExclude Id = “”


<AnnuityProductExcludeKey> String See the description at the beginning of this chapter for usage & meaning.

<AnnuityProductExcludeSysKey> String See the description at the beginning of this chapter for usage & meaning.

<FeatureCode> String References a particular <FeatureProduct> which is not available for sale by the distributor.

<ProductCode> String References a particular <FeatureOptProduct> which is not available for sale by the distributor.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 22 Chapter Four – Descriptions & Definitions <Authorization>


<Authorization> Object

The Authorization object identifies those entities that are allowed to complete specified financial and non-financial transactions by specified means. Attribute: Authorization id= “ ”


<AuthorizationKey> String See the description at the beginning of this chapter for usage & meaning.

<AuthorizationSysKey> String See the description at the beginning of this chapter for usage & meaning.

<BusinessMethodCC> <BusinessMethod> LookUp Table String= ‘App Submission Type’ LookUp Table Code= ‘OLI_LU_APPSUBMITTYPE’

Choice Collection

A list of means by which transactions may be initiated within the contract. Type Code Translation 1 = Mail 2 = Electronic 3 = Fax 4 = Phone Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AuthorizationEntityCC> <AuthorizationEntity> LookUp Table String= ‘Relation RoleCode’ LookUp Table Code= ‘OLI_LU_REL’

Choice Collection

Identifies those parties allowed to initiate transactions within the contract. Type Code Translation 8 = Owner 35 = Annuitant 38 = Servicing Agent 69 = Trustee 82 = Registered Representative 127 = Third Party Designees 153= Contingent Annuitant 177 = Contingent Owner 183 = Joint Annuitant 184 = Joint Owner 999 = Any Relationship is Acceptable (Any Entity) Note: ‘Any Relationship’ implies anyone with a valid PIN/Identification. This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AuthorizationSignatureReqInd> Boolean 0=False 1=True

Indicates whether a signature is required from the owner before requested authorization is activated. True indicates that a signature is required.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 23 Chapter Four – Descriptions & Definitions <AuthorizationTransaction>


<AuthorizationTransaction> Object

This object describes Financial and Non-Financial transactions that may be performed by authorized entities. <AuthorizationMappingCodeInd> Boolean

0=False 1=True

Identifies the transaction as being Financial or Non-Financial. False = FinActivityType for Financial Activity. Indicates the activity is a financial activity. True = TXLifeTransCode for Non-Financial Activity. Indicates the activity is non-financial.

<AdministrativeTransaction> LookUp Table String= ‘Transaction Type’ LookUp Table Code= ‘OLI_LU_TRANS_TYPE_CODES’

TypeCode Identifies the Non-Financial transactions that may be performed by authorized entities. Type Code Translation 101 = Fund Allocation Change for Investment or Policy (Standing Allocations Changes) 107 = Schedule Arrangement (Current Allocations Changes) 181 = Address Change 561 = Pre-Arranged Non-Financial Transactions Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<FinActivityType> LookUp Table String= ‘Financial Activity Type’ LookUp Table Code= ‘OLI_LU_FINACTTYPE’

TypeCode Identifies the Financial transactions that may be performed by authorized entities. Type Code Translation 17 = Asset Allocation 18 = Asset Rebalancing 22 = Dollar Cost Averaging 101 = Systematic Withdrawal 102= Minimum Required Distribution 103 = Fund Transfers 295 = Surrender-Free Amount Withdrawal 330 = Substantially Equal Payments 999 = All Financial Activities Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 24 Chapter Four – Descriptions & Definitions <BreakPoint>


<Breakpoint> Object

This object reflects the basis points to be used for either: a) the interest rate that funds will earn in a fixed annuity, or b) the sales charge that will be applied to deposited funds. If RangeRateType is Interest Rate, then this is the Rate for this breakpoint level. If RangeRateType is Sales, then this is the Sales Charge applied at this breakpoint level. Breakpoints can be defined for both Letter of Intent (LOI) and Rights of Accumulation (ROA), as well as for Sales Charges and Interest Rates. The LOIROA amount ranges may be duplicated for each of these separate breakpoint series. Attribute: Breakpoint id= “


<BreakpointKey> String See the description at the beginning of this chapter for usage & meaning.

<BreakpointSysKey> String See the description at the beginning of this chapter for usage & meaning.

<LOIROAType> LookUp Table String= ‘Letter of Intent or Rights of Accumulation’ LookUp Table Code= ‘OLI_LUI_LOIROA’

TypeCode Identifies if a Letter of Intent or Rights of Accumulation apply to the annuity product. LOI applies to a single contract: letter of intent would indicate the initial dollars and the dollars intended within the carriers guarantee period. ROA is determined on the assets held with the carrier across multiple contracts and LOBs. Based upon the Total Amount of the LOI/ROA, the customer would get the sales charge rate, or the accumulation rate bonus, for the intended amount. Type Code Translation 1 = Letter of Intent 2 = Rights of Accumulation 3 = Both Letter of Intent and Rights of Accumulation Note: If neither applies, the element should not be sent.

<RangeLowAmt> Currency The low amount of the breakpoint range for a LOI and/or ROA. This value is expressed as currency. The range is inclusive of the value.

<RangeHighAmt> Currency The high amount of the breakpoint range for a LOI and/or ROA. This value is expressed as currency. The range is inclusive of the value.

<RangeRateBP> Real Rate adjustment in basis points for given breakpoint ranges. Determines the basis points to be used for either: a.) the bonus interest (added to the base rate) that funds will earn in a fixed annuity, or b.) the sales charge that will be applied to deposited funds. See RangeRate Type to determine a) or b). The breakpoint level is based on either Premium or Account Value depending upon LOI or ROA type.

<RangeRateType> LookUp Table String= ‘Range Rate Type’ LookUp Table Code= ‘OLI_LU_RANGERATETYPE’

TypeCode Indicates whether this breakpoint level is to define an Interest Rate series, or a Sales Charge Series. Type Code Translation 1 = Interest Rate Bonus 2 = Sales Charge

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 25 Chapter Four – Descriptions & Definitions <BusinessProcessAllowed>


<BusinessProcessAllowed> Object

This object describes the business processes allowed for the product based on either product contractual limitations and/or business process constraints. This object describes details of the agreement between two trading partners. Attribute: BusinessProcessAllowed id= “ ”


<BusinessProcessAllowedKey> String See the description at the beginning of this chapter for usage & meaning.

<BusinessProcessAllowedSysKey>


<AdministrativeTransaction> LookUp Table String= ‘Transaction Type’ LookUp Table Code= ‘OLI_LU_TRANS_TYPE_CODES’

TypeCode Identifies financial transactions allowed for the product. Type Code Translation 103 = New Business Submission 508 = Payment Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<Description> String Further explains the Business Process Allowed. Industry Comment: NAVA recommends that the description element be used as the Order Entry Display Name or Marketing Name.

<BusinessProcessCC> <BusinessProcess> LookUp Table String= ‘Business Process Types’ LookUp Table Code= ‘OLI_LU_BUSPROCESS’

Choice Collection

Further describes the business processes allowed with electronic transactions. Type Code Translation 3 = Funded New Business Allowed 5 = 1035 Business Received Electronically, but pending paperwork 6 = Business in which Signature is required at Solicitation (NY), app-later 7 = Business in which Signature is required by non-natural owners (i.e. trust) before investment

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 26 Chapter Four – Descriptions & Definitions <CarrierObject>


<Carrier> Object

A sub object under Party, providing more detailed information about the financial product manufacturer (a.k.a. the Carrier). Attribute: Carrier id= “ ”


<CarrierKey> String Unique Key used only by a sending system if it wishes to pass to a downstream system a key/pointer to an internal record. Useful only for Request/Response transaction method. The response must return the Key without change in a reply msg. Generally not used in Transmittal Transaction.

<CarrierSysKey> String See the description at the beginning of this chapter for usage & meaning.

<CarrierCode> String When referencing products, this code uniquely represents the manufacturer / issuing Insurance Carrier. The CarrierCode is used frequently throughout the model as one component of information for entity recognition. Industry Comment: NAVA recommends using the NAIC code when representing the Insurance Company,.

<NAICCode> String NAIC Code of the carrier. <DSTCarrierCode> String DST Carrier Code. <PershingCarrierCode> String Pershing Carrier Code.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 27 Chapter Four – Descriptions & Definitions <CarrierAppointment>


<CarrierAppointment> Object

The CarrierAppointment collection represents the various appointments between the producer (firm) and various insurance companies. A producer may have multiple appointments because an appointment may be made at the issuing company level and products may be sold under more than one issuing company, or they may simply have several different contracts; for different regions, different product lines, one for old business and one for new, etc.. The DistributionAgreement object is used to define the specifics of a selling agreement, including the commissionable events, the available products which may be sold and associated commission options, whether netting is allowed, et cetera. The DistributionAgreementInfo object within CarrierAppointment is used to specify which DistributionAgreement(s) (i.e. selling agreements) apply to the producer being modeled. Structured this way, many different distributors may then share the same DistributionAgreement. Each producer/distributor would have their own CarrierAppointment, but those could all point to one (or more) DistributionAgreements. Or, if necessary, each can have separate agreements. Attributes: CarrierAppointment id= “ ”

String

See the description at the beginning of this chapter for usage & meaning.

<CarrierAppointmentKey> String


<CarrierAppointmentSysKey> String


<CompanyProducerID> String The producer identification number issued by the carrier. This is the producer (which may be an organization or individual, although organization is expected within the PPfA usage) to which this commission profile applies.

<CarrierCode> String When referencing products, this code represents the issuing Insurance Carrier. Industry Comment: NAVA recommends using the NAIC code when representing the Insurance Company.

<EffDate> Date First date the appointment is effective. <ExpDate> Date The expiration date of the appointment.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 28 Chapter Four - Descriptions & Definitions <ChargePctSchedule>


<ChargePctSchedule> Object

The ChargePctSchedule object functions with the SurrenderChargeSchedule object to describe surrender charge rates for the purposes of disclosure of charges at order entry and distributor forms. It is not intended to describe complex surrender charge schedules for the sake of post-issue processing. Attributes: ChargePct id= “ ”


<ChargePct Key> String See the description at the beginning of this chapter for usage & meaning.

<ChargePctSysKey> String See the description at the beginning of this chapter for usage & meaning.

<Duration> Integer The duration to which the rate applies.

<DurQualifier>

LookUp Table String= ‘Payment Mode’

LookUp Table Code= ‘OLI_LU_PAYMODE

Describes the duration of the rate. . Type Code Translation 1 = Annually 2 = Semi-Annually (twice a year) 3 = Quarterly 4 = Monthly 5 = Semi-Monthly (twice a month) 6 = Weekly 7 = Bi-Weekly (every two weeks) 8 = Daily Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<Percentage> Percentage The percent surrender charge. 6.25% is expressed as 6.25 (i.e. do not express as a decimal)

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 29 Chapter Four – Descriptions & Definitions <CommProduct>


<CommissionProduct> Object

This element describes generic commission information associated with the product. The PPfA usage does not intend CommOptionAvailable as a child of CommissionProduct. Attributes: CommissionProduct id= “ ”


<CommissionProductKey> String See the description at the beginning of this chapter for usage & meaning.

<CommissionProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<CommissionAgeCalculationType> LookUp Table String= ‘Age Calculation Method’ LookUp Table Code= ‘OLI_LU_AGECALCMETH’

TypeCode Indicates the algorithm used to determine the contract entity upon which commission breakpoints are determined. Type Code Translation 2 = Age Last Birthday 3 = Age Nearest in days Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<SubpayCommAgeBasis> LookUp Table String= ‘Subpay Comm Age Basis’ LookUp Table Code= ‘OLI_LU_SUBPAYCOMMAGE’

TypeCode Indicates the commission breakpoints upon which subsequent premium are based if age is used as a threshold. Type Code Translation 1 = Issue Age 2 = Attained Age

<CommissionAgePartySelection> LookUp Table String= ‘Party Selection’ LookUp Table Code= OLI_LU_PARTYSELECT

TypeCode When multiple participants are indicated by PolicyProduct.ParticipantBasedOn, this further refines the selection for Commission calculations. Type Code Translation 1 = Party selection is not applicable 2 = Oldest of the specified participants 3 = Youngest of the specified participants

<ParticipantBasedPartySelection> LookUp Table String= ‘Participant Role’ LookUp Table Code= ‘OLI_LU_PARTICROLE’

When multiple participants are indicated by PolicyProduct.ParticipantBasedOn, this further refines the selection when one must be selected. Type Code Translation 18 = Owner 27 = Primary Annuitant 36 = Both Primary Annuitant and Primary Owner 42 = Owner (if owner is a natural person, otherwise use annuitant)

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 30 Chapter Four – Descriptions & Definitions <CommFormula>


<CommFormula> Object

This object communicates the appropriate commission rate table that will apply for the given commission event and commission option. The CommissionType field was deprecated in favor of using the construct within XTbML. Attributes: CommFormula id= “

String


<CommFormulaKey> String See the description at the beginning of this chapter for usage & meaning.

<CommFormulaSysKey> String See the description at the beginning of this chapter for usage & meaning.

<CommEvent>

LookUp Table String= ‘Commission Event’ LookUp Table Code= ‘OLI_LU_COMMEVENT’

TypeCode Describes the event (trigger) generating a commission. This is a REQUIRED element. Type Code Translation (revisions noted from 04-1.01.AN222) 3 = Premium – Cash With App 4 = Exchange – Internal 5 = Exchange – External 7 = Premium – Additional 18 = Premium (fixed or scheduled) * 46 = Premium – Initial * 47 = Exchange (04-1.29.34) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<RelationRoleCode>

LookUp Table String= ‘Relation RoleCode’

LookUp Table Code= ‘OLI_LU_REL’

Choice Collection

Role Code of Relationship. Type Code Translation 48 = General Agent 83 = Broker Dealer 182 = Writing Agent 169 = All but Self 999 = Any Relationships Acceptable Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CarrierCommCode> String The carrier defined code for this specific commission option. ??? Should commission option be required ???

<TableIdentity> String Unique carrier-defined identifier for the Table. This element, combined with the ProviderDomain, provides a unique key for to XTbML table, where commission rates are stored. Therefore, while this property is not required in the schema, TableIdentity is required in concert with ProviderDomain to access XTbML.

<ProviderDomain> String The domain name of the provider. This element, combined with TableIdentity, provides a unique key to the XTbML table. Therefore, while this property is not required in the schema, ProviderDomain is required in concert with TableIdentity to access XTbML.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 31 Chapter Four – Descriptions & Definitions <CommOptionAvailable>


<CommOptionAvailable> Object

This object communicates the commission options available to this Producer (within the context of this distribution agreement for this allowed product.). While this object is available under the <PolicyProduct> / <PolicyProductInfo> relationship, it is intended for use within the PPfA only under the <DistributionAgreement> / <PolicyProductInfo> relationship, and Commission Options must be explicit by distributor/producer. This object is not used as a child of CommissionProduct within PPfA usage. <CommOption>

LookUp Table String= ‘Commission Option’

LookUp Table Code= ‘OLI_LU_COMMOPTION’

TypeCode Generic Classification of commission options. Type Code Translation 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. 3 = Reduced First Year Commission Rate plus the policy is included in the Expense Allowance Plan. 4 = Reduced First Year Commission Rate with no Persistency or Expense Allowance Payments included. 5 = Heaped (Levelized) Commission Option 6 = Full First Year Commissions – 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 Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CarrierCommCode> String Carrier defined code for this specific commission option. Further definition on the associated commission rates are be established using the CommFormula and XTbML objects.

<CommOptionDesc> String Textual description of the commission option. <MinAvailableAge>

03-2.01.AN09 Integer Minimum age of the Owner/Annuitant for this Commission

Option to be available. Indication of which entity applies can be found on the PolicyProduct object (ParticipantBasedOn or CommissionAgePartySelection).

<MaxAvailableAge> 03-2.01.AN09

Integer Maximum age of the Owner/Annuitant for this Commission Option to be available. Indication of which entity applies can be found on PolicyProduct.ParticipantBasedOn or CommissionProduct.CommissionAgePartySelection if ParticipantBasedOn = Both Owner and Annuitant).

<EffDate> 03-2.01.AN09

Date Effective date when the commission option is initially effective.

<TermDate> 03-2.01.AN09

Date The first date this commission option is no longer effective.

<CommOptionName> 03-2.01.AN09

String Full name of the commission option. This is to be used in the user interface presentation when the user elects their commission option.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 32 Chapter Four – Descriptions & Definitions <CommRemittance>


<CommRemittance> Object

This object describes different commission events that are authorized at the distribution agreement level and apply to all products under the DistributionAgreement. Attributes: CommRemittance id= “ ”

String


<CommRemittanceKey> String See the description at the beginning of this chapter for usage & meaning.

<CommRemittanceSysKey> String See the description at the beginning of this chapter for usage & meaning.

<AdvancingAllowedInd> Boolean 0=False 1=True

Indicates whether advancing of commissions will be accepted. Reflects if the carrier has agreed to advance commissions with this producer.

<NettingAllowedInd> Boolean 0=False 1=True

Indicates if netting of commissions will be accepted. Reflects if the carrier has agreed to net commissions with this producer.

<CommEvent>

LookUp Table String= ‘Commission Event’ LookUp Table Code= ‘OLI_LU_COMMEVENT’

TypeCode Describes the event (trigger) generating a commission. This is a REQUIRED element. Type Code Translation (revisions noted from 04-1.01.AN222) 3 = Premium - Cash With App 4 = Exchange - Internal 5 = Exchange - External 7 = Premium - Additional 18 = Premium (fixed or scheduled) 46 = Premium - Initial 47 = Exchange Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PaymentMethod> DEPRECATED LookUp Table String= ‘Payment Method’ LookUp Table Code= ‘OLI_LU_PAYMETHOD’

TypeCode Deprecated via 04.1.01.AN195 as of 2.11.00. The business process by which payment is made. Type Code Translation 7 = Electronic Funds Transfer (EFT) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Note: This element will be replaced with the more appropriate PaymentForm when it is added with the ACORD

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 33 Chapter Four – Descriptions & Definitions <CommRemittance>

XML Element Name Type Description Life Spec v 2.11 Release.

<PaymentMode>


LookUp Table Code= ‘OLI_LU_PAYMODE’

TypeCode Frequency of payment. These values are assumed to be based on policy effective date, not calendar dates. Type Code Translation 1 = Annually 2 = Semi-Annually (twice a year) 3 = Quarterly 4 = Monthly 5 = Semi-Monthly (twice a month) 6 = Weekly 7 = Bi-Weekly (every two weeks) 8 = Daily 100 = Any Paymode is Allowed Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AdvanceRate> <Percentage>

The percent (%) of total premium submission applicable to the commission event that is eligible for advance. If the entire premium is advanced, then 100 should be stated.

* <PaymentFormCC> <PaymentForm> LookUp Table String= ‘Payment Form’ LookUp Table Code= ‘OLI_LU_PAYMENTFORM’ 04-1.01.AN195

Choice Collection

Allowable forms of payment for the commission event. Type Code Translation 1 = Cash 2 = Credit Card 3 = Money Order 4 = Cashier’s Check 5 = Certified Check 6 = Personal Check 7 = Electronic Funds Transfer (EFT) 10 = Corporate Check 11 = Clearinghouse 12 = Wire 13 = Funds to follow Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 34 Chapter Four – Descriptions & Definitions <CommSchedule>


<CommSchedule> Object

Combined with CommFormula, this object enables definition of a series of commission tables. More than one product and/or producer can use the same commission schedule; schedules are linked by the appropriate keys. Attributes: CommSchedule id= “ ”

String


<CommScheduleKey> String See the description at the beginning of this chapter for usage & meaning.

<CommScheduleSysKey> String See the description at the beginning of this chapter for usage & meaning.

* <CommScheduleCode> 04-1.01.AN248

String This is the entity recognition element for this object which is pointed to from within the PolicyProductInfo aggregate.

<EffDate> Date Effective date that aggregate (i.e. the commission schedule) is initially available/applicable.

<ExpDate> Date Expiration date of the aggregate (schedule); the first date the schedule is no longer available.

<CarrierCode> String This is the code used to represent the carrier for the commission schedule being described.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 35 Chapter Four – Descriptions & Definitions <DestInvestProduct>


<DestInvestProduct> Object

Indicates fund(s) available as destination fund(s) for the option being described. If DestInvestProduct is not present, it implies all funds associated to the product (via InvestProductInfo) are available. If there are restrictive funds applicable (e.g. If 8 out of 10 funds are applicable), then all eight would be explicitly stated using DestInvestProduct. Funds defined in this object must reference funds defined in both <InvestProduct> and <InvestProductInfo>. <CarrierCode> String This code represents a link to <InvestProduct>. <ProductCode> String Indicates a <ProductCode> from <InvestProduct>, which

can be selected as a destination fund with this feature option. This <CarrierCode> <ProductCode> combination must be present in <InvestProduct> and <InvestProductInfo>. Format: NAVA recommends the 5 character fund abbreviation as used in DTCC’s ‘Fund CUSIP’.

* <MinAmt> 04-1.01.AN246 String Minimum amount. * <MaxAmt> 04-1.01.AN246 String Maximum amount. * <MinPct> 04-1.01.246 Percentage Minimum percentage. * <MaxPct> 04-1.01.246 Percentage Maximum percentage.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 36 Chapter Four – Descriptions & Definitions <DistributionAgreementInfo>


<DistributionAgreement> Object

Provides information related to the agreement between the producer (firm) and carrier. For NAVA presale commission purposes, this object provides information on the allowed products and commission specifics per the Carrier and the Producer (firm) agreement. Attribute: DistributionAgreement id= “ ”


<DistributionAgreementKey > String See the description at the beginning of this chapter for usage & meaning.

<DistributionAgreementSysKey > String See the description at the beginning of this chapter for usage & meaning.


Indicates if Advancing will be accepted per the agreement between the carrier and Producer (firm).

<BackDatingAllowedInd> Boolean 0=False 1=True

Reflects if the Carrier will accept back dated transactions from this Producer (firm).

<ProductType> LookUp Table String= ‘Policy Product Type’ LookUp Table Code= ‘OLI_LU_POLPROD’

TypeCode Indicates type of product this distribution agreement allows. Type Code Translation 9 = Fixed Annuity 10 = Variable Annuity 11 = Indexed Annuity Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<InterestRateClass> 03-2.01.AN04

String This element is a key to the Interest Rate Variation XTbML.

<DateBasedOn> 03-2.01.AN04 LookUp Table String= ‘Date Basis’ LookUp Table Code= ‘OLI_LU_ DATEBASIS’

Date The Date which is used for the lookup in the Interest Rate variation table. Specifies which date will be used in the lookup for interest rate variations for the product. Type Code Translation 1 = Application Signed Date 2 = Date Submitted

<NettingAllowedInd> (03-2.01.AN19)

Boolean 0=False 1=True

Indicates if the Carrier will accept net transactions with this Distributor.

* <EffDate> (04-1.01.AN219) Date The date beginning on which this distribution agreement is effective.

* <ExpDate> (04-1.01.AN219) Date The date on which this distribution agreement is no longer effective. This is the first day the distribution agreement cannot be used.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 37 Chapter Four – Descriptions & Definitions <DistributionAgreementInfo>


<DistributionAgreementInfo> Object

Provides link and information related to the agreement between the producer (firm) and carrier. Within a Producer’s CarrierAppointment, is this DistributionAgreementInfo object. It is here that each DistributionAgreement that supports a given CarrierAppoinment is listed. This object links the specific Distribution Agreement with a specific Distributor. Also, additional agreement specific parameters which may very at this level are available, such as BackDating or Advancing. Attribute: DistributionAgreementInfo id= “ ”


<DistribAgreementInfoKey > String See the description at the beginning of this chapter for usage & meaning.

<DistribAgreementInfoSysKey > String See the description at the beginning of this chapter for usage & meaning.

<DistributionAgreementId > String A unique identifier for the DistributionAgreement aggregate to link the specific producer/distributor to a particular DistributionAgreement.


Indicates if Advancing will be accepted for this specific producer. If yes, details related to advancing options allowed will be provided under Comm Event. Note that this indicator is available on the DistributionAgreement object as well. On a DistributionAgreement level (a higher level in the model) it means anyone with this DistributionAgreement may do this. However it can subsequently be ‘overridden’ at this level by specifying that this indicator is disallowed here, even though it is allowed at the higher level. The reverse is NOT true, if it is not allowed on the DistributionAgreement level, then specifying that it is here doesn’t then make it available. Subordinate (lower) items can only further restrict rules.

<BackDatingAllowedInd> Boolean 0=False 1=True

Reflects if the Carrier will accept back dated transactions from this Distributor. See note above, same restriction applies.


Indicates if Netting will be accepted. See note above, same restriction applies.

* <EffDate> (04-1.01.AN219) Date The date beginning on which the distribution agreement is effective for the producer.

* <ExpDate> (04-1.01.AN219) Date The date on which this distribution agreement is no longer effective for the producer. This is the first day the distribution agreement does not apply.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 38 Chapter Four – Descriptions & Definitions <EntityType>


<EntityType> Object

This aggregate defines the type of entity (Individual/Organization) and, if the entity is an organization, the form (type) of organization. <OrgForm> LookUp Table String= ‘Organization Form’ LookUp Table Code= ‘OLI_LU_ORGFORM’

TypeCode Further describes the entity when the entity is not a person. Type Code Translation 1 = Sole Proprietorship 2 = Partnership 9 = Government Agency 12 = Non-Profit Organization 14 = Limited Liability 16 = Trust 23 = Corporation (General) 24 = Estate 25 = Plan Administrator Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PartyTypeCode> LookUp Table String= ‘Party Type’ LookUp Table Code= ‘OLI_LU_PARTY’

TypeCode Indicates what types of entities are allowed for the product. Type Code Translation 1 = Person 2 = Organization

<TrustTypeCC> <TrustType> LookUp Table String= ‘Trust Type’ LookUp Table Code= ‘OLI_LU_TRUSTTYPE’

Choice Collection

Indicates what types of trusts are allowed for the product when OrgForm = Trust. Type Code Translation 13 = Charitable Remainder Annuity Trust 24 = Estate Trust 26 = Grantor Trust 33 = Living Trust 37 = Minority 51 = Testamentary Trust 55 = Qualified Plan Trust Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 39 Chapter Four – Descriptions & Definitions <ExclusionInvestProduct>


<ExclusionInvestProduct>Object

This object identifies funds that cannot be used within the contract if the option being modeled is selected. If there are restrictive funds applicable (e.g. If 8 out of 10 funds are applicable), then all eight must explicitly stated using Exclusion Invest Product. If no funds are specified, then all funds are unrestricted. Funds defined in this object must reference funds defined in both <InvestProduct> and <InvestProductInfo>. <CarrierCode> String This code represents a link to <InvestProduct>. <ProductCode> String Indicates a <ProductCode> from <InvestProduct>, which

cannot be selected as a fund with this feature option. This <CarrierCode> <ProductCode> combination must be present in <InvestProduct> and <InvestProductInfo>. Format: NAVA recommends the 5 character fund abbreviation as used in DTCC’s ‘Fund CUSIP’.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 40 Chapter Four – Descriptions & Definitions <FeatureConflict>


<FeatureConflict> Object

This element indicates any other feature(s) which is/are not available simultaneously with the feature being described. A reference to another FeatureProduct which, when elected, makes this FeatureProduct unavailable. <FeatureCode> String List <FeatureCode> of a feature, which cannot be selected

(i.e. are in conflict) with this feature. The <FeatureCode> must reference a valid node within <FeatureProduct>.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 41 Chapter Four – Descriptions & Definitions <FeatureOptConflict>


<FeatureOptConflict> Object

This element indicates any other feature(s) or feature option(s) which is/are not available simultaneously with the feature option being described. This is a reference to a feature or feature option that, if elected, makes this FeatureOptionProduct unavailable. If all options within a feature are conflicts, then only the FeatureCode is required. <FeatureCode> String List <FeatureCode> of features, which cannot be selected

(i.e. are in conflict) with this feature option. The <FeatureCode> must reference a valid node within <FeatureProduct>.

<ProductCode> String Unique Code, referencing the <ProductCode> from <FeatureOptProduct> which identifies the feature option which conflicts with the feature option being described.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 42 Chapter Four – Descriptions & Definitions <FeatureOptProduct>


<FeatureOptProduct> Object

This element contains all the details about each and every available feature option for this product. Where there are similar/like fields in the AnnuityProduct level or the FeatureProduct level, only specify values here if they are different and need to override the defaults specified on AnnuityProduct or FeatureProduct. At least one FeatureOptProduct node is required for every FeatureProduct, and only one option may be elected within a FeatureProduct. Attribute: FeatureOptProduct id= “ ”


<FeatureOptProductKey> String See the description at the beginning of this chapter for usage & meaning.

<FeatureOptProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<ProductCode> String Unique code for this feature option, used by carrier to identify the selection of this feature option and to identify conflicts and requisites. The ProductCode is an identifier only; descriptive information about the feature option should not be inferred from the ProductCode. The ProductCode must be unique within the FeatureProduct being described.

<JurisdictionCC> <Jurisdiction> LookUp Table String= ‘State’ LookUp TableCode= ‘OLI_LU_STATE’

Choice Collection

Collection or list of all jurisdiction(s) where the option can legally be offered or sold. If this element and JurisdictionApproval are missing, it is assumed that the option is available in the states in which the feature AND product are available. Use JurisdictionCC instead of JurisdictionApproval if no dates are specified by individual states. Type Codes 1 = AL 2 = AK 4 = AZ 5 = AR 6 = CA 7 = CO 8 = CT 9 = DE 10 = DC 12 = FL 13 = GA 15 = HI

38 = NC 39 = ND 41 = OH 42 = OK 43 = OR 45 = PA 47 = RI 48 = SC 49 = SD 50 = TN 51 = TX 52 = UT 53 = VT 55 = VA 56 = WA 57 = WV 58 = WI 59 = WY 3 = American Samoa 14 = Guam 24 = Marshall Islands 46 = Puerto Rico 54 = Virgin Islands 101 = Alberta 102 = British Columbia 103 = Manitoba 104 = New Brunswick 105 = Newfoundland 106 = Northwest Territories


XML Element Name Type Description 16 = ID 17 = IL 18 = IN 19 = IA 20 = KS 21 = KY 22 = LA 23 = ME 25 = MD 26 = MA 27 = MI 28 = MN 29 = MS 30 = MO 31 = MT 32 = NE 33 = NV 34 = NH 35 = NJ 36 = NM 37 = NY

107 = Nova Scotia 108 = Ontario 109 = Prince Edward Island 110 = Quebec 111 = Saskatchewan 112 = Yukon Territories 113 = Nunavut Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The jurisdiction chosen must correspond to the PolicyProduct Issue Nation elected. Codes at lower level must be a subset of codes chosen at the higher levels.

<Name> String Full name of the rider or service feature option. <Description> String Free form description of feature option.

The description element be used as the Order Entry Display Name or Marketing Name.

<SaleEffectiveDate> Date The date before which this rider or arrangement option cannot be sold. This is the date rider or arrangement option is first available for sale. The format is: YYYY-MM-DD. If exact date is not available, an estimated date may be used, such as 1980-01-01.

<SaleExpirationDate> Date The last date through which the rider or arrangement option is available for sale, but additional deposits can continue. The format is: YYYY-MM-DD. If there is no Expiration Date, then do not send this element. A null value indicates that no such date has yet been declared. In the case where the ‘product’ is anything but a policy (e.g. Fund, Coverage, Feature), it may still be sold as an addition to an in-force policy, if that policy went into effect before the SaleExpirationDate. (e.g. 12/31/2003 means the product can be sold until the end of that day)

<NoNewMoneyDate> Date Date rider or service feature option is terminated or closed for all additional deposits. The format is: YYYY-MM-DD. If there is no termination date, then do not send it.


XML Element Name Type Description <QualifiedPlanCC> <QualifiedPlanType> LookUp Table String= ‘Qualified Plan Type’ LookUp Table Code= ‘OLI_LU_QUALPLAN’

Choice Collection

Allowable or permitted plan type(s) for this option. Use this element only if it is required to limit availability from that of the PolicyProduct and Ownership objects. <QualifiedPlanCC> and <QualifiedPlanEntity> must NOT be used concurrently as elements of the same <FeatureOptProduct>. These elements are mutually exclusive. (04-1.01-AN231) Type Code Translation 1 = Non-Qualified 2 = 401k 3 = 403b 4 = 457 Deferred Compensation 5 = IRA (408b) 6 = Roth IRA 7 = Educational IRA 8 = SEP/IRA 13 = HR10/Keogh 25 = Profit Sharing Plan 29 = Roth Conversion 30 = S.I.M.P.L.E. IRA (408k- replaced SARSEP) 33 = IRA Spousal 34 = Cash Balance Plan-Defined Contribution 35 = Cash Balance Plan-Defined Benefit 36 = Target Benefit Plan 37 = Foreign National 39 = Money Purchase 40 = SARSEP (408k) 41 = Texas ORP 42 = 403a (Qualified Employee Annuity Plan) 50 = Keogh 53 = Stretch IRA Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<DefaultInd>


Indicates the feature option code is the default for the feature when one is not chosen, but election of an option is mandatory. Example, when Death Benefit is chosen under Feature and no FeatureOption is chosen at issue, a default may occur to choose the Standard Death Benefit. True means this option will be the default. There cannot be more than one default assigned for all options within a Feature. The DefaultInd should only be used when the FeatureProduct SelectionType is 1 or 3: Required

<RevokableInd> Boolean 0=False 1=True

Indicates once the rider or service feature has been chosen whether the choice is revocable or irrevocable. True indicates that the service feature can be revoked.

<SignatureRequiredCode> LookUp Table String= ‘Signature Required’

TypeCode

Indicates if the signature is required before a feature option is activated. Type Code Translation


XML Element Name Type Description LookUp Table Code= ‘OLI_LU_SIGNREQUIRED’

1 = No Signature Required 2 = Required at Time of Application 3 = Required at Carrier Before Activation 4 = Electronic Signature Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<LivesType> LookUp Table String= ‘Coverage Lives’ LookUp Table Code= ‘OLI_LU_LIVESTYPE’

TypeCode Type code indicating the relation between the participants and coverage. Type Code Translation 1 = Single Life (Individual) 9 = Either Single or Joint 10 = Joint Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AgeCalculationType> LookUp Table String= ‘Age Calculation Method’ LookUp Table Code= ‘OLI_LU_AGECALCMETH’

TypeCode Indicates the algorithm used to determine age, given the date of birth and the effective date of the policy. Type Code Translation 2 = Age Last Birthday 3 = Age Nearest in days Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<ParticipantBasedOn> LookUp Table String= ‘Participant Role’ LookUp Table Code= ‘OLI_LU_PARTICROLE’

TypeCode Indicates which contract role player (e.g. Owner, Annuitant, Both Owner and Annuitant, etc.) drives the business logic around the feature option. For example, this determines whose age is used to underwrite for options, determines how the feature will be administered, and/or whose age is applied to issue age business rules, rate calculations, etc. Type Code Translation 18 = Owner 27 = Annuitant 36 = Both Annuitant and Owner Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<MinIssueAge> Integer Minimum age for all Covered Persons (i.e. the Annuitant) required in order that the rider or arrangement may be selected. Value Range: 0-199

<MaxIssueAge> Integer Maximum age for all Covered Persons (i.e. the Annuitant) allowed in order that the rider or arrangement may be selected. Value Range: 0-199

<MinIssueAgeOwner> Integer Minimum age of all Owners (including primary, joint, contingent, etc as applicable) required in order that the rider or arrangement may be selected. Value Range: 0-199

<MaxIssueAgeOwner> Integer Maximum age of all Owners (including primary, joint, contingent, etc as applicable) allowed in order that the rider


XML Element Name Type Description or arrangement may be selected. Value Range: 0-199

<MinIssueAgeJointCoveredPerson> Integer Present if the minimum issue age of the joint covered person (i.e. the Annuitant) is different than the minimum issue age of the Primary Annuitant. Value Range: 0-199

<MaxIssueAgeJointCoveredPerson> Integer Valued if the maximum issue age of the joint covered person (i.e. the Annuitant) is different than the maximum issue age of the Primary Annuitant. Value Range: 0-199

<MinContractAmt> Currency Minimum contract value allowed in order to select the rider or arrangement specified.

<MinRemainingBalanceAmt> Currency Minimum remaining balance allowed within the contract after being reduced by this rider or arrangement program amount.

<MinTransactionAmt> Currency Minimum transaction allowable for the feature option . This expresses a limit on the size of the modal amount. This should only be used when there is a limit on the modal amount, but either the annualized amount or the total program amount is captured for order entry.

* <MaxTransactionAmt> (04-1.01.AN240) Currency Maximum transaction amount allowed for the feature option. This expresses a limit on the size of the modal amount. This should only be used when there is a limit on the modal amount, but either the annualized amount or the total program amount is captured for order entry.

<MinTotalAmt> Currency Minimum amount of the total transactions within an arrangement program.

<SubPayDCAType> LookUp Table String= ‘Dollar Cost Averaging Type’

LookUp Table Code= ‘OLI_LU_DCATYPE’

TypeCode

Indicates the type of electronic processing the carrier supports for DCA accounts. Describing how subsequent payments are distributed to an account with an existing DCA program. Type Code Translation 1 = Add to Existing Program 2 = Started Over (Add to existing) 3 = Distributed Immediately (Not added to DCA program, but distributed to Standing Allocations) 4 = Start New Program (Multiple Programs Allowed Simultaneously)

<CostBP>

??? modify this… will created an MR to deprecate this element in favor of Fees… Ittai AN220 ???

Real One-time cost associated with a feature option, stated in basis points (i.e. 1%=100 basis points, or a credit of a 2% bonus is -200 basis points). May be expressed as a negative (debit or bonus) or positive (cost or credit) value. ??The use for modeling fees has been superseded by the Fee object. 04-1.01.AN221??

<RateCreditBP>

??? modify this… will created an MR to deprecate this element in favor of Fees… Ittai AN220 ???

Real Credit associated with rider or service program given in basis points. It has a continual affect impacting an interest rate or M&E. For a Fixed Rate Adjustment, the number of Basis Points that will be deducted from the fixed rate if certain features are selected.


XML Element Name Type Description For a Premium Bonus Rider, the number of basis points to be applied to the Premium (i.e. 3% bonus = 300 basis points). Note: Debits are represented by placing a (-) in front of the number.

<MinTerm> Integer The minimum allowable term within the rider or arrangement.

<MaxTerm> Integer The maximum allowable term within the rider or arrangement.

<TermQualifier> LookUp Table String= ‘Payment Mode’ LookUp Table Code= ‘OLI_LU_PAYMODE’

TypeCode Qualifies the min/max term of the rider or arrangement program. Type Code Translation 1 = Annually (Years) 4 = Monthly (Months) 8 = Daily (Days) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<MinPct> Percentage The minimum allowable percent within the rider or arrangement. This expresses a limit on the size of the modal amount computed as a percentage of the premium for the transaction. This should only be used when there is a limit on the modal amount, but either the annualized amount or the total program amount is captured for order entry.

<MaxPct> Percentage The maximum allowable percent within the rider or arrangement. This expresses a limit on the size of the modal amount computed as a percentage of the premium for the transaction. This should only be used when there is a limit on the modal amount, but either the annualized amount or the total program amount is captured for order entry.

<MaxNumSourceInvestProd> Integer Indicates the total number of source funds allowed at one time when the option is elected. If there is no limit, this field should not be sent.

<MaxNumDestinationInvestProd> Integer Indicates the total number of destination funds allowed at one time then the option is elected. If no limit, this field should not be sent.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 48 Chapter Four – Descriptions & Definitions <FeatureOptRequisite>


<FeatureOptRequisite> Object

This element indicates any other feature(s) or features option(s) that must be chosen in order to elect the rider or service feature option being described. This is a reference to a feature or feature option that is required in order to elect this FeatureOptProduct being described. If all options within a feature are required, then only the FeatureCode is required. <FeatureCode> String The feature <FeatureCode> which must be (i.e. are

required) to be selected with this feature option. <ProductCode> String Unique code which identifies the feature option.

Unique Code, referencing the <ProductCode> from <FeatureOptProduct> which identifies the feature option which conflicts with the feature option being described.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 49 Chapter Four – Descriptions & Definitions <FeatureProduct>


<FeatureProduct> Object

This element contains all the details about each and every available feature for this product. Here, the term “feature” is used loosely. A "Feature" in this object for annuities encompasses "rider", "arrangement", "service feature" and "program". Every optional component of a contract should be created as a FeatureProduct. Where there are similar/like fields in the AnnuityProduct level, only specify values here if they are different and need to override the defaults specified above. Attributes: FeatureProduct id= “ ” DataRep= “ ”

String “Full”

See the description at the beginning of this chapter for usage & meaning. Every object in the ACORD data model has an attribute called "DataRep" or Data Representation. This field indicates whether the data following is a full representation of the data, a partial feed, or a Remove/Delete request. Thus valid attribute values are "Full", "Partial" or "Remove".

<FeatureProductKey> Attribute: Persistence of Key

LookUp Table String= ‘Persistence of Key Code’

LookUp Table Code= ‘PERSISTKEY’

String Attribute

See the description at the beginning of this chapter for usage & meaning. Format: PolicyProductID+ ‘-’ + carrier-defined feature code (up to 15 char/alphanumeric) Generally useful only for Request/Response transaction method; however, NAVA recommends that this key be made permanent in all situations. A key is made permanent by sending the persist element which indicates the length of time a key persists. This code should always be set to ‘2’. Type Code Translation 2 = Permanent or Value Provided is Persistent Indefinitely (a permanent key is assigned by the owner of the data.) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<FeatureProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<FeatureCode> String Unique carrier-defined code which identifies the feature being described. Its purpose is to properly identify requisites and conflicts at the feature level. Is also used within requisites and conflicts at the feature option level. The FeatureCode is an identifier only; descriptive information about the feature option should not be inferred.


Choice Collection

Collection or list of all jurisdiction(s) where the product can legally be offered or sold. If this element and JurisdictionApproval are

37 = NY 38 = NC 39 = ND 41 = OH 42 = OK 43 = OR 45 = PA


XML Element Name Type Description missing, it is assumed that the feature is available in the states in which the product is available. Use JurisdictionCC instead of JurisdictionApproval if no dates are specified by individual states. Type Codes 1 = AL 2 = AK 4 = AZ 5 = AR 6 = CA 7 = CO 8 = CT 9 = DE 10 = DC 12 = FL 13 = GA 15 = HI 16 = ID 17 = IL 18 = IN 19 = IA 20 = KS 21 = KY 22 = LA 23 = ME 25 = MD 26 = MA 27 = MI 28 = MN 29 = MS 30 = MO 31 = MT 32 = NE 33 = NV 34 = NH 35 = NJ 36 = NM

47 = RI 48 = SC 49 = SD 50 = TN 51 = TX 52 = UT 53 = VT 55 = VA 56 = WA 57 = WV 58 = WI 59 = WY 3 = American Samoa 14 = Guam 24 = Marshall Islands 46 = Puerto Rico 54 = Virgin Islands 101 = Alberta 102 = British Columbia 103 = Manitoba 104 = New Brunswick 105 = Newfoundland 106 = Northwest Territories 107 = Nova Scotia 108 = Ontario 109 = Prince Edward Island 110 = Quebec 111 = Saskatchewan 112 = Yukon Territories 113 = Nunavut Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The jurisdiction chosen must correspond to the Issue Nation chosen. Codes at lower level must be a subset of codes chosen at the higher levels.


XML Element Name Type Description <Name> String Full name of the feature. <SelectionRule> LookUp Table String= ‘Rider Select Rule’ LookUp Table Code= ‘OLI_LU_RIDERSELECTRULE’

TypeCode Indicates whether the feature is optional or mandatory and whether the user is required to make a feature option selection or a default is allowed. For example, Death Benefit would be a mandatory feature with a default option allowed. Type Codes 1 = Rider Optional/Default Value of FeatureOption Allowed 2 = Rider Optional/User Selection of FeatureOption Required 3 = Rider Mandatory/Default Value of FeatureOption Allowed 4 = Rider Mandatory/User Selection of FeatureOption Required * 18 = Rider Mandatory/User Selection is Not Allowed (04-1.01.AN241)

<MaxNumInstances> Integer The maximum number of instances of this feature which is allowed on a contract concurrently. For example, if up to three DCA events may run at the same time, this element value is 3.

<FeatureMappingCode > LookUp Table String= ‘Object Type’ LookUp Table Code= ‘OLI_LU_OBJECTTYPE’

TypeCode Identifies the feature as a Rider or feature/arrangement. TypeCode Translation 86 = AnnRider 89 = Arrangement Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<RiderTypeCode> LookUp Table String= ‘Rider Type’ LookUp Table Code= ‘OLI_LU_RIDERTYPE’

TypeCode Unique identifier, which ties together information, related to the rider. Type Code Translation 19 = Nursing Home Rider / Long Term Facility Care & Service 96 = Premium Enhancement Extra Value Rider 203 = Terminal Illness Rider 204 = Guaranteed Income Benefit (Living Benefit Rider) 205 = Enhanced Earnings Benefit 206 = Death Benefit 207= Contingent Deferred Sales Charge Rider (Not Base Surrender Provision, a.k.a. an L Share Rider) 208= Earnings Max Rider 209= Pre-Selected Death Benefit 210= Extended Guarantee Period 211 = Secure Principal a.k.a. Beneficiary Protector Rider (03-2.01.AN05) 320 = Capital Preservation (MR 2.10?) 327=Living Benefit Rider (03-2.02.AN14) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.


XML Element Name Type Description <ArrType> LookUp Table String= ‘Arrangement Type’ LookUp Table Code= ‘OLI_LU_ARRTYPE’

TypeCode Unique identifier, which ties together information, related to the arrangement. Type Code Translation 2 = Dollar Cost Averaging 3 = Asset Rebalancing Sometimes Called Rebalancing (04-1.01.AN02) 4 = Interest Sweep 7 = Specified Amount Withdrawal (Net) 8 = Specified Amount Withdrawal (Gross) 9 = Surrender-Free Amount Withdrawal 10 = Interest Only Withdrawal (Net) 13 = Minimum Required Distribution Withdrawal 14 = Percentage of Value Withdrawal 19 = Override Standing Premium Allocation (Initial or subsequent premiums) 21 = Asset Allocation Customer Defined - sometimes called Rebalancing or may be defined by third party defined model (04-1.01.AN02) 22 = Auto Payment/Bank Drafting 24 = Special Dollar Cost Averaging 37 = Standing Allocation 38 = Systematic Withdrawal, Type Unspecified 39 = Subsequent Premiums 41 = Substantially Equal Payments (US only) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 53 Chapter Four – Descriptions & Definitions <FeatureRequisite>


<FeatureRequisite> Object

This object indicates which feature(s) must be present or elected in order to elect the rider or arrangement being described. <FeatureCode> String List <FeatureCode> of a feature which must be (i.e. is

required) to be selected with or prior to this feature. The <FeatureCode> must also exist in <FeatureProduct>. Note that the requirement is not reciprocal. If the feature being modeled must be elected to select the other feature, that must be modeled separately. For example, if B must be chosen to elect A, and A must be chosen to elect B, then each required FeatureRequisite objects.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 54 Chapter Four – Descriptions & Definitions <Fee>


<Fee> Object

The Fee Object identifies all fees associated with the investment, feature or policy object being described. Attribute: Fee id= “ ”


<FeeKey> String See the description at the beginning of this chapter for usage & meaning.

<FeeSysKey> String See the description at the beginning of this chapter for usage & meaning.

<FeeType>

LookUp Table String= ‘Fee Type’ LookUp Table Code= ‘OLI_LU_FEETYPE’

TypeCode Identifies type of fee being described. Type Code Translation 1 = Base Policy Fee (one-time initiation fee) 2 = Administrative Fee 3 = Marketing Fee i.e. 12-b1 4 = Base Mortality & Expense Charges 5 = Asset Based Admin Charges 6 = Asset Based Other Charges 7 = Mortality Charge 8 = Expense Charge 9 = Management Fee * 10 = Collection Fee * 22 = Premium Load Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Administrative Fee with a frequency of annual describes ‘Annual Contract Charge.’ Normally, Marketing and Management Fees apply to InvestProduct, while all but Management Fee can apply to PolicyProduct.

<FeeMode>

LookUp Table String= ‘Payment Mode’ LookUp Table Code= ‘OLI_LU_PAYMODE’

TypeCode Identifies the frequency of the fee. If no frequency applies, the do not send the element. Type Code Translation 1 = Annually 2 = Semi-Annually (twice a year) 3 = Quarterly 4 = Monthly 5 = Semi-Monthly (twice a month) 6 = Weekly 7 = Bi-Weekly (every two weeks) 8 = Daily Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<Description> String Narrative description of the fee. The description element can be used as the Order Entry Display Name or Marketing Name.


XML Element Name Type Description <FeeAmt> Integer

Currency If the FeeType references an amount, and/or the fee is represented in a dollar amount, this is the actual dollar amount charged.

<FeeCapAmt> Integer Currency

The maximum or ceiling amount of the fee. Charges are waived at (inclusive of) this amount.

<FeePct> Percentage If the FeeType references a percentage, and/or the fee is represented is a percentage amount, then this field contains the actual percentage fee or charge. (Basis Point fees should be multiplied by 100.)

<FeeCapPct> Percentage The maximum or ceiling percentage. Charges are waived at (inclusive of) this amount.

<FeeWaiverBasedOn>

LookUp Table String= ‘Rate Based On’ LookUp Table Code= ‘OLI_LU_RATEBASEDON’

TypeCode Indicates whether the threshold for having contract charges waived is based upon the amount of the premium or account value. Type Code Translation 1 = Premium 2 = Account Value 3 = Either Premium or Account Value (AN05) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<FeeWaiverAmt> Integer Currency

Amount of premium or account value at which the normal annual contract charge is waived.

<CommissionablePremCalcInd> Boolean 0=False 1=True

‘True’ indicates that this fee is included in the Gross-to-Net calculation to arrive at ‘CommissionablePremium’.

* <ChargeBasedOn> (04-1.01.AN221)

LookUp Table String= ‘Rate Based On’ LookUp Table Code= ‘OLI_LU_RATEBASEDON’

TypeCode Indicates upon what amount the fee percent is based. Type Code Translation 1 = Premium 2 = Account Value 6 = Net Amount At Risk 7 = Benefit Amount Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

* <TimingBasis>

(04-1.05.76)

LookUp Table String= ‘Statement Basis’ LookUp Table Code= ‘OLI_LU_ STMTBASIS’

TypeCode Indicates whether fees/charges are to be deducted on a calendar or policy anniversary basis. Type Code Translation 1 = Calendar Year Based 2 = Policy Anniversary Based

* <WaiverWindowInd> (04-1.05.76)

Boolean Indicates whether there is a charge free window allowed for a fee.


XML Element Name Type Description <WaiverWindowDays> (04-1.05.76) Integer The number of days for which a charge free window exists

for a fee.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 57 Chapter Four – Descriptions & Definitions <FreeLookInvestRuleProduct>


* <FreelookInvestRuleProduct> Object (04-1.01.AN216)

This object describes the free look investment rules indicating the provisions under which funds will be invested during the free look period of the policy. Attribute: FreelookInvestRuleProduct id= “ ”


<FreelookInvestRuleProduct Key> String See the description at the beginning of this chapter for usage & meaning.

<FreelookInvestRuleProductSysKey >


<FreeLookInvestDuration> Integer The number of days from the contract effective date to the end of the free look period. The number of days is inclusive, meaning the contract effective date and the last day of the free look period are counted/included.

<FreeLookReturnProvision> LookUp Table String= ‘Rate Based On’ LookUp Table Code= ‘OLI_LU_RATEBASEDON’

TypeCode Identifies the type of value to be returned if the Freelook provision is exercised. Type Code Translation 1 = Premium 2 = Account Value Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<MinIssueAge> String The minimum age for which this rule applies. <MaxIssueAge> String The maximum age for which this rule applies.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 58 Chapter Four – Descriptions & Definitions <FundingSourceMethodsAllowed>


<FundingSourceMethodsAllowed> Object

This object details the funding sources and methods available for policy purchases or subsequent payments.

Attribute: FundingSourceMethodsAllowed id= “ ”


<FundingSourceMethodsAllowedKey>


<FundingSourceMethodsAllowedSysKey>


<SourceOfFundsCC> <SourceOfFunds> LookUp Table String= ‘Source of Funds’ LookUp Table Code= ‘OLI_LU_SOURCEOFFUNDS’

Choice Collection

Indicates the source of premium (whether initial or subsequent premium). Type Code Translation 1 = Cash 2 = 1035 Exchange 3 = Death Benefit 4 = Annuity 5 = From a Pension Plan or Other Tax Qualified Plan 10 = Money from another policy (internal transfer) 12 = Money Market Fund 13 = Certificate of Deposit 15 = Savings Account 16 = Mutual Fund/Brokerage Account 17 = Rollover/Transfer from Another Insurance Policy 98 = Multiple Sources (such as 1035 and cash) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PaymentFormCC> <PaymentForm> LookUp Table String= ‘Payment Form’ LookUp Table Code= ‘OLI_LU_PAYMENTFORM’

Choice Collection

Allowable forms of payment . Type Code Translation 1 = Cash 2 = Credit Card 3 = Money Order 4 = Cashier’s Check 5 = Certified Check 6 = Personal Check 7 = Electronic Funds Transfer (EFT) 10 = Corporate Check 11 = Clearinghouse 12 = Wire 13 = Funds to follow * 19 = Payment from within this policy (04-1.01.AN239) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 59 Chapter Four – Descriptions & Definitions <FundingSourceMethodsAllowed>

XML Element Name Type Description <PaymentSourceCC> <PaymentSource> LookUp Table String= ‘Financial Activity Type’ LookUp Table Code= ‘OLI_LU_FINACTTYPE’

Choice Collection

Provides payment detail for specific source of funds. Type Code Translation 7 = Initial Payment 9 = Additional Payment Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 60 Chapter Four – Descriptions & Definitions <IncomeOptConflict>


<IncomeOptConflict> Object

This element indicates which IncomeOptions conflict (may not be elected) with the feature or feature option being described. A reference to an IncomePayoutProductOption that if elected this IncomePayoutProductOption or FeatureProduct or FeatureOptProduct is unavailable. IncomeOptConflict id = “”


< IncomeOptConflictKey> See the description at the beginning of this chapter for usage & meaning.

< IncomeOptConflictSysKey> See the description at the beginning of this chapter for usage & meaning.

<IncomePayoutProductOptionCode>

String The unique, carrier specific identification for this annuity income payout option code. This value correlates with the <ProductCode> from the IncomePayoutProductOption object. This ProductCode within the IncomePayoutProductOption must be passed back on an NBfA transaction within the Payout Object. When used within the Payout Object, specifies the Carrier defined Annuitization Payout Option selected for Immediate Annuities.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 61 Chapter Four – Descriptions & Definitions <IncomeOptRequisite>


<IncomeOptRequisite> Object

This element indicates which IncomeOptions that must be elected with the feature or feature option being described. A reference to an IncomePayoutProductOption that must be elected if this IncomePayoutProductOption or FeatureProduct or FeatureOptProduct is elected. IncomeOptRequisite id = “”


< IncomeOptRequisiteKey> See the description at the beginning of this chapter for usage & meaning.

< IncomeOptRequisiteSysKey> See the description at the beginning of this chapter for usage & meaning.

<IncomePayoutProductOptionCode>

String The unique, carrier specific identification for this annuity income payout option code. This value correlates with the <ProductCode> from the IncomePayoutProductOption object. This ProductCode within the IncomePayoutProductOption must be passed back on an NBfA transaction within the Payout Object. When used within the Payout Object, specifies the Carrier defined Annuitization Payout Option selected for Immediate Annuities.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 62 Chapter Four – Descriptions & Definitions <IncomeOptionInfo>


<IncomeOptionInfo> Object

A collection of Income Option selections, including their name and description. IncomeOptionInfo id = “”


< IncomeOptionInfoKey> See the description at the beginning of this chapter for usage & meaning.

< IncomeOptionInfoSysKey> See the description at the beginning of this chapter for usage & meaning.

<IncomeOption> LookUp Table String= ‘Income Option’ LookUp Table Code= ‘OLI_LU_INCOPTION’

TypeCode Describes the available payout options a carrier offers within an immediate annuity or at annuitization. Type Code Translation 1 = Life Only 2 = Greater of Period Certain and Life (Life with Period Certain) 3 = Period Certain Only 4 = Lesser of Period Certain or Life 5 = Life and Lump Sum 6 = Lump Sum 7 = Required Minimum Distribution 9 = With Installment Refund 10 = Pay a Percentage of Accumulated Value Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<IncomeOptionName>

Full name of the Income Option.

<IncomeOptionDescription> Integer Description of the Income Option.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 63 Chapter Four – Descriptions & Definitions <IncomePayoutProductOption>


<IncomePayoutProductOption> Object

IncomePayoutOption contains settlement information for immediate annuities and valid settlement options available upon annuitization of deferred annuities. Attribute: IncomePayoutProductOption id= “ ”


<IncomePayoutProductOptionKey>


<IncomePayoutProductOptionSysKey>


<ProductCode> String The unique, carrier specific identification for this Annuity Income Payout Option Code. This ProductCode within the IncomePayoutProductOption must be passed back on an NBfA transaction within the Payout Object. When used within the Payout Object, specifies the Carrier defined Annuitization Payout Option selected for Immediate Annuities.

<IncomeOptionCC> <IncomeOptionType> LookUp Table String= ‘Income Option’ LookUp Table Code= ‘OLI_LU_INCOPTION’ DEPRECATED in 2.10 via AN02

Choice Collection

Describes the available payout options a carrier offers within an immediate annuity or at annuitization. Type Code Translation 1 = Life Only 2 = Greater of Period Certain and Life (Life with Period Certain) 3 = Period Certain Only 4 = Lesser of Period Certain or Life 5 = Life and Lump Sum 6 = Lump Sum 7 = Required Minimum Distribution 9 = With Installment Refund 10 = Pay a Percentage of Accumulated Value Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<LivesType> LookUp Table String= ‘Coverage Lives’ LookUp Table Code= ‘OLI_LU_LIVESTYPE’

TypeCode Type code indicating the relation between the participants and coverage. Type Code Translation 1 = Single Life (Individual) 9 = Either Single or Joint 10 = Joint Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.


XML Element Name Type Description <AgeCalculationType> LookUp Table String= ‘Age Calculation Method’ LookUp Table Code= ‘OLI_LU_AGECALCMETH’

TypeCode Indicates the algorithm used to determine age given the date of birth and the effective date of the policy. Type Code Translation 1 = Age Next Birthday 2 = Age Last Birthday 3 = Age Nearest in days Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<LiquidityFeatureType> LookUp Table String= ‘Liquidity Feature Types’ LookUp Table Code= ‘OLI_LU_LIQUIDITYFEATURE’

TypeCode If a product provides for withdrawal of the commuted value it is considered to have a liquidity feature. The Liquidity feature type indicates if the product type allows the ability for withdrawals/liquidity. (04-1.01.AN203) Type Code Translation 1 = None 2 = Variable Only 3 = Fixed Only 4 = Fixed and Variable

<RevokableInd> Boolean 0=False 1=True

Indicates if once an option is chosen, whether it may be revoked or changed. True indicates that the option can be revoked.

<AnnuitizationMinDelayMonths> Integer Gives the minimum number of months that annuitization may be delayed before payout.

<PayoutType> LookUp Table String= ‘Payout Type’ LookUp Table Code= ‘OLI_LU_ANNPAYOUT’

Payout type of this payout Type Code Translation 1 = Immediate 2 = Deferred

<BenefitReductionBasedOn> LookUp Table String= ‘Benefit Reduction Based On’ LookUp Table Code= ‘OLI_LU_BENREDUCEBASEDON’

TypeCode Joint life payment options provide income for two individuals (annuitant and joint annuitant) as long as one of the individuals is alive. The annuity payments may or may not reduce on the death of the first individual. This is referred to as the "benefit reduction" For example, on the death of the annuitant, payments of 50% of the amount that would have been paid if the annuitant were living will be paid for the life of the joint annuitant. If the joint annuitant dies before the annuitant, the annuitant will continue to receive payments without the benefit reduction. Some joint life payment options provide that the benefit will be reduced on the first death regardless of who dies first. (04-1.01.AN203) Type Code Translation 1 = None (There is no reduction in benefit.) 2 = Primary Covered Person 3 = Contingent Covered Person 4 = Primary or Contingent Covered Person


XML Element Name Type Description <ContingentJointCC> <ContingentJointType> LookUp Table String= ‘Contingencies Joint’ LookUp Table Code= ‘OLI_LU_CONTINGJOINT’

Choice Collection

A contract providing income payments beginning when the named contingency occurs. OR On the occurrence of the contingency the payments made to the survival party or entity. Percent paid to survivor on a joint life option.

Type Code Translation 2 = First to Die (100%) 3 = Last to Die (0%) 5 = One Half 6 = One Third 7 = Two Thirds 8 = Custom 101-199 = 1%-99% Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<SplitPctIncrementsCC>

Choice Collection <Percentage>

Allowable increments between fixed and variable percentages of payout. The Split Percentage options are designated in the contract; and a Split is chosen by the client for the payout. Example: 5 = 5% 10 = 10% 25 = 25% Note: If no limits are imposed, the element should not be sent.

<AssumedInterestRateCC>

Choice Collection <Percentage>

Assumed Interest Rate. i.e. Assumed Investment Rate. Example: If 5% is chosen and gain is 5%, payments remain the same. Example: 1 = 1% 2.5 = 2.5% 4 = 4% 5.5 = 5.5% Etc.

<COLFixedPct> <Percentage>

Cost of Living Percentage.

<COLIndexCC> <COLIndex> LookUp Table String= ‘Cost of Living Rates’ LookUp Table Code= ‘OLI_LU_COLINDEX’

Choice Collection

Type of Cost of Living Index used. Type Code Translation 1 = CPIU (Consumer Price Index for Urban Workers) 2 = CPIW (Consumer Price Index for Workers General)

<COLIndexCapCC>

Choice Collection <Percentag

Cost of Living Index Cap. If CPI increases 10%, the cap limits rate used for payout calculation.


XML Element Name Type Description e>

Example: 1 = 1% 2.5 = 2.5% 4 = 4% 5.5 = 5.5%

<LevelizationOptionCC> <LevelizationOption> LookUp Table String= ‘Levelization Option Code’ LookUp Table Code= ‘OLI_LU_LEVELIZEDOPT’

Choice Collection

Indicates that a modal payout should be levelized annually. Type Code Translation 1 = Annual Levelization 2 = Unlevelized

<IncomeOptionRequired> 03-2.01.AN01 LookUp Table String= ‘Required Data Field’ LookUp Table Code= ‘OLI_LU_DATAREQ’

TypeCode Indicates whether or not the Income Option must be collected upon order entry. Type Code Translation 1 = Data collection is optional 2 = Data collection is required 3 = Do not collect data

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 67 Chapter Four – Descriptions & Definitions <InformationService>


<InformationService> Object

Contains the codes used by various data service providers for this investment. InformationService id= “ ”


<InformationServiceKey> String See the description at the beginning of this chapter for usage & meaning.

<InformationServiceSysKey> String See the description at the beginning of this chapter for usage & meaning.

<InformationServiceProvider> LookUp Table String= ‘Information Service Provider’ LookUp Table Code= ‘OLI_LU_INFOSRVPROVIDER’

TypeCode Provides the identity of the service provider to which the information in this object pertains. Type Code Translation 1 = Morningstar 2 = Lipper 3 = VARDS

<InformationServiceCode> String Contains the code that the service provider uses to refer to this investment.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 68 Chapter Four – Descriptions & Definitions <InvestProductInfo>


<InvestProduct> Object

Each and every available investment or fund is individually defined within the InvestProduct object. Each annuity product then lists the fund, based on Fund ID’s (<ProductCode>), that it has available via the InvestProductInfo object associated with the PolicyProduct.

Attributes: InvestProduct id= “ ” DataRep= “ ”

String “Full”

See the description at the beginning of this chapter for usage & meaning. Every object in the ACORD data model has an attribute called "DataRep" or Data Representation. This field indicates whether the data following is a full representation of the data, a partial feed, or a Remove/Delete request. Thus valid attribute values are "Full", "Partial" or "Remove".

<InvestProductKey>

Attribute: Persistence of Key



String Attribute

See the description at the beginning of this chapter for usage & meaning. Format: CarrierCode + ‘-’ + ProductCode (NAIC Code (5 char fund abbreviation) or IARD/CRD #) Generally useful only for Request/Response transaction method; however, NAVA recommends that this key be made permanent in all situations. A key is made permanent by sending the persist element which indicates the length of time a key persists. This type code should always be set to ‘2’. Type Code Translation 2 = Permanent or Value Provided is Persistent Indefinitely (a permanent key is assigned by the owner of the data.) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<InvestProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<InvestProductTypeCode> LookUp Table String= ‘Investment Product Type’ LookUp Table Code= ‘OLI_LU_INVESTPROD’

TypeCode Code that identifies the type of investment represented by the fund i.e. mutual fund, stock, bond. Type Code Translation 15 = Variable Annuity 23= Model (03-2.01.AN11) 24 = Category (Indicates that the InvestProduct is a step in multipart model. That is, it may be composed of other categories or InvestProducts.) (03-2.01.AN11) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<ProductCode> String Unique identifier assigned by the carrier that ties together information related specifically to the fund and fund


XML Element Name Type Description performance. This ProductCode must be passed back on an NBfA transaction.


Choice Collection

Collection or list of all jurisdiction(s) where the fund can legally be offered or sold. If this element or JurisdictionApproval is sent, jurisdiction is the same as the PolicyProduct. Use JurisdictionCC instead of JurisdictionApproval if no dates are specified by individual states. Type Codes 1 = AL 2 = AK 4 = AZ 5 = AR 6 = CA 7 = CO 8 = CT 9 = DE 10 = DC 12 = FL 13 = GA 15 = HI 16 = ID 17 = IL 18 = IN 19 = IA 20 = KS 21 = KY 22 = LA 23 = ME 25 = MD 26 = MA 27 = MI 28 = MN 29 = MS 30 = MO 31 = MT 32 = NE 33 = NV 34 = NH 35 = NJ 36 = NM 37 = NY 38 = NC 39 = ND

41 = OH 42 = OK 43 = OR 45 = PA 47 = RI 48 = SC 49 = SD 50 = TN 51 = TX 52 = UT 53 = VT 55 = VA 56 = WA 57 = WV 58 = WI 59 = WY 3 = American Samoa 14 = Guam 24 = Marshall Islands 46 = Puerto Rico 54 = Virgin Islands 101 = Alberta 102 = British Columbia 103 = Manitoba 104 = New Brunswick 105 = Newfoundland 106 = Northwest Territories 107 = Nova Scotia 108 = Ontario 109 = Prince Edward Island 110 = Quebec 111 = Saskatchewan 112 = Yukon Territories 113 = Nunavut Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The jurisdiction chosen must correspond to the Issue Nation chosen. Codes at lower level must be a subset of codes chosen at the higher levels.


XML Element Name Type Description <FullName> String Full legal name of the fund. <ShortName> String Abbreviated name of the fund. <Objective> LookUp Table String= ‘Investment Product Objective’

LookUp Table Code= ‘OLI_LU_INVESTOBJ’

TypeCode General investment objective of fund. Type Code Translation 1 = Aggressive Growth 2 = Balanced 3 = Equity Income 4 = Growth 5 = High Income 6 = International Equities (update; 03-02.01.AN15) 7 = Balanced/Asset Allocation (update; 03-02.01.AN15) 8 = Growth and Income 9 = Special Interest 10 = Tax Free 11 = Money Market 13 = Conservative Income 14 = Conservative Growth 16 = Small Company (03-02.01.AN15) 17 = Fixed Interest 27 = Government Bond Treasury (03-02.01.AN15) 30 = Small Company (03-02.01.AN15) 31 = Balanced/Income (03-02.01.AN15) 32 = Balanced/International (03-02.01.AN15) 33 = Balanced/Convertible (03-02.01.AN15) 34 = Corporate High Quality Bond (03-02.01.AN15) 34 = Corporate High Yield Bond (03-02.01.AN15) 36 = International Bond (03-02.01.AN15) 37 = Government Bond General (03-02.01.AN15) 38 = Government Bond Mortgage-Backed (03-02.01.AN15) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CarrierCode> String For InvestProducts, and keys referring to InvestProducts, this code represents the Managing Firm. Specifically, this should be the Fund Manager code (managing firm) when used in FundReference, InvestProduct, InvestProductInfo, SourceInvestProduct and SubAccount. When representing the Firm Manager, when not the Insurance Company, use the IARD/CRD number from the SEC’s ‘Investment Adviser Disclosure’ searchable database. The following is the URL to the site: http://www.adviserinfo.sec.gov/IAPD/Content/Search/iapd_OrgSearchInit.asp

<AssetClass> LookUp Table String= ‘Asset Class’

LookUp Table Code=

TypeCode Type of Asset this investment represents. TypeCode Translation 1 = Fixed 2 = Equity 3 = Cash

http://www.adviserinfo.sec.gov/IAPD/Content/Search/iapd_OrgSearchInit.asp

http://www.adviserinfo.sec.gov/IAPD/Content/Search/iapd_OrgSearchInit.asp


XML Element Name Type Description ‘OLI_LU_ASSETCLASS’ 5 = Debt

* 8 = Model (04-1.01.AN247) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CurrencyTypeCode> LookUp Table String= ‘Currency Type Code’

LookUp Table Code= ‘OLI_LU_CURRENCYTYPE’

TypeCode Identifies the type of currency accepted for investment into the fund. Type Code Translation 124 = CAD (Canadian Dollar) 840 = USD (United States Dollar) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<RateType> LookUp Table String= ‘Rate Type’

LookUp Table Code= ‘OLI_LU_RATETYPE’

TypeCode Identifies the type of investment in basic terms as being fixed or variable. TypeCode Translation 1 = Fixed 2 = Variable * 3 = Bonus (04-1.01.AN254) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<SaleEffectiveDate> Date The date before which this fund cannot be sold or elected. The format is: YYYY-MM-DD.

<SaleExpirationDate> Date The last date through which the fund is available for sale in new business, but additional deposits can continue. (e.g. 12/31/2003 means the product can be sold until the end of that day) The format is: YYYY-MM-DD If there is no Expiration Date, then do not send the element. A null value indicates that no such date has yet been declared. In the case where the ‘product’ is anything but a policy (e.g. Fund, Coverage, Feature), it may still be sold as an addition to an in-force policy, if that policy went into effect before the SaleExpirationDate.

<NoNewMoneyDate> Date Date after which no new money can be applied to this product (new business or inforce contracts). The format is: YYYY-MM-DD.

<VersionDate> Date The date which represents the version of the InvestProduct being sent. This is the date in which the carrier’s records (database) were last updated rather than when this particular transaction was prepared.

<MinPct> Percentage The minimum percentage required to deposit premium into the fund.




XML Element Name Type Description <DateBasedOn> 03-2.01.AN04 LookUp Table String= ‘Date Basis’ LookUp Table Code= ‘OLI_LU_DATEBASIS’




<InvestProductInfo> Object

This element provides the key or link to each available investment or fund available for this annuity product. Each fund is individually defined as an InvestProduct object; the <CarrierCode> <ProductCode> elements provides a key or link to each fund/investment which this specific product (in this jurisdiction) has available. If multiple alternate rates are available for this annuity product, the InvestProductInfo Object repeats for each allowable RateVariationKey for the investment. Within the context of InvestProduct, InvestProductInfo is used to define models or categories. Attribute: InvestProductInfo id= “ ”


<InvestProductInfoKey> String See the description at the beginning of this chapter for

usage & meaning.

<InvestProductInfoSysKey> String See the description at the beginning of this chapter for usage & meaning.

<CarrierCode> String Within the context of <InvestProduct>, and keys referring to InvestProduct, this code represents the Managing Firm. This element is used together with <ProductCode> to reference a fund detailed in the <InvestProduct> object.

<ProductCode> String Unique identifier that ties together information related

specifically to the fund. This element is used together with <ProductCode> to reference a fund detailed in the <InvestProduct> object.

<Sequence> Integer For an object that allows multiple objects with the same key, this element is used to define a unique occurrence of the object. Used to number the funds attached to a contract so they appear in a specified order.

<SaleEffectiveDate> Date The date before which this fund cannot be sold under this product. The date the fund is first available for sale or election within the product, model or category. The format is: YYYY-MM-DD. This date should not be before the SaleEffectiveDate specified on the <InvestProduct> object.

<SaleExpirationDate> Date The last date through which the fund is available for sale under this product, model or category, but additional deposits can continue. The format is: YYYY-MM-DD. This date should not be after the SaleExpirationDate specified on the <InvestProduct> object. If there is no Expiration Date, then do not send this element. A null value indicates that no such date has yet been declared. In the case where the ‘product’ is anything but a policy (e.g. Fund, Coverage, Feature), it may still be sold as an addition to an in-force policy, if that policy went into effect before the SaleExpirationDate. (e.g. 12/31/2003 means the product can be sold until the end of that day)


XML Element Name Type Description <NoNewMoneyDate> Date Date the fund is terminated or closed for all additional

deposits under this product. The format is: YYYY-MM-DD. This date should not be after the NoNewMoneyDate specified on the <InvestProduct> object. If there is no Termination Date, then do not send.

<RateVariationKey> * This element is deprecated as of 2.10.00. In this case, RateVariationKey will no longer be used as a pointer once RateVariationCode is added with the November 2003 Release Candidate. MR: 03-2.01.AN04

String This element acts as a pointer/link to a specific InvestProduct RateVariation aggregate thus providing a mechanism for defining alternate rates for an investment.

<RateVariationCode> String This element acts as a pointer/link to a specific InvestProduct RateVariation aggregate thus providing a mechanism for defining alternate rates for an investment by product.

<MinDepositAmt> 03-2.01.AN11 Currency The minimum amount that may be deposited into subaccount or allocated to the model or category.

<MaxDepositAmt> 03-2.01.AN11 Currency The maximum amount that may be deposited into subaccount or allocated to the model or category.

<MinDepositPct> 03-2.01.AN11 Percentage The minimum percentage that may be deposited into subaccount. In the case of Models, this is the minimum percent allocation defined for this model.

<MaxDepositPct> 03-2.01.AN11 Percentage The maximum percentage that may be deposited into subaccount. In the case of Models, this is the maximum percent allocation defined for this model.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 75 Chapter Four – Descriptions & Definitions <InvestRuleProduct>


* <InvestRuleProduct> Object (04-1.01.AN216)

This object describes the free look investment rules applicable to the product. Attribute: InvestRuleProduct id= “ ”


<InvestRuleProduct Key> String See the description at the beginning of this chapter for usage & meaning.

<InvestRuleProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<DefaultInd>


Indicates the rule is the default for the product when one is not chosen, but election of an option is mandatory.

<InvestRule > LookUp Table String= ‘Freelook Investment Rule’ LookUp Table Code= ‘OLI_LU_FREELOOKINVEST’

TypeCode Indicates how funds are to be invested during the Freelook period Type Code Translation 1 = Initial Allocation 2 = Safe Harbor

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 76 Chapter Four – Descriptions & Definitions <JurisdictionApproval>


<JurisdictionApproval> Object

The JurisdictionApproval object provides clarification on the jurisdictions where this object (PolicyProduct, InvestProduct, InvestProductInfo, FeatureProduct or FeatureOptProduct) is available, and may also describe the applicable dates. Indicates approval, expiration and similar dates, if applicable. JurisdictionApproval is to be used in place of JurisdictionCC when state and date information needs to be specified. JurisdictionApproval allows dates to be specified by individual states. Attribute: JurisdictionApproval id= “ ”


<JurisdictionApprovalKey> String See the description at the beginning of this chapter for

usage & meaning.

<JurisdictionApprovalSysKey> String See the description at the beginning of this chapter for

usage & meaning.


XML Element Name Type Description <JurisdictionCC> <Jurisdiction> LookUp Table String= ‘State’ LookUp TableCode= ‘OLI_LU_STATE’

Choice Collection

Collection or list of all jurisdiction(s) where the product can legally be offered or sold. If this element is not sent, the available jurisdictions are the same as the product (PolicyProduct). Type Codes 1 = AL 2 = AK 4 = AZ 5 = AR 6 = CA 7 = CO 8 = CT 9 = DE 10 = DC 12 = FL 13 = GA 15 = HI 16 = ID 17 = IL 18 = IN 19 = IA 20 = KS 21 = KY 22 = LA 23 = ME 25 = MD 26 = MA 27 = MI 28 = MN 29 = MS 30 = MO 31 = MT 32 = NE 33 = NV 34 = NH 35 = NJ 36 = NM 37 = NY 38 = NC 39 = ND 41 = OH 42 = OK

43 = OR 45 = PA 47 = RI 48 = SC 49 = SD 50 = TN 51 = TX 52 = UT 53 = VT 55 = VA 56 = WA 57 = WV 58 = WI 59 = WY 3 = American Samoa 14 = Guam 24 = Marshall Islands 46 = Puerto Rico 54 = Virgin Islands 101 = Alberta 102 = British Columbia 103 = Manitoba 104 = New Brunswick 105 = Newfoundland 106 = Northwest Territories 107 = Nova Scotia 108 = Ontario 109 = Prince Edward Island 110 = Quebec 111 = Saskatchewan 112 = Yukon Territories 113 = Nunavut Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The jurisdiction must correspond to Issue Nation chosen. Codes at lower level must be a subset of codes chosen at the higher levels.


XML Element Name Type Description <SaleEffectiveDate> Date Date before which the product is cannot be sold. The date

product is first available for sale. The format is: YYYY-MM-DD. Note: If exact date is not available, do not send the element.

<SaleExpirationDate> Date The last date through which the product is available for sale, but additional deposits can continue. The format is: YYYY-MM-DD If there is no Expiration Date, then do not send. A null value indicates that no such date has yet been declared. In the case where the ‘product’ is anything but a policy (e.g. Fund, Coverage, Feature), it may still be sold as an addition to an in-force policy, if that policy went into effect before the SaleExpirationDate. (e.g. 12/31/2003 means the product can be sold until the end of that day)

<InforceExclusionCalendarDate> Date

The calendar date after which this product can no longer be sold for in-force business. In the case where the ‘product’ is anything but a Policy (e.g. Fund, Coverage, Feature), additional money may still be applied to it, if it had been sold prior to the InforceExclusionCalendarDate. This date refers to the calendar date and not the contract date. You are comparing today’s date to this date. The format is: YYYY-MM-DD. Note: If there is no ‘InForceExclusionCalendarDate’, then do not send the element.

<InforceExclusionContractDate> Date The contract date after which this product can no longer be sold for in-force business. In the case where the ‘product’ is anything but a Policy (e.g. Fund, Coverage, Feature), additional money may still be applied to it, if it had been sold prior to the InforceExclusionContractDate. This date refers to the contract date and not the calendar date. You are comparing this date to the policy date. The format is: YYYY-MM-DD. Note: If there is no ‘InForceExclusionContractDate’, then do not send the element.

<NoNewMoneyDate> Date Date product is terminated or closed for all additional deposits. The format is: YYYY-MM-DD. Note: If there is no ‘NoNewMoney’ Date, then do not send the element.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 79 Chapter Four – Descriptions & Definitions <NumInvestProduct>


* <NumInvestProduct> Object (04-1.01.AN247)

This object enables restrictions and clarifications on how funds may be invested by type of fund, such as variable and fixed, for the feature option. Attribute: NumInvestProduct id= “ ”


< NumInvestProduct Key> String See the description at the beginning of this chapter for usage & meaning.

< NumInvestProduct SysKey> String See the description at the beginning of this chapter for usage & meaning.

<AssetClass> LookUp Table String= ‘Asset Class’

LookUp Table Code= ‘OLI_LU_ASSETCLASS’

TypeCode Type of Asset this investment represents. TypeCode Translation 1 = Fixed 2 = Equity 3 = Cash 5 = Debt 8 = Model Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<MaxNumDestinationInvestProd> String The maximum number of investments/funds allowed to be selected/used in specifying destinations in an allocation.

<MaxNumSourceInvestProd> String The maximum number of investments/funds allowed to be selected/used in specifying source funds in an allocation.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 80 Chapter Four – Descriptions & Definitions <Organization>


<Organization> Object

A sub object under Party, providing more detailed information about the producer/distributor or the carrier. Either the Organization or the Person object is required under Party. <OrganizationKey> String See the description at the beginning of this chapter for

usage & meaning. <OrganizationSysKey> String See the description at the beginning of this chapter for

usage & meaning. <AbbrName> String Abbreviated name of the organization <OrgCode> String Unique code for the organization. Defined as a short code

assigned by the organization to internally identify the organizational unit.

<DUNSNumber> String Unique number for the organization assigned by Dun and Bradstreet for credit reporting purposes.

<DTCCMemberCode> String Unique member code of the organization assigned by Depository Trust Clearing Corporation(DTCC).

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 81 Chapter Four – Descriptions & Definitions <Ownership>


<Ownership> Object

The Ownership object details ownership/entity information such as min/max ages, premium limits, and contract role counts that apply to a certain set of plans and owner entity types. A combination of ownership, plan and entity type can appear at most once, i.e. IRA as a qualified plan only appears once per entity type. Attribute: Ownership id= “ ”


<OwnershipKey> String See the description at the beginning of this chapter for usage & meaning.

<OwnershipSysKey> String See the description at the beginning of this chapter for usage & meaning.

<MaxNumPrimaryOwners> Integer Maximum number of primary owners allowed per contract. Greater than one indicates joint owners.

<MaxNumContingentOwners> Integer Maximum number of contingent owners allowed per contract. Greater than one indicates joint contingent owners are allowed on a contract.

<MaxNumPrimaryCoveredPersons>

Integer Maximum number of primary annuitants allowed per contract. Greater than one indicates joint annuitants are allowed.

<MaxNumContingentCoveredPersons>

Integer Maximum number of contingent annuitants allowed per contract. Greater than one indicates joint contingent annuitants are allowed.

<MaxNumPrimaryBeneficiaries> Integer Maximum number of primary beneficiaries allowed per contract.

<MaxNumContingentBeneficiaries>

Integer Maximum number of contingent beneficiaries allowed per contract.

<MaxNumCombinedBeneficiaries> Integer Maximum number of all types of beneficiaries allowed per contract including primary, contingent and tertiary beneficiaries.

<MinIssueAgeOwner>

Integer Minimum Issue Age for all Owners within the contract, including all primary, joint, contingent, etc. types. This value must be greater than or equal to the minimums defined for Primary, Joint and Contingent Owners if those elements are used. If the Owner is not a person, this value is not applicable (i.e. they do not default to the annuitant if the contract is owned by a non-person). Value Range: 0-199

<MaxIssueAgeOwner>

Integer Maximum Issue Age for all Owners within the contract including all primary, joint, contingent, etc. types. Must be less than or equal to maximums defined for Primary, Joint and Contingent Owners if those elements are used. If the Owner is not a person, this value is not applicable (i.e. they do not default to the annuitant if the contract is owned by a non-person). Value Range: 0-199

<MaxAddOnAgeOwner> Integer Maximum age where subsequent premium is accepted for all Owners within the contract. Must be less than or equal to maximum defined for Primary, Joint and Contingent Owners if those elements are used. If the Owner is not a person, this value is not applicable. Value Range: 0-199

<MinIssueAge> Integer Minimum Issue Age for all Annuitants within the contract.


XML Element Name Type Description Value Range: 0-199

<MaxIssueAge> Integer Maximum Issue Age for all Annuitants within the contract. Value Range: 0-199

<MaxAddOnAge> Integer Maximum age where subsequent premium is accepted for all Annuitants within the contract. Value Range: 0-199

<AllowExceptionsToAgeInd>


Indicates if exceptions to age minimums and maximums are permitted, thereby permitting a soft edit of min/max values. True indicates exceptions allowed.

<AllowExceptionsToPremiumInd> Boolean 0=False 1=True

Indicates if there are exceptions to minimum and maximum premiums allowed. True indicates exceptions allowed.

<MinPremiumInitialAmt> Currency Minimum Initial Premium accepted. Value Range: 0-+

<MinPremiumAddOnAmt> Currency Minimum Add-on (subsequent) Premium accepted. Value Range: 0-+

<MinPremiumAddOnEFTAmt>

Currency Minimum Add-on (subsequent) accepted if using EFT. Value Range: 0-+

<MaxPremiumInitialAmt> Currency Maximum Initial Premium accepted. Value Range: 0-+

<MaxPremiumAddOnAmt> Currency Maximum Add-on (subsequent) Premium accepted. Value Range: 0-+

<MinIssueAgeJointCoveredPerson>

Integer Minimum issue age of the joint annuitant(s). Use this value if the minimum issue age of the joint covered person is different than the MinIssueAge (i.e. of all Annuitants). Must be greater than or restricted to the MinIssueAge. Value Range: 0-199

<MaxIssueAgeJointCoveredPerson>

Integer Maximum issue age of the joint annuitant(s). Use this value if the maximum issue age of the joint annuitant(s) is different than the MaxIssueAge (i.e. of all Annuitants). Must be less than or restricted to the MaxIssueAge. Value Range : 0-199

<MinIssueAgePrimaryCoveredPerson>

Integer Minimum issue age of primary/first annuitant. Use this value if the minimum issue age of primary covered person is different than the MinIssueAge (i.e. of all Annuitants). Must be greater than or restricted to MinIssueAge. Value Range: 0-199

<MinIssueAgeContingentCovered Person>

Integer Minimum issue age of the contingent annuitant(s). Use this value if the minimum issue age of the contingent annuitant(s) is different than the MinIssueAge (i.e. of all Annuitants). Must be greater than or restricted to MinIssueAge. Value Range: 0-199

<MinIssueAgeContingentOwner>

Integer Minimum issue age of the contingent owner(s). Use this value if the minimum issue age of the contingent owner(s) is different than the MinIssueAgeOwner (i.e. of all Owners). Must be greater than or restricted to MinIssueAgeOwner. If the Owner is not a person, this value is not applicable. Value Range: 0-199

<MinIssueAgePrimaryOwner>

Integer Minimum issue age of the primary (first) owner. Use this value if the minimum issue age of the primary owner is different than the MinIssueAgeOwner (i.e. of all owners). Must be greater than or restricted to MinIssueAgeOwner. If the Owner is not a person, this value is not applicable.


XML Element Name Type Description Value Range: 0-199

<MinIssueAgeJointOwner>

Integer Minimum issue age of the joint owner(s). Use this value if the minimum issue age of the joint owner(s) is different than the MinIssueAgeOwner (i.e. of all Owners). Must be greater than or restricted to MinIssueAgeOwner. If the Owner is not a person, this value is not applicable. Value Range: 0-199

<MaxIssueAgePrimaryCoveredPerson>

Integer Maximum issue age of the primary (first) annuitant. Use this value if the maximum issue age of the primary annuitant is different than the MaxIssueAge (i.e. of all annuitants). Must be less than or restricted to MaxIssueAge. Value Range: 0-199

<MaxIssueAgeContingentCoveredPerson>

Integer Maximum issue age of the contingent annuitant(s). Use this value if the maximum issue age of the contingent annuitant is different than the MaxIssueAge (i.e. of all annuitants). Must be less than or restricted to MaxIssueAge. Value Range: 0-199

<MaxIssueAgeContingentOwner>

Integer Maximum issue age of the contingent owner(s). Use this value if the maximum issue age of the contingent owner(s) is different than the MaxIssueAgeOwner (i.e. of all owners). Must be less than or restricted to MaxIssueAgeOwner. If the Owner is not a person, this value is not applicable. Value Range: 0-199

<MaxIssueAgePrimaryOwner>

Integer Maximum issue age of the primary owner. Use this value if the maximum issue age of the primary owner is different than the MaxIssueAgeOwner (i.e. of all owners). Must be less than or restricted to MaxIssueAgeOwner. If the Owner is not a person, this value is not applicable. Value Range: 0-199

<MaxIssueAgeJointOwner>

Integer Maximum issue age of the joint owner(s). Use this value if the maximum issue age of the joint owner(s) is different than the MaxIssueAgeOwner (i.e. of all owners). Must be less than or restricted to MaxIssueAgeOwner. If the Owner is not a person, this value is not applicable. Value Range: 0-199

<OwnerJointAndContingentAllowed> (03-2.01AN21)


Indicates whether both Joint and Contingent Owners are allowed. 0 = No (they are mutually exclusive) 1= Yes (they are both allowed)

<CoveredPersonJntAndCntngntAllwd> (03-2.01AN21)


Indicates whether both Joint and Contingent Annuitants are allowed. 0 = No (they are mutually exclusive) 1= Yes (they are both allowed)

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 84 Chapter Four – Descriptions & Definitions <Party>


<Party> Object

The Party object provides a place to describe various parties to this Product Profile, most notably the annuity carrier and all producers that may sell the annuity. Like the ProductProfile object, the Party object is a general, generic aggregate which holds information common to all parties. Under <Party> are additional, more detailed objects, such as <Carrier> which contains more detailed information about a carrier party. Generally in an Annuity Product Profile there will be at least one Party with Carrier information. The ACORD schema requires either the Person object or Organization object; the PPfA standard uses the Organization object and does not use Person. Attribute: Party id= “ ”


<PartyTypeCode> Lookup Table String= ‘Party Type’ Lookup Table Code= ‘OLI_LU_PARTY’

TypeCode Type of party existing in the collection. Select one of the following: Type Code Translation 1 = Person 2 = Organization

<PartyKey> String See the description at the beginning of this chapter for usage & meaning.

<PartySysKey> String See the description at the beginning of this chapter for usage & meaning.

<FullName> String Full Legal Name of the 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. When Party.Type is "Organization", FullName is the full, legal name of the organization.

<GovtID> Integer 9-digit Federal Tax ID of the Party. Data should be stored as a string with NO formatting.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 85 Chapter Four – Descriptions & Definitions <PaymentModeMethodProduct>


<PaymentModeMethProduct> Object

PaymentModeMethProduct object further describes the allowable modes, methods and s.

* <PaymentModeMethProductKey> String See the description at the beginning of this chapter for usage & meaning.

*<PaymentModeMethProductSysKey>


<PaymentModeMethDesc> String A description used to describe this combination of Payment Mode and Payment Method collectively.

<PaymentMode>



TypeCode Describes the allowable frequency. Type Code Translation 1 = Annually 2 = Semi-Annually (twice a year) 3 = Quarterly 4 = Monthly 5 = Semi-Monthly (twice a month) 6 = Weekly 7 = Bi-Weekly (every two weeks) 8 = Daily 100 = Any Pay mode is Allowed Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PaymentMethod> LookUp Table String= ‘Payment Method’ LookUp Table Code= ‘OLI_LU_PAYMETHOD’

TypeCode 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 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.

Type Code Translation 1 = No Billing 7 = Electronic Funds Transfer (EFT) 9 = Credit Card Billing 27 = Receiving Carrier to Request EFT Release of Funds (03-2.01.AN08) 28 = Distributor Has Requested EFT Release of Funds (03-2.01.AN08) Note: This is a partial list from the current ACORD spec.


XML Element Name Type Description Please see current spec. for additional codes. This element has been replaced with PaymentForm with ACORD’s 2.10 Release.

<PaymentFormCC> <PaymentForm> LookUp Table String= ‘Payment Form’ LookUp Table Code= ‘OLI_LU_PAYMENTFORM’

Choice Collection

Allowable payment forms. Type Code Translation 1 = Cash 2 = Credit Card 3 = Money Order 4 = Cashier’s Check 5 = Certified Check 6 = Personal Check 7 = Electronic Funds Transfer (EFT) 10 = Corporate Check 11 = Clearinghouse 12 = Wire 13 = Funds To Follow (03-2.01.AN08) * 19 = Payment from Within the Policy (04-1.01.AN239) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AllowedDayCC> <AllowedDay>

Choice Collection <Integer>

This will be a choice of days from 1-31. Type Code Translation 1 = 1st 2 = 2nd 3 = 3rd 4 = 4th 5 = 5th 6 = 6th

7 = 7th 8 = 8th 9 = 9th

10 = 10th 11 = 11th 12 = 12th

13 = 13th

14 = 14th

15 = 15th 16 = 16th 17 = 17th 18 = 18th 19 = 19th 20 = 20th 21 = 21st 22 = 22nd 23 = 23rd

24 = 24th

25 = 25th 26 = 26th 27 = 27th 28 = 28th 29 = 29th 30 = 30th 31 = 31st

* 34 = Last Day Note: Allowable days are indicated here only if there is a limitation.

* <AllowedBusinessDayCC> <AllowedBusinessDay> (04-1.01.AN182)


This will be a choice of days from 1-31. Type Code Translation 1 = 1st 2 = 2nd 3 = 3rd 4 = 4th 5 = 5th 6 = 6th

7 = 7th 8 = 8th 9 = 9th

10 = 10th 11 = 11th 12 = 12th

13 = 13th

14 = 14th

15 = 15th 16 = 16th 17 = 17th 18 = 18th 19 = 19th 20 = 20th 21 = 21st 22 = 22nd 23 = 23rd

24 = 24th

25 = 25th 26 = 26th 27 = 27th 28 = 28th 29 = 29th 30 = 30th 31 = 31st

34 = Last Day Note: Allowable days are indicated here only if there is a limitation.


XML Element Name Type Description * <MinTerm> (04-1.01.AN182) Integer Minimum time units allowable in the term. TermQualifier

provides the frequency/mode. Defines the minimum term permissible for a form or method and/or mode, if applicable.

* <MaxTerm> (04-1.01.AN182) Integer Maximum time units allowable in the term. TermQualifier provides the frequency/mode. Defines the maximum term permissible for a form or method and/or mode, if applicable.

* <TermQualifier> (04-1.01.AN182) LookUp Table String= ‘Payment Mode’ LookUp Table Code= ‘OLI_LU_PAYMODE’

TypeCode Qualifies the minimum and/or maximum term. Type Code Translation 1 = Annually (Years) 4 = Monthly (Months) 8 = Daily (Days) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

* <MinPct> (04-1.01.AN182) Percentage Defines the minimum percentage permissible for a method and/or mode, if applicable.

* <MaxPct> (04-1.01.AN182) Percentage Defines the maximum percentage permissible for a method and/or mode, if applicable.

* <MinTransactionAmt> (04-1.01.AN182)

Currency Defines the minimum transaction amount for any modal and/or method of payment, if applicable.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 88 Chapter Four – Descriptions & Definitions <PeriodCertainCC>


<PeriodCertainCC> Object

PeriodCertainCC object further describes the duration of each available period certain. This object only applies to those Income Options which include period certain. <PeriodCertainMode>



TypeCode The mode or qualifier of the periods allowed in a period certain. Type Code Translation 1 = Annually (Years) 4 = Monthly (Months) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PeriodCertainPeriods> <PeriodCertainCC>


Number of periods allowed under a period certain option. Note: If no limits are imposed, PeriodCertainMode and PeriodCertainPeriod elements should not be sent.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 89 Chapter Four – Descriptions & Definitions <PolicyProduct>


<PolicyProduct> Object

ProductProfile contains general, non-annuity specific information about the product. Detailed annuity specific information is sent in the AnnuityProduct object. ACORD users will note that there are many additional fields in the ACORD <PolicyProduct> object. The elements listed here are the ones relevant for a Product Profile for Annuities. Attributes: PolicyProduct id= “ ” DataRep= “ ”

PartyID= “ ”

String “Full” String

See the description at the beginning of this chapter for usage & meaning. Every object in the ACORD data model has an attribute called "DataRep" or Data Representation. This field indicates whether the data following is a full representation of the data, a partial feed, or a Remove/Delete request. Thus valid attribute values are "Full", "Partial" or "Remove". For PPfA this attribute occurs on PolicyProduct, FeatureProduct, InvestProduct and Relation objects. PartyID references the party related to the product being described by linking to the id within the Party object for a carrier. In the case of PolicyProduct, the PartyID and id within Party link to the Carrier offering the product.

<PolicyProductKey>

Attribute: Persistence of Key LookUp Table String= ‘Persistence of Key Code’


String Attribute

See the description at the beginning of this chapter for usage & meaning. Format: CUSIP + ‘-’+ carrier-defined unique id (9char) (up to 15 char/alphanumeric) A key is made permanent by sending the persist element which indicates the length of time a key persists. This type code should always be set to ‘2’. Type Code Translation 2 = Permanent or Value Provided is Persistent Indefinitely (a permanent key is assigned by the owner of the data.) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PartyProductSysKey> String See the description at the beginning of this chapter for usage & meaning.

<CarrierCode> String Insurance Carrier’s NAIC Code as a unique identifier. This element indicates the manufacturer (i.e. writing company) of the annuity and correlates with data present on the <Carrier> object.

<PlanName> String Full legal name of the product.


XML Element Name Type Description <ProductCode> String Insurance Carrier’s internal code for the product.

Each PolicyProduct object must have a unique ProductCode for entity recognition purposes.

<VersionDate>

Date The date which represents the version of the profile being sent. This is the date in which the carrier’s records (database) were last updated rather than when this particular transaction was prepared.

<ShortName> String Short product name used most commonly. <Description> String Free-form narrative description of the product.

Description element may be used as the Order Entry Display Name or Marketing Name.

<PolicyProductTypeCode> LookUp Table String= ‘Policy Product Type’ LookUp Table Code= ‘OLI_LU_POLPROD’

TypeCode Indicates type of Annuity this profile is describing. Type Code Translation 9 = Fixed Annuity 10 = Variable Annuity 11 = Indexed Annuity Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<PolicyProductForm> LookUp Table String= ‘Holding Form’ LookUp Table Code= ‘OLI_LU_HOLDINGFORM’

TypeCode Identifies product as whether product is individual or group. Type Code Translation 1 = Individual 2 = Group Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<LineOfBusiness> LookUp Table String= ‘Line of Business’

LookUp Table Code= ‘OLI_LU_LINEBUS’

TypeCode Identifies the type of product this profile is describing. Type Code Translation 2=Annuity Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<ParticipantBasedOn> LookUp Table String= ‘Participant Role’

LookUp Table Code= ‘OLI_LU_PARTICROLE’

TypeCode Indicates which contract role player (e.g. Owner, Annuitant, Both Owner and Annuitant, etc.) drives the business logic around the product. For example, this determines whose age is used determine how the product will be administered, and/or whose age is applied to issue age business rules, rate calculations, etc. Type Code Translation 18 = Owner 27 = Annuitant 36 = Both Annuitant and Owner 42 = Owner (if owner is a natural person, otherwise use annuitant)


XML Element Name Type Description Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CurrencyTypeCode> LookUp Table String= ‘Currency Type Code’ LookUp Table Code= ‘OLI_LU_CURRENCYTYPE’

TypeCode Identifies the type of currency accepted. TypeCode Translation 124 = CAD (Canadian Dollar) 840 = USD (United States Dollar) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CusipNum> String CUSIP (Committee on Uniform Securities Identification Procedures) number, which is assigned by Standard & Poor’s, which identifies the product. More info at www.CUSIP.com.

<IssueNation> LookUp Table String= ‘Nation’ LookUp Table Code= ‘OLI_LU_NATION’

TypeCode Indicates the nation in which the product will be sold. Type Code Translation 1 = United States of America 2 = Canada Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.


Choice Collection

Collection or list of all jurisdiction(s) where the product can legally be offered or sold. Use JurisdictionCC instead of JurisdictionApproval if no dates are specified by state. Type Codes 1 = AL 2 = AK 4 = AZ 5 = AR 6 = CA 7 = CO 8 = CT 9 = DE 10 = DC 12 = FL 13 = GA 15 = HI 16 = ID 17 = IL 18 = IN

38 = NC 39 = ND 41 = OH 42 = OK 43 = OR 45 = PA 47 = RI 48 = SC 49 = SD 50 = TN 51 = TX 52 = UT 53 = VT 55 = VA 56 = WA 57 = WV 58 = WI 59 = WY 3 = American Samoa 14 = Guam 24 = Marshall Islands 46 = Puerto Rico 54 = Virgin Islands 101 = Alberta 102 = British Columbia 103 = Manitoba 104 = New Brunswick 105 = Newfoundland

http://www.cusip.com/


XML Element Name Type Description 19 = IA 20 = KS 21 = KY 22 = LA 23 = ME 25 = MD 26 = MA 27 = MI 28 = MN 29 = MS 30 = MO 31 = MT 32 = NE 33 = NV 34 = NH 35 = NJ 36 = NM 37 = NY

106 = Northwest Territories 107 = Nova Scotia 108 = Ontario 109 = Prince Edward Island 110 = Quebec 111 = Saskatchewan 112 = Yukon Territories 113 = Nunavut Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The jurisdiction chosen must correspond to Issue Nation chosen. Codes at lower level must be a subset of codes chosen at the higher levels.

<SaleEffectiveDate> Date Date product is first available for sale. The format is: YYYY-MM-DD.

<SaleExpirationDate> Date The last date through which the product is available for sale, but additional deposits can continue. The format is: YYYY-MM-DD If there is no Expiration Date, then do not use this element. A null value indicates that no such date has yet been declared.

<NoNewMoneyDate> Date This is the first date the product is terminated or closed for all additional deposits. The format is: YYYY-MM-DD. Note: If there is no ‘NoNewMoney’ Date, then do not send this element.

<AgeCalculationType> LookUp Table String= ‘Age Calculation Method’ LookUp Table Code= ‘OLI_LU_AGECALCMETH’

TypeCode Indicates the algorithm used to determine age given the date of birth and the effective date of the policy. Type Code Translation 2 = Age Last Birthday 3 = Age Nearest in days Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<ScheduledPaymentCC> <ScheduledPayment> LookUp Table String= ‘Payment Method’ LookUp Table Code= ‘OLI_LUI_PAYMETH’ DEPRECATED

Choice Collection

DEPRECATED IN 2.11 via 04-1.01.AN205 Collection of allowable scheduled payments. Type Code Translation 1 = No Billing 2 = Regular Billing 3 = Irregular Billing 4 = Paid in Advance 5 = List Billing


XML Element Name Type Description 6 = Payroll Deduction 7 = Electronic Funds Transfer 8 = Government Allotment 9 = Credit Card Billing 10 = Collection Institution 11 = Suspended Billing 12 = Pay from a Premium Deposit Fund 13 = Pay from Special Accounts 14 = Combined Billing Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<MaxNumAgents> Integer Maximum number of agents allowed per contract. This is typically an administrative, not contractual, limitation.

<MaxNumInvestProducts> Integer Maximum number of funds that can be selected with on a contract. This includes the fund allocations and all funds involved in arrangements (service programs).

<IllustrationReqForSaleInd> Boolean 0=False 1=True

Indicates whether an illustration is required prior to the sale of the product. True indicates that an illustration is required prior to sale of this product.

<LOIPeriodType> LookUp Table String= ‘Payment Mode’ LookUp Table Code= ‘OLI_LUI_PAYMODE’

TypeCode The unit of measure for the LOI period. Type Code Translation 1 = Annually 3 = Quarterly 4 = Monthly 6 = Weekly 8 = Daily Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<LOIPeriodDuration>

Integer The duration of the LOI period. Number of days, months, etc. based on LOIPeriodType.

<TaxWithholdingCollect> 03-2.01.AN01

Integer Indicates whether or not the Tax Withholding information for Federal and State is required to be collected for this product upon order entry.

<GuarLifetimeRate> ?? ??

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 94 Chapter Four – Descriptions & Definitions <PolicyProductInfo>


<PolicyProductInfo> Object

ProductProfileInfo contains general, non-annuity specific information about the product. Detailed annuity specific information is in the AnnuityProduct object. If the object is referenced from PolicyProduct, it describes the generic, overall product information. If the object is referenced from DistributionAgreement, it is intended to provide information on allowed products and pre-sale commissions’ defaults. From the DistributionAgreement, it describes specifics on the agreement between the Carrier and the Producer (firm). The PolicyProductInfo associated with DistributionAgreement should use or limit detail specified in PolicyProduct; it should not increase availability. Attributes: PolicyProductInfo id= “ ”


<PolicyProductID>

String RefID for PolicyProduct. Provides link to PolicyProduct being referenced.

<PolicyProductInfoKey> String See the description at the beginning of this chapter for usage & meaning..

<PolicyProductInfoSysKey> String See the description at the beginning of this chapter for usage & meaning.

<ProductCode> String The Carrier’s internal code for the product. This, combined with <CarrierCode> must reference a valid <ProductCode> <CarrierCode> defined in the <PolicyProduct> object.

<CarrierCode> String Represents the Carrier (manufacturer) of the annuity product. This, combined with <ProductCode> must reference a valid <ProductCode> <CarrierCode> defined in the <PolicyProduct> object.


If associated with the PolicyProduct object this reflects if the carrier will accept netting transactions. If associated with DistributionAgreement, this indicates if the carrier will accept netting transactions from this Distributor. True indicates netting is allowed.

<CommissionScheduleKey>

String This element is used only with the DistributionAgreement parent object. The commission schedule data is defined in <CommissionSchedule> and <XTbML> objects. NOTE: CommissionScheduleCode is used for Entity Recognition instead of CommissionScheduleKey.

* <CommissionScheduleCode> (04-1.01.AN248)

String This element, when combined with CarrierCode, enables entity recognition to CommSchedule.

<DefaultCommCode> String This element is used only with the DistributionAgreement parent object. This is the default commission option (chosen by the distributor if associated with DistributionAgreement) to be utilized when an option is not selected at the time of sale.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 95 Chapter Four – Descriptions & Definitions <PolicyProductInfo>

XML Element Name Type Description <AdvancingAllowedInd> 03-2.01.AN19


Indicates if advance commissions may be accepted on this product, or with the distributor if associated with DistributionAgreement.



<DateBasedOn> 03-2.01.AN04 LookUp Table String= ‘Date Basis’ LookUp Table Code= ‘OLI_LU_DATEBASIS’


© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 96 Chapter Four – Descriptions & Definitions <Producer>


< Producer > Object

An agent, agency, broker, broker/dealer, or distributor. This captures the additional information you have on a commission earning party. For our purposes “Producer” must be passed through to obtain COMPANY level data. This is an empty holding object (no data elements required, all detail is under Carrier Appointment to identify the firm). We assume valid licenses exist in order to be appointed, and this information will NOT be duplicated here. Attributes: Producer id= “ ”


<ProducerKey> String See the description at the beginning of this chapter for usage & meaning.

<ProducerSysKey> String See the description at the beginning of this chapter for usage & meaning.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 97 Chapter Four – Descriptions & Definitions <QualifiedPlanEntity>


<QualifiedPlanEntity> Object

The QualifiedPlanEntity object is used to define the allowable types of plans within a product as they apply to entity relationships. <QualifiedPlanCC> <QualifiedPlanType> LookUp Table String= ‘Qualified Plan Type’ LookUp Table Code= ‘OLI_LU_QUALPLAN’

Choice Collection

Allowable or permitted plan types. Definitions of US-based plan type can be found on www.irs.gov. Type Code Translation 1 = Non-Qualified 2 = 401k 3 = 403b 4 = 457 Deferred Compensation 5 = IRA (408b) 6 = Roth IRA 7 = Educational IRA 8 = SEP/IRA 25 = Profit Sharing Plan 30 = S.I.M.P.L.E. IRA (408k- replaced SARSEP) 33 = IRA Spousal 34 = Cash Balance Plan-Defined Contribution 35 = Cash Balance Plan-Defined Benefit 36 = Target Benefit Plan 37 = Foreign National 39 = Money Purchase 40 = SARSEP (408k) 41 = Texas ORP 42 = 403a (Qualified Employee Annuity Plan) 50 = Keogh (a.k.a. HR10) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<AccountDesignationCC> <AccountDesignation> LookUp Table String= ‘Account Designation’ LookUpTableCode= ‘OLI_LU_ACCTDES’

Choice Collection

Identifies how the contract is registered; the types of allowable owner designations for this policy by qualified plan. Type Code Translation 3 = Owner 4 = Self directed 5 = Custodial 6 = UGMA/UTMA 7 = Trust 8 = Joint Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 98 Chapter Four – Descriptions & Definitions <RateAgencyInfo>


* <RatingAgencyInfo> Object (04-1.01.AN252)

A collection of properties used to describe the ratings that various agencies have assigned to a party. For a carrier, this would be rating agencies like Moody's, Dupp & Phelps, Standard & Poors. For a person this could be rating organizations like Equifax for credit scores. Attribute: RatingAgencyInfo id= “ ”


<RatingAgencyInfoKey> String See the description at the beginning of this chapter for usage & meaning.

<RatingAgencyInfoSysKey> String See the description at the beginning of this chapter for usage & meaning.

<RatingSource> LookUp Table String= ‘Rating Agency

LookUp Table Code= ‘OLI_LU_RATINGSRC

TypeCode Name of the rating agency assigning the Rating Value. Nationally Recognized Statistical Rating Organizations Type Code Translation 1 = Standard & Poors 2 = A.M. Best 3 = Moody’s Investor Service 4 = Fitch, Inc. 5 = Weiss Ratings, Inc. 6 = Dominion Bond Rating Service, LTD

<RatingValue> String The rating (A++, A, B, etc) assigned to the carrier by the rating agency.

<RatingDescription> String Descriptive name for the RatingValue, such as ‘Very Good.’ <EffDate> Date Effective date of the rating. <TermDate> Date Expiration date of the rating.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 99 Chapter Four – Descriptions & Definitions <RateVariation>


<RateVariation> Object

The RateVariation object further describes fixed interest rate information, and also provides a mechanism for defining alternate rates for an investment which may be used by different products (<PolicyProduct>) and feature options (<FeatureOptProduct>). Attributes: RateVariation id= “ ”


<RateVariationKey> String See the description at the beginning of this chapter for usage & meaning.

<RateVariationSysKey> String See the description at the beginning of this chapter for usage & meaning.

<RateType>

LookUp Table String= ‘Rate Type’

LookUp Table Code= ‘OLI_LU_RATETYPE’

TypeCode Identifies type of rate being described. Type Code Translation 5 = Declared 6 = Bonus 7 = Guaranteed 8 = Guaranteed Lifetime 9 = Growth Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<RateVariationCode>

String This element acts as a pointer/link to a specific InvestProduct aggregate thus providing a mechanism for defining alternate rates for an investment.

<GuaranteeDuration> Integer The overall duration that this particular rate variation signifies - e.g. 3 year, 5 year, 6 month. The field DurQualifier indicates the mode it corresponds to (e.g. a month period, year period, etc).

<DurQualifier> LookUp Table String= ‘Payment Mode’ LookUp Table Code= ‘OLI_LU_PAYMODE’

TypeCode Type of duration applicable to the rate being described in XTbML??. Type Code Translation 1 = Years (Annually) 4 = Months (Monthly) Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<TableIdentity> String Unique Identifier for the XTbML table used to store interest rates. This along with ProviderDomain provides a unique key for the table.

<ProviderDomain> String The domain name of the provider. This along with TableIdentity provides a unique key for the table.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 100 Chapter Four – Descriptions & Definitions <SourceInvestProduct>


<SourceInvestProduct> Object

This object indicates which fund(s) are available as source fund(s) within the rider or arrangement option being described. It must use the same ProductCode and CarrierCode combinations as used in the <InvestProduct> and <PolicyProduct> <InvestProductInfo> objects. If the <SourceInvestProduct> object is not present, it implies all funds which are available to the product via <InvestProductInfo> are available for the rider or arrangement. If there are fewer funds applicable (e.g. 8 out of 10 funds are applicable), then all eight would have to be explicitly stated using <SourceInvestProduct>. If multiple alternate rates are available for SourceInvestProduct, the object repeats for each allowable RateVariationKey for that investment. <CarrierCode> String Lists the carrier code from <InvestProduct> to define the

managing firm. <ProductCode>

String Indicates a <ProductCode> from <InvestProduct>, which can be selected as a destination fund with this feature option. This <CarrierCode> <ProductCode> combination must be present in <InvestProduct> and <InvestProductInfo>.

* <MinAmt> 04-1.01.AN246 String Minimum amount.

* <MaxAmt> 04-1.01.AN246 String Maximum amount. * <MinPct> 04-1.01.246 Percentage Minimum percentage.

* <MaxPct> 04-1.01.246 Percentage Maximum percentage.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 101 Chapter Four – Descriptions & Definitions <SurenderChargeSchedule>


<SurrenderChargeSchedule> Object

The SurrenderChargeSchedule object describes surrender charge information for the purposes of disclosure at order entry and distributor forms. It is not intended to describe complex surrender charge schedules for the sake of post-issue processing. Attributes: SurrenderChargeSchedule id= “ ”


<SurrenderChargeScheduleKey> String See the description at the beginning of this chapter for usage & meaning.

<SurrenderChargeScheduleSysKey>


<SurrenderChargeType> LookUp Table String= ‘Surrender Charge Type’

LookUp Table Code= ‘OLI_LU_SURRCHGTYPE’

Type Code Describes the type of surrender charge. Type Code Translation 1 = Standard based on Contract Date 2 = Rolling based on Deposit Date of each payment

<ChargeBasedOn> LookUp Table String= ‘Rate Based On’

LookUp Table Code= ‘OLI_LU_RATEBASEDON’

TypeCode Further describes what rate is based upon. Type Code Translation 1 = Premium 2 = Account Value Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 102 Chapter Five – Transmitting PPfA <Common Elements>

CHAPTER 5 – TRANSMITTING PPFA

Common Elements

Every object above also has an extension mechanism allowing you to add additional, proprietary fields of information (elements). Since these proprietary values are only known to the sender they must be independently communicated to the receiver(s) for them to recognize these fields. Generally, extensions should be submitted to NAVA or ACORD for addition to the standard, however these mechanisms allow for immediate, proprietary extensions when necessary. <KeyedValue> <KeyName> <VendorCode> <KeyValue>

This mechanism provides for the addition of new elements to an object, without ACORD or NAVA approval. KeyName is the name of your new element (e.g. EyeColor) VendorCode is your unique ACORD assigned code so recipients can see who created this new element in this XML stream. KeyValue is the value of your new element (e.g. Blue)

<OlifEExtension> This mechanism allows you to add virtually whatever you want between the start and end tags (<OLifEExtension>). The schema ignores any and all text between the tags. Generally you would want to put well-formed XML inside this tag,

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 103 Chapter Six – XTbML Spec. for a PPfA

CHAPTER 6 – XTBML SPECIFICATION FOR A PRODUCT PROFILE FOR ANNUITY

The ACORD XMLife model provides two standard data formats for table type data - Table Manager and XTbML. It was decided by the Committee that the preferred standard for table type data will be XTbML. This section will give the user an object hierarchy, detailed element descriptions with type codes and a standard usage sample detailing how XTbML will be used. Within the construct of the Product Profile for Annuities, the use of XTbML has been approved for the purpose of communication of Commission Rates and Interest Rates. Additional information can be found in the ACORD XTbML Implementation Guide. The general structure and hierarchy of the XTbML object elements is as follows with detailed descriptions and type code definitions following this section, listed in alphabetical order: <TXLife>

<TXLifeRequest> <OLife>

<XTbML> <ContentClassification> <Table>

<MetaData> <KeyDef> <AxisDef>

<Value> <Key> <Axis> <Y>

Guiding Principles: • ACORD requires that all KeyDef objects are defined first, then AxisDef objects. • Within 2.9, the order of the KeyDef and AxisDef is critical. Values provided within the Values sections of

axises and keys are assumed to be in the same order in which KeyDef and AxisDef is defined within the MetaData. Within 2.10, an IDRef is available on Key (KeyDefId) and Axis (AxisDefId) to not force this, but, the working group suggests that this order still be followed.

• Standard usage for PPfA does not utilize the JurisdictionCC element on Metadata. If rates vary by jurisdiction, a different table should be constructed.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 104 Chapter Six – XTbML Spec. for a PPfA <XTbML>

XTbML Element Name Type Description

<XTbML> Object

The aggregates for XTbML ACORD tabular standard. It is a mechanism for describing tables of information (such as rates, commissions, etc.)

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 105 Chapter Six – XTbML Spec. for a PPfA <Table>


<Table> Object

A high level container for tabular data. A collection of rate records organized by different banding elements. Such items as age, sex, substandard class, duration, etc may band rates. This is used to supply the rate records in a tabular format for rates associated with aspects of calculations. They may include items such as: mortality tables, commission rates, premium rates, tabular cash values, net single premium rates, etc. Contains information about the content of the table data including name, supplier, and identification.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 106 Chapter Six – XTbML Spec. for a PPfA <AxisDef>


<Axis> Object

Identifies a dimension in the table values as defined in the AxisDef. Attribute: <T>

Integer A sequence defined by whatever the Axis is intended to order the V values. This value must be numeric.

<DT> Date Date used to identify the effective date value of an Axis, Key or Value row.

<FN> ??? <AxisDefID> ??? <Y> Integer Dimension or value. Commission rates are expressed as a

decimal/percentage. That is, 3% is represented as 3.0..



<AxisDef> Object

AxisDef contains the definition of dimensions that have ordered ranges such as numeric sequential values, amounts and dates.

<ScaleType> LookUp Table String=

‘Scale Type’

LookUp Table Code= ‘OLI_LU_SCALETYPE’

TypeCode Indicates the type of information contained in this particular dimension. Type Code Translation 1 = Dates – Fully qualified 2 = Ordinal Date –units of time i.e. years, months, days 3 = Age 4 = Service 5 = Currency

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<ScaleSubType> LookUp Table String= ‘Scale Sub Type’

LookUp Table Code= ‘OLI_LU_SCALESUBTYPE’

TypeCode Further details of the semantic concept represented by the axis.

Type Code Translation 1 = Issue Age 2 = Attained Age 3 = Entry Age 4 = Decrement Age 5 = Payment Age 6 = Age Nearest 7 = Age Next 8 = Age Last 9 = Age Retirement * 10 = Premium * 11 = Face Amount * 12 = Contract Value * 13 = Contract/Issue Date * 14 = Premium Effective Date


<AxisName> String Short description of the axis. <DimensionSequence> String Used to control the ordering of AxisDefs and KeyDefs.

Sequencing should start with "1". <MinScaleValue> Integer Minimum value for the dimension of the table.


XTbML Element Name Type Description <MaxScaleValue> Integer Maximum value for the dimension of the table. <MinScaleDate> Minimum date for the dimension of the table. <MaxScaleDate> Maximum date for the dimension of the table. <Increment> Integer Identifies the increment used between each of the values in

this dimension. <Mode>


LookUp Table Code= ‘OLI_LU_PAYMODE

TypeCode Defines the modal representation of the values in the table.

Type Code Translation 1 = Annually 2 = Semi-Annually (twice a year) 3 = Quarterly 4 = Monthly 5 = Semi-Monthly (twice a month) 6 = Weekly 7 = Bi-Weekly (every two weeks) 8 = Daily 100 = Any Paymode is Allowed


<Continuous> Boolean 0 = False 1 = True

Defines the meaning of intermediate values of the table. If ‘True’, then the value of the previous row should be carried forward. If ‘False’, then the value of missing data is undefined.

<Banding Type>

LookUp Table String= ‘Banding Type’

LookUp Table Code= ‘OLI_LU_BANDTYPE’

TypeCode Indicates the type of banding for rates.

Type Code Translation

1 = No Bands Specified 2 = Banded with a Simple Break, where the rate is selected based on the premium and the rates applies to the entire premium. E.g. 5% if premium is less than $100,000; 4% if premium is greater than $100,000

3 = Banded with a Marginal Break. E.g. 5% on premium up to $100,000; 4% on premium in excess of $100,000

<AgeCalculationMethod> LookUp Table String= ‘Age Calculation Method’

TypeCode Indicates the algorithm used to determine the contract entity upon which commission breakpoints are determined. Type Code Translation 2 = Age Last Birthday


XTbML Element Name Type Description LookUp Table Code= ‘OLI_LU_AGECALCMETH’

3 = Age Nearest in days Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<TimingOption> String Two options – beginning of period, end of period. <EnumeratedValue> String When used under AxisDef, lists the values expected in the

related XTbML Table.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 110 Chapter Six – XTbML Spec. for a PPfA <ContentClassification>


<ContentClassification> Object

Contains information about the content of the table data including name, supplier, and identification. <ContentClassificationKey> String Unique Key used only by a sending system if it wishes to

pass to a downstream system a key/pointer to an internal record. Generally useful only for Request/Response transaction method. The response must return the Key value without change in its response.

Not used in Transmittal Transaction. <TableIdentity> String Unique Identifier for the table. This along with the

ProviderDomain creates a persistent unique key for the table.

<ProviderDomain> String The domain name of the provider. This along with the TableIdentity creates a persistent unique key for the table.

<ProviderName> String Name of the provider of the table. <TableURL> String Location where the values of the table are published. <TableReference> String Reference to the published document, which contains the

table. <ContentType> LookUp Table String= ‘Content Type’

LookUp Table Code= ‘OLI_LU_CONTENTTYPE’

TypeCode Identifies the type of information in the table. Type Code Translation 53 = Commission Rates Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<TableName> String Name as defined by the table supplier. <TableDescription> String Freeform description of the contents of the table or sub-table

being included. <EffDate> Date Date that aggregate is initially effective. <Comment> String Miscellaneous information regarding the information that is

within the file itself.


© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 111 Chapter Six – XTbML Spec. for a PPfA <Key>


<Key> Object

Identifies a dimension in the table values as defined in the KeyDef. <Y> Integer Dimension or value.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 112 Chapter Six – XTbML Spec. for a PPfA <KeyDef>


<KeyDef> Object

Contains the definition of non-ordered dimensions of a table such as type codes, strings and codes. <KeyType> LookUp Table String= ‘Key Type’ LookUp TableCode= ‘OLI_LU_KEYTYPE’

TypeCode The type of key defined Type Code Translation 1 = Key is a String 2 = Key is a Type Code

<KeyCodeType> (04-1.01.03.09)

TypeCode Lookup Variants

The typecode set from which the Key's EnumeratedTypecodeValues will be drawn.

<KeySubType> LookUp Table String= ‘Key Sub Type’ LookUp TableCode= ‘OLI_LU_KEYSUBTYPE’

TypeCode The place in the model from which the values in EnumeratedStringValues are drawn. Type Code Translation

20 = Interest Rate Class

21 = Product Code:

22 = FeatureOptProduct

23 = InvestProduct

24 = InvestProductInfo

25 = PolicyProduct

26 = PolicyProductInfo


<KeySubClassType> LookUp Table String= ‘Key Sub Class Type’ LookUp TableCode= ‘OLI_LU_KEYSUBCLASSTYPE’

TypeCode KeySubClassType is used to refine the KeySubType. Specifically, to define the element to be used to access the table when multiple elements may be used. Type Code Translation

1 = FeatureCode

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 113 Chapter Six – XTbML Spec. for a PPfA <KeyDef>

XTbML Element Name Type Description <KeySubClass> String Provides the actual FeatureCode value. ??? <KeyName> String The name of the custom property. <DimensionSequence> String Used to control the ordering of AxisDefs and KeyDefs.

Sequencing should start with "1". <EnumeratedValue> Integer An inclusive collection of integer values which lists any key

which may be used within Tables. For example, to indicate Rate Types of 1 (Fixed) and 2 (Variable) as values which may be used as dimensions: ?? need to validate ?? < EnumeratedValue t="1"> < EnumeratedValue t="2">

<EmumeratedTypeCodeValue> Enumerated

An inclusive collection of type code values which lists any key which may be used within Tables. For example, to indicate the FeatureOptProduct FeatureCodes which may be used as dimensions: < EnumeratedTypeCodeValue t="DB"> < EnumeratedTypeCodeValue t="EEB">

<EnumeratedStringValue> String An inclusive collection of string values which lists any key which may be used within Tables. For example, to indicate Interest Rate Classes A and B as dimensions which may be used: < EnumeratedStringValue t="A"> < EnumeratedStringValue t="B">

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 114 Chapter Six – XTbML Spec. for a PPfA <MetaData>


<MetaData> Object

Contains information on how to interpret the values in the table. <ScalingFactor> Integer Used to identify the scale of the numbers used in the table.

You must multiply each value by this number. This is stated as an integer representing the power of 10. It can be positive or negative. Example: ‘3’ would indicate the numbers are stated in thousands. If scaling does not apply, 0 may be sent to indicate no scaling.

<DataType> LookUp Table String= ‘Data Type’

LookUp Table Code= ‘OLI_LU_DATATYPE’

TypeCode Represents the type of data presented in the table. Type Code Translation 0 = Boolean 1 = Integer 2 = Long 3 = Short 4 = Double 5 = Currency 6 = Decimal 7 = Date 8 = String Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<CurrencyTypeCode> LookUp Table String= ‘Currency Type Code’

LookUp Table Code= ‘OLI_LU_CURRENCYTYPE’

TypeCode Identifies the type of currency accepted for investment into the fund. Type Code Translation 124 = CAD (Canadian Dollar) 840 = USD (United States Dollar) Note: This is a partial list from the current ACORD pec. Please see current spec. for additional codes.

<Nation> LookUp Table String= ‘Nation’ LookUp Table Code= ‘OLI_LU_NATION’

TypeCode Indicates the nation in which the product will be sold. Type Code Translation 1 = United States of America 2 = Canada Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<JurisdictionCC> TypeCode The jurisdiction(s) to which rates apply. <TableDescription> String Freeform description of the contents of the table or sub-table

being included.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 115 Chapter Six – XTbML Spec. for a PPfA <Values>


<Values> Object

Contains information about the content of the table data including name, supplier and identification. <ContentClassificationKey> String Unique Key used only by a sending system if it wishes to

pass to a downstream system a key/pointer to an internal record. Generally useful only for Request/Response transaction method. The response must return the Key value without change in its response.

Not used in Transmittal Transaction. <TableIdentity> String Unique Identifier for the table. This along with the

ProviderDomain creates a persistent unique key for the table.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 116 Chapter Seven – Transmitting PPfA

CHAPTER 7 - TRANSMITTING/SENDING A PRODUCT PROFILE FOR ANNUITY

The ACORD XMLife model provides two basic techniques for sending information between trading partners. The first, most common, technique is a Request/Response method whereby a requester sends a “request” transaction to a provider who receives, process and replies back with a “response” transaction – typically containing the requested data or a result if an action was requested. For the Product Profile for Annuity method NAVA recommends the second method that is a “Transmittal”. A Transmittal is a one-way sending of data (i.e. not request/response) from a provider to a recipient. This is a simpler method. A Transmittal contains two basic parts: a content section and an envelope section. The content is what has been discussed thus far, all the details beginning at the <OLifE> level object element on down, including <ProductProfile>, <AnnuityProfile>, 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 product profile- that is in the content section beginning with the <OLifE> object. Following are all the expected fields that you should value and include in a well-formed and valid ACORD TXLife Transmittal. There are many different types of ACORD transactions. The one that is of interest in this context is the Product Inquiry Transaction, transaction type 1201. The basic construct of a full TXLife Transmittal is: <TXLife> <UserAuthRequest> <TXLifeRequest> <OLifE>

[all the product profile details] Following are descriptions of each element.

TX Life Wrapper Descriptions <UserAuthRequest> Object This object contains the information related to the user <TXLifeRequest> Object This object contains the information related to the message/transaction

itself

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 117 Chapter Seven – Transmitting PPfA <UserAuthRequest>


<UserAuthRequest> Object

This object defines the transaction/message information about the user and the system that is sending the message <UserLoginName> String User Login name into receiving system, if applicable.

Conditional part of key - either UserLoginName and UserPswd or UserSessionKey constitutes a valid login.

<UserDate> Date Date that User makes request. <UserPswd> String User Password, if applicable. Conditional part of key -

either UserLoginName and UserPswd or UserSessionKey constitutes a valid login.

<UserSessionKey> Attribute: Persistence of Key



String Attribute

Authentication key, issued previously based on password. Conditional part of key - either UserLoginName and UserPswd or UserSessionKey constitutes a valid login. Generally useful only for Request/Response transaction method. Default for the length of time the key persists is ‘1’, meaning only for the length of the session. A key is made permanent by sending the persist element of ‘2’. Type Code Translation 1 = Value provided is persistent for the duration of this session only 2 = Permanent or Value Provided is Persistent Indefinitely (a permanent key is assigned by the owner of the data.)

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 118 Chapter Seven – Transmitting PPfA <VendorApp>


<VendorApp> Object

This object identifies the application creating this transaction of the creator of the Product Profile. <VendorName> String Name of submitting organization. Sender/creator of

Product Profile name i.e. Carrier. <AppName> String Name of system creating product profile (source system).

Name of application that uses the object. If it applies to more than one application, separate the application names with commas. This is useful in the case where the OLifE server is provided as a part of another application and is not a stand-alone server. Read Only.

<AppVer> String Client application version. Version of system creating product profile.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 119 Chapter Seven – Transmitting PPfA <ProxyVendor>


<ProxyVendor> Object

This object identifies the application creating this transaction of the third party sending the Product Profile. <ProxyVendor>

String Name of third party, if there is one, sending or transmitting this message.

<VendorName

String Sender/creator of Product profile name (third party name).

<AppName> String Name of system creating product profile (source system). Name of application that uses the object. If it applies to more than one application, separate the application names with commas. This is useful in the case where the OLifE server is provided as a part of another application and is not a stand-alone server. Read Only.

<AppVer> String Version of system creating product profile.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 120 Chapter Seven – Transmitting PPfA <TxLifeRequest>


<TXLifeRequest> Object

This object defines the information about this particular message/transaction. Contains elements needed to process a request. <TransRefGUID> String Uniquely identifies this transaction. Use a 32-bit GUID

(Globally Unique Identifier). Universally unique identifier by Client application. This is provided by the application at time of request. Then for request/response, this identifier is echoed back in the response to allow the client application to match the response with the request.

<TransType>

LookUp Table String= ‘Transaction Type’ LookUp Table Code= ‘OLI_LU_TRANS_TYPE_CODES’

Typecode Transaction type uniquely indicates that this is an ACORD Policy Product Inquiry transaction to the receiving system. Always “1201” for the Product Profile Transmittal. Type Code Translation 201 = Policy Product Request 1201 = Policy Product Transmittal Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<TransSubType> LookUp Table String= ‘Transaction Sub Type’ LookUp Table Code= ‘OLI_LU_TRANS_SUBTYPE_CODES’

Typecode Not currently used within the PPfA. This element defines this Policy Product Inquiry as a Policy Product Inquiry for an Annuity. (+)Codes to be defined by ACORD. Could setup unique subtypes for varying levels of detail. For example – 101= Inf for well formed application, 102= complete product profile (including marketing info), etc.

<TransExeDate> Date Date and time when this file or feed 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:00-05:00. You may use TransmitDate to indicate the order or sequence number (i.e. order received) for processing transactions that may have come in a batch/group. ACORD database defines as the date the file was transmitted on a Request or the server date the transaction was processed on a Response.

<TransExeTime> Time Time when this file or feed was created.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 121 Chapter Seven – Transmitting PPfA <TxLifeRequest>

XML Element Name Type Description ACORD database defines as the date the file was transmitted on a Request or the server date the transaction was processed on a Response.

<TransMode> LookUp Table String= ‘Transaction Mode’ LookUp Table Code= ‘OLI_LU_TRANS_MODE_CODES’

TypeCode Not currently used within the PPfA. Used by Sender in Request/Response. Not used for initial implementation which is Transmittal only. Example: Type Code Translation 2 = Original Request Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes.

<NoResponseOk> Boolean 1 = True

Indicates if a response is desired or necessary. For a transmittal, always set to ‘1’ for True.

<TestIndicator> Boolean 0 = False 1 = True

Indicates whether this is a test or production file/stream. If Test then set to ‘1’. If Production, set to ‘2’. Value Range: 0-1

A standard example of a TXLife Transmittal wrapper would look like: <TXLife> <UserAuthRequest> <UserLoginName/> <CryptType/> <Pswd/> <CryptPswd/> <UserSessionKey/> <VendorApp> <VendorName VendorCode="##">Lincoln National Life</VendorName> <AppName>Annuity Profile App Generator</AppName> <AppVer>1.24c</AppVer> </VendorApp> </UserAuthRequest> <TXLifeRequest> <TransRefGUID>938749384753ea765c87-876432</TransRefGUID> <TransType tc="1201">Product Inquiry Transmittal</TransType> <TransExeDate>2002-05-31T13:47:53-05:00</TransExeDate> <TransExeTime>13:20:10</TransExeTime> <TransMode> <NoResponseOK tc="1">TRUE</NoResponseOK> <TestIndicator> <OLifE> <!—BEGIN PRODUCT PROFILE DATA --> …

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 122 Diagram 1A

APPENDIX A - PRODUCT PROFILE FOR ANNUITY OBJECT DIAGRAMS It should be noted that there is an indication of ‘*’ where an object or code has been added to 2.10 schema and is therefore not in the public schema. An indication of ‘(+)’ means that a Maintenance Request has been submitted for the item.

Diagram IA: TXLife Wrapper

TXLife PolicyProduct Transmittal TransType

Tc=1201

TXLife VendorApp [0.1]

VendorName[1] AppName[0..1] AppVer[0..1]

UserAuthRequest [0.1]

UserLoginName[0..1] UserDate[1] UserTime[1] CryptType[0..1] Pswd[0..1] CryptPswd[0..1] UserSessionKey[0..1]

OLifE [1]

TXLifeRequest [1]

(SEE NEXT DIAGRAM)

ProxyVendor [0.*]

VendorName[1] AppName[0..1] AppVer[0..1]

General ACORD XMLifeNaming Conventions: Id = XML type"XSL:ID", unique XML identifier, valid only in XML stream/doc ____ID = XML type "XSL:IDREF", "foreign key" to XML object "id" ____IDs = XML type "XSL:IDREFs", "foreign keys" to XML object "id" ____Type = ACORD type code (attribute "tc") ____CC = ACORD type code collection ____Ind = Boolean (Yes/No or 1/10) indicator ____Code = Permanent unique object identifier ____Key = Temporary Session Key, valid for length of session ____Amt = Amount (Double) ____Date = Date (Date) ____BP = Basis Points; 1/100 or .01% (Integer) Note: There are exceptions to these general rules!

(SEE NEXT DIAGRAM)

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 129 Diagram VII

Diagram VII: XTbML – Commission Profile for Annuity

KeyedValues ContentClassificationTableIdentity : StringTableIdentity : StringVendorName : StringContentType : Integer

0..n0..n

KeyVt : Integerdt : Date

0..n0..n

AxisV t : Integerdt : Date 0..n0..n

XTbML

1 1

Values

0..n0..n0..n0..n

Enumerated Values

EnumeratedTypeCodeValues

Table

0..n 0..n

11

Jurisdiction onCC

KeyDef KeyType : IntegerKeyName : String

0..n0..n0..n0..n

AxisDefScaleType : IntegerScaleSubType : IntegerAxisName : StringMinScaleValue : DoubleMaxScaleValue : DoubleIncrement : DoubleMode : IntegerContinuous : Boolean

MetaData

TableSubDescription : StringScalingFactor : IntegerDataType : IntegerCurrencyCode : IntegerNation : Integer Jurisdiction

1 1

0..n0..n0..n0..n

0..n0..n

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 130 Appendix B

APPENDIX B - TERMINOLOGY

Element ID An Element ID is an internal system pointer, which uniquely identifies an element within the computer system. This is not readable and is not persistent for external systems. Therefore, it should not be stored or used by external systems for identification. In XML, this is implemented via attributes for “ID” and “IDRef” and is used to tie together aggregates at the same level. For instance, a PolicyProduct and an InvestProduct are at the same level. Since you might have several of these in a stream, you can identify which one you are referencing by using the ID. Notice below, there are two InvestProducts. However, under PolicyProduct we need to reference the second InvestProduct. We do this through an Element ID. <PolicyProduct ID=”Product_1”> {elements} <InvestProductInfo ProductID=”Invest_2”> </InvestProductInfo> </PolicyProduct > <InvestProduct ID=”Invest_1> {elements} </InvestProduct> <InvestProduct ID=”Invest_2> {elements} </InvestProduct> Element Key An Element Key is a persistent identifier that can be used to reference an item across transactions. This is necessary in situations where you need to ask for something for which you do not know the code. This is also used on items in the model, which do not have a code related field. For instance, if I was to ask for an annuity with certain features but I did not know the Product Code, I could identify what I am asking for with a key. When I receive the response, it would have a Product Code associated with it, but I might not be able to immediately recognize it. Instead, what I would do is look for the key that matches the key I used in my request.


Request Please send me an Annuity Product of type code “1”. Notice, I do not know the ProductCode. <PolicyProduct ID=”Product_1”> <PolicyProductKey>767</PolicyProductKey> <AnnuityProduct> <AnnuityProductType tc=”1”></AnnuityProductType> </AnnuityProduct> </PolicyProduct>


Response Here is your Annuity Product of type code “1”. By the way, the Product Code is “SP01”. You can find it by looking for the PolicyProductKey that matches the key you sent. <PolicyProduct ID=”Product_1”> <PolicyProductKey>767</PolicyProductKey> <PolicyCode>SP01</ProductCode> <AnnuityProduct> <AnnuityProductType tc=”1”></AnnuityProductType> </AnnuityProduct> </PolicyProduct> Element Code An Element Code is the identifier that is both readable and persistent to all interested parties. This code is generally identified by the administration system, which manages the item in question. For instance, in most carriers, they identify a code for each annuity that used as the short identifier in the administration system. This is persistent and never changes. Anyone can reference it. See example under Element Key. Objects / Aggregates / High Level / Low Level Objects or Aggregates are items which themselves do not have a value, but rather contain subitems often referred to as Elements or Properties. For instance, below PolicyProduct and AnnuityProduct are objects or aggregates. <PolicyProduct ID=”Product_1”> <PolicyProductKey>767</PolicyProductKey> <PolicyCode>SP01</ProductCode> <AnnuityProduct> <AnnuityProductType tc=”1”></AnnuityProductType> </AnnuityProduct> </PolicyProduct> We often refer to an Object or Aggregate as either High Level or Low Level. This is done to identify if an object can exist by itself or if it must reside under another object. High Level objects can exist stand alone underneath the “OLifE” tag. Low Level objects cannot. For instance, in the example above, PolicyProduct is a High Level object. AnnuityProduct is a Low Level object.


Elements / Properties Elements or Properties are individual elements that contain data. The data has a data type, format, and value. They are contained in Objects or Aggregates. For instance, in the example below, PolicyProduct and AnnuityProduct are Objects or Aggregates. The rest of the tags are Elements or Properties. <PolicyProduct ID=”Product_1”> <PolicyProductKey>767</PolicyProductKey> <PolicyCode>SP01</ProductCode> <AnnuityProduct> <AnnuityProductType tc=”1”></AnnuityProductType> </AnnuityProduct> </PolicyProduct> Schema A schema is a standard defined by the W3C, which is used to restrict what can be contained in an XML Document. It can be compared to a database diagram, a COBOL copybook, or a record layout. It does not contain data. When a document containing data is created, it must adhere to the restrictions set forth by the schema. Example restrictions are things like what elements can exist and where. DTD A DTD performs the same task as a schema (see associated definition). This was a format defined prior to schemas by vendors and not the W3C. It also does not allow for as in depth validation as a schema. Keyed Values Keyed Values allow you to define additional data elements in the XML Data Document without violating the Schema (see associated definition). This is more structured than OLifEExtensions (see associated definition). For example if you have a need to define a Pet’s Age in the XML Data Document, but there is no element for Pet’s Age, you can add this via a Keyed Value. They are structured as defined below. <KeyedValue tc=”1”> <KeyName>PetsAge</KeyName> <VendorCode>X</VendorCode> <KeyValue>3</KeyValue> <KeyedValue> There are a couple of important notes. First, the tc attribute on KeyedValue identifies what the type of data is in KeyValue element such as string, date, number, etc. Second, it is important to note that the VendorCode is necessary to interpret PetsAge. For instance, if we have two vendors who both identify Pet’s Age through Keyed Values, one vendor may represent this in human years and the other in dog’s years. You would need to know the vendor to know if the pet is “3” years old or “21” years old.


OLifEExtension OLifEExtensions allow you to define additional data elements and objects in the XML Data Document without violating the Schema (see associated definition). This is more free form than Keyed Values (see associated definition). For instance, within an OLifEExtension the only requirement is that you have a valid XML structure. None of the objects or elements needs to be defined by the Schema in advance. <OLifEExtension VendorCode=”X” ExtensionCode=”PetInfo”> <Pet> <PetName>Rover</PetName> <PetType Species=”Dog”>Dalmatian</PetType> <PetsAge>3</PetAge> </Pet> <FavoriteKennel> <KennelName>Happy Hounds</KennelName> </FavoriteKennel> </OLifEExtension> There are a couple of important notes. First, notice the structure does not have to be restricted to a single object. In the example above, there two objects, Pet and FavoriteKennel. Second, it is important to note that the VendorCode and ExtensionCode are necessary to parse and interpret the extension. If you did not know the vendor, then you would not understand anything related to underlying structure. Since vendors could distribute more than one extension, then you also need to identify the specific structure that is contained in this one OLifEExtension. Type Code A Type Code is used when the values for a field are limited to a list of known values. For instance, when speak of a person’s gender; we know that they are male or female. Therefore, we can restrict the values to these two. This allows for a programmer to look at the codes to identify the values and then process them accordingly. They do not have to look for “Male”, “Man”, or some other representation. <Gender tc=”1”>Male</Gender> There are a few important notes here. First, the tc attribute is used to specify a numeric identifier for the value. The text is used for the visual representation and must be consistent with the numeric identifier. Second, the list of valid values (numeric and its meaning) is maintained by ACORD. In order to add new values, you must contact ACORD. You may also request for private values that will be assigned to you but not disclosed in the public standard. In order for additions to be adopted in the public standard, they must be accepted by a 2/3-majority vote at the ACORD Semi-Annual Subcommittee meeting.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 135 Appendix C

APPENDIX C

Ittai Kan Senior Director, Product Development Finetre Corporation [email protected]

Product Profile for Annuities

In Service Financial Transactions

Introduction The Product Profile for Annuities (PPfA) was developed primarily to support product specific order-entry requirements for new business. The application process has all necessary contract entity, qualified plan, account designation, and customer selection information available to it. The PPfA also supports product specific requirements for subsequent premiums, although this capability is less well developed. The Subsequent Premium transaction is an In Service transaction, and there are numerous issues regarding the usage of the PPfA depending on what information about the in service contract is available. In addition, there is information that was intended to be applied to applications that may be inaccurate if extended to Subsequent Premium transaction. This document only addresses financial transactions. It does not address administrative transactions such as address change or beneficiary change. Any data required for the application of the transaction rules as defined on the product side of the ACORD model must be transmittable through a Holding inquiry. Requirements

Timing Rules Out of Scope A product may have timing restrictions for operational reasons involving feed and processing times, or for fund volatility reasons (so that fund managers need not maintain a large cash position), or to prevent market timing. These restrictions may be fund dependant or not. We feel that Timing Rules are not appropriate to the PPfA because they are not so much product rules as processing rules. In addition, regulatory authorities may require different cutoffs depending on process.


Rules Must Be Enforceable Using Position & Product Data Only In order for a vendor or distributor or third party to be able to use the PPfA for In Service transactions, the data to support the rules must be available to the transaction-entry system. Position data is commonly available. Financial transaction history is much less available, and the storage requirement for complete transaction history for large numbers of aged contracts is prohibitive. Processing requirements for a transaction-entry system should be as light as possible since it is unreasonable to expect transaction-entry systems to duplicate the immense processing power of established administrative systems. In addition, duplication of processing capability between an autonomous transaction-entry system and full-blown administrative systems is wasteful. Querying a transaction history database to find cumulative turnover for a contract is very resource intensive. Therefore, we require that the PPfA combined with position data should suffice for enforcing In Service transaction rules. The position feed may be enhanced in order to supply the requisite data.

Features Intrinsic to an In Service Transaction More than one feature may be intrinsic to an In Service transaction. For instance, depending on a carrier’s administrative systems, a Subsequent Premium transaction may actually be a Subsequent Premium transaction coupled with a change of Standing Allocation feature. This need can be accommodated by the creation of new ACORD transactions. Also, there may be several Features of the same arrangement or rider type. For instance, there might be two Systematic Withdrawal Features, one for the application and one for an In Service transaction. This need can not be accommodated by the creation of new ACORD transactions.

Extrinsic Features Impacting an In Service Transaction An In Service transaction may be impacted by several extrinsic Features. For instance, the funds available to a Standing Allocation transaction may be restricted if a particular GMAB rider is active. For the only existing In Service transaction in the PPfA (Subsequent Premium transaction), the current ACORD model would seem to make every Feature in the PPfA for that product potentially impacting the Subsequent Premium transaction. For instance, if a fund is not available to any.

Impact of Issue Date on an In Service Transaction The Issue Date may alter the rules for an In Service transaction in the following ways.

• Funds Availability – Funds may be restricted for new issues.

• Transaction Availability – Features may only be available to contracts with issue dates in certain ranges (due to contract provisions at issue).


• Transaction Rules – Transfer or dump-in provisions may depend on issue date.

Impact of Sales Date of a Feature Intrinsic to an In Service Transaction The Sale Date for a Feature intrinsic to an In Service transaction may impact that transaction in the following ways.

• Funds Availability – Funds may be restricted depending on the Sales Date for an intrinsic rider.

• Transaction Rules – Rider dump-in provisions may depend on Sales Date for that rider.

Impact of Sales Date of a Feature Extrinsic to an In Service Transaction

The Sale Date for a Feature extrinsic to an In Service transaction may impact that transaction in the following ways.

• Funds Availability – Funds may be restricted depending on the Sales Date for an extrinsic rider.

• Transaction Rules – Transfer or dump-in provisions may depend on Sales Date for an extrinsic rider.

Status Dependent Availability of Transactions

Transaction rules may depend on contract status. Examples include: • Transaction Availability – Subsequent Premium is typically not permitted during

the freelook period.

• Transaction Rules – A common provision for a variable annuity is that 12 transfers are permitted per year while the contract is in deferral and 4 transfers are permitted per year after the contract is annuitized.

Transaction Count and Amount Limits

Transactions have various count and amount limits. Some are to prevent excessive trading and some are to limit account value volatility. The determinants of these restrictions have two different sources.

Position Dependent Limits • Fund position limits – No more than 20% may be allocated to the Special

Opportunities Fund • Fund position restrictions based on riders and rider effective dates – If the

Special Return Rider was selected before 1/1/2002, then allocations are unrestricted. If the Special Return Rider was selected after 1/1/2002, then the position must be no more than 50% in equity funds.

• Cumulative premium maximums – The cumulative premium may be limited to $500,000 without prior home office approval


Transaction History Dependent Limits Fund roundtrips – Movements into and out of a fund are restricted once per annum.

• Turnover – Total cumulative buy/sell activity as a percentage of account value • Number of transactions of a given type – Twelve transfers are permitted per

annum Feature Allocation and Amount Rules

The Features intrinsic to an In Service transaction may have an associated allocation. The source and/or destination transfer amounts may be limited in the ways described in an earlier white paper entitled Allocations and Amounts that was submitted by Finetre in support of MR: 04-1.01.AN246. This functionality is now in 2.11 at the Feature Option level. Proposed Solution – Product Side

Financial Transaction Product Consider the requirements above with the exception of the Transaction Count and Amount Limits (the Feature Allocation and Amount Rules are already supported by the AmountProduct aggregate introduced in 2.11) which we will discuss later. Some structure must be added in order to express, for any dates and contract status, the relationship of the financial transaction to any relevant intrinsic and extrinsic Features as of any date. In principle, this structure could reside on FeatureProduct, FeatureOptProduct, or AnnuityProduct. The problem with placing this structure on the intrinsic FeatureProduct or FeatureOptProduct, is that there could be many Features or Feature Options that are potentially many of these for a given transaction (i.e. the application transaction), and this would result in the repetition of lots of information about extrinsic Features. Therefore it is proposed that a FinancialTransactionProduct aggregate is proposed to be added to AnnuityProduct. This aggregate in combination with the existing conflict, requisite, allocation, and amount structures on FeatureOptProduct satisfies all the requirements except for the Transaction Count and Amount Limits. <FinancialTransactionProduct>

<FinActivityType> Existing - uses OLI_LU_FINACTTYPE <PolicyStatusCC> New – collection of statuses for which the aggregate applies

<PolicyStatus> Existing – uses OLI_LU_POLSTAT <TransactionEffectiveDate> First date for which this aggregate applies to the transaction type <TransactionExpirationDate> Last date for which this aggregate applies to the transaction type <IssueEffectiveDate> First contract issue date for which this aggregate applies to the transaction type <IssueExpirationDate> Last contract issue date for which this aggregate applies to the transaction type <FeatureProductInfo> Provides information about Features intrinsic and extrinsic to this transaction type

<FeatureRoleType> Intrinsic | Extrinsic <FeatureCode> Foreign key to FeatureProduct.FeatureCode <SaleEffectiveDate> If FeatureRoleType is extrinsic, then first date on which this Feature was

purchased or effective. Do not use if the FeatureRoleType is intrinsic, use the TransactionEffectiveDate instead.


<SaleExpirationDare> If FeatureRoleType is extrinsic, then last date on which this Feature was purchased or effective. Do not use if the FeatureRoleType is intrinsic, use the TransactionEffectiveDate instead.

Uniqueness – For every FinancialTransactionProduct.(FinActivityType, Status) the TransactionEffective/Expiration and IssueEffective/Expiration date ranges must not both overlap (that is, there must be no single date that is in both ranges for two aggregates). Also, within any one FinancialTransactionProduct aggregate, the repeating aggregate FeatureProductInfo with the same FeatureCode must not have SaleEffective/Expiration date ranges that overlap.

Transaction Count and Amount Limits The cumulative premium Position Dependent Limit can be supported by the addition of the following property to Ownership.

• MaxCumPremiumAmt – This amount would be the maximum amount of premium that could be put into the contract over its life. This is the natural place add this since it would apply to Autopay programs as well.

The other Position Dependent Limits can be supported by the addition of one new arrangement types for use on the product side. These extrinsic Feature Products would be linked to the intrinsic Feature Product via FeatureOptRequisite.

• Position Limitation Arrangement – This arrangement would describe the overall position restrictions using MinAmt, MaxAmt, MinPct, and MaxPct on SourceInvestProduct and DestInvestProduct.

As discussed in the Rules Must Be Enforceable Using Position & Product Data Only requirement, Transaction History Dependent Limits must be supported through the Holding side. For any particular contract, the Fund roundtrips and Turnover restrictions when applied to a particular date boil down to a restriction regarding either purchase or sales of funds. This can be supported by the addition of two new arrangement types for use on the holding side. These would be returned in the position feed and would indicate any purchase or sale restrictions that apply to the particular contract.

• Buy Limitation Arrangement – This arrangement would describe the overall fund purchase restrictions using MinAmt, MaxAmt, MinPct, and MaxPct on SourceInvestProduct and DestInvestProduct.

• Sell Limitation Arrangement – This arrangement would describe the overall fund sale restrictions using MinAmt, MaxAmt, MinPct, and MaxPct on SourceInvestProduct and DestInvestProduct.

For any particular contract, the Number of transactions of a given type restrictions when applied to a particular date boil down to a restriction regarding whether transactions of a specific type are permitted for the particular contract as of a particular date. This can be supported by the addition a new CC for use on the holding side.


This CC would be returned in the position feed and would indicate any prohibited restrictions for the particular contract. This CC could be placed on Holding, Policy, or Annuity. We suggest Policy.

• ProhibitedFinancialTransactionCC.ProhibitedFinancialTransaction – The type codes would be drawn from OLI_LU_FINACTTYPE.

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 141 Index

INDEX

AbbrName .....................................................................80 Address ........................................................................12 AddressTypeCode......................................................12 AdministrativeTransaction .........................................25 AdvancingAllowed..................................................36, 37 AgeCalculationType .......................................45, 64, 92 AllocTypeProduct ...................................................14, 18 AllocTypeProductKey.................................................14 AllowedDayCC ............................................................86 AllowExceptionsToAgeInd.........................................82 AllowExceptionsToPremiumInd...................................82 AnnuitizationMinDelayMonths ..................................64 AppName ...................................................................119 AppVer .......................................................................119 ArrType.........................................................................52 AssetClass.............................................................70, 79 AssumedInterestRateCC...........................................65 Authorization ...............................................................22 AuthorizationEntity......................................................22 AuthorizationKey.........................................................22 AuthorizationMappingCodeInd .................................23 AuthorizationSignatureReqInd..................................22 BackDatingAllowed ................................................36, 37 BenefitReductionBasedOn ........................................64 Breakpoint....................................................................24 BreakpointKey .............................................................24 BusinessMethod .........................................................22 BusinessProcess ........................................................25 BusinessProcessAllowed ..............................25, 36, 37 BusinessProcessAllowedKey ...................................25 CarrierCode ....................... 26, 27, 35, 39, 70, 73, 89, 100 COLFixedPct ...............................................................65 COLIndexCapCC........................................................65 COLIndexType ......................................................65, 66 CompanyProducerID.....................................................27 ContingentJointType ..................................................65 CostBP...........................................................................46 CurrencyTypeCode ......................................71, 91, 114 CusipNum .....................................................................91 DefaultInd ...............................................................44, 75 Description.................................................25, 43, 54, 90 DestTransferAmtType ................................................14 DistribAgreementKey ...........................................36, 37 DSTCarrierCode............................................................26 DTCCMemberCode ......................................................80 DUNSNumber...............................................................80 DurQualifier ..................................................................99 FeatureCode ................................................40, 41, 48, 49

FeatureMappingCode................................................ 51 FeatureOptProduct........................................................ 42 FeatureOptProductKey ................................................. 42 FeatureProduct........................................................... 49 FeatureProductKey.................................................... 49 Fee ................................................................................ 54 FeeAmt ......................................................................... 55 FeeCapAmt................................................................... 55 FeeKey.............................................................. 54, 57, 75 FeeMode....................................................................... 54 FeePct ........................................................................... 55 FeeType ........................................................................ 54 FeeWaiverAmt ............................................................. 55 FeeWaiverBasedOn...................................................... 55 FinActivityType ........................................................... 23 FullName ............................................................... 70, 84 FundingSourceMethodsAllowed .............................. 58 FundingSourceMethodsAllowedKey ....................... 58 FundReference.............................................................. 35 GovtID.......................................................................... 84 IllustrationReqForSaleInd ......................................... 93 IncomeOptionType .................................................... 63 IncomePayoutProductOption ................................... 63 IncomePayoutProductOptionKey ............................ 63 InvestProduct.............................................. 27, 32, 34, 68 InvestProductInfo ........................................... 73, 76, 79 InvestProductInfoKey ................................................ 73 InvestProductKey ......................................................... 68 InvestProductTypeCode ............................................... 68 IssueNation ................................................................. 91 Jurisdiction ............................................42, 49, 69, 77, 91 KeyedValue............................................................... 102 KeyName................................................................... 102 KeyValue ................................................................... 102 LineOfBusiness ............................................................ 90 LiquidityFeatureType ................................................. 64 LivesType .............................................................. 45, 63 LoadingType ............................................................... 19 LOIROAType ........................................................ 20, 24 MaxAddOnAge ............................................................ 82 MaxAddOnAgeOwner ............................................... 81 MaxIssueAge.......................................................... 45, 82 MaxIssueAgeJointCoveredPerson................................ 46 MaxIssueAgeOwner ............................................... 45, 81 MaxNumAgents.......................................................... 93 MaxNumCombinedBeneficiaries ............................. 81 MaxNumContingentBeneficiaries ............................ 81 MaxNumContingentOwners ..................................... 81

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 142 Index

MaxNumDestinationInvestProd ................................47 MaxNumInstances......................................................51 MaxNumInvestProducts.............................................93 MaxNumPrimaryBeneficiaries ..................................81 MaxNumPrimaryCoveredPersons............................81 MaxNumPrimaryOwners ...........................................81 MaxNumSourceInvestProd .......................................47 MaxPct .........................................................................47 MaxPremiumAddOnAmt ............................................82 MaxPremiumInitialAmt ................................................82 MaxTerm.......................................................................47 MinContractAmt ...........................................................46 MinIssueAge ...........................................................45, 81 MinIssueAgeJointCoveredPerson .................................46 MinIssueAgeOwner ................................................45, 81 MinPct...........................................................................47 MinPremiumAddOnAmt...............................................82 MinPremiumAddOnEFTAmt........................................82 MinPremiumInitialAmt .................................................82 MinRemainingBalanceAmt...........................................46 MinTerm .......................................................................47 MinTotalAmt.................................................................46 MinTransactionAmt ......................................................46 NAICCode.....................................................................26 Name .......................................................................43, 51 NettingAllowed .............................................................37 NewMoneyAllocationRule............................................19 NoNewMoneyDate............................................43, 74, 92 NoResponseOk.........................................................121 Objective ......................................................................70 OlifEExtension...........................................................102 OrgCode ........................................................................80 OrgForm.......................................................................38 OrgKey....................................................................79, 80 OriginatingRole ...........................................................16 Ownership....................................................................81 OwnershipKey .............................................................81 ParticipantBasedOn .............................................45, 90 Party ........................................................................84, 98 PartyKey............................................................84, 85, 98 PartyTypeCode .....................................................38, 84 PaymentForm..................................................33, 58, 86 PaymentMethod....................................................32, 85 PaymentModeMethDesc ...........................................85 PaymentSource ..........................................................59 PayoutType .................................................................19 PeriodCertainMode ....................................................88 PeriodCertainPeriods .................................................88 PershingCarrierCode .....................................................26 PlanName ......................................................................89 PolicyProduct ................................28, 29, 89, 94, 99, 101 PolicyProductForm........................................................90 PolicyProductKey..........................................................89 PolicyProductTypeCode................................................90

PremType.................................................................... 19 ProductCode35, 39, 41, 42, 48, 60, 61, 62, 63, 68, 73, 90,

100 ProxyVendor ............................................................. 119 QualifiedPlanType................................................ 44, 97 RangeHighAmt ........................................................... 24 RangeLowAmt ............................................................ 24 RangeRateBP............................................................. 24 RateCreditBP................................................................ 46 RateType............................................................... 71, 99 RateVariationByVolumeKey................................ 28, 101 RateVariationKey ................................................... 74, 99 RelatedRole .................................................................. 16 Relationship............................................................ 17, 30 RevokableInd........................................................ 44, 64 RiderTypeCode .......................................................... 51 SaleEffectiveDate ............................................. 43, 73, 92 SaleExpirationDate........................................... 43, 73, 92 SelectionRule ............................................................. 51 ShortName.................................................................... 90 SignatureRequiredCode ........................................... 44 SourceOfFundsTC ..................................................... 58 SourceTransferAmtType ........................................... 14 SplitPctIncrementsCC ............................................... 65 SubPayDCAType ....................................................... 46 TermQualifier ......................................................... 47, 87 TestIndicator ............................................................. 121 TransExeDate ............................................................. 120 TransExeTime .......................................................... 120 TransMode ................................................................ 121 TransRefGUID.......................................................... 120 TransSubType............................................................. 120 TransType................................................................... 120 VendorCode.............................................................. 102 VendorName............................................................. 119 VersionDate.................................................................. 90

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009 Page 143 Revision History

REVISION HISTORY

Version Date Description of Change 2.2 Jan. 2009 *ACORD's Standards License (formerly our Terms and Conditions

of Use) has been updated. This is a documentation change only. No content changes have been made.

2.11 v2.1 Final Oct. 2006 ACORD's Terms and Conditions of Use have been updated. This is a documentation change only. No content changes have been made.

2.11 v2.0 Final Jan. 2005 Guide Release as Final for the 2.11 Life Specification and publication to the ACORD Web site.

2.11 v1.0 Oct. 2004 Document update for the 2.11 Life Specification Release.

acord lah ppfa implementation guide v2.2 jan 2009

Documents