AFFirm Annuities Product Guide 8-21 including the many riders and features available with these...

Copyright © 2014 iPipeline All Rights Reserved. No portion of this document may be reproduced

without the express written permission of iPipeline

AFFIRM for Annuities

Product Guide

Document Date: 5/21/2015 Print Date: 5/21/2015

Copyright © 2014 iPipeline

2

Table of Contents 1. INTRODUCTION .......................................................................................................................... 4

1.1. ABOUT THIS DOCUMENT ........................................................................................................ 4 1.2. INTENDED AUDIENCE .............................................................................................................. 4

2. AFFIRM BUSINESS OVERVIEW ................................................................................................ 5

3. AFFIRM OVERVIEW ................................................................................................................... 7

3.1. AFFIRM INFORMATION FLOW ................................................................................................ 7 3.1.1. Information Consumed by AFFIRM for Order Entry ................................................... 8 3.1.2. Information Generated by AFFIRM ........................................................................... 10

3.2. AFFIRM PHYSICAL COMPONENTS ........................................................................................ 10 3.2.1. Overview ................................................................................................................... 10 3.2.2. Databases ................................................................................................................. 12 3.2.3. FMS Servers ............................................................................................................. 12 3.2.4. Web Servers ............................................................................................................. 13

3.3. AFFIRM SOFTWARE ORGANIZATION .................................................................................... 14 3.4. AFFIRM USER ROLES ......................................................................................................... 17 3.5. THE ADMSERVER MACRO LANGUAGE .................................................................................. 18 3.6. AFFIRM REGIONS AND ROUTING ......................................................................................... 18 3.7. AFFIRM WORKFLOW .......................................................................................................... 22

4. USER ACCESS OF AFFIRM ..................................................................................................... 26

4.1. ACCESS METHODS............................................................................................................... 26 4.1.1. ADMServer Login ...................................................................................................... 26 4.1.2. Single Sign-On .......................................................................................................... 27 4.1.3. Gateway Patterns ..................................................................................................... 30

5. AFFIRM OPERATION BY MODULE......................................................................................... 32

5.1. AFFIRM PRODUCT MODULE ................................................................................................ 32 5.1.1. Overview ................................................................................................................... 32 5.1.2. Product Profile Administrator (PPA) ......................................................................... 33 5.1.3. Product Manager Application .................................................................................... 33 5.1.4. Distributor Rules Application ..................................................................................... 34 5.1.5. The Composite Product Profile ................................................................................. 36 5.1.6. Test Manager Application ......................................................................................... 40 5.1.7. Cut-Down Products ................................................................................................... 40

5.2. AFFIRM FORMS MODULE .................................................................................................... 41 5.2.1. Overview ................................................................................................................... 41 5.2.2. Forms Management Application ............................................................................... 42 5.2.3. Forms Generation during Order Entry ...................................................................... 44

5.3. AFFIRM HIERARCHY MODULE ............................................................................................. 45 5.3.1. Overview ................................................................................................................... 45 5.3.2. Hierarchy Management Application .......................................................................... 46

5.4. AFFIRM ORDER MODULE .................................................................................................... 50 5.4.1. Overview ................................................................................................................... 50 5.4.2. Order Dashboard ...................................................................................................... 51 5.4.3. Order Entry Business Rules ..................................................................................... 53 5.4.4. Initial Purchase Order Entry ...................................................................................... 56 5.4.5. Subsequent Payment Order Entry ............................................................................ 57 5.4.6. Order Submission ..................................................................................................... 59

5.5. THE AFFIRM APPROVAL MODULE ........................................................................................ 59 5.5.1. Overview ................................................................................................................... 59 5.5.2. Approval Queues Configuration Application ............................................................. 62


3

5.5.3. Approval Queues Application ................................................................................... 65 5.6. AFFIRM AUDIT SUPPORT .................................................................................................... 70 5.7. AFFIRM ANNUITY ARCHIVE ................................................................................................. 71

5.7.1. Industry Background & Solution Overview ............................................................... 71 5.7.2. Compliance Management Overview ......................................................................... 71


4

1. Introduction

1.1. About This Document

This Product Guide provides an overview of the AFFIRM for Annuities™ Order Entry & Compliance system. It is intended to provide an overview of the entire system, illustrating the interaction between the various applications that make up the AFFIRM annuity lifecycle. It is intended as a primer to the entire system, to be used in conjunction with the AFFIRM application User Guides.

1.2. Intended Audience

This document is intended for AFFIRM Carrier and Distributor project management, business analytics, training, administrative, help desk/support and technical staff. This document is written to be understandable to both technical and business readers; wherever possible, technical concepts are described in non-technical language.


5

2. AFFIRM Business Overview

AFFIRM for Annuities™ was created in response to industry demand for an annuity order entry and compliance solution that would meet the following business requirements: o An order entry system in to enable sales of variable and fixed deferred

annuities, including the many riders and features available with these products. o Support for straight-through-processing (STP) to reduce costs, increase

revenue, & improve customer-servicing capabilities. o Support for integration with Carrier, Distributor, and third party systems for

single sign on (SSO), licensing & appointment checks, status messaging, order submission, and forms submission.

o A system with the flexibility to support variations in Carrier and Distributor

business processes and approaches to compliance. o Automatic safeguards to ensure that each annuity sale is suitable, auditable,

complete and “In Good Order”. o A standards-based solution, with emphasis on the Depository Trust and

Clearing Corporation (DTCC) and ACORD standards. o A solution that allows Carriers and Distributors to manage their own business

information, such as product and order form definitions. Because AFFIRM™ allows an unprecedented level of configuration and control, Distributors can now define annuity order business rules specific to their organizations and configure user workflow, warnings, and error messages that suit their needs. AFFIRM™ integrates with the Distributor’s back office systems and operates seamlessly within the enterprise. A highly flexible “single sign-on” approach provides secure access to only those functions necessary to a given User. AFFIRM™ can also be integrated to consume “seed data” provided by Distributor back office systems to reduce data entry and improve quality. This data can pre-populate the order, including forms required for signature, thus saving time and ensuring accurate data entry. AFFIRM™ electronically consumes industry-standard annuity product profiles (PPfA), which eliminates the Distributor’s maintenance costs. AFFIRM™ is compliant with the standards of the Association for Cooperative Operations Research and Development (ACORD), and supports ACORD or proprietary forms,


6

configurable business rules, and file formats including ACORD messages and Depository Trust and Clearing Corporation (DTCC).


7

3. AFFIRM Overview

This section provides an overview of the organization of AFFIRM, along with key concepts that will be important in understanding system operation.

3.1. AFFIRM Information Flow

Before delving into a description of AFFIRM organization, it is important to understand the general flow of information that the system is designed to manage.

Blue Frog Carrier, Distributor, Third-Party Provider

Distributor

Carrier

Product Profile(ACORD TX 1203/

PPfA)

Carrier Forms, Form Applicability Rules, Form Maps

Carrier Questions

Agent License, Appointment, Registration Information

Distributor Product Rules

Distributor Forms, Form Applicability Rules, Form Maps

Distributor Questions

Distributor-Specific Order Entry Rules

AFFIRM-Standard Order Entry Rules

AFFIRM Annuity Order Entry

Electronic Annuity Order (DTCC APP or ACORD NBfA)

Order Entry Forms (Paper)

Order Entry Forms (Electronic)

Order Status Information

Distributor Order “Seed Data”

Distributor Configuration

Values

To Distributor

To Carrier or Distributor

To Carrier

To Carrier

Annuity Order Information

Order Approval Information

AFFIRM ReportsTo Carrier or Distributor

Approval Queue Configuration

Figure 1: AFFIRM Information Flow

In the simplest terms, the AFFIRM Annuity Order Entry application consumes information that is introduced by both the Carrier and Distributor in order to assure that the annuity order entry process generates “in good order” (IGO) orders, as opposed to “not in good order” (NIGO) annuity orders. The diagram below illustrates the general flow of information.


8

3.1.1. Information Consumed by AFFIRM for Order Entry

3.1.1.1. Industry General Information to by Consumed by AFFIRM

The information below is introduced by iPipeline prior to order-entry: o AFFIRM-Standard Order Entry Rules – AFFIRM comes pre-loaded with

hundreds of business rules that are validated during order entry to ensure IGO orders. Some of these rules are validated against the rules set out in the Product Profile that is introduced and maintained for each product by the Carrier. A simple example of a business rule is the requirement that no more annuitants are included on an order than allowed for the given product.

3.1.1.2. Carrier-provided Information to be Consumed by AFFIRM

The information below is provided by the Carrier prior to order-entry: o Product Profile – A detailed description of each annuity product, including

distribution agreement, jurisdictions for sale, subaccounts, rules for sale (minimum owner age, maximum owner age, etc,) and features/riders. AFFIRM uses the ACORD standard transaction #1203 XML message for product description, also known as the Product Profile for Annuity (PPfA).

o Carrier Forms – The Carrier forms (paperwork) that is required to accompany

annuity orders, especially the paperwork requiring wet signature. These forms are introduced to AFFIRM as fillable PDF documents. Along with forms, the Carrier loads business rules to define the rules for which a form is applicable and form mapping to define order data that is to be populated into the form’s fillable fields.

o Carrier Questions – The Carrier may also introduce questions to be asked

during the order entry process, along with rules for which the questions are applicable.

3.1.1.3. Distributor Information to be Consumed by AFFIRM

The information below is provided by the Distributor prior to order-entry: o Distributor Product Rules – Each Carrier Product Profile includes rules for

sale (minimum age, maximum age, allowed types of funding source, etc.). AFFIRM also allows Distributors to introduce rules that restrict (but do not loosen) the rules set out by Carriers in the Product Profile. These rules are applied to all products from all Carriers (i.e. if a Distributor introduces a rule to


9

limit the maximum owner age to 90, then it applies to all products from all Carriers).

o Distributor Forms – Like Carriers, the Distributor may introduce forms, form

applicability rules, and form mapping. o Distributor Questions – Like Carriers, the Distributor may introduce questions

and question applicability rules. o Distributor-Specific Order Entry Rules – In addition to the standard set of

order entry business rules that come pre-loaded with AFFIRM, a Distributor may introduce additional rules particular to their business & compliance requirements.

o Distributor Order Seed Data – Some Distributors choose to pass some order

data from Distributor systems to AFFIRM at the beginning of order entry. This “seed data” is typically passed to reduce the burden of manual order entry on the Agent, and may include information about the brokerage account, the owner, the Agent (and/or sales team), and other data that is available prior to order entry.

o Distributor Configuration Values – Some aspects of AFFIRM behavior during

order entry are controlled by configuration values that are set by iPipeline during AFFIRM system setup. Examples include whether the Agent is allowed to edit or delete Agent/team information during order entry, and whether or not to use AFFIRM approval queues.

o Approval Queue Configuration – AFFIRM provides a mechanism to allow

Distributor to configure any number of approval queues, sequence the queues, and set rules for which each approval queue is applicable.

3.1.1.4. Third-Party Information to be Consumed by AFFIRM

o Agent License, Appointment, and Registration Information - AFFIRM

makes a License and Appointment check during order entry. This check occurs after the jurisdiction and type of product have been selected. The check is typically made via a Web service request to the Distributor, or to a third party provider such as Kaplan or RegEd.

3.1.1.5. Information Introduced During Order Entry and Approval

o Annuity Order Information – During order entry, the Agent provides all

