At Account Creation

At Account creation, you lay the scaffolding for some key dates that make up the shape of the borrower lifecycle.

In particular, you establish concepts such as

• The cycle structure for an account (when do their billing cycles end?) (denoted by first_cycle_interval and cycle_interval - these policies are instantiated for each borrower. For example; a borrower onboarded on March 15th and a 1 month cycle_interval would have all their cycles ending on the 15th of subsequent months. first_cycle_interval may be used to control the borrower's first cycle behavior; for instance, if you'd prefer their statements generate on the 20th of each month, you may make the first cycle long or short to account for this (5 days or 1 month 5 days). Subsequent cycle lengths will respect cycle_interval
• The interest calculation structure for an account (when does interest accrue? Daily? Monthly?) - denoted by the interest_calc_policy
• The due date for each billing cycle: positive values designate due dates counting from the start of the cycle; negative values count back from the end of the cycle. For example:
  • 25 days: denotes that the borrower's due date is on the 25th day of each billing cycle
  • -5 days: denotes that the borrower's due date is 5 days from the end of each billing cycle
    • For installment loans, we recommend using the pre_statement_payments_affect_min_pay configuration to ensure that payments made between the due date and the cycle end contribute to the borrower's next amount due.

These dates are instantiated at account creation, but they are often inherited from policies set at the Product level.

🚧

End of Cycle Behavior

Because dates are denoted by an interval, which may vary, Canopy defines certain end of cycle behavior. In particular:

• If a statement date is on a final day of a long month (longer than the subsequent month), the following statement dates will fall back to the latest of:
  • The last day of the month
  • The day that matches the original end of cycle.

Observe the following two examples:

• If the borrower's first cycle ends on the 31st of a month: all subsequent statements will end on the last day of each month. Cycles are denoted by cycle_exclusive_end which will always be the 1st day of the following month (i.e. 2023-07-01 04:00:00.000000 +00:00; indicating that the last full day of each cycle is the last day of each month. Remember - since this value is exclusive, the system treats the 31st as the last full day of that borrower's cycle; the 4:00:00 is due to a UTC offset from the borrower's product_time_zone of America/New_York
• If the borrower's first cycle ends on the 30th of January: The last day of their next billing cycle will be the 28th of February; all other cycles will end on the full day of the 30th of each month. Their cycle ends in the API response, when normalized for the product timezone, should have a day corresponding to the next full day at midnight, as the timestamp response is "exclusive". For example:
  • 2023-07-01 04:00:00.000000 +00:00- normalized to the America/New_York timezone is 2023-07-01 00:00:00.000000 +00:00--- this means that the borrower cycle includes the full day on 6/30, but does not include any of the day on 7/01.