Follow Bruce Silver on Method & Style.

Trisotech is a world leader in providing decision management solutions. Trisotech fully supports the Decision Model and Notation (DMN) standard for modeling and the Trisotech Decision Automation Engine for automating DMN models. This support includes full Conformance Level 3 compliance and supports the very latest version of the standard.

Trisotech’s Digital Automation Suite coupled with the Digital Modeling Suite is a decision management platform superior to any other product on the market. Its modern architecture is built around SaaS cloud technologies including API-first design which allows for the invocation of automated decisions from practically any programming language in mobile, cloud and on-premise server environments. These automated decision services are stateless, atomic and provide scalable high performance straight through processing. The automated decision services and decision automation engine are also structured to provide full support for today’s complex availability needs including containerization and docker technologies. The decision making platform’s modeling and automation is completely browser based and can be run in any modern browser environment including Chrome, Edge, Safari, Firefox, etc. Automation servers can be hosted by Trisotech, or Clients including on-premise and public/private clouds like AWS, Azure, Google, etc. Advanced configurations allow for 24 X 7 operation, concurrent geographic dispersion and failover, and containerization operating environments.

Trisotech has also expanded the decision management platform to include specific support for advanced technologies like AI/Machine learning with the inclusion of PMML models in the modeling environment and a PMML execution engine in the automation environment. Decision model creation, testing, administration and management as well as automation library management, administration, configuration, debugging, simulation and audit logging are all visual and browser based making Trisotech’s offering a complete decision management and automation solution.

What Does a Workflow Management System Do?

Workflow Automation software executes computer-driven flows (processes) of human and system tasks, documents, and information across work activities in accordance with flow paths based on business decisions. Workflow Management software also ensures processes – both internally across organizational boundaries, and externally for Customer/Client interactions – are optimized, repeatable and auditable while still being quick and easy to change.

While Robotic Process Automation (RPA) has been making inroads in automating tasks within processes, Workflow Automation software is far more powerful than RPA. However, the two are both compatible and synergistic. RPA bots can automate individual tasks within a business process, but they typically can’t connect those tasks together. Good workflow engines allow RPA tasks to be included as part of a process.

Workflow Design software and Workflow Process software are being effectively used in practically every industry, frequently serving as standard operating procedures software. Digital Workflow software can be especially effective and valuable in two industries: Healthcare and Financial Services.

Using Trisotech’s workflow management software, healthcare organizations can develop evidence-based workflow and decision models that are human-readable, machine automatable, and embeddable in most medical encounter systems. While healthcare organizations can and do create their own automatable models, Trisotech also provides pre-built models including nearly 1,000 free customizable care pathways, clinical guidelines, and healthcare decision calculators in the BPM+ Health standard. This way, Trisotech’s process management software enables practitioners to stay updated, accelerate solution adoption and ensure greater consistency in care execution. Additionally, the comprehensive visual models offered by the Workflow Design software are readable by IT, providers and business people, serving as a guideline specification, the guideline logic, the guideline documentation, and the automation code for the workflow engine – all in a single visual artifact!

Moving to evidence-based practices is very desirable but also often difficult for healthcare organizations. Subject matter experts (SMEs) and clinicians constantly work with IT to translate large volumes of regulatory, new medication and procedure information into organizational policy. This is a consistent and expensive requirement for SMEs using their existing, often antiquated systems to keep information up to date. Trisotech’s Workflow Design software and Workflow Automation software solutions allow healthcare organizations to easily define and deploy evidence-based best practices that offer a consolidated view of the interactions and multiple touchpoints with patients, care pathways, and workflows at the point of care.

Back-office tasks such as pre-authorization, medical necessity determinations and off-label drug prescription approvals have a huge bearing on patient experiences. They are also time-consuming, expensive and highly manual activities. Utilizing Workflow Process software for these types of activities expedites decisions for waiting patients, allows for services to be rendered sooner, and increases ROI. Using Trisotech’s digital workflows paves the way for improving both the perceived and real quality measurements for any healthcare organization.

Healthcare Payers and Insurers are also leveraging Trisotech’s process management software to automate processes like claims processing and pre-authorization determinations, leading to more efficient decision making and significant cost savings. Trisotech’s Automated Workflow software can ensure the correct information is collected at the outset, help pay claims rapidly and organize case management for disputed or confusing exception claims. The workflow software also helps payers keep complete records in case of an audit. Health plan members benefit from a better experience as they can access the care they need with minimal delays and without surprises at the time of claim payments or billing.