required information that was not passed by the Distributor as seed data. This includes Agent/Team information, product selection, funding information,


10

selection of subaccounts, selection of features/riders, and answering Carrier and Distributor questions. The information above, provided by the Carrier and Distributor during order entry, is used by AFFIRM to validate the information as the Agent enters it. If the Agent enters invalid information, AFFIRM will stop the order from proceeding and communicate the error to the Agent.

o Order Approval Information – After the Agent has completed order entry and

printed the order forms, they submit the order for Approval. The order is then made available for review by one or more Approvers in one or more Approval Queues, as configured by the Distributor. The Approver has the option to Approver, reject, return to the Agent for additional information, or return to the Agent for rework. The Approver may also attach notes to the order.

3.1.2. Information Generated by AFFIRM

o Electronic Annuity Order – The primary purpose of AFFIRM is to generate the electronic annuity order. The order is typically generated in DTCC APP format, but may be generated in other formats, such as the ACORD Transaction #103, which is also known as the New Business for Annuity (NBfA) XML message.

o Order Forms (paper) – In addition to the electronic annuity order, Carriers and

Distributors typically also require some hardcopy paperwork. AFFIRM provides for this paperwork by allowing the Agent to save and/or print the applicable forms for an order as PDF documents.

o Order Forms (electronic) – Some Carriers and Distributors also require that

forms be submitted electronically with the order. While DTCC does not yet support forms attached with an order in DTCC APP format, AFFIRM can still generate and transmit forms, typically as PDF files embedded in the ACORD TX 103 (NBfA) message.

o Order Status Information – AFFIRM has the capability to send status

messages to the Distributor during the order entry and approval process. o Reports – Because each Carrier and Distributor typically requires their own

specific reports, iPipeline has taken the strategy of providing a limited number of basic AFFIRM reports, and providing the raw data for Carriers and Distributors to run their own reports. Please see AFFRM and Compliance Database report specifications under separate cover.

3.2. AFFIRM Physical Components

3.2.1. Overview

AFFIRM is typically offered as a hosted solution, with the AFFIRM servers residing in iPipeline data centers, but AFFIRM can also be installed onsite at a Distributor location. AFFIRM is an n-tier application, meaning that the entire system can be


11

run from a single server, or distributed across a number of servers. In practice, a number of servers are used to meet security, capacity, availability, and scalability requirements. The following general components are a part of any AFFIRM implementation.

Figure 2: AFFIRM Infrastructure

A typical infrastructure implementation will include a protected sub-network, which is protected by a firewall and not directly accessible to the outside world. The protected network houses the database and FMS server. A DMZ sub-network is typically also implemented to house Web servers, which may be load balanced for failover and load management. End users typically connect to AFFIRM Web application via a Web browser (Internet Explorer 6.0 or higher is required) over the Internet using Secure-Socket Layer (SSL) HTTPS. Telecommunication links with the Distributor back office or third parties, including the DTCC, may also be implemented for Licensing and Appointment checks, seed data transmission, and the transmission of other messages, such as status messages and electronic annuity orders.


12

3.2.2. Databases

AFFIRM uses three primary types of databases: Business, Admin, and Metadata. Databases can be subdivided into Subscriptions, and ADMServer controls which users and applications can access data in which Subscription. The Subscription concept will be discussed later in the sections pertaining to AFFIRM Regions (Development, Pilot, and Production) and product/form routing. o Business Database - Each AFFIRM Carrier and Distributor has a business

database (or a Subscription within a physical database) where all business data is stored. Business data includes product profiles, form definitions, form maps, approval queue configuration, Distributor product rules, and annuity orders.

o Admin Database – Each AFFIRM site has a single Admin database. In the

iPipeline data centers, a single Admin database is shared by all hosted Carriers and Distributors. The admin database contains information on user roles and access, database subscriptions, permissions, and the configuration information for processors and events, which are used by the Feed Management Server (FMS—discussed later in this section) to control the configuration and timing of some units of work done by the AFFIRM system.

o Metadata Database – The Metadata database contains “data about data”. This

includes descriptions of the data models used by AFFIRM (ACORD, DTCC, proprietary), contexts (subsets of a data model selected for a given purpose), macro-language business rules, and suitability questions. In general, information that is kept in the metadata database would have traditionally been hard-coded into the software. By storing this information in the Metadata database, iPipeline is able to increase flexibility and reduce implementation timelines by reducing the amount of work that is done during software development cycles.

3.2.3. FMS Servers

Feed Management Servers (FMS) are the “workhorse” of the AFFIRM implementation. FMS manages all batch processing through Processors, which maybe organized into scheduled or triggered Events. In general terms, processing work that can be done in batch or in the background is offloaded from the Web servers to the FMS servers. This allows iPipeline the ability to lighten the workload on Web servers, which can then be focused on user-facing tasks. Examples of work performed by FMS include: o Seed Data Processing – During single sign-on (SSO) for order entry, AFFIRM

may be passed “seed data” for an order to lighten the data-entry load on the Agent. This seed data may be passed from the Distributor’s back office, or AFFIRM may call one or more systems in the Distributor back office to request the seed data. The seed data must then be collected into a single standard


13

format (ACORD NBfA) and saved in the Distributor business database prior to the initiation of an order entry session.

o Product and Form Routing – After Carriers introduce product and form

information, it must be routed to the Distributors with whom they do business. The process of sending this data out from the Carrier business database and loading it into the Distributor business database is processor-intensive, and thus performed by FMS.

o Inbound/Outbound messaging – AFFIRM may send/receive messages

to/from other systems during normal operation. Examples of messages sent include the DTCC APP (sent to DTCC), order status messages (sent to Distributor), and order forms (sent to Distributor or Carrier).

o Forms Generation – During order entry, AFFIRM decides which Carrier and

Distributor forms to generate for each order. After selecting the correct forms, AFFIRM populates the PDF for the form from data in the business database. PDF generation is highly processor-intensive, so therefore run on the FMS servers.

o The Application of Business Rules – Each time that any data, including data

entered by a user via the user-interface, data uploaded to the system, or data received as a message or response to a system request is stored in the business database, it must first be vetted against ADMServer macro-language business rules, which are stored in the metadata database. The application of business rules, which are sometimes complex is typically run on the FMS servers.

3.2.4. Web Servers

Web servers host the user-facing Web applications that Distributor BA’s, Carrier BA’s, Agents, Approvers, and other users see when they interact with AFFIRM. Web servers also host the Distributor Gateway, which works as the first point of contact during single sign-on (SSO). The Gateway interacts with the seed data processor to gather and format seed data, and also routes the user to the correct application based on !UserRole and !UserAction parameters passed from the Distributor during SSO. Finally, the Web servers host Web services, which are implemented to answer requests made by other systems, typically Distributor systems. An example of an AFFIRM Web service is one that cancels when the Distributor requests that the order is cancelled.


14

3.3. AFFIRM Software Organization

AFFIRM is comprised of number of Web Applications that are organized into six Modules. Each module is formed around a business function. o Each module has a Delegate that acts as the single point of contact for all other

modules. o Each delegate expects certain pre-defined requests and returns pre-defined

responses; each request/response pair is considered a Method. As an example, the Forms module delegate has a “PopulateForms” method. During order entry, the Order module calls the PopulateForms method, passing the order data, and expecting back the order data with the populated forms for that order.

o If any change is made behind the scenes to any module, the other modules can

continue to operate using the same delegate, unaware of the change. This gives iPipeline the opportunity to make behind-the-scenes adjustments to any module without affecting other modules, so long as the methods remain unchanged.

o Both Carriers & Distributors use some modules, such as forms and order entry.

In these cases, ALL users see EXACTLY the same software. The only difference is in configuration.

The current AFFIRM modules, and the Web applications included in each is illustrated and tabulated below.


15

Figure 3: AFFIRM Modules and Delegates


16

Module Application Used By DescriptionBlue Frog

Abbreviation

Product Profile Administrator (PPA)

Carrier BA

This is not an AFFIRM application, but is sold as a separate and optional Blue Frog product. It is used by a Carrier Business Analyst to introduce and manage annuity product descriptions, and generates ACORD-Standard Product Profile for Annuity (PPfA) messages for consumption by an annuity order entry system.

IPPA

Product Manager Application Carrier BA

AFFIRM application used by Carrier Business Analyst to upload and manage ACORD-Standard Product Profile for Annuity (PPfA) messages. PPfA messages may be created by the Blue Frog Product Profile Administrator application, or by a third-party tool. This tool provides the Carrier BA with a

IPMR

Distributor Rules Application Distributor BA

AFFIRM application used by Distributor Business Analyst to introduce and manage distributor product rules. These are general (not product specific) rules that can be used to constrain carrier product rules for all carriers and products. These rules will override carrier rules set out in the PPfA. As an example, a distributor may wish to limit maximum owner age to 90 for all carriers and products.

IDRA

Test Manager Application Distributor BA

AFFIRM application used by Distributor Busines Analyst to manage Carrier and Distributor products and forms. The primary purpose of this application is to allow for the management products and forms through the AFFIRM Regions (Dev, Pilot, Production).

ITMR


Abbreviation

Forms ApplicationCarrier BA,

Distributor BA

AFFIRM Application used by Carrier and Distributor Business Analysts to introduce PDF fillable forms, form applicability rules, and form mappings to AFFIRM.

IFAP

Forms LibraryCarrier or Distributor

AFFIRM Application used by various AFFIRM users to search and view PDF fillable form templates.

IFLA


Abbreviation

Hierarchy ModuleHierarchy Management Application

Distributor User Admin

AFFIRM Application used by Distributor User Administrators to manage Agent and Approver Hierarchy. This is an optional application that is used primarily by distributors with limited or no single sign-on (SSO) integration.

IHMA


Abbreviation

Approval Queues Configuration Application

Distributor User Admin

AFFIRM Application used by Distributor User Administrator to configure Approval Queues. This means creating, naming, sequencing, and setting up applicability rules for Approval Queues.

IAQC

Approval Queues Application ApproverAFFIRM Application used by Approver to review and approve, send for rework, send for additional information, or reject an annuity order.

IAQA


Abbreviation

Annuity Order Entry Application

Agent AFFIRM application used for annuity order entry. IAOE

Subsequent Payment Order Entry Application

Agent AFFIRM application used for subsequent payment order entry. ISUB


Abbreviation

Licensing ModuleLicensing & Appointments Application

-

AFFIRM application used for Licensing and Appointment (L&A) inquiries to L&A data providers, such as Kaplan, RegEd, or the Distributor Back Office. The licensing module does not currently include a user interface.

ILNA


Abbreviation

Questions Management Application

Carrier BA, Distributor BA

Future application (pending change order 5949) that will allow Carriers and Distributors to manage their own order questions in much the same manner that they currently manage product and form information.

IQUE

Order Entry Rules Management Application

Carrier BA, Distributor BA

Future application (pending change order 5950) that will allow Carriers and Distributors to manage their own order entry rules in much the same manner that they currently manage product and form information.

IRMA

Order Entry UI and Help Text Management Application

Distributor BAFuture application (pending change order 7090) that will allow Distributors to manage their own order entry help text in much the same manner that they currently manage product and form information.

IOUI

Distributor Parameters Management Application

Distributor BAFuture application (pending change order 5951) that will allow Distributors to manage their own order entry help text in much the same manner that they currently manage product and form information.

IDPA


Abbreviation

N/AAudit Application (ADM Application)

