Printer Friendly

EDI harmonizing data standards.

I am considered "death" at a dinner party. An engaging dinner guest leans across the table and asks, "So what do you do?"

"Oh, I'm manager of electronic data interchange (EDI) for a secondary mortgage market agency. I work with all aspects of the mortgage industry to identify common mortgage information and define standards for exchanging that information electronically."

You should see the looks I get. One woman drew back and said, "I'm so sorry for you," and she turned back to the tax attorney, whom I thought she'd been trying to avoid.

It's about as sexy as being a plumber and a lot harder to explain. Occasionally, however, I meet a curious soul who asks me, "Why would one want to standardize mortgage information anyway?"

I begin by explaining how many different companies are involved in a mortgage from its origination to its closing and from its possible sale to its monthly servicing and eventual payoff. I remind my inquirer of all the forms he or she filled out when buying a home. Certain facts and figures from each form are used to initiate dozens of distinct steps in the process: from credit reports and enhancements, to appraisals, title searches and verifications. All of this information is stored in different computers in different locations - and usually in different ways. No one can move these details around easily. The goal of standardized EDI is to move all of this information smoothly between the different service providers.

People hearing may answer usually make the same comment. "Aren't all of these details already stored somewhere? I thought everyone used computers for everything today." And of course they are right, to a point. Many of the forms that make up a thick mortgage loan file are generated by computers. But the information is still printed on a piece of paper before being mailed or faxed to the lender.

At this point I back up and explain that, as more and more information is stored in computers, industries as diverse as transportation, shipping, insurance and education all face the same issue: how to get their hands on data that is meaningful. To do so means combining and comparing data from many different sources. Each of these industries, along with the government and other businesses like automobiles, electronics and petroleum, have recognized the importance of some type of common data language.

Processing mortgage data

In the mortgage industry, we typically begin the mortgage process by collecting specific information from the borrower on the loan application. In the next six weeks, we forward this data to service providers for confirmation or updating. And along the way, we collect additional details relating to the loan from verifications, credit checks, appraisals and title searches.

Typically today, once the loan file is complete, an underwriter sits down and compares all the different pieces of paper noting what the borrower wrote down on the application versus what was reported by the borrower's employer, bank, credit report, etc. These are all on separate pieces of paper, and depending on the company, each form might appear differently. The fields might have various meanings depending on the type of form used. If the response has been faxed, the quality of the page can be difficult to read.

Efforts to improve the flow of mortgage information started in the 1970s with the approval of common paper form layouts. Anyone responsible for reviewing seasoned loan packages originated on documents other than the Form 1003/65 Residential Loan Application knows how difficult it can be to find useful information when every form is different every field takes on a different meaning depending on who filled it out.

So when someone asks me about why I am interested in standardization, I attempt to draw a parallel between standardized paper forms and electronic data interchange formats. The mortgage industry's EDI efforts are designed to make it simpler for computer systems to know what data goes where and how to interpret data coding. When everything is recognizable and defined, the computer knows what to do with information once it is received - and exactly where to store it until you need it.

EDI basics

Let's say one can receive all the information on a residential credit report in a format the computer understands. Once received, the computer can recognize the borrower's name or loan number and can automatically update the lender's electronic loan file. The processor's checklist of required forms can be updated to show the receipt of the credit report. A quick review of the credit history can be performed as the findings are being stored. Particular problems, such as a credit rating other than a "1" can be set up to trigger an alert to the processor to inspect the report more closely and perhaps initiate corrective measures.

The fields of data that make up a residential appraisal report can be fed into an origination system without hassle with EDI. Simple checks like the number of comparables or the types of housing construction: colonial, cape cod, ranch, rambler, etc., can be verified to make sure everything meets the basic requirements. Weeks before anyone picks up the file to underwrite the loan, the computer system can warn the lender of problems that might delay the loan closing. Such checks leads to better customer service - problems are identified and resolved, instead of last-minute frantic, and sometimes fruitless, final-hour gyrations.

When the computer is automatically receiving and logging in the arrival of employment and bank verifications, credit reports and appraisals, mortgage insurance and hazard insurance details, then it can easily generate reports detailing missing items or unusual values and ratios outside acceptable loan-program ranges. A mortgage lender's staff can spend time responding to these problems and proactively setting things straight or offering borrowers an update or status on their loan package. By having the computer "open the incoming mail" from all of your service providers, employees have more time to communicate with customers - leading to improved customer service.

