The servicing feature is designed to manage mortgage servicing requests that are triggered directly from the lender's banking system, such as upcoming renewals or payment change requests. These requests differ from deals that originate in the Loan Origination System (LOS), which are either manually created or ingested through a POS system. The servicing feature streamlines the handling of servicing tasks, requests, and workflows, ensuring efficient management within the system. The user interface and workflows for servicing and origination are similar. This guide provides an overview of servicing related functionalities and the overall workflow.

Note: Servicing is a tenant setting meaning it is only available in your environment if you request to enable this functionality. To do so, please contact the Client Success Team.

Role and Permission Management

Admin users with the appropriate permissions can configure roles and permissions specifically for servicing-related functions. Creating new servicing roles ensures that users are granted access to the appropriate servicing features and workflows while restricting their access to origination-related functionalities, if necessary. Roles and Permissions are configured within the Role Management section of the Manager Portal. To gain a better understanding, you can refer to our Roles and Permissions Management PFG.

To find the Role Management section for Servicing, follow these steps:

Navigate to the 'Manager Portal' from the top menu.
Click on the 'Role Management' option in the sidebar on the left. The section has two subsections: Origination and Servicing.
Select the Servicing option. When configuring servicing roles, the Servicing tab in the Role Management section should always be selected to ensure the appropriate stages and roles are configured specifically for servicing.

The division of both tabs makes the task of role management easier. When assigned to a servicing role, users will only see the servicing pipeline and will not have access to the origination pipeline. Similarly, if a user is assigned an origination role, they will only see the origination pipeline. The permissions for the servicing roles mirror those for origination, but they are specific to servicing-related functions. Refer to this link to watch a video demonstration: Servicing - Role and Permission Management.

Note: If a user is assigned both origination and servicing roles, they will have access to both pipelines. This configuration maintains clear separation of duties and ensures that users only access the functionalities necessary for their role.

Linked Stages

The Linked Stages field in the Roles and Permissions section can only be linked to servicing stages for servicing roles. Similar to the functionality for deals in the origination pipeline, once a role is linked to a stage or multiple stages, users with that role will have visibility of the unassigned deals in the linked stages through their Pipeline View. Once a user is assigned or self-assigns to a deal, that deal will no longer appear in the Pipeline View for other users with the same role.

Note: If a role is unassignable, it cannot be linked to any stage.

Roles must be configured in the Manager Portal before they become visible in the application dashboard and team members can be assigned to them.

Task Management

Task management is an essential component of the servicing feature. Admin users can create tasks related to specific servicing requests. These tasks can be linked to certain stages in the servicing process to ensure that required actions are completed before the deal moves forward. For example, tasks can be associated with stages like "Waiting for Signature" or "Queued for Upload," where specific fields must be filled out before the deal proceeds. The system allows users to create, view, and manage these tasks efficiently, ensuring that servicing requests are processed smoothly and on time. The configuration for Task Management in servicing mirrors that used for origination, ensuring a consistent user experience across both workflows.

Note: When setting up servicing-related tasks, ensure the Servicing tab is selected in the Role Management section to maintain a clear distinction from origination tasks. Please refer to the Task Management PFG for further details on task configuration.

Document Management

Document Management within servicing allows admin users to set up and control the documentation requirements for servicing deals. As in origination, specific document types or templates can be linked to servicing stages, ensuring that necessary documents are provided at the appropriate steps. Users can configure Document Management separately for servicing, ensuring that the right documents are requested and uploaded as part of the servicing workflow.

When configuring document management for servicing, always ensure the Servicing tab is selected in the Document Management section. This helps keep the document workflow aligned with servicing-specific requirements. Further details on configuration are available in the Document Management PFG.

Products Management

The configuration of servicing products follows the same process as deals in the Origination pipeline, as outlined in the Products, Credit Tiers, and Rates PFG. There is no need for separate Origination and Servicing tabs because products are managed using the external ID field, which accurately maps each product. As long as the external ID field is properly filled, the correct servicing products will be applied, maintaining the integrity of product selection.

Ingestion of Servicing Requests

Servicing requests, such as renewals, payment changes, and cost-of-borrowing adjustments, are triggered by the user directly from the lender's banking system. Once the appropriate servicing option is selected, the deal is pushed through to FundMore's LOS. These deals will then appear in the servicing pipeline, specifically in the Open stage, where they can be managed and processed accordingly.

Servicing Pipeline

For the most part, the Servicing Pipeline functions the same as the Origination Pipeline. A noticeable exception is the exclusion of the “Create New Application” button as this option is not available in this view. The Servicing Pipeline will be visible to users with Servicing roles (i.e. assuming they have the appropriate permissions). This is where users can see all the servicing applications assigned to them, unless they have roles with broader permissions to view, edit, or engage with deals beyond their own. To gain a better understanding of the functionalities within the pipeline view, you can refer to our Pipeline View PFG.

Each application is labeled with a purpose tag (e.g., Renewal, Payment Change), serving as a visual indicator for users. The deal card provides other key details for each application, including the deal number, property address, loan amount, closing date, and, where applicable, information about co-borrowers.

Avatar Profile Icon for Deals

Similar to the Origination Pipeline, when users are in the Servicing Pipeline, they are able to see at a glance who is assigned to a deal. The assigned users are represented in an avatar profile icon at the top right corner of the deal card. Furthermore, if they hover over the icon, it expands showing more details about the user, or where relevant, other team members assigned to the deal. If no one is assigned to the deal, they will see an unassigned icon.

Board/Kanban View:

List View:

Servicing Deal Stages

The stages within the servicing pipeline include the following:

Open
Waiting for Signatures
Ready for Upload
Queued for Upload
Uploaded / Completed
Canceled

Users can move servicing requests through the various stages, just as they would in the origination pipeline. Deals are locked once they are uploaded or canceled. Uploaded deals cannot be moved back to "Ready for Upload," and canceled deals cannot be edited. This ensures data integrity and prevents unintended changes.

Filter, Sort, Deal Priority, Search

The pipeline shows all incoming servicing requests and allows users to filter, search, and prioritize them for more efficient processing. The Filter, Sort, Deal Priority, and Search functionalities in the servicing pipeline are identical to those in the origination pipeline. There are two search boxes to keep in mind, each one behaves differently:

Global Search: Accessible via the search icon in the top navigation menu (to the left of the help icon) - this search function displays results for both origination and servicing deals. Each result clearly identifies whether it belongs to the origination or servicing pipeline, allowing users to search across both pipelines, provided they have the necessary permissions.

Pipeline-Specific Search: Located next to the "Servicing Applications” heading at the top of the pipeline (i.e. above the filter options), this search dynamically updates as you type and only shows deals relevant to the selected pipeline—either origination or servicing.

Application Dashboard

For servicing deals, the widgets within the application dashboard are Servicing, Loan Details, Credit, Conditions and Documents, and Stakeholder Details. For the most part, the functionality remains the same as detailed in the Dashboard PFG. The following sections will highlight any servicing-specific differences in functionality compared to the origination dashboard.

Note: The Loan Details and Stakeholder Details widgets are currently read-only. The Credit Widget is opened for editing in the Open Stage - this allows users to edit the FICO and BNO scores directly within the application.

Adjustments for Servicing Deals

The information at the top of the dashboard includes: the name of the primary applicant and any co-borrowers, the application ID, the product number, the subject property address, the closing date, and the creation date of the application.

Note: For Payment Change or Cost of Borrowing deals, the closing date will be set as the Effective Date.

The ratio summary bar for metrics like LTV, GDS, and TDS has been hidden within the servicing pipeline to minimize unnecessary clutter.
In the Stakeholder’s Details widget, we have disabled the ability to request client screening.

The functionality for tasks and stage transitions remains unchanged, as outlined in the Deal Stages section of the Dashboard PFG. However, tasks for servicing applications are limited to those configured in the servicing section of Task Management in the Manager Portal. For instance, tasks related to adjudication have been disabled for servicing applications.

Document Generation: Only documents configured for servicing in the Manager Portal can be generated in servicing applications. This ensures that irrelevant documents are filtered out. For more details on Document Generation, refer to the Generate Documents PFG.

Conditions and Documents: The functionality for the Conditions and Documents widget remains unchanged. For a comprehensive guide on this widget refer to the Conditions and Documents Widget PFG. Additionally, you can refer to the FundMore.IQ PFG for a guide on managing document requests.
We have included a Source of Business field for Servicing deals. This helps to ensure that the correct renewal products and rates are applied based on the originating business channel. This aligns with the existing Source of Business field in Origination and enables product filtering. The Source of Business value is sent from the lender’s banking system to the LOS via API. The value for this field will be displayed in the Loan Details widget.

The Source of Business field displays the ingested value from the banking system. The available options include Retail, Mobile, Broker, and Digital. The rules for product filtering as it related to this field are as follows:

Product Filtering:

If the Source of Business is Retail, Digital, or Mobile, only Retail products will be available in the dropdown list.
If the Source of Business is Broker, only Broker products will be available in the dropdown list.

Servicing Deals

When you open a new deal, a pop-up window will appear, requiring you to fill out specific information based on the purpose of the deal. This may vary, for example:

Renewals: The pop-up will request the Renewal Type* and Renewal Date*.

Payment Changes and Cost of Borrowing: The relevant fields such as Servicing Type* and Effective Date* will be required.

Users have the option to skip this step, as the required fields can also be filled in the Summary tab. However, users cannot navigate to the Mortgage Terms tab in the Servicing widget until these fields are completed.

If the deal comes into the LOS without an application purpose, the pop-up will not appear. Users must first select the purpose of the application from the options in the servicing widget to trigger the pop-up. As seen in the example below, the Mortgage Terms tab is disabled and cannot be accessed until the required fields are completed.

Mortgage Terms

The Mortgage Terms section will vary in appearance and fields based on the application purpose, ensuring that users have a streamlined and relevant experience when managing servicing deals.

Renewals

Renewal applications enable users to extend existing mortgage agreements with updated terms, allowing for adjustments to the mortgage that may better suit the borrower’s current financial situation. These are automatically triggered by the lender’s banking system.

When handling renewal applications, the Mortgage Terms tab is divided into two columns:

The left column displays the Current Values pulled from the lender's banking system, reflecting the existing terms of the mortgage.
The right column provides fields for users to enter the New Values related to the renewal process.

Payment Changes

Payment change requests allow users to modify the payment structure of mortgages, enabling adjustments that can lead to better financial management and alignment with the borrower’s current capabilities.

In the case of payment change requests, the Mortgage Terms tab also features two columns:

The left column displays the Current Values pulled from the lender's banking system.
The right column provides fields for users to enter the New Values related to the payment modifications.

The fields displayed in this section depend on the selections made in the Servicing Type field of the Summary Tab. Options such as Increase Payment, Decrease Payment, Change Frequency, or Change Payment Date will dynamically adjust the fields visible to the user. This tailored approach ensures that only relevant fields are presented.

Cost of Borrowing

Cost of borrowing adjustments focus on providing transparency regarding the costs associated with borrowing.

For cost of borrowing adjustments, the Mortgage Terms tab is simplified to a single column displaying the Current Value from the lender's banking system. This straightforward layout is designed to provide clarity on the existing terms without requiring users to input new values, as the focus is primarily on informing them of the current cost implications rather than making changes.

Refreshing Applications

In the Open stage of the Servicing Pipeline, users have the option to refresh an application by clicking the Refresh button. This action updates the values within the application to reflect the latest data. Refer to this link to watch a video demonstration: Servicing - Refresh Action.

Note: The refresh option is only available in the Open stage. In all other stages, the button will be greyed out.

Uploading to Lender’s Banking System

Users can choose to upload deals to their company’s banking system by selecting the Upload Now button, available via the menu accessed by clicking on the ellipsis next to the Cancel button. Alternatively, deals can be moved to the Queued for Upload stage, where the upload will happen automatically at the appropriate time.

Deals uploaded without errors will now automatically transition to the UPLOADED COMPLETED stage. If errors occur during scheduled uploads, the deals will return to the Ready for Upload stage from the Queued for Upload stage. For manual "Upload Now" actions, deals will remain in their current stage if an error occurs. Additionally, buttons are disabled during pending actions or uploads in progress to prevent unintended transitions.

Submissions

When a servicing application is resubmitted, a banner will appear at the top of the dashboard. This serves as a visual indicator that the deal is a resubmission. The banner will include a link that can be used to navigate back to the original submission. The system logic for this functionality has been refined to exclude COB, Cancelled, and Uploaded applications, simplifying workflows and enhancing the user experience.

Alternatively, users can use the submissions tab in the left-hand navigation menu to track previous submissions. If the application originated in FundMore’s LOS, a link to the original application will be provided in the Submissions section. If the application originated from the lender's banking system, there will be no link available as the system does not support that functionality.

Additional Notes on Servicing

Renewals

For Renewals, users can adjust the Renewal Date depending on the type of renewal:

Early Renewal: The date can be set between the Next Payment Date and the Current Maturity Date.
On Maturity: The Renewal Date field is locked and not editable. For the On Maturity Servicing type, the Renewal date is preset to the Current Maturity Date on the deal. This can be viewed in the Summary tab of the Servicing widget. When "Renewal on Maturity" is chosen, the current maturity date will automatically populate as the effective date in the renewal modal, summary, and mortgage terms sections. This update ensures accurate date alignment with the expected current maturity date. Video Demonstration: Preset-current-maturity-date-as-effective-date-for-on-maturity-renewal.mp4
For these deal types, the Total Loan Amount will populate with the current balance of the mortgage instead of the original mortgage amount.

Editing Rate Type and Product Reapplication

During Renewals, users are given the ability to select the rate type and reapply the necessary products. This functionality streamlines the renewal process by providing easy access to key variables that impact the deal. To do this, navigate to the Mortgage Terms tab in the Servicing Tab and update the relevant fields in the New Values column on the right side of the screen.

Closing Date

For closing date selection in renewals, users have the option to select today’s date as the closing date. This allows for same-day renewals, including those with a maturity date of today. This ensures greater flexibility for immediate transactions and seamless handling of time-sensitive renewals.

Refresh Projected Balance

For Renewals, users can update the Projected Balance by clicking the refresh icon next to the Projected Balance field. This enables them to recalculate the balance whenever the renewal date is changed or payments are recalculated, ensuring that any payments made up to the renewal date are considered.

For renewals, the payment calculation process uses the Projected Balance instead of the Product Balance. This ensures that new payment amounts are based on the most up-to-date balance, with calculations for the blended rate and amortization schedules. The integration of the Projected Balance streamlines the renewal process, ensuring consistent results across all renewal scenarios including in the relevant documents.

Blended Rate Payment Automation in Early Renewals

For early renewal applications, the system now automates the recalculation of the payment amount when a blended rate is selected. Once the blended rate is applied, the payment is updated dynamically based on the updated final rate, streamlining the renewal process and ensuring accuracy.

Video Demonstration: Automated-Blended-Rate-Payment-Recalculation.

Ability to manually initiate mortgage renewal

Users can initiate a mortgage renewal directly from the lender's banking system. The key features of this functionality are as follows:

Selecting "Renew" from the product menu in the lender's banking system disables other servicing options and redirects the user to the FundMore LOS for the renewal process.
The FundMore LOS pre-populates renewal details, including Application Type or Mortgage Classification as 'Renewal.'
Users can pull individual credit bureau reports for all borrowers if not available via Equifax extract.
For multi-borrower renewals, the FundMore LOS determines pricing based on borrower credit scores.
Eligible rates are displayed from the Manager Portal's rate table, with a 30-day rate hold, including consideration of start and expiry dates.
The system prevents overlapping servicing requests by locking "in progress" actions and displaying relevant messages for active servicing requests. When a mortgage renewal is in progress, the system displays a message and provides access to review the renewal details. If a payment change request is in progress, a message notifies users that the payment change is in flight.
Servicing requests require a status of 'Complete' or 'Cancelled' before initiating a new request.

Payment Changes

Closing Date on Payment Change Deal Type

For payment date deal types, the closing date will automatically update to match the effective date, ensuring accuracy in servicing deals. Video Demonstration: Fix-Servicing-Effective-Closing-Date.mp4

Prepayment Validation

The system validates payment increases against the Original Prepayment Percentage ingested from the lender’s API. This ensures that prepayment increases comply with the lender's terms and are clearly communicated to users. Here is how it works:

The Original Prepayment Percentage is ingested from the lender’s system and displayed in the Current Values section.
The system calculates the maximum allowable payment increase based on the Original Prepayment Percentage and the existing payment amount.
An error message is displayed if the new payment amount exceeds the maximum allowable increase based on the Original Prepayment Percentage.

Example 1:

If the original prepayment percentage is 20%, warnings appear only if the new payment surpasses a 20% increase, maintaining compliance with the originally permitted prepayment limits.

Example 2:

Original Payment Amount: $1,234.57
Original Prepayment Percentage: 20%
Maximum Allowable Increase: $1,234.57 × (20 ÷ 100) = $1,481.48

If the New Payment Amount is $1,500, an error message appears because it exceeds the $1,481.48 limit.
If the New Payment Amount is $1,450, no error message appears as it is within the allowable limit.

Remaining Prepayment Room

If a prior payment increase has been made, the system adjusts the Original Prepayment Percentage to reflect the remaining room for additional increases. For example:

Original Prepayment Percentage: 20%
Prior Increase Used: 10%
Remaining Prepayment Room: 10%

This adjusted percentage is applied to future payment changes, ensuring the lender’s prepayment limits are respected.

Payment Change Constraints

We restrict input options depending on the user’s selection for the Servicing Type:

When selecting “Increase Payment” or “Decrease Payment” only, the Next Payment Date in the New Values section defaults to the value of the Next Payment Date in the Current Values section, and cannot be modified.

For “Change Frequency” only, adjustments to the Payment Amount and Amortization are disabled to align with the selected servicing request.

These changes help ensure users can only modify applicable fields based on their selected payment change action. Video Demonstration: Disable-inputs-based-on-selected-Payment-Change-types.mp4.

Additionally, the servicing product includes constraints for Payment Change requests. These constraints ensure a streamlined process and they include the following:

Change Frequency + Change Payment Date: This combination allows users to adjust both the frequency of their payments and the specific payment date.
Decrease + Change Payment Date: Users can decrease their payment amount and select a new payment date to better fit their financial situation.
Increase + Change Payment Date: Users can increase their payment amount while selecting a new payment date, facilitating better management of their payment schedules.

These enhancements are designed to provide greater flexibility and control over payment management, ensuring users can tailor their servicing options to their needs.

Payment Frequency Change for Variable and Fixed Rates

The system supports payment frequency changes for both Variable and Fixed Rate mortgages. The system will now calculate payment amounts based on the selected frequency using predefined formulas, ensuring accurate and seamless updates. Some of the key features include:

Supported payment frequencies include: Monthly, Semi-Monthly, Biweekly, Biweekly Accelerated, Weekly, and Weekly Accelerated.
The system uses the current payment amount and frequency to calculate the new payment amount when the frequency changes.
Variable and fixed-rate calculations adhere to the following rules:
- For Variable Rates, the prime rate (non-LOC) plus/minus increments or decrements is applied to determine the final rate used in the calculation.
- For Fixed Rates, the existing final rate is used.

Payment Change Scenarios:
- Increase/Decrease Payments (Variable): Changes are based on the current prime rate plus/minus adjustments, ensuring they do not exceed the maximum remaining amortization.
- Frequency Changes: Conversions between payment frequencies (e.g., monthly to biweekly) are calculated using standard conversion formulas.

Cost of Borrowing:
- For variable rates, COB is calculated using the current prime rate plus/minus adjustments.
- For fixed rates, COB uses the existing product rate mapping.

Fixed-rate mortgage changes maintain the existing rate logic while allowing frequency adjustments.
Automatic recalculations ensure accurate updates to the payment amount based on the selected frequency.

Payment Frequency Selection Constraints

When updating the payment frequency and the selected frequency is semi-monthly, we have implemented a constraint on date selection. The system permits only the 1st and 15th of each month as payment dates, aligning with the current configuration for origination deals. As a result, users will only be able to select these two dates within each calendar month when choosing payment dates.

Restrict First Regular Payment Date for Semi-Monthly Payments

Note: This is a tenant setting and defaults to disabled. To enable it, please contact our Client Success Team. For tenants who have this setting disabled, the First Regular Payment Date allows selection of the 1st and 15th.

To align with the client’s banking system, the system enforces validation on the First Regular Payment Date when the payment frequency is set to Semi-Monthly. The details for this functionality are as follows:

Process on Deal Ingestion:
- The application is ingested into the system.
- The payment frequency is set to Semi-Monthly, and the loan type is either Mortgage or Loan (not LOC or Bridge).
- The system automatically selects the First Regular Payment Date (15th or 30th) based on the closing date. For example:
  - Closing Date: December 7 → First Payment Date: December 15th
  - Closing Date: December 16 → First Payment Date: December 30th
  - Closing Date: December 30 → First Payment Date: January 15th