C/DFuture application (pending change order 9638) that will allow AFFIRM administrative users to search and view AFFIRM audit information.

IAUD

N/A

Product Module

Forms Module

Approval Module

Order Module

Figure 4: AFFIRM Modules and Applications


17

3.4. AFFIRM User Roles

AFFIRM supports a set of pre-defined user roles; each user role is represented by an Actor in a use case. Each user role has access to a specific set of AFFIRM applications and a specific set of data. AFFIRM uses the Admin database to keep track of which users have access to which applications and which data subscriptions (subsections of data). In some cases (usually in high volume Distributor rules, such as Agents and Approvers) users access AFFIRM via single sign-on. In these cases, information about a single user is not stored by iPipeline. Instead, security/technology measures are taken to implement the Distributor as a trusted partner, and Distributor users are assigned to an AFFIRM user role to control access to applications and data. In other cases (usually low-volume Carrier and Distributor rules, such as Business Analysts (BA’s) and User Administrators), information on the individual AFFIRM user is stored in the AFFIRM Admin database. In these cases, application and data access privileges for each individual user are stored in the AFFIRM database, but the types of individual users are still limited to the pre-defined user roles. The diagram below illustrates the AFFIRM user roles, along with the applications and subset of data (subscription) that each can access. The AFFIRM User Roles are defined as follows. Table 1: AFFIRM User Roles

Carrier or Distributor Role Description Access To Application NoteForms Management ApplicationTest Management ApplicationDistributor Rules ApplicationOrder Entry DashboardOrder Entry (Initial Purchase)Order Entry (Subsequent Payment)Order Entry Dashboard Displays Orders for Agent & Team Members OnlyOrder Entry (Initial Purchase)Order Entry (Subsequent Payment)Forms LibraryOrder Entry Dashboard Displays Orders for Agents Superior in HierarchyOrder Entry (Initial Purchase)Order Entry (Subsequent Payment)Forms LibraryOrder Entry Dashboard Displays Orders for Agents Subordinate in HierarchyOrder Entry (Initial Purchase)Order Entry (Subsequent Payment)Forms Library

APROVER Approver (OSJ, etc.) Approval Queue ApplicationApproval Queue Configuration ApplicationHierarchy Management Application OptionalForms Management ApplicationProduct Management ApplicationOrder Entry DashboardOrder Entry (Initial Purchase)Order Entry (Subsequent Payment)Order Entry DashboardOrder Entry (Initial Purchase)Order Entry (Subsequent Payment)

BAPRODUCTION

Business Analyst

Business Analyst (Pilot Testing)

Agent (Rep, FA, etc.)

Agent Assistant

Agent Manager

User Administrator

Business Analyst



Distributor

Carrier

BA

BAPILOT

AGENT

AGENTASSISTANT

AGENTMANAGER

USERADMIN

BA

BAPILOT


18

3.5. The ADMServer Macro Language

ADMServer (and AFFIRM) was conceived with the notion that complex software products support the flexibility required to meet wide variations in customer requirements and short delivery timelines by reducing the amount of effort that is developer-centric, and increasing the amount of work that is business analyst-centric, thus moving work from technology staff to business staff. To this end, iPipeline implemented the ADMServer macro-language, an XPATH-based system for expressing business rules and data maps. Working with the macro-language requires a working knowledge of the underlying data model (ACORD in this case), as well as skills that lie on the technical end of the spectrum typically covered by business analysts. If you are comfortable with Excel formulas, then you can likely manage the macro language. The example below illustrates typical macro-language usage.

1. Business Analysts enter rules using any of a number of user-friendly AFFIRM applications (see IPPA, the Forms Module Application, etc below). These rules are entered using the macro language.

Macro-language Example:

Carrier Code: key('AnnuityOrder')/Policy/CarrierCode

2. The rules are stored as metadata schemas and pre-compiled by the system for better performance at runtime.

3. Rules that are too complex to be entered using the macro-language can be coded using C# or other languages. These are stored in processors and business objects.

4. At runtime, the system validates all data that is processed or loaded into a database through the data layer using the rules that were entered by the business analysts.

5. If data violates any rules, the exception is captured and either returned to the user or logged in the application log.

3.6. AFFIRM Regions and Routing

In the broadest terms, the AFFIRM system has two halves—a Carrier half and a Distributor half. The Carrier half is purposed with providing Carrier information for order entry, while the Distributor half is purposed with providing Distributor information required for order entry, the order entry process itself, and post order entry processes that include approval and various order entry outputs, such as the electronic order and order forms.


19

AFFIRM is also designed to provide business analysts with the tools that they need to perform tasks that were historically reserved for developers. Examples include the configuration of product profile data, configuration & mapping of forms, the management of business rules, and the management of suitability questions and the related business rules. Because a mistake made in entering a business rule can have the same ill affect as a mistake made in writing software, AFFIRM includes a mechanism to test the information that is introduced by business analysts before it is made available for order entry. It also includes a routing mechanism to share information entered in the Carrier applications with the Distributor applications. The diagram below shows how product, Distributor product rule, and form data is routed from Region to Region. Each Region is actually a Subscription, or logical partition between data in an AFFIRM database. As illustrated in a previous section, each user role has access to only specific subscriptions.

Figure 5: AFFIRM Regions and Routing

All routing follows these rules:


20

o Original Always in Dev Region – While it is easier to show products and forms moving from Dev to Pilot and then Pilot to Production in diagrams, the original is always kept in the Dev Region in reality. This approach borrows on the concept of software source control. Therefore, in reality, when we say that a product is moving form Pilot to Production, it is in reality moving from Dev to Production, and the status of the Product in the Dev Region is updated from “Dev” to “Production”.

o Versioning – AFFIRM automatically creates a new version (by date and time)

each time that a given version of a product or form is copied. Each time that a new version of a product or form is promoted into the Pilot or Production Region, all the previous version is automatically deactivated.

o Edit Only in Dev Region – Products and forms may be edited only in the

AFFIRM Dev Region. This is necessary to ensure that each version of a product or form has a unique set of characteristics.

o Routing by Distribution Agreement – Products are routed by the Distribution

Agreements set up in the Carrier Product Profile (PPfA). This means that so long as a Carrier has defined a distribution agreement with a Distributor, that AFFIRM will make the Carrier products available to that Distributor.

o Overnight Production Promotion – All product, Distributor product rule, and

form promotion into the Production Region occurs overnight. This ensures that product and forms do not change during the trading day.

o Auto-Promotion – After a Carrier promotes products or forms into Carrier

Production, they are made available to the Distributor for testing in the Distributor Pilot Region. In an effort to balance Carrier business requirements, Distributor workloads, and Distributor business requirements, AFFIRM follows the following auto-promotion logic for Carrier products and forms.

o Products are not auto-promoted from the Distributor Pilot Region to the

Distributor Production Region. o Forms are auto-promoted from the Distributor Pilot Region to the

Distributor Production Region. o Deactivation – If a Carrier or Distributor deactivates a product or form, then

ALL versions of that product or form are deactivated in ALL Carrier and Distributor Regions.

o Demotion – Distributors my demote products, but not forms from the Production

Region. When a product is demoted, it is made available in the Pilot Region for Pilot testing and re-promotion (if desired) to the Production Region. If a newer version of a demoted product is in the Pilot region at the time of a demotion, then the newer version remains and the older version is deactivated.


21

Form demotion is not supported because it conflicts with the form auto-promote rules set out above.

The tables below describe the step-by-step routing process for products, forms, and Distributor product rules. Table 2: Carrier Product and Form Routing

User Action AFFIRM Handling Timing

Upload Form Form saved in Carrier Dev Region Real Time

Promote Form to PilotForm made available for Carrier Pilot Testing in Carrier

Pilot RegionReal Time

Promote Form to Production

Form made available for Distributor Pilot Testing in Distributor Pilot Region. Also availble for testing in

Carrier Production Region. Forms are auto-promoted to Distributor Production Region.

Overnight

Copy Form Copy made in Carrier Dev Region Real Time


Upload Product Product saved in Carrier Dev Region Real Time

Promote Product to PilotProduct made available for Carrier Pilot Testing in Carrier

Pilot RegionReal Time

Promote Product to Production

Product made available for Distributor Pilot Testing in Distributor Pilot Region. Also availble for testing in Carrier Production Region. Products are not auto-

promoted to Distributor Production Region.

Overnight

Copy Product Copy made in Carrier Dev Region Real Time

Carrier Forms

Carrier Products


22

Table 3: Distributor Form and Product Rule Routing


Upload Form Form saved in Distributor Dev Region Real Time

Promote Form to PilotForm made available for Distributor Pilot Testing in

Distributor Pilot RegionReal Time

Promote Form to Production Form made available for Production order entry. Overnight

Copy Form Copy made in Distributor Dev Region Real Time


Upload Product Product Rule saved in Distributor Dev Region Real Time

Promote Product Rule to PilotProduct Rule made available for Distributor Pilot Testing

in Distributor Pilot RegionReal Time

Promote Product Rule to Production

Product Rule made available for Production order entry. Overnight

Copy Product Copy made in Distributor Dev Region Real Time

Distributor Forms

Distributor Product Rule Rules

3.7. AFFIRM Workflow

The following workflow ties the topics covered in this section together. It shows how the various AFFIRM user roles interact with the AFFIRM applications to provide the annuity order entry system with the information that it needs to generate IGO orders.

1. Carrier Configuration – Carrier uses browser-based applications to enter product information (using the ACORD standard), upload PDF form templates, enter form rules, map forms to order data, select suitability questions.


23

2. Carrier Testing – Carrier is provided with a test Order Entry platform so that they can test their products, forms, and suitability questions prior to transmission of this information to the Distributor

3. Carrier Data Transmission – Carrier transmits their configuration data to the Distributor system using any standard messaging protocol (SOAP, FTP, NDM, etc.)

4. Distributor Configuration – Distributor uses browser-based applications to enter Distributor product rules (using the ACORD standard), upload PDF form templates, enter form rules, map forms to order data, select suitability questions, configure approval queues, and enter information about Agent hierarchy, business hierarchy, sales teams, & approval teams.

5. Joint Testing – AFFIRM provides a Pilot order entry test environment that the Distributor makes available to the Carrier for joint testing of product information, forms generation, order entry & compliance system behavior, suitability questions, approval queues, business rules, etc. The Pilot system generates order messages, which can also be validated during Pilot testing.

6. User Management – Distributor uses the AFFIRM application to provision users via email. Users receive an email with a link to gain access to the system. When they access the system, they are presented with a challenge question that was configured by the Distributor. When they answer the question correctly, they are presented with login information and the option to change their password.

7. Order Entry & Compliance – The order entry & compliance process is shaped around gathering information to submit DTCC-standard and ACORD-standard orders. The system is comprised of a number of screens to gather data. The screens are highly data-driven and include reflexive questioning, so that an answer to a question in an earlier screen may alter behavior in screen flow or in later screen behavior. The system relies heavily on business rules as described above to validate the order as the user enters information, catching errors, and returning messages to the user as they work. The user navigates through the system by clicking “Next” or by clicking on the next of a series of tabs presented at the top of the screen. Since some screens must be completed before others, the system makes use of the ADMServer business rules support again to control which tabs are available to the user. The user may save an incomplete order at any time and return to it later by searching/viewing it in a “dashboard” that is displayed to the user when the log into the system. Because business rules may change during the time that an incomplete order is saved, the system automatically tests ALL business rules again on an order prior to submission.


