The mortgage industry is very dynam-ic with frequent volume fluctua-tions, shifting investor requirements,

and evolving regulatory and compliancestandards, not to mention ever-changingcustomer demands. In the mid-1990s, Fan-nie Mae introduced Desktop Underwriter(DU), an automated underwriting system(AUS) that significantly improved theunderwriting process (McDonald et al.1997). DU and other automated under-writing systems have created enormousefficiencies in the mortgage originationprocess, and most lenders now evaluateconforming mortgage applications usingsuch systems. AUSs have expanded thenumber of loans that lenders can make bysignificantly reducing the time and cost oforiginating a loan and allowing lenders totailor loan terms based on an individualborrower’s risk profile.

The Internet and other technologyadvances make it a necessity that mort-gage operations run efficiently andsmoothly. The Internet era is changing theexpectations of customers across all finan-cial services including the mortgage indus-try (Pafenberg 2004). Consumers wantpersonalized services and solutions fortheir individual financial situation, notoff-the-shelf, one-size-fits-all financialproducts. Mortgage lenders are required tosatisfy consumer expectations while stilladapting a technology infrastructure thathas been primarily designed to processtransactions and to meet the needs ofinvestors. The Internet provides the per-fect communications conduit for informa-

tion, decisions, transactions, and proce-dures.

Building on the success of AUSs such asDU, lenders have started looking at waysto extend the efficiencies of technology toother parts of the mortgage process. Fan-nie Mae developed Custom DU as a com-prehensive system that allows lenders tocreate and publish their own customizedunderwriting rules, investor variances,and individual loan product messages.Custom DU provides lenders with theability to leverage the power of DU fortheir other product lines, gaining operat-ing efficiencies that give them more con-trol of their pipelines. Custom DUenhances the process by allowing addi-tional rules that lenders can apply to theirmortgage production. An example is port-folio products. Custom DU allows lendersto build proprietary underwriting rules fortheir portfolio products and minimizemanual intervention required to under-write the loan. This enhanced benefit alsoapplies to different products and differentchannels as explained in the followingsections.

Custom DU also allows lenders to cus-tomize transaction output, the underwrit-ing findings report (see the sample under-writing findings report sidebar). Thefindings report includes data supportingthe underwriting decision from the sys-tem in the form of customized, transac-tion-specific messages and underwritingcalculations. The lender can choose toleverage existing DU messages or developproprietary messages and conditions.

Articles

SPRING 2008 41Copyright © 2008, Association for the Advancement of Artificial Intelligence. All rights reserved. ISSN 0738-4602

Custom DU—A Web-Based BusinessUser-Driven Automated Underwriting System

Srinivas Krovvidy, Robin Landsman, Steve Opdahl, Nancy Templeton, and Sydnor Smalera

■ Custom DU is an automated under-writing system that enables mortgagelenders to build their own business rulesthat facilitate assessing borrower eligibili-ty for different mortgage products. Devel-oped by Fannie Mae, Custom DU hasbeen used since 2004 by several lenders toautomate the underwriting of numerousmortgage products. Custom DU uses rulespecification language techniques and aweb-based, user-friendly interface forimplementing business rules that representbusiness policy. By means of the user inter-face, lenders can also customize theirunderwriting findings reports, test therules that they have defined, and publishchanges to business rules on a real-timebasis, all without any software modifica-tions. The user interface enforces structureand consistency, enabling business usersto focus on their underwriting guidelineswhen converting their business policy torules. Once lenders have created theirrules, loans are routed to the appropriaterule sets, and customized, but consistent,results are always returned to the lender.Using Custom DU, lenders can create dif-ferent rule sets for their products andassign them to different channels of thebusiness, allowing for centralized controlof underwriting policies and procedures—even if lenders have decentralized opera-tions.

AI Magazine Volume 29 Number 1 (2008) (© AAAI)

