ACORD LAH PPfA Implementation Guide v2.2 Jan 2009

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 rd 3 Floor PO Box 1529 Pearl River, NY 10965-8529 U.S.A. London London Underwriting Centre Suite 1 / 3 3 Minster Court Mincing Lane London EC3R 7DD United Kingdom

© 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED.

Table of Contents 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
OBJECT ........................................................................................................................................ 12 OBJECT ..................................................................................................................... 14 OBJECT ................................................................................................................. 16 * OBJECT (04-1.01.AN246)............................................................................................. 18 OBJECT........................................................................................................................... 19 OBJECT ............................................................................................................ 21 OBJECT .............................................................................................................................. 22 OBJECT ......................................................................................................... 23 OBJECT ................................................................................................................................... 24 OBJECT.......................................................................................................... 25 OBJECT ......................................................................................................................................... 26 OBJECT ................................................................................................................... 27 OBJECT ................................................................................................................... 28 OBJECT .................................................................................................................... 29 OBJECT .............................................................................................................................. 30 OBJECT ................................................................................................................ 31 OBJECT.......................................................................................................................... 32 OBJECT ............................................................................................................................. 34 OBJECT ..................................................................................................................... 35 OBJECT............................................................................................................... 36 OBJECT ....................................................................................................... 37 OBJECT .................................................................................................................................... 38 OBJECT ............................................................................................................. 39 OBJECT ......................................................................................................................... 40 OBJECT ................................................................................................................... 41 OBJECT ................................................................................................................... 42 OBJECT .................................................................................................................. 48 OBJECT .......................................................................................................................... 49 OBJECT ........................................................................................................................ 53 OBJECT ................................................................................................................................................. 54 * OBJECT (04-1.01.AN216) ...................................................................... 57 OBJECT .............................................................................................. 58 OBJECT ..................................................................................................................... 60 OBJECT .................................................................................................................... 61 OBJECT ........................................................................................................................ 62 OBJECT .................................................................................................... 63 OBJECT ..................................................................................................................... 67 OBJECT ............................................................................................................................. 68 © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

OBJECT ...................................................................................................................... 73 * OBJECT (04-1.01.AN216)....................................................................................... 75 OBJECT ................................................................................................................. 76 * OBJECT (04-1.01.AN247) ........................................................................................ 79 OBJECT ................................................................................................................................ 80 OBJECT .................................................................................................................................... 81 OBJECT ............................................................................................................................................ 84 OBJECT ....................................................................................................... 85 OBJECT......................................................................................................................... 88 OBJECT ............................................................................................................................. 89 Indicates the nation in which the product will be sold. .......................................................................................................................... 91

OBJECT...................................................................................................................... 94 < PRODUCER > OBJECT .................................................................................................................................... 96 OBJECT ................................................................................................................... 97 * OBJECT (04-1.01.AN252) ........................................................................................ 98 OBJECT .............................................................................................................................. 99 OBJECT .............................................................................................................. 100 OBJECT .................................................................................................... 101 CHAPTER 5 – TRANSMITTING PPFA............................................................................................................... 102 COMMON ELEMENTS ....................................................................................................................................... 102 CHAPTER 6 – XTBML SPECIFICATION FOR A PRODUCT PROFILE FOR ANNUITY .................................. 103 OBJECT ......................................................................................................................................... 104 OBJECT ........................................................................................................................................... 105 OBJECT ............................................................................................................................................. 106 OBJECT ....................................................................................................................................... 107 OBJECT ............................................................................................................. 110 OBJECT .............................................................................................................................................. 111 OBJECT ........................................................................................................................................ 112 <METADATA> OBJECT ................................................................................................................................... 114 Indicates the nation in which the product will be sold. ........................................................................................................................ 114

OBJECT......................................................................................................................................... 115 CHAPTER 7 - TRANSMITTING/SENDING A PRODUCT PROFILE FOR ANNUITY ........................................ 116 OBJECT ..................................................................................................................... 117 OBJECT ................................................................................................................................. 118 OBJECT ............................................................................................................................. 119 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

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


Page 1

Chapter One – Background

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


Page 2

Chapter Two – Product Profile Objectives

So now instead of this:

You have this:

XML PPfA

One-To-One Sharing, All Different

One-To-Many Sharing, All Same

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.


Page 3


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


Page 4


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, in the 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, , 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 and , additional features can be included under the same instance of . 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 and , the value of the element in the subordinate object would always further limit that of the higher level object . 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).


Page 5

Chapter Three – Guiding Principles for Implementation

Carriers & Distributors •

•

•

There must be one and only one object representing the product manufacturer (i.e. the carrier writing company) for each . This object contains a element providing carrier information applicable to all its applicable products within the XML document. Multiple carriertype parties may be present in a file. There may be multiple objects representing producers/distributors for each . Each of these objects contains a element providing the individual producer/distributor information. If no 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 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 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 objects, one for each CUSIP. If a file comprising multiple objects with a common CUSIP is sent from a carrier: • Each must have a unique / 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 and are intended to uniquely identify a given . and are used for entity recognition of a specific product profile, so it is therefore critical the combination is unique. Where and are both present on an object, the 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.


Page 6


Arrangements & Riders •

•

• • •

•

Each product requires at least one . is used to model service programs/arrangements, riders and payouts. The annuity product usage of the ACORD standard requires that, for a to exist, there must be at least one related . When there is more than one feature option available for selection, one and only one can be chosen for each . In cases when there are multiple feature options to be selected, a new composite feature can be created to make up the in question. If SourceInvestProduct and DestInvestProduct are not present, this implies all funds described by 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. values are persistent identifiers used in “Request/Response” transactions. For “Transmittal” transactions values would not be used.


Page 7


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


Page 8


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.

* 04-1.01.AN252
04-1.01.AN254 © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 9

Chapter Four – Descriptions & Definitions

*

04-1.01.AN246

* (04-1.01.AN221) * (04-1.01.AN231) * (04-1.01.AN247) © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 10


* (04-1-AN2??) * (04-1-AN2??) * (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 11


XML Element Name

Type

Description

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.
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. Type Code Type of address. Type Code Translation 2 = Business 3 = Vacation 9 = Regional Office 12 = Previous 16 = Business Shipping Address 17 = Mailing

LookUp Table String= 'Address Type'

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

< AddressStateTC>

String String String String String String Choice Collection

LookUp Table String= ‘State’ LookUp TableCode= ‘OLI_LU_STATE’

Used to contain an attention of additional address line. First line of the address. Second line of the address. Third line of the address. City of the address. State of the address. 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


Page 12


XML Element Name

Type

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

String

Type Code

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. Country of residence for the party.

String

Type Code Translation 1 = United States of America Postal Drop Code for address.


Page 13


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for AllocTypeProduct id= “ ” usage & meaning.

String

String

Choice Collection

LookUp Table String= ‘Transfer Amount Type’

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

LookUpTableCode= ‘OLI_LU_TRNSFRAMTTYPE’

LookUp Table String= ‘Transfer Amount Type’ LookUp Table Code= ‘OLI_LU_TRNSFRAMTTYPE’

See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. Types of allocations allowed for source funds. This element describes the means by which money may be allocated to the source fund(s).

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


Page 14


XML Element Name

Type

String

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 The name given by the carrier for this combination.


Page 15


XML Element Name

Type

Description

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. TypeCode The originating contract entity that the relationship being described is based upon. LookUp Table String= ‘Relation RoleCode’ Type Code Translation 8 = Owner 34 = Beneficiary Primary LookUp Table Code= 35 = Annuitant ‘OLI_LU_REL’ 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)

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

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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.


Page 16


XML Element Name LookUp Table String= ‘Relation RoleCode’ LookUp Table Code= ‘OLI_LU_REL’

Type Choice Collection

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


Page 17


XML Element Name

Type

Description

* Object (04-1.01.AN246) This object describes details about the amount which may be transferred or associated with a feature option. Attribute: AmountProductId = “”

String String

String

TypeCode

LookUp Table String= ‘Amount Context’ LookUp Table Code= ‘OLI_LU_AMTCONTEXT’

TypeCode

LookUp Table String= ‘Transfer Amount Type’

Type Code Translation 1 = Face Amount 2 = Rider Amount 3 = Modal Amount 4 = Annualized Amount 5 = Total Program Amount 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

LookUpTableCode= ‘OLI_LU_TRNSFRAMTTYPE’

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

String String String Percentage Percentage

????? Minimum amount. Maximum amount Minimum percentage Maximum percentage.


Page 18


XML Element Name

Type

Description

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. TypeCode Annuity Premium Structure. LookUp Table String= ‘Annuity Premium Type’

Type Code Translation 1 = Single 2 = Flexible

LookUp Table Code= ‘OLI_LU_ANNPREM’

TypeCode

LookUp Table String= ‘Annuity Payout Type’

Type Code Translation 1 = Immediate 2 = Deferred

LookUp Table Code= ‘OLI_LU_ANNPAYOUT’

