Displays a to identify that the pair includes a time delay.

For more information on the execution of delayed event/action pairs, please see the Executing a Delayed Event/Action Pair section in this topic.

When an event/action pair includes a time delay, the status of the pairing can be viewed within the Delayed Actions Report tab. Please see the Delayed Actions Report section in this topic for more information.

Displays a  to identify an event/action pair as system-defined.

For an overview of the system-defined event/action pairs available, please see the System Defined Event/Action Pairs section in this topic.

Select the check box to enable a time delay for the event/action pair. By default, this field is disabled.

Synchronous events cannot be set on a time delay. If this field is enabled for an Event Processing pair that is assigned a synchronous event, an error message is received that prevents the event/action pair from being created. When an event type is synchronous, a  displays under the Synchronous column in the Events tab. For a complete list of the synchronous events, please see the Events section in this topic.

• Days
• Hours
• Minutes
• Seconds

This field is disabled until the Delay Action(s) check box is selected.

Enter a whole number to identify the duration of the delay type. For example, if configuring an event/action pair to include a time delay of three days, select a Delay Type of Days and enter a value of 3 for the Duration.

This field is disabled until the Delay Action(s) check box is selected.

Enables the ability to edit an event assigned to the Event Processing pair. This button is only enabled for those events that require additional information, such as Field Changed. 

Please see the Editing Events section in this topic for more information on the event types that can be modified.

Displays a to identify an event as synchronous. If the event type is not synchronous, a blank check box is displayed for the event.

Please see the Events table below for an overview of the synchronous events in Temenos Infinity.

Raised directly after the creation of a new application in Temenos Infinity.

This event provides the ability to set fields, or apply a change, once an application is created.

Raised at the same time an application is created in Temenos Infinity.

This event occurs simultaneously with application initialization to populate values from the Applicant Import, and/or apply a change, prior to the application being created in Temenos Infinity.

Raised whenever a document is attached to an application.

This event is triggered each time a document is attached to an application. If desired, a rule can be written to stop the action from executing if the Document Source does not equal a certain value, such as that of a particular third party connector. For more information, please see the Send Notifications to Notification Group rule template example in this guide.

Raised whenever Next is clicked on the Workflow screen.

Due to the way screens function in a virtual application, the Next on Workflow Screen event cannot be used for Event Processing in Virtual Capture.

Enables the ability to edit an action assigned to the Event Processing pair. This button is only enabled for those actions that require additional information, such as Execute Rules and Execute Code. 

Please see the Edit Actions section in this topic for more information on the action types that can be modified.

This action automatically disburses the application if:

• The application is not locked by a Temenos user.
• If the IsLoanReadyForDisbursement and/or flags are selected.

If the application is locked: The auto disburse action stops. A notification stating "the application is ready to be automatically disbursed" is added to the application.

This action triggers a web service call that sends application information to the Consumer Financial Protection Bureau’s Rate Spread calculator, and provides the ability to automate a rate spread calculation for HMDA regulations.

In order for this action/web service call to successfully execute, the following information is required:

• ActionTakenType must have a value equal to Application > HMDA > Action - Code
  • For a Rate Spread to return, the actionTakenType must be 1, 2, or 8. All other actionTakenTypes returnApplication > Term a Rate Spread result of NA

    1 – Loan Originated 2 – Application Approved but not accepted 3 – Application denied 4 – Application withdrawn by applicant 5 – File closed for incompleteness 6 – Loan purchased 7 – Preapproval request denied 8 – Preapproval request approved by not accepted

• LoanTerm must have a value equal to Application > HMDA > Introductory Rate Term.

  The FFIEC calculator accepts loan terms in years (not months). Prior to sending out the calculation, this value is converted to years. For example, a LoanTerm of 3.75 is rounded up, and sent as a value of 4. The Application > HMDA > Introductory Rate Term field is not populated by the system, and must be set by the institution either automatically through rules, or manually in a screen.

• AmortizationType must have a value equal to FixedRate or VariableRate.

  This is based on the Application > Is Variable Rate flag. If the Application > Is Variable Rate flag is true, this is set to VariableRate If the Application > Is Variable Rate flag is false, this is set to FixedRate.