24

Order entry is highly dependent upon business rules that were entered as part of the Carrier product configuration and transmitted to the Distributor as an ACORD-standard message. ADMServer provides a unique approach to applying Distributor rules, which may further restrict Carrier rules as defined in the product definition. The Distributor is provided with an online application that they user to enter their own ACORD-standard product definition, which is a subset of the Carrier rules. The AFFIRM system then automatically applies the Distributor rules to each Carrier product definition, creating a “composite” product definition that is used during the order entry & compliance process.

8. Forms Generation – After an order is submitted and validated, the system automatically selects the appropriate Carrier AND Distributor forms based on macro-language business rules entered during form configuration. The system then populates the PDF form templates loaded during form configuration with data from the order entry & compliance process, using the form mapping that was entered by a business analyst during the form configuration process. These rendered forms (PDF, HTML, text, etc.) forms are saved with the order and presented to the order entry user to review and print. AFFIRM maps forms directory to the ACORD model with not need for proprietary mapping. Finetre requires the use of their proprietary mapping language.

9. Approval – After forms generation, orders are automatically “tagged” by the AFFIRM system with approval queue requirements. Order Approvers then have access to review the orders in an approval queue and have the option to accept, reject, or send the orders to be reworked by the Agent. The approval queue automatically keeps an order history with the order, and allows Approvers and Agents to append notes to the order to communicate throughout the approval workflow.

10. Audit and Reports –The AFFIRM system provides the Distributor agency with built-in functionality to view audit logs and standard or customized reports.

11. Order Submission – After approval, the order is submitted to the Carrier (sometimes via an intermediary such as DTCC). ADMServer natively supports ACORD and DTCC order formats, and is configurable to support proprietary formats. ADMServer also includes native support to handler message not acknowledged (NACK) and reject messages from the receiving party.

The diagram below illustrates the various AFFIRM rules, how they introduce information to AFFIRM, and how information flows through AFFIRM.


25

Figure 6: AFFIRM Workflow


26

4. User Access of AFFIRM

The purpose of this section is to provide an overview of the mechanisms available for user access to AFFIRM. This section explains the concepts of ADMServer Login, Single Sign-On (SSO), seed data, tokens, filter criteria, AFFIRM Gateway, and !UserRole/UserAction.

4.1. Access Methods

There are two primary methods for accessing AFFIRM functionality, ADMServer Login and Single Sign-On. Most AFFIRM partners will choose to implement one or the other, but some may decide to implement ADMServer Login for some AFFIRM user roles and SSO for other user roles.

Note: Most AFFIRM Carriers are using ADMServer Login, while most Distributors are using either SSO, or a mix of SSO (Agents/Approvers) and ADMServer Login (BA’s, User Administrators).

4.1.1. ADMServer Login

ADMServer Login means that a user logs into AFFIRM using an ADMServer login screen. In this case, the user’s information must be stored and maintained in the ADMServer Admin database so that ADMServer can check the user’s credentials (UserID & Password) and provide the user with access to the correct functionality and data for their given user role and individual access rights. ADMServer login has the following Pros and Cons:

Pros

o Simplicity - No need for Distributor & iPipeline developers to write SSO software during AFFIRM implementation.

Cons

o Additional Login – User must log in to AFFIRM separately from other applications. This means another UserID and password to maintain and enter for each use.

o Maintenance - Requires that the Distributor manage user information in AFFIRM. This means additional maintenance to maintain this information manually. For a large number of users (example: Agents), this workload can become unmanageable.

o No Support for Approval Queue Permissions - AFFIRM does not support Approver queue permissions using ADMServer login—all Approvers have access to all queues. See additional information on Approval Queue permissions in the SSO section below.

o No Support Approval Queue and Dashboard Filtering - AFFIRM does not support queue or dashboard filtering using ADMServer login—all Approvers see


27

all orders that are in each queue, and all Agents see all orders for which they are a primary or additional Agent. See additional information on Approval Queue & Dashboard filtering in the SSO section below.

o No Support for Seed Data – AFFIRM does not support “seed data”, allowing the Distributor to pass order data such as owner name and brokerage account information to ease the order entry burden on the Agent when ADMServer Login is incorporated.

The diagram below illustrates the step-by-step process for AFFIRM Login.

Figure 7: ADMServer Login

4.1.2. Single Sign-On

Single Sign-On (SSO) means that the user signs in a single time to a Distributor or Carrier application, then can link directly to AFFIRM without the need to sign in again. The benefits of this approach is support for all of the items listed in the AFFIRM Login “Cons” above, while the cost is additional complexity. To implement SSO, the Carrier or Distributor must undertake a software integration project with iPipeline. The process includes requirements gathering, analytics/design, development, testing, and finally Production rollout.

4.1.2.1.The AFFIRM Gateway

A key SSO concept is the AFFIRM Gateway. In order to support partner-specific SSO, security, infrastructure, seed data, and other requirements, AFFIRM introduced the concept of a Gateway. In simplest terms, the purpose of the gateway is to interface with the AFFIRM partner, supporting varying partner requirements, while always presenting the same interface to the Various AFFIRM


28

applications. This allows iPipeline to support a number of partner implementations without the need to customize AFFIRM for each one. The diagram below illustrates basic gateway operation.

Figure 8: AFFIRM Gateway Operation

As you can see from the diagram, the Gateway has *** primary functions: 1. Authenticate User – This is usually done by creating a “Trusted Partner”

infrastructure between iPipeline and the Distributor, in which a security infrastructure is used to validate that the user is who they claim to be.

2. Route User to Correct AFFIRM Application – During SSO, the AFFIRM partner always passes the three basic values enumerated below. Based on the !UserRole/UserAction combination, AFFIRM sends the User to the correct application.

2.1. UserRole – The AFFIRM User Role, tabulated below:


29

Table 4: AFFIRM User Roles

List Sublist Code Value Code Name Code Description

<UserRole> Agent Agent

<UserRole> AgentAssistant Agent Assistant

<UserRole> AgentManager Agent Manager

<UserRole> Approver Order Approver

<UserRole> CarrierBA Carrier Business Analyst

<UserRole> CarrierBAPilotCarrier Business Analyst with Pilot Testing Access

<UserRole> CarrierBAProductionCarrier Business Analyst with Production Access

<UserRole> CarrierUserAdmin Carrier User Administrator

<UserRole> ClearingFirmBA Clearing Firm Business Analyst

<UserRole> ClearingFirmBAPilotClearing Firm Business Analyst with Pilot Testing Access

<UserRole> ClearingFirmBAProductionClearing Firm Business Analyst with Production Access

<UserRole> ClearingFirmUserAdmin Clearing Firm User Administrator

<UserRole> DistributorBA Distributor Business Analyst

<UserRole> DistributorBAPilotDistributor Business Analyst with Pilot Testing Access

<UserRole> DistributorBAProductionDistributor Business Analyst with Production Access

<UserRole> DistributorUserAdmin Distributor User Administrator

<UserRole>

2.2. User Action – The AFFIRM Action that the User is Requesting, tabulated below.

Table 5: AFFIRM User Actions

List Sublist Code Value Code Name Code Description

<UserAction> AdministerUsers Administer Users

<UserAction> ApproveOrders Approve Orders

<UserAction> ConfigureApprovalQueues Configure Approval Queues

<UserAction> EnterInitialPurchaseOrder Enter New Money Order

<UserAction> EnterSubpayOrder Enter Subsequent Payment Order

<UserAction> ManageBusinessDataManage Business Data (Products, Forms, etc.)

<UserAction> PilotInitialPurchaseOrder Pilot Test New Money Order

<UserAction> PilotSubpayOrder Pilot Test Subsequent Payment Order

<UserAction> PilotViewDashboard Pilot Test View Order Dashboard (All Orders)

<UserAction> ViewDashboard View Order Dashboard (All Orders)

<UserAction> ViewReports View Reports

<UserAction>

2.3. UserID – A unique (within the Partner) identifier for the User. Used for

audit. 3. Standardize Seed Data – (Order Entry Only) Distributors may pass seed data

from a number of sources, and in either a standard or proprietary format. The Gateway calls Distributor-custom software to convert the seed data that the Distributor passes to AFFIRM into an ACORD-standard New Business for Annuities (NBfA/TX103), or Subsequent Payment (TX508) message, save that


30

standardized data in the AFFIRM database, and pass a key (GUID) to find that data on to the AFFIRM order entry application.

4.1.3. Gateway Patterns

Different AFFIRM partners will decide to implement SSO using one of two general AFFIRM Gateway patterns, or possibly by mixing the patterns described below. Factors such as security requirements, data organization, infrastructure, business/regulatory requirements, and budget will drive this decision.

4.1.3.1. “Single Shot”

The “Single Shot” pattern is used when all required information is passed at one time, as a single “token” (URL parameter) in the HTTP post. In this case, the AFFIRM partner may simply pass the !UserRole/UserAction/UserID to the Gateway, and the Gateway will redirect the use to the correct AFFIRM Application. This simplest approach is generally used for the BA and User Administrator AFFIRM Roles, as well as for Agent Dashboard and Approver Approval Queue access. In the case of the Dashboard and Approval Queue access, the Distributor may also pass filtering information as part of the token to tell AFFIRM which data to display in the dashboard or approval queue. The allowed filtering parameters are as follows: o OrderTakerUserID – The UserID of the individual who initially entered the

Annuity Order. o AgentID – The primary or any additional Agent present on the order. o BranchID – The branch ID on the order. A single branch ID is allowed for each

order. o RegionID - The Region ID on the order. A single Region ID is allowed for each

order. o BrokerageAccountNumber – A funding brokerage account number. Any order

may have one or multiple funding brokerage accounts. AFFIRM uses the following logic to filter orders in the approval queue or dashboard:


31

Table 6: Approval Queue and Dashboard Filtering Logic OrderTakerUserID AgentID BranchID RegionID BrokerageAccountID Filtering Logic

No No No No No ALL active orders displayed

Yes No No No NoAll active orders entered by

OrderTakerUserID displayed

No Optional Optional Optional OptionalOnly orders that have the AgentID AND

BranchID AND RegionID AND BrokerageAccountID displayed

Yes Optional Optional Optional Optional

Orders that have the OrderTakerUserID OR AgentID AND BranchID AND

RegionID AND BrokerageAccountID displayed

For the Approver user role, the Distributor may also opt to pass Approval Queue Permissions to tell AFFIRM which approval queue(s) to display to the Approver. These permissions are defined by the Distributor during approval queue configuration. See details in the Approval Module section below. Finally, the Distributor may also opt to pass seed data for order entry as part of the single token. While AIRM supports seed data passed as a single ACORD NBfA (TX103) message “out of the box”, it also supports other formats, including Distributor-proprietary formats.

4.1.3.2. “Call Back”

In some cases, the Distributor may be unable to pass all of the UserID/UserRole/UserAction, Seed Data, and Filtering information with the initial token. In these cases, the AFFIRM Gateway may be programmed to call one or more Distributor back office applications for the data that was not passed in the token. At one extreme, the Distributor may opt to pass only the UserID or a Unique Session ID with the initial token, and then expect the Gateway to call back for the rest. Between this extreme and the other extreme of “single shot”, any mixture of “token” and “call back” data may be implemented. As another variation on this them, the AFFIRM partner may opt to load some information, such as Agents, Approvers, Approval Teams, Sales Teams, Agent Managers, and Agent Assistants into the AFFIRM hierarchy module. While this imposes a user maintenance burden on the AFFIRM partner, it is required in some cases when the partner is unable to integrate such information from their back office with AFFIRM. In this case, the AFFIRM Gateway simply calls to the AFFIRM Hierarchy Module exactly as if it was a Distributor back office system.