TypeCode

LookUp Table String= ‘Allocation Option’

LookUp Table String= ‘Loading Type’ LookUp Table Code= ‘OLI_LU_LOADINGTYPE’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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)

LookUp Table Code= ‘OLI_LU_ALLOCATIONOPTION’

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

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.


Page 19


XML Element Name

Type TypeCode

LookUp Table String= ‘Letter of Intent or Rights of Accumulation’ LookUp Table Code= ‘OLI_LU_LOIROA’

Description 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

LookUp Table String= Data Field’ LookUp Table Code= ‘OLI_LU_DATAREQ’

‘Required

TypeCode

Note: If neither applies, the element should not be sent. 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.


Page 20


XML Element Name

Type

Description

Object Provides a means to exclude feature availability from a product for a distributor. AnnuityProductExclude Id = “”

String

String

String

String

String

See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. References a particular which is not available for sale by the distributor. References a particular which is not available for sale by the distributor.


Page 21


XML Element Name

Type

Description

Object The Authorization object identifies those entities that are allowed to complete specified financial and nonfinancial transactions by specified means. Attribute: String See the description at the beginning of this chapter for Authorization id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. Choice A list of means by which transactions may be initiated within Collection the contract. LookUp Table String= Submission Type’

‘App

LookUp Table Code= ‘OLI_LU_APPSUBMITTYPE’

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. Identifies those parties allowed to initiate transactions within the contract.

Choice Collection

LookUp Table String= ‘Relation RoleCode’

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)

LookUp Table Code= ‘OLI_LU_REL’

Boolean 0=False 1=True

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. Indicates whether a signature is required from the owner before requested authorization is activated. True indicates that a signature is required.


Page 22


XML Element Name

Type

Description

Object This object describes Financial and Non-Financial transactions that may be performed by authorized entities. Boolean Identifies the transaction as being Financial or NonFinancial. 0=False 1=True False = FinActivityType for Financial Activity. Indicates the activity is a financial activity.

TypeCode

LookUp Table String= ‘Transaction Type’

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

LookUp Table Code= ‘OLI_LU_TRANS_TYPE_CODES’

LookUp Table String= ‘Financial Activity Type’ LookUp Table Code= ‘OLI_LU_FINACTTYPE’

True = TXLifeTransCode for Non-Financial Activity. Indicates the activity is non-financial. Identifies the Non-Financial transactions that may be performed by authorized entities.

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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.


Page 23


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for Breakpoint id= “ usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. TypeCode Identifies if a Letter of Intent or Rights of Accumulation apply to the annuity product. LOI applies to a single contract: LookUp Table String= ‘Letter of letter of intent would indicate the initial dollars and the Intent or Rights of Accumulation’ 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 LookUp Table Code= ‘OLI_LUI_LOIROA’ 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. 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. 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. 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. TypeCode Indicates whether this breakpoint level is to define an Interest Rate series, or a Sales Charge Series. LookUp Table String= ‘Range Rate Type’ Type Code Translation 1 = Interest Rate Bonus 2 = Sales Charge LookUp Table Code= ‘OLI_LU_RANGERATETYPE’ © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 24


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for BusinessProcessAllowed id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. usage & meaning.

TypeCode

LookUp Table String= ‘Transaction Type’

Type Code Translation 103 = New Business Submission 508 = Payment

LookUp Table Code= ‘OLI_LU_TRANS_TYPE_CODES’

LookUp Table String= ‘Business Process Types’ LookUp Table Code= ‘OLI_LU_BUSPROCESS’

Identifies financial transactions allowed for the product.

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

Further explains the Business Process Allowed.

Choice Collection

Industry Comment: NAVA recommends that the description element be used as the Order Entry Display Name or Marketing Name. 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


Page 25


XML Element Name

Type

Description

Object A sub object under Party, providing more detailed information about the financial product manufacturer (a.k.a. the Carrier). Attribute: String See the description at the beginning of this chapter for Carrier id= “ ” usage & meaning. 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. String See the description at the beginning of this chapter for usage & meaning. 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.

String String String

Industry Comment: NAVA recommends using the NAIC code when representing the Insurance Company,. NAIC Code of the carrier. DST Carrier Code. Pershing Carrier Code.


Page 26


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for CarrierAppointment id= “ ” usage & meaning.

String

String

String

String

Date Date

See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. 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. When referencing products, this code represents the issuing Insurance Carrier. Industry Comment: NAVA recommends using the NAIC code when representing the Insurance Company. First date the appointment is effective. The expiration date of the appointment.


Page 27


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for ChargePct id= “ ” usage & meaning.

String

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

String


Integer

The duration to which the rate applies.

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

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

Percentage

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The percent surrender charge. 6.25% is expressed as 6.25 (i.e. do not express as a decimal)


Page 28

Chapter Four - Descriptions & Definitions

XML Element Name

Type

Description

Object This element describes generic commission information associated with the product. The PPfA usage does not intend CommOptionAvailable as a child of CommissionProduct. Attributes: String See the description at the beginning of this chapter for CommissionProduct id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. TypeCode Indicates the algorithm used to determine the contract entity upon which commission breakpoints are determined. LookUp Table String= ‘Age Calculation Method’ Type Code Translation 2 = Age Last Birthday 3 = Age Nearest in days LookUp Table Code= ‘OLI_LU_AGECALCMETH’ Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. TypeCode Indicates the commission breakpoints upon which subsequent premium are based if age is used as a threshold. LookUp Table String= ‘Subpay Comm Age Basis’ Type Code Translation 1 = Issue Age LookUp Table Code= 2 = Attained Age ‘OLI_LU_SUBPAYCOMMAGE’ TypeCode When multiple participants are indicated by PolicyProduct.ParticipantBasedOn, this further refines the LookUp Table String= ‘Party selection for Commission calculations. Selection’ Type Code Translation 1 = Party selection is not applicable LookUp Table Code= 2 = Oldest of the specified participants OLI_LU_PARTYSELECT 3 = Youngest of the specified participants 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)


Page 29


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for CommFormula id= “ usage & meaning.

String


String

TypeCode

See the description at the beginning of this chapter for usage & meaning. 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)

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

Choice Collection

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

String

String

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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. The carrier defined code for this specific commission option. ??? Should commission option be required ??? 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. 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.


Page 30


XML Element Name

Type

Description

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 / relationship, it is intended for use within the PPfA only under the / relationship, and Commission Options must be explicit by distributor/producer. This object is not used as a child of CommissionProduct within PPfA usage. 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

LookUp Table String= ‘Commission Option’ LookUp Table Code= ‘OLI_LU_COMMOPTION’

String

String Integer

03-2.01.AN09

Integer

03-2.01.AN09

Date

03-2.01.AN09

Date

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Carrier defined code for this specific commission option. Further definition on the associated commission rates are be established using the CommFormula and XTbML objects. Textual description of the commission option. 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). 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). Effective date when the commission option is initially effective. The first date this commission option is no longer effective.

03-2.01.AN09

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.


Page 31


XML Element Name

Type

Description

Object This object describes different commission events that are authorized at the distribution agreement level and apply to all products under the DistributionAgreement. Attributes: String See the description at the beginning of this chapter for CommRemittance id= “ ” usage & meaning.

String


String


See the description at the beginning of this chapter for usage & meaning. Indicates whether advancing of commissions will be accepted. Reflects if the carrier has agreed to advance commissions with this producer.


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

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

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

DEPRECATED LookUp Table String= ‘Payment Method’ LookUp Table Code= ‘OLI_LU_PAYMETHOD’

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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


Page 32


XML Element Name

LookUp Table String= Mode’

Type

TypeCode

Frequency of payment. These values are assumed to be based on policy effective date, not calendar dates.

‘Payment 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

LookUp Table Code= ‘OLI_LU_PAYMODE’

*

Choice Collection

LookUp Table String= ‘Payment Form’ LookUp Table Code= ‘OLI_LU_PAYMENTFORM’ 04-1.01.AN195

Description Life Spec v 2.11 Release.

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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. 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.


Page 33


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for CommSchedule id= “ ” usage & meaning.

String


String

*

String

See the description at the beginning of this chapter for usage & meaning. This is the entity recognition element for this object which is pointed to from within the PolicyProductInfo aggregate. Effective date that aggregate (i.e. the commission schedule) is initially available/applicable. Expiration date of the aggregate (schedule); the first date the schedule is no longer available. This is the code used to represent the carrier for the commission schedule being described.

04-1.01.AN248

Date

Date

String


Page 34


XML Element Name

Type

Description

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 and . String This code represents a link to . String Indicates a from , which can be selected as a destination fund with this feature option. This combination must be present in and .

* 04-1.01.AN246 * 04-1.01.AN246 * 04-1.01.246 * 04-1.01.246

String String Percentage Percentage

Format: NAVA recommends the 5 character fund abbreviation as used in DTCC’s ‘Fund CUSIP’. Minimum amount. Maximum amount. Minimum percentage. Maximum percentage.


