Helping the Mortgage Industry Go Digital

Fannie Mae is one of two major Government Sponsored Entities (GSEs) underpinning the residential mortgage market in the USA.  They supply liquidity to the system by purchasing mortgages from lenders and repackaging them as interest-paying securities sold to investors.  Without them, we wouldn’t have the low-rate long-term fixed rate loans that so many home buyers depend on.  Recently Fannie published a white paper titled “Without Data Standards, the Mortgage Industry Doesn’t Go Digital.”  The paper is meant as a wakeup call to mortgage industry participants, who have been notoriously slow to adopt digital transformation.  Unless they pick up the pace, warns Fannie, they risk being displaced by new fintech companies, who are already rapidly increasing their share of the mortgage business.

Their 2018 survey of lenders revealed the following leading challenges to adoption of new technology:

• Lack of industry-wide data standards (46%)
• Inflexible processes (38%)
• Lack of industry-wide system/platform standards (26%)

Fannie’s white paper focuses primarily on the data standards problem and points to recent gains in that area spurred by MISMO, the data standards arm of the US Mortgage Bankers Association.  These include a logical data model and XML schema for mortgage-related data elements.  MISMO data serves as the basis for things like the Uniform Mortgage Data Program and Home Mortgage Disclosure Act, as well as the new Uniform Appraisal Dataset, which enables automated acceptance of appraisals in Fannie’s Uniform Collateral Data Portal.  Not discussed in the white paper, but nearly as important as standardizing the data, is MISMO’s recent adoption of BPMN and DMN standards for process and decision modeling.  BPMN allows the definition of new, more flexible processes.  DMN allows decision logic to be deployed as microservices behind REST APIs, emerging as the next-generation system/platform architecture.  Thus in combination, MISMO data, BPMN, and DMN address all three of the leading barriers to going digital.  In this post we’ll see how they can be used together.

It’s one thing for standards to exist or to be “adopted” by an industry association.  It’s quite another for the companies participating in the industry to actually incorporate those standards in their work.  As Fannie notes at the outset, lenders have been slow to break free of their legacy systems and replace them with new digital technology.  In my own interactions with these folks, for example, in MISMO’s Decision Modeling Community of Practice, I would say that the biggest obstacle is simply lack of awareness of how these new technology standards can be applied and work together.  That’s unfortunate, because MISMO data, BPMN, and DMN can be applied in digital mortgage apps today.

MISMO Data

Let’s start with MISMO data.  MISMO’s logical data model standardizes the names of data elements used in all aspects of the mortgage business – origination, servicing, securitization, etc.  This not only eliminates terminology differences between various lenders and systems, but prevents the same element having different names and attributes when used for different purposes across the enterprise.  There is great benefit in that, but the downside is that the resulting schema is huge, so XML data conforming to that schema can be difficult to access and manipulate.  MISMO is working on reducing that difficulty, but for the moment what we have is a mortgage data standard based on a large unwieldy schema.  Still, it’s a system-independent standard and we can work with it.

The key advantage of having such a standard is interoperability of mortgage data across participant systems.  For example, it has allowed Fannie and Freddie Mac, the other major GSE, to unify their loan application forms in a common Uniform Residential Loan Application, or URLA.  Each field in the form is linked to a MISMO data element, and Fannie and Freddie require that lenders deliver loans to them as MISMO-conformant XML.  That means lenders’ Loan Origination Systems must be capable of outputting loan application information as standard MISMO XML.  New applications and microservices can then make use of this data standard to streamline customer interactions.

Example: Loan Origination

For example, let’s suppose a lender wants to determine the maximum loan amount available to a prospective borrower consistent with the lender’s ability to sell the loan to Fannie.  With DMN you can model and execute that logic.  You can use BPMN to handle the mapping between MISMO data, URLA form data, and the DMN decision logic, and deploy the whole thing as a microservice.  And to top it off, with tools like Trisotech’s Digital Enterprise Suite, it can all be done by subject matter experts who are not programmers.  Let’s see how this works.

The details of Fannie’s Automated Underwriting System are undisclosed, but they publish them for Manual Underwriting, so we’ll use that for this example.  For simplicity, we will be concerned with 30-year fixed rate mortgages for purchase of a single-unit primary residence.  Fannie’s eligibility matrix is shown below:

We will assume the lender will approve the loan if it meets these eligibility requirements, which have four inputs: the credit score, the loan-to-value ratio (LTV), the debt-to-income ratio (DTI), and the borrower’s reserves, meaning liquid assets after closing, measured in months of housing expense payments.  We can turn this table into a DMN decision table by determining the minimum credit score required for a given combination of LTV, DTI, and Reserves.

DMN Solution

Values of LTV over 95%, DTI over 45%, or Reserves less than zero are always ineligible, so the minimum credit score for those is null.

Of course, LTV, DTI, and Reserves are derived values, not raw data reported in URLA.  As is usually the case, the bulk of the DMN Decision Requirements Diagram (DRD) is deriving those values from the input data, based on the calculations detailed in the Guide on Fannie’s website. That DRD is shown below:

The top-level decision Result simply consolidates reporting of various details of the loan application, including whether the loan is eligible nor not.  To assist lenders in implementing the URLA form and MISMO XML data standard, Fannie publishes some test cases, including the one for Ken Customer shown below:

This is just page 1 of Ken’s URLA form, which contains many pages detailing the various sources and types of his income, assets and liabilities, plus details of the loan, property value, and cash required at closing entered by the lender.  On delivery to Fannie, this data is formatted as MISMO XML.  Ken wants to borrow $300,000 for a $340,000 purchase, and we’ve assigned him a credit score of 660.

In this case, the minimum credit score is 680, so Ken is ineligible to borrow $300,000.  Of course, that’s not news.  Undoubtedly the lender’s Loan Origination System already knows this.

Max Loan Amount

But let’s say we want to be able to tell Ken the maximum loan amount he would be eligible for given his financial details.  That’s more difficult to model, since as the loan amount changes (here we assume the same purchase price), the LTV, DTI, and Reserves all change.  In fact, even the loan rate may change.  So for that we have the modified DRD shown below:

Now we’re going to vary the loan amount (LTV), and calculate an adjusted interest rate based on the lender’s daily best rate, LTV, and credit score.  With the resulting change in down payment and mortgage payment, the model will also recalculate DTI and Reserves.  In DMN, even though the logic is detailed, it does not require programming.  Using FEEL and boxed expressions, a subject matter expert can enter it directly.  For example, below is the decision Qualifying PITIA, Ken’s monthly housing expense payments:

We can test the logic by entering input data values in the form here on the left and running the model.  Recall that Ken did not qualify for 300,000, but for a loan amount of 272,000, corresponding to LTV of 80%, Ken’s credit score of 660 is equal to the required minimum, so he is eligible at this LTV.  Once testing gives confidence that the model is correct, it can be published in one click as an executable decision service we could call for any borrower given URLA and the current best interest rate.

Mapping the Data

As a practical matter, we need to take account of the fact that MISMO XML, because of its nature as an enterprise data dictionary, makes expressions referencing specific data elements more complicated than they need to be.  We’d like the format of our input data element URLA to be more DMN-friendly, simplifying those expressions.  Here you see a side-by-side comparison of a fragment of Ken’s data in the two formats:

As output by the Loan Origination System, Ken’s data is MISMO XML, so data mapping is required.  Trisotech automatically creates the corresponding FEEL datatypes when you import an XML Schema and provides a special system task, called Context Parser, to map XML data to its FEEL equivalent.  So our plan is to create a DMN-friendly XML Schema for the input data element URLA, map MISMO XML to that, pass that to the Context Parser, which then invokes the DMN.

BPMN Solution

We can model those steps as a process in BPMN and deploy the whole thing as a REST service that takes MISMO data as input and outputs the result of our decision.  It looks like this:

The first activity is a service that maps MISMO XML to our DMN-friendly schema.  You can write a program to do this, or use a tool like Altova MapForce to create the mapping graphically.  The output of that task, here called URLA DMN XML, is passed to the system task Context Parser, which converts the XML to FEEL.  The decision task Max Loan amount simply executes the DMN model we showed earlier, with its three input data elements URLA, LTV, and Best rate pct.  The DMN decision Result is passed to the process data output, which is also tested by a gateway to provide process end states Eligible and Ineligible.

We can deploy this BPMN process in one click as an executable microservice in the Trisotech cloud.  When we run it with an LTV of 80%, Ken is Eligible for the loan.  That’s the service output shown below on the left.  But if we bump it up just slightly to 81%, as shown on the right, the minimum credit score required jumps to 680 and Ken is Ineligible.  This slight increase in loan amount pushes DTI above 36% and also requires private mortgage insurance (PMI).  Thus we can report to Ken that the maximum he can borrow for this property is $272,000, or LTV 80%.

Executable Process Design without Programming

Executable modeling by non-programmers is a basic feature of DMN, but BPMN historically has required programming to make it executable.  Trisotech, however, has borrowed FEEL and boxed expressions from DMN to let non-programmers create executable processes like this one.  Just like invocation mappings in DMN, the tool provides boxed expressions to map between BPMN data objects (variables) and task data inputs/outputs.  For example, below you see the mapping from the process data objects LTV, URLA FEEL, and Best rate pct to the corresponding DMN input data elements.  In this case the mapping is trivial, but as in DMN, any FEEL expression can be used.

The Bottom Line

It’s a lot to process, but let’s review what we just showed:

1. A DMN decision service, created by a subject matter expert – not a programmer – to determine loan eligibility per Fannie Mae manual underwriting rules (perhaps with modifications) based on URLA data.
2. A mapping of URLA data from MISMO XML format to a more DMN-friendly format.  This could be created by a non-programmer using a third party graphical tool, or by a programmer as a reusable service.
3. A BPMN process, also created by a non-programmer, to convert the MISMO data to DMN-friendly XML and then to FEEL, execute the DMN, and branch based on the decision result.

Assuming the lender’s LOS can output MISMO data, none of this depends on the details of the underlying systems.  It is all based on standards – for mortgage data (MISMO), decision logic (DMN), and executable processes (BPMN).  The whole thing can be packaged and deployed easily as a microservice, and it can be done by subject matter experts without programming.

The tools for the mortgage industry to go digital are here today.  Lenders should get to know them!