Due to the NDA with the client, the case study explains the problems solved by DevriX and our process breaking the business requirements into technical components and software architecture without sharing brand names and URLs.
We were contacted by a designer working as a consultant for an international bank in order to build the credit calculators for their main website. Prior to that customers had to use complex formula in order to manually calculate the final amount of the loan to be returned and interest rates over time. When compound interest is involved, it gets significantly more complicated to sort out the payment terms over time.
Our Business Process
Our contract started in the end of November. Due to the coming holidays in December (banks are often with more days off than private companies) we had several meetings and calls with the financial department in the headquarters, and a conference call with the technical lead who was leaving on a business trip for several weeks.
The financial department presented us with a list of formulas used for their calculations, and an overview of the calculators to be built. We had to build several different loan calculators for various use cases such as buying real estates or applying for a business loan, each having specific constraints in terms of amount and duration, and different payment terms.
We went over various use cases for applications by people and companies in order to determine the different fees and the general process applying for all loans in order to establish the generic platform.
In order to validate our results, we asked for 20 different spreadsheets listing specific loans. This was our base for determining additional fees and edge cases, as well as comparing our formula implementation based on different criteria.
Contracting Financial Analysts
One of our engineers was in charge of implementing the formula in the financial engine used for calculating the complete plans. The mathematical equations were extremely complicated, which is why we hired three financial analysts who were responsible for breaking down the formulas.
We managed the process internally and compared the results provided by the three contractors and our engineer. One of the contractors provided a solution with minor mistakes as compared to the other analysts. We focused on the detailed solutions by the other two contractors and managed to reproduce the results with different input combinations, so we set that as the base in our algorithm.
Technical Implementation
Since the technical solution was to be implemented within the bank corporate web solution built with ASP.NET, we had two options: building a Silverlight application or a JavaScript library. We ruled out Silverlight for several reasons and took the JavaScript approach that allowed us to build a fast and powerful calculator that inherits the look and feel of the corporate website, without introducing various restrictions across different platforms.
One of the main technical challenges was dealing with dates. Most interest fees were calculated based on several input parameters, such as: days in a month, number of business days, remaining interest amount (deducted over time), and several other arguments. In addition to having annual fees deducting this number over time, leap years and edge cases such as contracts started on December 31st, covering all use cases without introducing regressions to the main edges was challenging, and required a lot of attention and careful investigation of the presented results.
The final solution looks like this:
We built a beta of the engine and presented it to the bank staff. While some of their test results validated successfully, we received a number of invalid records with slight changes in terms of total amounts or annual taxes.
We encountered three different aspects that were not implemented in our beta engine:
- some algorithms required initial payment that changed the rest of the calculations
- some fees are applied annually, or every 3 years. We went over the long contracts for each calculator and adjusted the engine
- there were certain mathematical approximations that didn’t correspond to the mathematical rounding, but were included in the bank policy. Based on that our original engine resulted in slightly lower total amount to be paid
Our team got back to adjusting the financial engine in order to produce a working engine. We had a few emails back and forth asking for more test cases that let us isolate the specific scenarios. In a few weeks we implemented the final solution that successfully covered the original test cases and the new reports falling in the three categories above.
During the process we built a simplified version of the engine written in Python that included several layers of debugging toolkit libraries that allowed us to validate the script with the case studies and break on each step that didn’t correspond to the reports from the bank. This was essential to the development process as it saved us time and provided a second version of our engine that we could use for validating our results as well.
The JavaScript version also included a test suite that included an Excel library integrated with OpenOffice. This allowed the financial department to validate the results with both of their tools – their proprietary system and their spreadsheets with Excel formulas.
During the development process we did not have access to their original internal solution which was denied for security reasons.
Business Results
Our online calculators have been deployed online and are successfully used by existing and potential customers of the bank. This has increased the percentage of customers applying for loans, and the customer satisfaction levels due to the lack of “hidden fees” given the transparent calculator available online.
A month after the solution has been accepted, a senior manager contacted us and purchased an unlimited license that allowed the bank to deploy that platform internally, as our solution was significantly faster and easier to use than their internal system.