And because computers are able to recognize and interpret the critical details making up a loan package, they can perform the initial review of loan packages. Underwriters can spend more "quality time" on the packages that require underwriting as an "art" not a science. The vanilla packages well within program ratios, with straightforward credit and appraisals, can be moved quickly through the underwriting process.

Tying processes together

There are computer and software systems available that aim to streamline many of the steps in the mortgage process. Most automated processes or software systems, however, you are one of the lucky few that have your internal shop completely under control, where all systems are tied together and where details you need from origination processing flow smoothly to your secondary marketing and servicing systems.

Even then, you still have no control over the data arriving from all those other guys outside your shop. In order for the computer system to be able to set off alarms about credit rating problems, it has to receive the ratings and translate what they mean. Does somebody sit down and type everything from the credit report into the computer? Is the paper credit report received and somehow read or "scanned" into the computer - how does it know what data is where on the form, what to call it and where to store it? Can it be sent electronically in a way that the computer immediately understands without any help?

At this point, you may understand why my friend at the dinner party would rather talk about tax law. But hopefully, the scope of the problem is coming to light. So far I've only focused on the origination process. What about servicing transfer, hazard insurance renewals, tax authorizations, secondary market transactions and monthly reporting? These types of exchanges occur over and over again, between many of the same players, and with very similar information.

Working toward uniformity

As I try to explain all this, I am often bombarded with this response: "Someone must have tried to transfer information electronically before now, right?" Sure they have tried, I answer, and many people continue to try - but, there's a catch.

Let's say that I am a lender working with one credit company to develop a format for an electronic credit report transaction. We define codes to identify types of credit accounts and the locations and meanings of credit ratings. Now my computer receives valuable credit information and it know enough to put it

where I need it. I've spent limited program budget dollars to set this up, so I use this credit company as much as possible, even though it wouldn't be my first choice in certain parts of the country, if this was purely a business decision. But it's not - now technology is dictating with whom I do business.

So from a business perspective, I decide to work with additional credit companies and set up electronic exchanges with them. What do I do when the second, third or fourth credit firm starts sending me credit information electronically in completely different formats? The basic information on the report is the same, it's just arranged differently or named differently. Now I have to carefully match a particular report to the company that sends it. If I use the wrong program to interpret the delivered report, I'll end up with garbage. Depending on the size of these interpretation program, I might need to keep them on several systems. Any modifications, like reporting seven years' worth of past residences instead of three, requires changes to every program. Some people would say I would be better off just eye-balling the paper credit report when it arrived in the mail.

So what will it take to achieve this vision of rapid and smooth movement of all the information needed to process, close, service and sell mortgages? From verification of employment to details on the pool and security, the mortgage finance process should consist of easily recognizable data items being transmitted between all service providers. This includes mortgage lenders, credit companies, mortgage insurers, title firms, government agencies, borrower's employers and banks, closing attorneys, secondary marketing investors, appraisers, tax authorities hazard insurance firms, property inspection services and flood insurers.

Putting words into action

After I get really carried away with describing this enormous image of ebbing and flowing mortgage information, the question often asked of me is: "But how do you plan to accomplish this?"

In 1986, when I joined the Electronic Communications Department of the Mortgage Bankers Association of America (later to become the Mortgage Banking Service Corporation), a rudimentary set of standard data identifiers had already been defined. But over time, as more applications with expanded data requirements were presented, this set of data standards broke down. Among the many problems were issues relating to maintenance, updates and distribution procedures.

Those of us who were data "junkies" went looking for a longer term solution that would accommodate the industry's growing need for data. We wanted a solution that would be easy to "sell," not only in the mortgage industry, but in related industry - banking and credit and insurance (hazard, mortgage, flood and title) as well.

Considerable time and energy went into researching other. Organizations like the Automotive Industry Action Group, the Petroleum Industry Data Exchange of the American Petroleum Institute and the Transportation Data Coordination Committee had all hit upon a common approach to defining information in their respective industries. Mortgage data pioneers explored how these other industries met the challenges of the electronic ordering and receiving of products and services

These pioneers have taken the same approach used in all of these industries - that is, they create a set of standardized data fields and codes used between different companies and industries for electronic data interchange. These standard formats are developed and maintained on the national level by a group sponsored by the American National Standards Institute (ANSI).

Unfortunately the group has a name that sounds like a Star Wars robot: ANSI Accredited Standards Committee (ASC) X12. The group, comprised of volunteers form businesses located in North America, is accredited by ANSI as the keeper of the national dictionary on data elements used in electronic data interchange. ASC X12 offers definitions, field sizes and codes for over 1,200 data items. The X12 Committee has grouped these data items, known as data elements, into more than 600 commonly used records called data segments defining pertinent business particulars. These data segments are then arrange, depending on one's business need, into files representing the information found on paper forms. The X12 equivalent of a paper form is known as a transaction set. Transaction sets exist for invoices, financial information reporting, payments, tax information reporting and so on.

Making the ANSI grade

The X12 Committee offers a formal standards review and approval process. All standards are distributed for vote among the members and the meetings are open and based on consensus of the participants. The X12 Committee meets three times a year.

Leaders in the mortgage industry decided to set up an industry group. They then decided that rather than invent a completely new way of doing things for mortgages only, they would try out the X12 method of "electronic computerspeak."

But like any new language, it takes a considerable amount of time and education before one speaks it with any confidence. Though several mortgage holding companies use existing X12 transaction sets, we had no previous experience with this method of electronic transaction design. So we set up the Mortgage Data Standards Task Force and went back to school in our spare time. Volunteers from mortgage, companies, appraisal firms and title companies began meeting in work groups to define the business fields needed to streamline the mortgage flow.

We also ventured into the intimidating world of ANSI's committees to see what we could learn about X12 EDI and the national standards-setting process.

In 1989, ASC X12 had 10 subcommittees, but none of them were prepared to review and approve mortgage transactions. Talk of mortgage loan application, properly and appraisal specifics and mortgage insurance had them baffled. Therefore, we received permission to set up a Lending Task Group under the ANSI's Finance Subcommittee. Upon approval from the mortgage industry via its Mortgage Data Standards Task Force, transactions were brought to the Lending Task Group of X12 for review, approval and ongoing maintenance on the national level.

X12 advantages

Maintenance of mortgage standards is a major advantage for receiving final approval from the X12 Committee on mortgage transactions. Once approved, X12 makes all transactions, data segments, date elements and code list available to anyone obtaining the X12 draft standard directory. X12's approval process allows three updates per year to approved standards. After initial approval is given, the MBA or a particular mortgage company, software supplier or service provider does not have to keep records of changes and continually circulate them throughout the industry. The X12 Committee, and its secretariat, the Data Interchanges Standards Association (DISA), are set up to do this.

Another advantage to the mortgage banking industry of aligning itself with a national standards organization is that it gains access to expertise in the areas of security, legal issues or audit control. There are major corporations within X12 focusing on these issues. Why reinvent the wheel? Instead let's review the recommendations of the experts in these areas, and implement when they make sense for the mortgage industry.

A dictionary of date

Now that I've given a full explanation of what data standards are and how we implement them in mortgage banking, my dinner companion asks: "So what have you accomplished towards the goal of fast-flowing mortgage information?"

Though we had a lot to learn about design guidelines, and the many ins and outs of the X12 approval process, the mortgage industry now has X12-approval for the first mortgage transaction set: the mortgage insurance application. (This is included in the latest X12 draft standard directory.) The mortgage insurance application transaction is the first step in ordering mortgage insurance electronically. But from a broader perspective, the approval of the MI application also brings with it the approval of data segments that can easily be used in other mortgage transaction. Collections of fields describing "mortgage characteristics requested," "property or housing expense," "loan-specific data," as well as "mortgage loan product description." "adjustable-rate and payment descriptions" and "real estate property information," are all data segments defined in the X12 draft standard directory.

The date elements and the codes necessary to explain these segments are also included. Now that these are approve, they can be used again and again in any combination to describe additional mortgage transactions. And whether simply designing an internal program or a sophisticated interface between two partners or multiple players, the X12 data element dictionary is a valuable resource. For every item, it lists the size of the element, whether it is a code, a number or an alphanumeric field, and it gives valid code values for everything from interest rate change to real estate loan type.

Among the other transactions under review by X12 and the Lending Task Group is the mortgage credit report order. A mortgage lender uses this transaction to order residential mortgage credit reports as well as other credit products. Upon X12 approval, it will add data segments to the national X12 database relating to income, applicant residence specifics, civil action income and liabilities, employment specifics, financial participation, consumer credit accounts and personal property descriptions.

These segments use data elements and codes like employment-class code, type-of-income code, type-of-personal-property code and type-of-account-ownership code. With the recent emphasis on Home Mortgage Disclosure Act (HMDA) data, there are even codes for race or ethnicity and gender included in the X12 data element dictionary.