• APR must have a value equal to Application > Disclosure APR.
• lockInDate must have a value equal to Application > Rate Set Date.
• reverseMortgage must have a value equal to 2.

  This field is always set this to 2.

When this action/ web service call executes successfully, the rate spread calculation is stored in Application > HMDA > Rate Spread.

The Application > HMDA > Rate Set Date field is not automatically set based on the calculation of the FFIEC rate spread. This field may be set manually, or via rules.

If an error is returned from the Rate Spread Calculator, the error is displayed as a Notification in the application. If fields are missing, the notification includes the field names.

If the application is for a non-account holder, this action automatically creates and returns an account number for the application's primary applicant based on the following logic:

• If the Host Supports Person Account Number Auto-Generation parameter is set to "Yes" in the Origination page in System Management, and the Account Origination module is not active, the system executes code to create person account using Get New Member portion of interface specified as the Disbursement Method.
• If the Account Origination module is active, the system creates the member account number based on Account Origination code.
• If the Host Supports Person Account Number Auto-Generation parameter is set to "No" in the Origination page in System Management, the system stops executing the action.
• If the primary applicant is a current account holder, and the value of the NewMembership field is Create New Member Account, a new member account number is created for the primary applicant in the core. When a new member account is created, the primary applicant's account number is set to the new account number in the application and the value of the NewMembership field is set to New Member Account Created.

Additionally, queue routing rules execute if the application is not currently in process by a user.

Executes the calculation process in an application.

It is highly recommended to consider the order that processes occur in an application when assigning the event that triggers this action. For example, if this action is paired with the Application Created event, since no loan terms are set at that stage of the application, errors will be received when the Execute Calculate Application action executes. Similarly, if paired with the Field Changed event, when Save and Next is clicked, the next screen could load before the event is complete, which will override the calculation occurring with the action.

The rules executed via this action are able to perform the following actions:

• Update data on the application
• Send Emails

Users are not able to return messages since the actions are processed asynchronously.

This action assigns a new loan and/or account number/suffix based on the following logic:

• If the Host Supports Account Number Auto-Generation parameter is set to "Yes"  in the Origination page in System Management, and the Account Origination module is not active, the system executes code for the interface specified as the Disbursement Method.
• If the Account Origination module is active, the system assigns the next based on Account Origination code.
• If the Host Supports Account Number Auto-Generation parameter is set to "No" in the Origination page, the system stops executing the action.

Additionally, queue routing rules execute if the application is not currently in process by a user.

This action coverts each "in use" credit report on an application to a PDF, and attaches it to the application.

When a credit report is attached to an application, it is saved using the following naming convention:

• <ApplicantFullName>_<ApplicationNumber>_<LoanSuffix>_<AccountNumber>_<CreditReportDate>
  
• If multiple applicants are linked to the attached credit report, the following naming convention is used:
  • <Applicant1FullName>_<Applicant2FullName>_<ApplicationNumber>_<LoanSuffix>_<AccountNumber>_<CreditReportDate>
    
• If this action triggers before the Loan Suffix or Account Number is generated, these fields are excluded from the file name, and the following naming convention is used:
  • <ApplicantFullName>_<ApplicationNumber>_<CreditReportDate>

If a credit report attachment currently exists on an application, the existing credit report is overwritten when this action is triggered subsequent times.

This action generates new loan and/or account documents. As part of this action, the following processes occur:

• Document Selection Rules execute to assign the document set to the application as well as any included account products.

  When a document set is generated for an account application, account product tags are added to the IMM XML for the application, as well as each account product.

• Checks if the IsLoanReadyForDisbursement and/or flags are selected.
• Checks the status of the document set.
• Checks that the assigned Document Set was not already generated for the application.

  As part of this check, the document delivery method is also verified to allow the same version of a document set to be regenerated when the versions include different delivery methods.

• Sends appropriate flag to IMM based on Document Delivery Method.
• Executes queue routing rules if the application is not currently in process by a user.

