eMortgages and the MISMO Version 3 Reference Model
Abdias Lira, Principal Software Architect Wolters Kluwer Financial Services
As part of the MISMO Version 3 Data Standards development process, the eMortgage Workgroup worked together with other MISMO workgroups and partner organizations to consolidate all previous electronic document strucutres into a single, comprehensive specification that could be used for all transactions across all mortgage process areas.
Prior to Version 3, MISMO data standards were fairly independent from each other. Each MISMO workgroup developed and maintained its own specifications with little sharing among them. As a result, MISMO 2.x standards ended up with multiple inconsistent, and sometimes conflicting, definitions for commonly-used business objects. There are approximately fourteen different XML definitions for PROPERTY, LOAN and BORROWER, just to mention a few examples. This situation created a Tower of Babel nightmare to anyone trying to use the MISMO standards across multiple process areas.
While these issues were well-known when MISMO started the work on Version 3 and were attacked diligently since the beginning, there was another issue that was not so obvious. Lurking around the MISMO specifications were multiple discrepant ways of representing and communicating documents, impeding system interoperability, and frustrating adoption efforts. A close look at the specifications reveals at least three different document structures:
- EMBEDDED_FILE – This XML element is used in various request/response messages to convey document images, like PDF, TIFF or XHTML. Although there is some commonality, each workgroup has its own variation of this element.
- PRIA_DOCUMENT – This XML element was developed by the Property Records Industry Associations (PRIA) for use with the eRecording messages. It accommodates the document image, signatory information, and recordation-related data.
- SMART Doc® - This specification was originally developed by Fannie Mae and then further enhanced by the eMortgage workgroup. The main focus is to support the eNote, but other uses are also possible. It allows for communicating the document image, the data, a mapping from the data to the rendered document, signature information and audit trail.
Even before thinking about the reconciliation of these three document representations, we had already realized the need for some changes in the SMART Doc® specification. First, we decided to move away from any semblance of a proprietary format and towards the reuse, without modification, of existing standards. No more foreign elements in the XHTML view. No more MISMO-specific mapping methods. Secondly, we needed a change in perception. We wanted to position our document representation as a complement to popular document formats, and not as replacement to them. The main benefit we were seeking was the ability to leverage third-party document tools as much as possible, while being able to easily access the business data in the MISMO format.
These ideas aligned very well with the thinking of the other workgroups. That allowed us to consolidate all existing document containers into a single Version 3 structure, which we are now simply calling DOCUMENT. The new structure easily supports the simple use cases, such as delivering an image of a document, and is also capable of handling more elaborate use cases, where the document wrapper has to carry signature properties, audit trail, document data, and mapping information. As is the case with any Version 3 structure, all elements are optional; allowing each workgroup to define which elements should be used for each type of message.
In addition to having a common container for representing all types of documents, smart, intelligent, or otherwise, MISMO Version 3 also defines a common placement for those documents within the message structure. Every message is defined as a subset of a common model – called the Reference Model. The messages have two main nodes: DATA and DOCUMENT_SETS. Every time a message contains a document, that document is placed under the DOCUMENT_SETS branch. Anyone looking for a document (or its components) within a message can always go to the same location, regardless of the type of transaction.
Common message structure, common placement for data and documents within the messages, and common structure for all objects across all process areas: that is the beauty of MISMO Version 3. In practice, it means that Lender, Credit, MI, Document Preparation, Closing Room, Title, Investor, Land Record, and Electronic Vault systems can all work with the same overall structure for conveying data and documents, even though they may each support only a sub-set of the defined features. These systems can then evolve to communicate richer content to each other over time, without losing compatibility. One implementer can start small and build new modules upon that to support additional functionality. The XML representation of the document becomes richer at each stage of the development, but the implementer does need to change the structures created in the earlier stages. Likewise, this approach also promotes greater interoperability across systems of different capabilities. A receiving system can eliminate or ignore the features that it does not understand. In another scenario, a sender can remove the items that the receiver does not accept. In either case, the process works by simply adding or subtracting XML nodes, instead of translating between conflicting XML representations.
MISMO Version 3 is an electronic-document and eMortgage ready model. It provides a path to anyone who wants to transition from electronic paper to actual electronic documents. It will be an important tool for providing better and faster information to all players in the industry, be it a lender or a title company trying to avoid the next Matthew Cox, an investor wanting to assess the borrower’s ability to pay next month’s bills or any of us striving to reduce costs and survive in a shrinking economy.