An Example of AI in the Real World: Mortgage Application Prediction
The word “mortgage,” in old French, means death pledge as in “this debt is yours until you die.” While mortgages are more flexible than their root word implies, you are cemented to the responsibility of repaying your loan. To obtain a mortgage, a borrower must apply for one through an institution, where a loan officer uses his business acumen and domain experience to properly assess the lending risk depending on an individual’s varying factors.
Thankfully, one of Finastra’s products, known as Mortgagebot, streamlines the whole mortgage lending process. So with this already in production, our innovation team proposed the idea of using machine learning and artificial intelligence to predict the probability of a mortgage approval as an additional feature to the platform.
On one hand, we want to lighten the load on a loan officer’s plate — reviewing each extensive application is time consuming. On the other hand, we want to help our clients (the financial institutions) by increasing the number of mortgage applications that result in closed loans. One way of doing so is to display instant estimated approval rates to the clients.
While intelligence is largely associated to be a human trait, the revolution behind AI is because of its ability to efficiently detect and illustrate problem solving, learning, perception, reasoning, and patterns. It’s worth noting that there is a stigma surrounding AI — especially portrayed by the media: think movies such as Ex Machina (2014) and I, Robot (2004) featuring Will Smith. People seem to be afraid of AI or reluctant to utilize its benefits because of the misconception that humans will be replaced by machines. However, as illustrated by the Mortgagebot feature, I believe AI is a powerful tool that humans can adopt to enhance our work and efficiently increase our productivity.
One of the most common uses of AI in production is to take a different approach than the conventional business order and influence alternate opportunities — the algorithms can delve into unforeseeable patterns or projections to influence a company’s management into making the correct data-driven business decisions. In our case using Mortgagebot, say that an institution consistently has a lower actual approval rate. This could prompt the institution to adjust their underwriting eligibility to ensure that the filters are not being too restrictive. Also, when a borrower is approved for that institution, they are less likely to shop around and apply for loans at other institutions. For institutions that do not offer online approvals at all, we hope that seeing estimated approval rates can show them a better idea of how many applications they could approve. This, in turn, could help their close rates.
I’m sure you’re familiar with America’s 2008 economic crisis, AKA the Great Recession, which was largely due to the housing market. Thus, we are well-aware that there are hills and troughs in lending cycles. Since new, real-time mortgage data is continuously streamed into the database, we built a pipeline that would allow for automatic retraining of the model. This ensures that our model adapts to the market fluctuations and economic trends to make more accurate predictions as time progresses.
The idea here was to attack the development of this model by treating it as a supervised learning problem because the data we are feeding into the algorithm is labeled — we know whether the submitted applications were approved or not. Furthermore, this is also a binary classification task because we split the data into two categories: denials and approvals.
We performed feature engineering, which is the process of selecting our features and constructing them to accurately represent the task at hand. We also performed statistical tests to determine which features would be more significant than others. Some of our features included were income, debt-to-income ratio, and indicative credit score.
Finally, it was time to choose an algorithm. Keeping in mind that, given our logistics constraints and computational time constraints, it is nearly impossible to build a perfect tree, we built a few models and selected the one with the best results. We experimented with bagging algorithms (Random Forest) and boosting algorithms (XGBoost, AdaBoost, Gradient Boosting, LightGBM). We needed a versatile model that could handle outliers, imbalanced data, bias, and overfitting in addition to being fast and handling huge datasets with high dimensionality.
Here at the Innovation Lab at Finastra, mostly what we do is proof-of-concepts. Someone will come to us and give us some data and say, “Hey, here is some of our data. How can you implement ML/AI to help us perform better?” We will discuss some use-cases, then we will deliver our work along with our explanations and evaluations to show whether this is possible and has some sort of potential or if we have any concerns. If they like it, they will take the necessary steps to expand it into production.
We were lucky enough to see our Mortgagebot project go all the way through from basic development to production. We work in 90-day innovation sprints here at the Innovation Lab, which means that we try to go from 0 (concept) to 100 (fully developed deliverable) in 90 days. We developed the model in 3 days on the week of July 8th, and it officially launched on August 29th. This feature had 7 clients live on the first day! It was an incredible achievement to not only the Innovation Lab and the Mortgagebot team, but to the whole company: this feature was the first ML/AI implementation in production at Finastra.
Here are a couple ways we are exploring to improve our model. Housing markets and socioeconomic levels vary from location to location — New York City’s market is vastly different from Des Moines, Iowa’s market. However, our current model trains only one model from the whole database of applications, so taking geolocation into account could shell out better insights. Another enhancement is to set up a pipeline where each institution could also train/retrain a second model that is custom to that specific institution, since requirements, qualifications, and preferences vary by institution.
If you’d like to learn more about what kind of tools we used to build the and implement the model, see details in this blog post here!
Thanks for reading!
