On August 1, 2015, the forms previously known as the Good Faith Estimate and the Truth in Lending Disclosures will be replaced with a new form called the Loan Estimate, which must be provided to consumers no later than the third business day following the submission of a loan application. In addition, the forms previously known as the HUD-1 and final Truth in Lending Disclosure will be replaced with a new form, the Closing Disclosure, which must be provided to consumers three business days before the loan is consummated. Our industry has taken to referring to these rules collectively as “TRID” or TILA-RESPA Integrated Disclosure rules.
Numerous resources on the Consumer Financial Protection Bureau’s website assist affected parties in implementing the Integrated Disclosure rules, including guides and sample forms. http://www.consumerfinance.gov/regulatory-implementation/tila-respa/ This article is intended to explore some of the practical considerations of the Integrated Disclosure Rules through programming and efforts to ensure that the resulting mortgage loan documents remain fully compliant … from the computer room to the courtroom.
The art of programming dynamic documents.
From a programming perspective, the Loan Estimate and the Closing Disclosure start out as a blank “electronic” sheet of paper, upon which is imposed X and Y coordinates for the placement of data. Data is pulled from the LOS and used to populate the new forms.
Featured Sponsors:
Each field on the Loan Estimate and Closing Disclosure has a corresponding annotating reference within the Code of Federal Regulations. For purposes of programming the content within each field, the First Guiding Principle is to follow these parameters on data insertion: if the reference is clear and free from ambiguity, then the LOS data is directly inserted in that field. An example of an unambiguous data point is the borrower’s last name. If the field is capable of different meanings, then a legal opinion might be required in order to determine the field’s content. An example of such a data point is the Date Issued, since the date may be different if the Loan Estimate is electronically issued on one date, but necessity prompts mailing the Loan Estimate (i.e. “papering out”) on a subsequent date. Finally, if the field requires a mathematical calculation, then mathematics drives the result, subject to rounding (in the case of the Loan Estimate). While this sounds straightforward, it might implicate the second rule depending on what should or could be included in the calculated result. An example might be the inclusion of Gift Funds in Cash to Close, or the rounding of some calculations and the truncation of others.
The Second Guiding Principle relates to the fluid boundaries on the electronic real estate. That is, an adjustable rate mortgage will have an Adjustable Payments Table and Adjustable Interest Rate Table, neither of which is present for a fixed rate mortgage Integrated Disclosure. The programming must be flexible enough to draw the table when required, yet move surrounding fields in place of the tables when the tables are absent.
Both the First Guiding Principle and Second Guiding Principle illustrate the concept of Dynamic Documents, instead of Static Documents. The latter are akin to simple forms where the boundaries and text never move; rather text or mathematical calculations are simply inserted into prepared blanks within the documents. With the former, Dynamic Documents, the document itself evolves as information is imprinted, drawing and re-drawing itself until completed.
Featured Sponsors:
It’s not possible to discuss the Loan Estimate and Closing Disclosure without touching upon MISMO 3.3 and its application to programming efforts. While the most recent release is already the subject of numerous lengthy articles and commentary in its own right, MISMO 3.3 was intended to serve as a companion to the Loan Estimate and Closing Disclosure, by providing a uniform set of data points and extensions to build the documents.
Programmers and web developers will debate whether MISMO really makes things easier, or whether it was simply a solution chasing a problem that has yet-to-appear. Some might persuasively argue that MISMO 3.3 is not even necessary to program for Integrated Disclosures. Whether MISMO 3.3 is utilized or not, it is unquestionably a burden to map (or re-map as the case may be) data and extensions by the lender, the Loan Origination System, and the document provider in order for all three to seamlessly communicate with each other. But taking a long term view, MISMO 3.3 (and subsequent, contemplated releases) has become the de facto industry standard. To the extent that Integrated Disclosures require mapping, our industry simply must consider utilizing MISMO 3.3 when programming for Integrated Disclosures. At a minimum, MISMO 3.3 already has the necessary data elements to make the development of Integrated Disclosures more streamlined.
Defensible documents from the computer room to the courtroom.
The Loan Estimate and the Closing Disclosure are tantamount to the left hand and the right hand, each clasping the other through the mortgage loan application process. Each is intended to be a companion to the other so that the consumer can readily see and assess all costs associated with the contemplated mortgage; however the Loan Estimate and Closing Disclosure are also traps for the unwary since inconsistencies between the two can cause compliance alerts. For these reasons, using the same technology platform/provider for preparation of both forms is ideal when it comes to minimizing errors.
Advancing to the end of the mortgage process and beyond closing, both the Loan Estimate and Closing Disclosure must be compliant (and defensible) to the end investor. Given the ambiguities within so many of the rules applicable to both forms, it is important to have a way to defend the programming logic used to define the output. To that end, an attorney’s opinion advising on the applicability (or not), or the inclusion (or not) of data point makes the end product more compliant (and defensible) to the compliance officer, investor, and/or auditor. To be sure, legal opinions are not always iron clad, but using a thumbtack to attach an attorney’s opinion along each path of the programming effort makes the end product highly defensible, from the computer room to the courtroom.
In the end, one starts with the premise that a loan origination system is feeding data to a mortgage document system to draw the application disclosures and then the closing documents. As a general proposition, technology aids in compliance effort when embedded tests check the data, again and again, for compliance with pertinent regulations. But the advantage of technology ends if the programming becomes outdated because the continuous bombardment of newly issued regulations are not interpreted and incorporated within that programming.
Human error can be almost eliminated through technology, but a human intelligence remains essential to parse the language of an ambiguous regulation and decide upon an appropriate course of action. Never has technology and human intellect been so critical to the creation and delivery of mortgage documents, all of which is in the name of making the process easier for the consumer.