Business Problem DescriptionFannie Mae purchases residential home loans inthe secondary market and either retains them forits own portfolio or pools them together as mort-gage-backed securities (MBSs) for sale to investorswith a guarantee of timely payment of principaland interest. More than 2650 lending institu-tions—including mortgage companies, thrifts,banks, and credit unions—are approved to do busi-ness with Fannie Mae in the secondary mortgagemarket. Fannie Mae’s DU is used to determinewhether a loan complies with Fannie Mae under-writing guidelines. Fannie Mae purchases onlyconforming loans whose amounts are below aspecified maximum loan limit. In addition to theconforming loans, lenders originate loans that areeither too large to be eligible for purchase by Fan-nie Mae or may not be eligible for sale to FannieMae. While lenders are able to take advantage ofDU for some of their mortgage products, they stillhave to address a couple of challenges: first,lenders need to underwrite loans that are not soldto Fannie Mae, including the loans they hold intheir own portfolios or sell directly to otherinvestors, and second, many lenders want to serveborrowers whose needs exceed conforming guide-lines.

To address these issues, lenders had to put inplace different business processes for conformingand nonconforming loans. It also meant thatlenders could not replace some of their manualprocesses entirely. Custom DU was developed as atool to address these problems and address thebusiness and technical objectives that are discussednext.

Business ObjectivesCustom DU addresses a number of business objec-tives. First, it creates a single process for all loans.Lenders prefer to underwrite all of their businesswith one automated underwriting system thatthey can manage. It is ideal to have a system thatallows them to build their own customized rulesets based on their risk factors and operationalchallenges. These rule sets are typically managedand maintained by business users. Custom DUhelps to support further their underwriting needs.

It builds on their current investment and auto-mated underwriting process and expands it to pro-vide consistent loan recommendations and loaneligibility screening for all the products they origi-nate. Custom DU provides seamless integration byleveraging the underwriting transaction, the loanfile, and key components of the Desktop Under-writer recommendation.

Second, Custom DU originates more loans thatmeet investor requirements. Custom DU allowslenders to manage eligibility criteria for variousinvestors without manual workarounds. CustomDU also provides a centralized way to change rules,resulting in consistent communication to all per-sonnel.

Third, it reduces operational costs and increasesefficiencies. By streamlining the entire loan origi-nation and closing process, lenders can achievegreater efficiencies and potentially pass savings tocustomers. Fewer mistakes and less redundantworkflows turn into quicker closings and animproved borrower experience. In fact, accordingto a recent mortgage benchmarking study, lendersthat deploy automated underwriting at the pointof sale recognize the largest per loan cost savingsand achieve the greatest per person loan capacity.

Fourth, Custom DU targets specific niche mar-kets or product types. Market changes demand thatunderwriting systems do the same. It is importantthat lenders can create products that are channel-specific or location-specific without additionalpaperwork or manual workarounds. Specifically,they need to be able to develop, automate, andimplement complex niche products rapidly and ontheir own schedule. Custom DU allows them tocreate different sets of rules for different productswithout any programming assistance.

Finally, it ensures consistent communications.Automated underwriting provides a consistentapproach for every loan. It also allows for central-ized control of underwriting policies and proce-dures—even if lenders have decentralized opera-tions. In addition Custom DU provides lenderswith a capability to create customized underwrit-ing findings with targeted messaging for pricing,processing, closing, postclosing, and vendor man-agement.

Articles

42 AI MAGAZINE

Sample Underwriting FindingsUnderwriting findings is the report generated after anunderwriting transaction. The findings include severalmessages generated by the underwriting rules and resultsfrom several underwriting calculations, along with someother data. The messages can be grouped under differentsections and are completely customizable by the admin-istrative users. The following list includes some of thecustomization capabilities provided by Custom DU:

Findings report and title

Findings section and header

Labels for recommendations from the system

Messages from DU findings and how they are mapped inCustom DU findings

Technical ObjectivesBased on the business objectives just discussed, thedevelopment team identified several overall tech-nical objectives that directed the system architec-ture and design and the technology chosen forimplementation. They determined that the systemshould have an administrative interface and atransaction interface with the following capabili-ties.