32

5. AFFIRM Operation by Module

The following sections provide an overview of AFFIRM operation for each module and application.

5.1. AFFIRM Product Module

5.1.1. Overview

The diagram below illustrates the flow of product data through the AFFIRM system. See the AFFIRM Workflow section above for additional details.

Figure 9: Product Management Overview


33

5.1.2. Product Profile Administrator (PPA)

Product Profile Administrator is not an AFFIRM application, it is available as a separate product. PPA is used by some Carriers to create and manage the ACORD-standard product profiles (PPfA/TX1203) that are required by AFFIRM potation, and uploaded to AFFIRM using the Product Manager Application described in the next section.

Figure 10: Product Profile Administrator Screen Shot

5.1.3. Product Manager Application

The diagram below illustrates the place of the Product Manager Application in the AFFIRM workflow. It is used by the Carrier BA to: 1. Upload ACORD product profile (PPfA/TX1203) to AFFIRM. AFFIRM runs

business rules during the upload to detect errors. 2. Manage product profiles through the Carrier Dev, Pilot, Production Regions. See the section on AFFIRM routing for additional details on the information flow through AFFIRM.


34

AFFIRM Order Entry System

Carrier Applications

Product Module

IPMR - Product Manager

Order Module

IAOE (Carrier Order Entry Pilot)

Carrier Dev

Database

Distributor Applications

CarrierPromote

ToProduction

Order Destination(DTCC or Carrier)

Order Submission

Carrier Pilot

Database

CarrierBAPromote To Pilot

Carrier Prod.

Database

CarrierBA PromoteTo Production

Forms Module

IFAP (Carrier Forms)

Order Module

IAOE (Carrier Order Entry Production)

Distributor Dev

Database

Distributor Pilot

Database

DistributorBAPromote To Pilot

Distributor Prod.

Database

DistributorBA PromoteTo Production

Product Module

IDRA - Distributor Rules

Order Module

IAOE (Distributor Order Entry Pilot)

Forms Module

IFAP (Distributor Forms)

IAOE (Distributor Order Entry Production)

Approval Module

IAQC (Approval Configuration)

IAQA (Approval Queues)

Carrier BA

Upload & ManageProducts

UploadForms

DefineQuestions

& Question Rules

PilotTest

ProductionTest

Agent/FA

Approver

DistributorAdmin

BlueFrogBA

Blue Frog

AFFIRM Master

Admin DB

Partner Info, Distributor-Specific UIConfig, Common Order Entry Business Rules,

Master Questions List

DistributorBA

IntroduceDistributor

Product Rules


Forms

DefineQuestions

& Question Rules

Pilot Test

Order Entry

Hierarchy Module

IHMA (Distributor Hierarchy

Management)

Define Hierarchy(Non-SSO Only)

ConfigureApproval Queues

Approve Orders

AFFIRM MetaData Database

Blue Frog BALoadData

Carrier Questions


Distributor Order Entry Rules

DefineOrder Entry

Rules

MetaData Used During OrderEntry

ITMR – Manage Carrier Products &

FormsManageCarrier

Products & Forms

Figure 11: Product Manager in AFFIRM Workflow

5.1.4. Distributor Rules Application

The Distributor Rules Application is used by the Distributor BA. It was designed to provide each Distributor with the capability to define and implement product rules, in much the same way that a Carrier defines product rules using the ACORD PPfA message. Distributor rules take the form of restrictions on Carrier product profiles that reflect the Distributor’s compliance guidelines with regard to selling variable annuities. The Distributor Rules Application provides the capability to define blanket rules that will apply to all products sold by the Distributor, but limits the Distributor to defining rules that are more restrictive than those set by the Carrier (i.e. a Distributor can’t loosen Carrier rules).


35

Blanket rules can be defined for the following product parameters: o Minimum and Maximum Issue Age o State of Sale o Owner Types o Qualified Plan Types o Order Funding Methods o Premium Minimum and Maximum AFFIRM automatically combines Distributor rules and forms with the Carrier’s product profile (PPfA) and forms to generate a composite set of rules that reflects the more conservative rules set by either party. A separate set of composite rules is generated for each Distributor’s Pilot and Production order entry systems. These rules control the acceptable values to be entered during an annuity order. The diagram below illustrates the location of Distributor Rules Application in the Overall AFFIRM workflow. See the section on AFFIRM routing for additional details on the information flow through AFFIRM.


36



Product Module


Order Module


Carrier Dev

Database


CarrierPromote

ToProduction


Order Submission

Carrier Pilot

Database


Carrier Prod.

Database


Forms Module


Order Module


Distributor Dev

Database

Distributor Pilot

Database


Distributor Prod.

Database


Product Module


Order Module


Forms Module



Approval Module



Carrier BA


UploadForms

DefineQuestions

& Question Rules

PilotTest

ProductionTest

Agent/FA

Approver

DistributorAdmin

BlueFrogBA

Blue Frog

AFFIRM Master

Admin DB



DistributorBA


Product Rules


Forms

DefineQuestions

& Question Rules

Pilot Test

Order Entry

Hierarchy Module


Management)



Approve Orders



Carrier Questions



DefineOrder Entry

Rules



FormsManageCarrier

Products & Forms

Figure 12: Distributor Rules in AFFIRM Workflow

5.1.5. The Composite Product Profile

Distributors typically use software-based order entry systems to capture sales and transmit the order information to the Carrier. These order entry systems have a high degree of dependency on product descriptive information (product profiles), which is generally created by the Carrier. This creates a problem because product descriptions are complex (see example product description data model below) and change frequently.


37

Figure 13: ACORD PPfA Data Model

Furthermore, a typical Carrier sells products through any number of Distributors, sometimes with Distributor-specific products. Finally, Distributors may impose their own product rules that are more restrictive then Carrier rules. This means that: 1. Carriers must create and maintain complex product profiles. 2. As the product profile changes, they must distribute product information to any

number of Carriers. 3. When they receive a new product profile from a Carrier, the Distributor must be

able to impose their own rules on a product-by-product basis. 4. The Distributor’s order entry system must be able to interpret both Carrier and

Distributor rules. The current industry approach is for Carriers to maintain separate product profiles for any Distributor that has rules that are more restrictive than the Carrier rules. This approach is costly and error-prone because it requires the Carrier to maintain large volumes of data that is duplicate except for minor changes, and also requires a high-degree of ongoing collaboration between the Distributor and Carrier.


38

In recent years, there has been a movement to create standards for business messaging in the industry—this has eased the maintenance burden somewhat, in that now a Carrier can use the same product description format for all Distributors, but does not solve the problem outlined above, which will be referred to as the “synchronization problem”. For an example product profile, refer to the ACORD XML standard (www.acord.org) Product Profile for Annuity (PPfA – Transaction #1201). The ADMServer approach is applicable to any messaging standard and any financial instrument. IPipeline is in the process of developing the AFFIRM system for financial instrument order entry; this system is constructed on the IPipeline ADMServer platform. The system includes an elegant solution to the synchronization problem.

5.1.5.1.Composite Products Process Overview

1. Carrier Business Analyst Uses a Product Management System to enter product profile information in a standards-based data model.

2. Carrier Business Analyst transmits the product information via a standard

message to any number of Distributors. There is no need for the Carrier to create Distributor-specific product profiles.

3. Distributor Business Analyst enters Distributor product rules using the same

standards-based data model as the Carrier used. The Distributor need enter their rules only once.

4. The ADMServer AFFIRM system compares the Distributor and Carrier product

profiles and generates a composite product profile, which takes the more restrictive value for each of the data members in each profile. The composite product profile is in the same standards-based data model as the Carrier and Distributor profiles.

4.1. For collections of values, such as lists of applicable states, the system

creates a composite with the union of the lists. 4.2. For values that become more restrictive as they grow smaller, the

composite includes the lesser of the two values. 4.3. For values that become more restrictive as they grow larger, the composite

includes the greater of the two values.

5. The order entry system then interprets the composite product profile to control system behavior during the order entry process.

The diagram below illustrates the use of Distributor product rules to generate a composite product profile.


39

Figure 14: Distributor Product Rules

5.1.5.2. Composite Product Profile Benefits

There is no need for direct coordination between the Carrier and Distributor business analysts—each can work independently.

There is no need for a Carrier to create separate product profile for each

Distributor. As the product profile is updated by the Carrier, the system automatically

creates new composite product profiles based on the latest information available.

As the Distributor changes their product rules, the system automatically creates

new composite product profiles based on the latest information available.


40

5.1.6. Test Manager Application

The Test Manager Application is used by the Distributor BA to manage Carrier Product and Forms, as well as Distributor rules through the AFFIRM Dev, Pilot, and Production Regions. The diagram below illustrates the location of Distributor Rules Application in the Overall AFFIRM workflow. See the section on AFFIRM routing for additional details on the information flow through AFFIRM.

Figure 15: Distributor Test Manager in AFFIRM Workflow

5.1.7. Cut-Down Products

*** Pending Jim F ***


41

5.2. AFFIRM Forms Module

5.2.1. Overview

The purpose of the forms module is to provide for the introduction, management, and generation of Carrier and Distributor forms that are required for annuity order entry. The diagram below illustrates the flow of form data for AFFIRM. See the AFFIRM Workflow section above for additional details.

Carrier Database (Dev)

ADOBE AcrobatProfessional

Version

1. Create& Tag PDF Templates

CarrierBA

Forms Management Application UI5. Define

Form Rules

4. Create Form Data Maps

3. Create Form Data Model

Distributor Database

(Production)

Rep

Order Entry Application UI (Production)

11. Enter & SubmitAnnuity Order

Order

12. Forms Selected(Based on Form Rules)

& Populated(Based on Mapping)

& Rendered

13. Download/PrintRendered Forms

AFFIRM Distributor Database

Rep

Forms Library Application UI

11. Search for Forms

Query

12. List ofForms Meeting

SearchCriteria

13. Download/PrintSelected Forms

OR

Start

2. Upload Tagged Templates to AFFIRM

Distributor Database Pilot)

8. Promote Forms For Distributor Pilot Testing

Order Entry Application UI

(Distributor Pilot)

Carrier BA Distributor BA

9. Distributor & Coordinated

Testing

10. TransmitForms

for Production

AFFIRM Feed Management

System UI (Production)

10. Promote FormsInto Production

Carrier Database (Pilot)

6. Promote Forms For Carrier

Pilot Testing

Order Entry Application UI (Carrier Pilot)

7. CarrierPilot Testing

Note: Steps 1-8 are also carried out by a DistributorBA for Distributor forms. The distributor has a Dev database that is analogous to the carrier Dev database.

End

End

Figure 16: the Forms Module Application & IFLA Overview

The diagram below illustrates the form lifecycle with the portion that is completed by the AFFIRM Solution. Adobe Acrobat or similar is used to create and “tag” PDF’s with editable fields. Forms are generated by AFFIRM, but the printed and submitted by the Agent (AFFIRM can also submit electronic forms). AFFIRM does


42

not include document imaging/repository functionality, but is sometimes used as the document source for a document imaging system, such as Paperclip or Intelisys.

Figure 17: Order Form Lifecycle

