With the digital mortgage revolution underway, the debate about adopting new technologies revolves around both where it will come from and what initiatives to pursue.
Mortgage lenders are forced to consider whether buying or building a product is the most effective way to go after a year of higher interest rates limiting their profits and terms and conditions that have only recently improved as those interest rates have come down.
Buying a product is usually the quicker and cheapest option in the short term, as a tool for evaluation already exists and will be more readily available for integration. However, companies developing their own technology have the benefit of customization, although it is a difficult and potentially costly task, and may have less money to spend.
But given the complexity of the mortgage business, no tool is really off the shelf. Institutions need to ensure that a product integrates with their existing suite and can be configured to meet specific needs, which may require additional expenses.
So when considering a product to buy, mortgage companies may want to create a comprehensive checklist to ensure that the product they are buying is doing the job.
“The sales pitches, sex, and crackling are the things that usually get people excited when looking at a new product. I think it is important as you go through the vendor discussion and assessment that you have a checklist of the things you are looking for – requirements or functionality – and that you are able to evaluate them, ”said Bob Orkis , Director at RKO Technical Services.
How is your digital mortgage performing?
Orkis was among the panelists at the Mortgage Bankers Association Technology Conference in Dallas on Monday.
Should a product tick the boxes, a proof of concept is critical to ensure it can keep up. This enables mortgage lenders to assess how and whether a tool is applicable to business-specific use cases. “Dummy data” can be used during testing to avoid privacy concerns.
While some vendors charge a proof of concept fee, lower upfront costs are better than millions wasted after the contract is signed, Orkis said.
And while the initial cost seems cheaper overall than building a tool, the expenses pile up annually and usually increase over time.
“If you look at the cost, look not just a year or two, but maybe five years and see what this picture looks like,” said Suzy Bashore, chief information officer, PGIM Real Estate Finance.
Developing a tool means that it is designed to handle a company’s mortgage size and integrate with other technologies already in place. But the decision to build also opens another can of worms as companies sift through time, resources, manpower, and regulations.
Some companies may choose to develop a fully comprehensive tool first before bringing it to market, which may take longer but have fewer kinks. Others will instead introduce a little faster and learn as they go. But both approaches have their weaknesses.
“Fail quickly and iterate quickly” works very well for development teams. It doesn’t work that well for the people using it in the front end and they get frustrated when it doesn’t work and you tell them our next sprint will fix that so just wait a week. “Said Aaron Perlis, Executive Vice President and Chief Technology Officer, Walker & Dunlop.
“But the big bang process doesn’t work either,” he said. “It’s about, ‘How long will it take me to build? that’s bought. ‘”
But whether built or bought, keeping business goals in mind is at the heart of technical implementation and requires more attention from business leaders and stakeholders than a technical department.