Administrative Interface. The system must allowlender product managers (or other nontechnicalusers with business expertise) to build and main-tain a set of underwriting rules. It is critical that theuser interface be easy to learn how to use and easyto remember how to use. The system must providethe ability for lenders to create new rules, changeexisting rules, and make changes effective imme-diately, or at a specified date and time. The systemmust provide a capability for lenders to assign dif-ferent underwriting rule sets to different products.Appropriate rule sets must be chosen automatical-ly based on the characteristics of the loan and theproduct under consideration during the transac-tion phase. The system must provide a capabilityfor the administrative users to customize theirunderwriting findings including their format andheadings. Changes to their findings setup must beeffective immediately for future underwritingtransactions. Finally, the system must provide atest interface so that users can test rules beforerolling them out.

Transaction Interface. The system must provide aseamless integration for customers that are alreadyintegrated with DU. The system must deliver a fast,consistent, high-quality underwriting experienceto customers by underwriting their custom ruleswithout significantly increasing the underwritingtransaction time. The system must provide a seam-less process for end users. They merely need to sub-mit a loan to underwrite and receive results.

Additional Objectives. The system must be easilymaintainable, and system maintenance should nothave any impact on the lenders’ need to makechanges to their underwriting rules at will. The sys-tem must be designed in a manner that supportscomplete backward compatibility when newenhancements are made to the system. Fannie Maewill handle all storage and processing require-ments, and customers only need access to a PC anda browser. All processing (including writing rulesand messages, testing, and so on) must be done 24hours a day, 7 days a week, with no downtime formigrations. Minimal Fannie Mae technical supportmust be needed to answer/troubleshoot customerquestions. End users must essentially be self-sup-porting from a technical perspective.

Based on these objectives, three core compo-nents were identified in the design of the system.

First, it should be a web-based GUI that can be usedfor editing and testing underwriting rules, cus-tomizing findings, and associating rule sets withappropriate products. Second, it should be a repos-itory to store and retrieve lender-defined under-writing rules and data defined to associate lenderrule sets with their products. Finally, it should havea rule engine that can accept loan data, identifythe appropriate rule set, and dynamically load andexecute the underwriting rules and generate cus-tomized findings.

Based on the successful use of business rules inautomated underwriting systems, it was an easydecision early in the design that the underwritingrules in Custom DU must map to business rules.

Traditionally, business rule applications in busi-

Articles

SPRING 2008 43

Business Rules at Fannie Mae

Fannie Mae has a long tradition of developing rule-based systems, and the design of Custom DU bene-fited from various ideas successfully implementedin those systems. Fannie Mae developed anddeployed a knowledge-acquisition and rule-man-agement assistant (KARMA) and business rule serv-er to allow policy changes to be implementedquickly and to provide business users with directownership and management of Fannie Mae’s poli-cies in a way that seamlessly integrates policy intothe software applications (Sobieski et al. 1996).KARMA also introduced several business rule man-agement concepts during the life cycle of businessrules. As mentioned earlier, Fannie Mae developedand deployed Desktop Underwriter (McDonald etal. 1997), an automated underwriting system thatapplies heuristics and statistics to the underwritingproblem. DU continues to be the leader amongautomated underwriting systems with periodicenhancements since its initial rollout. Building onthe successes from KARMA and DU, Fannie Maedeveloped a formal business rule specification lan-guage (Krovvidy and McClintock 2000) that couldbe used by business users to specify their businessrules in an unambiguous manner. More recently,Krovvidy and Bhogaraju (2005) discuss the conceptof modeling rules as data and how the conceptallows shipping and sharing of data and rules acrossapplications, eventually leading to interoperabilityof business rules. They also mention a case study onhow interoperable business rules can be used in themortgage industry.

ness to business (B2B) or business to customer(B2C) systems are designed such that they canreceive data and execute a static set of businessrules using the data shipped from the sender. Themain advantage of using business rules for thesesystems is the efficient and consistent applicationof business rules. It is important to note that alltransactions in these applications always executethe same set of business rules. For a system likeCustom DU, however, the business rule set to beexecuted can be different for each transaction, asthe appropriate rule set is based not only on thelender initiating the transaction, but also on theproduct that is being underwritten. In addition,

