The argument between synchronous and asynchronous integrations is valid. There are advantages and disadvantages to both. However, without understanding the context, an argument cannot be accurately made. In the case of document preparation, particularly with regard to the level of compliance validation and service necessary for lenders today, asynchronous integrations to a loan origination system (LOS) are and should be a requirement. They allow the most flexibility with regard to the processing time needed to create the required customized, compliant documentation. In this article, we will examine and establish a basis for this argument.
It is important to appreciate the distinction between a synchronous and an asynchronous integration in connection with the movement of data to accomplish the preparation of various products and programs for mortgage disclosure and closing documents. Synchronous integration simply implies that a service on system “A” (in this case, a LOS) sends a message containing data (i.e., a MISMO 3.3 data file) to a service on system “B” (a document preparation system). Then, system “B” responds a few moments later, with the document package requested. This is a single, electronic transaction containing a request followed by a response.
Asynchronous integration, on the other hand, contains multiple, electronic transactions. For example, an initial transaction may simply be a service on system “A” sending a message containing data (i.e. the same MISMO 3.3 data file) to a service on system “B”, and system “B” responds that the data was received and processing has begun. Then, within a certain timeframe depending upon what action is necessary (to be explained later in this article), a follow up electronic transaction from system “B” sends a message containing the document package to a service on system “A”, and system “A” responds that the document package was received. This would be an example of a “push” transaction from a document preparation system where system “B” is pushing the document package back to a service on system “A”. Likewise, certain document preparation systems will also support “pull” transactions where system “A” can send a status request to system “B”, and, if the document is ready at that time, the document will be provided; otherwise, a status of “pending” will be provided. The purpose is to provide a certain level of flexibility. All clients have differing requirements, and as we have seen over the past few years, those requirements change. Without the flexibility going into a relationship with a client, it is much more difficult to provide the services required.
Document Preparation is all about the validation of data and the creation of compliant loan documentation. An asynchronous system is designed to accept package requests in the form of various data file formats such as MISMO 2.6 and 3.3, along with other file types. Once the data is received, an asynchronous system goes about its business validating the data, running fee calculations, running the necessary compliance tests and checks, building lender specific, customized and tailored dynamic document package set as mandated by that validated data, and delivering the resulting document package.
It is not unusual for a document system to delay processing due to an issue with the data or per specific legal requirements. Flags and triggers are set within a smart document preparation system to handle these legal interventions and exceptions so that an attorney or compliance officer can act rapidly from a legal aspect if necessary. If no legal interaction is required, the package is then delivered.
One example of this is in the case of Texas loans that require attorney intervention for title review. Another example would be loans that have POA (power of attorney), Corporations or LLC’s, or Trusts and so on. In order to deliver the compliant product clients want and expect, sophisticated document systems are designed to handle any loan scenario that might occur, and sometimes that means extra data processing or legal intervention. While the goal is to deliver documents back to the LOS system as quickly as possible, that should never be at the risk of delivering documents that did not pass through all appropriate system checks and balances.
In some document preparation systems, synchronous integration forces the document provider to provide documents within a few seconds, or the process on system “A” will give up, or timeout. That “timeout” forces the user to resubmit the document package to the document provider a second time or in worst case scenario, documents are presented back to the user that are incorrect or out of compliance.
From a LOS development standpoint, synchronous integration is the simplest form of integration that could be written, but it is not necessarily the best scenario for a lender and can yield documents which are fraught with mistakes upon final delivery. In an asynchronous integration, the user submits the document request and can receive a notification that the document preparation system has received the request. Then after going through compliance tests, data validation, running calculations, interpreting whether or not the document package needs legal intervention, or there are errors to cure, the documents will appear. That time delay is typically less than two minutes, but it may be longer if something necessitates extra data processing or attorney intervention in the processing of the document package.
These two approaches may also affect a user’s workflow. If the workflow is designed to do one loan at a time, then the potential delays that are part of an asynchronous integration will be more evident. Whether the delay is disruptive is something to be determined. If determined to be disruptive, the workflow may have to be modified. A detailed discussion with the lender regarding workflow and processes at early stages of the integration and implementation phase are recommended to achieve maximum efficiency and 100% accurate compliance results every time.
Beyond workflow, there are also service level considerations. Recovery from many kinds of system issues, on either side, is far more tolerant in an asynchronous environment than in a synchronous one. An asynchronous system acknowledges receipt of the request, control of system “A” is returned to the user. System “A” and system “B” can then process independently. Many things are happening in system “B” to ensure compliance. Once the document set is created, system “B” will continuously try to return the document set to system “A” until system “A” responds that it has accepted the document set, thus ending the entire transaction. In a synchronous system, any failure, or extended delay, from either end causes the entire transaction to fail.
Many LOS providers support asynchronous integrations because they see the value this type of integration brings to not only their clients, but to the industry as well. Others have modified their systems, or are in the process of modifying their systems, to support the technology. The development effort for a LOS project team to move toward providing an asynchronous development option within their environment is not assumed to be a simple proposition, but neither is it as daunting a task as some fear it to be. The difference is how the results of the request are displayed. Remember, in an asynchronous environment, the documents are not returned as part of the “request” transaction. Instead, a popup is provided to the user that the documents have been ordered, the system then, behind the scene, validates the data, performs the calculations, runs the necessary compliance tests, checks to see if there is any legal or attorney intervention necessary, then displays and/or sends the 100% compliant results.
In certain circumstances, a report showing a list of errors that are preventing the documents from being ordered can be displayed. If the documents were successfully ordered, they will be made available in very short order. The user simply presses a button within the LOS to check the status of the documents in the document preparation system. If the documents are available, they are immediately retrieved. If not, another “pending status” is displayed. Upon a successful retrieval, various status information about the document request are updated within the LOS, and the user moves on to the next task. This would be an example of a manual “pull” transaction described in the first paragraph. “Pull” transactions are the most popular method of asynchronous integrations among the LOS providers supporting this type of integration; however, “push” transactions are easily managed.
The legal compliance world is changing. Flexibility is the key to being able to adapt to those changes quickly and efficiently. Asynchronous systems were developed to maintain that flexibility and adaptability. Clients who benefit from this type of interface have come to expect a higher level of detail in their software systems, along with the ability to quickly satisfy any requirement from any source along the way. An LOS integration that invokes an essentially instantaneous “timeout” situation in all “documents ordered” transactions mitigates against the core value proposition that a more robust asynchronous integration offers its clients.
About The Author
Brad McFarling is the Information Technology Director for the Mortgage Resources Group, LLC. Mr. McFarling has been with MRG since 1987 and has been working in the legal, software industry since graduating with a B.S. Degree in Computer Science and Mathematics in 1985. Besides his duties as IT Director, he is also the senior software developer and system architect for MRG’s document preparation system. Mr. McFarling pioneered many of today’s document preparation technologies such as remote document delivery, dynamic document templates and business-to-business integrations before they became the industry mainstays they are today. Outside of work related activities, Mr. McFarling is an avid sports photographer and fisherman.