The purpose of this interface is to receive the claim transactions and creates the appropriate pending/process transactions based on the claim status coming in the inbound request. ALIP interface will receive the details of the death notices for the insureds on policies administered in ALIP and process the death claims and rider claim.The document lists the system impact, changes and testing criteria for this interface
The below list of products are in scope for this operation.
Deferred Annuity
Term Life Insurance
| TR ID# | Technical Requirements |
| TR1 | ACORDv2.36 shall be used to communicate. |
| TR2 | ACORD Tx 1820 “Claim Status Notification tc=1820” should be used for executing claim transactions. |
| TR3 | Interface must always return an error code and desc in the event of a processing failure in addition to HTTP response code. |
| TR4 | For a successful transaction a return code of 200 is returned. |
| BR ID# | Business Requirements |
| BR1 | Claim Status Notification supports three types of claim transactionDCPDBRider Claim(Child Rider Only) |
| BR2 | For 'Death Benefit' Transaction Death Claim Transaction need to be processed first. |
| BR3 | The contract and client/rider needs to be present in ALIP for the data to be returned. |
| BR4 | The Contract should be in the below status to support claim transaction.Active |
The external system would fire the REST/SOAP with the message containing the transaction information to be created or retrieved on the request queue.
ALIP Inbound Gateway would pick up, process the message, convert it into XML format, and posts it onto the ALIP request queue.
ALIP API Processing Server will pick up the message, convert from ACORD to the canonical format, perform the necessary XSD validations, and other basic validations on the completeness of the transaction information, existence of the contract id in ALIP etc.
Post the necessary validations, it would invoke the necessary ALIP APIs/workflows to create or retrieve the necessary transaction information from the database.
The transaction information in case of a “GET” request, or the status information in case of a create, would be generated in XML format, converted to ACORD format, and sent back to the REST layer.
Here, it would be further converted back into the final JSON output format and returned back to the external system.
This interface provides the ability forprocessing Claim transactions on active contracts.
Upon receiving the request, ALIP system checks if client id/rider id provided in the request exists in ALIP and on policy number provided for processing transaction
If claim status tc = ‘1’, then DCP transaction would be created and DOD would be updated for insured on all the associated contracts.
If claim status tc = ‘9’, then DB and DOD transaction would be created for contract provided in the request.
If claim status tc = ‘13’, then Rider Claim transaction would be created for contract provided in the request.
If client id or rider id is not provided in the request , then
DCP transaction would run for insured present in the input contract
Rider Claim transaction would run on rider present in the input contract
If the validations fail the appropriate error messages will be displayed on ALIP system.
N/A
N/A
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The ClaimStatusNotification call was successful with details being returned in the output | 1 | Success | Informational | TXLife/TXLifeResponse/TransResult/ResultCode/@tc =1 |
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The ClaimStatusNotification call was NOT successful due to a technical error or contract not found. | 5 | Internal Error | Informational | TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5 |