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.

Trisotech provides 100% browser-based business process management discovery and modeling tools in cloud-hosted or on-premise environments. The process discovery tool – the Discovery Accelerator – helps business people describe the Who, What, When, Where, and Why of how their processes work through simple interactive screens and/or existing written policies, guidelines, business rules or other documents. These business observations can then be turned into an initial workflow starter diagram with the click of a single button.

Business processing modeling software from Trisotech – the Workflow Modeler – is used to produce a visual workflow using the international standard BPMN (Business Process Management Notation) via an intuitive drag-and-drop visual interface. These model diagrams provide comprehensive documentation, analysis, collaboration, and reporting features recognized as the gold standard in the process modeling industry and can be used directly by the Trisotech business process automation software. Using Trisotech’s BPM tools and combining the Workflow Modeler business process mapping software with the Trisotech Business Automation platform gives customers an unrivaled, powerful, and comprehensive low code/no code application development capability.

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.

Follow Bruce Silver on Method & Style.

Without Data Standards the Mortgage Industry Doesn’t Go Digital

Last time I showed the value of Business Knowledge Models (BKMs), those misunderstood and often-maligned elements in DMN diagrams.  In this post I’m going to try to do the same for contexts, another DMN feature that is similarly underappreciated and frequently disparaged by tool vendors that don’t support them.

Unlike BKMs, contexts are not DRG elements, meaning distinct shapes in the DRD.  Instead, a context is a type of boxed expression, a standard tabular format for the decision logic of a decision or BKM.  Contexts provide three essential benefits:

1. They simplify complex decision models, providing a compromise between models with simple-looking DRDs containing complicated literal expressions and DRDs containing many decisions, each with simple decision logic.
2. They allow you to model complicated decision logic – even a whole DRD – as a single value expression.  This is critical if you want to encapsulate that logic in a BKM.
3. They allow you to construct structured data out of simple values.

We’ll illustrate all of these in this post.

Even though contexts are primarily about managing complexity, we will illustrate their use with something simple, the same example we used last time: calculating the monthly payment for a home mortgage.  As before, typically this would be just a small part of some larger end-to-end decision.

When you shop for a mortgage, it is common to see loan products specified as a combination of the annual interest rate, an origination fee called “points”, and possibly additional fixed fees.  Points are a percentage of the requested loan amount that is paid up front.  Typically the points and fees are simply added to the requested amount and paid off over time along with the rest of the loan.

Even something as basic as this can be modeled in a variety of styles, according to the tastes and skills of the modeler.  For example, James is a business analyst who likes the DRD to break down the logic into lots of simple decisions.  He modeled the mortgage payment logic like this:

Each element in James’s model has a very simple value expression but it requires four decisions, plus a BKM payment for the amortization formula.  Since this calculation represents only 5-10% of the expected end-to-end decision logic, that projects out to a complete DRD with dozens of elements.  That could be a problem, because beyond 20 or so elements in the DRD, the decision model becomes difficult to maintain.

Edson is another member of the team.  He’s more technical and prefers his logic to get right to the point.  He modeled the same scenario in a single literal expression:

Edson’s DRD has just a single decision node and no BKMs, but that literal expression has a lot going on.  If we were to model the end-to-end logic in this style, the DRD won’t have too many elements, but their decision logic likely will be too hard for most other stakeholders to understand… and too hard to debug, even for Edson.  Both versions of the logic give the same answer for Monthly Payment – $1427.16 –  but they represent an extreme difference in modeling style.

Contexts provide a compromise, a way to reduce the number of decision nodes in the DRD while making their decision logic easy to understand.  A context effectively collapses a DRD fragment into a single two-column table representing the entire value expression of a decision or BKM.  Each row of the table is called a context entry.  The first column is the name of the context entry, a variable used in the context’s logic. The second column is its value expression, usually a literal expression but possibly any other boxed expression, including decision table, invocation, or even another context.  The last row of the context has no name, just a value expression.  That is called the final result box, holding the value of the context as a whole.

