In the past we only supported account balance offsets. Now we support the ability to offset specific line item loans and allocate to amounts within that line item. You can Offset loans via the API and also inside of CanopyOS!
How do I use the new feature in CanopyOS?
We have expanded the experience of individual loans in CanopyOS!
This will allow you to access more actions that can be done to specific loans.
With the new Offsets drawer you can now select an offset and get a high level view of the affects before you submit it.
There are two types of Offsets, Debit Offsets and Credit Offsets.
Debit Offsets decrease the balance of a loan
Credit Offsets increase the balance of a loan
You can also choose allocation of the offset which can vary depending on the loan you are offsetting
Allocation Options: Principal, Interest, and Amortized Fees
You can still offset the account by accessing it in the Manage Button Menu on the Account Overview
Here you can apply offsets to the account balances
How do I use the new feature in LoanLab?
We also ensured you can make these actions inside of LoanLab as you simulate and create test cases for SafeGaurd. You can add them with a few easy steps:
When creating actions you can select Apply Offset
First you must choose if you wish to Debit or Credit with your offset.
Then, when you have the Apply Offset card open you can select where the balance should be allocated
You can select a individual loan that has been created on the account, or apply it to the account balance
Lastly, you can set up the details of the Offset below that
Choose the amount, allocation, and status of the offset to validate behavior in our system
FAQ
What happens when I offset for more than the balance of a given allocation on a loan?
When applying a debit offset that is more than the allotted amount in a given allocation, the remainder will be poured into the loan using typical payment pouring logic
When there is no balance left on the loan the offset will pour into the account using the typical payment pouring logic
Where can I see offsets?
They will be present in the Transaction History and Recent Transaciton views. They will also have the loan that they are correlated to on their details drawer view.
Canopy is excited to announce a significant update to CanopyOS with the launch of our new analytics dashboard. This innovative feature sets a new benchmark by providing instant, detailed insights into loan portfolio performance directly within CanopyOS. With immediate access to essential metrics like customer count, account numbers, and upcoming payment amounts, the dashboard simplifies the decision-making process and enhances operational efficiency for lenders, ensuring a more integrated and seamless experience.
Please be aware that these new features are currently available only to customers on Canopy V2.
Canopy is thrilled to announce an innovative update to our loan restructuring functionality, designed to offer lenders unmatched simplicity and adaptability in their restructuring efforts. This upgrade introduces a range of flexible options that significantly enhance the restructuring process.
New Enhancements in Loan Restructuring on Canopy v2:
Consolidation Capability: Allows for the merging of multiple loans into one, streamlining management.
Advanced Financial Options: Provides the flexibility to manage outstanding interest and fees with the option to offset and more optionality coming soon.
Enhanced Clarity with Contextual Notes: Enables the addition of notes for clearer understanding and documentation of restructuring decisions.
Ability to Change Min Pay Calculations: Offers the ability to alter the method used for calculating minimum payments, facilitating tailored repayment strategies.
Increased Transparency: Introduces a dedicated restructuring API endpoint and webhook notifications for more transparent communication.
This beta release is just the start, with more improvements on the horizon, including the ability to do loan restructures through CanopyOS.
In the past Canopy had only one Create Customer Entity input when creating them in our system. We understand that this created a frustrating experience so we solved this problem. You can now use the new Create Business Customer Entity to add business borrowers into your ledger.
What can I do now?
Now you can create business customers easily and set up business structures in your system.
Legacy format restrictions:
Historically you would use the create customer endpoint and use the customer_type field to select business.
The required fields on the call create an undesired experience
Businesses could only be individuals or Parent-Entities.
A business could not be a Child-Entity
How do I use this?
Historically you would use the create customer endpoint and use the customer_type field to select business. The required fields on the call create an undesired experience so you can now use the endpoint in the example below to ensure clean data is imported into your system.
Example:
Here is how you would add a business to Canopy’s API using the new endpoint
The goal of the new feature functionality is to enable your team to add business information into Canopy without needing to follow the more restrictive requirements of the legacy way of doing it. Which means new functionality is available as well!
What will this enable?
In the future we will expand the functionality of hierarchy and relationships between entities. This is a step towards that future. Today, however we have unlocked some awesome functionality for your teams.
You can create business structures using the new /customers/business endpoint
using the "customer_parent_id" you can set a new business’s parent entity to a pre-existing customer in our system using it’s customer_id
This means you can assign business entities under people or other businesses
FAQ
How do I create a person entity?
You still use the legacy API endpoint and it will not be deprecated to ensure API functionality for pre-existing data records.
We do highly recommend using this new endpoint moving forward for all business Customer Entities to ensure your program can access features built specifically for commercial lending.
Can I merge my existing data to the new endpoint?
Yes, but this will take intervention from our Client Delivery team and may need development based on your specific use case. Please contact your account representative if you are interested.
As an enhancement to our recently released Account Tagging feature, we have added the ability to filter your accounts by the tags that are applied to them.
To take advantage of this feature, navigate to your list of accounts in CanopyOS, select the Filter option, and choose which Tags you would like to filter for.
As an enhancement to our recently released Account Tagging feature, we have added a page within CanopyOS to make it even easier to add and management Tag Options. You can now add, deactivate, and see all Tag Options from directly within CanopyOS.
This new page can be found by selecting Tag Options from the Admin menu.
As an enhancement to our recently released Account Tagging feature, we have added the following enhancements.
Historic Audit Log Table in DataDirect
Accounts_Tags_Log: This new table is an audit log of historical changes of tags that were applied and/or removed from a given account. [Documentation]
Account Tag Webhook
When a Tag is applied or removed from an account, you can now subscribe to webhook notifications of these events. This new webhook is also available in Canopy Connect to trigger workflows from.
Business Information and Structures Accessible in CanopyOS!
We recognize that you cannot add business information easily into our system, and we would like to alleviate some of the frustrations around handling borrowers who are businesses. We also noticed our system was forcing undesirable data to be passed in some cases, which we want to clear up. Last, we wanted to enable more complicated business structures to be serviced easily.
We will be rolling this feature out slowly to select customers
Once this feature is enabled you can:
Easily view the Associated Entities to an individual Customer Entity
Edit Business Information inside of CanopyOS
View business structures inside of CanopyOS
New Terms
Entity - A person or business that has a stakeholder relationship
ei: an Account or Customer in Canopy’s API. They include Customers(Type: Person or Business), Suppliers/Merchants, Beneficial Owners, Payout Entities
Associated Entities - Refers to the concept of how people and businesses are tied together in complex commercial financing relationships.
Associated Entities Table - The UI component that allows you to see the entities associated to a customer
Associated Entities Tab - The new tab view under the Customer Detail Page to hold the Associated Entities Table
Associated Entities - How does it work?
Start off with the Customer Table being updated for easier identifying and filtering businesses vs people
You can now manage Business information on a specific customer!
We created an experience to help you understand the business structures in your system today. Below, you can see the new view of a Customer that is a business.
You can update business details in the new drawer
When pulling up individuals from the business, you can now easily see what business they are associated to.
Finally, we added a view to Customer Detail pages to allow you to view business structures better in our system. Associated Entities refers to the connections of other entities in our system.
What type of scenarios can be covered?
The goal of the new feature functionality is to enable the visualization and use of business structures in CanopyOS.
Opening your team to be able to do things like:
Figure out how many controllers have been added under a business
See what business an individual works for on their customer detail page
Be able to update business details and information operationally inside of the UI
Quickly filter by business or person when searching for customers
F.A.Qs
Does this effect any older client data I have in my system?
No, we created a solution that will support data that has been added to the Customers Table. This experience so that you can better view and edit this information
Can I create business structures inside of CanopyOS?
No, the goal of this experience is so you can view the business structures that you programmatically add to your ledger
What business structures can I see in CanopyOS now?
Canopy is excited to introduce our new Account Tagging feature. This practical tool allows customers to assign multiple, custom-defined attributes to their accounts, simplifying and improving account management. With Account Tagging, identifying specific accounts for reporting and operational tasks becomes simple and flexible.
You’ll notice the account view CanopyOS now has a new Account Tags card. You can apply new Tags to an account by hitting the Manage button.
You’ll notice Canopy has added a few Tag Options to get you going. You can remove these and add more at anytime through our API. See our API docs here.
Coming Soon: Stay tuned as we're working on further enhancements that will enable you to manage Tag Options directly through CanopyOS, adding even more convenience to your experience.
What’s the difference between Tags, External Fields, and Account Statuses? When do I use each?
Tags: Tags in Canopy are flexible, dynamic attributes or labels that you can associate with an account. They don't directly influence the system's behavior but are incredibly useful for categorization and contextualization. Tags are particularly beneficial for temporary or conditional information about an account, rather than permanent data. For instance, you might use tags to denote an account that requires review or to group accounts into specific cohorts.
External Fields: These are best suited for data that remains constant over the lifetime of an account. External fields are typically used to store stable information, such as external ID values from other systems, making them ideal for long-term, unchanging data.
Account Statuses: Account statuses in Canopy are primarily used to represent an account's current state within the system, influencing its behavior. For example, an account might automatically be categorized as Active, Delinquent, or Charge-Off based on its creation settings and ongoing activity. While some existing account statuses like Risk Review and Fraud don't inherently alter system behavior, they are more effectively utilized as Tags. Given this, Canopy plans to eventually deprecate these status options in favor of Tag usage; there is no set timeline on this deprecation at this time.
There are Tag Options available that are the same as some account statuses, what's the difference?
Account statuses in Canopy are primarily used to represent an account's current state within the system, influencing its behavior. For example, an account might automatically be categorized as Active, Delinquent, Closed-Paid Off or Charge-Off based on its creation settings and ongoing activity. While some existing account statuses like Risk Review and Fraud don't inherently alter system behavior, they are more effectively utilized as Tags. Given this, Canopy plans to eventually deprecate these status options in favor of Tag usage. While there is no set timeline on this deprecation at this time, we’ve seeded some of these options for you to get you started. You may deactivate these Tag Options if they are not of use to you.
What’s the difference between a Tag Option and an Account Tag?
A Tag Option is any attribute or label that you would like to be able to associate with account. An Account Tag is simple a Tag Option that has been applied to an account.
What does disabling a Tag Option do?
Disabling a Tag Option will remove it from being an option to be applied to an account. Please note that disabling will not remove the tag from all of the accounts it’s already been applied to.
What is the purpose of the color and description setting on a Tag Option?
The Tag Option color and description is there to provide further and context and clarity.
The Tag color is the color that will show within CanopyOS with the goal of easier and quicker identification. For example, perhaps you want to choose Red for risk related Tags to call greater attention to them, but use gray for more informational Tags, such as a cohort.
How can I identify which accounts a tag is applied to?
We have two enhancements planned for future releases to help you identify which accounts a tag is applied to.
We will have a new DataDirect table that will include all actively applied tags and which accounts they are applied to.
The Account list within CanopyOS will be enhanced to allow filtering by an account Tag.
Can I see a history of which tags were applied to an account previously?
An additional enhancement to be on the lookout for is a Tag history table within DataDirect.
The goal of the new feature functionality is to enable more sophisticated data connections to other systems that run your program
Opening your team to be able to do things like:
Being able to view and reference more non-Canopy data points within Data Direct Reporting for more advanced insights
Enable more systems to connect with Canopy and allow different data shapes to be passed into Canopy
Allow your team to add crucial data points needed for delinquency reporting, remediation, origination, and restructuring in our product experiences
What will this enable going forward?
With this feature we are releasing more flexibility on top of it very shortly. We will be expanding more functionality in the future to enable more sophisticated account tagging and external fields of client data.
This release is the first step towards more advance data correlations from external systems!
Feature Enablement:
External Field JSON Objects visible inside CanopyOS
Account Tagging
The ability to apply multiple, dynamically defined labels or attributes to accounts, enabling more precise and flexible account management and reporting.
FAQ
What formats are available to be entered?
The examples above show the formats excepted by our API with this new functionality
Can I pass in multiple formats onto the same data object?
NO, you cannot use multiple formats on an any object in the external fields column
What if I already use one format, how can my team switch to a more preferred format?
There are a few important aspects to note:
The data that is sent in the body of the request will fully override any values that were previously assigned to the account’s external fields. If you are intending to only update a single key value, we recommend doing a GET /account call first to retrieve the previous values, updating the relevant portion, and then providing that as your body for the request.
The endpoint will accept any valid JSON object, however, if the key/value structure above is not used, you risk breaking your CanopyOS view for the given account.
Changes to the external fields on an account do not trigger the account_update webhook.
Represents the account's credit limit minus the total of principal, interest, and fee balances.
This new field can be found on the following objects in the API:
account → summary
statement → open_to_buy
Noteworthy:
This new field is in addition to available_credit_cents, which isthe account's credit limit minus the principal balances.
The new net_available_credit_cents field does take into account the value configured for pending_pmt_affects_avail_credit, which determines if a pending payment affects the available credit on an account.
Business Information and Structures Accessible in CanopyOS!
We recognize that you cannot add business information easily into our system and we would like to elevate some of the frustrations around handling borrowers that are businesses. We also noticed our system was forcing undesirable data to be passed in some cases, which we want to clear up. Last, we wanted to enable more complicated business structures to be serviced easily.
You can now:
Easily view the Associated Entities to an individual Customer Entity
Edit Business Information inside of CanopyOS
View business structures inside of CanopyOS
New Terms
Entity - A person, or business that has a stakeholder relationship
ei: an Account or Customer in Canopy’s API. They include Customers(Type: Person or Business), Suppliers/Merchants, Beneficial Owners, Payout Entities
Associated Entities - Refers to the concept of how people and businesses are tied together in commercial financing in complex relationships.
Associated Entities Table - The UI component that allows you to see the entities associated to a customer
Associated Entities Tab - The new tab view under the Customer Detail Page to hold the Associated Entities Table
How does it work?
Start off with the Customer Table being updated for easier identifying and filtering businesses vs people
You can now manage Business information on a specific customer!
We created an experience to help you understand the business structures in your system today. Below you can see the new view of a Customer that is a business.
You can update business details in the new drawer
When pulling up individuals from the business, you can now easily see what business they are associated to.
Finally we added a view to Customer Detail pages to allow you to view business structures better in our system. Associated Entities refers to the connections of other entities in our system.
What type of scenarios can be covered?
The goal of the new feature functionality is to enable the visualization and use of business structures in CanopyOS.
Opening your team to be able to do things like:
Figure out how many controllers have been added under a business
See what business an individual works for on their customer detail page
Be able to update business details and information operationally inside of the UI
Quickly filter by business or person when searching for customers
F.A.Qs
Does this effect any older client data I have in my system?
No, we created a solution that will support data that has been added to the Customers Table. This experience so that you can better view and edit this information
Can I create business structures inside of CanopyOS?
No, the goal of this experience is so you can view the business structures that you programmatically add to your ledger
What business structures can I see in CanopyOS now?
Now it is easier to search for Line Item Transactions in CanopyOS! We have created a stand-alone tab on the Account Detail Page to allow you to view and filter all Line Item Transactions on an individual account.
Using advanced filtering, you can now find specific Line Item Transactions, groups, or windows of time to help you understand the history of an account. You can also search by line_item_id
The Account Detail Page has been simplified. The transactions table now shows the first few transactions. We also gave you a shortcut button to take you to the new page
Previous State:
New State:
You are now prompted to search the larger view to access the new filtering.
Some of the columns have changed names to better reflect what data it is showing from the API
Description → Line Item Type — Allocation
This is how we represent the information today in Canopy. We use the line_item_type and the allocation to fill this column.
The description is another field in the API that has different information.
The data that is sent in the body of the request will fully override any values that were previously assigned to the account’s external fields. If you are intending to only update a single key value, we recommend doing a GET /account call first to retrieve the previous values, updating the relevant portion, and then providing that as your body for the request.
The endpoint will accept any valid JSON object, however, if the key/value structure above is not used, you risk breaking your CanopyOS view for the given account.
Today, our system only allows you to define interest policy for your borrowers at a template (a.k.a. Product) level. The interest policy governs the amount of interest accrued on a borrower’s account (using that policy template, a.k.a. Product).
Previously, the only way to define it was via providing a predefined calculation method (interest_calc_method) in your POST …/products request. Some of the accepted values include monthly_ending_bal_360, cycle_start_365 etc. Read more here
Underneath, there is a formula:
Now, however, we added new fields which allow you to tweak individual configurations that make up that calculation method:
interest_accrual_interval - Interval that specifies when interest is calculated and accrued on the account. E.g. 1 day, 7 days, 1 week, 1 month etc.
interest_calc_balance_type - Target balance (Principal in the formula) to be used when calculating interest accrual relative to the cycle. E.g. STARTING, ENDING, AVERAGE
interest_year_length - The number of days a year has in the interest calculation formula. E.g. 360, 365
You can fill in the corresponding fields within product_lifecycle_policies.interest_policies.
AND
you should ALSO specify your own label/ Name for that interest calculation method under interest_calc_method. e.g. “My_new_calculation_method”. That’s a terrible example, but feel free to name it the way you like!
A bug occurred that caused users in timezones behind the product timezone to observe mismatched values for “Requested Outlay Date” on the “Request Details card” compared to the “Modify Request Details form”. This bug made it possible for “Requested Outlay Date” to be inadvertently changed, as the incorrect value in the form field would be propagated to the database when the form was saved.
This bug has been fixed and users should observe the same date for “Requested Outlay Date” in all cases, regardless of their local timezone.
As a quality-of-life improvement, you should be now able to filter the GET /Customers response by:
customer_type - can be either person or business
business_ein - EIN of the business, expected input format in NN-NNNNNNN.
as part of the search_parameters query parameter
Some other filters that had been available prior to this release, and could help you get results of Business customers faster/ more efficiently via search_parametersqueryparameter:
doing_business_as - The DBA name of the Business
business_legal_name - The legal name of the Business
As part of our effort to rename Delinquency_report table into a more-aptly-named Past_due_report within DataDirect, we have added an identical Past_due_report table.
Both tables are going to be available until the end of November, to give you enough time to update your scripts and ingest Past_due_report table going forward.
Delinquency_report table in DataDirect is getting deprecated on December 13th.
As a quality-of-life improvement, you should be now able to filter the GET {account_id}/line_items response by:
line_item_type - to show different kinds of transactions on a specified account. can be one of the following:
CHARGE
PAYMENT
CREDIT_OFFSET
DEBIT_OFFSET
MANUAL_FEE
line_item_status - to show all transactions of the selected status:
AUTHORIZED
DECLINED
INVALID
OFFSET
PENDING
POSTED
PROCESSING
RETRO_VALID
REVERSED
ROLLED
SETTLED
SPLIT_INVALID
SPLIT_VALID
VALID
VOID
effective_at_before and effective_at_after - to see all transactions processed by our system within the time constraints (inclusive).
Both query parameters expect a timestamp input. e.g. 2020-04-21T00:00:00+00:00
max_original_amount_cents and min_original_amount_cents - to see all transactions with original amounts within absolute monetary value constraints (in cents).
Canopy will add a new table to store all accounts recurring fee data with the appropriate relationship linking them back to the accounts table (relationship one to many - one account to many recurring fees linked by foreign key ‘account_id’ in accounts_recurring_fees)
The field credit_balance_cents has been added to the line item detail. In the Get Individual Line Item API request, you can now see how much each line item contributes to an account's credit balance.
LoanLab now supports simulating restructuring a loan for an account! Loan restructuring provides various options of changing an existing loan's behavior. Learn more about Loan Restructuring in Canopy's system here.
Try it out by using the new Restructure Loan option from the action menu in LoanLab!
Per notice that has been communicated with customers, Canopy is introducing a change to the handling of credit balances that occur primarily as a result of payments that exceed the total balance of an account.
Going forward, when a new line item is created, the system will automatically check for an existing credit balance on the account and pour the credit balance towards the new charge line item. If the credit balance fully covers the new line item amount, no interest will be applied.
In cases where the credit balance does not fully cover the charge, the system will apply interest to the remaining balance of the charge after the credit balance has been applied.
We added a new enum to the promo_min_pay_type called INTEREST_AND_PERCENT_PRINCIPAL_V2. This new min pay type formula will combine all unpaid balance, newly accrued interest within the cycle, newly accrued fees within the cycle, and an allocated percentage of the principle.
We’re excited to announce the launch of our newest product, Canopy Connect!
Connect is a user friendly workflow builder that allows users to integrate Canopy with the other systems that power their lending program and automate manual processes.
Click on Connect in the menu of your CanopyOS UAT environment to learn more!
Canopy’s new Preview capabilities are launching into Beta! Preview is supported for the Payment Creation, Payment Reversal, and Loan Creation API Endpoints.
Operations in the system of record are complex; often, a single operation results in many changes. For example, a single borrower payment alters balances, minimum payment obligations, amortization schedules, and more. The Preview API allows you to fully visualize all changes to the computational state of a borrower account prior to executing the operation.
Try it out in CanopyOS!
In CanopyOS, the Preview capabilities are now available in the Payment and Payment Reversal drawers.
While accessing the payment and reversal drawers, a new "Preview" button allows the operator to see what changes would occur to the account, new line items, allocation details, and even an updated amortization schedule where relevant.
These previews have no effect on the state of the account and can help operators make changes with confidence before committing to important account actions.
Using The Preview API
When the preview header is provided on a request for a supported API endpoint, a URL to the Preview endpoint with a fully formatted request will be returned. This endpoint returns all computationally relevant differences on the account from the operation being previewed.
This allows you to increase borrower transparency - for example, helping your borrowers understand the impact of payments they are considering making.
Preview helps operators and borrowers alike make good decisions and communicate effectively about the impact of changes they make before taking final action on an immutable ledger.
We currently consider the Preview feature as a Beta release - we would love feedback from your team! Please reach out to your account representative if you’re interested in providing feedback. Before a full-featured launch, we’d like to better understand:
The situations in which you preview operations on an account
The information you’re aiming to learn from Previews
Any designs or experiences you’re interested in embedding in your borrower-facing applications to increase borrower transparency
Any unsupported operations for which you are interested in Previewing Activity
Payment Reversals (or payment failure) in Canopy increase an account’s balance in two ways:
Reintroduced balances: The payment being reversed paid down some portion of interest, fees, and principal balances. This balance needs to be reintroduced by the reversal.
Retroactive balances: If the payment never occurred, overall interest and fees for the account may need to be higher. For example:
If the balance should have been higher, the borrower may need to have accrued more daily interest than they actually did
If the borrower’s payment helped them avoid a late fee, that payment’s failure means the late fee would have been assessed.
This release helps you granularize a payment reversal to understand how it breaks down to each of those categories:
Both when observing a statement and when observing a payment or payment_reversal line item.
See below for detailed changes to the API:
To improve visibility of retro-active events in our system (payment reversals in particular), we have added additional fields at the individual transaction (line_item) and a tallied-up cycle (statement) levels.
Both of those should give you a reversal breakdown (SPLITS) by balance types (PRINCIPAL, INTEREST, FEE), and whether that balance is re-introduced (existed before the payment and its subsequent reversal) or newly-introduced (net new balance as a result of the reversal).
At the line_item level (GET /line_item/{line_item_id}), we’ve added a new object called line_item_relationship_summary! It includes the following values:
At the statement level (GET /statements/{statement_id}), within the cycle_summaryobject you will get tallied up values of balances (INTEREST, FEE, PRINCIPAL) as a result of ALL reversals that cycle:
cycle_payment_reversal_interest_cents
cycle_payment_reversal_interest_split_cents
cycle_total_payment_reversal_interest_cents
cycle_payment_reversal_fees_cents
cycle_payment_reversal_fees_split_cents
cycle_total_payment_reversal_fees_cents
cycle_payment_reversal_principal_split_cents
cycle_reversal_split_cents
All of that in addition to individual line item detail (line_item_relationship_summary) within an array of objects (line_items) for that cycle!
This release includes a number of minor CanopyOS improvements:
In the “Account Detail” view, secondary customers of an account were incorrectly marked as “P” for primary. Now, all related customers should have the correct role.
When submitting the “Account Status Change” form after changing the account status, sometimes the user would be unable to submit the form without changing the account substatus as well. This has been corrected.
Sorting of rows in the “Interest Rate drawer” on the “Account Detail” view could be non-deterministic, causing the ordering to change on successive renders. This issue has been corrected.
The “Admin” menu in the top bar has been moved to the left navigation.
Previously, the dashboard view for Borrower Portal included upcoming payments for closed accounts in the Upcoming Payment list as well as summing them into the “Payments Due This Month” amount.
We are enhancing the way we support account statuses by allowing any account in a closed status (regardless of sub status) to continue to stop all cycle related activity (statement generation, reoccurring fees, new charges) while now supporting payment activity (payments, refunds, credits, offsets). Payments will also following payment pouring logic for applicable line items.
A bug in our release Aug 22, 2023 caused installment cards for embedded loans on the “Account Detail” view in CanopyOS to intermittently re-order, as well as amortization schedules for embedded loans to be incorrectly ordered.
A hotfix for this bug has been deploy: the ordering of installment cards and loan amortization schedules should now be fixed.
Previously, the Account Status Change form drawer available through the Manage menu in the Account Detail view did not have a notes field, unlike most of the other similar drawers. This meant that a user would potentially have to go through form submission twice: once to change the status, and once to add a note explaining the status change.
Now, Account Status Change form contains a note field which includes the context of which statuses the account changed from and to.
Previously, the statement detail view in LoanLab incorrectly displayed the statement’s minimum payment due for the “Previous Statement Min Pay” field due to mismapped fields in the frontend.
Formerly, in the App Keys view in CanopyOS, there was a poor user experience when attempting to add application keys when:
Organization is already at the maximum number of application keys
Application key name has invalid characters
Now, we properly disable app key creation when the organization is at the maximum number of keys, and user should correctly observe form validation errors when entering an invalid application key name.
Formerly, CanopyOS did not properly apply the product timezone in transaction detail drawers. In some cases, this resulted in a mismatch of dates between the “Transaction History” list and their respective transaction detail drawers.
This issue has been resolved, and all dates should now match between both views.
Canopy now allows sending webhook notifications to multiple URLs. This is useful if you need multiple systems to act on the activity and changes that happen within Canopy.
You can now also limit which webhook events get sent to a particular URL. For example, if you only wanted to receive webhook notifications for account creation events, you can limit that through our new filter property.
For more details on this change, please see our Docs.
Updates to the Canopy roadmap can be reviewed here.
Other changes
Improving the performance of retroactive engine
Updates to reconciliation reporting for money movement customers
Formerly, in some cases, after changing the “Requested Outlay Date” field in the “Modify Finance Request” form, and saving changes, an edge case caused timezone offsets to be applied incorrectly when the record was updated in the database, causing the “Requested Outlay Date” field to shift by one day.
This edge case has been identified and is now correctly handled, ensuring users should always observe the same “Requested Outlay Date” value after they save the form.
Previously, installment accounts in LoanLab had a fixed number of cycles (defaulting to the term of the loan). Two changes have been made:
The default number of cycles has been increased to the term of the loan + 1, as no payment is expected the first cycle. This additional cycle enables LoanLab scenarios with strict repayment and observing final statement with $0.00 balance.
The “Add a Cycle” button, formerly present only for revolving accounts, is now present on the timeline for installment accounts as well. This enables the user to create scenarios where borrower underpays (which will result in creation of an additional cycle).
Previously, because the merchant notes form default value was not populated from the API, a merchant with note would have its note overwritten with an empty value when submitting the “edit merchant” form.
Now, the “edit merchant” form should correctly populate the existing merchant note as the default value, allowing it to be edited, and ensuring it is not overwritten with empty values.
Previously, in the account detail view, when a drawer was opened by clicking an item in the “Manage” dropdown, in some cases the dropdown items would remain clickable while the drawer was open. This caused unintended behavior that could result in opening other drawers while interacting with the current drawer.
An additional safeguard has been added to ensure this does not occur.
Canopy has behaviorally changed handling of payment failures throughout the system to leverage our V2 Retroactive engine and to make the nature of behavior consistent with the reversal of settled payments.
All Impacted users have received full notice around these impacts and coordinated with the Accounts team.
LoanLab now supports the ability to simulate the behavior of an account when strict payment is enabled.
The new setting can be found in the Advanced Details section of the Account Setup screen.
Strict payment turned on will limit min pay reduction to only payments. Refunds and debit offsets will not reduce min pay when off. This setting is often useful for consumer products at risk of refund fraud.
Previously, in LoanLab simulations, a bug with initial null values being coerced to false resulted in amortization schedules always appearing as if minimum payments due had not been met. Amortization schedules in LoanLab simulations should now correctly reflect payment activity on the simulated account.
Previously, CanopyOS did not provide insight into which payment was reversed. Now, once a reversal has processed, users will observe a reversed tag in the Transaction History list on the reversed payment.
Previously, Upcoming Payments list view included payments for accounts in all statuses including CLOSED. This caused confusion as these payments are no longer expected to be made.
By default, this view now applies a filter that excludes accounts in CLOSED status. See new account_status filter for more details.
Previously, min pay principal amount in statements for revolving accounts was being sourced from the incorrect attribute and thus would be appear as -. Now it is correctly sourced from min_pay_details.min_pay_revolving_principal_cents
Previously, current interest rate in SCRA drawer was wrong in some scenarios. The current interest rate shown is now correctly sourced from from account.summary.interest_rate_percent.
LoanLab is powerful loan simulation platform that empowers you to experiment, validate, and optimize your credit and lending programs with confidence. Simulate the entire lifecycle of a loan, test different policies and actions, and observe real-time effects.
LoanLab can be found in the CanopyOS menu of your UAT environment.
DataDirect has added a new Refresh History Table to assist you in identifying the date and time of the last refresh of a particular table. This will also let you know the exact time at which a tables’ data is representative of.
A number of additional fields that were previously only available through our API are now also available through DataDirect as well. All available fields can be found in the DataDirect Getting Started Guide.
When a payment is initiated before a due date, but fails after the due date, all past due assessments can now be applied. This reduces fraud risk and guards against borrowers making a payment they know will fail in order to stay in the grace period, avoid fees, or avoid delinquency.
You can now safely modify the terms of a loan while preserving the history of loan activity. This supports a variety of use-cases depending on your loan agreement with your borrower. This allows you to enhance your lending programs to give borrowers more flexibility over their repayments, and adjust the structure of your loans to meet the changing needs of your borrowers.
Canopy has added the capability to charge interest on installment products (loans) using the average daily ending balance of the loan. Interest is calculated by multiplying the daily periodic interest rate by the mean ending balance of the loan across all days in the cycle in question.
Fine-grained transaction details from Galileo authorizations & adjustments are now present in Canopy line_item metadata for users of the Canopy Galileo issuer-processor integration.
For users of the Canopy Lithic Integration, Canopy is now prepared for Lithic’s published breaking changes taking effect on February 8th, 2023. No action is needed on your part.
Canopy has an allocation feature that may be applied to balance offsets to designate that the offset can be applied to a specific balance bucket (fees, interest, principal, or deferred interest). Previously, when applying an offset with an allocation, subsequently querying the offset did not let you know which balance bucket the offset was applied to. The allocation parameter is now included in the response, so you can see which balance bucket an offset was applied to!
You can now react to changes in an account’s calculations — any activity that changes a computed value for an account will automatically get sent to your subscribed webhook URL.