More info on Healthcare

Technology replacement is also very important because most organizations have their knowledge, policies and procedures embedded in large complex programs maintained by IT programming staffs. Today, “old school” practices like SMEs maintaining Excel spreadsheets for policies and rules (regulatory and organizational) that then must be “translated” by IT into traditional programming languages and proprietary rules systems are giving way to visual models incorporating standardized “decision services.” Using Trisotech’s Digital Enterprise Suite, modern workflows and decision services can be built and maintained by SMEs and turned into automated business processes by clicking a single button. This, in turn, frees up IT resources to work on centralizing, consolidating and making available additional more current technologies across organizational silos.

Challenges

Primary challenges the financial industry is facing today include rapid and often massive regulatory changes, privacy, security, and fraud prevention, surpassing or keeping up with the competition by exceeding customer expectations, and replacing old technologies with emerging technologies. Trisotech’s workflow software is already recognized as the reference implementation for many international standards such as BPMN, CMMN, and DMN. In the financial industry Trisotech is rapidly taking a leadership position with its implementation of the Mortgage Industry Standards Maintenance Organization (MISMO) standard and support of other standards like the Financial Industry Business Ontology (FIBO), common database connections and multiple AI techniques.

For Fintech organizations, Trisotech’s Workflow Design software and Workflow Automation software accelerate digital transformation by providing the ability to easily define, deploy and maintain improved decision-making and workflows supported by artificial intelligence and machine learning in a graphical environment. While Trisotech’s Digital Enterprise Suite is being used by customers for everything from retail credit card processing to insurance claims processing, one area, underwriting, has been of particularly high value to customers.

Underwriting is the process by which an institution takes on financial risk – typically associated with insurance, loans or investments. Underwriting means assessing the degree of risk for each applicant prior to assuming that risk. That assessment allows organizations to set fair borrowing rates for loans, establish appropriate premiums to cover the cost of insuring policyholders, and creating a market for securities by pricing investment risk.

Underwriters evaluate loans, particularly mortgages, to determine the likelihood that a borrower will pay as promised and that enough collateral is available in the event of default. In the case of insurance, underwriters seek to assess a policyholder’s financial strength, health and other factors and to spread the potential risk among as many people as possible. Underwriting securities determines the underlying value of the company compared to the risk of funding its capital acquisition events such as IPOs. All of these activities lend themselves to digital workflow software solutions.

For example, mortgage loan origination. By utilizing Trisotech’s Workflow Design software, customers are able to build standard operating procedures software for loan origination that encompass the organization’s specific underwriting policies. These workflows can be created and maintained by underwriting experts while complex mathematical models, AI and privacy and security requirements are taken care of by IT personnel. Trisotech provides for all of this in a single common visual model understandable by both the business people and the IT personnel while still maintaining separation of concerns through granular permissions. Once the visual model is complete, a single button click can automate the workflow and make it available to Trisotech’s workflow engine part of the Workflow Process software.

More info on Finance

The unique capabilities of Trisotech’s Automated Workflow software are rooted in its ability to simplify the complex process of digital transformation for all. In order to streamline their processes and decisions, enterprises must first know what those processes and decisions are. Discovering and validating them is the responsibility of business leadership not solely IT. Thus, a must-do activity of digital transformation is rendering organizational workflows and business decision logic into international standards-based visual diagrams and documents. Then, they can be shared by business people and technical people and automated directly from those visual diagrams.

Trisotech calls this process Business Services Automation. The Trisotech offering includes visual Workflow Design software and visual Workflow Automation software.

A critical piece of what makes DMN accessible to business users is its expression language FEEL. FEEL variable names are business-friendly. Because they are simply the labels of the shapes in the Decision Requirements Diagram (DRD), FEEL names may contain spaces and other punctuation not allowed by other expression languages. OK, you already know this.

But when you publish a DMN model as a collection of executable decision services, a non-DMN client can’t invoke it using FEEL. The service inputs must be provided in XML or JSON format, and the outputs are returned in those formats as well. If you’re using Trisotech Decision Modeler, the tool provides a good bit of help, including automatically mapping XML and JSON inputs to FEEL, and templates that suggest the proper XML or JSON structure required as service inputs. But for certain things you’re on your own. In this post I’ll try to clear the air.

