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?To build an application using system-to-system data from scratch, you have a lot of work on your hands.
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
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.