Create a Product

What is a Canopy Product? It's a template that lays out the general policies to be enforced over your borrower’s lifecycle. Think of this as your blueprint for future lending programs.

Overview

A product in Canopy is a template that lays out the general policies to be enforced over your borrower’s lifecycle.

The majority of these policies can be optionally overridden when onboarding each individual borrower.

In production, you will likely only have one or two products in your system. In your sandbox, you can experiment with a variety of product setups to figure out which best meet your needs.

A product can serve as the template for revolving lines of credit, installment loans, and hybrid-type loan agreements, depending on which parameter values you set in the API call.


Product Categories

There are three general categories of products, but there are not hard lines between these categories. Canopy intends to have the most flexible lending management software; if your lending program doesn't fit neatly in these lines, it's still likely Canopy supports the configurations your program is looking for.

The three categories as Canopy identifies them:

  • Revolving
  • Multi-Loan (Revolving line with installment draws/advances)
  • Installment

Revolving

Revolving products give borrowers perpetual access to an account; the account is a vehicle for end-user charges, finance charges (interest, fees, etc.), and payments. The account is expected to be open in perpetuity, until such time as the borrower requests an account closure or the borrower's behavior leads to some delinquent status. An example of a lending program that would use this type of product is a Credit Card program.


Multi-Loan

Multi-Loan (Revolving line with installment draws/advances) products give borrowers perpetual access to an account; the account is a vehicle for loans against a revolving LOC issued to the borrower. The account is expected to be open in perpetuity until such time as the borrower requests an account closure or the borrower's behavior leads to a delinquent account status. An example of a lending program that would use this type of product is a Merchant Cash Advance program.


Installment

Installment products give borrowers access to an account with an expected closure date. The account is a vehicle for a single loan (sometimes with ancillary line items like origination or late fees, etc.). The account is expected to close at the end of the borrower's repayments (or at delinquency). An example of a lending program that would use this type of product is a Secured Loan program.


Endpoint Usage Guide

Configuration Steps

Product configuration may require some back-and-forth with Canopy's Delivery team to fully match your intended lending constructs with Canopy's product configuration constructs. Don't worry, we're happy to help.


There are a number of policy decisions to make before configuring your product with Canopy. We can group these into several categories, including but not limited to:

  • Product Overview, or general information about the product (such as a product name)
  • Payment Due policies, which configures system behavior around due dates and delinquency
  • Billing Cycle policies, which configures system behavior around cycle dates and time zones
  • Interest policies, which configures how interest will be accrued on borrower accounts

A more detailed description of each policy configuration can be found here.

Interest policies

There are two ways to specify how to calculate interest amount for the accounts under a product: either by providing a predefined calculation method, or by providing the individual configurations that make up that calculation method.

Predefined calculation methods

If one of the existing calculation methods corresponds to the desired way of calculating the interest amount, the most straightforward approach to specify it is to provide a predefined calculation method. You can do this by filling in the interest_calc_method field within product_lifecycle_policies.interest_policies.

Each calculation method is characterized by the formula it uses as well as by the moment when the interest is accrued. For example, daily_ending_bal_360 method calculates the interest amount at the end of each day using the following formula: [principal] * (r / 360) where r is the interest rate.

If no calculation method is specified, 30_day_end_bal_365 method is used by default. This method calculates the interest amount once at the end of each one month cycle using the following formula: [principal] * (r / (365 / 30)).

If an unsupported calculation method is provided, interest_calc_method field will work as a label and individual configurations will be taken into account.

Individual calculation method configurations

The second approach to specify the way to calculate the interest amount is by providing the individual configurations that make up the calculation method. These configurations are described below.

  • interest_accrual_interval
    • Interval that specifies when interest is calculated and accrued on the account
    • Possible values: 1 day, 7 days, 1 week, 1 month, etc.
    • If not provided, defaults to the length of the billing cycle (cycle interval)
  • interest_calc_balance_type
    • Target balance to be used when calculating interest accrual
    • Possible values: STARTING, ENDING, AVERAGE
    • Default value: ENDING
  • interest_year_length
    • The number of days a year has in the interest calculation formula
    • Possible values: 360, 365
    • Default value: 365

You can specify them by filling in the corresponding fields within product_lifecycle_policies.interest_policies.

It's good to know that these individual configurations can only be provided if the interest_calc_method field contains an unsupported method (i.e. a label). Otherwise, the product creation API will return a 409 Conflict response.


What’s Next