Page 35


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for DistributionAgreement id= “ ” usage & meaning.

String


String

Boolean 0=False 1=True Boolean 0=False 1=True TypeCode

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

LookUp Table String= Product Type’

‘Policy

Indicates type of product this distribution agreement allows. Type Code Translation 9 = Fixed Annuity 10 = Variable Annuity 11 = Indexed Annuity

LookUp Table Code= ‘OLI_LU_POLPROD’

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

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. This element is a key to the Interest Rate Variation XTbML.

03-2.01.AN04

Date

03-2.01.AN04

LookUp Table String= ‘Date Basis’

Type Code Translation 1 = Application Signed Date 2 = Date Submitted

LookUp Table Code= ‘OLI_LU_ DATEBASIS’ (03-2.01.AN19)

*

(04-1.01.AN219)

*

(04-1.01.AN219)

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.

Boolean 0=False 1=True Date Date

Indicates if the Carrier will accept net transactions with this Distributor. The date beginning on which this distribution agreement is effective. The date on which this distribution agreement is no longer effective. This is the first day the distribution agreement cannot be used.


Page 36


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for DistributionAgreementInfo id= “ ” usage & meaning.

String


String

String


See the description at the beginning of this chapter for usage & meaning. 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.


Boolean 0=False 1=True Date

*

(04-1.01.AN219)

*

(04-1.01.AN219)

Date

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. 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. The date beginning on which the distribution agreement is effective for the producer. 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.


Page 37


XML Element Name

Type

Description

Object This aggregate defines the type of entity (Individual/Organization) and, if the entity is an organization, the form (type) of organization. TypeCode Further describes the entity when the entity is not a person. Type Code Translation 1 = Sole Proprietorship LookUp Table String= 2 = Partnership ‘Organization Form’ 9 = Government Agency 12 = Non-Profit Organization LookUp Table Code= 14 = Limited Liability ‘OLI_LU_ORGFORM’ 16 = Trust 23 = Corporation (General) 24 = Estate 25 = Plan Administrator

TypeCode

LookUp Table String= ‘Party Type’ LookUp Table Code= ‘OLI_LU_PARTY’ LookUp Table String= ‘Trust Type’ LookUp Table Code= ‘OLI_LU_TRUSTTYPE’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Indicates what types of entities are allowed for the product. Type Code Translation 1 = Person 2 = Organization

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.


Page 38


XML Element Name

Type

Description

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 and . String This code represents a link to . String Indicates a from , which cannot be selected as a fund with this feature option. This combination must be present in and . Format: NAVA recommends the 5 character fund abbreviation as used in DTCC’s ‘Fund CUSIP’.


Page 39


XML Element Name

Type

Description

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. String List of a feature, which cannot be selected (i.e. are in conflict) with this feature. The must reference a valid node within .


Page 40


XML Element Name

Type

Description

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. String List of features, which cannot be selected (i.e. are in conflict) with this feature option. The must reference a valid node within . String Unique Code, referencing the from which identifies the feature option which conflicts with the feature option being described.


Page 41


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for FeatureOptProduct id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. 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. LookUp Table String=

Choice Collection ‘State’

LookUp TableCode= ‘OLI_LU_STATE’

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


Page 42


XML Element Name

Type 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

String String

Date

Date

Date

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

Full name of the rider or service feature option. Free form description of feature option. The description element be used as the Order Entry Display Name or Marketing Name. 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-MMDD. If exact date is not available, an estimated date may be used, such as 1980-01-01. 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) 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.


Page 43


XML Element Name


LookUp Table String= ‘Qualified Plan Type’

Description 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. and must NOT be used concurrently as elements of the same . These elements are mutually exclusive. (04-1.01-AN231)

LookUp Table Code= ‘OLI_LU_QUALPLAN’

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


Boolean 0=False 1=True TypeCode

LookUp Table String= ‘Signature Required’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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 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. Indicates if the signature is required before a feature option is activated. Type Code Translation


Page 44


XML Element Name

Type

LookUp Table Code= ‘OLI_LU_SIGNREQUIRED’

TypeCode

LookUp Table String= ‘Coverage Lives’

LookUp Table String= Calculation Method’

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Indicates the algorithm used to determine age, given the date of birth and the effective date of the policy.

‘Age Type Code Translation 2 = Age Last Birthday 3 = Age Nearest in days

LookUp Table Code= ‘OLI_LU_AGECALCMETH’

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

LookUp Table Code= ‘OLI_LU_LIVESTYPE’

Description 1 = No Signature Required 2 = Required at Time of Application 3 = Required at Carrier Before Activation 4 = Electronic Signature

TypeCode

LookUp Table String= ‘Participant Role’ LookUp Table Code= ‘OLI_LU_PARTICROLE’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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

Integer

Integer

Integer

Integer

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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 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 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: 0199 Maximum age of all Owners (including primary, joint, contingent, etc as applicable) allowed in order that the rider


Page 45


XML Element Name

Type

Integer

Integer

Currency

Currency

Currency

* (04-1.01.AN240)

Currency

Currency

TypeCode

LookUp Table String= ‘Dollar Cost Averaging Type’

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)

LookUp Table Code= ‘OLI_LU_DCATYPE’

Real

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

Description or arrangement may be selected. Value Range: 0-199 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 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 Minimum contract value allowed in order to select the rider or arrangement specified. Minimum remaining balance allowed within the contract after being reduced by this rider or arrangement program amount. 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. 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. Minimum amount of the total transactions within an arrangement program. 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.

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??

Real

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

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.


Page 46


XML Element Name

Type

Integer

Integer

TypeCode

LookUp Table String= ‘Payment Mode’

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. The minimum allowable term within the rider or arrangement. The maximum allowable term within the rider or arrangement. Qualifies the min/max term of the rider or arrangement program. Type Code Translation 1 = Annually (Years) 4 = Monthly (Months) 8 = Daily (Days)


Percentage

Percentage

Integer

Integer

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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. 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. 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. 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.


Page 47


XML Element Name

Type

Description

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. String The feature which must be (i.e. are required) to be selected with this feature option. String Unique code which identifies the feature option. Unique Code, referencing the from which identifies the feature option which conflicts with the feature option being described.


Page 48


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for FeatureProduct id= “ ” usage & meaning. DataRep= “ ”

“Full”

String

Attribute: Persistence of Key

Attribute

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". 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’.

LookUp Table String= ‘Persistence of Key Code’ LookUp Table Code= ‘PERSISTKEY’

Type Code Translation 2 = Permanent or Value Provided is Persistent Indefinitely (a permanent key is assigned by the owner of the data.)

String

String

Choice Collection

LookUp Table String=

‘State’

LookUp TableCode= ‘OLI_LU_STATE’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. See the description at the beginning of this chapter for usage & meaning. 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. Collection or list of all 37 = NY jurisdiction(s) where the 38 = NC product can legally be 39 = ND offered or sold. 41 = OH 42 = OK If this element and 43 = OR JurisdictionApproval are 45 = PA


Page 49


XML Element Name

Type

Description missing, it is assumed 47 = RI that the feature is 48 = SC available in the states in 49 = SD which the product is 50 = TN available. Use 51 = TX JurisdictionCC instead of 52 = UT JurisdictionApproval if no 53 = VT dates are specified by 55 = VA individual states. 56 = WA 57 = WV Type Codes 58 = WI 1 = AL 59 = WY 2 = AK 3 = American Samoa 4 = AZ 14 = Guam 5 = AR 24 = Marshall Islands 6 = CA 46 = Puerto Rico 7 = CO 54 = Virgin Islands 8 = CT 101 = Alberta 9 = DE 102 = British Columbia 10 = DC 103 = Manitoba 12 = FL 104 = New Brunswick 13 = GA 105 = Newfoundland 15 = HI 106 = Northwest Territories 16 = ID 107 = Nova Scotia 17 = IL 108 = Ontario 18 = IN 109 = Prince Edward Island 19 = IA 110 = Quebec 20 = KS 111 = Saskatchewan 21 = KY 112 = Yukon Territories 22 = LA 113 = Nunavut 23 = ME 25 = MD Note: This is a partial list from 26 = MA the current ACORD spec. 27 = MI Please see current spec. for 28 = MN additional codes. 29 = MS 30 = MO The jurisdiction chosen must 31 = MT correspond to the Issue Nation 32 = NE chosen. 33 = NV 34 = NH Codes at lower level must be a 35 = NJ subset of codes chosen at the 36 = NM higher levels.


Page 50


XML Element Name LookUp Table String= Select Rule’

Type String TypeCode ‘Rider

LookUp Table Code= ‘OLI_LU_RIDERSELECTRULE’

Description Full name of the feature. 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 (041.01.AN241)

Integer

TypeCode

LookUp Table String= Type’

‘Object

TypeCode Translation 86 = AnnRider 89 = Arrangement

LookUp Table Code= ‘OLI_LU_OBJECTTYPE’ LookUp Table String= Type’

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. Identifies the feature as a Rider or feature/arrangement.

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Unique identifier, which ties together information, related to the rider.

