gives your application a well-defined, useable internal data interface. It avoids error-prone text parsing.

All three credit bureaus can send their data in two ways: Text and System-to-System.

Text Credit Reports

Credit bureaus can format reports and send them to you as text. This is the TTY method. It is used by the standalone "teletype" terminals that were once common, and in low-cost desktop PC software packages, which simply request it, and print it verbatim.

The TTY method is not suited to any application that needs to actually use the report data. Your program would need to parse the data to find the specific data elements, and could easily be "broken" with any minor layout change from the bureau, any unexpected message on the report, or any glitch in the data stream.  The bureaus specifically warn against trying to parse text reports. They don't publish technical specifications for them, and they reserve the right to make layout changes without warning.

System to System Credit Reports

The faster and more powerful alternative is to request bureau data in a system-to-system format.  Data arrives in packed, predefined record layouts.  It is near-impossible for human eyes to read, but the computer can handle it quite well.  To get human-readable reports, the program "renders" them locally, in a layout and font that may be completely custom, or in a style that replicates the TTY style of your choice of bureaus: Equifax format, Experian format, or TransUnion format.

A major benefit of system-to-system is that the individual detailed data elements of a credit report can be used reliably in custom systems.

As the bureaus add new data elements, they do so with strict version control, and in a way that protects the integrity of existing systems. For example, when the bureaus went to 4-digit years, they did so by adding data segments to handle them. Applications that didn't need the 4 digits could count on the 2-digit year fields remaining where they had always been.

Can you do it yourself?

Fixed length record layouts are incompatible.  The bureaus all have different dial-up protocols. They don't  use the same terminology. Their reports are formatted differently. Reporting periods differ. Error and reason codes differ, and they are often quite cryptic. 

After obtaining the hundreds of pages of bureau documentation, you'll soon realize that you have over 1800 different data elements to deal with.

When you are ready for testing, how do you test your system when the Fair Credit Reporting act makes it a Federal offense to use live data from real consumers.  Testing is not a permissible purpose for retrieving credit data!

Bureau documentation, though extensive, is subject to misinterpretation.  Developers soon learn that test data does not always represent real-world data accurately.  One reason is that credit records were originally amassed from local bureaus around the country, each of which had their own ways of representing data. On occasion, you may find non-conforming data that can crash  a "perfectly" designed system.  It can take  years of field operation and hundreds of thousands of reports to run across these anomalies in the data.

The MERit Credit Engine

The MERit Credit Engine is the only practical, cost effective, and expeditious way to implement a system using credit report data.