In a perfect loan transfer scenario, the process would be as simple as dragging and dropping loan documents from one servicing system into the next. Files could be found exactly where you expected them to be, and loan information would leap off the page. We work in a far-from-perfect mortgage industry. The servicing transfer currency du jour is the “BLOB” (binary large object), a massive and unwieldy PDF containing the myriad documentation of a loan, or perhaps multiple loans, within a file. Untangling this mess costs servicers time and money—and opens them up to risk. With MSR values on the rise, many servicers are seizing the opportunity to grow their portfolios. But the process of transferring a loan from one servicer to another continues to be a headache for the teams working on the project. Here are just a few of the challenges servicers face today.
Inconsistent file naming
Servicing transfers naturally involve two parties. And since there is no “North Star” in the industry for document naming conventions, what Client A calls one file could mean something radically different for Client B. Unless you are using optical character recognition (OCR), you have no real way of knowing what is in a given document until you open it and read it over manually.
MISMO has provided standards on document naming, but most of it focuses on the origination side and it falls off once the loan ticks over to servicing. And until servicing transfer standards are adopted industry-wide, servicers will have to navigate the lengthy and costly process of “de-blobbing.”
Missing files
Many servicers also deal with seasoned loans in the servicing transfer space, which means scores of additional documents may have been added above and beyond what was in the original origination package.
That includes anything like letters, affidavits and more (especially in the default space), and any servicer can tell you the frustration of desperately needing to find a copy of a modification agreement, or a demand agreement, or communication back and forth with attorneys during foreclosure, and wondering what in the world it might be called.
Missing or unorganized documents ties back to the first problem: finding specific files becomes exponentially more difficult when no one names their files the same thing.
Extracting data from files to the system
Even once you do identify and classify the files in a BLOB, and then map the data into your own system, the de-blobbing work still isn’t done. In fact, it’s just now hitting one of the most critical stages: the stage where servicers need to verify the mapped data in their system matches the original documentation.
Post-transfer validation can be a messy – and risky – process. For example, if you scanned documents, the quality may not be perfect, eroding the integrity of the data you’re working with. Without a strong verification process, the data on the original mortgage documents may not match what is inputted into the servicing system.
Not only is this process time-consuming and inefficient, it can also create repurchase risk. If the servicer fails to properly service the loan according to the terms of the note and mortgage, the investor could force the servicer to repurchase the loan.
Another instance of risk could come with something both as simple and as important as whether the interest rates listed on the loan are correct. Take for example a fixed rate loan. While you might not think the interest rate would change, you notice in post-transfer validation it did. Now you have to wade through the history of that loan to research whether that change was supposed to happen (did the borrower have a modification?), or whether this was an error when mapping from system to system.
Mapping data from system to system
Mapping data from the original servicing system to the target system is another complex piece of the process. Not only are data fields not always named the same, but there can be a host of other complications as well.
Just like learning a foreign language, the transfer process doesn’t always come with direct “one-to-one” translations. One servicing system could have its own set of rules that isn’t shared with the other. Or what one system calls a “loan number” could be called a “loan ID” in another.
Automation can help with system mapping, but before the process can be automated, it’s critical to establish clear instructions. Additionally, there needs to be a thorough test plan to help verify the quality of the data and to address any duplication, or missing or misassigned data.
Reducing the headaches of “de-blobbing”
The “de-blobbing” process of the documents and the transfer of data from one system to another requires a significant amount of pre-transfer mapping, testing and reconciliation to make sure that the loan information being transferred from one servicer to another is reliable and useful. The good news is that there are technologies available today to help automate the process, making it easier for acquisition teams to perform the work with fewer errors. Technology providers should also offer professional services to help you through the process – from setting up naming conventions and mapping processes, to testing data and reviewing exceptions.