Skip to main content

Application Denials

Overview​

When a card product application is denied, two fields expose why, at different levels of specificity:

  • applicationDenialReason: a general reason available on every card product application.
  • adverseActionReasons: specific reasons populated only for underwritten (credit) applications.

This guide covers the general denial reasons, including inactivity denials, and how they relate to adverse action codes. For credit decisions, see Simulate Underwriting Decisions.

Application denial reasons​

The applicationDenialReason field is available on both AccountHolderCardProductApplication and AuthorizedUserCardProductApplication. It returns one of two intentionally general values from the ApplicationDenialReason enum:

  • DENIED_DUE_TO_APPLICATION_INACTIVITY: the application could not be decisioned within the timeframe defined in the cardholder agreement because required information was missing.
  • DENIED_DUE_TO_OTHER: the application was denied for another reason.

Highnote keeps these subscriber-facing reasons general by design. Internally, Highnote maintains more specific denial reasons for auditing and compliance.

All card product applications

applicationDenialReason is available on every card product application. Underwritten applications additionally receive a more specific adverse action code. See Adverse action codes.

Inactivity denials​

An inactivity denial (DENIED_DUE_TO_APPLICATION_INACTIVITY) occurs when an application stalls before it can be decisioned and the timeframe defined in the cardholder agreement elapses. This is typically because information needed to verify the applicant was never provided.

Because this timeframe is set by the cardholder agreement, it can vary by card product. An inactivity denial reflects an application that was never completed, not a substantive decision against the applicant.

Denial notifications​

When an application is denied, Highnote sends a notification event:

  • CARD_PRODUCT_APPLICATION_DENIED: for account holder applications.
  • AUTHORIZED_USER_CARD_PRODUCT_APPLICATION_DENIED: for authorized user applications.

The denied application is included in the event, so you can read applicationDenialReason directly from the notification. No separate lookup is required.

Adverse action codes​

Underwritten (credit) applications populate the adverseActionReasons field, in addition to the general applicationDenialReason. Each entry carries a code (an AdverseActionCode) and a human-friendly description. The code reflects the step at which the application was denied; for example, an application closed while awaiting underwriting maps to UNABLE_TO_VERIFY_CREDIT_REFERENCES.

In collaborative underwriting, a decision must be received within 30 days of the application creation date, or the application transitions to DENIED with an adverse action code.