Home / Issuing / Manage Credit

Simulate Underwriting Decision

Overview

Warning: To ensure the security of your real-world data, do not enter production data in the test environment. Production data includes sensitive information such as customer details, financial data, or personally identifiable information (PII).

The Highnote test environment lets you explore platform features and functionality. It is intended for experimenting, building integrations, and training your team. Use only dummy or test data explicitly created for testing purposes in the test environment.

Highnote provides simulations for credit application underwriting. This is useful for testing your integration and credit policy, configuring notifications, and simulating the cardholder experience.

This guide provides an overview for simulating underwriting decisions using the test environment.

Assign a credit line

Your credit policy may allow for dynamic allocation of credit limits on approved applications. You can test various credit line assignments on approved applications using the test environment.

Simulating credit line assignment requires two steps:

  1. Onboard an account holder and provide a simulation value for the annualRevenue or totalAnnualIncome fields. To onboard an account holder, see Onboard an account holder.

  2. Open an application for the account holder. When the application is approved, the credit line will reflect the simulation value used during onboarding. To open an application, see Open an application.

Simulation values

The following table provides simulation values for simulating credit line assignment:

Account holder typeFieldSimulation valueCredit line assignment
US business account holderannualRevenue$1,000,000$1,000
annualRevenue$10,000,000$10,000
annualRevenue$100,000,000$100,000
US person account holdertotalAnnualIncome$1,000,000$1,000
totalAnnualIncome$10,000,000$10,000
totalAnnualIncome$100,000,000$100,000

Lookup application credit line

After simulating credit line assignment, you can use the following query to lookup the application to verify the credit line:

Deny application

In the test environment, opening applications for credit card products allows you to test adverse action reasons for DENIED responses. Testing adverse action reasons consists of the following steps:

  1. Create a business or person account holder in your test environment using an adverse action simulation value.
  2. Open an application for the account holder.

In the live environment, a DENIED application may have one or more adverse action reasons. All adverse action reasons must be provided to the account holder.

Adverse action values

The following table provides adverse action values you can use to simulate application denial:

Account holderFieldSimulation valueAdverse action response code
US business account holderannualRevenue$1.00INSUFFICIENT_INCOME: Income is insufficient for the requested credit amount
annualRevenue$2.00DELINQUENT_CREDIT_OBLIGATIONS: Account holder has delinquent past or present credit obligations
annualRevenue$5.00INSUFFICIENT_INCOME and DELINQUENT_CREDIT_OBLIGATIONS
legalBusinessNameDECLINEUNABLE_TO_VERIFY_IDENTITY
US person account holdertotalAnnualIncome$1.00INSUFFICIENT_INCOME: Income is insufficient for the requested credit amount
totalAnnualIncome$2.00DELINQUENT_CREDIT_OBLIGATIONS: Account holder has delinquent past or present credit obligations
totalAnnualIncome$5.00INSUFFICIENT_INCOME and DELINQUENT_CREDIT_OBLIGATIONS
givenNameDECLINEUNABLE_TO_VERIFY_IDENTITY

Lookup application adverse action

Note: To automate your integration, you can use the notification event CARD_PRODUCT_APPLICATION_DENIED to send notifications when an application is denied. See Account holder application status in the Events Reference.

After simulating denial with adverse action reasons, use the following query to find a card product application:

Credit report inquiries

Note: If your credit policy requires credit report inquiries, you must collect additional consent from the account holder during the card product application flow.

If you are not using collaborative application decisioning, your card product's credit policy is executed on your behalf by Highnote.

For credit policies that perform credit report inquiries, you must monitor and manage credit report freezes and fraud alerts for your account holders. Refer to the following to resolve credit report freezes and fraud alerts for your account holders:

  • Credit report freezes: The account holder must contact the applicable credit bureau and remove the freeze on their credit report.
  • Credit report fraud alerts: You must contact the account holder and verify their identity.

View credit score reason codes

For credit policies that use a credit bureau's risk score, use the following query to view an application's credit creditScoreReasons:

Freezes, flags, and fraud alerts

In some scenarios, account holders may have a freeze or fraud alert on their credit report, or be flagged for MLA eligibility. Using the test environment, you can simulate a credit report freeze, fraud alert, or MLA flag on an application response. Simulating these scenarios requires the following steps:

  1. Onboard an account holder and provide a simulation value for the phoneNumber field. See Onboard an account holder.

  2. Open an application for the account holder. When the application processes, it creates a fraud alert, credit report freeze, or MLA eligibility flag in the response payload.

Simulation values

The following table provides simulation values for creating an account holder to simulate credit freezes, credit report fraud alerts, and MLA eligibility. The same simulation values apply to both US business and person account holders:

FieldSimulation valueResponse
phoneNumber1111111111CREDIT_REPORT_FREEZE
phoneNumber2222222222CREDIT_REPORT_FRAUD_ALERT
phoneNumber3333333333MLA_ELIGIBLE

Simulate fraud alert

After creating an account holder using the CREDIT_REPORT_FRAUD_ALERT simulation value, use the following mutation to open an application. The fraud alert is noted in the response payload:

Simulate credit report freeze

After creating an account holder using the CREDIT_REPORT_FREEZE simulation value, use the following mutation to open an application. The credit report freeze is noted in the response payload:

Simulate MLA eligibility

After creating an account holder using the MLA_ELIGIBLE simulation value, use the following mutation to open an application. If the applicant is eligible for MLA, a CREDIT_REPORT_FRAUD_ALERT tag will also be present on the application. Once a financial account is issued from the application, you can lookup the military status on the account. The MLA eligibility is noted in the response payload:

Managing fraud alerts

Memos are now global. As a best practice, add context to your memos so they make sense when queried on different parts of an application.

When a credit report inquiry returns a CREDIT_REPORT_FRAUD_ALERT, indicating the the account holder may have a freeze on their credit report, you can use the following set of queries to:

In the Highnote API, the memo field is now supported by a globalNote object that can be added and viewed anywhere across a card product application, not just the entity to which is was applied. Global notes are stored centrally and encrypted at rest. With this added flexibility, consider adding context to your notes so that when you run a query on an unrelated part of the application, the note makes sense.

View fraud alert

Use the following query to lookup an application. The response's status and memo fields include account holder information that you can use to reach out to and verify the identity of the account holder:

Verify fraud alert

If an account holder has a fraud alert on their credit report, you must contact the account holder to verify that their name, date of birth, and address match that on the application. If the account holder can't verify the information provided on their application, the application will be denied.

Use the following mutation to verify an account holder for a fraud alert:

Confirm unfrozen credit report

If the account holder has a freeze on their credit report, you must contact the account holder and instruct them to remove the freeze from their report. Once the account holder has confirmed they removed a freeze, you can use the following mutation to confirm and re-run the application decisioning workflow:

Provide Feedback

Was this content helpful?