Private preview

Report other credit decisions and manage adverse action notices Private preview

Learn how to report various credit decisions and send adverse action notice emails.

With the CreditUnderwritingRecord API, you can record application and decision details across many credit underwriting scenarios, including some which are adverse actions and require sending adverse action notice emails, known as AANs.

We’ve documented examples of these credit underwriting scenarios and the steps to follow to:

• Act on an application received from a customer
• Make proactive underwriting decisions without a customer application
• Override your written policies through an exception
• Correct an erroneous underwriting record

Act on an application received from a customer

Each time a customer or prospective customer completes and submits an application for credit to your platform, you must record their application details through the create_from_application endpoint of the CreditUnderwritingRecord API, and then record the decision within 30 days through the report_decision endpoint.

If their application is approved, you’ll also need to set their credit_limit_amount in the CreditPolicy API. If it’s rejected, you’ll need to provide rejection reasons and send an adverse action notice.

Refer to these example scenarios for detailed steps:

• Report and approve an application for a new credit line
• Report and approve an existing user’s application for a credit limit increase
• Report and reject an application for a new credit line or increased credit limit (requires an AAN)
• Handle an incomplete or withdrawn application for a new credit line

Diagram of scenarios when receiving an application from a customer.

Report and reject an application for a new credit line or increased credit limit and report rejection reasons

First, report the application through the create_from_application endpoint.

Command Line

cURL

Example response

{
 "object": "issuing.credit_underwriting_record",
 "id": "cur_1NiHAD2eZvKYlo2CmWGpt5OX",
 "credit_user": {
 "name": "Barbell Gym",
 "email": "barbell-gym@gmail.com"
 },
 "created_from": "application",
 "application": {
 "purpose": "credit_line_opening",
 "submitted_at": 1681138952,
 "application_method": "online"
 },
 "decision_deadline": 1683601352 // 30 days after submission, set by Stripe
}

To reject the application, the steps are the same for both application purposes ( credit_line_opening and credit_limit_increase).

Use the report_decision endpoint with the ID from the response, set the decision type to application_rejected, and provide at least one value from application_rejected.reasons in the application_rejected hash. You can provide up to four reasons, and these must be the “principal” reasons for rejecting the application. They must be consistent with the rejection reasons defined in your bank-approved credit policy.

If you select other, also provide an explanation of the rejection in reason_other_explanation. Stripe compliance reviews these explanations and might contact you for further details.

Command Line

cURL

You must send an adverse action notice email to rejected applicants that includes these rejection reasons.

Handle an incomplete or withdrawn application for a new credit line

Report an applicant’s decision to withdraw their application

First, report the application through the create_from_application endpoint. Then use the report_decision endpoint with the ID from the response and set the decision type to withdrawn_by_applicant.

If the applicant decides to withdraw their credit application, set the decision to withdrawn_by_applicant.

Request more information on an incomplete application, then make a final decision

Sometimes you receive an incomplete application and need to ask the applicant for additional information before making a final decision. This can occur when an applicant doesn’t provide requested information, or provides wrong information in their initial application which prevents your underwriting team from reviewing the application.

In these cases, report the application as always through the create_from_application endpoint. Then use the report_decision endpoint with the ID from the response and set the decision type to additional_information_requested. This lets Stripe know the original application isn’t considered a “complete application”.

Command Line

cURL

If the applicant provides more information

If the applicant provides more information within 30 days to “complete” the application, then use the create_from_application endpoint with the same connect account ID to report the new application and create a new underwriting record. Set the submitted_at field to the date when you received the additional info which “completed” the application. As always, report the decision on the new application within 30 days.

If the application remains incomplete after 30 days

If the applicant fails to provide additional information to “complete” the application within 30 days, reject the application. Do so by using the same credit underwriting record ID and posting to the report_decision endpoint with the decision type application_rejected and incomplete_application as the reason. This decision requires an AAN for rejecting an application.

See the complete list of valid decision reasons for all available options.

Command Line

cURL

Caution

If you report an incomplete application as “additional_information_requested”, you have 30 days to either report a new application for the same connected account, or to update your decision on the original application to rejected. Stripe compliance might notify you of a compliance violation if you fail to take action within 30 days on incomplete applications.

Make proactive underwriting decisions on existing users without a customer application