‘Rider

LookUp Table Code= ‘OLI_LU_RIDERTYPE’

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.


Page 51


XML Element Name

Type TypeCode

LookUp Table String= ‘Arrangement Type’ LookUp Table Code= ‘OLI_LU_ARRTYPE’

Description Unique identifier, which ties together information, related to the arrangement. Type Code Translation 2 = Dollar Cost Averaging 3 = Asset Rebalancing Sometimes Called Rebalancing (041.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.


Page 52


XML Element Name

Type

Description

Object This object indicates which feature(s) must be present or elected in order to elect the rider or arrangement being described. String List of a feature which must be (i.e. is required) to be selected with or prior to this feature. The must also exist in . 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.


Page 53


XML Element Name

Type

Description

Object The Fee Object identifies all fees associated with the investment, feature or policy object being described. Attribute: String See the description at the beginning of this chapter for Fee id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. 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

‘Fee

LookUp Table Code= ‘OLI_LU_FEETYPE’


TypeCode

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

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

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. Identifies the frequency of the fee. If no frequency applies, the do not send the element.

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Narrative description of the fee. The description element can be used as the Order Entry Display Name or Marketing Name.


Page 54


XML Element Name

Type Integer Currency

Integer Currency Percentage

Percentage

TypeCode

LookUp Table String= ‘Rate Based On’

Type Code Translation 1 = Premium 2 = Account Value 3 = Either Premium or Account Value (AN05)

LookUp Table Code= ‘OLI_LU_RATEBASEDON’

*

Integer Currency Boolean 0=False 1=True TypeCode

(04-1.01.AN221)

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Amount of premium or account value at which the normal annual contract charge is waived. ‘True’ indicates that this fee is included in the Gross-to-Net calculation to arrive at ‘CommissionablePremium’. 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

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

Description If the FeeType references an amount, and/or the fee is represented in a dollar amount, this is the actual dollar amount charged. The maximum or ceiling amount of the fee. Charges are waived at (inclusive of) this amount. 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.) The maximum or ceiling percentage. Charges are waived at (inclusive of) this amount. Indicates whether the threshold for having contract charges waived is based upon the amount of the premium or account value.

TypeCode

(04-1.05.76)

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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

LookUp Table String= ‘Statement Basis’ LookUp Table Code= ‘OLI_LU_ STMTBASIS’ * (04-1.05.76)

Boolean

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


Page 55


XML Element Name (04-1.05.76)

Type Integer

Description number of days for which a charge free window exists for a fee.

The


Page 56


XML Element Name

Type

Description

* 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: String See the description at the beginning of this chapter for FreelookInvestRuleProduct id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. usage & meaning. 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. TypeCode Identifies the type of value to be returned if the Freelook provision is exercised. LookUp Table String= ‘Rate Based On’ Type Code Translation LookUp Table Code= 1 = Premium ‘OLI_LU_RATEBASEDON’ 2 = Account Value

String String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The minimum age for which this rule applies. The maximum age for which this rule applies.


Page 57


XML Element Name

Type

Description

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

Attribute: FundingSourceMethodsAllowed id= “ ”

String


String

See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. Indicates the source of premium (whether initial or subsequent premium).

String Choice Collection

LookUp Table String= ‘Source of Funds’

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)

LookUp Table Code= ‘OLI_LU_SOURCEOFFUNDS’

LookUp Table String= ‘Payment Form’ LookUp Table Code= ‘OLI_LU_PAYMENTFORM’

Choice Collection

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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.


Page 58


XML Element Name


Description Provides payment detail for specific source of funds.

LookUp Table String= ‘Financial Activity Type’

Type Code Translation 7 = Initial Payment 9 = Additional Payment

LookUp Table Code= ‘OLI_LU_FINACTTYPE’



Page 59


XML Element Name

Type

Description

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 See the description at the beginning of this chapter for id = “” usage & meaning. < 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. income payout option code. This value correlates with the 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.


Page 60


XML Element Name

Type

Description

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 See the description at the beginning of this chapter for id = “” usage & meaning. < 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. income payout option code. This value correlates with the 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.


Page 61


XML Element Name

Type

Description

Object A collection of Income Option selections, including their name and description. IncomeOptionInfo See the description at the beginning of this chapter for id = “” usage & meaning. < 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. TypeCode Describes the available payout options a carrier offers within an immediate annuity or at annuitization. LookUp Table String= ‘Income Option’ Type Code Translation 1 = Life Only 2 = Greater of Period Certain and Life (Life with Period LookUp Table Code= Certain) ‘OLI_LU_INCOPTION’ 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. Full name of the Income Option.

Integer

Description of the Income Option.


Page 62


XML Element Name

Type

Description

Object IncomePayoutOption contains settlement information for immediate annuities and valid settlement options available upon annuitization of deferred annuities. Attribute: String See the description at the beginning of this chapter for IncomePayoutProductOption id= “ ” usage & meaning. usage & meaning. usage & meaning. String The unique, carrier specific identification for this Annuity Income Payout Option Code.

LookUp Table String= Option’

Choice Collection ‘Income

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

LookUp Table Code= ‘OLI_LU_INCOPTION’ DEPRECATED in 2.10 via AN02

LookUp Table String= ‘Coverage Lives’ LookUp Table Code= ‘OLI_LU_LIVESTYPE’

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. Describes the available payout options a carrier offers within an immediate annuity or at annuitization.

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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.


Page 63


XML Element Name LookUp Table String= Calculation Method’

Type TypeCode

‘Age Type Code Translation 1 = Age Next Birthday 2 = Age Last Birthday 3 = Age Nearest in days


TypeCode

LookUp Table String= ‘Liquidity Feature Types’ LookUp Table Code= ‘OLI_LU_LIQUIDITYFEATURE’

Boolean 0=False 1=True Integer


‘Payout

LookUp Table Code= ‘OLI_LU_ANNPAYOUT’ LookUp Table String= Reduction Based On’

Description Indicates the algorithm used to determine age given the date of birth and the effective date of the policy.

‘Benefit

LookUp Table Code= ‘OLI_LU_BENREDUCEBASEDON’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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 Indicates if once an option is chosen, whether it may be revoked or changed. True indicates that the option can be revoked. Gives the minimum number of months that annuitization may be delayed before payout. Payout type of this payout Type Code Translation 1 = Immediate 2 = Deferred

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


Page 64


XML Element Name


LookUp Table String= ‘Contingencies Joint’ LookUp Table Code= ‘OLI_LU_CONTINGJOINT’

Description 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%

Choice Collection

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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%

Choice Collection

Note: If no limits are imposed, the element should not be sent. Assumed Interest Rate. i.e. Assumed Investment Rate. Example: If 5% is chosen and gain is 5%, payments remain the same. Example: 1 = 1% 4 = 4% Etc.

Choice Collection

Cost of Living Percentage. 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)

LookUp Table String= ‘Cost of Living Rates’ LookUp Table Code= ‘OLI_LU_COLINDEX’

2.5 = 2.5% 5.5 = 5.5%

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


Page 65


XML Element Name

Type

Description

e> Example: 1 = 1% 4 = 4%

Choice Collection

2.5 = 2.5% 5.5 = 5.5%

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

LookUp Table String= ‘Levelization Option Code’ LookUp Table Code= ‘OLI_LU_LEVELIZEDOPT’ 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


Page 66


XML Element Name

Type

Description

Object Contains the codes used by various data service providers for this investment. InformationService String See the description at the beginning of this chapter for id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. Provides the identity of the service provider to which the TypeCode information in this object pertains. LookUp Table String= ‘Information Service Provider’ Type Code Translation 1 = Morningstar 2 = Lipper LookUp Table Code= 3 = VARDS ‘OLI_LU_INFOSRVPROVIDER’

String

Contains the code that the service provider uses to refer to this investment.


Page 67


XML Element Name

Type

Description

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 (), that it has available via the InvestProductInfo object associated with the PolicyProduct. Attributes: InvestProduct id= “ ”

String


DataRep= “ ”

“Full”

String

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". See the description at the beginning of this chapter for usage & meaning. Format: CarrierCode + ‘-’ + ProductCode (NAIC Code (5 char fund abbreviation) or IARD/CRD #)


Attribute

LookUp Table String= ‘Persistence of Key Code’

Type Code Translation 2 = Permanent or Value Provided is Persistent Indefinitely (a permanent key is assigned by the owner of the data.)

LookUp Table Code= ‘PERSISTKEY’

String

TypeCode

LookUp Table String= ‘Investment Product Type’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. See the description at the beginning of this chapter for usage & meaning. 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)

LookUp Table Code= ‘OLI_LU_INVESTPROD’

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

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Unique identifier assigned by the carrier that ties together information related specifically to the fund and fund


Page 68


XML Element Name

LookUp Table String= ‘State’ LookUp TableCode= ‘OLI_LU_STATE’

Type

Choice Collection

