In addition to the various enhancements made throughout the Lifecycle Management Suite, new core functionality has also been introduced to increase productivity and efficiency in the connection between the Lifecycle Management Suite and the following core interfaces:
- Corelation KeyStone
- Symitar
Corelation KeyStone
Reference the table below for an overview of the enhancements made to the Corelation KeyStone interface in the 15.02 Lifecycle Management Suite release:
| Feature | Description |
| Collateral Insurance Information | The Corelation KeyStone interface now supports the ability to send collateral insurance information to KeyStone during disbursement. Prior to this enhancement, host values to send the collateral insurance information for the collateral on a loan application were not supported. Now, if COLLATERAL_INSURANCE host values exist, a request to create the insurance record for the collateral on a loan application is sent to KeyStone at time of disbursement. |
| Support for Passing Additional Person Identification | The Corelation KeyStone interface now provides financial institutions with the ability to store additional instances of information within the Keystone core. With this enhancement, institutions are able to send additional values for fields in the PERSON_ID table to KeyStone during disbursement. Previously, additional values for the identification fields could not be sent to KeyStone. Now, additional values are sent to KeyStone for each field in the PERSON_ID table that includes a value for the Unique Identifier. When a rule is written using the Set Applicant Host Value template, entering a value in Field 2 for the Unique Identifier creates an additional field within KeyStone to hold the supplemental identification data. When the Set Applicant Host Value rule template does not include a value in Field 2, the direct mapping for the field is overwritten. |
 |
For more information on the above enhancements, please see the Corelation KeyStone Connector Guide as well as the Field Mapping document for Loan Origination. |
Symitar
Reference the table below for an overview of the enhancement made to the Symitar interface in the 15.02 Lifecycle Management Suite release:
| Feature | Description |
| Bypass Account Number Generation from Core |
The Symitar interface now allows institutions to bypass the core processor's standard method of generating member account numbers. Prior to this enhancement, the system only supported the ability to create a new membership account using the core processor’s standard functionality to assign the next available account number. Now, system administrators are provided with the option to author custom code in the API and define a custom process for generating member account numbers at their institution.
To support this functionality, a new flag field titled BypassAccountNumberGeneration has been added for screens and rules to indicate that the standard method of generating member account numbers should be bypassed during the application process. This field is set via rules and displays as read-only when configured to appear in an Applicant screen.
A new Pre-Create Member Account Number event has also been added to Event Processing to be paired with the existing Execute Custom Code action. This event is raised upon execution of the Create Member Account Number action, manual generation of a member account number within the Change Account/Loan Number screen or when an application is disbursed.
With this feature, when the BypassAccountNumberGeneration field is set to true, and the Create Member Account Number process is called in an application, the Pre-Create Member Account Number event fires to execute the custom code and return the account number defined by the institution. |
| Import joint liabilities based on Loan Name records and/or ECOA codes. | The Symitar interface now supports the ability to import joint liability information based on the Loan Name records and/or ECOA codes for an account. Prior to this enhancement, the Lifecycle Management Suite identified joint owners based on the presence of an Account Name record and imported all liability information for both the primary and joint owners. Now, the Lifecycle Management Suite is able to filter the liabilities that are imported for a joint owner by looking at the Loan Name records and/or ECOA codes on an account to determine whether or not a liability should be imported for a joint owner. |
|
For more information on the above enhancement, please see the Symitar Connector Guide as well as the Field Mapping documents for Loan Origination. |