Counteroffers provide users with the ability to counter the loan terms requested by the applicant with alternate terms. Rather than outright declining an application with unfavorable terms, users are able construct one or more counteroffers with terms more agreeable to the institution. This functionality provides institutions the opportunity to increase their loan portfolios, while minimizing their declinations.

Counteroffers may be constructed manually by Temenos users, or automatically by rules. Once a counteroffer is created, it is stored within the system where it can be reviewed with applicants.

If an application was originated by Dealertrack or RouteOne, Temenos Infinity communicates Counteroffers created within the system back to the connector. For more information on Counteroffers and their behavior within Dealertrack or RouteOne, refer to their Connector Guides.

The processing can then proceed automatically, if indicated, without resubmitting to the decision engine. Counteroffers supports expirations and reminders of counteroffers using email.

The loan terms originally requested are available in the Audit History once a counteroffer is created. The following information is stored: Loan Terms, Aggregates, Ratios, and Review Indicators.

This topic provides administrators details on the System Management configurations required to implement Counteroffers within the Loan Origination module. These configurations include:

• Screen and Workflow Model Configurations
• User Permissions
• Queuing
• Automatic Withdraw and Email Notifications
• Automated Counteroffer Generation
• Automatic Decline Process for Countered Applications

Screen and Workflow Model Configurations

Counteroffers are created, maintained, and viewed within the Counteroffer panel. This panel can be added to an Application screen in System Management > Origination > Screens.

Once configured, the screen must then be assigned to the applicable Loan Workflow Models in System Management > Origination > Loan > Loan Workflow Models.

It is recommended that this panel is assigned to an Application screen used during Underwriting Review.

User Permissions

Counteroffer processing requires permissions to be granted in order to Add, Edit, Delete, Accept, and Reject Counteroffers. These permissions can be granted at both the User and Security Group levels within the Permissions tab in System Management Users, and System Management > Groups > Security Groups.

Each function contains two permission options:

When changing permissions for a security group, it affects every user under the security group. For example, a user has his/her permission for "Counteroffer - Accept and Reject" set to "None." This user is also part of the Lending Security Group. If the Security Group has permission for "Counteroffer- Accept and Reject" as "Change," then the user has full access to this permission, even though individually the permission is set to "None."

Queuing

Any application that requires Underwriting Review (Application Status = Pending Review) should be "queued" to an Underwriter. For any Application that has a Counteroffer, the application should be “queued” back and forth between the Underwriter and the user processing the Application. It is recommended that a queue be configured per department or per user. Underwriter (LO) and Member Service Representative (MSR) fields are now configurable.

The following new fields allow the administrator to design queuing rules around the following roles:

Automatic Withdraw and Email Notification

Using dates set within each application, institutions are able to configure the system to automatically withdraw abandoned applications and countered applications. Three date fields drive this functionality:

• Expiration Date - The date in which the Counteroffer expires.
• First Notification Date - The date when the first notification is sent.
• Second Notification Date - The date when the second notification is sent.

Based upon editability and user/group permissions, these fields can be manually set on both application and counteroffer screens.

If the First Notification Date, Second Notification Date or Expiration Date is today and the Application Status is not Disbursed, Withdrawn or Auto Withdrawn, the Automatic Withdraw Process executes.

• If the First Notification Date is reached, a warning email is sent to the applicants. The value in First Notification Date is set to null.
• If the Second Notification Date is reached, a warning email is sent to the applicants. The value in Second Notification Date is set to null.
• If the Expiration Date is reached, a warning email is sent to applicants and the Application Status is set to Auto Withdraw. The value in Expiration Date is set to null.

To configure the automatic withdraw process, institutions must complete the following steps:

Screen Configuration

By default, the Counteroffer screen contains the Expiration Date, First Notification and Second Notification Date fields. However, these fields must be assigned to the application screen where loan terms and loan tracking information is collected.

       

Within the Counteroffers screen, the Expiration Date, First Notification and Second Notification Date fields are not required. However when these fields are added to the Application screen, the administrator is able to determine whether the fields are Required, Recommended or Read Only.

For more information on configuring application screens, refer to the Screens topic.

These field can either be set manually by the user or set automatically by rules. Refer to the Rules section within this topic for more information on rules.

Editability and Permissions

Rule Configuration

By authoring rules, institutions are able to set the values of the Expiration Date, First Notification Date and Second Notification Date fields. Rule authors are able to write these rules at both the Application and Application.Counteroffer entity levels.

When authoring rules at the application level, it is advised that two rules are created or a single rule is written in such a way that the Expiration Date, First Notification Date and Second Notification Date fields are set initially by  Created Date and reset by the Decision Date.

Email Templates

The automatic withdraw process uses emails to inform applicants when the First Notification, Second Notification and Expiration Dates have been reached. To use this feature, institutions must create individual email templates for both applications and counteroffers using the following email fields:

• ##Expiration Date##
• ##First Notification Date##
• ##Second Notification Date##

Once all email templates have been created, institutions should have six warning email templates (three templates for the automatic withdraw of an application and three templates for the automatic withdraw of a counteroffer).

For more information on creating email templates, refer to the Email Template topic.

Withdraw Reason

Process Configuration

An automatic withdraw cannot be removed or changed manually. A withdraw can be removed by using rules or field change event processing.

