Home / Compliance / Risk-e Business: Is There an Undetected Compliance Risk with Data and Electronic Documents?

Risk-e Business: Is There an Undetected Compliance Risk with Data and Electronic Documents?

 By Rachael Sokolowski

In the satirical 1980s film Risky Business, a Chicago teen’s parents leave him home alone while they go on vacation. The result is a series of unintended mishaps, involving prostitution and a pop-up brothel, high speed chases and a waterlogged Porsche, stolen furniture and a crack in his mother’s prized Steuben glass egg. Joel, the teenager, manages to restore the house to order, including the Steuben egg on the mantle, just as his parents walk in. Although Joel’s mother notices a crack in the glass egg, she does not ask how the crack happened or why there is a crack. She only asks how Joel could have let the crack happened and simply expresses her disappointment.

With its humorous depiction of how one simple decision can set off a series of catastrophic events, the movie Risky Business may have some bearing in the mortgage industry in the way electronic mortgage documents and data are handled. All may appear to be fine at the end of the process, but there could be a series of unintended issues along the way which may contribute to a less than perfect conclusion. For starters, there is a disconnect between the representation of the data in the document and the electronic data used by mortgage technology systems. Throughout the life of the loan, from origination, closing, servicing, and securitization, the document and the data from the document operate in parallel universes, much like Joel and his parents.

In today’s mortgage processing of paper documents, there is a reliance on humans, instead of technology, to determine inconsistencies. With paper, the only way to automate the processing of the information on the documents is to extract the data and this is typically performed after closing. The extraction may be done in one of two ways. In one method, a person manually keys the information on a document into a system. To reduce the error rate and to improve accuracy, two or three different people enter the data and the inputs are cross-checked against each other for inconsistencies. The accuracy rate varies between 98 and 99 percent for this type of manual keying.

A second approach is to automatically recognize text and numbers on the paper document. Automatic recognition involves utilizing technology, such as optical character recognition (OCR) and business rules about the document, to determine the letters and numbers. OCR systems, just as counterpart systems for voice recognition, make mistakes and are not 100 percent accurate. To have confidence in the quality of the data, regardless of whether it is input by hand or by technology, a certain amount of human intervention is required to audit inconsistencies, to perform exception processing and to control data quality.

Regardless of the method, after extraction, there must be a check for inconsistencies. If the data representing the loan amount was extracted incorrectly, this will have major consequences for the downstream systems processing the loan. Eyes must compare the two sets of information to assure a match. This process is commonly referred to in the industry as “stare-and-compare.” A person stares at the paper document or an image of the paper document and compares it with the data in the system. There is always a human involved in the final stage of the extraction process for a quality review of the data. But, it is not fiscally feasible to have a person to perform this check on every document in every mortgage loan. This creates the possibility for inconsistency in those loans that are not subjected to a compliance check.

This whole process from data extraction to stare-and-compare may happen more than once. It may occur in the loan origination system (LOS) and/or the lender’s system and/or the servicing system and/or the loan delivery system for the investor and/or whatever technology touches the mortgage. Each time data is re-entered into a system, there is a risk of error and inconsistencies. Paper will never be eliminated in the mortgage process or at least not in our lifetimes. But where in the process should these parallel universes be checked to determine that they are in sync? Before closing or after closing? And which entity in the entire loan process should be responsible for the verification of the data on the document and the data used by mortgage systems?

It is time to ask why this disconnect exists and whether this is causing operational and compliance issues for the industry. There are operational and technological solutions to reduce the risks. There is no need for these parallel universes.

The only way to eliminate the need to stare-and-compare is to capture the loan information once, and to minimize the reliance on paper documentation. Processing documents in this way is the premise of an electronic Mortgage, or eMortgage, and is often referred to as “lights-out” processing. In the early 2000s, the Mortgage Industry Standards Maintenance Organization (MISMO) with support from the Government-Sponsored Enterprises (GSEs), developed a standard representation for eMortgage documents called the SMART document. The MISMO specification carries the data of the document in a standardized format with a direct link to the visual presentation in a single, self-contained electronic document. It is possible to automatically verify that the data provided for machine consumption matches the information presented to humans. The SMART document is currently in use today for the electronic promissory note document and only for that one document.

A SMART document eNote eliminates the need for stare-and-compare. So, why not use this electronic specification for all loan documents? In the case of the promissory note document, there are special considerations since the document is a negotiable instrument. The promissory note is as good as cash and there needs to be an assurance that the document has not been tampered with—such as the loan amount changing after the document was signed. It is also important to know who is the holder or possessor of the electronic document. Since it is easy to make copies of and/or change an electronic document, the industry agreed to designate a registry to identify the “authoritative copy” or the electronic equivalent of the paper original and to ensure the electronic document had not changed in any way after the last borrower signed the document. Since 2004, the Mortgage Electronic Registration Systems “eRegistry” provides this information. The GSEs have defined delivery requirements for accepting electronic promissory notes and MISMO defines the eMortgage as “A mortgage loan where the closing documents—through an eClosing process that includes, at a minimum, the Promissory Note—are created, accessed, presented, executed, transferred, and stored electronically.”

This definition narrows what can be described as an eMortgage. Only loans with an electronic promissory note document qualify. And despite this legal and technical infrastructure for electronic mortgages, the number of eMortgages remains static at around one percent of all mortgages. Why is this?

