Home / Issuing / Manage Credit
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.
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:
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.
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.
The following table provides simulation values for simulating credit line assignment:
Account holder type | Field | Simulation value | Credit line assignment |
---|---|---|---|
US business account holder | annualRevenue | $1,000,000 | $1,000 |
annualRevenue | $10,000,000 | $10,000 | |
annualRevenue | $100,000,000 | $100,000 | |
US person account holder | totalAnnualIncome | $1,000,000 | $1,000 |
totalAnnualIncome | $10,000,000 | $10,000 | |
totalAnnualIncome | $100,000,000 | $100,000 |
After simulating credit line assignment, you can use the following query to lookup the application to verify the credit line:
When a credit card application is denied, regulations require you to provide a customer with Adverse Action (AA) reasons within 30 days. This regulation promotes credit availability to all creditworthy applications and ensures the credit decision is based on creditworthiness.
Adverse action reasons are assigned and associated with rules in your card product's credit policy. When a credit policy rule fails during decisioning, an adverse action is returned in the response payload.
If you use collaborative application decisioning, you are responsible for providing the adverse action reasons to an account holder when an application is denied. For a full list of adverse actions, see the API Reference.
You can simulate various adverse action reasons for denied applications in the test environment. Simulating adverse actions requires the following steps:
annualRevenue
, totalAnnualIncome
, legalBusinessName
or givenName
fields. To onboard an account holder, see Onboard an account holder.The following table provides adverse action values you can use to simulate application denial:
Account holder | Field | Simulation value | Adverse action response code |
---|---|---|---|
US business account holder | annualRevenue | $1.00 | INSUFFICIENT_INCOME : Income is insufficient for the requested credit amount |
annualRevenue | $2.00 | DELINQUENT_CREDIT_OBLIGATIONS : Account holder has delinquent past or present credit obligations | |
annualRevenue | $5.00 | INSUFFICIENT_INCOME and DELINQUENT_CREDIT_OBLIGATIONS | |
legalBusinessName | DECLINE | UNABLE_TO_VERIFY_IDENTITY | |
US person account holder | totalAnnualIncome | $1.00 | INSUFFICIENT_INCOME : Income is insufficient for the requested credit amount |
totalAnnualIncome | $2.00 | DELINQUENT_CREDIT_OBLIGATIONS : Account holder has delinquent past or present credit obligations | |
totalAnnualIncome | $5.00 | INSUFFICIENT_INCOME and DELINQUENT_CREDIT_OBLIGATIONS | |
givenName | DECLINE | UNABLE_TO_VERIFY_IDENTITY |
After simulating denial with adverse action reasons, use the following query to find a card product application:
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:
In some scenarios, account holders may have a freeze or fraud alert on their credit report. Using the test environment, you can simulate a credit report freeze or fraud alert on an application response. Simulating freezes and fraud alerts requires the following steps:
phoneNumber
field. To onboard an account holder, see Onboard an account holder.The following table provides simulation values for creating an account holder to simulate credit freezes and fraud alerts. The same simulation values apply to both US business and person account holders:
Field | Simulation value | Response |
---|---|---|
phoneNumber | 1111111111 | FREEZE |
phoneNumber | 2222222222 | FRAUD_ALERT |
After creating an account holder using the FRAUD_ALERT
simulation value, use the following mutation to open an application. The fraud alert is noted in the response payload:
After creating an account holder using the FREEZE
simulation value, use the following mutation to open an application. The credit report freeze is noted in the response payload:
If a credit report inquiry returns a CREDIT_REPORT_FRAUD_ALERT
, you can use the following query to lookup the application. The response's status
and memo
fields will include account holder information that you can use to reach out to and verify the identity of the account holder:
If an account holder has a fraud alert on their credit report, you must contact the account holder to verify the following information matches their 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:
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: