Account Status
The status of an account in Canopy is communicated to borrowers and drives certain implicit behaviors that are important for operators of lending programs to understand
Overview
In the Canopy lending management system, Account Statuses and Sub-statuses are static attributes associated with each account. These statuses provide valuable context for servicing and analytical purposes. While most account statuses are not automatically changed by Canopy's system and do not trigger any specific behaviors, there are certain exceptions. In some cases, Canopy may automatically update an account status based on predefined policies. You can refer to the table below for documentation on these automated cases.
Managing Account Statuses
To manage account statuses, you can programmatically update them through API calls or make changes through the user interface (UI). If you need to modify an account status based on specific activities within Canopy, it is recommended to use the webhook response pattern. By listening to relevant webhooks such as line_item_create and line_item_update, you can detect changes in the account balance and respond by adjusting the account status accordingly.
Enforced Pairings and Customization
In the Canopy system, Account Status to Sub-status pairings are enforced to maintain consistency and accuracy. The accepted pairings are defined in the provided table. If your lending program requires additional pairings to support its operational needs, please reach out to our support team at [email protected].
| Account Status | Account Substatus | Description | System Automatic Behavior (if any) |
|---|---|---|---|
| ACTIVE | Status when a new account is successfully created or returned to active after correcting bad status | Automatically set active on creation | |
| ACTIVE | HARDSHIP/EXEMPTIONS | ||
| SUSPENDED | BANKRUPTCY | A customer calls and states they have filed for bankruptcy. Account placed in this status for further review. | |
| SUSPENDED | FRAUD | An account has been suspected of fraud and needs further review. | |
| SUSPENDED | INACTIVITY | An account is suspended after a certain period of inactivity | |
| SUSPENDED | RISK_REVIEW | Based on activity monitoring, an account is suspended for further review. An example may be unusual activity on the account (5x the average number of monthly transactions) | |
| SUSPENDED | INELIGIBLE | Account does not meet the criteria to maintain an account | |
| SUSPENDED | DELINQUENT | Account is past due in a way that is operationally defined by the terms of their loan or line of credit. Automatically set to SUSPENDED :: DELINQUENT after n-consecutive underpayments as configured at the product level. Note: This configuration is to be deprecated in the future in favor of using webhooks to control account status changes | |
| SUSPENDED | CHARGE_OFF | Account is charged off in a way that is operationally defined by the terms of their loan or line of credit. | |
| SUSPENDED | DECEASED | Customer is deceased and account needs further investigation | |
| CLOSED | BANKRUPTCY | If BK has been verified. System stops processing events for the account | |
| CLOSED | FRAUD | If fraud has been verified. System stops processing events for the account | |
| CLOSED | INACTIVITY | If lack of activity exceeds predefined threshold. System stops processing events for the account | |
| CLOSED | RISK | Account has been compromised and either it's just closed, or it's closed and possibly a new card is issued (the latter to be part of card processor integration). System stops processing events for the account | |
| CLOSED | CUSTOMER_REQUEST | Customer decides to close the account. System stops processing events for the account | |
| CLOSED | GRANTOR_REQUEST | Grantor decides to close the account. System stops processing events for the account | |
| CLOSED | DECEASED | Account is closed for the death of the customer. System stops processing events for the account | |
| CLOSED | CUSTOMER_REQUEST_PENDING_PAYOFF | Customer requests the account to be closed but still has a balance. System stops processing events for the account | |
| CLOSED | GRANTOR_REQUEST_PENDING_PAYOFF | Grantor requests the account to be closed but still has a balance. System stops processing events for the account | |
| CLOSED | CHARGE_OFF | Account has been automatically charged off based on exceeding some days since delinquency threshold. Automatically set to SUSPENDED :: CHARGE_OFF after n-consecutive underpayments as configured at the product level. Note: This configuration is to be deprecated in the future in favor of using webhooks to control account status changes | |
| CLOSED | PAID_OFF | Account has been paid off. Accounts in the Post-promo (pure installment loans) period automatically move to the CLOSED :: PAID_OFF status once the borrower’s full outstanding balance is paid off. System stops processing events for the account | |
| CLOSED | SURPLUS_BALANCE | Account has been paid off in excess of what was due. Accounts in the Post-promo (pure installment loans) period automatically move to the CLOSED :: SURPLUS_BALANCE status when the borrower's total balance is less than 0. System stops processing events for the account | |
| CLOSED | SETTLEMENT | System stops processing events for the account | |
| CLOSED | ADMINISTRATIVE | Account was closed for administrative reasons. System stops processing events for the account |
Frequently Asked Questions
If an account goes into delinquency (suspended, delinquent) if the customer only makes a partial payment not covering the full amount past due will the account remain in suspended, delinquent until the total amount past due amount is paid (including fees and accrued interest on the late fee) or the account is closed?
Yes. Unless the status is manually/programmatically changed via the Edit Account Status endpoint, it will remain in suspended until the full balance owed is repaid (or it is closed)
If an account is closed will there be any statement_generation webhook events to follow stating the loan is fully repaid?
If the borrower pays off their balance, the account will automatically close after their final statement date, so the final statement webhook will be sent. However, if the account closes for any other reason (manual account status change, charge-off, etc) -- you will not receive any subsequent webhook notifications.
Related Articles
Updated about 1 year ago