5.2.2. Forms Management Application

The purpose of the Forms Module Application is to provide the Carrier and Distributor BA with a utility to:

o Introduce and Manage PDF tagged (with fillable fields) PDF forms. o Define the applicability rules of the form using the ADMServer Macro

Language. o Define data mapping for form fillable fields.

The screenshot below, from the iPipeline Wiki, illustrates typical fillable fields mapping, using the ADMServer Macro Language.


43

Figure 18: Sample Form Mapping Formulas

The diagram below illustrates the location of Forms Management Application in the Overall AFFIRM workflow. See the section on AFFIRM routing for additional details on the information flow through AFFIRM.


44



Product Module


Order Module


Carrier Dev

Database


CarrierPromote

ToProduction


Order Submission

Carrier Pilot

Database


Carrier Prod.

Database


Forms Module


Order Module


Distributor Dev

Database

Distributor Pilot

Database


Distributor Prod.

Database


Product Module


Order Module


Forms Module



Approval Module



Carrier BA


UploadForms

DefineQuestions

& Question Rules

PilotTest

ProductionTest

Agent/FA

Approver

DistributorAdmin

BlueFrogBA

Blue Frog

AFFIRM Master

Admin DB



DistributorBA


Product Rules


Forms

DefineQuestions

& Question Rules

Pilot Test

Order Entry

Hierarchy Module


Management)



Approve Orders



Carrier Questions



DefineOrder Entry

Rules



FormsManageCarrier

Products & Forms


5.2.3. Forms Generation during Order Entry

After the Agent has completed order entry, AFFIRM automatically selects the applicable forms, populates the fillable fields per the form mapping, and presents the rendered forms to the Agent as PDF documents which he may save, email, or print from his/her browser.


45

Figure 20: Forms Rendering After Order Entry

Note: After forms are rendered, the order is not available for editing. This rule is in place to prevent a mismatch between forms and the electronic order. In order to edit an order after forms are made, a copy must be made. When a copy of an order is created, it is automatically assigned a new AFFIRM-assigned Order ID.

5.3. AFFIRM Hierarchy Module

5.3.1. Overview

The purpose of the hierarchy information is to provide a repository for Distributor hierarchy information for those Distributors that are unable to share hierarchy information from their back office systems during single sign-on. In AFFIRM, hierarchy information is used for the following purposes: o Superior/Subordinate Relationships for Access to Orders:

o To determine which orders a given Agent Assistant can access. o To determine which orders a give Agent Manager can access.

o Grouping Relationships:

o To group agents on a sales team. o To group approvers on an approval team.

o User Credentials:

o Determine to which AFFIRM User Role (Agent, Approver, etc.) a user belongs.

o Store user-specific information, such as UserId and password.


46

The sample hierarchy diagram below illustrates these concepts.

Figure 21: Sample Distributor Hierarchy

5.3.2. Hierarchy Management Application

Carriers are not provided with hierarchy and provisioning functionality, as the number of users is relatively small, and the only role a business analyst (BA). Carrier users will be provisioned and managed by iPipeline. Note: Because manual hierarchy management can impose a heavy workload on the Distributor User Administrator, iPipeline recommends that the Hierarchy Module is implemented only if the Distributor has no way to support hierarchy information passed during single sign-on. The Hierarchy Management Application provides a user interface for the Distributor User Administrator to manage Distributor hierarchy. Because some hierarchies may be large, AFFIRM provides three options for hierarchy management.


47

Distributor Database

Windows/Excel

Distributor BA

Browser

XML Hierarchy

Excel Hierarchy Spreadsheet

IHMAInbound Process

IHMA UI Direct Entry

Option 1: XML from Another

SystemOption 2: Upload

Excel Spreadsheet

Option 3: Enter via IHMA User

Interface

Figure 22: Hierarchy Management Options

o User Interface – For small hierarchies, the Distributor User Administrator may

introduce and manage hierarchy data via the Hierarchy Management Application user interface.

o Spreadsheet Upload – For larger hierarchies, Distributor User Administrator

may introduce and manage hierarchy data via a standard spreadsheet provided by iPipeline. The Hierarchy Management Application user interface provides an upload utility for this spreadsheet.


48

PartyIDPartyTypeCo

de FullName GovtID GovtIDTC1 2 ABC Life, Inc 123456789 82 1 John Smith 123456788 13 2 ABC Life SubCorp 1 123456787 84 2 ABC Life SubCorp 2 123456786 85 1 Anne Parsons 123456785 16 2 East Region 123456784 87 2 West Region 123456783 88 1 Richard Jett 123456782 19 1 Riley Dixon 123456781 1

10 1 Gail Adams 123456788 111 1 Stacy Fitch 123456788 112 1 Jim Garland 123456788 113 1 Bill Adams 123456788 114 1 Carol Smart 123456788 115 1 Sally Fieldstone 123456788 116 1 Shane Hammer 123456788 117 1 Alex Ambrose 123456788 118 1 Jay Furst 123456788 119 1 Rob Mayes 123456789 120 1 Jan Piorier 123456789 121 1 Helen Allen 123456789 1

Parties

GroupIDGroupingTypeCo

de FullName1 4 Sales Team 12 4 TEST SALES TEAM3 15 OSJ Team 14 15 OSJ Team 2

Groups

SuperiorPartyID SubordinatePartyID1 32 53 64 75 86 37 48 29 3

10 4

Relationships Between PartiesGroupMemberID GroupID

1 12 13 14 25 26 27 38 39 3

10 2

Relationships Between Groups and Their Members

Figure 23: Sample Excel Workbook (Multiple Worksheets)

o XML Upload - For larger hierarchies, Distributor may introduce and manage

hierarchy data via an ACORD-standard XML message. This approach is best suited for machine-generated hierarchy information. The Hierarchy Management Application user interface provides an upload utility for this XML file.


49

Figure 24: Sample Hierarchy ACORD XML Message

See the User Access of AFFIRM section above for an overview of the user of Hierarchy information for AFFIRM use access. The diagram below illustrates the location of the Hierarchy Management Application in the Overall AFFIRM workflow.


50



Product Module


Order Module


Carrier Dev

Database


CarrierPromote

ToProduction


Order Submission

Carrier Pilot

Database


Carrier Prod.

Database


Forms Module


Order Module


Distributor Dev

Database

Distributor Pilot

Database


Distributor Prod.

Database


Product Module


Order Module


Forms Module



Approval Module



Carrier BA


UploadForms

DefineQuestions

& Question Rules

PilotTest

ProductionTest

Agent/FA

Approver

DistributorAdmin

BlueFrogBA

Blue Frog

AFFIRM Master

Admin DB



DistributorBA


Product Rules


Forms

DefineQuestions

& Question Rules

Pilot Test

Order Entry

Hierarchy Module


Management)



Approve Orders



Carrier Questions



DefineOrder Entry

Rules



FormsManageCarrier

Products & Forms

Figure 25: Distributor Hierarchy Management in AFFIRM Workflow

5.4. AFFIRM Order Module

5.4.1. Overview

The AFFIRM order module is the centerpiece of the AFFIRM suite of applications. It is the consumer of the data introduced by all of the applications discussed up until this point. The diagram below illustrates the location of Order Entry Application in the Overall AFFIRM workflow. The same order entry application is used for Carrier Pilot testing, Distributor Pilot testing, and Production order entry. AFFIRM controls which order data is available to which order entry user role through the use of Subscriptions, as described in the AFFIRM User Roles section above.


51



Product Module


Order Module


Carrier Dev

Database


CarrierPromote

ToProduction


Order Submission

Carrier Pilot

Database


Carrier Prod.

Database


Forms Module


Order Module


Distributor Dev

Database

Distributor Pilot

Database


Distributor Prod.

Database


Product Module


Order Module


Forms Module



Approval Module



Carrier BA


UploadForms

DefineQuestions

& Question Rules

PilotTest

ProductionTest

Agent/FA

Approver

DistributorAdmin

BlueFrogBA

Blue Frog

AFFIRM Master

Admin DB



DistributorBA


Product Rules


Forms

DefineQuestions

& Question Rules

Pilot Test

Order Entry

Hierarchy Module


Management)



Approve Orders



Carrier Questions



DefineOrder Entry

Rules



FormsManageCarrier

Products & Forms


5.4.2. Order Dashboard

Each Annuity Order in AFFIRM is assigned an internal status, which is used by the various AFFIRM processes to track the order. Each internal status has a corresponding AFFIRM dashboard display and dashboard functionality. The table below illustrates the dashboard display for each of the possible order status codes, and also the dashboard functionality (View, Edit, etc.) for each.


52

Table 7: Dashboard Display

ADMTransStage

Direction Internal StatusDisplay Dashboard

Status TextView Edit Copy Cancel Delete

1 1 Unprocessed In Progress x x x65 1 Pre-Submitted In Progress x x x23 1 Forms Rendered Forms Rendered x x x19 1 Pending Review Assignment Pending Approval x x x20 1 Pending Review Pending Approval x x x53 1 Approval Rejected Cancel/Rejected x x x54 1 Approval Replaced Cancel/Reworked x x x18 1 Order Sent for Rework Rework Pending x x x63 1 Additional Information Requested Info Requested x x x64 1 Cancelled Cancelled x x x4 1 Sent to DTCC (Error Detected) Executed x x x5 1 Exception Reported Executed x x x

65 1 Pre-Submitted In Progress x x x6 1 Approval Complete Executed x x x3 1 Pending Transmission Executed x x x7 1 Sent Executed x x x8 1 To Be Purged Don't Display26 1 Delivery NACK (Reject) Executed x x x27 1 Transaction Rejected Executed x x x29 1 Delivery ACK (Acknowledged) Executed x x x61 1 Not Sent to DTCC (Fatal Error) Executed x x x60 1 Complete (Paper Application) Executed x x x58 1 Audit Copy N/A

Dashboard Actions AvailableDashboard Display Dashboard Display Rules

The chart below shows all of the possible internal status codes for an order, and the possible paths between the various states.


53

New/Saved Order ADMTransStage=1

Marked to Purge ADMTransStage=8

PurgedSent for Additional InfoADMTranStage=63

/ Rep Discards

Order Sent to DTCC ADMTransStage=7

[Rep Initiates Order]

Order Replaced ADMTransStage=54

[Purge]

[RepDiscards]

ORDER ADMTrans/TransType=NewOrderTrans ADMTrans/Direction=1

DTCC ACK ADMTransStage = 29

Exception Reported ADMTransStage = 5

Approval Complete=6

[Approve]

Pending Approval ADMTransStage=20

[Send for Rework]

[Send forAdditional

Information]

Rejected ADMTransStage=53

[Rejected]

DTCC NACK ADMTransStage = 26

DTCC Reject ADMTransStage = 27

Order Sent to DTCC (Error Detected) ADMTransStage=4

Order Not Sent to DTCC (Error Detected) ADMTransStage=61

[Resubmit]

On orders sent for rework, the original orderis cancelled and the status on that originalorder set to 54 (cancelled)--see below.

In this case, the initial statuson the NEW ORDER CREATED FOR REWORK would be 18 (Order Sent for Rework)Instead of 1--see above.

[Agent Navigates to Submit Screen]

Order Cancelled ADMTransStage=64

Pre-Submitted ADMTransStage=65

[Agent Submits Order]

Forms Rendered ADMTransStage=23

[Agent Renders Forms]

Pending Transmission/Success=3

[Approval Complete Process]

Complete Paper Submission=60