Automatic Counteroffer Generation

By default, counteroffers are constructed manually; however, institutions are able to automate the counteroffer process by completing the following configurations:

• Rule Authoring
• Event Processing Configurations
• Solution Parameter Configurations

Rules Management

Within Rules Management, institutions are able to author rules which determine the countered terms and behavior. Within the Event Processing category, rule authors are able to define the behavior of automatic counteroffers using the following action templates:

Template	Description
Create a counteroffer	This template enables institutions to define the interval in which countered loan terms and amounts should increase or decrease.
Create a counteroffer for manual review	This template enables institutions to define the loan terms and amount of the counteroffer. Upon generation, each counteroffer is flagged for underwriting review.
Set counteroffer priority	This template enables institutions to define which loan term should be prioritized when creating counteroffers. This does not apply for the “Create a counteroffer for manual review” rule template.
Add a comment to a counteroffer	This template enables institutions to add comments to a counteroffer.
Add a stipulation to a counteroffer	This template enables institutions to add stipulations to a counteroffer.

A rule can also be authored to set a default decline reason on automatic counteroffers.

For more information on authoring rules using these action templates, see the Rules Management topic.

Institutions may opt to adjust Decisioning rules in order to counter more and decline less applications.

Event Processing

Once rules have been authored, create Event Action pairings to tie the automatic counteroffer rules to triggering events.

Within the Events tab, select an event that triggers the automatic counteroffer rules to process, such as: Field Changed > Application Status.

The Field Changed > Application Status event triggers the automatic counteroffer rules at any application status change. If configured, it is recommended that rule authors define which Application Statuses and/or Application Decisions trigger automatic counteroffer processing.

Within the Actions tab, select the Execute Counteroffer Processing action and, using the multi-grid, assign the desired automatic counteroffer processing rules.

Parameters

Once rules and event action pairs have been defined, navigate to System Management > Modules > Origination, and select the System tab.

Update the following parameters to define the behavior of automatic counteroffer processing:

Parameter	Description
Indirect Application Counteroffer Decision Notification	Allows institutions to indicate how the system communicates counteroffers to indirect connectors. Within this parameter, the following options are available: Send First Counteroffer Details Only - Communicates the loan details for the first counteroffer on the application. Any subsequent counteroffers are not communicated. Update Decision upon Counteroffer - Communicates the loan details of each counteroffer. However, each new counteroffer added to the application is communicated back to the indirect connector replacing the existing decision details. Send First Counteroffer with Additional as Comments - Communicates the first counteroffer as decision details and any subsequent counteroffers as comments. The comment is a concatenation of the counteroffer loan terms. The first counteroffer refers to there being no other active counteroffers on the application.
Automated Counteroffer Maximum Iterations	Allows institutions to indicate the maximum number of iterations that each automated counteroffer action type should attempt. This value must be equal to or greater than one.

Automatic Decline Process for Countered Applications

The Automatic Decline Process for Countered Applications provides institutions with the ability to automatically decline or withdraw applications including unaccepted counteroffers after a pre-determined amount of time lapses from when the counteroffer was created.

This process only auto-declines applications that have been countered, and surpass the value configured for the Cutoff Number of Days parameter in the Origination page.

To activate and configure the Automatic Decline Process for Countered Applications:

• Navigate to the Origination page (System Management > Modules > Origination), and select the Declined tab.

   

• Within the Auto Decline Counteroffered Applications section, activate the Auto Decline process by selecting Yes from the Activate Auto Decline drop-down list.
• In the Cutoff days to Decline field, enter the number of days that must lapse before an application with a status of "Countered" is automatically declined or withdrawn.
• From the Auto Decline Default Adverse Action drop-down list, select the default Adverse Action to appear on the Adverse Action notification transmitted to the applicant.

  The Auto Decline Default Adverse Action drop-down list contains the values configured for the ADVERSE_ACTION lookup type in System Management > Origination > Field Configurations.

• From the Auto Decline Default Decline Reason drop-down list, select the default Decline Reason to appear on the Adverse Action notification transmitted to the applicant.       

  The Auto Decline Default Decline Reason drop-down list contains the values configured for the REJECT_REASON lookup type in System Management > Origination > Field Configurations.

• Upon completion of all fields, click  at the top of the Origination page to retain the settings.

Once activated, the Automatic Decline Process for Countered Applications runs each night at 10pm.

During this process, applications with a status of "Countered" are identified and automatically declined if they exceed the time frame configured for the Cutoff days to Decline parameter. When a countered application is automatically declined, the following values are set within the application:

Field	Application Value
Application Status	Set to Decisioned.
Loan Decision	Set to one of the following: Auto Rejected - When the counteroffer is initiated automatically by the system. LO Rejected - When the counteroffer is initiated by a user.
Decisioned By	Set to the name of the user who initiated the counteroffer. When a counteroffer is initiated automatically by the system, the value for Decisioned By is set to System, Lending.
Adverse Action	Set to the value configured for the Auto Decline Default Adverse Action parameter in the Origination page.
Assigned Decline Reason	Set to the value configured for the Auto Decline Default Decline Reason parameter in Origination page.   In an application, this value populates in the Assigned Decline Reason box that appears in the Adverse Action panel.

©2022 Temenos Headquarters SA - all rights reserved.