Many are excited about the prospects of the American National Standards Institute's X.12 computer format and what it will do to standardize the flow of data in the mortgage industry.
Promoted mainly by the Mortgage Bankers Association, the format is gaining acceptance among most industry technologists.
There have been glowing reports about how standardization will streamline the information flow among the many offices that handle loan information.
But almost nobody addresses the drawbacks of this format.
The format was designed for use with electronic data interchange. Electronic data interchange was designed to let large manufacturing companies electronically transfer invoices and purchase orders with their suppliers. Banks increasingly provide such services to their corporate clients.
General Motors Corp. was one of the first to use electronic data interchange successfully. Today it is difficult to do business with GM without using electronic data interchange and the X.12 format.
Invoices and purchase orders were well-suited for data interchange applications for three reasons:
* The data contained on such forms is very standard. Fields are well defined, unambiguous and not very numerous. This makes it easy for all parties involved to agree on a standard format.
* Very few changes are anticipated in the kinds of data required for orders and invoices. This makes it feasible to construct a standard without worrying about the prospect of forcing thousands of companies to upgrade or modify their software.
* Finally, the data itself is not the product but only a means of ordering and billing for product. This is important because it means that suppliers have no desire to change the format for competitive reasons. The data is not subject to quality issues or subjective review. Competitors are not evaluated on the data on the invoices and orders but rather on the products shipped.
Information and transactions in the mortgage industry do not typically fit these criteria.
Mortgage loan data is complex and far from standard. A typical loan file will contain 1,000 to 3,000 data elements or fields.
Not only are there lots of fields, but whole classes of fields become either required or meaningless depending on the contents of other fields.
The picture itself changes when a loan is a refinance versus a purchase. It changes again depending on whether the agency is the Veterans Administration, the Federal Home Loan Mortgage Association, or the Federal National Mortgage Association ... whether the loan amount is Jumbo or conforming ... whether the property is owner occupied or not ... whether the borrower is self-employed or not, and so on.
This kind of complexity combined with the already complex structure of the X.12 format makes programming a transaction a time-consuming undertaking not without difficulty or ambiguity.
Second, the requirements of all the parties involved change constantly. You can count on Fannie Mae, Freddie Mac, FHA, and Veterans Administration - along with individual investors, Congress, and a hundred other federal or state regulators - to invent new fields, eliminate some, and modify others with and without due notice.
The only constant in the mortgage industry is change. We are beginning to see how new technology itself can create change. It is very difficult to create a standard in a constantly changing environment.
Once developed, the standard could be even more difficult to change or enhance.
The national standards institute is very careful about what it does. It works through committees, mostly national in scope. Existing standards seldom change more than once in four years. The alternative might even be worse - the standard never really will become standard but will be modified almost weekly, necessitating constant programming fixes.
Another problem is the most overlooked but probably the most significant.
For many transaction sets, the data itself is the product being sold. Think about credit reports, appraisals, title reports, flood certifications and even loan submissions. Any company selling such products goes to great lengths to distinguish its wares from the competition's. Competitors will change formats even when it is not required. Such changes are often subjective, being introduced for marketing reasons.
Actual presentations involve less a problem of standardization as one of providing meaningful, market-oriented information that goes beyond a "commoditized" minimum. Vendors work hard to add value to their offerings. Indeed, some credit reporting companies, for instance, will do more extensive legwork than others and dig for derogatory information through legal searches. The very nature of their business is to avoid becoming a commodity by differentiating themselves from the other guys.
Those companies that adopt the "voluntary" standard may find themselves restricted in the kinds of information they can offer for sale. They also risk being perceived as lackluster in their own markets.
Software vendors have real incentives to change a format or create a new one to exploit attractive features or genuinely new technology. Software look and feel is important. Vendors offering products that integrate well with existing loan origination systems have found a competitive advantage that was made possible in large part by ignoring the X.12 format. Some have gone so far as to be able to create a new borrower record within a third party's loan origination system. Needless to say, whether that data structure is proprietary or open, it is certainly not X.12.
Part of the promise of the information superhighway is the ability to use a common carrier, specifically a value-added network such as Compuserve, to move data between your computer and anybody else's. However, X.12 data bundles can be several times larger than proprietary files currently used for a given standard purpose. This becomes significant since the networks normally charge for their services both on a per-character sent and received plus a per-minute connection basis.
Informative Research Inc. tested this theory in a series of studies with various lenders using X.12 to order and receive credit reports over a value-added network.
"The X.12 files were so data intensive," said Mick Goldstein, vice president of client support services, "that where both a merged infile and RMCR were ordered on the same borrower each request/response added up to $40.00 in VAN connect and character transfer charges."
Mr. Goldstein adds that Informative Research continues to work with various value-added networks to reduce these charges in an effort to bring them more into line with today's point-to-point and dial-up connection costs.
The temptation is strong to stick with the old reliable ASCII flat-file format, which is used for more electronic data interchange than any other because it's easy to create, easy to read, and does not need to take up space with anything other than data needed for the transaction at hand.
One programmer, who works for another large credit reporting company, points out that creating an X.12 file for "export" is quick and straightforward. However, interpreting an "import" file relies heavily on figuring out context to know where fields belong.
Programmers find this strange, because such programs are cumbersome to write. He wonders whether the authors of this system really have much data processing experience. He feels they have succeeded in providing him with unexpected job security.
An industry analyst who has been working with mortgage-insurer transactions and X.12 wrote:
"X.12 has always been presented as a single format that will be gladly embraced by all the participants. One would think that we would then be able to deliver the same fields to each participant in the transaction ... Quite the contrary, we are finding that each mortgage-insurer company is developing their own implementation. Fields that are marked as optional under the X.12 requirements may be mandatory (and vice versa) depending on which MI is receiving the transaction."
Many are eager to give their opinions but are reluctant to be identified with them. The issue begins to look more and more like a modern episode of The Emperor's New Clothes. It's obvious that something is wrong. Yet those professionally involved cannot afford to go on record as having noticed anything.
You may have noticed that all of the companies that have developed automated underwriting systems also created their own format for the data elements they need. The X.12 format will never be able to meet such not- yet-invented requirements.
Also consider that X.12 is not the first mortgage-data format. Several years ago, the MBA released a standard format for 1003 information, one of the more standard kinds of mortgage information. The format never enjoyed widespread acceptance.
Still the siren song of standardization assails our ears and lulls our minds with its message of there must be an easier way. This makes us overlook how difficult it really is. Take an already large tangle of facts complicated by unpredictable laws and regulations, give it to a group of national committees, and hope something wonderful happens.
Even qualified and distinguished committees can get things wrong or leave things out. Select the committees for expertise from different segments of the industry and you have a veritable factory for inconsistencies and pieces that do not fit together.
Standardization can help many things run more smoothly, and applying the X.12 to mortgage transactions that can meet the three criteria described above will help us all be more efficient.
But in the everyday mortgage business, X.12 will be struggling against formats that are simpler, faster, more flexible, already widely used, and likely to provide a competitive edge.
There is no doubt that electronic data interchange has arrived in the mortgage industry. As software developers, we are committed to providing our customers with whatever they want. This includes some EDI solutions based on the X.12 format.
However, every company or contractor we have talked to and who has worked on an X.12 translator has reported - sometimes to their surprise - that what they built was "not exactly standard." If it were, it just would not do the job.
MBA should be applauded for its work in trying to streamline EDI. However, some very important issues may have been ignored, and it looks like the X.12 format will not be everything its evangelists hope.