One of the most recent proponents of data standards is the Department of Housing and Urban Development (HUD). Under Federal Information Processing Standard 161 (printed March 29, 1991), the federal government is instructed to use X12 EDI transactions for any electronic exchanges. If applicable transactions exist, they should be used or else new transactions will be designed to apply the new standard. HUD has joined the X12 Committee and the Lending Task Group and is developing a single-family claims transaction in conjunction with the MBA and X12.

MBA's commitment to technology

The MBA has expanded its focus beyond just data standards and has sanctioned a standing committee on technology. The work groups of the Mortgage Data Standards Task Force now report to MBA's Technology Committee, offering a comprehensive industry approach on technological issues. As new transactions are identified and defined by the work groups, they are also presented to X12's Lending Task Group. Transactions such as the appraisal report and request, the mortgage insurance response and the single-family claims transaction are registered as current development items with the national standards group.

It has taken a lot longer than anticipated to reach this point. A great deal had to be learned on both sides. The X12 Committee had no experience with service-oriented transactions. They knew manufacturing and shipping, but industries like education, insurance and entertainment all joined the national group about the same time as mortgage lending and began educating the members on transactions based on types of customer services, rather than number of widgets ordered.

And within the mortgage industry, we are just beginning to explore the technologies needed to fully benefit from the standards we have defined. EDI translation between a lender's internal software application and the approved EDI format has to take place, communications delivery options should be explored, data segments and transaction sets need to be implemented to confirm their flexibility and robustness. Conferences like MBA's "EDI in Mortgage Banking" and "Cash Management Technology" assist us in better understanding the role of data standards and EDI in the future. Educational seminars on EDI offered by the X12 Committee are also an important learning tool.

But, back to my dinner guest. After giving my explanation, I think perhaps it would be easier next time just to say I'm a plumber for the mortgage industry, and leave it at that.

Earning ANSI's

"Good Housekeeping" Seal

What do ladders, diving equipment, baked goods and mortgage insurance applications having common?

Up until this year, very little. But as of 1992, standards for all of these products or services have earned the blessing of the American National Standards Institute (ANSI), a voluntary organization that offers a kind of "Good Housekeeping Seal of Approval" to standardized specifications for products and services from all walks of life.

Under the auspices of ANSI's Accredited Standards Committees (ASCs), professionals from varying fields come together to develop, test, approve and publish standards. The Residential Mortgage Insurance Application Transaction Set, a standard for transmitting information about an insurance application through the use of electronic data interchange (EDI), is one of the latest of this group of standards.

EDI is a technology that promises a reduced-paper society where information is telecommunicated and stored in computers, eliminating burgeoning file cabinets and facilitating the sharing information. Thousands of business are using EDI now to cut costs and expedite service. Accredited Standard Committee X12 is open; volunteers are drawn from all industries and state and federal governments and agencies.

Other mortgage banking- and insurance-related standards being developed in ASC X12 includes one for residential mortgage applications and residential mortgage loan credit report orders.

Once the standards are approved for publication as draft standards for trial use, they enter a maintenance phase, during which they can be amended and enhanced as users put the standards through their paces. At designated intervals the standards are balloted to the entire ANSI community for approval as American National Standards.

Although adoption of an adherence to standards developed through ANSI is voluntary, ANSI standards are widely used - there are at least 20,000 X12 EDI standards users. ANSI is also the sole U.S. member of the two leading non-treaty international bodies that develop standards, thus providing U.S. industry, business and government a voice in decisions that affect world trade.

What does all this mean? That standards now being developed for the mortgage banking and insurance fields will be most the widely used and recognized in the industry, country and world. Such prominence assures the development of products and services to support these standards and brings the benefits of electronics data interchange to the real state finance industry.
COPYRIGHT 1992 Mortgage Bankers Association of America
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1992 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:includes related article on American National Standards Institute; electronic data interface
Author:Barkley, David
Publication:Mortgage Banking
Article Type:Cover Story
Date:Mar 1, 1992
Previous Article:Special delivery.
Next Article:What's hot in technology.

Related Articles
Electronic data interchange is coming: here's why.
Business-to-business payments and the role of financial electronic data interchange.
A new technological era for hazard insurance renewals.
EDI: an acronym to watch.
HCFA's evolving role.
FTA Task Force on Electronic Data Interchange: a status report.
EDI: setting the record straight.
EDI and the tax department.
Obstacles to ubiquity: EDI's slow acceptance.

Terms of use | Copyright © 2017 Farlex, Inc. | Feedback | For webmasters