Tuesday, September 6, 2016

UCD, ULAD, and HMDA. Oh My!

If you are a provider of mortgage or settlement services, you might have heard a lot of acronyms being thrown around recently. In addition to QM and TRID, which have been a source of anxiety over the past several years, now there are new terms such as UCD, ULAD, and HDMA that are causing consternation. Oh my, indeed.

What do all these new acronyms have in common? They are all new and upcoming data reporting requirements. Fannie Mae, Freddie Mac, and the Consumer Financial Protection Bureau want improved information about mortgage loans that are being made – and for the most part, they want it in MISMO data formats that are similar, but not exactly alike.

The first reporting requirement on the list is the Uniform Closing Dataset, or UCD. Beginning in Q3 of 2017, Fannie Mae and Freddie Mac (GSEs, or government sponsored enterprises) will begin requiring a data set that provides detailed information on the contents of Closing Disclosure documents for loans they acquire. The UCD specification requires the use of the MISMO 3.3 data standards.

Muddying the waters a little bit, MISMO has since released a newer version of its data standards: MISMO 3.4. Another upcoming GSE data specification will rely on this newer set of standards. The Uniform Loan Application Dataset, or ULAD, describes the information on the soon-to-be-available redesign of the Uniform Residential Loan Application (URLA) form.

Finally, the Consumer Financial Protection Bureau (CFPB) is also piggybacking on the newer MISMO 3.4 standards for the revised Home Mortgage Disclosure Act (HMDA) reporting requirements. The CFPB will begin phasing in the new HMDA rule in 2018, and the required data submission directly corresponds to terminology and data points from MISMO 3.4.

With all these scary-sounding acronyms and varying requirements for MISMO, how can an organization prepare for the future and proceed with the minimum amount of pain and cost? Fortunately, there are a few facts that can help alleviate some fears.

First, even though these required datasets use different versions of the MISMO standards, the mechanics of how MISMO files are laid out is mostly the same. Just as the English language has evolved over time to add new words and phrases, MISMO standards also evolve to capture additional terms and meanings over time. Usually, loan information that was supported in earlier versions of MISMO will still look the same in newer versions.

There are other ways that MISMO is similar to a spoken language. When someone learns a new language, there is effort required to obtain a minimal level of competence. With enough practice, a speaker can effortlessly exchange ideas. That is fluency. MISMO is similar in that once it is implemented the first time, adding support for future requirements is relatively easy.

Finally, and thankfully, UCD, HMDA, and ULAD are not coming all at once. They will be phased in over the next several years. With one year to go until the first of these, UCD, becomes a mandate, there is time to get a grasp on MISMO and be successful. Lions, tigers, and bears, these data specifications are not.

Monday, August 5, 2013

Brace for Impact: GSEs Announce Uniform Closing Dataset (UCD) for New Closing Disclosure

For over a year, title agents and loan originators have been closely following efforts by the Consumer Financial Protection Bureau (CFPB) to create new rules and disclosure forms for real estate settlements. Under the proposed rule, expected to be finalized this fall, a new Closing Disclosure form will replace the existing HUD1 settlement statement, while another new form, the Loan Estimate, will replace the Truth in Lending (TIL) and Good Faith Estimate (GFE) forms.

The new Closing Disclosure, in particular, will require significant changes to software and office procedures. Gone are the familiar line numbers of previous HUD1 forms - replaced by a new format that alphabetically organizes loan costs into new groups, such as "Origination Charges", "Services Borrower Did Not Shop For", and "Services Borrower Did Shop For". (This of course, assumes that the final disclosures will resemble the earlier drafts - and all indications are that they will.)

New rules also require that the Closing Disclosure be provided to the consumer three days before closing, with any significant changes to costs triggering a new waiting period. This rule will require loan originators and settlement agents to share information much more closely in order to be compliant.

Although the draft CFPB disclosure rules put ultimate responsibility for the accuracy of the Closing Disclosure on the lender, most industry insiders fully expect title and settlement agents to maintain their role in preparing this statement. In order to stay compliant with the three-day rule, lenders and settlement providers, each of whom provide some of the cost information for settlement statements, will need to make sure their software systems can exchange closing costs electronically.

In an effort to standardize the underlying data required by the new disclosure, Fannie Mae and Freddie Mac have jointly created a new standard dataset called the Uniform Closing Dataset, or UCD. This dataset will be a new component in the Uniform Mortgage Data Program (UMDP), which is an ongoing endeavor by the GSEs, under the direction of the Federal Housing Finance Agency (FHFA), to improve the quality and accuracy of loan data.

