The Ownership Transfer interface provided by ALIP, on receiving a request for a Non-Custodianto Non-Custodian Transfer, performs necessary validations, invokes the needed ALIP API, transfers the non-custodian on the contract along with other associated roles, and returns the status response.
Below are the input parameters, that this interface accepts as input:
:
Contract Number
Source Non Custodian Information
Servicing Agent Information
Writing Agent Information
| TR ID# | Technical Requirements |
| TR1 | ACORDv2.36 shall be used to communicate. |
| TR2 | The external system will send an Ownership Transfer request message for a non-custodian, in the ACORD XML format to ALIP Process Server’s Request Queue. (TransTypetc=”186”). This message will be picked up and processed by the ALIP process server. |
| TR3 | The Contract Numberreceived in the requestwill be used to invoke ALIP API for performing the needed Ownership Transfer. If there are any issues finding the contract, it will be returned as a failure response. |
| TR4 | Any failure during the Ownership Transfer will be treated as an Integration Failure in ALIP system and will be stored in the Integration database tables. |
| BR ID# | Business Requirements |
| BR1 | ALIP will apply the following business validations on the input request.Contract should exist in ALIPContract should not be ‘Pending’, not Annuitized, not Restricted and should not have any pending or processed Death ClaimsThere should be no active SEPP Distribution Schedule events on the contract.The source party should be present in ALIPIf Source Party is a non-Custodian then the Target Party must be a non-CustodianAgents sent in the input, should exist in ALIPAllocation percentage of servicing agent should be 100. |
| BR2 | If all the needed validations are satisfied,the interface will terminate existing Servicing Agent ID on the Contract and use the received Servicing Agent ID to create a new Servicing Agent on the Contract with the same percentage. |
| BR3 | All scheduled events (Systematic withdrawal/RMD) on the contract will be terminated post transfer. |
| BR4 | The success or failure response would be transformed back to ACORD format and sent back to the calling system |
ALIP will receive a new request for a Non Custodian To Non Custodiantransfer scenario, on the Alip Request Queue.
The ALIP process server will pick up the message, and use the Contract Number received in the request, to invoke the needed ALIP APIs. If there are any issues in finding the contract, an Integration Failure would be created and stored in ALIP.
If the contract exists in ALIP, additional needed business validations as defined in the Business Requirements will be run, after which the interfacewill terminate the existing Servicing Agent ID on the Contract, and use the received Servicing Agent ID to create a new Servicing Agent on the Contract after performing needed validations and will use the same percentage. Associated scheduled events on the contract will be terminated post transfer.
The success or failure response would be transformed back to ACORD format, and sent back to the calling system.
None
None
An average response time of under 5 secondsis expected for this interface.
NA
| Request Parameters | Description | Mandatory | Allowed values |
| Contract Number | A number which uniquely identifies a Contract within ALIP. | Y | Detailed in the attached Data Elements. |
| Non Custodian Information | Source Non CustodianInformation. | Y | Detailed in the attached Data Elements. |
| Servicing Agent Information | Servicing Agent Information | Y | Detailed in the attached Data Elements. |
| Writing Agent Information | Writing Agent Information | Y | Detailed in the attached Data Elements. |
| Success | Success Scenario Description | Message Code | Message Description | Message Type | Additional Comments |
| #1 | The Non Custodian to Non Custodian transfer is complete and Success response is displayed in Outbound External on Integration History Page | 1 | Success | Informational |
| Error | Error Scenario Description | Message Description | Message Type | Additional Comments |
| #1 | The Non-Custodian to Non-Custodian Transfer request was successful with details being returned in theoutput. | Success | Informational | |
| #2 | The Non-Custodian to Non-Custodian Transfer call wasNOT successfuldue to technicalerrors. | Internal Error | Fatal | |
| #3 | The Non-Custodian to Non-Custodian Transfer call was NOT successful as Contract does not exist in ALIP. | Failure | Warning | |
| #4 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to XSD failure. | Failure | Warning | |
| #5 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to Contract being in a status where non--Custodian transfer cannot happen i.e Pending or Annuitized or Restricted | Failure | Warning | |
| #6 | The Non-Custodian to Non-Custodian Transfer was NOT successful, due to Contract consisting of pending or processed Death Claims | Failure | Warning | |
| #7 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to Contract having active SEPP Distribution schedule events | Failure | Warning | |
| #8 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to non-Custodian not existing in ALIP | Failure | Warning | |
| #9 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to Agent not existing in ALIP | Failure | Warning | |
| #10 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to allocation percentage of agent in input not being 100 or having more than one servicing agent. | Failure | Warning | |
| #11 | The Non-Custodian to Non-Custodian Transfer request was NOT successful, due to source and target parties being of different types | Failure | Warning |