Each context entry defines a local variable, meaning it can be referenced by subsequent context entries in the context and by the final result box, but not by expressions outside the context.  While they are not outputs of the overall decision logic, context entries allow the final result box logic to be simpler and easier to understand.

With Monthly Payment modeled as a context, the DRD still has just a single decision node, but its logic is now easier to understand.

The context breaks out the logic into five context entries, each with the simple decision logic favored by James.   It could have fewer context entries, of course, with slightly more complex literal expressions in some of them.  Note how, for example, the first context entry, Requested Amount, is referenced by the value expression of the second context entry, Points, and so on, continuing down to the final result box.

Also note that not all the value expressions are literal expressions.  Number 4, payment, is a rarely seen type called a function definition.  Normally a function definition is modeled as a BKM, but it can also be modeled as a context entry.  Here we use it in place of the BKM in James’s DRD.  Context entry 5, Monthly Payment Exact, is a boxed invocation calling the function payment described above.  It has many digits after the decimal point, so the final result box simply applies the function decimal() to it, rounding to two places.  Again the calculation gives the same result, $1427.16.

That illustrates the first benefit of contexts, simultaneously reducing the complexity of both the DRD and the decision logic of each node.

Now consider the scenario we discussed in last month’s post:  We have an input data table of bank loan products, each specified by Rate, PointsPct, and Fees, and would like to compare their respective Monthly Payments by Lender by iterating over the input table Loan Products.  That involves iterating a call to the BKM Table Row to generate each row of the of the output table, which simply lists the lender name and the monthly payment.  The latter is a call from Table Row to the BKM Monthly Payment.

In this example both Table Row and Monthly Payment are modeled as contexts, illustrating the second and third benefits of this expression type.  Table Row is a context with no final result box.  In that case the context output is a structure, with one component per context entry.  Its datatype tLenderPayment has two components, Lender (Text) and Payment (Number), and the context entries of Table Row reflect that.  In fact, this is the normal way to create structured data one component at a time.  Contexts with no final result box are especially useful when working with table data.  Here the context entry Payment is modeled as a boxed invocation of the BKM Monthly Payment.

The BKM Monthly Payment is a context with a final result box.  It looks the same as in the previous example, except now as a BKM it has parameters: Purchase Price, Down Payment, and Loan.  The context entry Payment in the BKM Table Row invokes this BKM.

Executing the model gives the results below:

This example illustrates the second and third benefits of a context.

1. Since Monthly Payment is a BKM, it must be modeled as a single value expression, not a DRD fragment.  Contexts provide a way to reduce any decision logic, no matter how complex, to a single value expression.
2. Creating the table Mortgage payments by Lender one row at a time uses a BKM modeled as a context with no final result box to construct each row.  The BKM Table Row is an example of that.

You might notice that this model is still not a single value expression, since it requires two BKMs in addition to the decision.  Could we do it all with just one decision and no BKMs?  With a context, we can! 

The trick is to turn the BKMs into function definition context entries, like this:

Here the context has two context entries, both modeled as function definitions, plus a final result box that iterates over Loan Products.  The context entry payment is just the amortization formula, formerly a BKM.  The context entry Table Row is also a function definition.  It includes a context entry contextRow modeled as a context with no final result box – so it creates the two-column structure.  Table Row also contains context entries not in the output that create local variables to simplify the decision logic.  Since we want Table Row to output only the two-column structure, its final result box just points to contextRow. This does the trick; now the whole logic is a single value expression!

Contexts should be a part of every DMN modeler’s arsenal of tools.   You can learn how to use them in my DMN Method and Style Advanced training.  It’s unfortunate that some vendors that claim DMN conformance do not support them.  Every year in the Revision Task Force they tell us, “Business users don’t like the tabular format; they like DRDs.”  But as in the case of BKMs, these vendors typically support only the decision requirements portion of DMN – the DRDs – and offload the decision logic portion to their proprietary rule language.  That violates the spirit of a decision language standard, and it’s unnecessary.

If your DMN tool vendor does not support contexts or BKMs, please urge them to do so!

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!

From Business Rules to Decision Management using DMN