This interface in Accenture Life Insurance Platform (ALIP), provides the ability to an Agent or an customer to add/update a customer’s recurring withdrawal Arrangement information.
The following options are presented for data of the transaction:Frequency of the Withdrawal (once, monthly, quarterly, semiannual, annual), Method of Withdrawal (Dollar or Percentage), Amount (total amounts as well as the amounts from the individual funds).There are two methods of withdrawal allowed -
• Check
• EFT
The effective date of the transaction will default to the current system date.
The below list of products are in scope for this operation.
• Deferred Annuity
• Immediate Annuity
• Universal Life
| TR ID# | Technical Requirements |
| TR1 | ACORDv2.36 shall be used to communicate. |
| TR2 | ACORD Tx 107 “Holding Transaction tc=107” should be used for scheduling the Systematic Withdrawal event to support the business use cases. |
| 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 success the response will be sent for confirming the process. |
| TR5 | Q-switch needs to be run, while processing any event |
| TR6 | A response time of 3 seconds or less is expected. |
| BR ID# | Business Requirements |
| BR1 | Client requires the ability to invoke a service within ALIP to add a Systematic Withdrawal Event |
| BR2 | Client requires the ability to invoke a service within ALIP to update a Systematic Withdrawal Event |
| BR3 | Future and expired events will not be available in the response even if it is processed. Only the current events as of current system date will be returned in response |
| BR4 | Service should return a success or failure message depending on the outcome of processing. |
• The external system would fire the REST URL with the JSON message containing the arrangements information to be retrieved/updated/deleted on the request queue.
• ALIP webadapters would pick up, process the message, convert it into XML format, and posts it onto the ALIP request queue.
• ALIP process 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 arrangement information, existence of the contract id in ALIP etc.
• Post the necessary validations, it would invoke the necessary ALIP APIs/workflows to create/update/delete or retrieve the necessary arrangements information from the database.
• The arrangement information in case of a “GET” request, or the status information incase of a create/update/delete (POST/DELETE), 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.
Withholding information is available for Owner and Primary roles as part of response based on enabling configurable property in ALIP.
• The transaction generated from this arrangement, is for scheduled Withdrawal, where funds are requested from a single subaccount or a combination of subaccounts.
• Upon receiving the request, ALIP system checks if any pending requirements for the transaction need to be generated based on the rules specified in Business Configuration.
• If there are Pending requirements, they will have to be satisfied or waived before the next steps in the workflow are executed.
• If there are no pending requirements, or when the requirements have been satisfied or waived off, the transaction is placed in the “Pending” status.
• During the next nightly batch cycle, next steps in the workflow are executed to validate and perform the required actions on the contract.
• If the validations are successful, money will be be withdrawn from specified accounts and the net face value of the contract, will be reduced by the amount specified in the request. ALIP system will show a status of “Completed” for the transaction. The value of subaccounts will go down to reflect the amount withdrawn.
• Based on the method of Disbursement (Check/EFT) the request is forwarded to appropriate workflow and a request is created to transfer the money.
• If the validations fail, the appropriate error messages will be displayed on the ALIP system next to the transaction request. The status of transaction will reflect the same as in “Error”.
None
It is assumed that the incoming message from the calling system, will contain the required the RequestType, TransType, TransSubType within the request header provided by the external system to ALIP.
NA
| Error | Error Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The Systematic Withdrawal Scheduled Event Add/Update call was successful with details being returned in the output | 1 | Success | Informational | TXLife/TXLifeResponse/TransResult/ResultCode/@tc =1 |
| #2 | The Systematic Withdrawal Scheduled Event Add/Update interface could not find any matching contract id record in ALIP. | 5 | Internal Error | Informational | TXLife/TXLifeResponse/TransResult/ResultCode/@tc =5 |