Similar to other UMDP standards, such as ULDD (Uniform Loan Delivery Dataset) and UAD (Uniform Appraisal Dataset) which are already widely used, the UCD will be based upon XML standards produced by the Mortgage Industry Standards Maintenance Organization (MISMO).

Although full details on the UCD will not be released until after the CFPB releases its final disclosure rules later this year, this is a very significant development for several reasons and offers organizations and vendors a real opportunity to reduce implementation costs and risks associated with the new disclosures.

For software providers who must update systems to support the new Closing Disclosure, the UCD will take much of the guesswork out of determining which pieces of data go into which spots on the form. The MISMO Origination Workgroup, with feedback from the CFPB, has documented how to populate the new disclosures using the MISMO data points which underlie the upcoming UCD.

In addition to providing a blueprint to populating the disclosures, the UCD will also serve as a standard data format for settlement software and loan origination systems (LOS) to exchange information about loan costs. By embracing these standards, software providers have the opportunity not only to comply more easily with the CFPB's three-day rule, but also to increase the pool of trading partners with which they can easily integrate.

The most important thing to note about the UCD is that, like the ULDD and UAD before it, the dataset is likely to become a required format for all loans acquired by the GSEs. This is not something settlement service providers are going to be able to ignore.

With these new requirements coming, title agents and lenders should take time now to verify that their respective systems can accept electronic information from the other. Lenders, in particular, will likely demand this capability from settlement providers in order to ensure compliance with the three-day rule. Rekeying of data from one system to the other is not going to be an acceptable practice under the new rules.

Rather than waiting and "bracing for impact" later on, settlement providers and lenders would be well-advised to stay informed as more information comes out about the UCD and incorporate it into their plans to implement the new disclosures. Hopefully, adhering to and using the guidance inherent in the UCD will make the transition easier and less costly rather than simply being an added burden.

Sunday, July 28, 2013

To Minimize Integration Costs, Make Your Application a "Native Speaker" of MISMO

If you've ever been to a foreign country where the predominant language is unfamiliar to you and English is not widely understood, you probably experienced some frustration in trying to communicate. Doing something that is ordinarily simple, such as asking for directions, becomes a challenge when you must rely on your own limited knowledge of the foreign language to formulate your question, and then struggle to understand a response.

Ideally, you would like to find a local who also speaks English in order to have an easier time, but even the task of trying to locate that person takes time and effort. Imagine how much easier and enjoyable your trip would be if you could speak the foreign language fluently? No one speaks a given language more easily that a true native speaker - someone who learned the language during their formative years.

Software applications often struggle with similar translation issues when they must communicate with other systems. Commonly used integration methodologies such as REST or SOAP web services only address the mechanics of communicating, not the semantics. This would be akin to foreign speakers agreeing to communicate by forming distinct sounds with their vocal cords, lips, and tongues, but saying nothing about words and phrases.

For two applications to communicate, they must also agree upon semantics. One application must be able to send data (formulate a sentence) or request some data (ask a question) from the other application using terms (words) understood by both parties. If the two applications use different terminology or have different expectations on how to communicate, then extra effort development effort is typically required to build some sort of translator or adaptor layer. This adds to both the cost and the length of time required to make two applications talk to each other.

Ideally both applications would have been designed from the beginning to speak a common language, meaning that the underlying data model, service calls, and protocols for "talking" would be similar and no translation effort would be needed. The two applications could just converse - as easily as you might have a conversation with a neighbor.

For the mortgage industry and affiliated service providers, such as title insurance underwriters and appraisers, this common language exists in the form of the MISMO reference model. MISMO defines a common set of industry terms (words) as well as XML standards for common data exchange scenarios (questions and sentences).

An application that is a true "native speaker" of MISMO stores its data internally in a form similar to the MISMO reference model. In other words, the table names and relational structure mirrors the XML structure of MISMO. The column names are also aligned with common terminology from what MISMO calls its Logical Data Dictionary.

When coupled with a service layer that uses MISMO standards for forming the "sentences" of requests and responses to other systems, an application is ready for easy, low-cost integrations with other compliant systems. No translator required.

Since MISMO is rapidly become the de facto standard for mortgage and real estate transaction data, building new applications as "native speakers" will enable them to interact and adapt both now and in the future.

Tuesday, June 25, 2013

Don't Call it Title Insurance - Call it a Warranty

I recently read about yet another case of title insurance claim payouts being unfairly compared to other types of insurance, such as property and casualty. During a recent congressional house hearing on Qualified Mortgage, the president of the Center for Responsible Lending made a comment lamenting that, for every dollar spent on title insurance, 75 cents goes to commission and 10 cents to claims, while other forms of insurance pay 80 to 90 cents on the dollar for claims. These statistics are very misleading, and labeling title policies as "insurance" rather than a "warranty" is a big reason behind the misinformation.