the business rule set can be modified in real timeand the updated rule set must be effective for sub-sequent transactions. These requirements suggestthat business rules should be treated as data andthat each transaction should include not only thecase data but also the business rule set as its input.

Application DescriptionCustomers interact with Custom DU in two differ-ent modes. Figure 1 depicts the administrativepath and transaction path in a Custom DU session.The administrative path is used to create under-writing rules and to customize how and when the

Articles

44 AI MAGAZINE

Is it a Custom DUCase?

DesktopUnderwriter

DU

Custom DUCustom DULender Data

Transaction PathAdministration Path

Case Data forUnderwriting

DU FindingsYes

No

Lender Data

Custom DU Findings

Retrieve Lender DataLender DataRepository

PolicyAdministrator

Loan Officers, Underwriters

Figure 1. High-Level System Diagram.

rules need to be invoked along with an ability tocustomize the findings from the underwritingengine. During the transaction path, the case isfirst underwritten by DU. If it meets the lender-defined criteria to be underwritten by Custom DU,appropriate lender data (including the relevantrule set, findings from DU, and case data) are sentto Custom DU. After Custom DU completes under-writing using the lender rule set, the findings arereturned to the customer.

The administrative interface allows policyadministrators to create and update rules and mes-sages, test rules and messages, create and updateactivation rules that determine how rule sets areassociated with products, and customize findings.

Figure 2 is a reproduction of a screen shot fromthe administrative interface of Custom DU. Theleft panel provides links to various administrativefeatures of the application. In the context of Cus-tom DU, the guideline and rule set are used inter-changeably. As shown in figure 2, the guidelinemanager lists different rule sets that belong to theuser.

A guideline consists of several rules. Each rule ina guideline can be edited separately. Each rule con-sists of multiple conditions and actions, and as

shown in figures 3 and 4, these conditions andactions can be created through drop-down boxes.For example, the selection of a data field for creat-ing a condition determines the choice of operator,and this in turn determines the data fields that canbe compared to create the condition.

Some of the important design decisions madeduring the development of Custom DU to supportthe following core principles are discussed next.

Rules as Data. An abstract rule language was cre-ated and layered over an existing commerciallyavailable system. ILOG JRules was selected due toits ability to support dynamic rule loading andXML binding, as well as the dynamic view of rulesand data that it incorporates. Custom DU also usesthe open interfaces provided by the ILOG JRulesproduct to generate executable code from businessrules. As shown in figure 5, the business rulesstored in the rule repository are in XML format,and these rules are translated into low-level JRulesat the execution level. In addition, sequencing ofrules and association of data are predefined, andonly a small list of predefined actions is provided.A custom GUI supports the creation and organiza-tion of business rules and related metadata in anabstract XML format, and this metadata is persist-

Articles

SPRING 2008 45

Figure 2. Custom DU Administrative Interface.

ed to a data repository. A code generator is auto-matically invoked to generate executable businessrules when needed for testing or loan transactionprocessing.

Designed for Business Users. The Custom DUGUI must enable users to express their mortgageunderwriting policy rules as business rules. Usersdo not need to know about the syntax of the lan-guage. An abstract data model was created and lay-ered over existing data. Users do not need to knowthe underlying physical data model. The dataavailable for use in the rules is strictly limited tothe abstract data model. Users are able to cus-tomize their own (enumerated list) variables anduse them when building rules. The systemincludes numerous predefined calculations avail-able for building rules.

Designed for Multiple Lenders. The system isdesigned for scalability and can support severallenders concurrently. The rules are stored in a cen-tral location and can be dynamically loaded ondemand at run time.

Table 1 shows a high-level view of how lenderscan create different rule sets for their products andassign them to different channels of the business.These channels can be based on region or line ofbusiness. Each row represents the underwritingrule set that needs to be executed based on theproduct, the channel, and the date of the transac-tion.

Development ProcessOnce the project team determined that there wereno off-the-shelf solutions that completelyaddressed the project needs, the developmentprocess began with an extensive analysis effort.Technical and business analysts worked togetherto identify the desired functionality, capture bothbusiness and performance requirements, anddesign the application flow and user interface.The analysis process was structured and method-

