AFFIRM Physical Components

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.

• 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.
• 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 to control the configuration and timing of some units of work done by the AFFIRM system.
• 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.

Feed Management Servers (FMS)

Feed Management Servers (FMS) are the “workhorse” of the AFFIRM implementation. FMS manages all batch processing through Processors, which may be organized into scheduled or triggered Events. Examples of work performed by FMS include:

• 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 format (ACORD NBfA) and saved in the Distributor business database prior to the initiation of an order entry session.
• 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 performed by FMS.
• 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).
• 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 the business database.
• The Application of Business Rules – Each time data is entered by a user via the interface, uploaded to the system, or received as a message/response to a system request, it must first be vetted against ADMServer macro-language business rules.

Web Servers

Web servers host the following:

• The user-facing Web applications that Distributor BAs, Carrier BAs, Agents, Approvers, and other users see when they interact with AFFIRM.
• 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.
• The 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.