When a lender or an individual buys a title policy, what they are really paying for is the effort that goes into ensuring that a piece of real estate has clean title, rather than insuring against title issues that might crop up in the future. This effort includes property searches for things such as outstanding liens that might cloud title, as well as work that is done to actively cure adverse conditions. A common example of curative work is getting lien releases from prior payoffs properly recorded in the county recorder's office.

A claim against a title policy is an outcome that is desirable to no one - neither homeowner, lender, nor underwriter. Everyone involved would prefer that the stress, expense, and aggravation of a claim be avoided by the work and due diligence that is done before a policy is issued.

A title policy is really a guarantee on the quality of the work that went into searching, documenting, and curing title defects. This is more similar to a warranty on a new car than to traditional insurance, such as a homeowner's policy. When someone purchases a new car, they are issued a warranty that guarantees, for a period of time, the quality of materials and workmanship that went into making the car. No car owner ever wishes for the inconvenience of unexpected car trouble, whether the repairs are covered under warranty or not. The ideal claims rate for a car warranty is zero. Title insurance should ideally have a very low claims rate as well.

Perhaps the best way to stop misinformation and unfair comparisons is by emphasizing to consumers and regulators that title premiums are mostly paying for the work that goes into ensuring clean title rather than insuring against the uncommon scenario of future claims. Using the term "warranty" rather than insurance might be one way to make this distinction clearer.

Wednesday, May 16, 2012

Mobile Applications That Enhance Communication and Deliver New Business

Of all the new and emerging technologies out there today, none have captured as much attention or generated as much widespread excitement as mobile applications. With over half of all cellular subscribers now using a smartphone, and 20 percent of the population owning an iPad or other tablet, it is no surprise that vendors in the title and settlement industry have begun to jump into the mobile arena. 

Currently, most of the title and settlement mobile applications fall into three categories:  property research, communication and data access, and vendor management. Since technology evolves rapidly, vendors are already creating innovative new applications outside these categories that bear watching.

The first subset of applications, property research tools, are ideal for real estate agents and mortgage lenders who do not operate out of a fixed office.

Several of the major title insurance underwriters offer these kinds of mobile tools. These include Title 1-2-3 from Fidelity, AgentFirst from First American and Property Profiles from Stewart’s PropertyInfo division. All of these applications are available on both iPhone and Android devices, with Fidelity and First American offering Blackberry versions as well.

These applications allow a user to search for a property using a variety of criteria, such as street address, parcel number, or owner name. Fidelity’s Title 1-2-3 application even has a feature that uses the GPS capabilities of the device to provide a list of properties in the user’s immediate area.

Once a property is accessed with one of these applications, the user can view characteristics such as ownership and tax information, legal description, a property map and comparable sales. All of the applications mentioned also allow the user to email a property profile from the mobile device.

While the property research mobile applications are mainly aimed at real estate agents and lenders, underwriters and software vendors have created another class of applications that appeal to all participants in a real estate transaction. These are the communication and data access tools.

Most of the offerings in this category were built to expand access to existing web-based portals. These applications allow some or all of the participants in a transaction to view order information from a smartphone or tablet, send information to other parties and receive real-time notifications when important events occur, such as the delivery of a title insurance commitment.

Three such mobile tools are RamQuest’s Closing Market Mobile, PropertyInfo’s SureClose and Old Republic’s OR Mobile application.

RamQuest introduced its Closing Market Mobile iPhone application in October 2010. It allows users of RamQuest’s Closing Market platform to search for and view order details, including buyers, sellers, property information, and the status of outstanding requests to third-parties, such as appraisers and title insurance underwriters.

Additionally, RamQuest’s application taps into some smartphone-specific capabilities by allowing the user  to call or e-mail contacts directly from the application, view documents using scrolling and “pinch-to-zoom,” and displaying a map of the property location.

According to RamQuest, the application also works on the iPad device. An Android version of Closing Market Mobile is under consideration.

PropertyInfo, a division of Stewart Title Company, released a similar application for the iPhone in May, 2010 that provides transaction access to users of its SureClose transaction management platform. A version for Android phones was subsequently released.

Feature-wise, the PropertyInfo application is similar to the RamQuest offering. It also allows users to view a list of files, drill into order details, and call or e-mail a contact from within the application.

Another underwriter, Old Republic, has also released an application called OR Mobile that allows similar order access and capabilities from an iPhone or iPad.

