16319.jpg

Since the mid-1990s, default management systems (DMSs) have largely focused on managing default timelines. Today, many systems do an excellent job at this: All parties involved in the process can view the timelines and, given the appropriate permissions, update the dates.

However, keeping track of default timeline dates is a small fraction of what is required to efficiently manage a default. For all of the upgrades and enhancements that have been made by technology providers in the mortgage default servicing arena, significant gaps still remain in the users’ ability to implement new requirements effectively, easily and swiftly. The interconnected nature of mortgage servicers and their vendor partners means assistance from IT departments is almost always required - which is costly and often involves prolonged implementation.

When evaluating a DMS provider, it is critical that servicers consider both current and future use cases. Today isn’t tomorrow - and in the highly fluid mortgage servicing space, change is the only constant.

 

Keep users on a single system

In order to properly manage defaults in the new regulatory environment, a DMS must communicate with multiple disparate systems, including the servicing system, document imaging application, valuation software, PACER bankruptcy search software, SCRA search software and an additional three to eight systems, which are often “homegrown” and 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 1990s.

A DMS should be able to present users with a work queue. When a user drills down into a task in that work queue, the system should present a single page from which the user can accomplish the task - without being forced to open additional windows. This means the DMS needs to effectively communicate with the servicing system - both in batch and in real time - and have the ability to leverage internal Web services (e.g., net present value [NPV] models) and external services (e.g., PACER and SCRA).

 

Empowering power users

“Power users,” as they are called (i.e., a business analyst or non-technical person), must be able to easily control the invocation and display of data and timelines within a DMS. They also need the ability to configure the default workflow to interface with the other systems. Can non-technical power users control when to fetch servicing system data in real time or control when to order broker price opinions (BPOs), automated valuation models (AVMs) and property inspections? Instead of a servicer’s IT department’s creating a Web page for users to run NPV calculations, has IT exposed an NPV calculator that the DMS can call on as needed? Can power users determine what constitutes “as needed”? They should be able to.

When configuring the user interface for such tasks, many DMSs now allow power user-defined fields to be added. But the ability to add simple fields is not enough. Can power users add complex controls, such as rendering a panel displaying documents from the imaging system? Can they run calculations of payoff and reinstatement quotes? Can they prompt for sets of documents required for a particular loan modification?

How easy is it to configure the routing of a task for final approval based on power user-chosen criteria, such as unpaid principal balance range, geographic region and loan-to-value ratios? Setting up such rules and routines should be a point-and-click exercise that is easily digestible for power users.

Default.jpg

 

Producing documents and staying compliant

In 2010, document production was pretty straightforward: Servicers produced documents via the servicing system or a channel partner, and attorneys produced documents via their case management systems (CMSs). It has always been a challenge for attorneys to ensure that the servicing data needed for attorney-created documents is current (think total debt and payoff quotes) - but that’s not a problem that can be solved by just throwing labor at it.

Because the Consumer Financial Protection Bureau, the U.S. Department of Housing and Urban Development, and government-sponsored enterprises have held servicers responsible for quality control over attorney work, this equation has started to change. Many servicers are now required to prove that they have approved the documents’ language, which is typically produced by an attorney. In addition, they must show that they have reviewed the data associated with the documents filed by the attorney.

This is a serious consideration when evaluating a DMS. Does the DMS platform support things such as document creation in such a way that attorney CMSs can invoke a mail merge on demand? Will it enable real-time integration of CMS and DMS data so that one knows the servicing data is accurate? Can it deliver the produced document images to both the attorney and into the servicer’s document imaging system? Most importantly, can the servicer’s power users collaborate with the attorney to manage the document templates within the DMS?

 

Understanding business rules

“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 or ensuring that a comparable is in proximity to the subject property.

Complex rules are the meat and potatoes of making a DMS run smoothly and efficiently. For example, determining what conditions should be included in a breach letter, whether a user is eligible for a particular loan modification program or when to order an AVM versus a BPO versus an appraisal are all key considerations. These involve more complex business rules that must be easily configured and tweaked on a daily or weekly basis.

Enabling power users to maintain rules is a huge deal. A servicer’s power users are subject-matter experts who understand the nuances of default management far better than any IT department ever will. It is much more effective to offer power users tools to create rules than it is for business people to draft a requirements document for programmers and have them write the rules for the power user. With flexible business rules technology, a power user can create and implement rule changes much faster and more accurately.