Description performance. This ProductCode must be passed back on an NBfA transaction. Collection or list of all 41 = OH jurisdiction(s) where the fund 42 = OK can legally be offered or 43 = OR sold. 45 = PA 47 = RI If this element or 48 = SC JurisdictionApproval is sent, 49 = SD jurisdiction is the same as 50 = TN the PolicyProduct. Use 51 = TX JurisdictionCC instead of 52 = UT JurisdictionApproval if no 53 = VT dates are specified by 55 = VA individual states. 56 = WA 57 = WV Type Codes 58 = WI 1 = AL 59 = WY 2 = AK 3 = American Samoa 4 = AZ 14 = Guam 5 = AR 24 = Marshall Islands 6 = CA 46 = Puerto Rico 7 = CO 54 = Virgin Islands 8 = CT 101 = Alberta 9 = DE 102 = British Columbia 10 = DC 103 = Manitoba 12 = FL 104 = New Brunswick 13 = GA 105 = Newfoundland 15 = HI 106 = Northwest Territories 16 = ID 107 = Nova Scotia 17 = IL 108 = Ontario 18 = IN 109 = Prince Edward Island 19 = IA 110 = Quebec 20 = KS 111 = Saskatchewan 21 = KY 112 = Yukon Territories 22 = LA 113 = Nunavut 23 = ME 25 = MD Note: This is a partial list 26 = MA from the current ACORD 27 = MI spec. Please see current 28 = MN spec. for additional codes. 29 = MS 30 = MO The jurisdiction chosen must 31 = MT correspond to the Issue 32 = NE Nation chosen. 33 = NV 34 = NH Codes at lower level must be 35 = NJ a subset of codes chosen at 36 = NM the higher levels. 37 = NY 38 = NC 39 = ND


Page 69


XML Element Name

Type String String TypeCode

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)

LookUp Table String= ‘Investment Product Objective’ LookUp Table Code= ‘OLI_LU_INVESTOBJ’

Description Full legal name of the fund. Abbreviated name of the fund. General investment objective of fund.

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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

LookUp Table String= Class’ LookUp Table Code=

TypeCode ‘Asset

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


Page 70


XML Element Name ‘OLI_LU_ASSETCLASS’

Type

TypeCode

LookUp Table String= ‘Currency Type Code’


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

LookUp Table Code= ‘OLI_LU_CURRENCYTYPE’

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

‘Rate

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)

LookUp Table Code= ‘OLI_LU_RATETYPE’

Date

Date

Date

Date

Percentage

03-2.01.AN04

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The date before which this fund cannot be sold or elected. The format is: YYYY-MM-DD. 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. Date after which no new money can be applied to this product (new business or inforce contracts). The format is: YYYY-MM-DD. 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. The minimum percentage required to deposit premium into the fund. This element is a key to the Interest Rate Variation XTbML.


Page 71


XML Element Name 03-2.01.AN04 LookUp Table String= ‘Date Basis’ LookUp Table Code= ‘OLI_LU_DATEBASIS’

Type Date

Description 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


Page 72


XML Element Name

Type

Description

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 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: String See the description at the beginning of this chapter for InvestProductInfo id= “ ” usage & meaning. String


String

String

See the description at the beginning of this chapter for usage & meaning. Within the context of , and keys referring to InvestProduct, this code represents the Managing Firm. This element is used together with to reference a fund detailed in the object. Unique identifier that ties together information related specifically to the fund. This element is used together with to reference a fund detailed in the object. For an object that allows multiple objects with the same key, this element is used to define a unique occurrence of the object.

String

Integer

Date

Date

Used to number the funds attached to a contract so they appear in a specified order. 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 object. 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 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)


Page 73


XML Element Name

Type Date

String

* 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

03-2.01.AN11

Currency

03-2.01.AN11

Currency

03-2.01.AN11

Percentage

03-2.01.AN11

Percentage

Description 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 object. If there is no Termination Date, then do not send. This element acts as a pointer/link to a specific InvestProduct RateVariation aggregate thus providing a mechanism for defining alternate rates for an investment.

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. The minimum amount that may be deposited into subaccount or allocated to the model or category. The maximum amount that may be deposited into subaccount or allocated to the model or category. The minimum percentage that may be deposited into subaccount. In the case of Models, this is the minimum percent allocation defined for this model. The maximum percentage that may be deposited into subaccount. In the case of Models, this is the maximum percent allocation defined for this model.


Page 74


XML Element Name

Type

Description

* Object (04-1.01.AN216) This object describes the free look investment rules applicable to the product. Attribute: String See the description at the beginning of this chapter for InvestRuleProduct id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. Boolean Indicates the rule is the default for the product when one is 0=False not chosen, but election of an option is mandatory. 1=True TypeCode Indicates how funds are to be invested during the Freelook period LookUp Table String= ‘Freelook Investment Rule’ Type Code Translation 1 = Initial Allocation 2 = Safe Harbor LookUp Table Code= ‘OLI_LU_FREELOOKINVEST’


Page 75


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for JurisdictionApproval id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String



Page 76


XML Element Name LookUp Table String= LookUp TableCode= ‘OLI_LU_STATE’

‘State’


Description Collection or list of all 43 = OR jurisdiction(s) where the 45 = PA product can legally be 47 = RI offered or sold. If this 48 = SC element is not sent, the 49 = SD available jurisdictions are the 50 = TN same as the product 51 = TX (PolicyProduct). 52 = UT 53 = VT Type Codes 55 = VA 1 = AL 56 = WA 2 = AK 57 = WV 4 = AZ 58 = WI 5 = AR 59 = WY 6 = CA 3 = American Samoa 7 = CO 14 = Guam 8 = CT 24 = Marshall Islands 9 = DE 46 = Puerto Rico 10 = DC 54 = Virgin Islands 12 = FL 101 = Alberta 13 = GA 102 = British Columbia 15 = HI 103 = Manitoba 16 = ID 104 = New Brunswick 17 = IL 105 = Newfoundland 18 = IN 106 = Northwest Territories 19 = IA 107 = Nova Scotia 20 = KS 108 = Ontario 21 = KY 109 = Prince Edward Island 22 = LA 110 = Quebec 23 = ME 111 = Saskatchewan 25 = MD 112 = Yukon Territories 26 = MA 113 = Nunavut 27 = MI 28 = MN Note: This is a partial list 29 = MS from the current ACORD 30 = MO spec. Please see current 31 = MT spec. for additional codes. 32 = NE 33 = NV The jurisdiction must 34 = NH correspond to Issue Nation 35 = NJ chosen. 36 = NM 37 = NY Codes at lower level must be 38 = NC a subset of codes chosen at 39 = ND the higher levels. 41 = OH 42 = OK


Page 77


XML Element Name

Type Date

Date

Date

Date

Date

Description Date before which the product is cannot be sold. The date product is first available for sale. The format is: YYYY-MMDD. Note: If exact date is not available, do not send the element. The last date through which the product is available for sale, but additional deposits can continue. The format is: YYYYMM-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) 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: YYYYMM-DD. Note: If there is no ‘InForceExclusionCalendarDate’, then do not send the element. 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: YYYYMM-DD. Note: If there is no ‘InForceExclusionContractDate’, then do not send the element. 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.


Page 78


XML Element Name

Type

Description

* 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: String See the description at the beginning of this chapter for NumInvestProduct id= “ ” usage & meaning. < NumInvestProduct Key>

String

< NumInvestProduct SysKey>

String

TypeCode

See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. Type of Asset this investment represents. TypeCode Translation 1 = Fixed 2 = Equity 3 = Cash 5 = Debt 8 = Model

LookUp Table String= ‘Asset Class’ LookUp Table Code= ‘OLI_LU_ASSETCLASS’

String

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The maximum number of investments/funds allowed to be selected/used in specifying destinations in an allocation. The maximum number of investments/funds allowed to be selected/used in specifying source funds in an allocation.


Page 79


XML Element Name

Type

Description

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. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String Abbreviated name of the organization String Unique code for the organization. Defined as a short code assigned by the organization to internally identify the organizational unit. String Unique number for the organization assigned by Dun and Bradstreet for credit reporting purposes. String Unique member code of the organization assigned by Depository Trust Clearing Corporation(DTCC).


Page 80


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for Ownership id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. Integer Maximum number of primary owners allowed per contract. Greater than one indicates joint owners. Integer Maximum number of contingent owners allowed per contract. Greater than one indicates joint contingent owners are allowed on a contract. contract. Greater than one indicates joint annuitants are allowed. contract. Greater than one indicates joint contingent annuitants are allowed. Integer Maximum number of primary beneficiaries allowed per contract. contract.

Integer

Integer

Integer

Integer

Integer

Maximum number of all types of beneficiaries allowed per contract including primary, contingent and tertiary beneficiaries. 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 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 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 Minimum Issue Age for all Annuitants within the contract.


Page 81


XML Element Name

Type

Integer

Integer

Boolean 0=False 1=True Boolean 0=False 1=True Currency

Currency

Currency