Perhaps the most compelling of the current batch of mobile applications are the vendor management tools. These applications allow professionals such as notaries and appraisers, whose jobs are mobile by nature, to receive and accept (or reject) bids and complete work entirely from a smartphone or tablet.

One such tool is an iPhone application from ISGN that allows its network of appraisers to receive, accept and process real-estate appraisals entirely from a mobile device. The application features a series of screens that allow appraisers to enter all necessary property details, including room-by-room descriptions and notes on the condition of the property. Appraisers can also take pictures directly from the application. Once the on-site appraisal is complete, the user has the option to send the appraisal information from the mobile device to a partner to complete any necessary paperwork.

Another company, National Loan Closers, is developing similar technology to match the needs of title agents with its nationwide network of notaries. The company plans to release a mobile application in late 2012 that will complement its existing Closingboard solution.

Using Closingboard, notaries can choose to be notified when opportunities to perform a closing arise. By setting notification criteria such as price, location and times available, notaries can find out about the exact closings they wish to pursue without being bombarded with unwanted requests.

The Closingboard application allows the notary to accept or reject the assignment, check in when they arrive at the closing location and mark the work as complete.

Since appraisers and notaries are mobile, tools that allow them to bring in and complete new business while they are on-the-go will certainly give them an advantage and help grow business.

While most of the title and settlement-related mobile applications fall into the previously-mentioned categories, vendors continue to invent ways to introduce smartphones and tablets into the daily workflow.

One such vendor is Ernst Publishing Company, which has developed a mobile application that calculates potential settlement costs. Ernst’s client companies can customize the application to use a combination of their own propriety cost calculations along with standard closing cost data that Ernst provides. Once customized, client companies can affix their own branding logos to the application and make it available to their customers.

Another innovative vendor is LandTech Data Corporation. Their new LandTech eSign application for the iPhone and iPad allows users to scan, receive and sign documents directly from a mobile device – eliminating the need for printing and faxing of paper documents.

Without a doubt, mobile applications are getting the most attention from the public of any new technologies. I expect that many more vendors will introduce compelling new mobile applications in the near future.

Sunday, March 25, 2012

Designing Software to Minimize the Cost of Change

With all the legislative and technical changes that are impacting real estate settlement software, expensive and time-consuming changes are becoming increasingly necessary. With yet another revision of the HUD-1 form on the horizon, and new MISMO data requirements for lenders set to go into effect this year, this is a good time to look at ways you can make your software more easily adaptable to change.

For those who are not as familiar with the technical aspects of creating software, perhaps an analogy could help. Consider light bulbs. The federal government and some state legislatures are considering a ban on traditional incandescent bulbs in favor of energy-saving technologies such as compact fluorescent or LED bulbs.

Imagine if a ban on incandescent bulbs required you to hire an electrician and replace every light fixture in your home. That would be very costly, and pardon the expression, but a royal pain-in-the-arse, right? Thankfully, you can just swap one type of light bulb for another without any electrical work.

The reason you can easily switch from one light bulb technology to another is because light fixtures use a well-defined socket that will accept any bulb. All long as a light bulb fits the dimensions and electrical requirements of standard household fixtures, you do not need to be concerned with the underlying technology of the bulb (except for cost perhaps, but that is another discussion entirely).

There are similar concepts in software design: loose-coupling and interfaces.

Loose-coupling means designing software in such a way that distinct pieces of functionality can be readily swapped out with little or no need to modify other parts of the application.

Interfaces are the software mechanism that allows the easier and less-costly replacement of functionality. In the case of light bulbs, the socket is the interface. In software, an interface defines how one part of an application talks to another.

Ideally, settlement software should be designed so that the implementation of anything that is subject to change (such as the HUD-1 form) is a separate component (think light bulb). The portions of the software that gather the data for the HUD-1 form should have no knowledge of the physical formatting of the form, such as sections and line numbers. The order entry portion of the software should simply pass this data to the HUD preparation component using an interface (think light bulb socket) and let the HUD piece deal with how to present the data.

Designing software in this way minimizes the cost of changes by isolating the parts of the application that change. It is relatively easy to create a new software component that takes raw data, such as settlement information, and displays or prints it in a new format.

On the flip side, when details such as HUD sections and line numbers are referenced throughout an application, the amount of software code that needs to be changed grows dramatically. Application-wide, non-isolated changes are both costly and risky.

I highly recommend that anyone responsible for designing or building software read the book Design Patterns, Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (the “gang of four”). If this book is not already required reading for computer science curriculums, it should be.

Application developers need to make sure they take the time to adequately design for change. End-users need assurance from their vendors or information technology providers that they are providing change-resilient software. Doing so will save tremendous amounts of money and aggravation.