(This is part one of a two-part Q&A focused on how automated underwriting systems have evolved and how they have changed the mortgage process.)
If you don’t count the statistically based mortgage scoring models of the 1980s, automated underwriting engines (AUS) have been in use in the mortgage industry since the introduction of Fannie Mae’s Desktop Underwriter (DU) in the early 1990s. Back then, many people predicted that AUS would one day replace human underwriters. Although that still has not happened, today’s AUS have evolved to become “smarter,” faster and more accurate as lenders continue to find new ways to automate the mortgage application and underwriting process.
Driving a lot of this innovation, of course, are today’s “fintech” mortgage lenders, which are deploying Web portals with advanced auto-verification, automated underwriting and e-signature/e-document capabilities. Many of the large depositories – and some regional and community lenders – have also rolled out their own, advanced online mortgage application platforms. Not only is this seen as a requisite – in this age where the home buying process begins online (many borrowers want to know if they are pre-approved for a loan immediately after filling out an application) – these portals and the related technology have also made lenders’ operations many times more efficient: Today, lenders can avoid having to manually process the high percentage of applications that would ultimately have been denied due to the borrower not meeting the underwriting requirements. What’s more, they can neatly and quickly “categorize” applicants and determine which mortgage product is the best “fit” for each borrower.
But what, exactly, is an AUS? Where does it “live” on a lender’s network? Are different AUS used at various junctures during a typical mortgage process? To get answers to these questions and more, MortgageOrb recently interviewed Kim Thompson, executive vice president of Overture Technologies, which offers a suite of solutions that help lenders, investors and insurers capture market share, scale operations and boost profits; and Linn Cook, senior communications manager at LendingQB, one of the only providers of loan origination technology that bundles AUS and product pricing capabilities natively within its loan origination system (LOS).
Q: What is an AUS?
Thompson: An AUS performs an automated analysis of a loan application and its supporting data, such as a credit report, to quickly determine whether it complies with a lender’s or investor’s lending guidelines and requirements. Some AUS also integrate loan-level pricing across a lender’s entire product set so that the best option for the consumer and its terms can be determined.
Cook: Technically speaking, an AUS is a computer system that analyzes borrower, loan and credit report data and determines whether a borrower qualifies for a loan program based on underwriting guidelines expressed as rules. Therefore, an AUS must have the capability to properly read the input data and apply it to rules that are configured in the AUS such that an automated decision can be made with a high degree of specificity and accuracy. In the context of residential mortgage lending underwriting, the ability to read input credit report data is essential.
There are two factors that differentiate an AUS from a product pricing eligibility engine (PPE): The ability to parse every data element from a credit report and utilize that data for decisioning and a rules-based conditions engine utilized to generate loan scenario specific conditions automatically.
Credit report data is an ideal AUS input because it is comprehensive (the volume of data is large), standardized (data accessibility) and credible (three independent sources of data). Credit report data allows an AUS to make much more specific decisions across many different scenarios. In addition, an AUS must be able to generate conditions/instructions that the borrower must fulfill in order to verify that the data input into the system is valid. These conditions/instructions must be specific to a borrower and loan scenario such that verification of the information provided to the AUS as it pertains to the loan program in question can satisfy the funding requirements of the lender.
Q: Where does this software typically reside, and is it always integrated with a lender’s LOS?
Thompson: Automated underwriting engines are often Web-based application program interfaces (APIs) to enable easy access. They may be accessed via a direct integration with an LOS or through an online portal that facilitates the upload of data files or direct entry of loan data.
Cook: Where an AUS resides is primarily a function of convenience and data fidelity. The borrower and loan data typically originates from an LOS, while the source of the credit report data originates from a credit report vendor (which originates from the three major credit report bureaus, Equifax, Experian and Transition). It is always a preference to reduce the number of steps it takes to get the data from the LOS and credit report vendor in to the AUS because it reduces the workload of the end user and minimizes the risk of data loss or errors. Although, there is no hard requirement that the AUS be integrated with a lender’s LOS, as evidenced by Fannie Mae’s DU and Freddie Mac’s Loan Prospector (LP) systems (which provide lenders with the ability to import data from an LOS export), but again, the ideal scenario is for the LOS to be directly connected to an AUS.
Q: Do some lenders use multiple engines, and are different engines used at different points during the mortgage process?
Thompson: A lender may access multiple AUS. Which system is used is determined by the investor and the product being originated – although multiple systems are not used on a single loan. Fannie Mae and Freddie Mac not only provide AUS capabilities to their lenders (DU and L P, respectively), but also incentivize their use. Large aggregators and investors, such as Wells Fargo (ECS) and Chase (Zippy), have their own underwriting systems for non-agency products and may require those systems to be used in order for a loan to be sold to them.
Cook: Yes – and this is what is curious about the separation of automated underwriting engines and pricing engines into different product categories. We believe this is simply a legacy of Fannie/Freddie AUS and the Countrywide CLOUT and CLUES systems.
Many lenders find it completely acceptable to run a loan through two systems – one for eligibility and another for pricing. This not only is inefficient and confusing for the end user, but also reflects a surprising lack of creativity and innovation. DU was originally introduced in 1994. More than 20 years later, the industry is still thinking in terms of a two-step process – not because it has to, but because it’s mired in old technology habits. What end users (originators) really want is a simple answer for the borrower: What is the best price I can get for a loan?
A single-decision engine should be able to answer that question in one step. The answer is either “Yes, here is the best price,” or “No, you don’t qualify for a loan.” This is a proven concept, and we’re still surprised to see that there are very few decision engines that combine AUS and pricing in a single system.
Q: Besides Fannie’s DU and Freddie’s LP, how many different third-party underwriting engines are currently being used in the industry?
Thompson: In addition to DU, LP, ECS and Zippy, other large lenders have deployed AUS technology over the years. Countrywide (CLUES), GMAC/RFC (AssetWise) and other big players developed their own proprietary systems. “Off-the-shelf” or independent, commercially available AUS were non-existent until our firm introduced its AUS in 2005.
Another type of solution – product, pricing and eligibility (PPE) engines – enable originators to submit key metrics regarding their transactions to determine how multiple investors may price and determine the eligibility of a loan. However, the ability to analyze all credit, appraisal, income and asset data (more than 3,000 data elements) in accordance with an investor’s rules separates the AUS from a PPE and other loan score carding systems.
Cook: To our knowledge, there are at least four products being marketed by vendors that meet the definition of AUS:
1. Corelogic/MDA Mindbox;
2. Overture;
3. Loan Scorecard; and
4. LendingQB UDE (Universal Decision Engine).
What is interesting to note is that the only engine that is natively built as part of an LOS is LendingQB. The other three AUS platforms mentioned above must be integrated to a third-party LOS platform. There are likely proprietary systems that have been developed, as well.
It’s important to note that one of the most difficult parts of developing an AUS is implementing the requisite credit report vendor integrations. Not only is credit report data difficult to work with, but there are still at least 75 independent credit reporting vendors in the industry. Building integrations to every credit report vendor is not required, but if an AUS is limited to accepting credit reports from a small set of vendors, then there is a risk that a borrower’s credit report is unnecessarily pulled again, creating an additional inquiry on the borrower’s credit file that negatively impacts the borrower’s FICO score.
Q: In terms of their design and functionality, are most underwriting engines “customized” by the lenders that use them, or are most used “off the shelf”?
Cook: Generally speaking, there are two approaches to AUS systems:
1. Software license model: The lender purchases a software license for an AUS and installs the system in-house. The lender is responsible for all aspects of system implementation, configuration and maintenance. The lender gains the benefit of “owning” the system and the ability to fully customize, but it must have the expertise to accomplish this – either utilizing internal resources or hiring third-party resources. There is a high cost and slower return on investment.
2. Software subscription model: The lender subscribes to the software via a hosted system, where the vendor provides both the technical functionality and the resources to implement, configure and maintain the system. The lender’s technical resource requirements are limited to the interface between the AUS and the lender’s LOS or other existing systems, which are managed via APIs and Web services.
Although the lender does not “own” the AUS, it gains flexibility and agility provided by a vendor that has expertise in its own AUS technology. The total cost of ownership of the software subscription model is much lower than the license model. However, the ability to customize may be limited by the vendor’s available resources.
It is important to note who the end user is of the AUS. Is it a large correspondent investor buying up thousands of closed loans? Or is it a small independent mortgage banker funding $25 million a month? Surprisingly, the difference is very small. Both types of lenders have a need to automate loan eligibility in order to lower operational costs and improve compliance. The hosted subscription model can be just as effective for the big lender as it is for the small one (provided that the vendor has the capabilities to deliver). It really comes down to the lender’s comfort level with a hosted model. Large companies tend to be late adopters of a hosted model, but eventually they come around because the cost savings are too big to ignore.
Q: How are AUS becoming faster and “smarter”? Is it processing speed? Ease of integration with other databases? Better algorithms?
Thompson: Speed really hasn’t been an issue for AUS because most can return decisions in less than one second. This obviously compares really favorably with the time it takes to manually review loans. But some AUS are “smarter” than others. For example, some use expanded data sets that can be accessed and analyzed through automation, including appraisal, tax transcript, bank account, data extracted from documents and, recently, trended credit data.
Cook: It’s important to understand that an AUS is really just a collection of binary and conditional rules. It’s not as if it’s trying to land the Mars Rover. If you look at a single AUS rule, you’d be surprised by its simplicity – “yes/no” or “if/then.”
The trick is how to manage hundreds and then thousands of rules at the same time and make sure there are no conflicts. The old adage of “garbage in, garbage out” absolutely applies in the case of AUS. An engine that uses five data points for a decision is going to be much less accurate and useful than an engine that uses 500 or 5,000 data points. A single credit report has between 500 and 2,000 pieces of data contained in it. If an AUS does not have the ability to parse out and utilize that data for decisioning, or can only parse out a portion of the data, then the decision is going to be less accurate.
Processing speed is not really a factor. Integration with LOS databases is more important from an accessibility and ease-of-use standpoint. In fact, I would argue that AUS became “dumber” post 2008 because mortgage lending became strictly conforming/conventional, in that only a Fannie or Freddie decision was accepted. In that scenario, a third-party AUS becomes an obsolete concept. But there are signs that the non-conforming, non-qualified mortgage space is starting to grow. More lenders are going to be offering products that rely more heavily on direct credit report decisioning, leading to greater interest in AUS versus just a pricing engine.
Q: Why is it important that the engines render decisions quickly, and what are the factors that can slow them down?
Cook: Making a quick decision is really just a convenience issue for the end user. The less time a user has to watch a static screen, the less frustrated the user is. There are many factors that can slow the process down that are out of the control of vendors: ISP issues, local hardware issues, etc. In terms of factors that have a direct impact on the vendor or system’s performance, they would most likely be related to processing bandwidth and a consideration of all of the functions that a given AUS system must perform. In our view, speed is less of an issue than accuracy and system uptime.
Q: Today, how easy is it for a lender to change its lending parameters (overlays) around specific products within an AUS’ interface “on the fly”? Is this something that most lenders can do on their own? For example, can they push this functionality out to management? Or do lenders usually need to go back to the vendor or developer to have adjustments made?
Thompson: It can be very easy, depending on what technology you use. For example, our firm has developed an AUS that could be adopted by multiple lenders, with a break-through user interface to a rules engine that enables lenders to easily author and maintain rules for their programs. Using “plain English” logical commands, users can associate data elements contained in fly-outs and matrices with nested conditions and other structures needed to capture the sometimes-complex dependencies between loan characteristics.
Cook: Whether it is easy for a lender to make changes to lending parameters (or anything else) depends on three things:
1. Does the system allow the lender to make changes on its own?
2. What is the ease of use of the system?
3. What is the skill or knowledge level of the lender’s resource to make changes to the system?
The AUS provider can only control items #1 and #2. Either a system allows a lender to make changes itself, or it must ask the vendor to do it. If a system allows the lender to make changes, how easy is it to accomplish those changes? Are the controls and features highly technical and complicated, requiring extensive training or technical skills? Or are they simplified to the extent that a layperson could learn how to make changes? Are the features that are exposed to the end user robust enough to satisfy the needs of the lender?
On the other hand, if the vendor must make changes on behalf of the lender, how responsive is the vendor to make these change requests? Is there a cost to make changes? How are disputes or errors handled?
One method is not necessarily superior to the other, but there are cost considerations to make. Large, national correspondent lenders have the resources to “own” their technology and the staff needed to maintain it. Smaller, non-bank lenders do not have this luxury and must rely on a vendor to be competent and responsive with their technology and services.
A third option, however, is for a lender, even a large correspondent, to leverage the agility of the hosted model and select a vendor that can satisfy its unique requirements; be as responsive as its own internal IT resources; enhance its marketing via partnerships to distribute its products via the vendor; and benefit from a lower total cost of ownership (TCO) of the AUS engine.
Q: How “templatized” are today’s mortgage underwriting engines? Are there basic designs that can be purchased or “borrowed” and then further developed to meet a lender’s specific needs? (Are any lenders/vendors taking templates of DU and LP and simply using those to develop their own engines, combined with their own overlays?)
Thompson: AUS are all different. No one is able to take a template from DU and LP. However, our firm provides libraries of rule sets that can be easily copied and modified, and these include Fannie and Freddie rule sets, which are easily adapted for prime jumbo lending programs. We can consistently apply lender overlays to agency programs, as well. Our library also includes non-agency rule sets that include rules to assign credit grade for subprime loans and determine other loan-level pricing adjustments.
Cook: I can only speak to our experience as a hosted vendor that builds and maintains loan program guidelines on behalf of our clients. In our business model, lenders come to us and select from a library of over 1,200 loan programs from 70 different investors and correspondents that we have already built and are actively maintaining. We offer the lender the option of leveraging these investor programs with the lender’s own overlays, or the lender can choose to have its own custom underwriting guidelines for its loan programs, which we will build and maintain in our AUS.
Obviously this is an advantage for lenders from an opportunity cost standpoint because it eliminates the following steps from the licensing model:
Training for system administrators: Lenders need to allocate resources to learn how to build and maintain rules;
Configuration and testing: Once lenders know how to build loan program eligibility rules, it takes time to build and thoroughly test the build; and
Ongoing support and maintenance: Resources need to be available to manage updates and troubleshoot issues.
In our model, lenders tell us which investors and products they want available in their systems, and then they provide us with any additional changes they want to make, such as adjusting or enhancing guidelines (overlays) to their own preferences. In effect, all of our loan programs are pre-made templates.
Q: Can today’s AUS “self update” based on new rules and regulations? Is that generally handled by the vendors via software updates, or is it mostly manual?
Thompson: Because many AUS are Web-based, they can be updated based on new rules without the lender having to reinstall software. If a change applies to all or most of our customers, Overture’s policy is to make the change and provide the update as part of its continual product development process.
Cook: No, to our knowledge it is impossible for an AUS to “self update.” Manual intervention is required. We receive bulletins and updates via email directly from the correspondents/investors and develop the changes internally. Our internal process utilizes a dual build model in which two different engineers build and test the changes against each other’s build to ensure accuracy.
Q: Typically, a first step in setting up an AUS is to upload all of a lender’s past lending data – this way, the system’s parameters are set based on past practices. How much can today’s AUS “self learn”? Is this seen as an important functionality?
Thompson: Generally speaking, the process of leveraging past lending data describes the development of scoring models rather than AUS. An AUS turns lending policies into machine-readable language for automated analysis of data, so the first step is usually establishing the lenders’ rules.
Cook: AUS technology is not “artificial intelligence,” by which the system can “self learn” or “self update.” The technology itself is actually quite simple – again, it’s a series of rules that requires extensive manual intervention in order for it to work properly. This is part of the reason why getting AUS technology to work properly is difficult. People with subject matter and technical expertise must be utilized. This is both a good and a bad thing because a human being is ever present to ensure that the machine does not go haywire, but it introduces the risk of human error, and vendors/lenders must have a process to mitigate this issue.
Q: What safeguards are typically put in place to ensure that an AUS remains properly programmed? What types of checks and balances are used to ensure system automation does not go “awry”?
Thompson: AUS must be maintained to ensure they remain in proper working order. One way to do this is to regularly re-test the system with test cases – that is, cases with known results to compare with system output.
Cook: As mentioned above, we utilize a dual build and testing model to minimize the possibility of errors.
Q: What basic things can be done to prevent AUS from rendering “false approvals” and “false denials”? How often does this happen, and how can these errors be caught quickly and rectified?
Thompson: AUS are used to automate underwriting analysis, determine risk-based loan documentation requirements and, in the case of our firm’s system, assign loan-level price adjustments based on loan data. Lenders do not approve or deny loans solely on the determinations of these systems; even the agencies refer to findings reports and the AUS decision as underwriting recommendations.
Any errors that may have occurred in the AUS findings generally relate to input data that is determined in the underwriting process to be incorrect, or imprecise. Under these conditions, the revised application data is re-submitted to the AUS for a re-determination of eligibility, documentation requirements and, in the case of our AUS, loan-level pricing adjustments.
Cook: Again, vendors and/or lenders must institute a process to ensure that human beings do not introduce errors. Beyond that, extensive testing, either in a test or production environment, must be applied with a methodology to quickly implement fixes.
In the hosted model that we use, we have the advantage of having more than one lender utilizing our builds, which increases the number of loan scenarios that can be tested. The advantage is that we can leverage the experience of one lender to improve the experience of others. When an error is detected, we can shut down the product from being utilized by all of our clients and push out a fix within a matter of minutes.