One of the companies I had worked at was a midsized fintech startup. I helped in the development of their internal loan management and payment scheduling software. At the time the company’s main line of business was providing customers with short term loans. The graph below shows in high level how the system operated. The blue shapes were the parts that I had been working on:

The customer journey starts as a lead. Leads are individuals who were requesting a loan from us. We had an internal underwriting service which was responsible for determining the individuals eligibility for a loan. Once eligibility was determined a customer account was created.

At this point the loan would be released to the customer and they would be provided with a payment schedule. The payment schedule would indicate how much payment was to be made by the customer at what dates. If the customer completed all their payments the file would be marked as paid off. If the customer failed to make payments, then their account would go to collections.

---

Developing Right to Cure (RTC) and Collection Products

When a customer failed to make payments they would first enter RTC (right to cure) and later would enter collections if they still failed to make payments. RTC is legal preliminaries before sending the customer to collections.

During my time I helped develop the RTC product along with several other products for their collections department. Implementing these features was very challenging in several aspects:

• The internal software that the company was using was very large and complex and such features often required changes to multiple places in the product. This required a strong understanding of how the entire product worked.
• The collections and RTC products had many different stake holders each with a different set of requirements (legal, collections, finance, operations, customer support, …). When developing these features I would often need to ensure:
  • All requirements are being met.
  • The legal and compliance constrains introduced various edge cases which were not always apparent at first. I would often work these edge cases out and discuss them with stake holders to ensure we do not have surprises when going to production.
  • Everyone is aligned with what is being delivered.

---

Working With Financial Calculations

Anytime you take on a loan from any financial institution you are required to pay this loan back over a specific schedule. In calculating these payment schedules there are two parts:

1. Principle: This is the money you have been lent out
2. Interest: Every day depending on how much principle you have outstanding you will accrue interest on the remainder of the principle

See the graph below:

This is a very simple payment schedule. The customer pays off a bit of principle on each payment date. The more outstanding principle there is the more interest that they have to pay.

Things can get really complex here. Imagine the customer calls in and says they would like to pay their 5th payment along with their 4th payment and move their 7 payment 4 days earlier? Now not only are the calculations far more complex now, these changes effect the interest of all down stream payments.

What adds to the complexity is also rounding errors which you must at all times ensure you do not charge the customer more principle than originally stated.

---

Improving Software Processes

I introduced various changes that had improved the overall software development process.

Automated Testing: I introduced integration tests written in Junit. The tests would interact with the software at the controller layer and would simulate the same path a real customer would take during the lifecycle of a loan.

Version Controlling the Database: Many of our code changes were heavily reliant on database changes that needed to be deployed along with the code changes. Keeping databases under version control is critical as without this code changes can be deployed without a proper database migration and can end up breaking the software.

Introduced GitHub Webhooks: Github offers web hooks that trigger anytime someone makes a pull request. These hooks can be used to run various automated tests. By integrating Github webhooks with our automated tests we managed to ensure that any code change that were merged did not break any existing functionality.

Improving the CI Environment: Created a CI environment using jenkins that would run our automated tests, migrate the databases and deploy the relevant code changes to QA environments. This greatly improved our development speed and ensured we had consistent QA environments to work with.

---

Skills

Java, Junit, Google Web Toolkit (GWT), Flyway, Mysql, Jenkins