The issue is the age of the SMART document specification that the GSEs require for delivery. This version was developed in the early 2000s. The industry has been slow to upgrade the SMART document specification to accommodate all loan documents, including the eNote, by using the updated MISMO Version 3 SMART document specification. With this version, there is a single reference model for all data about a loan throughout its lifecycle as well as all the data necessary for mortgage documents. The reference model also includes metadata information (such as the type of document), audit trails, and the ability to add information about document signers and signatures. Version 3 holds much promise for the industry to be widely used for all mortgage documents in the future as any mortgage document can be represented in the MISMO standard. However, there is a risk that the industry is mimicking the paper processes and will still rely on stare-and-compare for detecting inconsistencies. Why is this when a technology solution exists that does not require human intervention?

The MISMO eMortgage workgroup has developed different types of electronic documents to meet varying requirements. Four types of SMART documents are defined: Basic, Retrievable, Tamper Evident and Verifiable and these are known as document profiles. The profiles build on each other and become more extensive, from Basic to Verifiable much like a set of nesting Russian Matryoshka dolls. The most rudimentary one is the Basic profile. It contains the minimal amount of information wrapped up in a SMART Doc structure that includes the view (most typically a PDF), the document’s type (e.g., promissory note, closing disclosure, loan estimate, etc.), and, if the document is signed, information related to signatures. The intent of this profile is for electronic documents where the data is not used in the loan processing. An example would be the mortgage servicing disclosure. The Retrievable profile adds MISMO standard data to what is defined in the Basic profile and uses PDF/A for the view of the electronic document. PDF is an open International Standard Organization (ISO) standard and PDF/A guarantees future presentation of the electronic document despite technology changes and provides a mechanism to prevent changes to the document. The retrievable profile is used when the document data’s needs to be carried with the PDF image. There is no linkage between the data and the PDF for automatic processing to verify that the data matches the viewable representation of the document.

The GSEs have defined an industry dataset and electronic document format to support the closing disclosure forms, called the Uniform Closing Dataset (UCD). It uses the data and requirements for MISMO Version 3 SMART documents in the Retrievable profile. By requiring the use of the SMART document, the closing disclosure’s data is delivered along with electronic representation of the document. But one problem remains since there is no way to systematically check that the data in the UCD dataset matches what the borrower viewed before signing at the closing table. This disconnect introduces the potential for inconsistencies and furthers the reliance on stare-and-compare. This risk increases when the data comes from different sources which is very common for the closing disclosure.

And now, what is next for the eNote? The eNote needs a higher level of security that the electronic document has not been altered. The MISMO SMART document Tamper Evident profile requires an audit trail of events and a final digital signature for evidence of tampering. This digital signature is used for identification on the MERS eRegistry. This is necessary for the eNote. There must be confidence that the document and its data, such as the loan amount, have not changed since the borrower signed at the closing table. Is the Tamper Evident profile sufficient for the eNote? At present the GSEs believe so. But just like the closing disclosure, the possibility exists that the data does not match the PDF and, again, furthers the reliance on stare-and-compare after closing.

A solution for this situation exists in the Verifiable Profile. It includes all the features of the Tamper Evident profile plus links between the MISMO data and the information presented in the viewable image of the document. This provides a systematic and automated way to validate that the two match. The Verifiable Profile matches what is in place today for eNotes. The GSEs are currently not requiring this profile. For the eNote, the possibility exists that the data does not match the PDF. There is a risk here.

At some point in the process, a check that the data matches the document needs to occur. But where? And how? There are currently two different approaches: automated or manual. With an automated approach, the validation is pushed to the beginning of the loan process. The check that the data matches the document is an automated validation that can occur at any point in the loan process including before closing, during closing and after closing. Manually checking the data and documents is performed by humans after closing has occurred and only on a random set of documents. But is this operationally the right point for this check? Would it not make more sense to perform this check before closing? Or include technological solutions that do not require human intervention for inconsistencies such as those that were implemented years ago for the eNote?

Right now, it is unclear when the validation should occur and who should do it. The assurance that the data matches the document is performed in redundant and costly systems and processes that do not always have a technological mechanism to communicate with each other. There are impacts to staff and costs. What happens in the future when the technology provider of the eNote is no longer in business and there are errors in the data used to service and securitize the loan? Which entity will be responsible?

Technology should be used to remove mundane and labor intensive tasks. Technology should be leveraged to overcome the operational difficulties that arise when data is generated from different sources. But that is not the case for the closing disclosure or for eNotes as a MISMO Version 3 SMART document. Instead, the industry is relying on decades old processes for verification of information from paper documents. This is risk-e business, with a potential crack in the system.

Rachael Sokolowski, president of Magnolia Technologies LLC, is a recognized leader and technology evangelist in the mortgage banking industry. She can be reached at RSokolowski@MagnoliaTech.com.

Be Sociable, Share!

Check Also

The CFPB’s Five-Year Mortgage-Rule Review: An Opportunity to Improve the Regulatory Landscape?

By Joseph Yenouskas  & Lindsay Raffetto n March, Chris D’Angelo, the Associate Director for Supervision, …

Leave a Reply

Your email address will not be published. Required fields are marked *