Testing Loan Processing Software – 8 Critical Elements

Testing Loan Processing Software has many steps

Over the years, XBOSoft has worked with several clients in end to end testing loan processing software. Although they are in the business of making loans and may have brick-and-mortar storefronts, whether in the consumer finance domain or the mortgage industry, software is a main driver in their business. Software with defects obviously can lead to large material losses as well as other legal liabilities if regulations are not understood and implemented correctly and on a timely basis as regulations change periodically. We’ve found that end to end testing loan processing software involves several key elements.

Testing Loan Processing Software – Key Steps

1. Loan Application: Testing loan processing software begins with the process of a user applying for a loan. This includes filling out the application form, uploading necessary documents, and submitting the application. Some organizations will probably have an integrated approach to mobile and web-based browser solutions, so ensuring a smooth experience across device types is essential as a loan application may be started on mobile and finished on the desktop web browser. Additionally, some functionality may be only available on one platform. Uploading documents and access to security functions of mobile devices may also circumvent automation capabilities on mobile simulators thus forcing the use of real devices with manual testing.

Another major element is to check if the software validates the input data correctly and handles errors properly. Data validation and error handling are easier said than done as there are many reasons that data can be incorrect, incomplete, or invalid. This would lead to different types of context-driven error messages to help the user finish the application successfully. The last thing you want is ERROR 3454.

2. Loan Approval: Testing the process of loan approval by the system is based on many factors with sometimes complex business rules. Data that may be needed to do the assessment include the loan purpose, user’s credit score, income (both past and present), employment details, long-term and short-term liabilities, debt-to-income ratio, properties or autos owned, down payment, collateral, co-signer, previous loan history, age and residency, repayment period, and other criteria. Loans can be automatically approved based on certain criteria, need manager approval, or automatically denied as well. Understanding these criteria as well as regulations about loan approval, all of which could change, adds to the maintenance of end to end tests.

The system should correctly calculate the loan amount, interest rate, and repayment schedule. Variable interest rates that depend on other numbers outside of the system, and the rules for calculating the interest add another level of expertise needed as interest calculations may be more complex than you think and are often regulated as well.

3. Loan Disbursement: Once the loan is approved, disbursing the loan to the recipient requires that the software correctly transfer the loan amount to the user’s bank account and update the loan status. Sounds simple but with fraud so prevalent these days many checks and verifications need to take place to ensure that the money got there and to the right place. Two Two-factor authentication is the first step, but this also often crosses into the mobile platform which adds another layer of complexity. In addition to ensuring that all paperwork and legal compliance is in order, the lender must comply with regulations regarding not lending to individuals involved in illegal activities or on government watchlists. This requires integrating with other systems to either pull in data or cross-check regularly.

4. Loan Repayment: Processing the repayment of a loan involves many aspects including repayment schedule, making and logging payments, late payments, early repayment, and default in the case the loan is not repaid according to the terms of the loan.

• Repayment Schedule: Generating the repayment schedule requires that the software correctly calculates the monthly payments and due dates, and sends reminders to the user/borrower. Sounds easy, but there are many variables involved. Loan interest rates can vary and have trigger dates to change. Other elements include additional principal or late charges.
• Loan Repayment: To repay a loan, the user should be able to make payments through the system, and the system should correctly update the loan balance and status. The calculation of the effect on principal may be different depending on what day the payment was made, and what late fees or other loan items such as insurance and taxes can be automatically added for some mortgage loans. 
• Late and Early Payment: When the borrower makes a late payment, the software should correctly calculate and apply late payment fees, and send notifications to the user.
• Likewise, if the borrower repays the loan early, the software should correctly calculate any early repayment fees or interest savings.
• Loan Default: Of course, the opposite of payment is no payment, otherwise known as default. In this case, the software should correctly update the loan status and initiate the default handling process.

5. Customer Service: To test the customer service features of the software, the user should be able to easily contact customer service through the software, and the software should correctly log and handle customer service requests by sending them to the proper group or department while also notifying the customer/end-user of status to let them know their request has been received and when they can expect a resolution.

6. Reporting: In testing loan processing software, the reporting features of the software are one of the most critical and difficult tasks. Reports need to be generated by the end-user or borrower but also by the financial institution making the loan. The borrower should be able to generate reports on their loan status, payment history, and other details. On the other hand, the bank or loan organization must be able to generate various reports for different functions and roles in the organization. A branch manager will have different needs as well as different access or privileges for different levels and aggregations or reports or maybe even down to particular data items. Many of our clients find that reports are the hardest element in their software to test due to the complexity of the data and parameters involved.

• • Data Items: Data items that require special attention during testing include personal information of the borrower (name, address, social security number, etc.), loan amount, interest rate, loan term, payment schedule, collateral details, credit score, and employment details. Since many of these data items are dependent on the time or status of the loan at any given time, they need to be tested at particular loan milestones.
  • Calculations: Many calculations need to be tested, but the most critical include the calculation of the loan amount, interest amount, monthly payments, total repayment amount, late payment fees, early repayment fees, and penalties. The software should also correctly calculate the outstanding loan balance at any given time. When calculations are done as part of a report, the date of the calculation should be put into the report to notify the user. 
  • Aggregations: Aggregations that need to be tested include the total amount of loans issued (for the financial institution), total interest earned (financial institution), total interest paid (borrower), total outstanding loan balance, total number of active loans, total number of defaulted loans, and total number of loans paid off. Many aggregations need to be tested based on the various users who are viewing/using them.

7. Security: Testing the security features of the software may seem like a ‘no-brainer’ but it can be quite complex depending on the level of security required by both internal mechanisms and audits or required by external regulations. At a minimum, the user’s personal and financial data should be securely stored and transmitted, and the user should be able to change their password and other security settings. Many security standards can be applied and tested to protect data dependent on the organizational context and what regulations they are subject to.

8. System Integration: Testing the integration of the software with other systems is a complicated task with many variables and parameters especially since it is difficult to set up a test environment with all the integrations and data that are identical to the live system. So setting up the test environment to be as close as possible to the live system and understanding what differences may exist and therefore differences in tests and results is critical. The software should correctly exchange data with credit reporting agencies, banks, and other external systems to receive and transmit data depending on the type of financial institution.

Collected via many years of experience in working with our clients to test loan processing software, XBOSoft not only helps its clients to prevent and find defects but also works diligently to provide recommendations on making the software better from an end-user point of view. Taking advantage of our domain expertise, we develop test scenarios not from a functional view, but from what a borrower will execute (and not) on a daily and monthly basis as their loan is initiated and all steps toward maturity.