As a data definition language, FEEL is considerably more limited than XML Schema (XSD). For example, XSD has many different number types; FEEL has just one. XSD supports many different constraints on strings; FEEL just supports enumerated values and defined ranges of numbers or dates. XSD supports multiple cardinality specifications, including optional; FEEL has no conception of optional elements or number of occurrences other than 1 or “multiple”, i.e., a list. Nevertheless, Trisotech automatically creates an equivalent (or as close as possible) FEEL item definition when you import an XSD file, and automatically maps XML inputs conforming to that schema to the generated FEEL type. That mapping ignores namespaces and case, generates null values for omitted optional elements, and can even map XML names without spaces to their FEEL equivalent names including spaces!

All that is really helpful because many of the data sources you need in your decision models are already defined as SML conforming to some XSD. By associating your input data element with the generated FEEL type, you can easily model your decision logic using FEEL, and invoke the resulting decision service using the original XML!

That’s fine when you start with XML input data. But more often, modelers start with FEEL input data, which allow spaces in the names. Since XML variable names cannot contain spaces, this would seem to present a problem for calling a decision service. Somehow you need to create XML equivalent to FEEL input data with spaces in the names. The DMN task force in OMG has so far resisted standardizing a way to do this, but the DMN Technology Compatibility Kit (TCK), a working group charged with testing conformance to DMN semantics in execution, has done so, and Trisotech supports this alternative XML format as well. When calling a decision service in the Trisotech Cloud, XML input data in either format may be used.

Let’s make this clearer with a simple mortgage example, shown in the DRD below.

This decision model rates the Risk Category of a loan application based on summary data: Loan amount, loan-t0-value ratio LTV, and for each Borrower, debt-to-income ratio (DTI) and credit score.

Source data in mortgage applications often is provided consistent with the Mortgage Bankers Association MISMO XSD. That is a large and unwieldy schema, so to illustrate here we use a simpler one, shown below.

A few things to note about the XML variable LoanSummary:

• None of the components of this structure have spaces in their names; they are not allowed in XML elements.
• Components with solid outlines are required elements; those with dotted outline are optional. So component LTVPct may be omitted in some instances. FEEL does not have the concept of optional components.
• Another difference, not obvious from the schema, is that XML does not have the concept of lists. Instead it has sequences, which are always flat, so unlike in FEEL there is no distinction between a list with one item and the item itself.

When we import this XSD into our decision model, the Trisotech tool automatically creates the corresponding FEEL item definition shown below.

We assign our input data Loan Summary to this type. Note the component names have no spaces, so they are valid XML names, although our input data element itself does contain a space. Although I haven’t done it here, I could have modified the component names in the item definition: Loan Amt instead of LoanAmt, for example, and at runtime the tool would automatically map the XML element LoanAmt to the FEEL component Loan Amt. That’s pretty cool!

The decision logic, admittedly oversimplified, is shown in the boxed context below. Note that most of the variables used in the logic contain spaces in the names, except for components of the input data Loan Summary. Also note that context entry LTV Risk must account for the possibility that input data component LTVPct is omitted, i.e., null.

In Trisotech Decision Modeler, we can test the logic in the Execution/Test panel, here giving the result “Medium”.

Once we are satisfied that our logic is correct, in one click we can publish our model to the Trisotech Service Library in the cloud as a REST service. To invoke this service from an external client, we simply pass it XML data consistent with our original schema. In this case, our source data was already in this format, so it’s quite convenient.

When we execute the service with this XML input, not surprisingly, we get the same result:

The situation is a little different if we defined our decision model using FEEL for the input data. When we publish it as a REST service, we still will need to invoke it using XML or JSON, but in this case, we need to create the XML or JSON ourselves.

The Trisotech Service Library gives us a bit of help here in the form of XML and JSON templates. Notice in the figure above a link Download XML template. Clicking that downloads a skeleton XML file consistent not with the original XSD but with the alternative TCK format! The TCK XML has the advantage that element names may contain spaces, and since we started with FEEL that’s just what we want. It looks like this:

This looks nothing like the original XSD. Now the variable names are no longer XML element names but values of the attribute name, and thus may contain spaces. And because Borrower may occur multiple times, the new schema must declare it as a list. Even though LTVPct is optional in the original schema, there is no indication of that in the new schema, since FEEL has no conception of optional elements. Our test case instance, using the new schema, looks like this:

And when we execute the model using this XML input, we get the same result as before. In other words, Trisotech is able to transform XML input in either format – “normal” XML valid per the XSD, or its TCK equivalent – into the FEEL input data element Loan Summary. The advantage of the TCK format becomes apparent when your decision model is based purely on FEEL, with spaces in the variable names. In that case, the only XML that works is the TCK format, since “normal” XML does not allow spaces in variable names.