To change a connected account’s credit limit or deactivate a credit line without receiving an application from the account, report the decision in a single step through the create_from_proactive_review endpoint.

There is no decision_deadline for proactive reviews, since you report the decision in your initial API call (unlike for applications which require you to first submit the application, then submit the decision within 30 days).

If the decision results in a new credit limit, you’ll also need to set their credit_limit_amount in the CreditPolicy API. If you decide to close their credit line, you’ll also need to set their status in the CreditPolicy API to inactive.

Refer to these example scenarios for detailed steps:

• Proactively decide to increase an existing user’s credit limit
• Proactively decide to reduce an existing user’s credit limit (requires an AAN)
• Proactively decide to close an account and deactivate a CreditPolicy (requires an AAN)
• Take no action after a proactive review

Diagram: Proactive underwriting scenarios without a customer application.

Report a proactive review with a decision to take no action

Sometimes a proactive review might result in no action taken on the account. You can report that decision by setting the decision type to no_changes. This decision type is commonly used when reporting an exception.

Command Line

cURL

Override your written credit policies by submitting an exception

Underwriting decisions must be consistent with the parameters defined within your bank-approved credit policy. In rare circumstances, you may need to report a decision that is an exception to your usual underwriting criteria. Only do this after consulting with Stripe Compliance.

Override an application decision

Since you can only report an application decision once, only report the decision after the exception has been made.

Use the exception hash to record the default policy decision in exception.original_decision_type and explain your rationale for the exception in exception.reason.

As an example, after reviewing an application, the default decision based on your written credit policy was to reject the application. However, you’ve received evidence from the applicant of a nontraditional revenue source, so the decision is to approve the application instead. Report the decision as credit_limit_approved, and in the exception hash set original_decision_type to “application_rejected” and provide your explanation.

Caution

If you get an error “A decision already exists for this CreditUnderwritingRecord”, you need to use the /correct endpoint instead of /report_decision to modify an existing decision. When a decision exists, you must use the /correct endpoint to make changes.

Command Line

cURL

Override a proactive review

If a proactive review would have resulted in a policy decision that you decide to override, use an exception and set the decision type to no action. In this example, the proactive review results in an original_decision_type to reduce the credit limit, but the final decision is to take no action, and the rationale is provided in the exception reason.

Command Line

cURL

Correct an erroneous credit underwriting record

If your original submission contained incorrect information, you should POST to /the relevant part of the product/{the related setting}/correct with the ID of the previous credit underwriting record to override the prior application or decision you submitted. No additional explanation is required to submit a correction, and you should only use this method very rarely, to override mistakes in your reporting.

After correcting a record which changes the credit limit or status, update the CreditPolicy to reflect the corrected decision.

Sending adverse action notice emails

All Issuing platforms are required to send customer emails upon certain trigger events. Stripe helps you stay compliant by sending properly formatted notices when required.

Stripe offers a no-code solution to send regulated emails on your behalf. We recommend this option because it helps you stay compliant automatically, but you can send regulated emails yourself if you prefer.

Negative credit underwriting decisions that impact a customer require adverse action notices to comply with Regulation B. See the list of Charge Card events that require a customer notice.

Charge Card notice email templates

When Stripe sends regulated emails on your behalf, we send the below templates to your customers immediately after you report one of the trigger events above. You can preview each template from the Emails by clicking Preview and Customize under Stripe Issuing Notices.

If you’ve configured your custom email domain, Stripe automatically removes the italicized text in each template below. We only include this text when we send the email on your behalf from .

If you prefer to send these emails yourself, you can send your own templates to for approval. You must include all the legal disclosures and critical information from the Stripe templates, but you can customize some wording with your brand voice.

An application for a new charge card account is rejected

An application for an increased credit limit for an existing account is rejected

Your platform decides to reduce the credit limit for an existing account

Your platform decides to close the credit line of an existing customer

In the templates above, we replace <bank_specific_ECOA_footer> with the appropriate equal credit opportunity act disclosure for your platform’s bank sponsor.

We replace <Application rejected reasons>, <Credit limit decreased reasons>, and <Credit line closed reasons> with the descriptive text from Stripe API documentation (not the raw API value) for each reason you provided. For example, if you provided a reason customer_already_exists, the template shows “The applicant has a pre-existing application or is already a customer”.