- The Interest Adjustment Date and Interest Adjustment Amount fields will remain empty until the First Regular Payment Date is manually adjusted.
- When the user manually adjusts the First Regular Payment Date
  - Users can only select the 15th or 30th as the First Regular Payment Date for Semi-Monthly payments. Only the 15th and 30th (dates after the closing date) are displayed as selectable options in the date picker.
  - If the user attempts to manually type a date other than the 15th or 30th, or a date before the closing date, the system will display an error.

- - The system then calculates and displays the Interest Adjustment Date and Interest Adjustment Amount.
- The selected First Payment Date (either 15th or 30th) is pushed to the lender’s banking system for Product Creation

Impact on API for Product Creation:
- When selecting the 30th as the First Payment Date for semi-monthly payments, the system will pass this selection to the banking system for product creation.
- If the 1st is selected (and if it can't be removed from the LOS), the product creation will fail.

Cost of Borrowing

COB Calculations

The system aligns Maturity Date with Final Payment Date. The system auto-populates the new maturity date based on the selected product and term. It ensures the maturity date falls on the last valid payment date before the original maturity date. This means that if the initially calculated new maturity date is later than the current maturity date, it is adjusted to the last scheduled payment before that date. This keeps the maturity date aligned with the loan’s original schedule and ensures accurate interest calculations. Any changes to Term/Remaining Term, Closing Date, Interest Adjustment Date, or payment frequency will trigger a recalculation to reflect the final payment date, ensuring accurate COB calculations. The updated maturity date is then sent to the banking system and used for documentation. Video Demonstration:

Demo I: Maturity Date Calculation on Payment Change
Demo II: Servicing - Maturity Date

The calculation logic for Total Amount of All Payments and Total Interest for the Term of the Loan in Cost of Borrowing (COB) disclosures reflect the remaining loan term and updated servicing details such as remaining term, payment frequency, new payment amount, loan balance, rates, and maturity dates. This ensures that document disclosures correctly display payment and interest totals based on the latest servicing updates.

Video Demonstration: Total-Payment-and-Total-Interest-in-document-context.

Total Cost of Borrowing Calculation

The system uses the servicing mortgage product balance value (Mortgage Balance field) as the Total Loan Amount in the Total Cost of Borrowing (COB) calculations. This ensures that the COB accurately reflects the new loan details, including the remaining term, payment frequency, new payment amount, and maturity date. The number of payments and amortization schedules, including those for weekly and biweekly frequencies, are correctly calculated.

When working on deals where the Purpose is set to Cost of Borrowing, users are able to edit the Effective Date, providing flexibility in adjusting key dates according to deal requirements.

Other General Notes

Amortization and Payment Amount Calculation

Users with access to the Servicing pipeline can adjust amortization and payment amounts as part of their servicing tasks. These adjustments trigger automatic recalculations of both the payment amount and the amortization period. When users modify the payment frequency or amounts, the system updates the mortgage details accordingly, ensuring consistency in the updated terms.

The calculation logic utilizes the remaining term to ensure more accurate outputs in the amortization schedule within the document context for servicing scenarios. This improves the precision of key metrics, such as Total Interest Paid for the Term of the Loan and Total Amount of All Payments. These are particularly impactful for Payment Change and Cost of Borrowing (COB) requests, ensuring accurate documentation that aligns with the updated servicing terms.

Interest Adjustment Date (IAD) Calculation

The servicing system automates the calculation of the Interest Adjustment Date (IAD) and adjustment amount during payment changes. The IAD is based on the last payment date and THE new payment frequency, ensuring accurate interest for the interval between payments. For example, when switching from monthly to biweekly payments, the system calculates the IAD to cover the time from the last monthly payment to the first biweekly payment. This removes the need for manual entry, reduces errors, and ensures accurate interest adjustment for all payment frequency changes.

Video Demonstration: Enable Editing for IAAmount + Remove Calculation.

Adjustment of First Payment Date and Impact on Amortization

Note: This is a tenant setting and may not be enabled in your environment.

When the first payment date is manually set earlier than the regular payment frequency (e.g., before the end of the first month in a monthly payment schedule), the lender’s system processes a full payment. However, interest is only calculated for the shortened period, with the remaining amount applied to the principal.

As a result, the loan balance after this first payment is smaller than it would be if interest were calculated over the full period, which impacts the amortization schedule. To address this, we have configured the system to adjust the amortization schedule accordingly, ensuring accurate balance and payment breakdowns.

APR Calculations for Payment Change and COB Deals

For all Payment Change and COB deals, the APR is displayed in the New Values section of the Mortgage Terms tab. The APR calculation is based on the remaining term and incorporates both existing and updated information, including the Projected Balance for renewals.

APR calculations have been further refined to reflect accurate values based on deal type and rate selection:

For Servicing Renewals: APR aligns with the new product’s final rate or the blended rate, if selected.
For Servicing Payment Changes: APR is calculated based on the current final rate, as there are no associated fees.

Additionally, the system now uses the Next Payment Date instead of the First Regular Payment Date for APR calculations across all servicing deals. This ensures the accuracy of APR calculations for these deal types while maintaining consistency and avoiding the introduction of additional fees.

Video Demonstrations:

Property Tax Calculation Automation

We have an automated calculation feature that converts the requested mortgage property tax amount to match the servicing mortgage payment frequency. This ensures seamless integration of property tax with mortgage payments throughout the servicing process. For a detailed demonstration, refer to this video: Property-Tax-Calculation-Automation.

Increments

Users with appropriate permissions enabled can edit increments within a servicing application. This can be done within the Mortgage Terms tab of the Servicing widget.

Prime Rate Implementation for Variable Rate Servicing Applications

The servicing system applies the current Prime Rate and adjusts it based on increments or decrements for servicing applications with variable rates. This ensures accurate representation and calculations for variable rate scenarios in both new and existing deals.

Prime Rate Adjustment: The LOS automatically pulls the configured Prime Rate and adjusts it appropriately to determine the Final Rate.
Renewals Update: The rate mapping logic skips unnecessary mappings from 'productRate1' in renewal scenarios. This ensures that the correct rate is applied to servicing mortgages.

Functionality using prime rate:

Payload Sent:

Prime Rate configured:

Application Result:

POF Variable Rate with Payment Change/COB

Skip Mapping Net Rate for Renewal Application - Servicing Mortgage

Warnings and Notifications

Next Payment Date: A warning will be displayed if the Next Payment Date falls within five business days of the deal ingestion date. This warning will appear next to the Next Payment Date field in the Current Value column on the left side of the Mortgage Terms tab in the Servicing widget.

Warning on Payment Decrease: When the payment amount is decreased, a warning message and icon are displayed if the new amount results in an amortization period exceeding the remaining contract. Refer to this video demonstration: Warning-AM-Servicing.
Custom Field Check: Only fields relevant to servicing are marked as required, preventing unnecessary prompts for fields that are not applicable.

Servicing

Product Feature Guide

Table of Contents

Introduction

Role and Permission Management

Task Management

Document Management

Products Management

Ingestion of Servicing Requests

Servicing Pipeline

Avatar Profile Icon for Deals

Servicing Deal Stages

Filter, Sort, Deal Priority, Search

Application Dashboard

Adjustments for Servicing Deals

Servicing Deals

Mortgage Terms

Renewals

Payment Changes

Cost of Borrowing

Refreshing Applications

Uploading to Lender’s Banking System

Submissions

Additional Notes on Servicing

Renewals

Editing Rate Type and Product Reapplication

Closing Date

Refresh Projected Balance

Blended Rate Payment Automation in Early Renewals

Ability to manually initiate mortgage renewal

Payment Changes

Closing Date on Payment Change Deal Type

Prepayment Validation

Payment Change Constraints

Payment Frequency Change for Variable and Fixed Rates

Payment Frequency Selection Constraints

Restrict First Regular Payment Date for Semi-Monthly Payments

Cost of Borrowing

COB Calculations

Total Cost of Borrowing Calculation

Other General Notes

Amortization and Payment Amount Calculation

Interest Adjustment Date (IAD) Calculation

Adjustment of First Payment Date and Impact on Amortization

APR Calculations for Payment Change and COB Deals

Property Tax Calculation Automation

Increments

Prime Rate Implementation for Variable Rate Servicing Applications

Warnings and Notifications