This API allows an external system to post a New Business Submission request for an ‘Annuity’ or ‘Term’ or ‘Life’ Product. External systems can either use a SOAP based web service or REST mechanism to send ACORD request to this API. This API in ALIP, upon receiving the ACORD request performs validations and if they successfully pass, an application will be processed and submitted successfully in ALIP database. Acknowledgement will be sent back to client system, indicating the successful receipt of the incoming ACORD 103 request. If there is any failure in validations, application will either be rejected or saved as unsubmitted application or submitted as NIGO application depending upon the severity of validation failure.
Submission process internally kicks off the ‘Underwriting’ workflow for the newly submitted application, performing the the underwriting.
XSD Validation: If there is any XSD validation failure, the interface will reject an application by logging an integration failure in ALIP. It will not save the Application in ALIP database and send a Failure response back to the calling system, with the appropriate Error message.
Duplicate App Validation: If the XSD validation does not fail, the interface will check if there is already an Application, present in ALIP with the same External Policy Number, which matches the one coming in the input request. If present, the interface will reject an application by logging an integration failure in ALIP. It will not save the Application in ALIP database and send a Failure response back to the calling system, with the appropriate Error message.
Business and Product Validation: If the Duplicate App validation does not fail, the interface will send an Acknowledgment of receipt and perform the Business and Product validations.
If any of the Business and Product validations produce an error of HIGH severity, the interface will fail. Application will be saved in Unsubmitted status in ALIP database. No further response will be sent back to the calling system in this case. An Integration Failure will be logged in ALIP. Interface will not validate LOW errors.
If any of the Business and Product validations do not produce any HIGH severity error, , the interface will submit the application.
The interface will not log any Integration Failure in this case and will be displayed with Success status in the ALIP Integration History page.
The following products of Accenture Life Insurance platform are in scope of this interface.
| Product Type | Product Name |
| Deferred Annuity | Variable Annuity |
| Universal Life Insurance | Standard Flexible VUL |
| Term Life Insurance | Level Term |
| Whole Life | WL Config |
| TR ID# | Technical Requirements |
| TR1 | ACORDv2.36 shall be used for communication between ALIP and external system. |
| TR2 | External systems can either use a SOAP based web service or REST mechanism to send ACORD request to this API. |
| TR3 | The interface should perform basic validations (XSD and Duplicate Policy Number check). If validation fails, an Integration Failure will be logged in ALIP and an Error response will be sent back to the calling system. The integration will stop the execution. If validation passes, the interface will send an Acknowledgment of receipt. |
| TR4 | The Interface will perform the processing for Clients, Product, Rider/Benefit, Exchange/Replacement depending on product type as described in Processing section. |
| TR5 | After the processing is successful, the Interface will invoke ALIP Background Workflows to perform Business and Product Rules validation. If the Business and Product Rules validations pass, the interface will invoke the ALIP Background Workflow for Application Submission. |
| TR6 | If any of the Business/ Product Rules validations produce HIGH errors, the interface will not invoke the ALIP Background Workflow for Application Submission. It will save the application in ALIP database in unsubmitted. |
| TR7 | For any other errors that occur in the submission process, the application should be saved as an unsubmitted application. This will be captured as an Integration Failure and recorded in the ALIP Integration database tables. |
| BR ID# | Business Requirements | Interface Design Traceability | Test Case Traceability |
| BR1 | This API should perform XSD validations on the received data. | ||
| BR2 | As part of this submission, below components of the application will be handled and saved into ALIP.Primary/Child Insured/Annuity DetailsOwner/Joint/Contingent Owner DetailsPrimary/Contingent Beneficiary DetailsAgent Features InformationPremium InformationExchange replacement Information Rider/BenefitForms DataData Mapping spreadsheet explains how each of the received fields will be saved and processed within ALIP. | ||
| BR3 | Any invalid Product/Fund/Arrangement/Exchange or Replacements should return an error in the response and no application be creted in ALIP. | ||
| BR4 | In case of the reissue the Interface should reject the request if there is any processed ALIP financial transactions on the corresponding policy. | ||
| BR5 | A Policy Reissue indicator will be provided in the Application Submission request and saved into ALIP. |
The following is the high-level description of New Business Application Submit Integration process.
ALIP Process-server will receive SOAP based ACORD 103 request through ALIP Inbound Gateway.
New Business App Submit Spring Chain interface will validate the received ACORD 103 XML against the Inbound XSD.
Any XSD validation Failure that occurs will be treated as a HARD failure stopping any further processing of the ACORD 103 request by ALIP. Upon encountering an XSD Failure, this interface will prepare a Negative Acknowledgement indicating the Failure to process the received ACORD 103 request and returns the NACK response to the calling system. Along with returning the NACK Response, Communication Header will be updated to indicate the Integration Failure stopping any further processing of the request. Whenever an XSD Validation failure occurs, it is to be noted that, received ACORD 103 XML relevant application and any of its components will not be saved in the ALIP.
If no XSD validation Errors are found, then the spring chain validates the client Policy Number uniqueness to make sure there is no application already present in ALIP database. This process of check Duplicate Policy Number is configurable and property driven, can be skipped as per requirement.
If any application is found in ALIP with the received client Policy Number, then the request will be rejected with a failure and a NACK response will be sent back to the calling system indicating the Duplicate App Control Number. The Communication header will be updated to be a Failure and any further processing will be terminated.The application will not be saved in ALIP database.
If there is no existing record found for client Policy Number, then this spring chain will translate the ACORD 103 XML to the ALIP XML format. An Acknowledgement will be sent to the calling system indicating the successful receipt of a message.
The Interface will load the existing client from ALIP database and perform the client information comparison between the received client data and received data as described in Client Processing section.
After the Client Processing is successful, the Interface will perform Business and Product validations before submitting the application to ALIP. The Business validations are documented in the BRDs and they will be executed as a part of Pre-Submission rules for the application.
Interface will not validate LOW errors. The interface will allow an application to be submitted.
If any validation results in HIGH severity error, the interface will NOT allow an application to be processed further but save it as an unsubmitted application.The interface will always save an application irrespective of any Business or Product validation errors, but the submission will occur only if the validation results in Success.
If there are any other errors occurs in the submission workflow, this interface will save the application as in Unsubmitted status
ACORD 103 request will contain Product code mapped to “/Holding/Policy/ ProductCode” path..
The Product code will be used to retrieve the corresponding ALIP Product Id.
Using the retrieved ALIP product Id, this interface will load the required Product Information from ALIP database.
The mapping between client’s Product Code and ALIP Product Code is provided as part of the Data Mapping or Interface agreement.
Before associating a client with the application being submitted, ALIP verifies if that client already exists in the system. To perform this verification, ALIP uses the Client Type and SSN/Tax ID of a client to compare with the in-house client information and if the client already exists, then corresponding client information, existing in ALIP, will be used on the application being submitted. Otherwise, a new client will be created in ALIP and used with the application.
For every existing client, ALIP will also verify if the provided permanent and Mailing address is already existing in ALIP by matching following fields.
Address Type, Address Line1, Line2, Line3, City, State, Country, Zip
If the address already exists, then the existing address is used for the client on the application being submitted. If not, it will create a new address.
If the client is existing and there is a difference in value in any of the following fields, then existing customer details will be used.
Integration indicates that the client already exists in ALIP based on SSN and client type match. If client exist in ALIP-
For Individual clients below fields are compared:
First Name, Last Name, Middle Name, Suffix, DOB, Email and Gender
For Company and Trust below fields are compared:
Last Name
If mismatch exist in the above given fields, requirement would get created with instructions-
"The following client information does not match for client ID: <###>.
Below is the list of requirements that will get created for existing customer data mismatch.
| Requirement Name | Requirement ID |
| Existing Owner Update | INT-01-Req1 |
| Existing Joint Owner Update | INT-01-Req2 |
| Existing Primary Insured Update | INT-01-Req3 |
| Existing Primary Beneficiary Update | INT-01-Req4 |
| Existing Contingent Beneficiary Update | INT-01-Req5 |
| Existing Contingent Owner Update | INT-01-Req6 |
| Existing Rider Insured Update | INT-01-Req7 |
If there is a difference in any other fields apart from the ones mentioned above, no validation error/requirement will be generated, and application will get submitted.
If client already exist in ALIP, Interface will use the existing client data for submission and ALIP will contain the existing client’s data after submission. Existing Clients cannot be changed through this Interface.
New Business Interface will expect the receipt of all the Search and Licensing related fields for each Agent, along with Allocation Percentage of in 103 inbound requests. Interface will not integrate with external systems to retrieve any further Agent information. Mappings of these fields are provided as part of the Data Mapping document.
If the Agent exists in ALIP, then it will be attached to the application, but the Agent details will not be updated.
If the Agent does not exist in ALIP, it will be added in ALIP and then attached to the application.
Percentage for each Agent must be greater than 0%. All the agents entered on the application must total to 100% split.
Feature & Feature Option Details:
ALIP will receive the Feature options details as a part of the incoming ACORD request only if minimum one agent is present on the application. Following are Feature options supported for the above mentioned products in ALIP:
Commissions
Surrender Charge
Free Withdrawal Charge
ALIP supports different payment options depending upon the product. Received ACORD 103 request’s Payment type information will be verified against the payment types applicable per product. They are converted to ALIP XML format and associated with the application being submitted.
Whenever ALIP receives an EFT payment mode in the incoming ACORD 103 request, it is expected that the external systems do send the Bank information only one Bank information is expected. ALIP will use the Bank Name to search the Bank in the ALIP system. If a Bank is already found that that will be associated with the Application. If the Bank is not found then a new Bank will be created in the ALIP. This API uses internal ALIP Bank ABA Number validation only.
ALIP supports the above mentioned Scheduled Events on the application being submitted. For an EFT Scheduled Event, ALIP expects the incoming ACORD request to also provide Premium Banking information as a separate Holding block. If the Holding block for the Bank information is missing, it will generate a validation error.
Fund details per client product will be configured in ALIP during product configuration phase, which can be used while submitting the application. ALIP, currently has the logic to load the applicable Funds for a particular product.
ALIP will receive Fund Code and its percentage as part of the incoming ACORD request in the ‘Investment’ block ALIP will validate the following details:
If the total percentage of all the incoming funds is 100%. If not then, then a failure response with appropriate validation error will be send back to the external system.
If the incoming Fund Code is valid and configured for the current product applicable. If any of the Fund code is not valid or not supported, then a failure response with appropriate validation error will be send back to the external system.
ALIP New Business Processing Interface will support receiving Primary and Contingent Beneficiaries and establishing them on the Application submitted in this role.
Following are the Types of Beneficiaries that can be supported by the interface.
Individual
Company
Trust
Clause
This interface will support a maximum of 10 Beneficiaries for each class of Beneficiary i.e. Primary/Secondary.
Exchange Replacement details will be coming as part of the
| 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 |
For Term Life and Whole Life :
The interface will use the Carrier code and retrieve the Company Name from ALIP database. Note that the Exchange Replacement Companies will be loaded into the ALIP database as a part of Replacement Company Load batch process.
The interface will count the Replacement Company blocks in the request and populate the tag for “Number of different Replacement Companies listed on the Application.” If the interface is not able to match any Replacement company from the request, then the requirement “No Replacement Company Found” will be generated on the application. Exchange replacement data for which replacement company does not match, will not be saved in ALIP.
ACORD 103 request will contain one or many Rider codes mapped to “/Holding/Policy/Life/Coverage/ProductCode” path.
The interface will use the Rider code to retrieve the corresponding ALIP Rider Code.
Using the retrieved ALIP Rider code, this interface will load required Rider Information from ALIP database.
The mapping between client’s Rider Code and ALIP Rider Code is provided as part of the Data Mapping or Interface agreement.
The Interface will create and submit New Business application in ALIP per received ACORD 103 request.
Per each customer implementation, below actions are expected accordingly:
The IGO validations need to be modified/enchanced by the client teams implementing or extending this API as per the client needs.
Generation of pre-issue requirement in case of IGO validation failures, is subjective to client business requirements.
Any changes to Unique Client Identification process will require code enchanement to be implemented by the client teams implementing or extending this API.
The supported Features, Feature Options, Riders, Benefits are assumed to be added or modified through the product configuration.
Client upstream system will perform following necessary Integration processing on the data before sending it to ALIP and prepopulate them in the request for submission. ALIP will not have to make any outbound calls for them during the 103 processing.
Agent Search
Upstream system will be responsible for data validation before sending the request for processing.
ALIP would perform following integration with external systems during the underwriting processing
Agent Validation
Get Premium Quote
Vendors
Any failures in XSD validation will result in an Integration Failures. ALIP will reject the request with appropriate error response without Saving any information in ALIP. Client needs to monitor such Integration Failures and needs to troubleshoot any failed applications using ALIP logs.
Interface will not validate LOW errors.
The application can only be processed via the NB Submit Integration point once by ALIP. Any further updates need to be performed within ALIP.
As part of New Business Submit application interfaces, it is expected that ALIP will receive complete application information. ALIP do not validate all the required fields mentioned on the data elements sheet. There will be fields that are defaulted by ALIP. Some fields may result in pre-issue requirements being generated. These are noted in the data elements spreadsheet.
It is assumed that, No Image related Attachments Processing is in scope for this interface.
All the page end rule groups which get invoked during app entry in the front end would also get called in the integration to validate each field.
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The Success acknowledgement message will be displayed in response queue. | 1 | Success | Informational |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | New Business –Submit interface was NOT successful due to technical errors. | Internal Error | Fatal | ||
| #2 | New Business –Submit interface was NOT successful due to any Rule validation failure. | Validation Error | Fatal | ||
| #3 | New Business Submit interface was NOT successful due to validation errors (XML not conforming to the XSD) | 100 | XSD Failure | ||
| #4 | New Business –Submit interface was NOT successful because Contract is already present in ALIP | 119 | Duplicate Policy Number Found. | A validation error ‘Duplicate Policy Number Found.’. Request will not be processed further, and application will not save in ALIP. | |
| #5 | New Business –Submit interface was NOT successful due to minimum required data for application submission NOT provided | 100 | Validation Error | Any Validation error with HIGH severity in below processing.Minimum required data for client processing[Validation Message] - Respective error message would come. For Example: Primary Insured’s GovtID is required for further processing.Primary Insured’s Last Name is required for further processing.Primary Insured’s GovtID should be 9 digits only. | |
| #6 | New Business –Submit interface was NOT successful due to minimum required data for application submission NOT provided | 100 | Validation Error | New Business Pre-Submission Background RulesIf Business/Product validation high errors comes, application would NOT be submitted but saved as Unsubmitted | |
| #7 | The reversal or application update or policy re-issue process fails | 101 | Policy cannot be Reissued as there is one or more transaction(s) already in processed status. | Fatal | A validation error ‘Policy cannot be Reissued as there is one or more transaction(s) already in processed status’. Request will not be processed further, and application will not save in ALIP. |
| #8 | Policy number is empty or invalid | 101 | Valid policy number is mandatory when reissue indicator is set | Fatal | A validation error “Valid policy number is mandatory when reissue indicator is set”. Request will not be processed further, and application will not save in ALIP |