Pulling Credit

During the application process, users are able to request credit reports for each applicant. Temenos Infinity automatically retains credit reports and stores them at the Applicant level.

If the current applicant has a previously pulled credit report stored in Temenos Infinity, it can be recycled for the current application, rather than pulling a new report, if all of the following are true:

System administrators can determine whether the system reuses the most recent credit report from any credit bureau, or the most recent report based on the credit bureau sequence logic for the application type.

This determination is made by setting the Reuse Credit Report parameter in the Underwriting tab in System Management > Modules > Origination. For more information, please see the Underwriting section of the Origination topic in the Administrator guide.

The primary applicant's TIN matches the Applicant > TIN field.
The age of the credit report is less than or equal to the number of days to reuse the report, as defined by the system administrator in Loan Application Types or Account Application Types.

During credit report processing, the system automatically performs a check to verify whether a recent credit report was pulled for the applicant's TIN, and reuses a credit report if the age of the report falls within the number of days to reuse the report configured for the application type. When this occurs, a notification informing of a successful credit pull is still received in the application workspace, though a new credit report was not pulled for the applicant.

The CreditReportProductId is equal to 001 to indicate an Equifax credit report was pulled, or 005 to indicate an Experian or TransUnion credit report was pulled.

If there are no existing reports within the recycling requirements, the system automatically pulls a new credit report.

A credit report is only generated in Temenos Infinity if a Credit Bureau Return Code of "0" is received from the credit bureau for the applicant. This identifies a "valid credit data response file." If a value other than "0" is returned from the credit bureau, a report is not generated during credit processing, and the reason is identified in the value populated for the Application > Applicant > Credit Bureau Return Code field.

The value of the Application > Applicant > Credit Bureau Return Code can be captured and displayed in reports and views, as well as an Applicant panel on an Applicant screen, or a Primary and/or Additional Applicant panels on an Application screen. This field can also be added to rules. For example, to add a review indicator based on the value of the Credit Bureau Return Code during execution of a Risk rule. For more information, please see the applicable credit bureau connector guide for the institution.

When pulling credit, users have the ability to pull the following two types of credit reports:

Type	Description
Single	A credit report that is pulled for individual applicants.
Joint	A credit report that is pulled for joint (married) applicants. In order for a joint credit report to be pulled, applicants must be identified as Married and linked via the Spouse field.

Equifax, Experian, and TransUnion do not support joint inquires for Military Lending Act status searches. To perform MLA searches on multiple applicants, one request must be submitted for each applicant.

There are two methods for pulling credit reports during the application process:

Manually through the Credit Reporting screen
Automatically through Event Processing and Decisioning

Credit reports that are pulled outside of an application via the Credit Report button in the Ribbon are able to be used when processing an application.

Removing Duplicate Liabilities

Once credit report processing has completed, the system attempts to remove duplicate liabilities for the applicants and application to ensure like liabilities are not considered during the decision process.

The following flowchart provides an overview of the de-duplication process.

When attempting to remove duplicate liabilities from an application, the following processes are leveraged:

Process

Description

Applicant Liability De-Duplication

The Applicant Liability De-Duplication process consists of two sub-processes that remove duplicate liabilities that exist on the core and credit report.

The first sub-process is a housing expense comparison that attempts to match the housing expense information entered in the applicant's current address and mortgage/rental tradeline items.
The second sub-process is a tradeline comparison that attempts to match application liabilities (manually added and imported from core) to items on the applicant's tradelines.

Application Liability De-Duplication

Once the Applicant Liability De-Duplication process completes, the application liability de-duplication process executes to remove duplicate liabilities that simultaneously exist between all applicants on an application.

Applicant Liability De-Duplication

During the Applicant Liability De-Duplication process, the system first attempts to match duplicate housing expenses. Once duplicate housing expenses have been merged, the system attempts to merge all remaining trade types.

Housing Expense Comparison

In the Housing Expense Comparison process, the system attempts to match the housing expense created for an applicant from the current address with mortgage/rental tradelines in order to set the Housing flag on a liability. If a credit report liability has a trade type of Mortgage, the system attempts to match the current address expense.

The list below provides an overview of tips to consider for Housing Expense Liabilities:

The Housing Expense Comparison process is limited to a housing expense created for an applicant from the current address with Status of Own or Purchase.
Housing expenses are not compared to closed core or tradeline liabilities.
Only housing expense liabilities with a trade type of Mortgage are compared against credit report tradelines.
When a housing expense is de-duplicated, the housing balance is updated from the tradeline or core liability.
When a duplicate housing expense is unlinked, the liability is not deleted from the core or credit bureau.
The Housing Expense Comparison process only associates an applicant's housing expense to the tradeline, if that same applicant is also related to the tradeline liability.

