The tamper-evident seal is one of the foundational electronic mortgage concepts that was defined by the MISMO eMortgage Workgroup during the early development of the e-mortgage specifications and guidelines, way back in the 2001—2003 timeframe.
It utilizes public key infrastructure hash technology to create a digital “thumbprint” of a SMART Document e-note, or any other electronic document. At any point downstream in the process, the e-note can be revalidated against the value of the original tamper-evident seal, to prove that it is digitally identical to the original file that was signed at the closing table.
The value of an e-note’s tamper-evident seal is one of the data points that must be stored in the MERS eRegistry when an e-note is first registered. It’s called tamper evident because it doesn’t prevent someone from tampering with the file, but it provides absolute evidence of tampering, if anything has changed from the original file. All of this sounds very technical and theoretical, but we recently encountered a real-world example of the value of the tamper-evident seal.
A special servicer, using our electronic vault technology, wanted to take delivery of over 700 e-notes as part of a larger pool of distressed loans from a lender (this is called a hybrid pool—both paper and electronic notes). On behalf of our customer, we helped coordinate the technical transfer, from the lender’s e-vault system, through the MERS electronic delivery service, and into our electronic vault we provided the customer.
But when the e-notes arrived, our e-vault system rejected the transfer.
It took some intensive troubleshooting to pin down the underlying problem. The rejection itself was happening because our e-vault technology automatically re-validates the tamper-evident seal of any e-note before accepting it—after all, if the tamper-evident seal won’t validate, then the e-vault would be accepting an invalid e-note. The rejection mechanism protects the customer.
Within a SMART Doc e-note, there is a standard XML data element identifying where it is registered (just in case there was ever a need to identify a registry other than the MERS eRegistry). It looks like this:
At some point in the lives of these e-notes, they had passed through some kind of editor software that could not handle the registered trademark symbol—®—and that software had changed the ® to a question mark, and then saved the edited e-notes.
The tamper-evident seal will not validate if even one character in the eNote file has changed, and so changing “MERS® eRegistry” to “MERS? eRegistry” caused them to be rejected. Technically, the lender who was trying to e-deliver them to this servicer had actually been holding invalid e-notes and wasn’t aware of it.
Once we got to this point, the solution was easy. By simply changing the question mark back to the ® symbol, the e-notes were again digitally identical to their originals, and the tamper-evident seals validated properly.
At this point you might be wondering how the e-notes can be considered “original” after they’ve been edited and re-edited this way. That’s the beauty of the tamper-evident seal concept—if it validates properly, you know without a doubt that the e-note is a completely identical version of the e-note that existed at the moment it was first tamper-evident-sealed, right after all the e-signatures had been applied and right before it was registered on the MERS eRegistry.
In my panel presentations, I’ve been fond of saying that “technology is just a set of solutions for real-world business problems.” The tamper-evident seal is a classic example of exactly that—a complex technical framework that solves a basic business challenge: “How do I know that this e-note is still valid after it has changed hands several times?”