Articles

46 AI MAGAZINE

Figure 3. Custom DU Rule Editor.

Figure 4. Adding and Creating Conditions.

Lender Product Channel Rule Set Effective Date

1 30 YR FRM, 20 YR FRM, 7 YR ARM Wholesale—Dallas Rule Set A 2/1/2007

1 30 YR FRM, 20 YR FRM Retail—NY Rule Set B 8/15/2004

2 7 YR ARM All—Chicago Rule Set C 4/1/2007

2 Default Wholesale—NY Rule Set D 1/21/2005

Table 1. Rule-Set Assignment.

ical with much work occurring prior to the start ofany development tasks. Once the analysis phasewas well under way and the core requirementswere determined, the development team identi-fied and prototyped some of the more criticalalgorithmic and risk aspects of the application.These prototypes served as both a proof of con-cept and a tool for eliciting input from businesspartners and other stakeholders. The decision todevote significant time to up-front analysis andprototyping resulted in minimal misunderstand-ings and little rework during the developmentphase of the pilot project.

Architecture, Design, and DevelopmentThe project’s senior architect put together the over-all architecture document for the application andworked with the development teams in developingcore architecture principles and interfaces betweenthe different components of the application.Detailed high-level and low-level design docu-ments were created and carefully reviewed for allthe major components of the application. By care-ful interface design, a majority of the componentscould be developed in parallel. The project teamduring the initial development effort consisted offour to six developers and two to three analysts,depending on the tasks that were being performed

at a particular time. In addition, a quality assur-ance team was involved in testing the application.The first pilot version was completed in less than12 months after the decision to build the productin house was made.

When the application was in pilot, the FannieMae business team worked closely with pilot cus-tomers to understand their experiences with theapplication. Feedback was solicited and reviewedin order to determine those enhancements thatwould be needed to make the application attrac-tive to a wider audience. Custom DU was rolledinto full production to interested lenders in 2004.Since the application was designed to be scalableand flexible, the pilot version of the applicationwas seamlessly enhanced to become the produc-tion application without any disruption to thepilot customers. Since then there have been multi-ple releases with numerous functional and per-formance enhancements with virtually no cus-tomer impact.

In addition to the typical hurdles, such asstaffing and budget concerns, the project alsoencountered some more atypical difficulties duringthe initial development of the application. Theproject team included a group of individuals whowere brought together because of their skill sets.These individuals reported to several managers

Articles

SPRING 2008 47

High-Level Rule(XML)

Low-Level Rule(JRules)

Transform

Figure 5. Custom DU Rule Translation.

scattered throughout the organization. The projectteam worked at multiple locations and had notpreviously worked together, a situation that couldhave caused project delays. Team members com-pensated for this by holding regularly scheduledmeetings and by documenting and reviewing andrevising all relevant information, including usecases and sample screens. In addition, the teammembers were accustomed to using differentdevelopment methodologies including XP, Agile,and waterfall. The project team used this to theiradvantage. Within the overall project, the devel-opment methodology used for a component wasbased on the project timeline needs, includingdependencies on other components. Thisapproach gave developers the opportunity to learnmethodologies that they would not have beenexposed to otherwise.

One of the key challenges was developing a sys-tem for external use and capturing requirementsfrom a small group of potential users. Since manyof these lender customers had never managed arule-based system, it was a challenge to create aninterface that accurately represented the way theyconceptualized their products. During the require-ments-gathering phase, lenders commented onscreen mock-ups, and their initial feedback was tomanage the rules with a single rule set that con-tained the underwriting rules for multiple prod-ucts. Later, when they saw the prototype thatdepicted this approach, they realized this wouldnot work for their environment, where the under-writing rules for many products change on a regu-lar basis.

The production version of the tool allowed usersto create separate rule sets for each product, so theycould make changes to the products independentof one another. Lenders were happy to trade off thechallenge of having the same rules replicatedacross multiple products for the flexibility to makechanges for dynamic products in an easy and effi-cient manner. An additional challenge was creat-ing a user-friendly interface for building rules thatallowed business users to build rules as if they wereexperienced rule writers. The project team was ableto leverage their experiences with previous systemssuch as KARMA (Sobieski et al. 1996) during thisphase.