While users are able to manually regenerate all document sets, there is logic in place that prevents a document set from being regenerated during execution of the Generate Documents action if certain criteria is met. Document sets are NOT regenerated with the Generate Documents action when the following are true: The status of the document set includes a value other than Expired.  Document sets with a status of Expired are able to be regenerated with the Generate Documents action. The document set was previously generated for the application. If the current document set matches an existing document set, and includes the same delivery method as the version previously generated, the current document set is not regenerated with the Generate Documents action. If the current document set matches an existing document set, but the document delivery methods are different for each version, the current document set is regenerated with the Generate Documents action.

This action coverts each "in use" MLA Report on an application to a PDF, and attaches it to the application.

When an MLA Report is attached to an application, it is saved using the following naming convention:

• <ApplicantFullName>_<ApplicationNumber>_<LoanSuffix>_<AccountNumber>_<CreditReportDate>
  
• If multiple applicants are linked to the attached MLA Report, the following naming convention is used:
  • <Applicant1FullName>_<Applicant2FullName>_<ApplicationNumber>_<LoanSuffix>_<AccountNumber>_<CreditReportDate>
    
• If this action triggers before the Loan Suffix or Account Number is generated, these fields are excluded from the file name, and the following naming convention is used:
  • <ApplicantFullName>_<ApplicationNumber>_<CreditReportDate>

If a MLA Report attachment currently exists on an application, the existing MLA Report is overwritten when this action is triggered subsequent times.

If a report is marked as both Use for MLA Check and Use for Credit Report, one document is created under the Document Classification of Credit Report, even if both actions execute.

This action uses configured Event Processing rules to retrieve collateral information from core liabilities to populate within the Liabilities screen and panel, as well as the Add-On/Refinance panel.

The ability to populate collateral data with this action is only supported for certain cores. For more information, please see the applicable core connector guide for the institution.

This action generates the cross-sells for the application.

If creating a custom rule to process cross-sells, it is recommended that the StopCrossSellAction rule is assigned to the event pair in order to prevents cross-sell opportunities from generating on applications and child applications.

This action processes Loan Covenant rules based on the configured event types. When triggered, all rules authored under the Loan Covenants category in Rules Management are executed, and new loan covenants are added to the application based on the rule criteria.

When this action is triggered, the system reviews all existing loan covenants on the application, and removes any covenants that were not manually added (Is Manual = False), prior to adding the new loan covenants from the rule(s).

This action initiates a search within the core for existing account records, if the applicant indicates that he or she is not currently an account holder, or the applicant has an invalid TIN/SSN. This action prevents a new account record from being created for an applicant if he or she already has an account with the financial institution.

The Search Core for Applicant action does not automatically retrieve applicant information, such as demographics, assets, and liabilities, from the core. To import applicant information after the Search Core for Applicant action is executed, an Update from Core action can be performed either manually via the workspace, or automatically through Event Processing. If an Update from Core is performed during the virtual application process, a security risk may be exposed, as the Update from Core action can provide a fraudulent applicant with account numbers, and other secure information. To ensure this does not occur, it is highly recommended that institutions configure an ID Verification to occur in the application prior to the event that triggers the Update from Core action to execute.

This action runs once for each applicant where Is Customer is false, the Applicant > TIN field is NULL/Empty, or Applicant > Is Invalid TIN equals True.

• If Is Customer is false for the applicant, but the TIN is valid, the action searches the core for any existing accounts for the applicant based on the TIN.
• If Applicant > TIN = NULL/Empty, or Applicant > Is Invalid TIN = True, the system searches the core for any existing accounts for the applicant based on the Account Number, or Person Number, for the applicant.
  • If Applicant > TIN = NULL/Empty, the system uses the Applicant > Person Number to search the core.
  • If Applicant > TIN is not NULL/Empty, the system uses the Applicant > Account Number to search the core.

The following table outlines how an existing applicant is found in the core when a search is performed based on the applicant's TIN. This table includes the possible scenarios that can occur as a result of the search, and the information updated within the Temenos application:

Search Core for Applicant Functionality

This action updates an application with the most up-to-date information from the core, based on the option(s) selected for the action.

During the Update from Core process, Applicant Import rules are run to obtain information from the core; therefore, the fields updated with this process are dependent upon the core used by the institution. For more information, please see the field mapping document for the applicable core.

