New Business Application Save

Request/Response & Json Schema

Overview

This interface provides the ability to save in progress application in ALIP. The interface allows third party applications like eApp/ portal & etc to save application data which can be partial or complete. The interface allows user to edit application data multiple times before finally submitting the application to ALIP for contract creation. Once the application is submitted, this interface does not allow to update the application further.

The data coming in the request, is converted from ACORD format to ALIP canonical form before saving to the database. The basic data type validations like data type and length validation will be called from the service. This interface will not do any business validation on input request.

New business application save only allows application to be saved in ALIP. For new business processing to start on the saved application, the New business submit interface need to be used.

Product Type Product Name
Deferred Annuity Variable Annuity
Universal Life Insurance Standard Flexible VUL
Term Life Insurance Level Term

Technical Requirements

TR ID# Technical Requirements
TR1 ACORDv2.36 shall be used to communicate.
TR2 New Application Saver Request “integrationPoint=NEW_APPLICATION_SAVE” should be used for executing interface
TR3 Interface must always return an error code and desc in the event of a error while saving data in in database in addition to HTTP response code.
TR4 For a sucessful transaction a return code of 200 is returned.

Business Requirements

BR ID# Business Requirements
BR1 New Application data can be saved & updated using this interface
BR2 New Application data can be updated using this interface by providing application id/ contract number/ case reference number
BR3 The interface will save the application in unsubmited state.
BR4 The interface will only allow updating application in unsubmitted state.
BR5 The interface will do only data type validation and not business validation.

Process Flow Diagram:

Process Flow Description

This API can be invoked either using a REST / webservice. If a Webservice mechanism is chosen, the ACORD 103 request must be wrapped up with Integration point as the root node and then wrapped by the SOAP Format and sent to ALIP. Otherwise if the mechanism chosen is the REST, then the JSON format ACORD 103 request must be sent to rest url of the ALIP.

ALIP SOAP/REST gateway converts incoming ACORD request in JSON or SOAP format to ACORD XML and puts on ‘alipRequestQueue’.

ALIP process server will pick up the message from ‘alipRequestQueue’, perform the XSD Validations on the received request. If the XSD validations failed, then an Error response comprising the XSD Validation Failures, will be sent back to the alipResponseQueue. If the received request completes the XSD validations successfully, then it will move to the next step.

Assuming the XSD Validation is successful, ALIP API transforms received message into the ALIP canonical format, and processes it further. Part of this processing for various components is as follows:

Product Details:

ALIP will load the required product information based on the product description received in the input ACORD request. ALIP needs external systems to send this product description so that it can load the corresponding product information from ALIP database on the application being saved.

Client Details:

Depending upon the product requested in the input ACORD 103 request, corresponding Roles would be supported per below table.

Variable Annuity (Deferred Annuity) Standard Flexible VUL(Universal Life) Level Term (Term Life)
OwnerPrimary BeneficiaryAnnuitantAgentJoint OwnerJoint Annuitant OwnerInsuredPrimary BeneficiaryAgentJoint Owner OwnerInsuredPrimary BeneficiaryAgentJoint Owner

Per each role provided above, following client types are supported as shown in below table.

Client Role Client Type
Owner Individual
Primary Beneficiary Individual, Trust, Company orClause
Annuitant/Insured Individual
Joint Owner Individual
Joint Annuitant Individual

Agent Processing:

ALIP will receive the Agent ID as part of the incoming ACORD request. Based on this Agent ID, ALIP will search for an existing Agent in the ALIP database.

If an agent is found, ALIP will load the agent details and attach it to the application being saved.

If no agent is found, even then no error is set back in response.

Feature & Feature Option Details:

ALIP will receive the Feature options details as a part of the incoming ACORD request. Following are Feature options supported for the above mentioned products in ALIP:

Commissions

Surrender Charge

Free Withdrawal Charge

Exchange Replacement Details:

Exchange Replacement details will be coming as part of the block with attribute ‘DataRep’ as ‘ReadOnly’ indicating that this holding block represents the policy which is being replaced. Details of the company will be fetched from this referenced block. Below are the details currently supported by ALIP for Exchange Replacement handling.

Field Name Data Type Mandatory
Replaced Policy Number String (ContractNumber) Yes
Replaced Company Name String (CompanyName) Yes
Replacement Company Address String (CompanyAddress) No
Replaced Issue Date Date (MM/DD/YYYY) No

ALIP will use the correlation ID saved in the message header, which was received as part of the JMS request to generate the corresponding JMS response, along with the retrieved information. The response will be transformed back to ACORD format and sent back to the calling external system.

Impact on ALIP system

None

Assumptions

Application should not be available in ALIP system or if available then it should not be in submitted state.

Application if available in ALIP then it should not be in locked state.

Per each customer implementation, below actions are expected accordingly:

The supported Features, Feature Options, Riders, Benefits are assumed to be added or modified through the product configuration.

Dependencies

N/A

Request Data Elements

Response Data Elements

Success/Error Handling

Success Success Scenario Description Message Code Message Description Message Type Additional Comments
#1 The New application save interface called with valid request. Got successful response 1 Success Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =1
#2 The New application save interface called with invalid XSD structure request. Failed with error. 5 Internal Error Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5
#3 The New application save interface called and failed with system error. 5 Internal Error Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5
#4 The New application save interface called with request containing application which is in submitted state, then it failed with error 5 Internal Error Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5
#5 The New application save interface called with request containing application which is in locked state, then it failed with error 5 Internal Error Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5
#6 The New application save interface called with request having duplicate TransRefGUID, then it failed with error 5 Internal Error Informational TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5