Currency

Currency

Integer

Integer

Integer

Integer

Integer

Integer

Description Value Range: 0-199 Maximum Issue Age for all Annuitants within the contract. Value Range: 0-199 Maximum age where subsequent premium is accepted for all Annuitants within the contract. Value Range: 0-199 Indicates if exceptions to age minimums and maximums are permitted, thereby permitting a soft edit of min/max values. True indicates exceptions allowed. Indicates if there are exceptions to minimum and maximum premiums allowed. True indicates exceptions allowed. Minimum Initial Premium accepted. Value Range: 0-+ Minimum Add-on (subsequent) Premium accepted. Value Range: 0-+ Minimum Add-on (subsequent) accepted if using EFT. Value Range: 0-+ Maximum Initial Premium accepted. Value Range: 0-+ Maximum Add-on (subsequent) Premium accepted. Value Range: 0-+ 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 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 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 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 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 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.


Page 82


XML Element Name

Type

Integer

Integer

Integer

Integer

Integer

Integer

(03-2.01AN21)

Boolean

(03-2.01AN21)

0=False 1=True Boolean 0=False 1=True

Description Value Range: 0-199 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 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: 0199 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 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 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 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: 0199 Indicates whether both Joint and Contingent Owners are allowed. 0 = No (they are mutually exclusive) 1= Yes (they are both allowed) Indicates whether both Joint and Contingent Annuitants are allowed. 0 = No (they are mutually exclusive) 1= Yes (they are both allowed)


Page 83


XML Element Name

Type

Description

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 are additional, more detailed objects, such as 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: String See the description at the beginning of this chapter for Party id= “ ” usage & meaning. TypeCode Type of party existing in the collection. Select one of the following: Lookup Table String= ‘Party Type’ Type Code Translation 1 = Person 2 = Organization Lookup Table Code= ‘OLI_LU_PARTY’ String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. 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.

Integer

When Party.Type is "Organization", FullName is the full, legal name of the organization. 9-digit Federal Tax ID of the Party. Data should be stored as a string with NO formatting.


Page 84


XML Element Name

Type

Description

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

String

*

String

TypeCode


String

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

‘Payment


LookUp Table String= ‘Payment Method’ LookUp Table Code= ‘OLI_LU_PAYMETHOD’

See the description at the beginning of this chapter for usage & meaning. See the description at the beginning of this chapter for usage & meaning. A description used to describe this combination of Payment Mode and Payment Method collectively. Describes the allowable frequency.

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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 (032.01.AN08)

Note: This is a partial list from the current ACORD spec. © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 85


XML Element Name

Type

Choice Collection

LookUp Table Code= ‘OLI_LU_PAYMENTFORM’

Choice Collection

*

Choice Collection

(04-1.01.AN182)

This element has been replaced with PaymentForm with ACORD’s 2.10 Release. 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)

LookUp Table String= ‘Payment Form’

Description Please see current spec. for additional codes.

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 10 = 10th 25 = 25th This will be a th 11 = 11 26 = 26th choice of days th 12 = 12 27 = 27th from 1-31. th 13 = 13 28 = 28th th 14 = 14 29 = 29th Type Code th 15 = 15 30 = 30th Translation st th 1=1 16 = 16 31 = 31st nd th * 34 = Last Day 2=2 17 = 17 3 = 3rd 18 = 18th 4 = 4th 19 = 19th Note: Allowable th 5=5 20 = 20th days are indicated 6 = 6th 21 = 21st here only if there 7 = 7th 22 = 22nd is a limitation. 8 = 8th 23 = 23rd 24 = 24th 9 = 9th 10 = 10th 25 = 25th This will be a th 11 = 11 26 = 26th choice of days th 12 = 12 27 = 27th from 1-31. th 13 = 13 28 = 28th th 14 = 14 29 = 29th Type Code th 15 = 15 30 = 30th Translation st th 1=1 16 = 16 31 = 31st nd th 34 = Last Day 2=2 17 = 17 3 = 3rd 18 = 18th 4 = 4th 19 = 19th Note: Allowable th 5=5 20 = 20th days are indicated 6 = 6th 21 = 21st here only if there 7 = 7th 22 = 22nd is a limitation. 8 = 8th 23 = 23rd 24 = 24th 9 = 9th


Page 86


XML Element Name * (04-1.01.AN182)

Type Integer

*

Integer

(04-1.01.AN182)

*

(04-1.01.AN182)

TypeCode


Type Code Translation 1 = Annually (Years) 4 = Monthly (Months) 8 = Daily (Days)


* *

(04-1.01.AN182) (04-1.01.AN182)

* 1.01.AN182)

Description 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. 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. Qualifies the minimum and/or maximum term.

(04-

Percentage Percentage Currency

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Defines the minimum percentage permissible for a method and/or mode, if applicable. Defines the maximum percentage permissible for a method and/or mode, if applicable. Defines the minimum transaction amount for any modal and/or method of payment, if applicable.


Page 87


XML Element Name

Type

Description

Object PeriodCertainCC object further describes the duration of each available period certain. This object only applies to those Income Options which include period certain. TypeCode The mode or qualifier of the periods allowed in a period certain. LookUp Table String= ‘Payment Type Code Translation Mode’ 1 = Annually (Years) LookUp Table Code= 4 = Monthly (Months) ‘OLI_LU_PAYMODE’

Choice Collection

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Number of periods allowed under a period certain option. Note: If no limits are imposed, PeriodCertainMode and PeriodCertainPeriod elements should not be sent.


Page 88


XML Element Name

Type

Description

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 object. The elements listed here are the ones relevant for a Product Profile for Annuities. Attributes: String See the description at the beginning of this chapter for PolicyProduct id= “ ” usage & meaning. DataRep= “ ”

“Full”

PartyID= “ ”

String

String

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.

See the description at the beginning of this chapter for usage & meaning. Format: CUSIP + ‘-’+ carrier-defined unique id (9char) (up to 15 char/alphanumeric)

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

Attribute

LookUp Table Code= ‘PERSISTKEY’

String

String

String

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. See the description at the beginning of this chapter for usage & meaning. 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 object. Full legal name of the product.


Page 89


XML Element Name

Type String

Description Insurance Carrier’s internal code for the product.

Date

String String

Each PolicyProduct object must have a unique ProductCode for entity recognition purposes. 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. Short product name used most commonly. Free-form narrative description of the product.

TypeCode

Description element may be used as the Order Entry Display Name or Marketing Name. Indicates type of Annuity this profile is describing.

LookUp Table String= Product Type’

‘Policy

Type Code Translation 9 = Fixed Annuity 10 = Variable Annuity 11 = Indexed Annuity

LookUp Table Code= ‘OLI_LU_POLPROD’ LookUp Table String= Form’

TypeCode ‘Holding

Type Code Translation 1 = Individual 2 = Group

LookUp Table Code= ‘OLI_LU_HOLDINGFORM’ Table String= Business’

TypeCode LookUp ‘Line of

LookUp Table String= ‘Participant Role’

LookUp Table Code= ‘OLI_LU_PARTICROLE’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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.

LookUp Table Code= ‘OLI_LU_LINEBUS’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Identifies product as whether product is individual or group.

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)


Page 90


XML Element Name

Type

TypeCode


String

TypeCode ‘Nation’

LookUp Table String= LookUp TableCode= ‘OLI_LU_STATE’

Choice Collection ‘State’

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

LookUp Table Code= ‘OLI_LU_NATION’

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



Description

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Collection or list of all 38 = NC jurisdiction(s) where 39 = ND the product can 41 = OH legally be offered or 42 = OK sold. 43 = OR 45 = PA Use JurisdictionCC 47 = RI instead of 48 = SC JurisdictionApproval 49 = SD if no dates are 50 = TN specified by state. 51 = TX 52 = UT Type Codes 53 = VT 1 = AL 55 = VA 2 = AK 56 = WA 4 = AZ 57 = WV 5 = AR 58 = WI 6 = CA 59 = WY 7 = CO 3 = American Samoa 8 = CT 14 = Guam 9 = DE 24 = Marshall Islands 10 = DC 46 = Puerto Rico 12 = FL 54 = Virgin Islands 13 = GA 101 = Alberta 15 = HI 102 = British Columbia 16 = ID 103 = Manitoba 17 = IL 104 = New Brunswick 18 = IN 105 = Newfoundland


Page 91


XML Element Name

Type 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

Date

Date

Date

TypeCode

LookUp Table String= Calculation Method’

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. Date product is first available for sale. The format is: YYYYMM-DD. The last date through which the product is available for sale, but additional deposits can continue. The format is: YYYYMM-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. 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. Indicates the algorithm used to determine age given the date of birth and the effective date of the policy.

‘Age Type Code Translation 2 = Age Last Birthday 3 = Age Nearest in days


Description 106 = Northwest Territories 107 = Nova Scotia 108 = Ontario 109 = Prince Edward Island 110 = Quebec 111 = Saskatchewan 112 = Yukon Territories 113 = Nunavut

