Account Status

Account Statuses and Sub-statuses in Canopy are static attributes associated with the account. For the most part, account statuses are not automatically changed by Canopy’s system, and they do not kick off any additional behavior in Canopy’s system. Instead, they are used for providing context around the account — for servicing and analytic purposes.

There are a few exceptions; in some cases, Canopy may automatically change an account status in response to some behaviors, for example if there is a configured policy to do so. These are documented in the table below. Outside of those automated cases though, statuses are expected to be managed programmatically via API call or via UI. If account statuses need to be changed based on activity that occurs within Canopy, a webhook response pattern is recommended. For example, listening to line_item_create and line_item_update webhooks to detect reductions in account balance, and responding to those webhooks with a call to edit the account status accordingly.

Account Status to Sub-status pairings are enforced within the system. The pairings accepted are defined in the table below. If your team needs to see another pairing added to support the operational needs of your lending program, please contact our support team at support@canopyservicing.com.

Full Account Status List

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
	`HARDSHIP/EXEMPTIONS`
`SUSPENDED`	`BANKRUPTCY`	A customer calls and states they have filed for bankruptcy. Account placed in this status for further review.
	`FRAUD`	An account has been suspected of fraud and needs further review.
	`INACTIVITY`	An account is suspended after a certain period of inactivity
	`RISK_REVIEW`	Based on activity monitoring, an account is suspended for further review. An example may be unusual activity on the account (. 5 x the average number of monthly transactions)	If using the Galileo integration, draws on an account will be frozen.
	`INELIGIBLE`	Account does not meet the criteria to maintain an account
	`DELINQUENT`	Account is past due in a way that is operationally defined the 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
	`CHARGE_OFF`	Account is charged off in a way that is operationally defined the the terms of their loan or line of credit.	If using the Galileo integration, draws on an account will be frozen.
	`DECEASED`	Customer is deceased and account needs to further investigated
`CLOSED`	`BANKRUPTCY`	If BK has been verified	System stops processing events for the account
	`FRAUD`	If fraud has been verified	System stops processing events for the account
	`INACTIVITY`	If lack of activity exceeds predefined threshold	System stops processing events for the account
	`RISK`	Account has been comprised and either its just closed, or its closed and possibly a new card is issued (the latter to be part of card processor integration)	System stops processing events for the account
	`CUSTOMER_REQUEST`	Customer decides to close the account	System stops processing events for the account
	`GRANTOR_REQUEST`	Grantor decides to close the account	System stops processing events for the account
	`DECEASED`	Account is closed for death of customer	System stops processing events for the account
	`CUSTOMER_REQUEST_PENDING_PAYOFF`	Customer requests account to be closed, but still has balance	System stops processing events for the account
	`GRANTOR_REQUEST_PENDING_PAYOFF`	Grantor requests account to be closed, but still has balance	System stops processing events for the account
	`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
	`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
	`SURPLUS_BALANCE`	Account has been paid off in excess of what was due	System stops processing events for the account
	`SETTLEMENT`		System stops processing events for the account
	`ADMINISTRATIVE`	Account was closed for administrative reasons	System stops processing events for the account

FAQ

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.