This article will serve as a guide for architects who want to design, enhance, or augment existing workflows from within the loan-origination channel. It is part of a series of articles that describe the Loan-Origination Reference Architecture Pack (RAP). This article will focus solely on the workflow and orchestration capabilities of the RAP.
The guidance in this article will aid architects in unifying multiple loan-origination systems (LOS) and corresponding workflows. An LOS depends heavily on both loan processes and other services from within the enterprise. Unifying multiple loan workflows is a key concern for many lenders. With increasing acquisitions, and the respective increase in legacy systems, unification will give the necessary agility to be competitive in the banking industry.
Additionally, we will highlight how to automate the manual steps in the loan-origination process. As shown in Figure 1, oftentimes the largest bottleneck in the lending process is the manual steps. Between fax machines, paper-based forms, and manual data entry, this can get rather costly for lenders. Automation will ultimately shorten this process, referred to as the "application-to-close" process. Lenders can then process more loans with the same amount of infrastructure and personnel.
The scope of this article is in the context of the Loan-Origination Reference Architecture Pack (RAP). Links to all the corresponding articles and downloadable binaries will be provided in the References section.
Today, the loan-origination process is fragmented and inconsistent between different lenders. This is due to workflow complexity. To stay competitive, lenders use varying business processes to derive decisions on loans.
To aid in the development of this architecture we chose to break the loan-origination process down into a set of basic capabilities that the higher order business capabilities depend on. Surprisingly enough, this process comprises four core capabilities.
Loan origination is composed of the following basic IT capabilities:
We will describe how to create enterprise-scale workflows that enable your loan-origination process to run more effectively, reduce the amount of redundancy in the process, eliminate manual processes, and automate paper-oriented processing.
Described here are the enabling technologies that are used in our scenario:
WPF can reduce the training time of loan executives, officers, underwriters, and secondary marketing personnel. This is increasingly important in high-turnover areas.
WCF will reduce the increased complexities of the integration needs. For example, it will cover integration of broker, correspondent bank, flood, mortgage insurance (MI), appraisal, credit, verification of funds, and cross-sell services.
WF provides banks the flexibility to create workflows around documents, such as Office Excel, Office Word, and Office PowerPoint.
Office SharePoint can host your loan documents in a centralized, versioned, and secure environment, while also adding functionality, such as approval workflows and communications using Office Communicator 2005.
Office Excel Server can host your Office Excel data in a centralized SQL Server information store. This robust relational database provides data protection, centralized backup procedures, a single version of the truth, and security around sensitive data. This also provides the Office Excel user experience for multiple services without cross-training on other applications.
Document formats have been changed to Open XML, an open document format. This ensures cross-platform compatibility, robust integration, document manipulation opportunities, and controlled data integrity checks from within the documents themselves.
As mentioned in the introduction, we will be showing workflow in loan origination. For this scenario, we want to demonstrate the core capabilities of WF and BizTalk Orchestrations. We will walk you through a wholesale brokerage scenario, from the application process through the underwriting decision.
Please note that document-preparation and loan-closing processes have been excluded. The capabilities demonstrated within the architecture will show you how to build document-preparation and closing-document capabilities. The remaining capabilities will be addressed in forthcoming publications.
We will model our workflow after the business process shown in Figure 2. The purposes of these stages in the loan are as follows:
We will automate the majority of these stages in the workflow. As shown in Figure 1, there are many manual processes that hinder the process. To automate these steps, we have to look at the core capabilities that we want to expose from the loan process. We will be deriving the previously mentioned capabilities from the macro level and diving more into the details around the human workflow capabilities.
Breaking down these capabilities, it is easy to see why it takes lenders so long to approve and fund loans. We will focus on these detailed capabilities mentioned previously, and automate many of them—through the use of the Windows Workflow Foundation workflow automation capacities, BizTalk system orchestrations, and MOSS—to provide our core set of application services that will facilitate our process.
Before we dive into the solution, it is important that we understand some basic principles of our architecture. The terms workflow and orchestration have been used throughout this article. These types of flows are similar but very different.
Perhaps the most well known Microsoft implementation of workflow today is in BizTalk Server (although BizTalk Server uses the term orchestration, instead of workflow). BizTalk Server lets developers create system workflows for business-process management (BPM), enterprise application integration (EAI), and business-to-business (B2B) integration. The next release of Microsoft BizTalk Server will add support for creating WF workflows targeting these areas.
BizTalk Server and Windows Workflow Foundation have some obvious similarities. To a developer, for example, the BizTalk Server Orchestration Designer looks much like Windows Workflow Foundation's Workflow Designer. This commonality is no accident; the same group at Microsoft is responsible for both technologies. For the most part, however, deciding which one to use for a particular problem is not hard. What follows are some guidelines to help you make this decision.
For this reference architecture, we want to architect this solution in such a way that the workflows and orchestrations can interact and manage other external workflows. To enable these capabilities, we will rely on BizTalk's usage of industry-standard Business Process Execution Language (BPEL).
Figure 4. BPEL usage within the enterprise
A common thread within the process is the information that it uses. Throughout the loan process, data is gathered, manipulated, and sent to other systems. If we have a centralized loan-information store, business processes can work together more efficiently.
Figure 5. Centralizing information
For our scenario, we are only looking at origination and underwriting. However, we want to ensure that we provide mechanisms that can automate the downstream processes, too.
At the center of Figure 5 is a store of common information, such as borrower, assets, liabilities, and property. Aligning the information with the process areas containing information common to loan processing will also provide an information model for both process and information consolidation.
Using open standards for consumer mortgage is also helpful when interoperating with other system workflows. For example, MISMO has organized the business-process areas across the mortgage industry under four broad categories: Origination, Servicing, Secondary, and Real Estate Services. Processes under Origination include Mortgage Application, Underwriting, and Closing; Servicing includes Loan Setup and Transfer, Investor Reporting, and Default Reporting; Secondary includes Securitization, Bulk Pool Transfer, Funding, and Pricing and Discovery; and Real Estate Services include Appraisal, Credit Reporting, Flood, Mortgage Insurance, and Title.
MISMO aligns directly with the business process that we are enabling. However, RAP can support multiple loan channels, such as commercial. Organizations considering consolidating or augmenting multiple channels must ensure that they employ the right standard. For example, MISMO is a U.S. consumer-mortgage standard and would be inappropriate with other channels.
The human workflow aspect of the architecture will be controlled by Windows Workflow Foundation. WF will be running in conjunction with MOSS. Our architecture can now interact with several key areas:
For the loan application, we created several workflows, including:
Figure 6. Global workflow within the Loan-Origination Reference Architecture
As shown in Figure 6, there is a bit of intersection between the workflows. There are a variety of types and styles in which these workflows are used. Different personas and activity requirements drive the design of the workflow architecture. We are exposing the best-of-breed workflow solutions for each of these.
Products and Pricing Flow (PPF) is the mechanism that allows for the loan products and pricing process to occur. Because of the serial behavior of this process, we choose to use a sequential workflow.
However, for the Master Loan Flow (MLF), a state-machine workflow was used. The interactive nature of this workflow drove this decision. Documents are consistently updated and are working through various approval processes in a non-serial fashion. Additionally, this is a long-running workflow that will potentially last for several weeks.
The InfoPath Forms have their own sequential flow built in. By using the view feature of Office InfoPath, we can simulate multipage groups of forms. As an InfoPath form is iterating through the update of XML stored in the document library, the changes in the file trigger events in the MLF. Thus, Office InfoPath does not internalize any of the workflow, but rather indirectly invokes the workflow.