Having started its rise in the 2010s, fintech has changed the image of traditional financial services. With online banking, online investing, and online payments already existing, it has been only a matter of time for mortgage and loans to become digital products. They are becoming much more convenient than their traditional versions, more oriented at customers, and less time-consuming. And all these benefits are completed with the fact that millennials, one of the forces that powered the rise of fintech, are ready to become the target clients of the housing market. As the demand for mortgages is growing and the market orients at the digital users, online mortgage services aim to meet the needs of the present and replace traditional loan services.
Here, the essentials of an online mortgage software development are revealed: the pitfalls, recommendations, and best practices.
Table of Contents
- Why online mortgages thrive
- Organize the work process with your technical partner
- Flows, third-party integrations, and servers
- UI/UX Design
- Speaking of an online mortgage platform
My colleague once wrote that fintech appeared as a result of the never-ending struggle between the everyday need for financial activities and the difficulty with which we carry them out. We can conclude that one of the many factors that promoted fintech was the human unwillingness to deal with inconvenient and highly bureaucratic traditional financial institutions.
In terms of the service automation and rise of mortgage application software, a whole generation of people referred to as millennials has influenced the worldwide escalation of digital loan services. This is happening partly because millennials born between 1980 and 1999 are now mature enough to be the customers of such services, and partly because millennials comprise most of the purchasing population. As a result, businesses are shifting their strategies to satisfy the shopping habits of millennials by offering things like instant purchase, lower prices, and understandable products.
Online mortgage platforms are (1) more understandable than traditional bricks-and-mortar mortgage services (brokers, banks, etc.), (2) likely to move faster than a bank, and (3) probably cheaper.
According to JD Power & Associates, online loan services are experiencing a 30% higher loan growth rate compared to traditional institutions. The possibility of giving out 30% more loans should be sufficient motivation for companies to reevaluate their approaches and turn to a more customer-centric way of running their business.
But this does not mean that if you develop a mortgage service online, you will instantly become rich. There are many things to consider before and while creating such a service. In this article, I will share the experience my team and I had at Django Stars as we developed an online mortgage service for a client.
I will start with what your development team should know beforehand and what to focus on when designing a user flow. Then I will discuss integrations with third-party services, and in the last part I will tell you about the peculiarities of UI/UX in fintech products.
Here is what your development team should know to build mortgage platform suceessfully and how to organize the working process if you have an international team. I will focus on the pre-development stage – that is, what inputs are important before the real work begins.
In “mortgage platform”, platform implies that the service will be available to many types of users. It can be an individual who wants to get a mortgage, or a company (or a sole trader) that issues mortgages. Either way, define the roles in your platform and create an image of your customer.
Once you have them, you will answer two basic questions:
- Who do we do it for?
- How do these users interact with each other?
When you know who is going to use the platform, you can see how they are going to use it. Create a customer journey map to mark the stages of using the mortgage service and predict possible integration with third-party services. In this case, most such services are banks. You may need to use them to identify clients and get their credit records.
Based on the flow, you can see the user’s pain points and consider how to mend them. For example, many users do not like to give out their personal and banking information. When you have identified the step in which this is necessary, you can think how to transform a negative experience —”Somebody is going to see my credit record!” —into a positive one — “I will surely get a mortgage!”
Remember that banks are still traditional financial institutions, so some processes are bound to be full of foot-dragging bureaucracy. Take this into account when estimating the time required for certain operations in the flow.
If you are setting up an online mortgage for U.S., it does not always mean that Python development services will be delivered by the team that will be in there. This brief section is about working with international development teams.
To work efficiently, you need to remember the following things:
- Third-party services usually work only 9 to 5, local time. So if you need the Barclays Bank API, you can access it only from 9 to 5 BST. When you plan weekly activities, schedule meetings with third parties in advance to avoid delays.
- The time zones can be up to 8 hours different. This is a pain when working with international teams. From my experience, it is best to schedule meetings and plan your activities so that you have at least three working hours overlap.
- National holidays may be observed on a working day. Ask your technical team about such dates. According to Murphy’s Law, they usually occur during the week of the first release.
Regarding methodologies, there are many approaches to managing the Software Development Life Cycle (SDLC). The most famous is Agile. I wrote an article on why Agile SDLC model is the best for your startup. It will give you a basic understanding of Scrum and Kanban and when to apply one or the other.
Now let us go deeper into the study of user flows and integrations with third parties.
Well-thought-out user flow predicts higher user engagement. Along with other factors that I will mention later, the flow defines whether a user will turn into a customer. If your high-level flow seems too complicated, you need to optimize it.
One specific trait of mortgage software development is that users have to provide lots of personal information, and developers must figure out how to make this process painless. The process of filling out the online forms is time-consuming and frustrating. Most users quit websites when they are asked to fill out forms.
Caption: When working on Moneypark, we emphasized the importance of gathering only basic information in the first step
To ease the process, ask only for necessary information during the first steps. After they get the early feedback—e.g., rough estimates on the mortgage—and are ready to continue, you can ask for more detailed information. If you divide one big step (gathering the information) into smaller steps, your user will feel less pressure. The forms should be organized from the most to the least important. If some fields are optional, let users know.
Most third-party services integrated into online mortgages are banks. Platforms make requests to retrieve user information such as IDs, customer emails, credit records and so on. Such requests often have a fixed fee per request — typically $1 to $10. To avoid wasting money, you need to build the flow in such a way so that you make as few requests as possible — only when you are sure that a customer is ready to use your service.
Here is what we did. When using our mortgage system, users have to go through a several stages of verification process to check whether they are eligible for a mortgage. When signing up for the service, users provide their full name and date of birth. The second step involves providing rough mortgage estimates for the user. If users want to continue using a service and get a real offer, they need to finish registration process. This flow allows us to reduce the number of paid requests to third parties’ API’s, and thus waste less money.
When you integrate a bank API into your service, you need to test the payment system. To avoid using your own credit cards, the developers can yield results from test data. Many banks provide such test data to check the various outcomes of using payment systems: What to do if a card has expired, is lost or stolen; what happens when user enters invalid data and so on. You need to test as many cases as possible to avoid having to change the entire flow later.
We decided to use two different cloud services, one for the platform, and another for the database. The mortgage application runs on AWS EC2, while the database is on a separate RDS server. RDS is great for databases since (1) it uses PIOPS to achieve fast and consistent request processing, and (2) has two types of backup mechanisms (automated and user initiated), which make data administration simple.
I will summarize the main design obstacles and how to deal with them in this short part. I will not talk about general design principles, but focus on the needs of mortgage services instead.
Good design, as Dieter Rams so aptly puts it, is as little design as possible. So, to design well means to create a seamless (pardon the buzzword) flow. If we design it well enough, perhaps people will not know it is a financial service at all.
The first thing to consider is the mobile version. Since we are talking about an online-based application, many users will try to get a mortgage using their phones. The main trouble may be the data grid and how to display it on a 5-inch display. Mint App solves this problem by displaying a diagram rather than a grid. Visualization is what differentiates an Excel sheet (bad experience) from interactive data (good experience). Use it often.
What we need to inherit from traditional banking is attention to details, especially when it comes to money. All fields where users can enter amounts of money must allow decimals, because the number of cents influences the future benefits. You do not want your users to get bad mortgage conditions because your platform lacks a particular functionality.
I always recommend restricting the ability to change personal information. But there may be a situation in the future when some of it needs to be changed — if users get married and want to change their surnames, for example.
For better security, decide which information users can and cannot change and let them know when they sign up for an account that, once they create an account, they cannot change their personal information.
When running complex systems, like online mortgages, be ready to get a huge flow of how-to questions on your support channel. Your customers provide your best chance to improve something. Listen to them attentively, because they do know better.
I suggest that you set up an intranet website to test changes to the website using fake data before deploying it to live servers. You can validate the hypotheses received from the users, and by doing so regularly you will improve the UX until most of your users are happy.
Here are the main insights from our team of mortgage platform developers achieved while working on the development of an online mortgage platform. These statements summarize the main ideas in the article and are laid out as thoughts from our team members:
- Since we are going to develop an online mortgage service, let’s first identify our target end-user and create a flow to define the principal stages and activities.
- Our technical team is in another time zone. We must schedule meetings in advance and pay attention to the client’s days off.
- We have to differentiate our product from the traditional mortgage issuing process. What if we don’t ask for all the information at once, but rather divide it into several steps? Only those who are eager to get a loan will have to provide their personal information.
- Requests to bank APIs are expensive because they provide detailed information about a mortgage. Only paid customers should be able to make them. Otherwise, we’ll go bankrupt very soon.
- Let’s separate the database processing server from the website server. It makes it easier to manage the servers.
- Millennials are crazy about good design. If something can be top priority here, it’s the design.
Have an idea? Let's discuss!
Get consultancy on your project from experienced fintech product developers