MISMO: standard fare; The Mortgage Industry Standards Maintenance Organization Inc. (MISMO[R]) is on a mission to remove friction from the mortgage finance business. It is doing so slowly but steadily, by creating and leading the adoption of data standards.
A brief serving of alphabet soup
The Mortgage Industry Standards Maintenance Organization Inc. (MISMO) was formed by the Mortgage Bankers Association (MBA) in 1999 in response to a dire industry need to cut costs, increase efficiency and take advantage of any economies of scale in the origination and servicing of mortgage loans. (Note: Readers with aversion to acronyms should take some form of antidote at this point. The technology world is filled with them, mainly because technologists don't like to type long sentences.)
Data standards had already been bouncing around in the mortgage industry for a decade before MISMO, in the form of character-delimited (which means each character "space" in a file is assigned to a particular data field being transmitted) standards called electronic data interchange (EDI).
These efforts were hosted by organizations that worked full-time supporting the standards, and were structured under an organization called the American National Standards Institute (ANSI), Washington, D.C. (This organization, incidentally, provides the same structure to energy and other non-EDI standards.) By 1999 the EDI standards were mature, but lacking definitions for all the terms contained within (for instance, the definition of "loan amount"). It also had become apparent that character-delimited interface technology was (and is) difficult and expensive to support.
Then along came extensible markup language (XML)--itself formed in a rush and almost by accident. The core ways of building XML had been around for more than 25 years; they were just called something else--SGML--the history of which we'll save for another time. What was new was that the software industry finally made a decision to agree on the XML format, because nothing else was generating the needed efficiencies.
There were earlier versions of the same operating systems (the internal mechanisms that make your computer run) that we have today--e.g., Microsoft[R] Corporation Windows[R] and UNIX[R] (I say UNIX to denote the different flavors: BSD, Solaris[TM], Linux[R], etc). But there was no agreement on how to move data and process transactions among these platforms. Instead, there emerged a variety of proprietary ways (OLE/COM, Java[TM] Remote Methods Invocation [RMI], Remote Procedure Calls [RPC], etc.) and expensive standards such as Common Object Request Broker Architecture [CORBA[R]]. However, nothing really worked "off the shelf"--certainly not for a mortgage company--without significant customization at a technical level.
On top of the customization that already existed at the individual company level to support the differences among workflow, competitive practices, different mechanisms to handle regulatory compliance and more, these nonstandard tools meant much higher costs to implement systems in the mortgage banking arena.
Was there a way to curtail the costs and increase efficiencies? Was there a way by which we could form an industry-wide agreement that would benefit the industry and consumers, with a process efficient enough to reach the market and be implemented before it was time to revise the standard to the next version of features/functions?
MISMO's founding principles
A standard is only as good as the number of people using it. If only one-third of drivers agree a red light means stop, there will be important inefficiencies in personal transportation. Therefore, for a standards effort to be successful in the mortgage industry (or any other), it must cater to many different people with common needs--though differing approaches to meeting those needs.
When I first got involved with mortgage industry standards-setting, I observed there were two general constituencies. The first was the well-formed older and mature EDI working groups. These people generally came from large, very well-established and powerful residential mortgage companies that rolled out new releases slowly and were very meticulous and detailed about each atomic unit that might end up in its transaction.
The other constituency consisted of startup companies or dot-com groups that wanted to get standards done and to market fast enough so they could actually use them in parallel with the software they were developing, but were just getting formed into a standards-oriented focus. This second group (to which I belonged) had no idea what it was getting itself into. Yet these players wanted to build something fast and through consensus that could actually be used in the software they were rolling out almost simultaneously. So a very well-established, meticulous process that took a year to extend a standard was not going to work for them.
Another observation was that within any organization, big or small, there were two additional subdivided constituencies: people who usually had the word "analyst" somewhere in their title and who were very data-focused; and those with "programmer" or "engineer" in their title and who were concerned with process, technique and the architecture of handling the data--including what they looked like (the structure).
So, for a standards body to work for this industry, we could draw the following conclusions:
* It would have to be able to publish standards quickly, moving at the speed of business within the industry, but also more in lock-step with the software industry (e.g. Microsoft, Sun Microsystems Inc., IBM Corporation, etc.).
* It would need to cater and provide power, structure and work to both the data-centric people and the programming people.
* In order not to conflict with what was already completed, it would be focused solely on XML standards and provide definitions, names and structure to data points within the industry.
* The leadership of the standards body would have to include a cross-section of all the different types of entities within the industry--lenders, investors, service providers and software companies.
Changes in the software industry light the fire
Significantly, over the last decade the software industry finally agreed on an interchange format (XML) as a standard. Here I define the software industry as Microsoft and its flavors (.Net, COM and DCOM, et al.), IBM[R] (Lotus[R] Notes[R], WebSphere, DB2, et al.), Adobe[R] Portable Document Format (PDF), Sun Microsystems (Java, EJB[TM], Solaris, et al.) and Linux (Red Hat, Mandrake, SUSE, et al.). An interchange format is just a way of transferring data from one system or platform to another.
I believe this happened for two reasons. First, economics: Customers were simply sick of (that is, couldn't afford) paying all the increased costs to integrate across platforms or technologies. Also, the dot-com crash and the resultant IT budget tightening caused organizations of all sizes and types to push the software industry hard to agree to something.
Second, XML as an interchange format demonstrated that it does not interfere with any inner workings of the software companies' programs or applications. Thus it was not a threat, but an advantage. Just as MISMO is non-threatening to the mortgage industry, XML is non-threatening to all industries. This is the case because it allows software manufacturers to still hide (open source or not) all their logic and process specifics.
By the early 2000s, software interoperation was improving horizontally across all markets. However, software applications and technologies would not create consistent XML across platforms and systems for another few years. This meant that some form of translation was still necessary to achieve data transfer across platforms. But now it cost a lot less to set up and maintain, provided you had "vertical" definitions of the data (i.e., no matter what part of any process you perform, you use the same definitions as everyone else) you were describing--like MISMO.
Defining MISMO's goals
It is important to highlight what MISMO is and is not, because MISMO by its very design is not all things to all people. It was important in designing the MISMO standard to allow for companies to speak the same language, while being able to compete and not give up proprietary information. MISMO's standards are voluntary. Their use depends on their value proposition.
One important goal was to facilitate the ability of a mortgage company to switch off an application service provider's (ASP's) platform by reducing the costs associated with a change. That is not to say there are no costs associated with switching platforms when they are standardized; there are--they are just less.
In this vein, MISMO sought to partner with organizations that wanted to improve their part of the real-estate transaction (e.g., recording in the land records), provided they have a standards body and pluggable process we could map into the MISMO organization (e.g., Property Records Industry Association [PRIA] or the American Land Title Association [ALTA]). We designed fall-back capabilities so that if we could not obtain a formal partnership to other related industries, we could form a standardized way to transfer between the MISMO standards and the related industry standards or formats.
MISMO is a set of data-field values. These values were created bottom-up for residential lenders--that is, they were created based on the transaction "looking glass" that each MISMO participant was looking through.
We started with the Uniform Residential Loan Application (URLA) field values and rapidly built out each side to the other services that rely on all or part of that data set (mortgage insurance, credit reporting, title request, flood certification, etc.).
Simultaneously, MISMO's Servicing Workgroup started modeling the "servicing transfer" transaction, which has a much richer set of loan data and could and would also be used whole-cloth for loan setup/boarding. Over the years, they would expand into default and investor reporting and a more formal loan setup/boarding transaction.
Later on, two more groups began: the Secondary Workgroup, which started with product and price, and loan delivery (to an investor); and the Real Estate Property Information (REPI) Workgroup, with the support of the Appraisal Institute, Chicago. The latter workgroup worked on the real-estate property data set and is now working on the full appraisal request/response transaction.
These transaction-based workgroups create all the data listed out (usually in a spreadsheet) from their part of the world, and then agree on a definition for the data-field listing and its data type (i.e., money, enumerated list [including values], time/date and so forth). Lastly, common structures are agreed to and data are organized into a Document Type Definition (DTD)--which can be thought of as a set of rules by which to build XML data files.
Schema is a new specification in XML that allows you to specify and enforce the data type (money, time/date, etc.) during the processing of the files. The first Schema specifications from MISMO on the residential side are due in late 2005. Under the DTD architecture that exists currently, the data types are not enforced and none of the fields themselves are required. Everything is voluntary, not mandatory. This is the main reason MISMO rolled out the compliance service--so we could build a lowest common denominator for transactions.
To summarize, MISMO is a set of field values, called "tags," that are agreed upon industrywide and have unique definitions, also agreed upon by the industry. If some mortgage company or group of companies comes up with a field that exists, but with a different definition, then we usually try to work with them to call it something else--which works most of the time.
Then, MISMO structures those tags with the implied definitions (that you can look up in a MISMO dictionary) in a cohesive structural set of rules, or DTD, based on the transactional "looking glass" you are using. MISMO also specifies eMortgage file formats and standards--but we will save that for another article.
On the commercial mortgage side, the structures have been designed top-down--that is, the commercial mortgage industry got together and designed from the container and structures as objects, then what would be contained within them, based on multiple transactions, and then lastly assigned the unique data points. The commercial mortgage industry also is using Schema to start with and will have no DTD specifications.
Who pays for MISMO and why?
We made several very important decisions with regard to what we would provide as a standards organization to those who pay (subscribers) versus those who do not (participants). We decided that time was money, so the more capable people we could have participating, the better. Therefore e-mail listservs, the primary communication vehicle of MISMO, are free to participants.
The standards themselves--once approved and posted publicly--are also free. We decided to make the MISMO groupware collaboration software available only to subscribers. This gives access to concentrated sets of draft documents as the standards are being developed. Access to MISMO's revision-control infrastructure, the system that allows for the review and storage of the actual approved standards, is also free to participants.
I believe MISMO has enjoyed healthy growth over the past few years because of some of these choices. This growth is illustrated by the continual increase in e-mail listserv participants--the benchmark we use to gauge the number of people participating. Figure 1 shows the number of unique e-mails (which may be signed up across more than one list).
Lastly, one of the most important assets of the MISMO organization is its intellectual property rights (IPRs) and antitrust policies. The industry must be able to fiercely compete with and watch what competitors are doing in terms of participating with standards bodies. Our IPR policy allows competitive organizations to participate in the standards-setting activities of MISMO while keeping ownership rights to all the intellectual property they contribute. But they license that intellectual property to MISMO and all other organizations on a royalty-free basis for the purposes of building the parts of systems that use the standards. Putting the IPR policy in place for MISMO was no easy task, and took more than two and a half years.
Balancing 100 kittens with 10 saber-toothed tigers
One of the most amazing things about the MISMO organization is its equilibrium. Over the past five years, the staff has worked relentlessly to maintain it.
Through the standards-setting process, MISMO seeks to address those areas where an industrywide approach makes sense, while leaving the remaining areas open to proprietary innovation.
New challenges came when the MISMO Commercial Working Group joined the main MISMO group over the course of 2003 (while simultaneously forming the aforementioned IPR policy). During this same period we also spun MISMO off as a wholly owned 501(c)6 corporation.
The commercial real-estate world is quite different from the residential world. For those of you not involved in both, here is a quick summary of some key differences; when you read this, think of our perspective of creating a standards organization for and across both of these markets.
* Let's start with the markets themselves. Commercial, from a capital standpoint, is a little less than one-third the size of residential--about $2.5 trillion versus $8.5 trillion. The number of parties involved in the commercial world is also smaller comparatively. If we use MBA memberships as a baseline, there are approximately 652 regular members on the commercial side and about 1,097 regular members on the residential side. Translation: more market dollars controlled by fewer parties.
* Each deal in commercial is unique--the trick is to draw the commonalities out of each type of transaction (e.g., shopping mall, hospital, apartment complex, etc.). Residential is basically commoditized, and finds its uniqueness in how many ways bankers can slice and dice the terms of the loan (i.e., product and pricing).
* The appraisal in residential is quite streamlined and standardized, from a forms-and-process standpoint. The appraisal on the commercial side is a 300-page tome detailing the market and submarket characteristics of the property, such as occupancy levels and comparable expense levels of a building.
* Servicing in residential is the art of managing payments from (usually many) consumers individually. In commercial, there are additional complex analyses that are required during the life of a loan.
There are more differences as well. When you try to create standards, along with the process and framework by which to approve and distribute them, there are challenges in reusing the management infrastructure for the creation and distribution of independent standards across these two constituencies.
Another problem for all mortgage bankers is that they don't want to disrupt their pipeline of business for anything. This means a lot of them work on parallel deployments within their organizations--which is tricky for their technology staff as they are trying to roll out standardized solutions.
Does implementing a standard reduce costs?
We decided to try to quantify just how much a lender could save per residential loan by using open standards like MISMO across the front end of originating the loan. To do this we conducted the MISMO Time and Motion Study in October 2004. As it turns out, there were not many objective data recorded on interface creation, and certainly not comparing open non-proprietary interface implementations with proprietary ones.
So this led us to conduct a survey, which caused us to become a bit more subjective in our analysis. Nevertheless, we concluded that roughly $249 per loan originated could be saved if you reused (the "re-" is key) open data interfaces across the entire process of origination, up to closing and loan setup/boarding.
Having personally built an LOS in the mid-1990s with all proprietary interfaces and spending all those countless hours developing and testing those interfaces (or updating them), it sounded like a good number to me. The trick, then, was to be able to qualify the reusability of the interfaces. The need for a compliance-checking service became necessary, so we launched one in March 2005.
The lessons from all this
I believe these growth pains and complexities pulled the organization ever closer together and contributed to its existing equilibrium. This equilibrium is a beautiful thing to see in action.
New people come to MISMO meetings all the time. More often than not, they justify the travel or time expense to their organization with a reason that is usually self-serving in some way. They might say it's "to learn more about this standard so we can engineer it into our systems," "to learn more about the industry and its players," etc. Then, over time, because of the infrastructure and processes we have worked so hard to put in place and maintain, and because of the camaraderie that exists among existing participants, these new people balance their company's needs with those of the rest of the industry. And the equilibrium recalibrates to accept their participation.
Once they are comfortable with the standards body, its processes and people, they then may go on to join the ranks of our star performers--whom we affectionately refer to as the "MISMO STP."
Once again, a standard is only as good as the number of people using it. Judging by the type and number of requests we are getting about the standards, and from answers we are getting to MISMO implementation questions on our surveys, I believe we are doing quite well. Now if we could only fix those train tracks in Australia.
Gabe Minton is vice president of industry technology for the Mortgage Bankers Association (MBA) and executive vice president for the Mortgage Industry Standards Maintenance Organization Inc. (MISMO). He can be reached at email@example.com. To learn more about MISMO or to participate, visit www.mismo.org.
Figure 1 Growth in Listserv Participants 2002 2003 2004 2005 Commercial 42 199 240 310 Residential 716 978 1,248 1,998 SOURCE: MISMO INC. Note: Table made from bar graph.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||TECHNOLOGY; Mortgage Industry Standards Maintenance Organization Inc.|
|Date:||Oct 1, 2005|
|Previous Article:||Financing work-force housing: funds set up to build middle-market housing in inner-city neighborhoods are coming on strong. They make a lot of sense...|
|Next Article:||Why MISMO matters: how MISMO can help improve your bottom line and pave the way to the eMortgage.|