[Approval Complete Process]

Audit Copy = 58

Audit Copies of an Order May Also be Kept in the AFFIRMBusiness Database.

Figure 27: Order Status Chart

5.4.3. Order Entry Business Rules

During order entry, AFFIRM continually checks to ensure that no business rules have been broached. Orders with business rule breaches are typically returned by the Carrier as “Not in Good Order” (NIGO). One of the primary business drivers for electronic annuity order entry is the assurance of “In Good Order” (IGO) annuity orders. AFFIRM business rules are stored in the AFFIRM MetaData database as ADMServer Macro-Language expressions, and fall into the following categories: o AFFIRM-standard Business Rules – Industry-wide business rules that are

applicable to all Carriers and Distributors. Included are the rules that are checked against the Carrier product profile (Composite PPfA).

o Distributor-specific Business Rules – Order entry rules specific to a given

Distributor. A business rules breach will result in either an AFFIRM Error or Warning.


54

o Error – Error message is displayed in AFFIRM user interface and order entry is

halted until the error is corrected. o Warning – Error message is displayed in the AFFIRM user interface, but order

entry is allowed to proceed. All errors and warnings are displayed in the Order Summary Report. The diagrams below show how AFFIRM uses business rules during order entry: 1. To control information displayed in the order entry user interface. 2. To control information entered via the order entry user interface. When the user requests an order entry page, ADMServer checks each field on the page to see if required, disabled (grayed), a dropdown list, or if it has a default value.

Figure 28: Business Rules Used to Control Display

After the user enters information and clicks <Next>, ADMServer checks the entered data to be sure that the data types (text, number, etc.) are correct, that all numbers are within allowed ranges, if text string lengths are within allowed ranges, and if any Macro-Language rules are broken.


55

Figure 29: Business Rules Used to Check Order Entry

If there is an Error or Warning, then ADMServer displays a message to the user via the AFFIRM user interface.

Figure 30: Display Error or Warning

If there is no Error or Warning, then ADMServer stores the user-entered data and proceeds to check the rules to display the next screen.


56

Figure 31: Save User-Entered Data

Note: AFFIRM also uses Macro-Language business rules as follows: o Seed Data Validation Rules – AFFIRM checks that Distributor seed data

meets the minimum requirements so as not to cause AFFIRM system errors. o Product Profile (PPfA) Validation Rules – AFFIRM checks that Carrier

product profiles meet the minimum requirements so as not to cause AFFIRM system errors.

o Questions Business Rules – Business rules are used to control question

applicability (which questions to show), and the rules around the formatting and requirements for questions. Question business rules are also used to control reflexive questioning in AFFIRM.

5.4.4. Initial Purchase Order Entry

5.4.4.1.Overview

The diagram below illustrates the initial purchase order entry process.


57

Initial Purchase Order Entry Application

Agent

Browser

Order DashboardEnter Agent/Team

Information

High Level Order Information

(Jurisdictions, Qualified Plan

Type, etc.)

Select Product

Enter Funding Information(Brokerage

Account, 1035, etc.)

Enter Participant Information

(Owner, Annuitant, etc.)

Select Features (Riders, etc.) and Feature Details

Select Subaccounts

Answer Carrier Questions

Answer Distributor Questions

View Summary Report

Print Forms & Submit Order for

Approval

Saved Orders

SelectOrder

Next Next Next Next

Next

Next Next Next Next Submit

License and Appointment Information

Provider (Kaplan, etc.)

AFFIRM Request L&AInformation & use to create list

of applicable products

Distributor Back Office

OptionalOrder Data

Check

Approval Queues

Order Made AvailableFor Approval

New Orders

Figure 32: Initial Purchase Order Entry Process

The Agent can view a dashboard of saved orders, or initiate a new order. As the agent steps through the annuity order entry user interface, AFFIRM applies business rules to ensure that the order is in good order (IGO). During product selection, AFFIRM can be configured to make an ACORD-standard request to an external provider (such as Kaplan) for Licensing and Appointment information. Prior to display of the Order Summary Report, which displays all order information on a single page, AFFIRM can be configured to pass the order as a standard ACORD New Business for Annuity (NBfA/TX103) message to the Distributor for a final check that the brokerage account is still active, and agent still employed, etc. After the Agent prints forms, they submit for approval.

5.4.5. Subsequent Payment Order Entry

5.4.5.1. Overview

The Subsequent Payment Order Entry Application is an AFFIRM Order Module application that is similar to the Initial Purchase Order Entry Application, the difference being that the Initial Purchase Order Entry Application is for the capture of “new money” annuity orders for the establishment of a new polity, while the Subsequent Payment Order Entry Application is for the capture of subsequent payments on an existing policy. The Subsequent Payment Order Entry Application uses the same Order Module data model and business rules as the Initial Purchase Order Entry Application.


58

Please note that the AFFIRM Subsequent Payment system 1.0 is an initial release designed to enable subsequent payment support in an environment where most Distributors are unable to supply the requisite subaccount positions and values that are required for some of the more complex subsequent payment models, such as self-directed and pro-rata. These limitations on availability of information on the in-force policy lead to the following system limitations: 1. Initially, the system will support standing allocations only. 2. Since the AFFIRM system is not aware of the current allocations, a standing

allocation order may include subaccounts that were open to money when the standing allocation was declared, but has since closed.

3. The DTCC does not currently support the explicit declaration that a subsequent

payment is to be distributed among subaccounts as a standing allocation. Most Carriers assume standing allocation if no other allocation is declared. iPipeline has submitted an enhancement request to DTCC in support of an explicit standing allocation declaration.

In addition to handling changing allocations (other than standing allocations) in the future iPipeline also notes the desirability of providing a means of changing the current funding arrangements (i.e. change the standing allocation, etc.). Because the Carriers do not require a licensing and appointment check for subsequent payments, it will not be included in Phase 1. iPipeline does plan to include the check in subsequent versions in support of Distributor compliance support.

5.4.5.2. Subsequent Payment Order Entry Application

The diagram below illustrates the subsequent payment order entry process.


59

Subsequent Payment Order Entry Application

Agent

Browser

Order DashboardEnter Agent/Team

InformationCurrent Policy

Information





Answer Carrier Questions

Answer Distributor Questions

View Summary Report

Print Forms & Submit Order for

Approval

Saved Orders

SelectOrder

Next Next Next

Next

Next Next Submit

Approval Queues

Order Made AvailableFor Approval

New Orders

Figure 33: Subsequent Payment Order Entry Process

5.4.6. Order Submission

AFFIRM natively supports DTCC APP/SUB and ACORD NBfA (TX103) order submission. Currently all AFFIRM Carrier partners accept DTCC APP/SUB only. Typically DTCC APP/SUB is transmitted by AFFIRM to the Carrier via the DTCC, but AFFIRM sometimes transmits to DTCC via an intermediary, such as Thomson Transaction Services (TTS).

5.5. The AFFIRM Approval Module

5.5.1. Overview

After an Agent has completed order entry, they submit the order for a compliance review/approval process, which is carried out by the Distributor. AFFIRM includes a highly configurable & highly flexible approach for order approval queue management. Building on the ADMServer Macro-Language, AFFIRM allows the Distributor to configure as many order approval queues as they wish, to configure the sequence that the order passes from queue to queue, and the applicability rules for each queue. A sequential overview of the AFFIRM approval queue approach is illustrated below.


60

Figure 34: AFFIRM Approval Queue Overview

Approval Queue processing operates as follows: 1. Approval Queue Configuration – Distributor BA AFFIRM user configures

approval queues. The details or approval queue configuration are set out in the next section. Approval Queue configuration is stored in the same database as the annuity orders.

2. Agent Order Entry – Agent AFFIRM user enters an order, prints forms, and submits the order for approval. The details of annuity order entry are set out in a later chapter of this document.

3. Approval Queue Assignment – AFFIRM periodically (several times an hour)

scans the database for annuity orders that are in a “Pending Approval Queue Assignment” status; this means that the order has been submitted for approval by the Agent, but has not yet been assigned to approval queues. For these orders, AFFIRM compares each approval queue applicability rule (an ADMServer Macro-language formula set during approval queue configuration) against the data included in the order.

3.1.1. As an example, if an approval queue has an applicability rule such as

“This queue applies to all orders with an initial premium amount greater than $1,000,000 solicited in the state of New York.” If the given order meets this criteria, then AFFIRM will add a Requirement (an ACORD RequirementInfo record) to the order for this approval queue. If the order meets the criteria set out for several approval queues, then they will all be added at this time.

3.1.2. For the sample above, the queue applicability macro-language rule

would look like:


61

key('AnnuityOrder')/Policy/Annuity/InitDepositAmt>=1000000 and key(‘AnnuityOrder’)/Annuity/Jurisdiction=$ACORD/ OLI_USA_NY

3.1.3. After the approval queues have been assigned, an order in the

AFFIRM database might have this type of information:

Figure 35: Order in AFFIRM database with Approval Queue Requirements

4. Approval – After approval requirements are added to an annuity order and the

approval queues are assigned, the order becomes available for approval The Approver may approve the order, reject the order, send the order back to Agent for additional information, or send the order back to Agent for rework. Details in regards to annuity order approval are included later in this section.

5. Flag as Approved – As you can see in the illustration above, AFFIRM keeps a status code for the order “Pending Approval”, and for each approval queue “Pending”. This is important because approval queues may each have their own independent status codes, and the order status in regards to approval is dependent upon the status of the approval queues. To keep the order and approval queue status’ in synch, AFFIRM periodically (several times an hour) scans the database for orders that with a status “Pending Approval”, checks the status of each approval queue, and updates the order status using the following logic:

5.1. Orders Still in Approval – If any of the approval queue requirements are

still in a “Pending” status, the order remains in a “Pending Approval” status. 5.2. Approved Orders – If all of the approval queue requirements are in an

“Approved” status, the order status is updated to “Pending Submission to Carrier”.

5.3. Rejected Orders – If any of the approval queue requirements are in a

“Rejected” status, the order status is updated to “Rejected”.


62

5.4. Orders Sent for Rework – If any of the approval queue requirements are in a “Sent for Rework” status, the order status is updated to “Cancelled - Rework”, and a new copy of the order is created with a status of “Rework”.

5.5. Order Sent for Additional Information - If any of the approval queue

requirements are in a “Sent for Additional Information” status, the order status is updated to “Sent for Additional Information”.

These approval flows are discussed in additional detail below.

5.5.2. Approval Queues Configuration Application

The screen shot below gives a glimpse of the AFFIRM Approval Queue Configuration Application. This application is accessible to the Distributor BA AFFIRM user role. See the Approval Queue Application User Guide for additional information.

Figure 36: Approval Queue Configuration - Queue Details


63

Figure 37: Approval Queue Configuration - Queue Criteria

The diagram below represents approval queue configuration as it is stored in the AFFIRM database. As a note, approval queue configuration is stored in the same database with the annuity order data.

Figure 38: Approval Queue Configuration in AFFIRM Database

The types of data included in the approval queue configuration are as follows: o Approval Queue Name – Distributor-chosen name for the approval queue. o Sequence – Approval Queue sequencing—see examples below.


64

o Applicability Rule(s) – One or more macro-language rules to tell AFFIRM the

conditions for which to add an approval queue requirement to an order. This example is for an approval queue to be added for all 1035-transfers:

Is-not-null(key('FinActiv1035Policy'))