FEEL and XML also differ with respect to optional elements, meaning elements that may be missing in valid XML instances. They are quite common in XSD but do not exist in FEEL item definitions. In the XML instance, missing elements are simply omitted altogether, but in the Trisotech Decision Modeler Execution/Test panel, they are always listed. If you leave them blank, they are passed to the engine with the value null, which is just what you want. (If you enter the value null, they are passed as the string “null”, which is NOT what you want!)

On execution, if XML in either the XSD or TCK format is provided with an optional element missing, the corresponding item definition element is passed to the DMN engine with the value null, which is correct. The TCK format also provides an alternative format for missing elements. Instead of the xsi:type attribute, you need to write xsi:nil=”true” and leave the value empty. For example, to omit the optional element LTVPct, your XML would include

The reason I am going into this detail is that when you create decision models using FEEL input data, you need to create the XML equivalent manually. I wrote a program to convert all my Modeler test cases into TCK XML equivalents, but really it would be better if the tool did this automatically.

I’ve been focusing on XML because source data is more often specified as XSD, but in practice most often REST service calls use JSON instead. For example, the OpenAPI button in the Service Library downloads the service interface specification in JSON format. Some developers will tell you they love JSON and absolutely hate XML, but to me they are effectively equivalent. JSON syntax is more compact than XML, as seen by the equivalent test case below.

Not only is JSON more compact, but the component names may contain spaces. Also, a JSON element, as in FEEL, may be specified as an array of unnamed items. So in many respects, FEEL data is more like JSON than XML, and you may find JSON a more convenient format for testing your deployed decision services. Either way, once you’ve finished modeling your decisions using FEEL, in order to execute the resulting decision services from an external client, you will need to convert your input data to XML or JSON.

Follow Bruce Silver on Method & Style.

Without Data Standards the Mortgage Industry Doesn’t Go Digital

They used to say Seinfeld was a show about Nothing. But given its enduring influence on popular culture, Nothing is clearly not nothing. Attention must be paid.

In DMN, as well, Nothing demands attention. In simple models like the ones we study in my DMN Method and Style Basics and Advanced training, it doesn’t come up. But in many real-world decision models, Nothing pops up all over the place, often unexpectedly. When it does, proper attention must be paid or you will not get the correct result. This post shows you how.

A typical example is a model used to validate data prior to making the decision. FEEL is a fine language for data validation. Its functions and operators are rich enough, and it makes the logic transparent and business-friendly. But it is a little clumsy when it comes to handling Nothing, which in FEEL comes in two forms: null and an empty list [ ].

In real DMN models, it is often the case that some input data is missing. That’s not a mistake. In XML, those elements would be designated as optional in the schema, but FEEL does not have this concept. In the DMN input data, there is no distinction between required and optional elements, but in practice the optional elements often are missing. If a simple type, the missing element is assigned the value null; if a collection (list type), it is assigned the value [ ], i.e. an empty list; if a structured type, well let’s defer that one for now.

A common case of a missing simple type is a form field left blank.  For example, I’ve written before about the new standard Uniform Residential Loan Application (URLA) form for home mortgages.  Below is a clip of that form detailing the borrower’s monthly employment income:

Suppose you want to validate that the Total Income field matches the sum of the income items.  To do that, you could try some variant of the logic below:

Income Items: [Base, Overtime, Bonus, Commission, Military Entitlements, Other]
		Total Income = sum(Income Items)

But that test would fail.  Because some items have the value null, the sum is also null.  A better result would come from using

Total Income = sum(Income Items[item != null])

This filter removes the blank values from the list, and in this case the test now works.

But that’s not the end of the story.  This part of URLA is just wage income; it does not include self-employment income or other income.  So suppose all the Income Item elements are blank and the Total Income field is 0.  The test now fails!  The argument of the sum is an empty list, and for some reason (not a good one), the spec says

sum([])=null