If an Update from Core is performed during the virtual application process, a security risk may be exposed, as the Update from Core action can provide a fraudulent applicant with account numbers, and other secure information. To ensure this does not occur, it is highly recommended that institutions configure an ID Verification to occur in the application prior to the event that triggers the Update from Core action to execute.

When configuring this action, system administrators are able to select one or more of the following options to determine the information that is updated from the core:

• Include Demographics

  When this option is selected, a list of fields appears below the option to allow administrators to select the specific Applicant Demographic fields that are updated with the action. For more information, please see the below section titled Applicant Demographics.

• Include Addresses

  This option is only available when Include Demographics is selected.

• Include Income
• Include References
• Include Assets
• Include Liabilities
• Include Core Messages
• Import Closed Accounts    

  This option is only available when System Management > Modules > Origination > System > Import Demographics when Accounts Closed is set to Yes.

This action does not consider the source of the application, and overwrites any applicant data that does not exist in the core, including demographics if the option is configured for the action. Additionally, if Include Addresses is selected, this action overwrites any address data manually entered in Temenos Infinity, and clears fields such as Start Date, Address Status, and Monthly Payment.

Applicant Demographics

When Include Demographics is selected, a list of fields appears below the option to select the applicant demographics to be updated with the Update From Core action.

This list is only available when Include Demographics is selected for the action.

This list includes the following Applicant Demographic fields:

This is a list of standard fields, which are not core specific. If a field is not available to be mapped from the core, but is selected in the Update from Core action, the field does not update when the action executes. For information on the fields supported by each core, please see the field mapping document for the applicable core.

• Person Number
• First Name
• Middle Name
• Last Name
• Suffix
• SSN
• Date of Birth
• Email
• Mother’s Maiden Name
• Member Code
• Membership Start Date
• Restriction Code
• ID Record

  If ID Record is selected, the following ID fields are automatically included in the update: ID Type ID Number ID Issue Date ID Expiration Date ID Country ID ID State ID ID Visa Type ID Visa Expiration Date If ID Record is not selected, no ID information is updated with the Update From Core action.

• Segmentation ID

By default, all fields are selected to update with the action; however, administrators can select and clear the check box next to each field as desired.

The fields defined in this action do not determine the applicant demographics that are updated through Applicant Import or the Update from Core button in the workspace.

Displays a list of all Event Processing rules configured in System Management > Origination > Rules Management. Assign rules by selecting the desired rule(s) from the list and moving them to the Assigned box.

The EventProcessing rules may employ a "Stop Event Processing" template which prevents an event/action pair from executing.

Displays the ID of the object on which the event process was run, such as the Application Number. Reference the table below for an overview of the value that is displayed for each object type:

Displays the status of the event/action pair. One of the following values populates within this column to identify the status of the delayed actions:

Enables the ability to filter by Event/Action Pair Status. By default, the View drop-down is set to All to display information for all event/action pairs regardless of status. To filter by status, click the drop-down arrow and select one of the following statuses:

• Pending
• Completed
• Failed

Enables the ability to display information for a specific time period. By default, this tab displays status information for a time period of 30 days from the current date. To modify the date range, perform one of the following actions:

• Manually enter the desired dates into each box.
• Click the next to each box to select the desired date.
• Select a pre-configured date range from the To drop-down list.

The filter end date defaults to the current date; therefore, it may be necessary to adjust the end date to display execution times that are set in the future.

Enables the ability to refresh the information that appears in the screen.

The grid within the Delayed Actions Report tab does not automatically refresh. If an action executes while the tab is open, the status for the pairing is not updated until a refresh is performed.

Modifications made to any of the General attributes only apply to future executions of the event/action pair. For example, it the duration of the time delay is updated from one day to two days, any queued actions are still performed after the one day expires, but all actions that are queued after the modification are not executed until two days have passed.

If a delayed event/action pair is deactivated, all queued actions in a Pending status are still processed.

Collection Added

• Application.Applicants
• Application.Applicants.CreditReports
• Application.Assets
• Application.Collaterals
• Application.Incomes
• Application.Liabilities

Collection Removed

• Application.Applicants
• Application.Applicants.CreditReports
• Application.Assets
• Application.Collaterals
• Application.Incomes
• Application.Liabilities

Field Changed (1)