Choice Collection

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. DEPRECATED IN 2.11 via 04-1.01.AN205 Collection of allowable scheduled payments.

LookUp Table String= ‘Payment Method’ LookUp Table Code= ‘OLI_LUI_PAYMETH’ DEPRECATED

Type Code Translation 1 = No Billing 2 = Regular Billing 3 = Irregular Billing 4 = Paid in Advance 5 = List Billing


Page 92


XML Element Name

Type

Integer

Integer

Boolean 0=False 1=True TypeCode


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. Maximum number of agents allowed per contract. This is typically an administrative, not contractual, limitation. 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). 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. The unit of measure for the LOI period. Type Code Translation 1 = Annually 3 = Quarterly 4 = Monthly 6 = Weekly 8 = Daily

LookUp Table Code= ‘OLI_LUI_PAYMODE’

Integer

03-2.01.AN01

Integer

??

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The duration of the LOI period. Number of days, months, etc. based on LOIPeriodType. Indicates whether or not the Tax Withholding information for Federal and State is required to be collected for this product upon order entry. ??


Page 93


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for PolicyProductInfo id= “ ” usage & meaning.

String

RefID for PolicyProduct. Provides link to PolicyProduct being referenced.

String

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

String


String

String


String

The Carrier’s internal code for the product. This, combined with must reference a valid defined in the object. Represents the Carrier (manufacturer) of the annuity product. This, combined with must reference a valid defined in the 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. This element is used only with the DistributionAgreement parent object. The commission schedule data is defined in and objects.

*

String

(04-1.01.AN248)

String

NOTE: CommissionScheduleCode is used for Entity Recognition instead of CommissionScheduleKey. This element, when combined with CarrierCode, enables entity recognition to CommSchedule. 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.


Page 94


XML Element Name 03-2.01.AN19 03-2.01.AN04 03-2.01.AN04 LookUp Table String= ‘Date Basis’ LookUp Table Code= ‘OLI_LU_DATEBASIS’

Type Boolean 0=False 1=True String

Description Indicates if advance commissions may be accepted on this product, or with the distributor if associated with DistributionAgreement. This element is a key to the Interest Rate Variation XTbML.

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


Page 95


XML Element Name

Type

Description

< 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: String See the description at the beginning of this chapter for Producer id= “ ” usage & meaning.

String


String



Page 96


XML Element Name

Type

Description

Object The QualifiedPlanEntity object is used to define the allowable types of plans within a product as they apply to entity relationships. Choice Allowable or permitted plan types. Definitions of US-based Collection plan type can be found on www.irs.gov. LookUp Table String= ‘Qualified Plan Type’

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)

LookUp Table Code= ‘OLI_LU_QUALPLAN’

LookUp Table String= ‘Account Designation’ LookUpTableCode= ‘OLI_LU_ACCTDES’

Choice Collection

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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.


Page 97


XML Element Name

Type

Description

* 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: String See the description at the beginning of this chapter for RatingAgencyInfo id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. TypeCode Name of the rating agency assigning the Rating Value. Nationally Recognized Statistical Rating Organizations LookUp Table String= ‘Rating Agency Type Code Translation 1 = Standard & Poors LookUp Table Code= 2 = A.M. Best ‘OLI_LU_RATINGSRC 3 = Moody’s Investor Service 4 = Fitch, Inc. 5 = Weiss Ratings, Inc. 6 = Dominion Bond Rating Service, LTD String The rating (A++, A, B, etc) assigned to the carrier by the rating agency. String Descriptive name for the RatingValue, such as ‘Very Good.’ Date Effective date of the rating. Date Expiration date of the rating.


Page 98


XML Element Name

Type

Description

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 () and feature options (). Attributes: String See the description at the beginning of this chapter for RateVariation id= “ ” usage & meaning. String See the description at the beginning of this chapter for usage & meaning. String See the description at the beginning of this chapter for usage & meaning. TypeCode Identifies type of rate being described.


Type Code Translation 5 = Declared 6 = Bonus 7 = Guaranteed 8 = Guaranteed Lifetime 9 = Growth

‘Rate

LookUp Table Code= ‘OLI_LU_RATETYPE’

String

Integer

TypeCode


Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. This element acts as a pointer/link to a specific InvestProduct aggregate thus providing a mechanism for defining alternate rates for an investment. 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). Type of duration applicable to the rate being described in XTbML??.

‘Payment Type Code Translation 1 = Years (Annually) 4 = Months (Monthly)


String

String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Unique Identifier for the XTbML table used to store interest rates. This along with ProviderDomain provides a unique key for the table. The domain name of the provider. This along with TableIdentity provides a unique key for the table.


Page 99


XML Element Name

Type

Description

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 and objects. If the object is not present, it implies all funds which are available to the product via 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 . If multiple alternate rates are available for SourceInvestProduct, the object repeats for each allowable RateVariationKey for that investment. String Lists the carrier code from to define the managing firm. String Indicates a from , which can be selected as a destination fund with this feature option. This combination must be present in and . * 04-1.01.AN246 String Minimum amount. *

String

Maximum amount.

04-1.01.246

Percentage

Minimum percentage.

* 04-1.01.246

Percentage

Maximum percentage.

*

04-1.01.AN246


Page 100


XML Element Name

Type

Description

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: String See the description at the beginning of this chapter for SurrenderChargeSchedule id= “ ” usage & meaning.

String


String


LookUp Table String= ‘Surrender Charge Type’

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

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

TypeCode ‘Rate

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.


Page 101


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


Page 102

Chapter Five – Transmitting 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:

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.


Page 103

Chapter Six – XTbML Spec. for a PPfA

XTbML Element Name

Type

Description

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


Page 104


XTbML Element Name

Type

Description

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.


Page 105


XTbML Element Name

Type

Description

Object Identifies a dimension in the table values as defined in the AxisDef. Attribute: Integer A sequence defined by whatever the Axis is intended to order the V values. This value must be numeric.
Date Date used to identify the effective date value of an Axis, Key or Value row. ??? ???

Integer

Dimension or value. Commission rates are expressed as a decimal/percentage. That is, 3% is represented as 3.0..


Page 106


XTbML Element Name

Type

Description

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

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

‘Scale Type’ LookUp Table Code= ‘OLI_LU_SCALETYPE’

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. LookUp Table String= Sub Type’

TypeCode

Further details of the semantic concept represented by the axis.

‘Scale 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

LookUp Table Code= ‘OLI_LU_SCALESUBTYPE’


String String

Integer

Short description of the axis. Used to control the ordering of AxisDefs and KeyDefs. Sequencing should start with "1". Minimum value for the dimension of the table.


Page 107


XTbML Element Name

Integer

TypeCode


Type Integer

Description Maximum value for the dimension of the table. Minimum date for the dimension of the table. Maximum date for the dimension of the table. Identifies the increment used between each of the values in this dimension. 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

‘Payment

LookUp Table Code= ‘OLI_LU_PAYMODE


Boolean 0 = False 1 = True

TypeCode


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. Indicates the type of banding for rates.

‘Banding Type Code Translation

LookUp Table Code= ‘OLI_LU_BANDTYPE’

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

LookUp Table String= ‘Age Calculation Method’

TypeCode

3 = Banded with a Marginal Break. E.g. 5% on premium up to $100,000; 4% on premium in excess of $100,000 Indicates the algorithm used to determine the contract entity upon which commission breakpoints are determined. Type Code Translation 2 = Age Last Birthday


Page 108


XTbML Element Name LookUp Table Code= ‘OLI_LU_AGECALCMETH’

Type

Description 3 = Age Nearest in days

String String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Two options – beginning of period, end of period. When used under AxisDef, lists the values expected in the related XTbML Table.


Page 109


XTbML Element Name

Type

Description

Object Contains information about the content of the table data including name, supplier, and identification. 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.

String

String

String String String

TypeCode

Not used in Transmittal Transaction. Unique Identifier for the table. This along with the ProviderDomain creates a persistent unique key for the table. The domain name of the provider. This along with the TableIdentity creates a persistent unique key for the table. Name of the provider of the table. Location where the values of the table are published. Reference to the published document, which contains the table. Identifies the type of information in the table.

LookUp Table String= ‘Content Type’

Type Code Translation 53 = Commission Rates

LookUp Table Code= ‘OLI_LU_CONTENTTYPE’

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

Date String

XTbML Element Name

Name as defined by the table supplier. Freeform description of the contents of the table or sub-table being included. Date that aggregate is initially effective. Miscellaneous information regarding the information that is within the file itself.

Type

Description


Page 110


XTbML Element Name

Type

Description

Object Identifies a dimension in the table values as defined in the KeyDef. Integer Dimension or value.


Page 111


XTbML Element Name

Type

Description

Object Contains the definition of non-ordered dimensions of a table such as type codes, strings and codes. TypeCode The type of key defined LookUp Table String= ‘Key Type’ LookUp TableCode= ‘OLI_LU_KEYTYPE’ (04-1.01.03.09)

