Mortgage Systems – Wooing the Processor

“I went to the bank to borrow a cup of money. They said, ‘What for?’ I said, ‘I’m going to buy some sugar.’”
-Steven Wright

Well, we’re fresh back from the road, where the topic was mortgage origination systems. There are some interesting goings on, particularly the collision of Web application and back office mortgage application processing systems.

Let’s step back a few years. The first attempts at creating Web application capability were “skunk work” initiatives driven by mortgage groups and a renegade IT employee to get something out there borrowers could use. The initial result was a basic, online form that allowed the input of enough information to compete a 1003 application. That form was printed or otherwise retrieved and manually re-input into a loan processing system (Mortgageware, easyLENDER, etc.) by a bank employee. While this was hardly grand design, it worked as long as volumes were fairly low. Ultimately, though, something more was needed, and what resulted were several systems that focused on improving Web application processing, Mortgagebot and Prime Alliance being two of the better-known examples. These systems have continued to add features and functions that help Web borrowers select different options/plans, track the progress of their loans, correspond with the lenders, and supply missing documentation.

There is an interesting “Innovators Dilemma” aspect to these systems. They were originally started as very simple, focused solutions that were used by somewhat small mortgage groups for one purpose. However, they progressed to being more sophisticated, scaleable, and marketable to new buyers. The skunk works initiative became a product.

Early users of these systems still had the traditional back-end mortgage systems that were used by the underwriters and processors for workflow, decisioning, appraisals, exception tracking, document preparation, secondary and shipping. These systems have almost all migrated to browser technology, with tight integration to Fannie Mae and Freddie Mac. And, in terms of installed users, they still dwarf newer systems.

Mortgage groups looking at systems today are seeing these different systems overlapping. Specifically, we are seeing three issues that must be collectively addressed:

• The Web application systems have begun to add functionality for the back office employees to process and close – but they are not there yet with a complete solution.
• The back office systems have added modules that support Web applications – but they are not there yet with a complete solution.
• The mortgage department employees just want to use one system that does it all.

Now, this last point makes perfect sense. Why would there be a need for two systems to handle the mortgage application process? If borrowers can use an easy, intuitive application process on the Web, why wouldn’t employees use it, too? If a processing system tracks exceptions and missing documentation, why wouldn’t it be available for both employees and borrowers to view? If the address of the title company or attorney is entered, shouldn’t it be available to both the borrower and employees? (Remember a key Gonzo design principle – if people have a choice of using one system or two systems, they’ll use one).

So, as multiple systems inevitably merge to one over the next few years, will the upstart Web application systems be able to displace their larger, more established competitors in the race to become the turnkey mortgage system? We will be looking to see how things unfold on a number of fronts:

• Who will do the best job with non-conforming products?
  The truth is that all systems will be able to support conforming residential 1-4 loans that are sold to the agencies. What will be needed is a system that can support everything else – loans that will be put in the bank’s portfolio and may require a different automated decision matrix, forms, or process – all the way from the Web application to funding and shipping.

• Who will best support sales of additional products like HELOCs?
  With an increasing focus on making the most of every sales opportunity (not to mention generating more assets with fewer employees), banks will look to loan systems to automatically recognize additional lending opportunities and alert both the borrower and the loan officer.

• Who will price systems in a way that allows for a lower unit cost as volumes grow?
  Much of the pricing for the Web application systems is based on seats and number of applications processed. As volumes grow, this can become punitive – does anybody remember the first pricing formulas for Internet banking and bill pay? Success and volumes made the cost prohibitive, and there was major market pressure to move to more fixed pricing and much lower per-transaction fees. This will happen with the Web application systems, too (hint – keep any contract term short).

• Who will get there first with soup-to-nuts functionality?

It will be interesting to watch, and there’s nothing like a good scrap to spur on the availability of better systems for banks.
-tr