The application was designed from the outset toaccommodate new functionality without affectingexisting customers. One of the most challengingobstacles was the ability to thoroughly test theapplication prior to rollout, since exactly how eachof the lenders will use the provided functionalitycannot always be anticipated. This risk was miti-gated by including testing partners from the onsetof all development initiatives and by including sig-nificant testing time in the project plans.

The ever-changing nature of the mortgage

industry forced an iterative approach to develop-ment. It was understood from the beginning thatthe system needed to be built so that it could bechanged easily and quickly. Creating multiple sys-tem components was one way to address therequirement for system flexibility. The team alsolearned that having the right set of skills wasmore important than having a large team andthat up-front analysis was important in reducingthe amount of rework and miscommunication.

Thorough and complete documentation alsoimproved the development process and allowedthe staff to provide a superior level of customersupport. Additionally, the development team hadexperience from an earlier effort (Krovvidy andMcClintock 2000) in translating business policy toformalized business rules. This experience wasshared with business partners and includedemphasizing the significant up-front analysisrequired before the tool could be used to buildbusiness rules. This in turn helped business part-ners when they trained lenders in creating andmaintaining their underwriting rules.

Finally, the Fannie Mae business team worksclosely with lenders once they choose to use Cus-tom DU by providing them with extensive train-ing and helps them by sharing best practices onextracting business rules from business policy. Typ-ically, it is more difficult to train users on theabstract concepts related to business rules than it isto train them on how to use the tool.

MaintenanceFannie Mae has a robust, three-tier product-sup-port environment that can respond quickly andaccurately to customer problems. The first tier isthe DO/DU Hotline, which resolves customerproblems directly or escalates them to a produc-tion support team. All problems that cannot beanswered by the production support team are for-warded to the business team or the developmentteam for more extensive analysis. These individu-als are contacted when production issues arise. Inaddition, the system has a built-in troubleshootingcapability that customers can use to debug theircases. This capability provides them with moredetailed trace and debugging information aboutthe rules.

As Custom DU production volume continues toincrease, Fannie Mae continues to work proactive-ly to detect and address issues as early as possible.The Custom DU business team regularly solicitsfeedback and enhancement requirements fromlenders to ensure that the system continues tomeet their needs. The development team regularlymonitors performance and storage requirementsand proactively implements software upgrades andperformance enhancements on an ongoing basis.

Articles

48 AI MAGAZINE

Soon after Custom DU was rolled out for gener-al use in 2004, the quick adoption of the tool byvarious lenders necessitated the implementation ofmore efficient indexing and compression tech-niques for storing and retrieving lender data. Theseenhancements were rolled out in 2005. Similarly,upgrades were made in 2006 to the underlyingrules product and third-party products used in theapplication. These changes were made in additionto several functional enhancements made to thesystem since 2004.

Insights GainedWe made seveal key observations. First, a simpli-fied rule language is sufficient for most underwrit-ing, and inadequacies can be rectified through pre-defined calculations or other mechanisms. Second,it is important to capture, model, and provide sup-port for metadata outside the underwriting guide-lines in order to prevent lenders from embeddingit in their underwriting rules. Third, the addition-al layers of rule and data abstraction providedlenders with considerable stability to their under-writing rules, even when significant architecturalchanges were made to the system and when sig-nificant data changes were made to their under-writing data points.

Initially, the business users wrote simple ruleswith low complexity. Once they became proficientat rule building, they wanted much more complexand powerful capabilities. It is an ongoing chal-lenge to balance the need for rule-building powerwith the amount of technical knowledge a userneeds to be able to use the system.

