Introduction

This Project involves the creation of an end-to-end, fully automated loan origination system. A new customer needs only minutes to take out a loan from the bank with this application. Everything is automated, from the calculation of credit scores, to dynamic application processing and emailing of loan confirmation to necessary parties.

This is one of the projects where it’s close to impossible to complete it alone simply because of the scale and tools needed. Our FYP had to span not just Fintech, but also the scope of BA + DCS.

Photo of our customer app for loan application:

Photo of our credit scoring simulation to understand how the model performs and outputs:

Risk Grade Versioning as time goes on and banks revise their risk grade:

Project Overview

We had 2 sponsors, and worked with SMU + Narwhale Financial. The applications we built could be used on both fronts and helped to aid student’s learning + real loan application customers.

We managed to create a fully working training application that can be used to showcase what an Automated Loan Origination System (LOS) is. This will bring great impact to SMU Fintech students as the application will be integrated into the suite of Fintech teaching products.

Additionally, we kickstarted the negotiation with one of the leading Business Process Modelling providers (Camunda), and paved the way to for an educational license for learning. They had never given an educational license before and this was definitely an achievement. It was difficult because a lot of stakeholder management was involved, trying to negotiate and justify the license use.

There were also key challenges both on the technology and business side.

For technologies, there were many new technologies to learn and many moving parts to integrate. We didn’t just use the new technology, but we ensured that the best practices were followed, so as to ensure future maintainability and application scalability via modularization. On the Business side, there was a lot of stakeholder management, while also having to run UATs.

Application Overview

We had multiple features. At a high level:

1. New customers can log into the appliation to view, create, or handle anything to do with loan applications.
2. Bank Staff will be able to log into their own portal and look at all the current loans in the pipeline.
3. An automated credit scoring module will calculate credit scores for the customer and handle risk assesment. If the credit score is good, the loan will be automatically approved. For bad credit scores, the loan is automatically declined. For grey-area scores, it will be flagged out to appropriate bank staff for review.
4. Credit Scoring Simulation for Loan Administrators
5. Risk Grade Versioning
6. Secure Login using existing tBank APIs
7. Automated Emailing System using Business Process Automation

Technologies Used

There were multiple moving parts and much to learn as many of these technologies were new to us.

Upon following the best practices, we were able to modularize many of our services. We also had to handle 3 different deployment environments, in Outsystems, AWS EC2, and Camunda.

Outsystems

Outsystems was really challenging to use at first. There were both pros and cons to using Outsystems. Outsystems is great for fast prototyping, global variable management, and also pre-built UI. However, Outsystems is not as versatile on customization. Additionally, it is not easy to learn and follow on Outsystems best practices. Working with outsystems is quite complex in the beginning, and some programming knowledge will definitely help.

Outsystems also had it’s own process flow, and it is challening to model in Outsystems because of some limitations. However, the modeller is quite handy in that it allows for long running processes and easily integrates with the rest of the Outsystem application. Challenge comes when you want to integrate with external sources, and in our case it was for Camunda.

As an introduction, you could see how complex Outsystems can cummulate into. A simple table pagination feature can require so many low-code variables and functions. Even though we were using low-code platforms, it is still important to follow good coding princples such as variable naming and using proper variable types like Enums.

Camunda

Camunda was on a different level. Camunda is a Business Process Modelling tool that helps you to model and deploy the busines process automation on a self-hosted or cloud-hosted environment. Camunda is extremely versatile and brings about strong business process automation. It was really good to be able to visualize the business layer and orchestrate business tasks.

However, there were also challenges.

First, the modelling had either a self-hoted or cloud-hosted plan. We tried to self-host but it was very difficult to run the application, and there were many bugs that occured. Moving to cloud-hosted was very expensive, and we came up with a way to negotiate for an educational license for testing.

Second, was that the modeller lacked some functionality. It wasn’t great at supporting large text chunks. So in that sense, we had to do hacky string concatenation + there was no way to add spacing and paragraphing. So our email automation was slightly weird, but still readable.

Lastly was the lack of support of communication protocols. There was an issue communication with non-gRPC services. We had to create a gRPC wrapper layer to allow for communication between Camunda, Outsystems, and our AWS EC2.

AWS

Then came the integration of applications. We had a few constraits

1. The application had to be deployed on AWS, on a specific environment, due to business constraits.
2. Windows EC2 was initially prefrred instead of Linux based EC2s -> But Windows has Hypervisor Limitations while proved to be an issue for docker deployments. Hence we negotiated to shift to Ubuntu based instance.
3. But GUI was preferred. We had to do our own instance sizing to estimate costings and come up with the right instance size that will be able to run the workload while incurring low cost.

In the end, we also had to set up the entire environment from scratch. This involved thinking of an easy way to do continous deployment. It was not possible for us to include a CI/CD pipeline due to business and time constraits, and we proposed a script alternative that will help the sponsor handle any re-deployments.

Conclusion

This post focuses more on the technical implementation and challenges faced while building the application. Hope you enjoyed it!