• Application.Incomes.AdjustedMonthlyIncome
• Application.Incomes.Amount
• Application.Incomes.FrequencyId
• Application.Incomes.HoursPerWeek
• Application.Incomes.IncomeTypeId
• Application.Incomes.IsPartTime
• Application.Incomes.IsSelfEmployed
• Application.Incomes.LengthOfEmployment

Field Changed (2)

• Application.Collaterals.AdjustedMarketValue
• Application.Collaterals.AdjustedNetValue
• Application.Collaterals.AdjustedOriginalValue
• Application.Collaterals.AdjustedValue
• Application.Collaterals.AdjustmentPercentage
• Application.Collaterals.AppraisedValue
• Application.Collaterals.AvailableEquity
• Application.Collaterals.CollateralValue
• Application.Collaterals.MarketValue
• Application.Collaterals.NetValue
• Application.Collaterals.OriginalValue
• Application.Collaterals.TotalLiableLienAmount
• Application.Collaterals.TotalLienAmount

Field Changed (3)

• Application.Applicants.ApplicantTypeId
• Application.Applicants.BirthDate
• Application.Applicants.RiskTierId

Field Changed (4)

• Application.Applicants.Assets.AdjustedAvailableBalance
• Application.Applicants.Assets.AdjustedBalance
• Application.Applicants.Assets.AdjustedMarketValue
• Application.Applicants.Assets.AdjustementPercentage
• Application.Applicants.Assets.AssetTypeId
• Application.Applicants.Assets.AvailableBalance
• Application.Applicants.Assets.Balance
• Application.Applicants.Assets.HoldAmount
• Application.Applicants.Assets.IsFromHost
• Application.Applicants.Assets.MarketValue
• Application.Applicants.Assets.OriginalValue

Field Changed (5)

• Application.Applicants.Liabilities.AccountTypeId
• Application.Applicants.Liabilities.AdjustedBalance
• Application.Applicants.Liabilities.AdjustedBalloonRate
• Application.Applicants.Liabilities.AdjustedLimit
• Application.Applicants.Liabilities.AdjustedMonthlyPayment
• Application.Applicants.Liabilities.AdjustmentPercentage
• Application.Applicants.Liabilities.AssumedBalance
• Application.Applicants.Liabilities.AssumedCollateralValue
• Application.Applicants.Liabilities.AssumedInterestRate
• Application.Applicants.Liabilities.AssumedMonthlyPayment
• Application.Applicants.Liabilities.AssumedRemainingTerm
• Application.Applicants.Liabilities.Balance
• Application.Applicants.Liabilities.BalloonAmount
• Application.Applicants.Liabilities.CloseDate
• Application.Applicants.Liabilities.InterestRate
• Application.Applicants.Liabilities.IsExpense
• Application.Applicants.Liabilities.IsFromHost
• Application.Applicants.Liabilities.Limit
• Application.Applicants.Liabilities.OpenDate
• Application.Applicants.Liabilities.PaymentAmount
• Application.Applicants.Liabilities.PayoffAmount
• Application.Applicants.Liabilities.Term

Field Changed (6)

Application Created

• Application.Applicants
• Application.Applicants.CoreMessages

Collection Added

Field Changed

• Application.CrossSells.ResponseId

Application Created

Collection Added

• Application.Applicants

Field Changed

• Application.StatusId

Queue Changed

This Event/Action pair must be active in order for emails to be sent according to configurations made for the queue within the Notifications tab in System Management > Origination > Queues.

Field Changed

• Application.IsPinnedToQueue
• Application.QueueId

Field Changed

• Application.IndirectContractStatusId

Collection Added

• Application.AccountProducts
• Application.Applicants
• Application.Applicants.CreditReports
• Application.Collaterals
• Application.Collaterals.Liens

Collection Removed

• Application.AccountProducts
• Application.Applicants
• Application.Applicants.CreditReports
• Application.Collaterals
• Application.Collaterals.Liens

Field Changed

• Application.Applicants.RiskTierId
• Application.DebtProtectionPlan1Id
• Application.DebtProtectionPlan2Id
• Application.InterestRateActual
• Application.InterestRateAssigned

Field Changed

• Application.StatusId

Application Declined

Decision Suggested