Type Code Translation 1 = Key is a String 2 = Key is a Type Code

TypeCode Lookup Variants TypeCode

LookUp Table String= ‘Key Sub Type’

The typecode set from which the Key's EnumeratedTypecodeValues will be drawn. The place in the model from which the values in EnumeratedStringValues are drawn. Type Code Translation

LookUp TableCode= ‘OLI_LU_KEYSUBTYPE’ 20 = Interest Rate Class 21 = Product Code: 22 = FeatureOptProduct 23 = InvestProduct 24 = InvestProductInfo 25 = PolicyProduct 26 = PolicyProductInfo

LookUp Table String= ‘Key Sub Class Type’

TypeCode

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. 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

LookUp TableCode= ‘OLI_LU_KEYSUBCLASSTYPE’

1 = FeatureCode


Page 112


XTbML Element Name

Type String String String

Integer

Enumerate d

String

Description Provides the actual FeatureCode value. ??? The name of the custom property. Used to control the ordering of AxisDefs and KeyDefs. Sequencing should start with "1". 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"> 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"> 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">


Page 113


XTbML Element Name

Type

Description

Object Contains information on how to interpret the values in the table. 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.


TypeCode

Type Code Translation 0 = Boolean 1 = Integer 2 = Long 3 = Short 4 = Double 5 = Currency 6 = Decimal 7 = Date 8 = String

‘Data

LookUp Table Code= ‘OLI_LU_DATATYPE’

TypeCode


LookUp Table String= LookUp Table Code= ‘OLI_LU_NATION’

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


Example: ‘3’ would indicate the numbers are stated in thousands. If scaling does not apply, 0 may be sent to indicate no scaling. Represents the type of data presented in the table.

TypeCode ‘Nation’

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

TypeCode String

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. The jurisdiction(s) to which rates apply. Freeform description of the contents of the table or sub-table being included.


Page 114


XTbML Element Name

Type

Description

Object Contains information about the content of the table data including name, supplier and identification. 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.

String

Not used in Transmittal Transaction. Unique Identifier for the table. This along with the ProviderDomain creates a persistent unique key for the table.


Page 115


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 level object element on down, including , , 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 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: [all the product profile details] Following are descriptions of each element. TX Life Wrapper Object Object

Descriptions This object contains the information related to the user This object contains the information related to the message/transaction itself


Page 116

Chapter Seven – Transmitting PPfA

XML Element Name

Type

Description

Object This object defines the transaction/message information about the user and the system that is sending the message String User Login name into receiving system, if applicable. Conditional part of key - either UserLoginName and UserPswd or UserSessionKey constitutes a valid login. Date Date that User makes request. String User Password, if applicable. Conditional part of key either UserLoginName and UserPswd or UserSessionKey constitutes a valid login. String Authentication key, issued previously based on password. Conditional part of key - either UserLoginName and UserPswd or UserSessionKey constitutes a valid login.


Attribute

LookUp Table String= ‘Persistence of Key Code’ LookUp Table Code= ‘PERSISTKEY’

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


Page 117


XML Element Name

Type

Description

Object This object identifies the application creating this transaction of the creator of the Product Profile. String Name of submitting organization. Sender/creator of Product Profile name i.e. Carrier. 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. String Client application version. Version of system creating product profile.


Page 118


XML Element Name

Type

Description

Object This object identifies the application creating this transaction of the third party sending the Product Profile. String Name of third party, if there is one, sending or transmitting this message.

String

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. Version of system creating product profile.


Page 119


XML Element Name

Type

Description

Object This object defines the information about this particular message/transaction. Contains elements needed to process a request. 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. 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. LookUp Table String= ‘Transaction Type Code Translation Type’ 201 = Policy Product Request LookUp Table Code= 1201 = Policy Product Transmittal ‘OLI_LU_TRANS_TYPE_CODES’ Note: This is a partial list from the current ACORD spec. Please see current spec. for additional 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.

Date

Date and time when this file or feed was created.

LookUp Table String= ‘Transaction Sub Type’ LookUp Table Code= ‘OLI_LU_TRANS_SUBTYPE_COD ES’

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: 199905-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.

Time

ACORD database defines as the date the file was transmitted on a Request or the server date the transaction was processed on a Response. Time when this file or feed was created.


Page 120


XML Element Name

Type

TypeCode

LookUp Table String= ‘Transaction Mode’ LookUp Table Code= ‘OLI_LU_TRANS_MODE_CODES’

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

Boolean 1 = True Boolean 0 = False 1 = True

Note: This is a partial list from the current ACORD spec. Please see current spec. for additional codes. Indicates if a response is desired or necessary. For a transmittal, always set to ‘1’ for 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: Lincoln National Life Annuity Profile App Generator 1.24c 938749384753ea765c87-876432 Product Inquiry Transmittal 2002-05-31T13:47:53-05:00 13:20:10 TRUE …


Page 121 Chapter Seven – Transmitting PPfA

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] UserAuthRequest [0.1] VendorName[1] AppName[0..1] AppVer[0..1] UserLoginName[0..1] UserDate[1] UserTime[1] CryptType[0..1] Pswd[0..1] CryptPswd[0..1] UserSessionKey[0..1]

ProxyVendor [0.*] VendorName[1] AppName[0..1] AppVer[0..1]

TXLifeRequest [1]

(SEE NEXT DIAGRAM) OLifE [1]

(SEE NEXT DIAGRAM) 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!


Page 122

Diagram 1A

Diagram IB: TXLife OLifE Overview


Page 123 Diagram 1B

Diagram II: InvestProduct


Page 124

Diagram II

Diagram III: PolicyProduct


Page 125

Diagram III

Diagram IV: AnnuityProduct


Page 126

Diagram IV

Diagram V: Ownership


Page 127

Diagram V

Diagram VI: Commission


Page 128

Diagram VI

Diagram VII: XTbML – Commission Profile for Annuity

XTbML

ContentClassification TableIdentity : String TableIdentity : String 1 VendorName : String ContentType : Integer

KeyedValues 0..n

0..n Table 1 1 MetaData TableSubDescription : String ScalingFactor : Integer DataType : Integer CurrencyCode : Integer Nation : Integer Jurisdiction

Values

0..n

0..n Key V t : Integer dt : Date

0..n

Axis V t : Integer dt : Date 0..n

0..n 0..n Jurisdiction onCC

0..n Enumerated Values

0..n KeyDef KeyType : Integer KeyName : String

0..n EnumeratedTyp eCodeValues

AxisDef ScaleType : Integer ScaleSubType : Integer AxisName : String MinScaleValue : Double MaxScaleValue : Double Increment : Double Mode : Integer Continuous : Boolean


Page 129

Diagram VII

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. {elements} {elements} {elements} 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.


Page 130

Appendix B

Request Please send me an Annuity Product of type code “1”. Notice, I do not know the ProductCode. 767


Page 131

Appendix B

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. 767 SP01

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. 767 SP01 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.


Page 132

Appendix B

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. 767 SP01

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. PetsAge X 3 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.


Page 133

Appendix B

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. Rover Dalmatian 3 Happy Hounds 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. Male 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.


Page 134

Appendix B

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. © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 135

Appendix C

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


Page 136

Appendix C

•

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


Page 137

Appendix C

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. Existing - uses OLI_LU_FINACTTYPE New – collection of statuses for which the aggregate applies Existing – uses OLI_LU_POLSTAT First date for which this aggregate applies to the transaction type Last date for which this aggregate applies to the transaction type First contract issue date for which this aggregate applies to the transaction type Last contract issue date for which this aggregate applies to the transaction type Provides information about Features intrinsic and extrinsic to this transaction type Intrinsic | Extrinsic Foreign key to FeatureProduct.FeatureCode 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. © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 138

Appendix C

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. © 2001-2009 ACORD CORPORATION – ALL RIGHTS RESERVED. ACORD LAH PPFA IMPLEMENTATION GUIDE – V2.2 – JAN. 2009

Page 139

Appendix C

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.


Page 140

Appendix C

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


Page 141

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


Page 142

Index

REVISION HISTORY Version

Date

Description of Change

2.2

Jan. 2009

2.11 v2.1 Final

Oct. 2006

2.11 v2.0 Final

Jan. 2005

2.11 v1.0

Oct. 2004

*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. ACORD's Terms and Conditions of Use have been updated. This is a documentation change only. No content changes have been made. Guide Release as Final for the 2.11 Life Specification and publication to the ACORD Web site. Document update for the 2.11 Life Specification Release.


Page 143

Revision History

Report "ACORD LAH PPfA Implementation Guide v2.2 Jan 2009"

Your name

Email

Reason

Description

Copyright © 2025 IDOC.TIPS. All rights reserved.
About Us | Privacy Policy | Terms of Service | Copyright | Contact Us | Cookie Policy

Sign In

Email

Password

Remember me Forgot password?

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close

ACORD LAH PPfA Implementation Guide v2.2 Jan 2009

Recommend Documents