Lessons LearnedApproaches with no sequencing or prioritization ofrules were tried but were insufficient for the prob-lem domain. Implicit sequencing of the rules basedon typical underwriting use proved to be remark-ably well-received. Previous prototypes using lessdynamic bindings to rules and data clearly indi-cated that an approach that used standard tech-niques of compilation, testing, and release dateswould be unattractive to customers. The ability tocreate, edit, test, and deploy rules at any timeagainst existing customer underwriting trafficthrough DU required an architecture that can treatall aspects of the system as data—including sched-uling information, routing information, under-writing rules, and presentation styles, as well as tra-ditional underwriting data points such as creditand loan information. There is a need to model theuser interface based on how end users organize andsegment their business. What makes sense from arules perspective does not always make sense tobusiness users.

Application Use and PayoffIn 1995 it cost about $4,000 to originate a loan andtook 20 days to get approval, and the process reliedheavily on paper, courier, and fax. After AUSsentered the market, the underwriting space waschanged forever. For example, in 2003 the esti-mated cost to originate a loan dropped to $1,500or less, and approval took an average of 20 minutesthrough the use of Fannie Mae’s DU. Now FannieMae has again pushed the envelope and intro-duced Custom DU, through which lenders can cus-tomize DU with their own rules. The following is asample set of lenders benefiting from Custom DU.

Garritano (2005) discusses how users like a largeDallas-based mortgage company are able to embedCustom DU into their loan-origination system anddirectly pass information back and forth seamless-ly. With DU and Custom DU, this company hasbeen able to take the automated underwriting deci-sion directly to the point of sale because its mes-saging is so clear and comprehensive. According tothis article, this company felt that Custom DU isone of the best systems built by Fannie Mae. Itfound that Custom DU was easy to learn and thatone didn’t have to have a lot of programmingknowledge to build the rules. The rules were alsoeasy to test, and the system was easy to roll out.Custom DU not only let the company customizethe rules to meet its needs, but also provided itwith the ability to move with the industry.

Kersnar (2004) highlights the following provenbenefits lenders realize in using Custom DU:enhanced pull-through rates—enhanced as muchas 20 percent—and an aggressive return on theirinvestment within 12 to 18 months of fully imple-menting Custom DU. Another benefit is theimproved relationship Custom DU creates forlenders with correspondents and brokers.

In April 2006, a large mortgage bank announcedhow it used Custom DU to leverage its custombusiness rules on additional products other thanstandard Fannie Mae loans. In July 2006, a majormortgage wholesale company announced howintegrating with DU/Custom DU would enablebrokers to get a preapproval prior to loan submis-sion, giving its clients a decision in minutes, notdays. Custom DU is also seamlessly integrated withsome of the leading mortgage vendor technologiesto make the service more readily available to themarket.

A major mortgage bank successfully deployedCustom DU to provide easy and consistent under-writing responses. The system was used to evaluateeach applicant for income, employment, credithistory, assets, liabilities, the loan-to value/com-bined loan-to value, and other variables. Theseparameters were then compared to the require-ments contained in the bank’s underwriting guide-lines and product summaries to determine

Articles

SPRING 2008 49

whether the applicant was eligible for approval.This application provided several benefits to thecorrespondents of this bank, such as reducedunderwriting turnaround time, increased produc-tion capacity, relief from certain reps and warrants(representations and warranties), and the ability todeliver loans with larger amounts, provided theywere underwritten by Custom DU.

Prior to the development of Custom DU, Desk-top Underwriter was used to obtain a credit evalu-ation from a borrower’s application. However, anapprove decision from DU would not automatical-ly lead to a loan commitment, because the rulesapplied by Desktop Underwriter can differ fromthose applied by the bank’s underwriting guide-lines and product summaries with regard to itemssuch as maximum debt-to-income ratios andrequired reserves. In addition, the streamlined doc-umentation offered by DU findings was notallowed on some of the bank’s nonconformingproducts. Custom DU eliminated these inefficien-cies.

The success of the Custom DU application

Articles

50 AI MAGAZINE

2004 - 2006

Total Monthly Custom DU Loan Volumes

Loan

Vol

ume

Figure 6. Growth in Custom DU Volumes since 2004.

Figure 7. A Sample Custom DU Findings Report

resulted in a continuous increase in the volume oftransactions since 2004. Figure 6 depicts thegrowth in Custom DU volumes. Figure 7 depicts asample Custom DU findings report.