o Permissions – If your company is using single sign-on (SSO), then you’ll decide the names of the Permissions that will be passed with the Approver so that AFFIRM knows which queue(s) to make available to an Approver. Approver access, including SSO is explained in detail below. All permission names must begin with “Custom.”; as an example for Queue ABC, you may decide to name the permission Custom.CanSeeQueueABC. iPipeline will later share the permissions that you define with your technical team for use during the SSO implementation.

As noted above, AFFIRM provides for the sequencing of approval queues as part of the queue configuration. As a general rule, no order will become visible in an approval queue unless it has been approved by all queues with a lower sequence number. This allows you to set up queues that run in sequence (one after the other), in parallel (all at the same time), or a mixture of in parallel and sequenced. The diagram below shows several examples of queue sequencing.


65

Queue Sequence

Queue 1 1

Queue 2 2

Queue 3 3

Queue 4 4

Queue 1 Queue 2 Queue 3 Queue 4

Queue Sequence

Queue 1 1

Queue 2 2

Queue 3 3

Queue 4 3

Queue 1 Queue 2

Queue 3

Queue 4

Queue Sequence

Queue 1 1

Queue 2 1

Queue 3 2

Queue 4 3

Queue 1

Queue 2

Queue 3 Queue 4

Queue Sequence

Queue 1 1

Queue 2 1

Queue 3 1

Queue 4 1

Queue 1

Queue 2

Queue 3

Queue 4

Agent SubmitOrder

Agent SubmitOrder

Agent SubmitOrder

Agent SubmitOrder

Scenario 1 Scenario 2

Scenario 3 Scenario 4

Figure 39: Queue Sequencing Examples

5.5.3. Approval Queues Application

The screen shots below provide a glimpse of the AFFIRM Approval Queue Application. This application is accessible to the Distributor Approver AFFIRM user role. See the Approval Queue Application User Guide for additional information. *** Teresa ***

5.5.3.1. Approver Access to Approval Queues

Before an Approver can approve an order, they must gain access to AFFIRM. See the User Access of AFFIRM section above for details on approval queue access. In general, AFFIRM provides a multiple mechanisms for Distributors to pass the following information when an Approver Accesses AFFIRM: o Approval Queue Permissions – Which approval queue(s) can the Approver

access? o Approval Queue Filtering - Given Access to an approval queue, which orders

can the Approver access?


66

5.5.3.2. Approval Queue Processing

The diagrams below illustrate approval queue processing. The general workflow is described in the Approval Module Overview section above. After reviewing an order, the Approver is presented with a view of the Order Summary Report, which contains all information included in the order, order forms, and order notes added by the Agent or other Approvers. The Approver has four general options: o Approve Order – Approve order and make available for transmission to Carrier

with no changes. Once an order has been approved by all required approval queues, it is made available for submission to the Carrier.

o Reject Order – Reject order. If an order is rejected by any approval queue,

then it is cancelled and no longer available for Agent to correct and resubmit. o Send Order for Rework – Send order back to Agent for corrections. After

forms are generated for a given order, AFFIRM “locks” to order so that the Agent is unable to further edit an order and end up with an electronic order that does not match the printed forms. For this reason, AFFIRM cancels an order that is sent for rework and makes a rework copy for the Agent to edit. The Agent must then reprint forms before resubmitting the order for approval.

o Send Order for More Information – In some cases, the order may be correct,

but require additional information from the Agent. The Approver may send the order back to the Agent with a note, and allow the Agent to respond via a note. All correspondence via notes is saved with the order.

Important Note: All approval queue statuses, as well as the order status and notes added by Approvers are visible to the Agent via the order entry dashboard. In addition to the functionality listed above, the Approver may attach a note to an order at any time, and may also view the status of the order in each required approval queue. The diagrams below illustrate the details of order management for each of the actions (Approver, Reject, etc.) that an approver may take.


67

Order Status = “Pending Approval”

Approval Queue 3Requirement

“Pending”


“Pending”


“Pending”

Order Status = “Pending Approval Assignment”


“Pending”


“Approved”


“Approved”

Order Status = “Pending Transmission to Carrier”

Approval Queue 3

Requirement

“Approved”

Approval Queue 1

Requirement

“Approved”

Approval Queue 2

Requirement

“Approved”

2. Agent SubmitsOrder for Approval

3. AFFIRM Assigns Approval Queues

4. Approvers Approve Queues 1 & 2, But Not 3.

AFFIRM Checks Order, but Doesn’t Change

Status Because of Outstanding Queue 3.


6. AFFIRM Transmits Order to Carrier.

Order is visible in Agent Dashboard

with status of “Executed”.

Order Status = “Forms Rendered”

1. Agent Enters Order and Prints

Forms

5. Approver Approves Queue 3.

AFFIRM Checks Order, and Changes Order Status to “Pending Transmission”

Because All Queues Are “Approved”

Figure 40: Approval Queue Order Management - Approve


68



“Pending”


“Pending”


“Pending”


“Pending”


“Rejected”


“Pending”

Order Status = “Cancelled”

Approval Queue 3

Requirement

“Pending”

Approval Queue 1

Requirement

“Rejected”

Approval Queue 2

Requirement

“Pending”



3. AFFIRM Checks Order, and Changes

Order Status to “Cancelled” Because One of the Approvers

Rejected the Order

2. Approver Rejects Order in Queue 1.

4. The Order is no longer available in any Approval Queues, and is visible in

Agent Dashboard as “Cancelled”.

Figure 41: Approval Queue Order Management - Reject


69

Figure 42: Approval Queue Order Management - Rework


70



“Pending”


“Pending”


“Pending”


“Pending”


“Sent for Additional

Information”


“Pending”

Order Status = “More Information”

Approval Queue 3

Requirement

“Pending”

Approval Queue 1 Requirement

“Sent for Additional

Information”

Approval Queue 2

Requirement

“Pending”



3. AFFIRM Checks Order, and Changes Order Status to

“Additional Information” Because One of the Approvers Sent the

Order back to Agent for Additional Information

2. Approver Rejects Order in Queue 1.

4. The Order is no longer available in any Approval Queues, and is visible in Agent Dashboard as

“More Information”.

The Agent may not edit the order, but may add notes & resubmit.

5. After the Agent resubmits the order, the

Original Approval Queue Requirements are

Removed and AFFIRM Re-Assigns new

Approval Queues.

Order Status = “Pending Approval Assignment”

Figure 43: Approval Queue Order Management - Additional Information

5.6. AFFIRM Audit Support

One of the primary business drivers for AFFIRM, especially for AFFIRM Distributor partners, is the ADMServer platform ability to capture forensic audit data on any business data that is managed via AFFIRM. This includes products profiles, forms, distributor product rules, and orders. In future versions, it will also include questions and business rules. Here again, ADMServer makes use of the Macro-Language to determine the rules for which audit data is captured. The audit mechanism is a *** step process: 1. Capture Audit Data – For any “type” of AFFIRM transaction (product profile,

form, order, etc.), AFFIRM can be configured with a Macro-Language rule that tells the system when to take an audit snapshot (a full copy) of the transaction.


71

As an example, AFFIRM is configured to capture an audit copy of an annuity order transaction whenever the transaction status changes. The user (or system) that triggered the status change is saved with the audit data, along with a date/timestamp.

2. Capture Audit Deltas (pending enhancement) – Keeping a large number of

audit snapshots in the AFFIRM database would cause rapid database growth. AFFIRM will limit this growth by periodically scanning the business database for audit copies. If it finds a copy, it will look for the next older audit copy of the same transaction. If there is an older copy, then AFFIRM will compare the two and save only the differences between the two in the business database. It will then discard the older copy. After an AFFIRM has completed it’s lifecycle, the audit delta copies will represent the original order, plus a series of transactions that show, step-by-step, the changes that happened to the transaction as its status code changed.

Note: The business requirement set out by the AFFIRM partner was for the capture of detailed (forensic-level) audit data. This means that the audit data is extremely detailed, and can only be reasonably captured as XML.

3. View Audit Data (pending enhancement) – AFFIRM will include an application

that allows the user to search for any given transaction and view the audit history.

4. Transmit Audit Data – AFFIRM does not retain audit data for more than 60

days, so provides for the transmission of this information to AFFIRM partners via an XML message.

5.7. AFFIRM Annuity Archive

The AFFIRM Annuity Archive is sold separately from AFFIRM, but a description is included because the Annuity Archive is highly integrated with AFFIRM.

5.7.1. Industry Background & Solution Overview

Financial services organizations are encountering increased scrutiny and regulatory pressure to ensure that their employees adhere with the various rules and regulations governing the sale of financial products and services to the public. Compliance officers require new systems and tools to help them meet these challenges, and the current business atmosphere also demands more corporate visibility into how to achieve and manage compliance.

5.7.2. Compliance Management Overview

The AFFIRM Compliance Management Framework provides a cohesive solution for compliance management. The AFFIRM compliance lifecycle begins with the enforcement of business rules during AFFIRM™ order entry and extends for the


72

duration of the policy lifecycle by providing a powerful suite of tools focused on business data management & surveillance reporting. The ADMServer Annuity Archive, a component of the ADMServer Compliance Management Infrastructure loads & stores order, policy positions & values, and financial transaction data pertaining to annuity products and provides reporting functionality pertaining to that data. The scope of the ADMServer Annuity Archive (and this document) as part of the larger ADMServer Compliance Management Infrastructure is outlined in red below.

ADMServer

AFFIRM Order Entry Module

1. EnterOrder

Agent

Order

OSJ/Approver

AFFIRM Approval Queues

Compliance ReportUser

3. ApproveOrder

2. Order Submittedfor Approval

4a. TransmitTo Carrier

ADMServer Compliance

Module

Carrier5. TransmitTo Carrier

4b. TransmitTo Compliance

7. RunStandard,Custom,Ad-HocReports

StandardCompliance

Reports

8. TransmitStandard Reports

On Periodic (Daily) Basis

StandardReports Via

Email or OtherTransport

6. TransmitPositions, Values,Financial Activity

InformationOn In-Force

Policies

AFFIRM Validates Order Via Order Entry Process, Warning the Agent or Stopping Order Entry if Business Rules are Violated.

Configurable Approval Queues Provide OSJ and/or Other Approvers with Tools to Review (Including Warnings), Accept, Send for Rework, or Reject Any order.

Compliance Module Provides Standard reports, and mechanism for Distributor-Managed Custom Reports and Ad-Hoc Reports via Enterprise Reporting Solution, such as Crystal Reports.

AFFIRM Captures

Detailed Audit Information for

Forensic Purposes.

ADMServer Compliance Module

AFFIRM Compliance ManagementFramework

Figure 44: AFFIRM™ and ADMServer Compliance Management Overview


73

A Note on Reporting: iPipeline’s ADMServer Framework is designed for metadata-driven management of data; it is not an enterprise reporting solution. Since there are a number of readily available solutions in the market, and because a number of our clients have already adapted such a solution, iPipeline has chosen the strategy of including a limited number of standard surveillance/compliance reports, and to incorporate a 3rd-Party solution for Distributor-specific and dynamic reports, such as ad-hoc reports. Crystal Reports is the standard reporting solution for Annuity Archive implementations that are hosted by iPipeline. For installed solutions, Crystal Reports is available as an optional add-on.

AFFirm Annuities Product Guide 8-21 including the many riders and features available with these...

Documents

Transcript of AFFirm Annuities Product Guide 8-21 including the many riders and features available with these...