During the housing expense comparison process, conditions and rules are checked in the following order:

The percent difference between the payment amount of the application liability and the tradeline liability must be within the Liability Match - Payment Amount % Tolerance Factor established by a system administrator on the Origination page in System Management. If the Payment Amount % Tolerance Factor is not within the tolerance percent, the process attempts to find a match using the next matching rule.

The following calculations are used in calculating tolerance:

MinPymt = PaymentAmount - (PaymentAmount * PaymentToleranceFactor)
MaxPymt = PaymentAmount + (PaymentAmount * PaymentToleranceFactor)

The percent difference between the balance of the application liability and the tradeline liability must be within the Liability Match - Balance Amount % Tolerance Factor established by a system administrator on the Origination page in System Management. If the Balance Amount % Tolerance Factor is not within the tolerance percent, the process attempts to find a match using the next matching rule.

The following calculations are used in calculating tolerance:

MinBalance = Balance - (Balance * BalanceToleranceFactor)

MaxBalance = Balance + (Balance * BalanceToleranceFactor)

When the Balance is $0.00, only the BalanceToleranceFactor is considered.

If the system administrator sets the Liability Match - Consider Trade Type parameter to Yes within the Origination page in System Management, the liabilities that can be matched are restricted as follows:
- If the address status is Purchase, only Real Estate trade type liabilities are compared.
- If the address status is Rent, Lives with Others, or Other, only Utility/Rent trade type liabilities are compared.

The Address Status can be set through the Address Status lookup field. which can be added to a Real Estate Collateral screen by a system administrator.

When a current address record is added for an applicant, a housing expense liability is created and linked to that address. If any modifications are made to an address, there may be adverse reactions. For example, if the Address Status is changed from Mortgage to Rent, or Live with Others, the mortgage tradeline from the credit report is removed from the Liabilities screen. The only way to break a link between an address and housing expense liability is to delete the address record from the application; therefore, if a modification to the Address Status is required, it is highly recommended that the existing address is deleted, and a new address with the correct status is added for the applicant.

When the housing expense's loan balance and payment amount are both zero, the housing expenses are unlinked.

Tradeline Comparison

Within the Tradeline Comparison process, the system attempts to match applicant liabilities that occur on both the application and credit report, according to the following specifications:

Credit report tradelines are not compared to other credit report tradelines for an applicant, due to the robust matching and de-duplication capabilities of the Luxor Credit ++ Toolkit.
Core liabilities are not compared to other core liabilities for an applicant, due to the core being the system of record. Core liabilities are not de-duplicated for an individual applicant, unless the liabilities have different loan numbers. At the applicant level, core liabilities that have the same Credit Report Account Number but different loan numbers are not de-duplicated; however, these liabilities are de-duplicated at the application level.
Open core liabilities are compared to open credit report tradelines, due to the core being the system of record.
Closed core liabilities are compared to both closed and open credit report tradelines, due to situations where a loan is closed in the core but the credit report has not yet been updated.

During the tradeline comparison process, conditions and rules are checked in the following order:

In order for the tradeline comparison process to execute successfully and the correct fields to be updated on the core liability, Subscriber Codes for each of the financial institution's active credit bureaus must be configured in System Management > Origination > Field Configurations. During tradeline comparisons, if the core liability and the credit report tradeline have the same Open Date (month and year) and Limit, the Subscriber Codes are used to find a match as follows:

If the credit report tradeline has a Subscriber Code that is configured in the Equifax, Experian, or TransUnion Subscriber Code system lookups, de-duplication occurs to update the core liability with the credit report tradeline. If there is no match between the credit report tradeline's Subscriber Code and the Subscriber Code system lookups, the process adds the tradeline to the liabilities for an applicant and proceeds to process the next liability.

If Subscriber Codes are not configured, de-duplication only occurs at the application level, and the applicant level housing expense and tradeline comparisons do not occur.

If the core liability and the credit report tradeline have the same Credit Report Account Number and Open Date (month and year), de-duplication occurs to update the core liability with the credit report tradeline. If there is no match between the Credit Report Account Number and Open Date, the process attempts to find a match using the next matching rule.
If the core liability and the credit report tradeline have the same Open Date (month and year) and Trade Category, the Liability Partial Account Number Length parameter set by a system administrator is used to find a match as follows:
- If the first X digits of the Core Liability Credit Report Account Number match the first X digits of the Credit Report Liability Account Number, de-duplication occurs to update the core liability with the credit report tradeline. If there is no match between the Core Liability Credit Report Account Number and the Credit Report Liability Account Number, the process attempts to find a match using the next matching rule.
- If the last X digits of the Core Liability Credit Report Account Number match the last X digits of the Credit Report Liability Account Number, de-duplication occurs to update the core liability with the credit report tradeline. If there is no match between the Core Liability Credit Report Account Number and the Credit Report Liability Account Number, the process attempts to find a match using the next matching rule.