AcknowledgementsThe success of Custom DU is the result of manyindividuals. We thank Celina Binns, Terri Davis,and Philson Lescott for their support, guidance,and thoughtful leadership of the project. Specialthanks to Joe Hallett, Lisa Strachan, and ShannonLloyd for their leadership during the project.Thanks to Milind Naikwadi and Linda Wilson fortheir significant contributions to the project. Addi-tional thanks to all the developers including CathyDoman, Kevin Bates, and Santanu Dutt and to theimplementation team including Shane Hartzlerand Colin Deaso. Special thanks to Crystal Fergu-son Brown for help in testing. The project and thearticle benefited from the work of many other indi-viduals from other teams, and the authors appreci-ate all their help. This article was developed byFannie Mae. Desktop Underwriter and DU are reg-istered trademarks of Fannie Mae. Custom DU is atrademark of Fannie Mae.

ReferencesGarritano, A. 2005. Anchor’s Way. Mortgage Technology(April).

Kersnar, S. 2004. The Evolution of DU. Mortgage Technol-ogy (October).

Krovvidy, S., and Bhogaraju, P. 2005. Interoperability andRule Languages. Paper presented at the W3C Workshopon Rule Languages for Interoperability, Washington, DC,27–28 April.

Krovvidy, S., and McClintock, C. 2000. Integrating Busi-ness Rules and Objects. Paper presented at the BusinessRules Forum, Atlanta, GA.

McDonald, D. W.; Pepe, C. O.; Bowers, H. M.; and Dom-broski, E. J. 1997. Desktop Underwriter: Fannie Mae’sAutomated Mortgage Underwriting Expert System. InProceedings of the Ninth Annual Conference on InnovativeApplications of Artificial Intelligence, 875–882. Menlo Park,CA: AAAI Press.

Pafenberg, F. 2004. The Single-Family Mortgage Industryin the Internet Era: OFHEO Research Paper. Washington,DC: Office of Federal Housing Enterprise Oversight.

Sobieski, J.; Krovvidy, S.; McClintock, C.; and Thorpe, M.1996. KARMA: Knowledge Acquisition and Rule Manage-ment Assistant. In Proceedings of the Ninth Annual Confer-ence on Innovative Applications of Artificial Intelligence,1536–1543. Menlo Park, CA: AAAI Press.

Srinivas Krovvidy is a senior manager with Fannie Maewhere he has been involved in managing design, devel-opment, and implementation of knowledge-based sys-tems and knowledge acquisitions tools. He has been asso-ciated with knowledge-based systems development for

about 18 years and is also involvedin enterprise architecture and infra-structure development efforts. Hisresearch interests include knowledgeacquisition, machine learning, andbusiness rules representation. Hereceived his BE from Osmania Uni-versity, MTech from Indian Institute

of Technology, and a Ph.D. in computer science and engi-neering from the University of Cincinnati. He is a mem-ber of ACM and AAAI.

Robin Landsman has worked in theIT industry for approximately 20 years.She joined Fannie Mae as an analyst in2000. She has a BA in psychology fromthe State University of New York atStony Brook and an MBA from BaruchCollege.

Steve Opdahl is a senior developerwith Fannie Mae where he has workedon Custom DU since its inception. Hehas 20 years of work experience acrossa broad spectrum of technical areasspanning software development, sys-tem administration, data communica-tions, and real-time systems. He holds

a B.A. and M.S. in computer science.

Nancy Templeton is a senior productmanager at Fannie Mae. She has 20years experience developing innova-tive software products and risk-man-agement solutions. Templeton wasthe business lead on the Custom DUproject and contributed to the conceptdevelopment, business requirements,market test, and rollout. She received

a BA in molecular biology and an MBA from the Univer-sity of Colorado and can be reached at Nancy_Temple-ton@fanniemae.com.

Sydnor Smalera is a senior consultantat Fannie Mae, providing analyticalsupport to knowledge-based systemsfor the past 7 years. She has beeninvolved in software development forthe past 12 years. She has a BS in psy-chology from Randolph-Macon Col-lege.

Articles

SPRING 2008 51