Overview

Since the introduction of LenStar, default management platforms have focused on managing default timelines. LPS Desktop, LenStar/Tempo, VendorScape, Quandis Loan Servicing and others do an excellent job at this: all parties involved with the default can view the timelines, and given the appropriate permissions, update the dates. However, keeping track of the default timeline dates is but a small fraction of the work required to manage a default.

For all the upgrades and enhancements made (and being made) by technology providers in the mortgage default servicing arena, there remains gaps in the ability of business users to implement new requirements effectively and easily. The inter-connected nature of mortgage servicers and their vendors almost always mandates getting IT departments involved. When evaluating a default management solution (DMS), servicers should evaluate the platform with both current and future use cases in mind.

Tasks: Keeping Users in 1 System

Managing a default means communicating with multiple systems: a servicing system (MSP, MortgageServ, etc.), your DMS, document imaging, valuations, PACER, and probably 3-8 home-grown systems used by collections, bankruptcy and other departments. Expecting processors to be able to navigate and manage multiple systems to complete a single task is, well, so 1990’s.

Your DMS should be able to present users with a work queue, and when they drill down into a task on that work queue, present a single page from which they can accomplish the task without opening other windows. This means that, either prior to rendering the task or as the task is rendering, the DMS should be able to:

• Fetch the latest data from your servicing system (has a payment been made?),
• Check other systems based on conditions (foreclosure sale is tomorrow, check PACER for a bankruptcy filing),
• Call an internal NPV model to help determine ,
• Render all of the information needed to complete the task, and
• Determine the level of approval needed to complete the task.

Just as “power users” can establish timelines in current default management systems, they also need to be able to configure the default workflow to determine when to accomplish each of the bullet points listed above. Questions to ask include:

• Can a power user create a step in the workflow to get current data from your servicing system?
• Can a power user create a step in the workflow to request products from your vendors?
  • examples include BPOs, AVMs, Bankruptcy searches, SCRA checks, property inspections, title, pub and post
• Instead of your IT department creating a web page for users to run NPV calculations, have they exposed an NPV calculator that your DMS can call as needed? Can a power user determine what constitutes “as needed”?
• Can a power user control the user interface of a task? Not just creating new fields to track, but also things like:
  • rendering a panel displaying documents from your imaging system
  • complex controls like calculating payoff and reinstatement quotes
  • prompting for sets of documents required for a particular loan modification
• How easy is to configure routing of a task for “final approval” based on power-user chosen criteria like UPB range, geographic region, and LTV ratios?

Producing Documents: Be Compliant

In the olden days (2010), document production was pretty straight forward: servicers produced their documents (often via the servicing system or a channel partner), and attorneys produced their documents via their case management system. There has always been some pain surrounding attorneys ensuring that the servicing data needed for attorney-created documents was current (think total debt and payoff quotes), but that’s not a problem we can just throw labor at that problem!

With the CFPB, HUD and the GSEs holding the servicer’s responsible for quality control over the attorney work product, this equation has started to change. Many servicers are now required to:

• Prove that they have approved the language used in the documents typically produced by an attorney, and
• Prove that they have reviewed the data associated with documents filed by the attorney

This is a serious consideration when evaluating a DMS. Does the DMS platform:

• Support document creation (“mail merge”)?
• Allow attorney case management systems to invoke a mail merge on demand?
• Enable real-time integration of attorney and DMS data, so you know the servicing data is accurate?
• Deliver the document images produced to both the attorney and into your document imaging system?
• Most importantly, can your power users collaborate with the attorney to manage the document templates in your DMS?

Business Rules: Make Sure You Understand Them

“Rules” is a very broad term, encompassing simple to very complex ideas. Examples of simple rules include:

• Forcing a required field to be filled out,
• Validating that a date is within a given range,
• Ensuring field relationships, like a valuation comparable is near the subject property

More complex rules are the meat and potatoes of making your DMS run efficiently, such as:

• Under what conditions are you required to send a breach letter?
• Is a user eligible for a particular loan modification program?
• When should you order an AVM vs a BPO vs an appraisal?

Questions to consider when evaluating a DMS include:

• Does your DMS system enable power users to implement such rules, or
• Can your DMS call rules that you’ve set up in a dedicated rules engine?
• Are the rules easy to understand, or arcane?
• If the rules are set up in your DMS, can other systems call them (don’t repeat yourself!)

Enabling power users to maintain rules is a huge deal. Your power users understand the nuances of default management far better than any IT department ever will. ‘Tis far better to offer your power users a tool to create rules, than to require power users to draft a requirements document for some programmer to write the rule for you: you’ll get your rule faster and more accurately with your power user!

We recently encountered a client that had an easy-to-use rules engine, but asked their IT department to implement rules surrounding a 2 paragraph description of breach letter requirements. The IT department created a rule that was a nearly 300-line long list of conditions. After months of production use, upon researching some incorrect behavior,  the business unit discovered 2 of the 300 lines were slightly incorrect.

The business unit rewrote the rule in 6 lines, easily digestible by anyone familiar with default servicing. More importantly, it was more accurate because it was easier to read!  When you can keep the implementation of rules inside your business unit, do it. Don’t let the inmates run the assylum.

Demand More Technology From Your Vendors

Default servicers pay lots of money to their vendors for all kinds of valuable data, including timeline date, valuations, title, bankruptcy and much more. In most cases, these data products are ordered in two ways:

• In bulk, often via a data file dump from a servicer’s IT department (e.g. BPOs, AVMs), and
• Ad-hoc, often via a user manually keying in orders (e.g. PACER, SCRA)

Ideally, a DMS will allow your power user to configure workflow steps to place such orders as part of your DMS workflow. In this case, it takes two to tango: not only must your DMS enable power users to do this, but so must the vendor you are ordering data products from.  Many vendors offer web services, but that does not necessarily make them easy to use. Old-style SOAP-based web services generally require extensive IT involvement.  Newer RESTful APIs often do not.

Consider a RESTful API to order title:

http://titlecompany.com/OrderTitle?Address=123 Main Street, Anywhere, CA 90210

or

http://titlecompany.com/TitleRundown?TSG=1234567890

If your power users can do a vlookup in Excel, a RESTful API call is cake.

The philosophy behind the this approach is to have IT professionals build a secure, easy to use pipeline that enables power users to choose what goes through the pipeline, and when. No longer will you need to set up a 3 week project to change the criteria driving your BPO orders; now your power user makes the change in your DMS in minutes.

This approach offers benefits far beyond a more powerful DMS. Upon building such a pipeline for PACER and SCRA orders, Quandis has found our clients integrating PACER and SCRA searches not just into their DMS, but into their call-center scripts, back-end analytics jobs, and more.

Yeah, But Can I Use Excel?

If a DMS is being used as described above, many of the processing gaps that exist today can be closed. Some gaps will remain. For those unforeseen situations, make sure your DMS plays well with Excel. Getting data out of your DMS is an obvious requirement. With a powerful DMS, more interesting Excel-style use cases arise, often in the case of servicing transfers:

• Generate documents based on ad-hoc spreadsheets and save them to your imaging system,
• Bounce a spreadsheet of prospective loan transfers against your breach letter rules (or any other rules),
• Place ad-hoc data orders to your vendors

In short, can you invoke any piece of DMS functionality by dropping off an Excel spreadsheet? If your power users have invested the time to configure your DMS to automate so much of your default management process for the “expected path”, you ought to be able to leverage that work for the unexpected path too.