The Making of Underwriting Module

Question: Why you should be interested in reading this blog?
The purpose is to reach out to everyone who wants to better understand any problem, when and if it presents itself.
Also, I am trying out this new framework of Question-Discussion to represent how it helped me handle one of the projects I worked on recently.

Question: What this blog does not do?
This blog does not provide any framework with questions to ask for a specific type of problem. I am working on creating an abstract questionnaire for Technical Problems. Will share it as soon as I done with it.

Question: What is Underwriting Module? (Understand the domain)
Underwriting is the brain of any technologically driven finance system, enabling better decision making and lowering risks of loss or damage. Underwriting Module covers Fraud Detection, Loan Offers Management, Credit Scoring, etc.

Question: What are the challenges associated with Underwriting? (Get-to-know challenges)
Underwriting has a lot on its plate both in terms of depth and breadth of responsibilities. From providing credit-score that considers customer’s finances, spending patterns, social group activities to generating loan offers suitable enough for customer’s needs. And that’s just for one type of loan. Imagine the same requirements with n types of loans.

Question: What are the different components of Underwriting?
There are many components to building Underwriting. Loan Products(types of loans). Each loan product can have specific user eligibility criteria(1). Each loan product can have set-rules(2) to generate credit-score in a definitive way. For example, for a high-risk loan product, you might want to get all credit bureau reports but for a low-risk loan product, you can do with most-trusty one(saving money).

Question: How to design a system to incorporate the above-mentioned components? (the proposed solution)
Most system design problems can be solved by following design patterns. And that’s what I propose for solving the above-mentioned problems.

(1) For providing the desired functionality for different loan products, I used Provider Pattern. Define a helper service whose responsibility is to redirect requests to its designated loan product provider. For example,
Helper —LoanApplicationService (redirect request to respective loan service)
Provider1 — HomeLoanApplicationService
Provider2 — PersonalLoanApplicationService
Provider3 — CarLoanApplicationService

(2) For performing different rules in a given order, I used Chain-of-Responsibility Pattern. This pattern lets you define each rule as an entity and easy association with rule-initiator. For example,
Rule1 — Whitelisted
Rule2 — Blacklisted
Rule3 — CreditBureau1
Rule4 — CreditBureau2
EligibilityRules(HomeLoan)—[Rule2, Rule1, Rule3, Rule4]
EligibilityRules(CarLoan) — [Rule2, Rule3]
EligibilityRules(PersonalLoan) — [Rule3, Rule1, Rule2]

Question: Why is this a good solution? (why the proposed solution work)
The above solution enhances flexibility for incorporating any new changes greatly. If a new eligibility rule is introduced, we simply introduce that as a new entity. If a new loan product is introduced, we simply add a new provider for that loan product.
Also, this solution makes the system capable of plug-and-play. Experimenting with new or modifying existing components can be done with simple configurational changes.

Question: Where do I reach out for further comments/suggestions?
Discussion: Insta + Twitter + LinkedIn + Medium | Shivam Aggarwal