When a liability is de-duplicated during tradeline comparisons, the following fields are updated on the core liability:

Subscriber Codes must be configured in System Management > Origination > Field Configurations in order for the core liability to be updated correctly.

Show Fields Updated on the Core Liability

Field Name	Value Kept from Core?	Value Kept from Tradeline?
Balance	Yes
Payment Amount	Yes
Balloon Amount	Yes
Balloon Due Date		Yes, but only if it is blank from the core.
Charge Off Amount		Yes
Close Date		Yes
High Credit Amount		Yes
Last Delinquency Date		Yes
Last Payment Date	Yes
Last Reported Date		Yes, but only if it is blank from the core.
Limit	Yes
Max Delinquency Amount		Yes
Months Reported Open		Yes
Months Since Last Reported		Yes
Number 120 DQ		Yes
Number 150 DQ		Yes
Number 180 DQ		Yes
Number 30 DQ		Yes
Number 60 DQ		Yes
Number 90 DQ		Yes
Number Payments Past Due		Yes
Past Due Amount		Yes
Term	Yes
Subscriber Code		Yes
Creditor Name		Yes
Pattern		Yes
Is Secured		Yes, if the Trade Category is Real Estate, Automobile, Furniture, BoatYacht, or Recreational Vehicle.
Category Id		Yes
Closed Type Id		Yes
Condition Id		Yes
Derogatory Indicator Id		Yes
Industry Code		Yes
Max Delinquency Status Id		Yes, but only if it is blank from the core.
Payment Frequency Id		Yes, but only if it is blank from the core.
Product Code Id		Yes
Status Id		Yes, but only if it is blank from the core.
Credit Bureau Id		Yes
Remark Codes		Yes
ECOA Code		Yes, but only if it is blank from the core.
Is From Host	Yes, it is set to 1.
Is From Tradeline		Yes, it is set to 1.
Open Date	Yes

Application Liability De-Duplication

After the de-duplication process evaluates each liability belonging to a specific applicant, the process evaluates and attempts to match liabilities belonging to all applicants on the application, according to the following specifications:

Liabilities that have the IsConcurrent flag set to true are not processed.

The Concurrent App flag can display on the Liabilities screen/panel depending on the configurations made by a system administrator.

System liabilities flagged as IsFromHost and IsTradeline are not processed, as the application liability de-duplication process does not differentiate between core liabilities and credit report tradelines.

A system liability is one that is not from the core or a credit report.

Open liabilities are compared to both open and closed liabilities.
Closed liabilities are compared to both open and closed liabilities.

During the application liability de-duplication process, conditions and rules are checked in the following order:

Liabilities are de-duplicated based on the Last Reported Date. The de-duplication process keeps the most-recently reported liability and keeps a liability with a Last Reported Date over a liability without a Last Reported Date.

If one applicant's liability has the same Credit Report Account Number and Open Date (month and year) as another applicant's liability, de-duplication occurs to remove the matching liability. If there is no match between the Credit Report Account Number and Open Date, the process attempts to find a match using the next matching rule.
If one applicant's liability has the same Open Date (month and year) and Trade Category as another applicant's liability, the Liability Partial Account Number Length parameter set by a system administrator is used to find a match as follows:
- If the first X digits of the Core Liability Credit Report Account Number match the first X digits of the Credit Report Liability Credit Report Account Number, de-duplication occurs to remove the matching liability. If there is no match between the Core Liability Credit Report Account Number and the Credit Report Liability Account Number, the process attempts to find a match using the next matching rule.
- If the last X digits of the Core Liability Credit Report Account Number match the last X digits of the Credit Report Liability Credit Report Account Number, de-duplication occurs to remove the matching liability. If there is no match between the Core Liability Credit Report Account Number and the Credit Report Liability Account Number, the process attempts to find a match using the next matching rule.
If there is no match between applicant's liabilities, the process adds the liability to the application and proceeds to process the next liability.

When a liability is de-duplicated during the application liability de-duplication process, the following fields are updated on the applicant mapping and can be displayed within the Liabilities screen/panel, depending on its configuration by a system administrator:

Field	Condition
Is Expense	If the liability being matched is an expense, this flag is set to true.
ECOA Code Id	Based on the applicant being processed and their relationship to the liability, this field is set to Primary, Joint, etc.
Percentage Responsible	This remains the value assigned to the applicant's liability on the Liabilities screen/panel.

Additionally, the following fields are mapped to the applicant for the de-duplicated liability:

Account Number
Credit Report Account Number
Maturity Date
Payoff Amount
Is From Host