A client of ours recently had its IT department implement rules surrounding a two-paragraph description of breach letter requirements. The IT department created a rule that contained a massive list of conditions and was 300 lines long. This not only was difficult, but it took way too long to complete. After months of production use, upon researching some incorrect behavior, the business unit discovered that two of the 300 lines were slightly incorrect. This required it to go back to the programmers and start the arduous technical undertaking all over again.

Fortunately, the business unit has since been empowered with an easy-to-use, business-rules-authoring interface and flexible rules engine. As a result, a power user was able to rewrite the rule in only six lines and do it quickly - without the help of IT. More importantly, it was more accurate because it was easier to read, far easier to implement, more efficient and cost-effective.

The goal should be to keep the creation, implementation and maintenance of rules inside a servicer’s business unit. Putting these in the hands of IT or developers is a dated, costly and error-prone approach.

Even if a servicer’s chosen DMS does not have a slick rules engine and interface for business users, power users should still be able to conveniently manage rules that are pre-built by IT. If a DMS does include a rules engine, ensure that it exposes an application programming interface (API) so other systems can call the rules that have been set up in the DMS.

 

Demand from your vendors

Default servicers pay lots of money to their vendors for all kinds of valuable data, including things such as timeline dates, valuations, title, bankruptcy and more. In most cases, these data products are ordered either in bulk - often via a data file dump from a servicer’s IT department (e.g., BPOs and AVMs) - or ad hoc, often via a user’s manually keying in orders (e.g., PACER and SCRA).

Ideally, a DMS will allow a power user to configure workflow steps to place such orders as part of a normal DMS workflow. In this case, it takes two to tango: Not only must the DMS enable power users to do this, but so, too, must the vendor delivering the data products. Many vendors offer Web services, but that does not necessarily make them easy to use. Using old-style Simple Object Access Protocol-based Web services generally requires extensive IT involvement. Newer RESTful APIs (APIs adhering to representational state transfer [REST] constraints), however, often do not.

As such, servicers should consider a RESTful API to order a title: If a servicer’s power users can perform a simple lookup in Excel, making a RESTful API call is cake.

The philosophy behind 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 a servicer need to set up a three-week project to change the criteria driving BPO orders; now, the power user makes the change in the DMS in minutes, without the help of IT. This approach offers major benefits over larger, more established DMSs with legacy architecture.

 

Yeah, but can I use Excel?

If a DMS is being used as described above, many of the processing gaps that exist in antiquated systems can be closed. Some gaps, however, will remain. For those unforeseen situations, a servicer should make sure its DMS plays well with Excel. Getting data out of the DMS is an obvious requirement. With a powerful, contemporary, user-friendly DMS, more interesting Excel-style use cases arise, such as generating documents based on ad hoc spreadsheets and saving them to an imaging system, comparing a spreadsheet of prospective loan transfers against the breach letter rules (or any other rules), or placing ad hoc data orders to vendors.

Excel is currently used by workers in the default management space to house and manage a great deal of information. Some may say it’s actually the de facto standard. Can a servicer invoke any piece of DMS functionality by dropping off an Excel spreadsheet? It can if its power users have the tools to create, implement and maintain rules. These power users must be able to configure the DMS to automate a great deal of the default management process for the expected path, so one ought to be able to leverage that work for the unexpected path, too.

 

The bottom line

The servicing side of the mortgage business has become increasingly complex and timeline-oriented, not to mention compliance-intensive. A servicer can’t afford the potential for inaccuracies or the costly waiting game for IT to get to something on its own terms. The bottom line is that power users within a business unit should be in control of the rules and configurations, not IT.

However, they can be empowered only if they are armed with a flexible rules engine and a non-technical rules management interface that allows them to effectuate change on their own terms, without the IT department.

 

Eric Patrick is chief technology officer at Quandis Inc., a provider of default servicing technology. He can be reached at epatrick@quandis.com.

Default Management

Shifting Control

By Eric Patrick

Improving the default management process means putting more control into the hands of power users and relying less on IT to write rules and make changes.

 

 

 

 

 

sm_bod

sm_bod_i

sm_bod_b_i

sm_bod_b

hyperlink

sm_cal_date

SM_text

SM_caption

sm_subhead

SM_F_subhead

 

 

 

SM_F_1stpara

 

sm_bod_last_graph

SM_last_graph

 

SM_pullquote_text

SM_pullquote_text

sm_s_h

sm_s_h1

sm_names

 

 

SM_frontoffice_1stpara

 

 

 

SM_Frontoffice_Dropcap

Sidebar Headline