Total Income = if Income Items[item != null] = [] then 0 else sum(Income Items[item != null]

Wow, that’s a mouthful!  Because this comes up all the time, it’s better to make this a BKM:

nn sum(numList):  if numList[item != null] = [[] then 0 else sum(numList[item != null])
		Total Income = nn sum(Income Items)

Actually, Trisotech and Red Hat support nn sum and several other nn (non-null) functions as built-in extensions, so you don’t have to create the BKM yourself.

And I need to mention that empty lists don’t just arise from blank fields on a form.  They occur all the time when a filter returns no list items, and this is very common.  That means just as with null, any time you are dealing with lists you need to account for the possibility of an empty list.  If you have an expression like

some x in myList satisfies ...

you could get a runtime error if myList=[ ].

Turning back to our URLA example, what if all the Income Item elements are blank and Total Income is blank as well?  In that case, the test above still fails!  When a blank numeric element is interpreted as 0, you need a function to map it to 0.

num0(myNum): if myNum=null then 0 else myNum

num0(Total Income) = nn sum(Income Items)

As I said, when your DMN handles Nothing, attention must be paid!

A common feature of data validation models are error messages, and Nothing must be accounted for here as well.  Typically these error messages concatenate some fixed test and values from the model.  For example, suppose the Total Income value from URLA must match a corresponding value on some other form, such as Form XYZ.Total Monthly Income.  The error message would be something like this:

Error Message: "The Total Monthly Income " + string(FormXYZ.Total Monthly Income) + " reported on Form XYZ does not match the value " + string(Total Income) + " reported on URLA."

We need the function string() to cast a number to text for use in the concatenation.  But what if Total Income on URLA is blank, and FormXYZ.Total Monthly Income is some non-zero value?  As you probably have guessed,

string(null) = null

and so

Error Message = null

That’s not what we want, obviously.  Here we have a choice.  We could define Error Message as

"The Total Monthly Income " + string(num0(FormXYZ.Total Monthly Income)) + " reported on Form XYZ does not match the value " + string(num0(Total Income)) + " reported on URLA."

or as

"The Total Monthly Income " + stringn(FormXYZ.Total Monthly Income) + " reported on Form XYZ does not match the value " + stringn(Total Income) + " reported on URLA."

where the BKM stringn is defined as

stringn(myNum): if myNum=null then "null" else string(myNum)

The first one reports null values as “0” and the second reports null values as “null”.  Either one is ok.

Is your head spinning yet?  OK, one more.  I mentioned at the top that if an input data element is a structure and missing entirely on execution, its value is… what?  That’s a tough one.  In XML it’s easy, since there Nothing is represented by exactly that, i.e., nothing.  It’s not included in the instance at all.  Let’s say Form XYZ is missing entirely in the data.  You can test for that in XPath using the Boolean functions exists(FormXYZ) or not(FormXYZ).  But it’s trickier in DMN, and partially tool-dependent.  In the DMN runtime, you can use the expression Form XYZ=null and it works just like the XML case.  But in a tool like Trisotech Decision Modeler, leaving Form XYZ blank in the Execution/Test html form does not work, because it interprets Form XYZ as a structure containing null components, so Form XYZ = null returns false.  That’s a valid interpretation as well.  This all comes from the fact that FEEL does not support optional elements, and the spec is silent about their value when the data is missing.  To solve this issue, the safest thing is to test a component of the structure that will always be present if the element is not missing, such as id.  To test if Form XYZ is missing, you should

use something like

Form XYZ.id = null and...

In spite of these quirks, DMN is actually a great language for data validation models.  The logic is transparent and understandable to business stakeholders.  And once the data is valid, it can be used within the same decision model to evaluate the rest of the decision logic.  This is much better than validating the data first in Java and then passing clean data to DMN.

Who uses MISMO?

MISMO mortgage standards are accepted and deployed by most organizations involved in creating mortgages, and they are required by most regulators, housing agencies and the GSEs that participate in the industry. A partial list of organizations using MISMO standards includes banks, credit unions, mortgage lenders, investors in real estate and mortgages, services providers, real estate appraisers, industry vendors, borrowers, Fannie Mae, Freddie Mac, Ginnie Mae, the Federal Housing Administration and the Consumer Financial Protection Bureau. The standards are also used by settlement and other third parties.

What is MISMO used for?

MISMO’s vision is to standardize how the mortgage industry communicates. Their mission is to drive standardized data and information and improve business practices between all mortgage stakeholders through collaborative and innovative initiatives that improve efficiency, reduce costs, and facilitate stakeholder success.

MISMO, via broad industry collaboration, creates standards that improve transparency and communications in housing finance and support solutions to many of the mortgage industry’s primary business issues. Use of MISMO standards to exchange information more securely, efficiently, and economically has been found to lower per-loan costs, improve profit margins, reduce errors, and speed up the loan process by reducing manual, paper-based processes.

MISMO Standards and MISMO Reference Model

MISMO standards provide a common language for exchanging data and information across the mortgage finance industry. MISMO has residential mortgage, commercial mortgage, and eMortgage/digital standards available along with a wide variety of additional guides, tools, and other resources that support and accelerate the implementation process. The MISMO Reference Model which structures the concepts and data points used for the mortgage industry, is a framework used to structure information.

Here are some examples of well-known MISMO standards and resources:

• Business Glossary – a business-friendly collection of terms and definitions with content from both MISMO and non-MISMO sources. The glossary includes information about business terms, business processes, business events, documents, forms, and calculations, and supports elements from the Uniform Appraisal Dataset for MISMO 2.6 (UAD), Uniform Loan Delivery Dataset for MISMO 3.0 (ULDD), Uniform Closing Dataset for MISMO 3.3 (UCD), Industry Loan Application Dataset for MISMO 3.4 (iLAD), and Uniform Loan Application Dataset for MISMO 3.4 (ULAD).
• Life of Loan Business Process Model – a high-level business process model presented in Business Process Model and Notation (BPMN™), depicting common activities that may occur over the life of a mortgage loan. The model enables business professionals and others to access information about MISMO products within the context of their business processes.
• Logical Data Model (LDM) – the Logical Data Model consists of two sets of related models: a single Platform Independent Model that serves as the master blueprint for all formats of the MISMO model (XSD, JSON, ER model, etc.), and a series of Platform Specific Models that are derived from the Platform Independent Model. The Logical Data Model is new and completely different from models previously issued by MISMO. It is intended to support any technology that a company might choose to utilize. The LDM will support XML, as MISMO has always done, and will also support JSON, which is the technology of choice for mobile transactions.
• Residential Specifications – The MISMO Residential Standards are often referred to collectively as “the MISMO Reference Model”. The MISMO Reference Model contains:
  • The Logical Data Dictionary (LDD) which provides a business centric view of the model. The LDD provides standard business names, definitions, allowable values, formats and more in an easy-to-use Excel workbook format.
  • The Enhanced Logical Data Dictionary (ELDD) which is a user-friendly resource for business and technology professionals. A companion document to Version 3.5 of the MISMO Logical Data Model (LDM), the enhanced LDD allows for easier data searching, sorting, and filtering and shows how each data element fits into the LDM, XML Schema and API Toolkit. Business analysts can use the ELDD to easily find out which data elements are available within the MISMO Reference Model and where they are located.
  • The XML Schema specifies how the data and relationships that support industry business processes are organized into a logical, well-defined structure that allows for both the exchange of data and documents as well as its use within a system or enterprise. Included within the XML Schema are the SMART Doc^© standards which provide formats for electronic formatting of documents.
  • The Industry Loan Application Dataset (iLAD) which is a compendium of data that are included in the Uniform Residential Loan Application (URLA), the Government-Sponsored Enterprises’ (GSEs) Automated Underwriting System interfaces such as the Uniform Appraisal Dataset for MISMO 2.6 (UAD), Uniform Loan Delivery Dataset for MISMO 3.0 (ULDD), Uniform Closing Dataset for MISMO 3.3 (UCD), Industry Loan Application Dataset for MISMO 3.4 (iLAD), and Uniform Loan Application Dataset for MISMO 3.4 (ULAD) , as well as the existing Fannie Mae 3.2 file.
• Commercial Specifications – a Commercial Logical Data Dictionary (LDD) and Commercial Reference Model. The Commercial Reference Model is a model that standardizes industry terms and definitions and provides a comprehensive a structure for the relationship of all data in a commercial loan to be used in a consistent manner across all transactions.
• eMortgage Specifications – The MISMO eMortgage standards provide a framework for implementing and automating all aspects of the digital mortgage process. The work products provided are approved MISMO eMortgage standards and include Remote Online Notarization Standards (RON), SMART Doc® Components, eMortgage Glossary, eMortgage Closing Guide, eMessaging and Packaging, eRecording, and eSigned PDF Guidelines.

MISMO Communities of Practice (CoPs)

Each mortgage industry “Community of Practice” produces an implementation guide to document its area of the Standard. These provide more detailed guidance for implementing the Reference Model. MISMO has grouped the business process areas of the mortgage industry into four major categories: Origination, Servicing, Secondary, and Real Estate Services. Each category covers specific business processes within that industry area.

Communities of Practice focus on the interests of a particular area roughly based on MISMO’s Mortgage Industry Process Areas and include subject matter experts for each industry area. There are also data modeling, cross-industry, management, administrative, and other CoPs.

MISMO’s Mortgage Industry Process Areas

A complete list of CoPs and Development Workgroups can be found here.