XML Implementation Guide: Credit Reporting Version 2

Similar documents
XML Implementation Guide: Credit Reporting

XML Implementation Guide: General Information

Credit Report Reissue Recommendation TABLE OF CONTENTS

All About Credit Reports from A to Z

Processing FHA TOTAL and VA Mortgages

Understanding Credit Reports and Scores and How to Improve It!

Understanding Credit Reports and Scores and How to Improve it!

A summary of your financial reliability

Your Credit Score and the Price You Pay for Credit

How to Check Your Credit Report

TABLE OF CONTENTS. CHAPTER 1: Credit Report.. Page 1. CHAPTER 2: Credit Score...Page 3. CHAPTER 3: Credit Reporting Agencies.

A.MORTGAGE LENDER B. CREDIT CARD ISSUER C.HOME INSURER E. ELECTRIC COMPANY F. LANDLORD G.ALL OF THE ABOVE D.CELL PHONE COMPANY

Phoenix Company Credit Repair Services (ver )

Understanding Credit Reports & Credit Scores

Ordering Merged Credit (LoanProspector.com System-to-System Access)

Credit Scoring RATE

CBCInnovis Infile Credit Report Reference Guide

Credit Scores. Copyright 2009 How to Gain Wealth. All rights reserved.

Credit Reporting and Repair for Domestic Violence Survivors

Credit Score Secrets Revealed

CREDIT REPORTS WHAT EVERY CONSUMER SHOULD KNOW ABOUT MORTGAGE EQUITY P A R T N E R S

Understanding your Credit Score

Experian News. around the corner. In this issue. What s around the Legislative Corner! Special edition October 2004

Chapter 06. What is Consumer Credit? Chapter 6 Learning Objectives. Introduction to Consumer Credit

CREDIT REPORTING FOR A SMALL BUSINESS

Using Loan Prospector Merged Credit Report Options

Conference Center User Guide. Conference Center User Guide

Credit Reports Credit Scores. Understanding reports and scores Correcting errors Obtaining a free report

Processing FHA TOTAL and VA Mortgages

Business Funding Evaluation YOUR BUSINESS NAME

Lesson 6: Credit Reports and You Thought Your Report Card Was Important

Credit Reports. published by AAA Fair Credit Foundation

Credit Reporting. Commonly Asked Questions

Use and Misuse of Credit. Chapter 6. Advantages of Credit. What is Consumer Credit?

Prepared Statement of The Federal Trade Commission. Credit Scoring

Your credit score. What it is. What it means.

Identity Theft Red Flags Rule

Trans Union Credit Report Tutorial

Your Credit Report. Trade lines. The bulk of a credit report is dedicated to your history of handling credit. It includes:

PA HealthCare Credit Union. The Credit Clinic. The PA HealthCare Credit Union contributes to the financial success of our members.

How to read a CBCWeb Credit Report

Reviewing C Your Credit Report

Solving The Mystery of Credit Reports

Download and install dotnetfx1.0.exe first. Then, download and install NDP1.1sp1-KB X86.exe

Understanding Your Credit Score

Credit Scoring and Wealth

UNDERSTANDING YOUR CREDIT REPORT (Part 1) By Bill Taylor

Protecting Yourself from Identity Theft


Credit Histories & Credit Scores

LESSON 7 -- CREDIT REPORTS AND CREDIT SCORES

Topic 3 Credit Report

Understanding Your Credit Report

Your Credit Score score of at least 620 for approval and 760 for the best interest rate.

Financial payment profile Fair Isaac Corporation (FICO) 300 to 850 the higher, the better

Desktop Underwriter (DU) Troubleshooting. User Guide

Your Credit Score What It Means to You as a Prospective Home Buyer

Credit Reports & Credit Scores

Understanding Your MyVedaScore Rating. An overview of what your VedaScore Rating means to you

MISMO Version 3 Reference Model General Information Guide

How To Get A Credit Report From A Credit Card To A Credit Rating Card

Solving the Credit Puzzle. L G & W Federal Credit Union

Your Credit File Explained

Credco Instant Merge Credit Report

Tracking Your Credit History By Mark Schug

CREDIT SWEEPERS & ASSOCIATES LLC

FICO Scores. John Meeks Federal Deposit Insurance Corporation

Business Owner Profile - EVELYN ARPE. Identifying Information. Executive Summary. Legal Filings. ScorexPLUS SM score. Total legal filings: 4

TERM SHEET FOR THE UNSECURED BUSINESS LINE OF CREDIT

Credit Reports and Scores: Practices, Policies and Outcomes. National Consumer Law Center

NCUA LETTER TO CREDIT UNIONS

Understanding a Credit Report! April 21, New York City Department of Consumer Affairs. All rights reserved.

How To Understand Credit History

Credit Repair For Court Reporters. When Bad Dings Happen To Good People. By Julie Samford Realtime Ready. Julie Samford

Credit Scoring and Its Role In Lending A Guide for the Mortgage Professional

SUITE 12 TEL: (732) MAIN STREET FAX: (732)

Radian Mortgage Insurance

BUSINESS FINANCING APPLICATION

How to Build Credit for Your EIN That is Not Linked to Your SSN

Understanding the Use of Credit and Scores for Insurance Underwriting

Initial All Disclosures listed under the Client Obligations & Agreement on page 6 of the Client Retainer and Service Agreement;

Transcription:

XML Implementation Guide: Credit Reporting Version 2

Document Date Change List Jan 13 2002 o Original Version (Draft). Jan 28 2002 o Minor corrections to text. o Update with Version 2 Release Candidate 2 changes from Jan 16, 2002 Credit Work Group meeting in Nashville, TN. o Added Error Codes & Descriptions Chapter 4. o Added Chapter 5 Credit Status Response. Feb 14 2002 o Minor corrections to text. o Updated RMCR Request Example on page 2-14. Dec 26 2002 o Add section to Chapter 2 that lists the additional elements added to the AUS Loan Application structure for the use in the Credit Request. o Add section to Chapter 2 to describe request for update of Credit Inquiry data. o Add sections to Chapter 2 for new inquiry elements added in Version 2.1.1. o Update the Chapter 3 Credit Response with text regarding Borrower and Credit Request elements specifying that IDs from the request should be returned in the response. o Update Chapter 6 DTD Change List to include information about Version 2.1.1 changes. o Add Chapter 8 MISMO Credit Work Group Recommendation for the California Credit Report Freeze Law. Feb 11 2003 o Clarified text in the Required? block of the Credit Request sections for Credit Inquiry Element, Credit Liability Element and Credit Public Record Element. Aug 28 2003 o Update Chapters 2, 3 and 6 with Version 2.3 changes. o Update Chapter 3 section Manner of Payment (MOP) Codes to correct CreditRatingCodeType value in second sample credit report. Oct 02 2003 o Update Chapter 7 question What are the minimum elements required for a Merge credit report? to show that the BorrowerID attribute should be included. o Update Chapter 8 to include information about the Texas Credit Freeze Law and latest recommendations of the MISMO Credit Work Group. o Miscellaneous changes throughout document to clarify text. Oct 16 2003 o Update Chapter 1 to add section Repositories and Credit Bureaus Defined. o Update Chapter 4 Suggested Error Codes to include E061 and E062. Jan 17 2005 o Update Chapter 3 to correct CREDIT SUMMARY example to show proper element name. o Update Chapter 3 section on Manner of Payment Codes to clarify text and table. o Update Chapter 6 with Version 2.3.1 changes. Mar 29 2007 o Update Chapter 1 to add a MISMO MXCompliance Program section. Rename the Overview section to Files Included with the Data Standards Download. Updated list of example Credit Bureau names in the Repositories and Credit Bureaus Defined section. o o o o o o o o o o Update Chapter 2 Update Request section s sample XML to show the Instruction Comment Type attribute. Update Chapter 2 Credit Request Data section to add notes about requesting credit scores using score model names and score category types. Update Chapter 3 Prior Adverse Rating and Payment Pattern Data section to correct Months Delinquent range as 1-6 to match LDD. Update Chapter 3 Manner of Payment Codes section to add notes about how Experian classifies bankruptcies under codes 7 and 9. Update Chapter 3 to add an Including Code Values with Credit Comments section. Update Chapter 3 Credit Score Element section to add Valid Credit Score Values, Standard Credit Score Record, Expanded Credit Score Record, and Credit Score Record with an Exclusion Reason sub-sections. Update Chapter 3 Embedded File section to show additional Version 2.4 attributes. Update Chapter 6 with Version 2.4 changes. Update Chapter 7 to add FAQ regarding difference between Loan App Liability Type and Credit Loan Type. Add Chapter 9 Credit Report Reissue Reporting.

Document Date Change List Nov 19 2007 o Update Chapter 2 Credit Request Data section to update Reissue Request info and add Force New Request and Secondary Use Notification Request info. o Update Chapter 2 to add Embedded File Element section. o Update Chapter 3 Credit Bureau Element section to add FNM Credit Bureau Identifier attribute info. o Update Chapter 3 to add Alert Message Element section. o Update Chapter 4 Error Code table to add E038 Invalid Login or Password. o Update Chapter 6 with Version 2.4.1.1 changes. o Update Chapter 9 with multiple changes, including addition of Using a KEY element for Specifying a Billing Instruction section. Aug 22 2010 o Added Chapter 10 : Risk Based Pricing Disclosures

Table of Contents XML Implementation Guide: Credit Reporting Version 2 Document Revision Date: August 22, 2010 Copyright 2007 - Mortgage Industry Standards Maintenance Organization (MISMO). All rights reserved Permission to use, copy, modify, and distribute the MISMO DTD and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies. The copyright holders make no representation about the suitability of the DTD or documentation for any purpose. TABLE OF CONTENTS CHAPTER 1: INTRODUCTION... 1-1 PURPOSE OF THIS DOCUMENT... 1-1 MISMO MXCOMPLIANCE PROGRAM... 1-1 TRANSITIONING FROM EARLIER STANDARDS VERSIONS... 1-2 WHAT ELSE YOU WILL NEED... 1-2 FILES INCLUDED WITH THE DATA STANDARDS DOWNLOAD... 1-2 THE MISMO TRANSACTION ENVELOPE... 1-3 REPOSITORIES AND CREDIT BUREAUS DEFINED... 1-3 Repositories... 1-3 Credit Bureau... 1-3 CHAPTER 2: CREDIT REQUEST SECTION BY SECTION... 2-1 CREDIT REQUEST ELEMENT... 2-2 CREDIT REQUEST Attributes... 2-2 CREDIT REQUEST Element Usage... 2-3 CREDIT REQUEST DATA ELEMENT... 2-4 Typical Merge Request Options... 2-5 Force New Request Option... 2-5 Selecting Number of Repositories to Be Requested... 2-6 Reissue Request... 2-6 Secondary Use Notification Request... 2-6 Retrieve Request... 2-7 Upgrade to RMCR Request... 2-7 Update Request... 2-8 Requesting Credit for Multiple Borrowers on a Loan... 2-10 Requesting Credit Scores... 2-11 Checking on the Status of a Request... 2-12 DATA INFORMATION ELEMENT... 2-13 SERVICE PAYMENT ELEMENT... 2-14 CREDIT INQUIRY ELEMENT... 2-15 CREDIT LIABILITY ELEMENT... 2-16 CREDIT PUBLIC RECORD ELEMENT... 2-17 LOAN APPLICATION... 2-18 Borrower Data Used in a Merge or Score Only Request... 2-18 Borrower Data Used in an RMCR Request... 2-19 Page i

Table of Contents Loan Application Additions for the 2.x Credit Request... 2-21 EMBEDDED FILE ELEMENT... 2-23 CHAPTER 3: CREDIT RESPONSE SECTION BY SECTION... 3-1 CREDIT RESPONSE ELEMENT... 3-2 CREDIT RESPONSE Attributes... 3-3 CREDIT RESPONSE Element Usage... 3-5 DATA INFORMATION ELEMENT... 3-6 CREDIT BUREAU ELEMENT... 3-7 CREDIT REPORT PRICE ELEMENT... 3-8 CREDIT REPOSITORY INCLUDED ELEMENT... 3-9 REQUESTING PARTY ELEMENT... 3-10 CREDIT REQUEST DATA ELEMENT... 3-11 CREDIT ERROR MESSAGE ELEMENT... 3-12 BORROWER ELEMENT... 3-13 CREDIT LIABILITY ELEMENT... 3-14 CREDIT LIABILITY and UNMERGED LIABILITY Data... 3-15 Prior Adverse Rating and Payment Pattern Data... 3-16 Manner Of Payment (MOP) Codes... 3-17 Credit Liability Late Count and Periodic Late Count... 3-20 Including Code Values with Credit Comments... 3-20 CREDIT PUBLIC RECORD ELEMENT... 3-23 CREDIT INQUIRY ELEMENT... 3-24 CREDIT FILE ELEMENT... 3-25 CREDIT SCORE ELEMENT... 3-27 Valid Credit Score Values... 3-27 Standard Credit Score Record Versions 2.1-2.3.1... 3-27 Expanded Credit Score Record Version 2.4 & Later... 3-28 Credit Score Record with an Exclusion Reason... 3-30 CREDIT TRADE REFERENCE ELEMENT... 3-31 CREDIT COMMENT ELEMENT... 3-32 CREDIT CONSUMER REFERRAL ELEMENT... 3-33 CREDIT SUMMARY ELEMENT... 3-34 REGULATORY PRODUCT ELEMENT... 3-35 EMBEDDED FILE ELEMENT... 3-36 Before Version 2.4... 3-36 Version 2.4 and Later... 3-37 ALERT MESSAGE ELEMENT... 3-38 CHAPTER 4: CREDIT ERROR RESPONSE... 4-1 CHAPTER 5: CREDIT STATUS RESPONSE... 5-1 CHAPTER 6: CREDIT REPORTING DTD CHANGE LIST... 6-1 VERSION 2.1.1... 6-1 VERSION 2.3... 6-4 VERSION 2.3.1... 6-7 VERSION 2.4... 6-10 VERSION 2.4.1.1... 6-17 CHAPTER 7: QUESTIONS AND ANSWERS... 7-1 WHAT ARE THE MINIMUM ELEMENTS REQUIRED FOR A MERGE CREDIT REPORT?... 7-1 WHAT IS THE MISMO XML EQUIVALENT TO THE X12 RATING REMARKS?... 7-2 WHICH CREDIT RESPONSE ELEMENTS INDICATE THAT A REQUEST TO A CREDIT REPOSITORY FAILED?... 7-2 WHERE IS THE WHOSE FILE FLAG FOR LIABILITIES, PUBLIC RECORDS, ETC.?... 7-3 WHY IS THE LIST OF LOAN APP LIABILITY TYPES DIFFERENT FROM THE LOAN TYPES USED IN THE CREDIT RESPONSE?... 7-4 Page ii

Table of Contents CHAPTER 8: CREDIT REPORT FREEZE LAWS RECOMMENDATION... 8-1 BACKGROUND... 8-1 California... 8-1 Texas... 8-2 MISMO Credit Work Group Recommendations... 8-2 RECOMMENDATION MISMO XML FORMATS... 8-3 Key Names for California PIN values... 8-3 Key Names for Other State s PIN values... 8-3 CHAPTER 9: REISSUE / SECONDARY USE REPORTING... 9-1 BACKGROUND... 9-1 Repositories and Credit Bureaus Defined... 9-2 Reissue Reporting Overview... 9-2 MISMO SUPPORT FOR IDENTIFYING ADDITIONAL END-USERS... 9-4 Submit Credit Request... 9-4 Reissue Credit Request... 9-4 Secondary Use Notification Credit Request... 9-4 Credentials & Authentication... 9-4 Backward Compatibility... 9-5 KEY Element Using Internal Account Identifier... 9-5 KEY Element Using Login Account Identifier / Password... 9-6 Using a KEY Element for Specifying a Billing Instruction... 9-6 USING MISMO REQUESTS FOR REISSUES AND SECONDARY USE NOTIFICATIONS... 9-9 Request a Previously Prepared Credit Report for One or More Additional End-Users... 9-9 Request a New Credit Report and Simultaneously Provide It to One or More Additional End-Users... 9-11 Send a Secondary Use Notification Request to a Credit Bureau... 9-12 Setting Secondary Use Notification Action Type for Various MISMO Versions... 9-14 REPORTING ADDITIONAL END-USER AUTHENTICATION ERRORS... 9-15 CHAPTER 10: RISK BASED PRICING DISCLOSURE RECOMMENDATION... 10-1 BACKGROUND... 10-1 Repositories and Credit Bureaus Defined... 10-1 Risk Based Pricing Overview... 10-2 MISMO SUPPORT FOR RISK BASED PRICING... 10-2 KEY Element for Credit Score Ranking... 10-2 KEY Element for Credit Score Range... 10-2 KEY Element for Histogram Information... 10-3 EMBEDDED File for Histogram Graphic... 10-4 EMBEDDED File for Risk Based Disclosure Letter... 10-5 Page iii

Introduction Chapter 1: Introduction Purpose of this Document This document is designed to assist individuals who are implementing the MISMO XML Credit Reporting standards for both credit request transaction and for the credit response transaction. The guide covers the credit request and credit response section by section. Numerous examples with sample XML credit data are provided throughout the guide, along with detailed explanations. Not all of the credit data elements attributes will be discussed in detail in this guide. See the Credit Reporting LDD (Logical Data Dictionary) for definitions of the data attributes not covered in this section. Version and Release This implementation guide is based on versions 2.1, 2.1.1, 2.3, 2.4 and 2.4.1.1 of the MISMO standard. The MISMO Logical Data Dictionary (LDD), and Document Type Definitions (DTDs), sample files and implementation guides can be downloaded from the www.mismo.org web site. Comments Comments, questions, and suggestions for improvement of this document may be submitted directly to either of the Credit Reporting Work Group Co-Chairs. Mike Bixby LandAmerica Credit Services [MBixby@LandAm.com] Paul Wills Equifax Mortgage Services [Paul.Wills@Equifax.com] MISMO MXCompliance Program To protect the investments of the lender and vendor community who participate in developing and implementing standards-based solutions, the Mortgage Industry Standard Maintenance Organization (MISMO) established a voluntary compliance service, known as MXCompliance. Defining compliance objectively and providing marks of compliance to those organizations that meet the testing standards will provide assurance to providers and purchasers that the interfaces marked as MXCompliant are truly mapped to and supportive of the standards as published on the MISMO web site, and thus provide for maximum reuse from trading partner to trading partner. More information about the program is on the MISMO MXCompliance web site at: http://mxcompliance.mismo.org/. Page 1-1

Introduction Transitioning from Earlier Standards Versions If you have implemented earlier standards versions, you may find it helpful to review the Change List documents included with each release of the standard. The document is part of the Credit Reporting DTD package when you download it from the MISMO web site. It contains a list of changes implemented since the previous version. What Else You Will Need This guide covers aspects of the MISMO standard that are specific to credit reporting. To fully implement the standard, MISMO provides other files that can be downloaded from the MISMO web site (http://www.mismo.org). o MISMO XML Implementation Guide: General Information Version 2 This guide covers the MISMO architecture, a general discussion of types of MISMO elements and attributes, plus an overview of the MISMO Transaction Envelope. o Credit DTD Files The Document Type Definition (DTD) files define the structure of each of the process area data sets. These files are utilized to develop, write and read XML data files. o Credit LDD File Each mortgage process area also provides a Logical Data Dictionary (LDD), which defines each data element and attribute used in the DTD. o Sample XML Credit Files These can also be downloaded from the MISMO web site. Files Included with the Data Standards Download Three separate Credit Reporting DTDs are provided in the MISMO Version 2 of the XML mortgage standards: CREDIT_REQUEST_v2_x.dtd used to request any type of credit reporting product. This DTD included the AUS 2.x Loan Application in its entirety, to allow for easy implementation by those who are already supporting the AUS (Automated Underwriting System) standard. CREDIT_REQUEST_v2_x_MergeOnlydtd used only to request Merge credit reports. Only the basic borrower information is supported, such as borrower name, SSN, date of birth and address. This DTD is a subset of the CREDIT_REQUEST_v2_x.dtd. XML request files created using the Merge Only DTD will also validate against the full CREDIT_REQUEST_v2_x.dtd file. Page 1-2

Introduction CREDIT_RESPONSE_v2_x.dtd used to generate any type of credit response such as Merge, Merge Plus, RMCR (Residential Mortgage Credit Report), error reports and others. XSD Schema Files - are included with Versions 2.4 and later. Some XML software uses XSD Schema files for the data definitions, rather than DTDs. These files are provided as an alternative to DTDs but are equivalent to the DTDs. The MISMO Transaction Envelope MISMO has developed a set of Transaction Envelope DTDs that can be used to wrap the credit request and credit response transaction data. The MISMO Transaction Envelope DTDs are fully incorporated within the Credit Reporting DTDs. The Transaction Envelope elements and attributes cover the basic information common to most transactions elements that identify the requesting party, receiving party, responding party and other reference data that is commonly exchanged between business partners. The envelope transaction elements and attributes will not be covered in this document. The MISMO XML Implementation Guide: General Information Version 2 describes the MISMO Transaction Envelope in detail. Repositories and Credit Bureaus Defined Before getting into the details of the credit request and credit response transactions, it s probably a good idea to identify and define two of the parties involved in the production of the credit report. Repositories The credit data repositories are the companies that collect and store that credit data on individuals. Equifax, Experian SM and Trans Union are the three primary repositories for credit data. Credit Bureau The credit bureau is the agency that creates the credit report for the lender. They are also sometimes referred to as the credit reporting agency (CRA), or sometimes as the credit vendor. For consistency, in this document and the MISMO DTD and LDD files, we will always use the term credit bureau. Page 1-3

Introduction Advantage Credit, Equifax Mortgage Services, Fiserv CredStar, First American Credco, Kroll Factual Data, LandSafe Credit Services, LandAmerica Credit Services and LSI Credit Services are examples of credit bureaus. When a credit request is received by a credit bureau, the credit bureau then requests the raw credit data from one or more of the repositories. The credit bureau then processes and formats the credit data into a final credit report, which is returned to the lender. Page 1-4

Credit Request Section By Section Chapter 2: Credit Request Section By Section This section of the manual provides general information about each section of a credit report request. Below is a sample credit request file. The outlined area of the sample, beginning the CREDIT REQUEST element, is the portion of the standard that is covered in this section of the guide. Sample XML Credit Request (with MISMO Request Envelope) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE REQUEST_GROUP SYSTEM "CreditRequest_v2_1.dtd"> <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="MFC Mortgage" _StreetAddress="21650 Oxnard Street" _City="Woodland Hills" _State="CA" _PostalCode="91364"/> <RECEIVING_PARTY _Name="ABC Services" _StreetAddress="7200 Peachtree Street" _City="Atlanta" _State="GA" _PostalCode="30010"/> <REQUEST RequestDatetime="2002-01-08T17:19:01" InternalAccountIdentifier="ABC-0732"> <KEY _Name="MFC Transaction ID" _Value="702430023"/> <KEY _Name="MFC Portfolio ID" _Value="MFC2002-0030"/> <REQUEST_DATA> <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _UnparsedName="MARION C BRICK"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Page 2-1

Credit Request Section By Section CREDIT REQUEST Element The DTD segment below shows the major component elements of the CREDIT REQUEST element. Normally, the only two major components used are the CREDIT REQUEST DATA element and the LOAN APPLICATION element. The CREDIT INQUIRY, CREDIT LIABILITY and CREDIT PUBLIC RECORD elements are only used when ordering an Update to a liability or public record that appeared in a previous credit report. The DATA INFORMATION element records information about the software version that produced the credit request. (DATA INFORMATION is only available in Version 2.3 and later.) The SERVICE PAYMENT element is used to collect payment data such as credit card data for online consumer reports. (SERVICE PAYMENT is only available in Version 2.1.1 and later.) The EMBEDDED_FILE element is used to send borrower authorizations or loan applications that may be in a PDF, TIFF or HTML format. (EMBEDDED_FILE is only available in Version 2.4.1.1 and later.) An asterisk (*) appearing after an element indicates that it is optional, and it can be used in an XML file more than one time. A question mark (?) after an element indicates that it is optional, but it can only be used once in an XML file. Major CREDIT REQUEST Elements from DTD <!ELEMENT CREDIT_REQUEST( CREDIT_REQUEST_DATA*, _DATA_INFORMATION*, NEW: Ver 2.3 SERVICE_PAYMENT*, NEW: Ver 2.1.1 CREDIT_INQUIRY*, CREDIT_LIABILITY*, CREDIT_PUBLIC_RECORD*, LOAN_APPLICATION?, EMBEDDED_FILE*)> NEW: Ver 2.4.1.1 CREDIT REQUEST Attributes The CREDIT REQUEST element has several attributes worth mentioning here because of their importance. CREDIT REQUEST Element with Attributes <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R">... Other CREDIT REQUEST elements and attributes go here... </CREDIT_REQUEST> Page 2-2

Credit Request Section By Section MISMO Version ID identifies which version of the DTD this section of the data conforms to. This attribute is required. Lender Case Identifier the lender enters the loan number, reference number, or case number related to this credit request. This reference number will normally appear on the human readable version of the credit report. This attribute is required by most credit bureaus. Requesting Party Requested By Name the name of the person actually requesting the credit report. In the future, if the borrower ever asks why a credit report was requested, this data attribute will provide the name of the person who authorized pulling the borrower s credit data. This attribute is required by most credit bureaus. CREDIT REQUEST Element Usage The remainder of this chapter gives a brief overview of each section of a credit request. The Credit Request DTDs do not control the usage of the individual data elements that comprise the credit request. This document provides guidance for how and when to use the data elements. One of the categories of information provided for each section is Usage. YES indicates that a data element is generally used for a particular credit request type, and NO indicates that the data element is generally not used for that credit request type. The most commonly used types of credit requests are: Merge A merge report (also called merged infile) includes data on file from the selected credit data repositories. RMCR Residential Mortgage Credit Report is an enhanced credit product that contains verified information and/or additional investigation. Score Only Provides credit risk scores only. Other categories provided for each element are Required? describes whether or not the data element is required, Purpose a short summary describing what the data element is used for. The final category, Restrictions lists any DTD or Version restrictions for the data element. Examples: Not available in Merge-Only DTD. Available only for Version 2.1.1 and later. Page 2-3

Credit Request Section By Section CREDIT REQUEST DATA Element Usage: Merge = YES RMCR = YES Score Only = YES Required? Normally appears in all requests, but this element may not required by a credit vendor if credit request parameters are always the same for a customer, and they are on file with the credit bureau processing the request. Purpose: Specifies the credit report type requested, the action requested, credit repositories requested and other request parameters. Multiple CREDIT REQUEST DATA elements can appear in a CREDIT REQUEST element one for each credit report being requested. Restrictions: None. Sample CREDIT REQUEST DATA Element <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> <CREDIT_SCORE_MODEL_NAME _Type="EquifaxBeacon5.0"/> <CREDIT_SCORE_MODEL_NAME _Type="ExperianFairIsaac"/> <CREDIT_SCORE_MODEL_NAME _Type="TransUnionEmpirica"/> </CREDIT_REQUEST_DATA> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _UnparsedName="MARION C BRICK"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-4

Credit Request Section By Section Typical Merge Request Options The most common type of report in use today in the mortgage industry, is the three-repository Merge file. To submit a new request, the Credit Report Request Action Type is set to Submit, and the Credit Report Type is set to Merge. If you are ordering a combined credit report for a borrower / spouse pair, set the Credit Request Type to Joint, otherwise set the attribute s value to Individual. The CREDIT REPOSITORY INCLUDED element is used to identify which repository bureaus should be included in the request. In the sample below, all three repositories Equifax, Experian and Trans Union are being requested. Of course, if you did not want to request data from all of the repositories you would set the attribute value of the ones you didn t want to N (No). Sample CREDIT REQUEST DATA Three Repository Merge <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> Force New Request Option When the Credit Report Request Action Type is set to Submit, as in the above example, the Credit Bureau will normally first determine if a recent copy of that credit report data already exists on their system. Beginning with Version 2.4.1.1 and later, when the Credit Report Request Action Type is set to Force New, the Credit Bureau will request new credit data from the repository bureaus. This option is normally used only when credit data has been recently corrected or updated, and the requestor wants to force new data to be requested. Verify that your Credit Bureau supports this option before using it.. Sample CREDIT REQUEST DATA Force New Request <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="ForceNew" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> Page 2-5

Credit Request Section By Section Selecting Number of Repositories to Be Requested The previous example showed a request with specific repository bureaus being selected. It is also possible to just choose the number of repositories to be requested, and let the credit bureau choose the specific repository bureaus based on a zip-code table or some other method agreed upon by the credit trading partners. Sample CREDIT REQUEST DATA Repositories Selected Count <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRepositoriesSelectedCount= 2 CreditRequestType="Individual"/> Reissue Request To request that the credit bureau re-send you an existing report, you normally need to send the original credit report number in the Credit Report Identifier attribute and set the Credit Report Request Action Type to Reissue. One of the common uses of a Reissue Request is where a lender requests that a Credit Report reissue a credit report that was originally ordered by a mortgage broker. See Chapter 9 of this document for more detailed information on reissues and secondary use notifications. Sample Reissue Credit Request <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Reissue" CreditReportType="Merge" CreditReportIdentifier= 02-0027388 CreditRequestType="Individual"/> Secondary Use Notification Request In some business scenarios, the entity that ordered the original credit report, may have forwarded a copy of the credit report to another entity that has a permissible purpose to view or use the credit report data. In this case, there may be a requirement to notify the Credit Bureau about the secondary use of the original credit report, but it is not necessary for the Credit Bureau to send another copy of the credit report. In Version 2.4.1.1 and later, this notification can be accomplished by setting the Credit Report Request Action Type to Secondary Use Notification. See Chapter 9 of this document for more detailed information on secondary use notifications, plus how to format them for MISMO credit requests earlier than Version 2.4.1.1. Page 2-6

Credit Request Section By Section Sample Secondary Use Notification Credit Request <REQUEST_GROUP MISMOVersionID="2.4.1.1"> <REQUESTING_PARTY _Name="Lender"/> <RECEIVING_PARTY _Name="Credit Bureau"/> <REQUEST InternalAccountIdentifier="Lndr001"> <KEY _Name="Additional End-User (1) Name" _Value="Mortgage Insurer"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="MtgIns001"/> <REQUEST_DATA> <CREDIT_REQUEST> <CREDIT_REQUEST_DATA CreditReportIdentifier="07031113" CreditRequestActionType="SecondaryUseNotification"/> </CREDIT_REQUEST>... LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Retrieve Request In Version 2.1.1 and later, to request the delivery of an updated, upgraded or completed report, set the Credit Report Request Action Type to Retrieve and set the original credit report number in the Credit Report Identifier attribute. Sample Retrieve Credit Request <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" CreditRequestDateTime="2002-08-08T17:19:01" CreditReportIdentifier="14-0022558" CreditReportRequestActionType="Retrieve" CreditReportType="RMCR"/> Upgrade to RMCR Request Commonly a mortgage broker will order a one, two or three repository Merge file to see if the loan applicant qualifies for the loan. Depending on the result, the broker may then request that the Merge report be upgraded to a RMCR (Residential Mortgage Credit Report). To request such an upgrade, the Credit Report Request Action Type is set to Upgrade, the Credit Report Type is set to RMCR and the credit report number of the original credit report is entered in the Credit Report Identifier attribute. Sample Upgrade to RMCR Credit Request <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" CreditRequestDateTime="2002-01-09T10:58:43" CreditReportRequestActionType="Upgrade" CreditReportType="RMCR" CreditReportIdentifier= 02-0027388 CreditRequestType="Individual"/> Page 2-7

Credit Request Section By Section Update Request After a lender receives and reviews the credit report, sometimes there is a need to have the credit bureau update incorrect or outdated information on the initial credit report. For example, the borrower may advise the lender that his Sears account, which had shown a $250 past due balance, has now been paid in full and the account is closed. Credit request transactions created with the CREDIT_REQUEST_v2_x.dtd allow liability and public record element data from the original credit response transaction to be transmitted back to the credit bureau to be updated. After the credit bureau verifies the new information and has the correction made at the repositories, an updated version of the credit report is returned to the lender. To request a credit report update, the Credit Report Request Action Type is set to Update and the credit report number of the original credit report is entered in the Credit Report Identifier attribute. Any CREDIT LIABILITY or CREDIT PUBLIC RECORD element from the original report should also be included, along with a CREDIT COMMENT that identifies what information needs updating. Version 2.1.1 and later of the Credit Request DTD also supports sending CREDIT INQUIRY elements for updating. This may be useful to a lender that wants to know, for example, if a recent credit inquiry by GMAC resulted in a new loan debt that was not reported by the borrower. Version 2.3 and later of the Credit Request DTD also supports a new _Type attribute for the CREDIT COMMENT element. For Update requests, this attribute should be set to Instruction. NOTE: The CreditRequest-MergeOnly_v2_x.dtd does not have any of the CREDIT LIABILITY, CREDIT PUBLIC RECORD or CREDIT INQUIRY elements used in Update requests. If you plan to use the Update request, you will need to implement the CreditRequest_v2_x.dtd. A sample Update request is shown on the following page that asks the credit bureau to verify the balance and account status on a Sears liability and whether or not a loan was issued by GMAC. The liability and inquiry records from the original credit report are included along with a comment giving the credit bureau instructions for each item. Since the Update request includes a CREDIT INQUIRY element, Version 2.1.1 is used. Page 2-8

Credit Request Section By Section Sample Update Credit Request <CREDIT_REQUEST MISMOVersionID="2.3" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="ssn555336666" CreditRequestDateTime="2003-08-08T13:29:41" CreditReportIdentifier="14-0022558" CreditReportRequestActionType="Update" CreditReportType="MergePlus" CreditRequestType="Individual"> </CREDIT_REQUEST_DATA> <CREDIT_INQUIRY CreditInquiryID="CRInq0007" BorrowerID="ssn555336666" _Name="GMAC" _Date="2003-07-10" CreditBusinessType="Finance" CreditLoanType="AutoLoan"/> <CREDIT_COMMENT _SourceType="Lender" _Type="Instruction"> <_Text>PLEASE VERIFY WHETHER CREDIT WAS ISSUED</_Text> </CREDIT_COMMENT> </CREDIT_INQUIRY> <CREDIT_LIABILITY CreditLiabilityID="CRLiab0034" BorrowerID="ssn555336666" _AccountIdentifier="1743911111" _AccountOpenedDate="1999-12" _AccountOwnershipType="Individual" _AccountReportedDate="2003-06" _AccountStatusType="Open" _PastDueAmount="75" _UnpaidBalanceAmount="220" CreditLoanType="CreditCard"> <_CREDITOR _Name="SEARS"/> <_CURRENT_RATING _Code="2" _Type="Late30Days"/> <CREDIT_COMMENT _SourceType="Lender" _Type="Instruction"> <_Text>Borrower says Account is paid/closed</_text> <_Text>PLEASE VERIFY ZERO BALANCE/STATUS</_Text> </CREDIT_COMMENT> </CREDIT_LIABILITY> <LOAN_APPLICATION> <BORROWER BorrowerID="ssn555336666" _BirthDate="1978-09-01" _FirstName="JEAN" _LastName="LAPHROIG" _SSN="555336666"/> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-9

Credit Request Section By Section Requesting Credit for Multiple Borrowers on a Loan Most loans involve a single borrower or a borrower / spouse pair. For mortgage loans, however it is not uncommon to have additional borrowers on the loan. When requesting credit reports for a loan with multiple sets of borrowers, there needs to be a separate CREDIT REQUEST DATA element for each borrower data set. A Joint credit request may include a borrower / spouse pair; otherwise, it is an Individual credit request. A separate credit response will be returned for each CREDIT REQUEST DATA element present in the request. The next sample file includes three borrower sets one married couple, John Doe Jr. and Jane Doe, and two single unmarried relatives, John Doe Sr. and Henry Block. The married couple is referenced in one CREDIT REQUEST DATA element. Each of the unmarried relatives has their own CREDIT REQUEST DATA element, for a total of three credit requests. The Borrower ID attributes are used to link each CREDIT REQUEST DATA element to specific BORROWER elements. Sample Credit Request Multiple Borrower Sets <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001 BorRec0002" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y"/> </CREDIT_REQUEST_DATA> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0002" BorrowerID="BorRec0003" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y"/> </CREDIT_REQUEST_DATA> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0003" BorrowerID="BorRec0004" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y"/> </CREDIT_REQUEST_DATA> Page 2-10

Credit Request Section By Section <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _SSN= 123457001 _FirstName="John" _LastName="Doe" _NameSuffix="JR"> </BORROWER> <BORROWER BorrowerID="BorRec0002" _SSN= 123457002 _FirstName="Jane" _LastName="Doe"> </BORROWER> <BORROWER BorrowerID="BorRec0003" _SSN= 123457003 _FirstName="John" _LastName="Doe" _NameSuffix="SR"> </BORROWER> <BORROWER BorrowerID="BorRec0004" _SSN= 123456001 _FirstName="Henry" _LastName="Block"> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Requesting Credit Scores Many lenders and other parties requesting a credit report are setup to automatically receive one or more credit scores with each credit report. The CREDIT REQUEST DATA element allows the inclusion of one or more CREDIT SCORE MODEL NAME elements, which can be used to specify one or more score models on a report-by-report basis. There are three methods for requesting specific score models on an individual report. Check with your credit bureau to see which one(s) they support: 1. No action is required if your credit bureau has setup default scores to order for each of your credit requests. In this situation is it not necessary to add CREDIT SCORE MODEL NAME elements to your request. 2. The second method is to specify the exact Credit Score Model Name Type - for example; Equifax Beacon 5.0, Experian Fair Isaac or Trans Union Empirica. In this example, credit reports are being ordered from all three repositories and in addition, three score models are being requested using the repository bureau s product name. Sample Credit Score Request Using Credit Score Model Name Type <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2007-01-18T09:29:47" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> <CREDIT_SCORE_MODEL_NAME _Type="EquifaxBeacon5.0"/> <CREDIT_SCORE_MODEL_NAME _Type="ExperianFairIsaac"/> <CREDIT_SCORE_MODEL_NAME _Type="TransUnionEmpirica"/> </CREDIT_REQUEST_DATA> Page 2-11

Credit Request Section By Section 3. Beginning with Version 2.4, score models can also be requested by specifying the Credit Score Category Type. This allows a lender to order a score model from the repository bureau without having to know each repository bureau s product name for the score model. In this example, credit reports are being ordered from Equifax and Trans Union and FICO category score models are being requested from those two repositories. When the credit bureau received the credit request, they will order the appropriate repository bureau score model name that matches the specified score category type. Sample Credit Score Request Using Credit Score Category Type <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2007-01-18T09:29:47" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _TransUnionIndicator="Y"/> <CREDIT_SCORE_MODEL_NAME CreditScoreCategoryType="FICO"/> </CREDIT_REQUEST_DATA> Checking on the Status of a Request Since an RMCR (Residential Mortgage Credit Report) is manually investigated, it is not returned immediately like a Merge report. Some credit bureaus will allow you to send an electronic Status Query transaction to check on the status of RMCR requests. To create a status query, the Requested Action Type is set to Status Query, and the credit report number (if known) is entered in the Credit Report Identifier attribute. Sample Status Query Credit Request <CREDIT_REQUEST_DATA CreditReportRequestActionType="StatusQuery" CreditReportType="RMCR" CreditReportIdentifier= 02-0027388 /> For information on how the credit bureau may respond to a Status Query using the MISMO Version 2 Credit Response, see Chapter 5: Credit Status Response in this document. Page 2-12

Credit Request Section By Section DATA INFORMATION Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: This data structure is available to record the source data versions used to produce the MISMO XML transactions. This information may be useful for troubleshooting problems in production. Restrictions: Available only for Version 2.3 and later. Sample Credit Request with DATA INFORMATION Element <CREDIT_REQUEST MISMOVersionID="2.3" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <_DATA_INFORMATION> <DATA_VERSION _Name="BEST-LOS" _Number="5.0"/> </_DATA_INFORMATION> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="Bor001" CreditRequestDateTime="2003-01-03T13:21:58" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _UnparsedName="MARION C BRICK"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-13

Credit Request Section By Section SERVICE PAYMENT Element Usage: Merge = YES RMCR = YES Score Only = YES Required? Only if needed for billing of a service. Purpose: This data structure is available in the CREDIT REQUEST element to facilitate billing of online consumer reports using a credit card or other payment method. Restrictions: Available only for Version 2.1.1 and later. Sample Credit Request with SERVICE PAYMENT Data <CREDIT_REQUEST MISMOVersionID="2.1.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-08-13T13:21:42" CreditReportRequestActionType="Submit" CreditReportType="MergePlus"/> <SERVICE_PAYMENT _AccountIdentifier="5432200232559994" _AccountHolderName="MARION C BRICK" _AccountHolderTelephoneNumber="4893440338" _AccountExpirationDate="2005-04" _SecondaryAccountIdentifier="6425" _MethodType="MasterCard"/> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" > <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103" BorrowerResidencyDurationYears="2" MonthlyRentAmount="1500"> </_RESIDENCE> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-14

Credit Request Section By Section CREDIT INQUIRY Element Usage: Required? Purpose: Merge = YES RMCR = YES Score Only = NO Only used when requesting an Update to an inquiry record by the credit bureau. This element is used to return the original copy of a Version 2.x CREDIT INQUIRY element from a previous Credit Response transaction, for the current status of the earlier inquiry. Restrictions: Available only for Version 2.1.1 and later. Not available in Merge-Only DTD.. Requesting Updates to Inquiry Data The Version 2.1.1 Credit Request supports ordering of updates to inquiry data on a previously ordered credit report. To order an update, set the Request Action Type to Update and include one or more CREDIT INQUIRY elements from the original credit report that should be updated. Notice the CREDIT COMMENT element has instructions to the credit bureau from the lender. Sample Credit Request for update of CREDIT INQUIRY Data <CREDIT_REQUEST MISMOVersionID="2.1.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-08-28T14:23:27" CreditReportRequestActionType="Update" CreditRequestType="Individual"> </CREDIT_REQUEST_DATA> <CREDIT_INQUIRY CreditInquiryID="CRInq0001" BorrowerID="BorRec0001" _Name="MONEY STORE" _Date="2002-07-25" CreditBusinessType="Finance" CreditLoanType="HomeEquityLineOfCredit"/> <CREDIT_COMMENT _SourceType="Lender"> <_Text>PLEASE VERIFY WHETHER CREDIT WAS ISSUED</_Text> </CREDIT_COMMENT> </CREDIT_INQUIRY> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" > </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-15

Credit Request Section By Section CREDIT LIABILITY Element Usage: Merge = YES RMCR = YES Score Only = NO Required? Only used when requesting an Update to a liability record by the credit bureau. Purpose: This element is used to return the original copy of a Version 2.x CREDIT LIABILITY element from a previous Credit Response transaction, for re-verification of a balance or some other type of update. Restrictions: Not available in Merge-Only DTD. Requesting Updates to Liability Data The Version 2.x Credit Request supports ordering of updates to liability data delivered on a previously ordered credit report. To order an update, set the Request Action Type to Update and include one or more CREDIT LIABILITY elements from the original credit report that should be updated. The CREDIT COMMENT element has instructions to the credit bureau from the lender. Sample Credit Request for update of CREDIT LIABILITY Data <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Update" CreditReportType="Merge" CreditRequestType="Individual"> </CREDIT_REQUEST_DATA> <CREDIT_LIABILITY CreditLiabilityID="CRLiab0001" BorrowerID="BorRec0001" _AccountIdentifier="1743911111" _AccountOpenedDate="1998-06" _AccountOwnershipType="Individual" _AccountReportedDate="2001-12" _TermsDescription="$70/MO" _UnpaidBalanceAmount="420" CreditLoanType="InstallmentSalesContract"> <_CREDITOR _Name="AFFILIATED ACCEP CORP"/> <_CURRENT_RATING _Code="1" _Type="AsAgreed"/> <CREDIT_COMMENT _SourceType="Lender" _Code= 01 > <_Text>Borrower Says Account Now Paid</_Text> <_Text>PLEASE VERIFY ZERO BALANCE</_Text> </CREDIT_COMMENT> </CREDIT_LIABILITY> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" > </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-16

Credit Request Section By Section CREDIT PUBLIC RECORD Element Usage: Merge = YES RMCR = YES Score Only = NO Required? Only used when requesting an Update to a public record by the credit bureau. Purpose: This element is used to return the original copy of a Version 2.x CREDIT PUBLIC RECORD element from a previous Credit Response transaction, for re-verification of a case disposition or some other type of update. Restrictions: Not available in Merge-Only DTD. Requesting Updates to Public Record Data The Version 2.x Credit Request supports ordering of updates to public record data delivered on a previously ordered credit report. To order an update, set the Request Action Type to Update and include one or more CREDIT PUBLIC RECORD elements from the original credit report that should be updated. Notice the CREDIT COMMENT element has instructions to the credit bureau from the lender. Sample Credit Request for update of CREDIT PUBLIC RECORD <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Update" CreditReportType="Merge" CreditRequestType="Individual"> </CREDIT_REQUEST_DATA> <CREDIT_PUBLIC_RECORD CreditPublicRecordID="CRPubR0001" BorrowerID="BorRec0001" _DispositionDate="2001-10" _DispositionType="Unsatisfied" _DocketIdentifier="99-044444" _FiledDate="1999-01" _LegalObligationAmount="512" _PlaintiffName="COLLECTION, CBCMERCY AMB, COLL" _Type="Judgment"> <CREDIT_COMMENT _SourceType="Lender" _Code= 22 > <_Text>Borrower Says Judgment Now Paid</_Text> <_Text>PLEASE VERIFY JUDGMENT IS SATISFIED</_Text> </CREDIT_COMMENT> </CREDIT_PUBLIC_RECORD> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" > </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-17

Credit Request Section By Section LOAN APPLICATION Usage: Merge = YES RMCR = YES Score Only = YES Required? Yes. Purpose: Provides borrower-identifying data required for a credit request transaction. Borrower data for a Merge or Score Only Request includes the full name, plus current and recent previous Residence Addresses. For RMCR Requests, the Loan Application element may also include, Alias/AKA data, Assets and Liabilities, Declarations, Employment and Landlord data. Restrictions: None. Borrower Data Used in a Merge or Score Only Request The borrower data needed for a Merge or Score Only Request is the borrower s name (including generation), SSN and current address. Any additional information that is provided, such as date of birth and previous addresses will improve the search criteria used by the credit repositories when they are matching that data to the information in their credit files. Sample LOAN APPLICATION Element for Merge Credit Request <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _UnparsedName="MARION C BRICK"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Page 2-18

Credit Request Section By Section Borrower Data Used in an RMCR Request When requesting an RMCR (Residential Mortgage Credit Report), more data from the Loan Application is investigated and verified by the credit bureau. For this reason Alias, Declarations, Employment, Liability, Landlord and Real Estate Owned data from the LOAN APPLICATION are included in the Credit Request Transaction. For some RMCRs, Asset data may also be verified by the credit bureau. The CreditRequest_v2_1.dtd contains the full content of the LOAN APPLICATION structure of the AUS2_1.dtd. Later versions Credit Request DTD contain the equivalent version of the AUS DTD. This allows lenders who are already generating the LOAN APPLICATION structure for AUS (Automated Underwriting System) decisions, to simply include the same structure in the Credit Request Transaction. Sample LOAN APPLICATION Element for RMCR Credit Request <CREDIT_REQUEST MISMOVersionID="2.1" LenderCaseIdentifier="MFC2002-0030" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="RMCR" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <LOAN_APPLICATION> <ASSET BorrowerID= BorRec0001 _Type= Automobile _CashOrMarketValueAmount= 25000 /> <LIABILITY _ID="BorLiab001" BorrowerID="BorRec0001" _HolderName="American Express" _HolderStreetAddress="3200 N Federal Hwy" _HolderCity="Fort Lauderdale" _HolderState="FL" _HolderPostalCode="33015" _AccountIdentifier="372200422377777" _Type="Open30DayChargeAccount" _UnpaidBalanceAmount="830"/> <LIABILITY _ID="BorLiab002" BorrowerID="BorRec0001 BorRec0002" _HolderName="Macy&apos;s West" _HolderStreetAddress="505 N Orange DR" _HolderCity="Orlando" _HolderState="FL" _HolderPostalCode="33723" _AccountIdentifier="5692002350044444" _Type="Revolving" _UnpaidBalanceAmount="4725"/> Page 2-19

Credit Request Section By Section <MORTGAGE_TERMS BaseLoanAmount="190000" LenderCaseIdentifier="02-30200488BCS" LoanAmortizationTermMonths="180" MortgageType="Conventional" RequestedInterestRatePercent="6.45"/> <REO_PROPERTY BorrowerID="BorRec0001 BorRec0002" _StreetAddress="1616 BRICKELL AV" _City="MIAMI" _State="FL" _PostalCode="33127" _CurrentResidenceIndicator="N" _DispositionStatusType="RetainForRental" _LienUPBAmount="0" _MaintenanceExpenseAmount="200" _MarketValueAmount="152000" _RentalIncomeGrossAmount="1300" _SubjectIndicator="N"/> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _PrintPositionType="Borrower" _SSN="530889999" _UnparsedName="MARION BRICK" MaritalStatusType="NotProvided"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103" BorrowerResidencyDurationYears="2" MonthlyRentAmount="1500"> <LANDLORD _Name="Landmark Apartments" _StreetAddress="3750 S BRANDES AV # 100" _City="LAS VEGAS" _State="NV" _PostalCode="89103"> <CONTACT_DETAIL _Name="Jenny Clark"> <CONTACT_POINT _Type="Email" _Value="Jenny@LandmarkInvestments.com"/> </CONTACT_DETAIL> </LANDLORD> </_RESIDENCE> <DECLARATION AlimonyChildSupportObligationIndicator= N BankruptcyIndicator= N BorrowedDownPaymentIndicator= Y CoMakerEndorserOfNoteIndicator= Y LoanForeclosureOrJudgementIndicator= N OutstandingJudgementsIndicator= N PresentlyDelinquentIndicator= N /> <EMPLOYER _Name="Ace Casino Supplies" _StreetAddress="2130 McLarren Blvd" _City="Las Vegas" _State="NV" _PostalCode="89134" EmploymentCurrentIndicator="Y" EmploymentPositionDescription="VP Sales" IncomeEmploymentMonthlyAmount="7500"/> </BORROWER> Page 2-20

Credit Request Section By Section <BORROWER BorrowerID="BorRec0002" _BirthDate="1970-11-25" _FirstName="JERRY" _LastName="BRICK" _PrintPositionType="CoBorrower" _SSN="538529999" _UnparsedName="JERRY BRICK" MaritalStatusType="NotProvided"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103" BorrowerResidencyDurationYears="2"/> <DECLARATION AlimonyChildSupportObligationIndicator= N BankruptcyIndicator= N BorrowedDownPaymentIndicator= Y CoMakerEndorserOfNoteIndicator= Y LoanForeclosureOrJudgementIndicator= N OutstandingJudgementsIndicator= N PresentlyDelinquentIndicator= N /> <EMPLOYER _Name="Mandalay Bay Hotel" _StreetAddress="252 Main Highway" _City="Las Vegas" _State="NV" _PostalCode="89106" EmploymentCurrentIndicator="Y" EmploymentPositionDescription="Res Mgr" IncomeEmploymentMonthlyAmount="5100"/> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> Loan Application Additions for the 2.x Credit Request As mentioned in the previous section, the CreditRequest_v2_x.dtd contains the full content of the LOAN APPLICATION structure of the AUS2_x.dtd. The Credit Request s version of LOAN APPLICATION contains several additional elements and attributes that are not present in the AUS2_x.dtd. It is also important to note that these additions may not be present in other MISMO transactions that use the AUS LOAN APPLICATION structure. When you view the contents of the CreditRequest_v2_x.dtd you can locate areas of the LOAN APPLICATION structure that have been modified for the credit request DTD by searching for the CREDIT/AUS: label. The DTD section below shows the comment for the _Birth Date attribute that was added to the BORROWER element. <!-- CREDIT/AUS: THE FOLLOWING ATTRIBUTE WAS ADDED TO THE --> <!-- ORIGINAL AUS DTD BY CORE DATA WORK GROUP FOR VERSION 2.1 --> <!ATTLIST BORROWER _BirthDate CDATA #IMPLIED > The table on the following page identifies all of the elements and attributes that were added to the LOAN APPLICATION section for the Credit Request. Page 2-21

Credit Request Section By Section Credit Reporting Version 2.x Additions to AUS LOAN APPLICATION Element LOAN APPLICATION Container(s) Affected BORROWER BORROWER _RESIDENCE _RESIDENCE _RESIDENCE _RESIDENCE ELEMENT or Attribute added _Birth Date _Unparsed Name Monthly Rent Amount Monthly Rent Current Rating Type PARSED_STREET_ADDRESS LANDLORD Sample data showing Credit additions to AUS LOAN APPLICATION <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _PrintPositionType="Borrower" _SSN="530889999" _UnparsedName="MARION BRICK" MaritalStatusType="NotProvided"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103" BorrowerResidencyDurationYears="2" MonthlyRentAmount="1500" > <PARSED_STREET_ADDRESS _HouseNumber="3750" _DirectionPrefix="S" _StreetName="BRANDES" _StreetSuffix="AV" _ApartmentOrUnit="242" </PARSED_STREET_ADDRESS> <LANDLORD _Name="Landmark Apartments" _StreetAddress="3750 S BRANDES AV # 100" _City="LAS VEGAS" _State="NV" _PostalCode="89103"> <CONTACT_DETAIL _Name="Jenny Clark"> <CONTACT_POINT _Type="Email" _Value="Jenny@LandmarkInvestments.com"/> </CONTACT_DETAIL> </LANDLORD> </_RESIDENCE> </BORROWER> </LOAN_APPLICATION> Page 2-22

Credit Request Section By Section EMBEDDED FILE Element Usage: Required? Purpose: Merge = YES RMCR = YES Score Only = YES No. Provides an optional repeating element for holding a print image of a borrower authorization form or loan application. Attributes are provided for describing the file format and version. Restrictions: Available only for Version 2.4.1.1 and later. Not available in Merge-Only DTD. The EMBEDDED FILE element is used in a number of other MISMO transactions. Beginning with Version 2.4 several additional attributes were added to this element to enhance its use in the Credit Request, Credit Response and other transactions. Version 2.4 and later added a required MISMOVersionID attribute to identify the MISMO version of the EMBEDDED FILE element structure being used. Version 2.4 and later changed _EncodingType from a text attribute to an enumerated attribute with the following valid values: Base64, QuotedPrintable. DeflateBase64, GzipBase64, and Other. When Other is used, enter the character set name into the _EncodingTypeOtherDescription attribute. Version 2.4 and later added a _CharacterEncodingSetType attribute to describe the character encoding set used for the embedded document, which may be different than the character encoding set used for the XML document. The valid values are: ISO88591, USASCII, UTF8, UTF16 and Other. When Other is used, enter the character set name into the _CharacterEncodingSetTypeOtherDescription attribute. Sample EMBEDDED FILE Data (Version 2.4.1.1 and later) <CREDIT_REQUEST MISMOVersionID="2.4.1.1"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" CreditReportRequestActionType="Submit" CreditReportType="Merge"/> <LOAN_APPLICATION> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" > </BORROWER> </LOAN_APPLICATION> <EMBEDDED_FILE _Type="PDF" MISMOVersionID="2.4" MIMEType="application/pdf" _Description="Borrower Authorization Form" _EncodingType="Base64"> <DOCUMENT> <![CDATA[...File Data Goes Here...]]> </DOCUMENT> </EMBEDDED_FILE> </CREDIT_REQUEST> Page 2-23

Credit Response Section By Section Chapter 3: Credit Response Section By Section This section of the manual provides general information about each section of a credit report response. Below is a sample credit response file. The outlined area of the sample, beginning the CREDIT RESPONSE element, is the portion of the standard that is covered in this section of the guide. Sample XML Credit Response (with MISMO Response Envelope) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE REQUEST_GROUP SYSTEM "CreditResponse_v2_1.dtd"> <RESPONSE_GROUP MISMOVersionID="2.1"> <RESPONDING_PARTY _Name="ABC Services" _StreetAddress="7200 Peachtree Street" _City="Atlanta" _State="GA" _PostalCode="30010"/> <RESPOND_TO_PARTY _Name="MFC Mortgage" _StreetAddress="21650 Oxnard Street" _City="Woodland Hills" _State="CA" _PostalCode="91364"/> <RESPONSE RequestDateTime="2002-01-08T17:19:12" InternalAccountIdentifier="ABC-0732"> <KEY _Name="MFC Transaction ID" _Value="702430023"/> <KEY _Name="MFC Portfolio ID" _Value="MFC2002-0030"/> <RESPONSE_DATA> <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> </RESPONSE_DATA> </RESPONSE> </RESPONSE_GROUP> Page 3-1

Credit Response Section By Section CREDIT RESPONSE Element The DTD segment below shows the major component elements of the CREDIT RESPONSE element. Some of the elements repeat information that could be included in the Response Envelope. For example, the CREDIT BUREAU element has the same information as the envelope s RESPONDING PARTY element. The REQUESTING PARTY element has the same information as the envelope s RESPOND TO PARTY element. Including this information within the CREDIT RESPONSE allows it to become a permanent part of the credit report record, even if the envelope data is discarded. The DATA INFORMATION element records information about the software version that produced the credit response. (DATA INFORMATION is only available in Version 2.3 and later.) An asterisk (*) appearing after an element indicates that it is optional, and it can be used in an XML file more than one time. A question mark (?) after an element indicates that it is optional, but it can only be used once in an XML file. Major CREDIT RESPONSE Elements from DTD <!ELEMENT CREDIT_RESPONSE( _DATA_INFORMATION*, NEW: Ver 2.3 CREDIT_BUREAU?, CREDIT_REPORT_PRICE*, CREDIT_REPOSITORY_INCLUDED?, REQUESTING_PARTY?, CREDIT_REQUEST_DATA?, CREDIT_ERROR_MESSAGE*, BORROWER*, CREDIT_LIABILITY*, CREDIT_PUBLIC_RECORD*, CREDIT_INQUIRY*, CREDIT_FILE*, CREDIT_SCORE*, CREDIT_TRADE_REFERENCE*, CREDIT_COMMENT*, CREDIT_CONSUMER_REFERRAL*, CREDIT_SUMMARY*, REGULATORY_PRODUCT*, NEW: Ver 2.3 EMBEDDED_FILE*, _ALERT_MESSAGE* NEW: Ver 2.4.1.1 )> Page 3-2

Credit Response Section By Section CREDIT RESPONSE Attributes The CREDIT RESPONSE element has several attributes worth mentioning here because of their importance. CREDIT RESPONSE Element with Attributes <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-04" CreditReportLastUpdatedDate="2002-01-10" CreditReportMergeType="Blend" CreditReportType="Merge" CreditRatingCodeType= Equifax >... Other CREDIT RESPONSE elements and attributes go here... </CREDIT_RESPONSE> MISMO Version ID identifies which version of the DTD this section of the data conforms to. This attribute is required. Credit Response ID an optional ID attribute that can be assigned to each response. The ID value must be unique throughout the XML data file. It must also be a valid XML name that is, it begins with a letter and is composed of alphanumeric characters and the underscore without white space (spaces, tabs, carriage returns, line feeds). Credit Report Identifier the number or identifier assigned by the credit bureau to a particular credit report. This is defined as a MISMO String Attribute, so it may begin with a number. Credit Report First Issued Date the date that this credit report was first issued or originated. Credit Report Last Updated Date the date of the most recent update to the credit report. Credit Report Merge Type identifies which type of merging method was used for combining duplicate trade lines and/or public records. Valid options are: Blend: data is blended from a group of duplicates to form a single record. List and Stack: a blend record is provided, along with the individual duplicate records that the blend record was built from. Pick and Choose: a record is picked from a list of duplicates. Credit Report Type identifies the type of report included with this credit response. Valid options are: Error: The response contains error messages stating why a credit report is not being returned. Page 3-3

Credit Response Section By Section Merge: A merge report (also called merged infile) includes data on file from the selected credit data repositories. Merge Plus: An enhanced version of the Merge product. Contact the credit bureau for details. Non-Traditional: Provides credit evaluation for borrowers with minimal credit history. Other: Not one of the valid types. Enter the description will be entered in the Credit Report Type Other Description attribute. Risk Scores Only: Provides credit risk scores only. RMCR: Residential Mortgage Credit Report is an enhanced credit product that contains verified information and/or additional investigation. RMCR Foreign: RMCR with additional foreign investigation. Status: The Credit Bureau provides the current status of an earlier request for a credit product, such as an RMCR. Credit Report Type Other Description if the Credit Report Type attribute has a value of Other, enter its description here. Credit Rating Code Type identifies the Manner Of Payment (MOP) rating code set that is used in the Credit Liability section of the credit report. See page 3-17 for more information on MOP codes. Valid options are: Equifax: The Equifax MOP rating codes are used. Experian: The Experian MOP rating codes are used. Other: Not one of the valid types. Enter the description will be entered in the Credit Rating Code Type Other Description attribute. Credit Rating Code Type Other Description if the Credit Rating Code Type attribute has a value of Other, enter its description here. Page 3-4

Credit Response Section By Section CREDIT RESPONSE Element Usage The remainder of this chapter gives a brief overview of each section of a credit response. The Credit Response DTD does not control the usage of the individual data elements that comprise the credit response. This document provides guidance for how and when to use the data elements. One of the categories of information provided for each section is Usage. YES indicates that a data element is generally used for a particular credit response type, and NO indicates that the data element is generally not used for that credit response type. The most commonly used types of credit responses are: Merge A merge report (also called merged infile) includes data on file from the selected credit data repositories. RMCR Residential Mortgage Credit Report is an enhanced credit product that contains verified information and/or additional investigation. Score Only Provides credit risk scores only. Other categories provided for each element are Required? describes whether or not the data element is required, Purpose a short summary describing what the data element is used for. The final category, Restrictions lists any DTD or Version restrictions for the data element. Examples: Not available in Merge-Only DTD. Available only for Version 2.1.1 and later. Page 3-5

Credit Response Section By Section DATA INFORMATION Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: This data structure is available to record the source data versions used to produce the MISMO XML transactions. This information may be useful for troubleshooting problems in production. This data element might be used to identify the Equifax, Experian and Trans Union data versions used in the Credit Response transaction. Restrictions: Available only for Version 2.3 and later. Sample Credit Response with DATA INFORMATION Element <CREDIT_RESPONSE MISMOVersionID="2.3" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2003-01-03" CreditReportType="Merge"> <_DATA_INFORMATION> <DATA_VERSION _Name="ACME CREDIT ENGINE" _Number="3.1"/> <DATA_VERSION _Name="BEST-LOS Profile" _Number="5.0"/> <DATA_VERSION _Name="Equifax" _Number="5"/> <DATA_VERSION _Name="Experian" _Number="7"/> <DATA_VERSION _Name="Trans Union" _Number="4.1"/> </_DATA_INFORMATION> <CREDIT_BUREAU _Name="ABC Credit Services"/> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-6

Credit Response Section By Section CREDIT BUREAU Element Usage: Required? Purpose: Restrictions: None. Merge = YES RMCR = YES Score Only = YES No This element identifies the credit bureau processing the data from the repository bureaus and generating the response transaction. The CREDIT BUREAU element has the same information as the envelope s RESPONDING PARTY element. In Version 2.4.1.1 & later, a FNMCreditBureauIdentifier attribute can be added to show the unique, three character Agency ID code assigned by Fannie Mae to the Credit Bureau. Sample CREDIT BUREAU Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU _Name="ABC Services" _StreetAddress="7200 Peachtree Street" _City="Atlanta" _State="GA" _PostalCode="30010" FNMCreditBureauIdentifier="997"> NEW: Ver 2.4.1.1 <CONTACT_DETAIL> <CONTACT_POINT _Type="Phone" _Value="8182263700"/> <CONTACT_POINT _Type="Fax" _Value="8185879587"/> </CONTACT_DETAIL> </CREDIT_BUREAU> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-7

Credit Response Section By Section CREDIT REPORT PRICE Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No Purpose: This element identifies the prices charged by the credit bureau for the credit report. It map appear once for each price category. Restrictions: None. Sample CREDIT REPORT PRICE Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE _Amount="15.00" _Type="Net"/> <CREDIT_REPORT_PRICE _Amount="0.60" _Type="Tax"/> <CREDIT_REPORT_PRICE _Amount="15.60" _Type="Total"/> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-8

Credit Response Section By Section CREDIT REPOSITORY INCLUDED Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No Purpose: This element identifies the credit repositories (Equifax, Experian and Trans Union) whose data were actually used to produce this credit report. The repositories requested are identified in the CREDIT REQUEST DATA element. See page 7-2 for an example showing credit repositories requested and used. Restrictions: None. Sample CREDIT REPOSITORY INCLUDED Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-9

Credit Response Section By Section REQUESTING PARTY Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No Purpose: This element identifies the entity requested that will be billed for the credit report. The REQUESTING PARTY element has the same information as the envelope s RESPOND TO PARTY element. Including this information within the CREDIT RESPONSE allows it to become a permanent part of the credit report record, even if the envelope data is discarded. The _Requested By Name attribute also identifies the individual at the company who requested the report. Restrictions: None. Sample REQUESTING PARTY Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY _Name="MFC Mortgage" _StreetAddress="21650 Oxnard Street" _City="Woodland Hills" _State="CA" _PostalCode="91364" _RequestedByName= Sean R /> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-10

Credit Response Section By Section CREDIT REQUEST DATA Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No Purpose: This element identifies the original options that were requested. They can be echoed back in the response as a record of what was ordered by the REQUESTING PARTY. The same Credit Request ID value sent in the request transaction should be returned in the response transaction. Restrictions: None. Sample CREDIT REQUEST DATA Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="BorRec0001" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-11

Credit Response Section By Section CREDIT ERROR MESSAGE Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: When an error occurs that does not allow the return of a complete credit report, this element contains information about the cause and source of the error. Restrictions: None. Sample CREDIT ERROR MESSAGE Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Error" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE _SourceType="CreditBureau"> <_Text>Borrower SSN Missing</_Text> </CREDIT_ERROR_MESSAGE> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-12

Credit Response Section By Section BORROWER Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No Purpose: This element identifies the borrower(s) being reported on. This is the same information that was reported in the request transaction. The same Borrower ID value used in the request transaction should be returned in the response transaction. Restrictions: None. Sample BORROWER Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER BorrowerID="BorRec0001" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _UnparsedName="MARION C BRICK"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> </BORROWER> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-13

Credit Response Section By Section CREDIT LIABILITY Element Usage: Merge = YES RMCR = YES Score Only = NO Required? No. Purpose: Provides liability data merged from duplicate liabilities reported the repositories (Equifax, Experian, Trans Union). This container is also used when there is only data from a single repository. More information about Merged liability data and Repository liability data appears on the pages that follow the sample liability shown below. Restrictions: None. Sample CREDIT LIABILITY Element Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY CreditLiabilityID="CRLiab0001" BorrowerID="BorRec0001" _AccountIdentifier="1743911111" _AccountOpenedDate="1998-06" _AccountOwnershipType="Individual" _AccountReportedDate="2001-12" _AccountStatusType="Open" _AccountType="Installment" _HighCreditAmount="1620" _LastActivityDate="2001-12" _MonthsReviewedCount="25" _MonthlyPaymentAmount="70" _TermsDescription="$70/MO" _UnpaidBalanceAmount="420" CreditLoanType="InstallmentSalesContract"> <_CREDITOR _Name="AFFILIATED ACCEP CRP"/> <_CURRENT_RATING _Code="1" _Type="AsAgreed"/> <_LATE_COUNT _30Days="0" _60Days="0" _90Days="0"/> <_PAYMENT_PATTERN _Data="CCCCCCCCCCCCCCCCC" _StartDate="2000-01"/> <CREDIT_COMMENT _SourceType="RepositoryBureau"> <_Text>Installment Sales Contract</_Text> </CREDIT_COMMENT> <CREDIT_REPOSITORY _SourceType="Equifax" _SubscriberCode="321BC02496"/> <CREDIT_REPOSITORY _SourceType="Experian" _SubscriberCode="2681655"/> <CREDIT_REPOSITORY _SourceType="TransUnion" _SubscriberCode="B 2509348"/> </CREDIT_LIABILITY> <CREDIT_LIABILITY...Additional Liability Data Goes Here.../> </CREDIT_RESPONSE> Page 3-14

Credit Response Section By Section CREDIT LIABILITY and UNMERGED LIABILITY Data The CREDIT LIABILITY element is used for "merged or blended" data from more than one repository, or for data from a single repository. Most credit reports will only use the CREDIT LIABILITY container. The following sample is an abridged example of a single merged liability record. Sample Credit Liability (without Unmerged Liability Data) <CREDIT_LIABILITY CreditLiabilityID="CRLiab0001" _AccountIdentifier="371230230039498" _AccountReportedDate="2001-12" _UnpaidBalanceAmount="1425"> <_CREDITOR _Name="AMERICAN EXPRESS"/> <CREDIT_REPOSITORY _SourceType="MergedData"/> </CREDIT_LIABILITY> The UNMERGED LIABILITY container is normally supplied for quality control reports, or for customers who want to see the "merged liability data plus the original "unmerged" liability duplicates. In the sample below, there is a CREDIT LIABILITY element that holds the "merged" data, and within that element there are multiple UNMERGED LIABILITY elements - one for each liability record returned by a repository. Sample Credit Liability (with Unmerged Liability Data) <CREDIT_LIABILITY CreditLiabilityID="CRLiab0001" _AccountIdentifier="371230230039498" _AccountReportedDate="2001-10" _UnpaidBalanceAmount="1425"> <_CREDITOR _Name="AMERICAN EXPRESS"/> <CREDIT_REPOSITORY _SourceType="MergedData"/> <UNMERGED_LIABILITY CreditLiabilityID="CRLiab0002" _AccountIdentifier="37123023003" _AccountReportedDate="2001-10" _UnpaidBalanceAmount="1425"> <_CREDITOR _Name="AMEX"/> <CREDIT_REPOSITORY _SourceType="Equifax"/> </UNMERGED_LIABILITY> <UNMERGED_LIABILITY CreditLiabilityID="CRLiab0003" _AccountIdentifier="371230230039498" _AccountReportedDate="2001-09" _UnpaidBalanceAmount="1100"> <_CREDITOR _Name="AMERICAN EXPRESS"/> <CREDIT_REPOSITORY _SourceType="TransUnion"/> </UNMERGED_LIABILITY> <UNMERGED_LIABILITY CreditLiabilityID="CRLiab0004" _AccountIdentifier="371230230039" _AccountReportedDate="2001-10" _UnpaidBalanceAmount="1400"> <_CREDITOR _Name="AMER EXPR"/> <CREDIT_REPOSITORY _SourceType="Experian"/> </UNMERGED_LIABILITY> </CREDIT_LIABILITY> Page 3-15

Credit Response Section By Section Prior Adverse Rating and Payment Pattern Data The Version 2 Credit Response DTD provides two elements for displaying a borrower s monthly payment history the PRIOR ADVERSE RATING element and the PAYMENT PATTERN element. Prior Adverse Rating Data consists of a PRIOR ADVERSE RATING element for each month that the borrower was delinquent in making payments to a creditor. Each element has the date of the delinquency plus a _Type attribute that describes how late the borrower was at that time. The following XML sample from a BAY COMPANY liability record shows that the borrower was late in making payments 30 days in December 1995, 60 days in January 1996, and 90 days in February 1996 before becoming current. Sample Liability with PRIOR ADVERSE RATING Data <CREDIT_LIABILITY CreditLiabilityID="CRLiab0031" _AccountIdentifier="42426293888244" _AccountReportedDate="2001-12" _UnpaidBalanceAmount="1150"> <_CREDITOR _Name="BAY COMPANY"/> <_PRIOR_ADVERSE_RATING _Date= 1999-02 _Type= Late90Days /> <_PRIOR_ADVERSE_RATING _Date= 1999-01 _Type= Late60Days /> <_PRIOR_ADVERSE_RATING _Date= 1998-12 _Type= Late30Days /> <CREDIT_REPOSITORY _SourceType="MergedData"/> </CREDIT_LIABILITY> Another option for displaying payment history uses Payment Pattern Data, which consists of a string of characters representing delinquency ratings for a series of months. The first character of the payment pattern represents the rating at the date shown in the PAYMENT PATTERN element s _Start Date attribute. Each subsequent payment pattern character is for the next previous month. The following rating characters are used in the payment pattern: C = Current 1 6 = Number of months delinquent 7 = Wage Earner Plan 8 = Repossession / Foreclosure 9 = Collection / Charge Off N = No Activity X = No data available Page 3-16

Credit Response Section By Section The following is a payment pattern sample from the same liability record used in the previous example. The first character in the payment pattern, C, indicates that the borrower was current in making payments to BAY COMPANY as of April 1999, the Payment Pattern Start date. The previous month, March 1999 also had a current rating of C. The next character in the pattern, 3, indicates that the borrower was three months late in February 1999. The 2 indicates that the borrower was two months late in January 1999, and finally one month late in December 1998. The PAYMENT PATTERN element contains the same information as the PRIOR ADVERSE RATING element. It is just presented in a different format. Sample Liability with PAYMENT PATTERN Data <CREDIT_LIABILITY CreditLiabilityID="CRLiab0031" _AccountIdentifier="42426293888244" _AccountReportedDate="2001-12" _UnpaidBalanceAmount="1150"> <_CREDITOR _Name="BAY COMPANY"/> <_PAYMENT_PATTERN _Data="CC321CCCCCCCCCCCCCCC" _StartDate="1999-04"/> <_PRIOR_ADVERSE_RATING _Date= 1999-02 _Type= Late90Days /> <_PRIOR_ADVERSE_RATING _Date= 1999-01 _Type= Late60Days /> <_PRIOR_ADVERSE_RATING _Date= 1998-12 _Type= Late30Days /> <CREDIT_REPOSITORY _SourceType="MergedData"/> </CREDIT_LIABILITY> Manner Of Payment (MOP) Codes The MISMO Version 2 Credit Reporting DTDs include an optional _Code attribute that can be used with the Credit Liability Manner of Payment (MOP) elements CURRENT RATING, HIGHEST ADVERSE RATING, MOST RECENT ADVERSE RATING, and PRIOR ADVERSE RATING. The use of MOP codes can simplify processing by automated evaluation systems, since the codes are normally numeric and become higher in value as the derogatory status increases. There are two MOP coding systems that are commonly used in the credit reporting industry. The most commonly used coding system is that used by the credit repositories, Equifax and Trans Union. Experian uses a slightly different coding system for rating a borrower s manner of payment. Credit bureaus that produce credit reports for their customers generally use one of the two coding systems, or sometimes use one coding system for some customers and the other coding system for other customers. In an individual credit report, only one of the coding systems will be used for all of the MOP Rating codes, no matter which repository the credit data originally came from. In other words, if a credit bureau uses the Equifax / Trans Union MOP codes, those codes will be used for all credit data, even if it came from Experian. Page 3-17

Credit Response Section By Section The following table shows the MOP Rating text values, followed by the equivalent Equifax / Trans Union MOP code, and then by the equivalent Experian MOP code. The Experian MOP codes are similar to the codes used in the Payment Pattern that were described on page 3-16. The third column is provided to allow you to enter another MOP code set that a credit bureau may use. Note that the MOP codes that are shaded match more than one MOP Rating Text value. MOP Rating Text Plus Equifax and Experian Credit Rating Codes MOP Rating Text Credit Rating Code Type = Equifax Credit Rating Code Type = Experian Too New To Rate or Not Rated 0 N Current with No Balance 1 N Current, Pays as Agreed 1 C 30 Days Delinquent 2 1 60 Days Delinquent 3 2 90 Days Delinquent 4 3 120 Days Delinquent 5 4 150 Days Delinquent 5 5 180 Days Delinquent 5 6 Bankruptcy or Wage Earner Plan NOTE: Experian only includes Chapter 13 Bankruptcies under this code. 7 7 Repossession or Foreclosure 8 8 Collection or Charge Off NOTE: Experian includes Chapter 7, 11 and 12 Bankruptcies under this code. 9 9 No Data Available - - Credit Rating Code Type = Other The CREDIT RESPONSE element has a Credit Rating Code Type attribute that identifies which MOP coding system is used in the credit report. The valid options for this enumerated attribute are Equifax, Experian, or Other. When the Other option is selected, then the name of the MOP coding system should be entered in the Credit Rating Code Type Other Description attribute. Page 3-18

Credit Response Section By Section The first sample credit report below shows a single CREDIT LIABILITY element. The _Code attribute appearing in several rating elements uses the Equifax MOP codes. Note that the Credit Rating Code Type attribute in the CREDIT RESPONSE element is set to Equifax. Sample Credit Report with Equifax MOP Rating Codes <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend" CreditRatingCodeType= Equifax > <CREDIT_LIABILITY CreditLiabilityID="CRLiab0047" _AccountIdentifier="411284940023" _AccountReportedDate="2002-01" _UnpaidBalanceAmount="945"> <_CREDITOR _Name="MCB VISA"/> <_CURRENT_RATING _Code= 1 _Type= AsAgreed /> <_HIGHEST_ADVERSE_RATING _Code= 3 _Date= 1999-12 _Type= Late60Days /> <_MOST_RECENT_ADVERSE_RATING _Code= 2 _Date= 2000-01 _Type= Late30Days /> <CREDIT_REPOSITORY _SourceType="MergedData"/> </CREDIT_LIABILITY> </CREDIT_RESPONSE> The next credit report uses the same data but uses the Experian MOP Rating Codes. Note that the CreditRatingCodeType attribute in the CREDIT RESPONSE element is set to Experian. Sample Credit Report with Experian MOP Rating Codes <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend" CreditRatingCodeType= Experian > <CREDIT_LIABILITY CreditLiabilityID="CRLiab0047" _AccountIdentifier="411284940023" _AccountReportedDate="2002-01" _UnpaidBalanceAmount="945"> <_CREDITOR _Name="MCB VISA"/> <_CURRENT_RATING _Code= C _Type= AsAgreed /> <_HIGHEST_ADVERSE_RATING _Code= 2 _Date= 1999-12 _Type= Late60Days /> <_MOST_RECENT_ADVERSE_RATING _Code= 1 _Date= 2000-01 _Type= Late30Days /> <CREDIT_REPOSITORY _SourceType="MergedData"/> </CREDIT_LIABILITY> </CREDIT_RESPONSE> Page 3-19

Credit Response Section By Section Credit Liability Late Count and Periodic Late Count The CREDIT LIABILITY element s LATE COUNT tracks the number of times that payments have been reported late by the creditor. The LATE COUNT has attributes for 30, 60, 90 or 120 day late periods. In Version 2.3 and later, a PERIODIC LATE COUNT element can be added to the LATE COUNT element to break down 30/60/90/120 late count totals by year, using the Account Reported Date as the starting point. Below is a sample liability record showing both the LATE COUNT element available in all credit response versions, plus the PERIODIC LATE COUNT element that is available in the Version 2.3. Sample CREDIT LIABILITY with Late Count and Period Late Count <CREDIT_LIABILITY CreditLiabilityID="CRLiab0024" BorrowerID="BorRec0001" _AccountIdentifier="111235299999" _AccountOpenedDate="1998-06" _AccountOwnershipType="Individual" _AccountReportedDate="2003-06-11" _AccountStatusType="Open" _AccountType="Installment" _HighCreditAmount="90000"> <_CREDITOR _Name="AFFILIATED ACCEP CRP"/> <_CURRENT_RATING _Code="1" _Type="AsAgreed"/> <_LATE_COUNT _30Days="7" _60Days="3" _90Days="2" _120Days="1"> <PERIODIC_LATE_COUNT _Type="FirstYear" _30Days="1" _60Days= 0 _90Days= 0 120Days= 0 /> <PERIODIC_LATE_COUNT _Type="SecondYear" _30Days="2" _60Days= 1 _90Days= 1 _120Days= 0 /> <PERIODIC_LATE_COUNT _Type="ThirdYear" _30Days="4" _60Days= 2 _90Days= 1 _120Days= 1 /> </_LATE_COUNT> </CREDIT_LIABILITY> Including Code Values with Credit Comments Sometimes significant data about a credit liability is only available from the repository bureau data in the form of a Narrative Code (Equifax), Remarks Code (Trans Union) or Special Comment Code (Experian). These codes are normally converted into comment text by the credit bureau and included in the CREDIT COMMENT element. For automated processing of the credit data, some lenders and automated underwriting and decisioning systems prefer to have the original repository code values included in the _Code attribute of the CREDIT COMMENT element. Using the original code values allows for more reliable and faster processing than parsing of text comments. Page 3-20

Credit Response Section By Section In addition to its Special Comment Codes, Experian also provides a Status Code, which may have significant information that is converted into text and included in the CREDIT COMMENT element. NOTE: Lenders and Automated Decisioning Systems must make their own arrangements with the repository bureaus to have access to the repository comment code lists. These repository code tables are proprietary and are not supplied as part of the MISMO standards. For an automated system to be able to process the coded data, it needs to know which code table it originated from. To designate the source of the CREDIT COMMENT element s _Code and _Text data, there are two additional attributes provided: o Type identifies what type of comment is being included. There are six possible enumerated values, but for its use in this context, these are the most commonly used values: o Bureau Remarks the comment text may be associated with a a code value from an Equifax Narrative table, an Experian Special Comment table or a Trans Union Remarks table. o Status Code the comment text and code originated from and Experian Status Code. NOTE: This attribute enumeration was added in Version 2.4. o Source Type identifies the source of the data that has seven possible values, but for the purposes of identifying the origin of a code and its related text in this context, here are the values that could be used: o Credit Bureau The credit bureau that prepared the credit report has supplied the comment text, which may also have a code value associated with it. Contact the credit bureau for their complete code list. o Equifax The comment code and text is from the Equifax Narrative Code table, located in Attachment 6 of their System To System manuals (V5 and V6). o Experian If the _Type attribute is BureauRemarks then the code and comment are from Experian s Special Comment table in Appendix B of the Experian Technical Manual or the File One Appendix. If the _Type attribute is StatusCode then the code and comment are from Appendix L or Appendix N of the Experian Technical Manual or the File One Appendix. o Trans Union The comment code and text is from Appendix C of the TU Release 4 User Guide. Page 3-21

Credit Response Section By Section The sample file below shows three CREDIT COMMENT elements. The first comment is generated from Experian Special Comment Code 34. The second comment is generated from Experian Status Code 82. The third comment identifies the collateral for the loan and does not have an Experian code associated with it. Sample CREDIT LIABILITY with Credit Comment Text and Codes <CREDIT_LIABILITY CreditLiabilityID="CRLiab0072" BorrowerID="BorRec0001" _AccountIdentifier="320202999999" _AccountOpenedDate="2001-12" _AccountOwnershipType="Individual" _AccountReportedDate="2006-11-25" _AccountStatusType="Open" _AccountType="Installment" _HighCreditAmount="22300"> <_CREDITOR _Name="FORD MOTOR CREDIT"/> <_CURRENT_RATING _Code="5" _Type="Late120Days"/> <CREDIT_COMMENT _Code="34" _SourceType="Experian" _Type="BureauRemarks"> <_Text>DEBT BEING PAID THROUGH INSURANCE</_Text> </CREDIT_COMMENT> <CREDIT_COMMENT _Code="82" _SourceType="Experian" _Type="StatusCode"> <_Text>ACCOUNT DELINQUENT 120 DAYS PAST DUE</_Text> </CREDIT_COMMENT> <CREDIT_COMMENT _SourceType="Experian" _Type="BureauRemarks"> <_Text>COLLATERAL: 2006 FORD FOCUS</_Text> </CREDIT_COMMENT> </CREDIT_LIABILITY> Page 3-22

Credit Response Section By Section CREDIT PUBLIC RECORD Element Usage: Merge = YES RMCR = YES Score Only = NO Required? No. Purpose: Provides public record data merged from duplicate public records from the repositories (Equifax, Experian, Trans Union). This container is also used when there is only data from a single repository. When it is necessary to report the original repository public record data, the UNMERGED PUBLIC RECORD element is are used. RMCR Public Records may include a VERIFICATION container. Restrictions: None. Sample CREDIT PUBLIC RECORD Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD CreditPublicRecordID="CRPubR0001" BorrowerID="BorRec0001" _CourtName="CLARK CO JUSTICE COURT" _DispositionDate="2001-10" _DispositionType="Unsatisfied" _DocketIdentifier="99-044444" _FiledDate="1999-01" _LegalObligationAmount="512" _PlaintiffName="COLLECTION, CBCMERCY AMB, COLL" _Type="Judgment"> </CREDIT_PUBLIC_RECORD> <CREDIT_PUBLIC_RECORD...Additional Records Go Here.../> </CREDIT_RESPONSE> Page 3-23

Credit Response Section By Section CREDIT INQUIRY Element Usage: Merge = YES RMCR = YES Score Only = NO Required? No. Purpose: Provides a list of companies who have requested credit data on the referenced borrower. Restrictions: None. Sample INQUIRY Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY CreditInquiryID="CRInqu0001" _Name="MCYW/FDSNB" _Date="2001-11-21" BorrowerID="BorRec0001"> <CREDIT_REPOSITORY _SourceType="Equifax"/> </CREDIT_INQUIRY> <CREDIT_INQUIRY CreditInquiryID="CRInqu0002" _Name="JNB/ZALE" _Date="2001-09-21" BorrowerID="BorRec0001"> <CREDIT_REPOSITORY _SourceType="Experian"/> </CREDIT_INQUIRY> <CREDIT_INQUIRY...Additional Inquiry Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-24

Credit Response Section By Section CREDIT FILE Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: Provides identifying data for each credit file returned from a credit request. This identifying data can be used to verify that the credit file returned belongs to the borrower that is the subject of the credit request. It also provides additional data about the borrower that is on file with the repository, such as employment data, current/previous addresses and alias/aka names. When identifying data in a credit file varies from the identifying data in the credit request, those variations are reported in the _VARIATION element. If a repository does not return a credit file, an error message will appear in the data as shown in the second sample below. Restrictions: None. NOTE: In Version 2.3 & Later, ALIAS, EMPLOYER and RESIDENCE elements were added to the CREDIT_FILE / _BORROWER element. There are two methods of reporting this information, depending on the version: Data Type Version 2.1/2.1.1 Element Version 2.3 Element Alias/AKA CREDIT_COMMENT / Text _ALIAS Address _UnparsedAddress _RESIDENCE Employment _UnparsedEmployment EMPLOYER Sample CREDIT FILE Data (Version 2.1/2.1.1) <CREDIT_FILE CreditFileID="CRFilEFX03" BorrowerID="BorRec0001" CreditRepositorySourceType="Equifax"> <_ALERT_MESSAGE> <_Text>EFX: SSN (283556789) Issued: 1971 - OH</_Text> </_ALERT_MESSAGE> <_BORROWER _UnparsedName="MARION BRICK" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _BirthDate="1953-04-09"> <_UnparsedAddress>710 W BURLINGTON</_UnparsedAddress> <_UnparsedAddress>2929 BARRY ST, LAS VEGAS</_UnparsedAddress> <_UnparsedEmployment>ALLTEL, CUST SVC</_UnparsedEmployment> </_BORROWER> <_OWNING_BUREAU _Name="Equifax" _StreetAddress="3750 GRAND ST" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> <_VARIATION _Type="DifferentName"/> <_VARIATION _Type="DifferentBirthDate"/> <CREDIT_COMMENT _SourceType="RepositoryBureau"> <_Text>Also Known As: MARION JONES</Text> </CREDIT_COMMENT> </CREDIT_FILE> Page 3-25

Credit Response Section By Section Sample CREDIT FILE Data (Version 2.3 and Later) <CREDIT_FILE CreditFileID="CRFilEFX03" BorrowerID="BorRec0001" CreditScoreID="CRScoEFX03" CreditRepositorySourceType="Equifax"> <_ALERT_MESSAGE> <_Text>EFX: SSN (283556789) Issued: 1971 - OH</_Text> </_ALERT_MESSAGE> <_BORROWER _UnparsedName="MARION BRICK" _FirstName="MARION" _LastName="BRICK" _SSN="530889999" _BirthDate="1953-04-09"> <_ALIAS _FirstName="MARION" _LastName="JONES"/> <_RESIDENCE _StreetAddress="710 W BURLINGTON"/> <_RESIDENCE _StreetAddress="2929 BARRY ST " _City="LAS VEGAS" _State="NV"/> <EMPLOYER _Name="LAS VEGAS" EmploymentPositionDescription="CUST SVC"/> </_BORROWER> <_OWNING_BUREAU _Name="Equifax" _StreetAddress="3750 GRAND ST" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> <_VARIATION _Type="DifferentName"/> <_VARIATION _Type="DifferentBirthDate"/> </CREDIT_FILE> Sample CREDIT FILE Error Data: <CREDIT_FILE CreditFileID="CRFilTUC01"> <CREDIT_ERROR_MESSAGE _Code= 205 _Source="TransUnion"> <_Text> Trans Union: Member Code Missing or Invalid </_Text> </CREDIT_ERROR_MESSAGE> </CREDIT_FILE> Page 3-26

Credit Response Section By Section CREDIT SCORE Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: Provides credit risk score data, either as stand-alone data or as part of a credit report. In addition to the actual score value, up to four risk score factors and their associated text are supplied. These were the primary factors that affected the score value. Restrictions: None. Valid Credit Score Values To provide consistent data to lenders, credit bureaus should only put valid score values into the CREDIT_SCORE element s _Value attribute. Data values like N/A, n/a, None or - are not valid score values and should not be used for the _Value attribute. NOTE: The Risk Score data returned from Experian can include either a score value, or an Error/Model Exclusion Code. For some score models, these Experian Exclusion Code values may have values of 9000 and higher. For other models, they may be in the range of 0001 through 0003. Since the Experian Exclusion Codes do not represent a credit score value, they should not be mapped to the MISMO Credit Score Value attribute. See the Credit Score Record with an Exclusion Reason section on the next page. Standard Credit Score Record Versions 2.1-2.3.1 The Credit Score data for MISMO Versions 2.1 through 2.3.1 include a Score Value, Factor Codes and Factor Text, plus attributes that identify the model name, the source of the data, and what borrower and credit file the score data belongs to. Here is a sample of the basic Credit Score data record: Sample Standard CREDIT SCORE Data Record <CREDIT_SCORE CreditScoreID="CRScoXPN01" BorrowerID="BorRec0001" CreditFileID="CRFilXPN01" _ModelNameType="ExperianFairIsaac" _Value="575" CreditRepositorySourceType="Experian"> <_FACTOR _Code="38" _Text="Serious delinquency and public record or collection filed"/> <_FACTOR _Code="14" _Text="Length of time accounts have been established"/> <_FACTOR _Code="20" _Text="Length of time since legal item filed or collection item reported"/> <_FACTOR _Code="02" _Text="Delinquency reported on accounts"/> </CREDIT_SCORE> Page 3-27

Credit Response Section By Section Expanded Credit Score Record Version 2.4 & Later Beginning with Version 2.4, numerous attributes were added to the CREDIT_SCORE element. The additions basically fall into two types: the Category Type attribute, and the FACTA Disclosure attributes. Category Type Attribute The _CategoryType attribute is an enumerated list that describes the general type or purpose of a credit score model. This allows lender software to categorize scores by their general type rather than the specific _ModelNameType product names. The Credit Score Category Types defined in Version 2.4 are: o Bankruptcy These models present the score as a risk index representing an individual s likelihood to file for bankruptcy in the near future. o Credit Repository These models are jointly developed by the credit repository bureaus to evaluate credit performance and calculate risk of delinquency. o FICO These are score models developed by Fair Isaac Corporation, representing an individual s financial credit worthiness. This category includes the score models most commonly used in the mortgage industry: Equifax Beacon and Beacon 5.0, Experian Fair Isaac, and Trans Union Emperica and FICO Risk Score Classic 04. o FICO NextGen These are score models developed by Fair Isaac Corporation as part of their NextGen scoring algorithm, representing an individual s financial credit worthiness o Thin File A credit score model that uses non-traditional data such as utility bill or residential rental payment history to determine credit worthiness. This score model is used for individuals who do not have sufficient credit card, auto loan or other traditional credit history. o Other This type is used for models that are not one of the above categories. The category description should be entered into the _CategoryTypeOtherDescription attribute. NOTE: The Category Type associated with each score model is listed in a table in the Credit Score Model Name Types Recommendation document, which can be viewed or downloaded from the MISMO web site s Implementation Guides page at the following link: http://www.mismo.org/current%20specs/implementationguides.html Page 3-28

Credit Response Section By Section FACTA Disclosure Attributes A group of new attributes have been added to the MISMO CREDIT_SCORE element to support the credit score disclosure and compliance requirements of the Fair and Accurate Credit Transactions Act (FACTA or FACT Act) that was signed into law in 2003. Here is a list of new CREDIT_SCORE attributes and their definitions: o FACTA Inquiries Indicator This indicator is set to Y when the borrower s Credit Score Value was negatively affected by the presence of credit inquiry records on their credit report. o Maximum Value This is the upper range of possible score values for a particular Credit Score Model. The score range values are required as part of the FACTA disclosure letter. o Minimum Value This is the lower range of possible score values for a particular Credit Score Model. The score range values are required as part of the FACTA disclosure letter. o Provider Name / Street Address / StreetAddress2 / City / State / Postal Code / URL Description These attributes describe the name, address and web site address of the company whose algorithm and methodology provide the Credit Score Value and Factors. Sample Expanded CREDIT SCORE Data Record <CREDIT_SCORE CreditScoreID="CRScoXPN01" BorrowerID="BorRec0001" CreditFileID="CRFilXPN01" _FACTAInquiriesIndicator="Y" NEW: Ver 2.3.1 _ModelNameType="ExperianFairIsaac" _CategoryType="FICO" NEW: Ver 2.4 _Value="575" _MinimumValue="300" NEW: Ver 2.4 _MaximumValue="850" NEW: Ver 2.4 _ProviderName="Fair Isaac Corp" NEW: Ver 2.4 _ProviderStreetAddress="??" NEW: Ver 2.4 _ProviderStreetAddress2="??" NEW: Ver 2.4 _ProviderCity="??" NEW: Ver 2.4 _ProviderState="??" NEW: Ver 2.4 _ProvidePostalCode="??" NEW: Ver 2.4 _ProviderURLDescription="??" NEW: Ver 2.4 CreditRepositorySourceType="Experian" > <_FACTOR _Code="38" _Text="Serious delinquency and public record or collection filed"/> <_FACTOR _Code="14" _Text="Length of time accounts have been established"/> <_FACTOR _Code="20" _Text="Length of time since legal item filed or collection item reported"/> <_FACTOR _Code="02" _Text="Delinquency reported on accounts"/> </CREDIT_SCORE> Page 3-29

Credit Response Section By Section Credit Score Record with an Exclusion Reason When the requested Credit Score data cannot be generated, normally some type of error or exclusion reason code is returned. When the MISMO CREDIT_SCORE element is created, the exclusion reason code is converted into a MISMO _ExclusionReasonType value. In the example below, the original Experian credit score data returned the Exclusion code 9000 (Credit Profile contains more than 500 tradelines, inquiries and public records. The Experian 9000 code would be represented in the MISMO format with a _ExclusionReasonType value of Not Scored File Too Long. Sample CREDIT SCORE Exclusion Data Record <CREDIT_SCORE CreditScoreID="CRScoXPN01" BorrowerID="BorRec0001" CreditFileID="CRFilXPN01" _ExclusionReasonType="NotScoredFileTooLong" _ModelNameType="ExperianFairIsaac" CreditRepositorySourceType="Experian" /> Page 3-30

Credit Response Section By Section CREDIT TRADE REFERENCE Element Usage: Merge = YES RMCR = YES Score Only = NO Required? No. Purpose: Contains a list of the names, addresses and contact information for the creditors listed in the credit liabilities and credit inquiry sections of the credit report. Some credit bureaus report this information under each liability and inquiry and some report it in a separate listing. The Credit Response DTD supports both options. Restrictions: None. Sample CREDIT TRADE REFERENCE Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_SCORE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE CreditTradeReferenceID="CRTrRf0138" _Name="AFFILIATED ACCEP CRP" _StreetAddress= 101 Main ST _City= Atlanta _State= GA _PostalCode= 30089 /> <CONTACT_DETAIL> <CONTACT_POINT _Type="Phone" _Value="7703303324"/> </CONTACT_DETAIL> <CREDIT_REPOSITORY _SourceType= Equifax _SubscriberCode= 321BC02496 /> <CREDIT_REPOSITORY _SourceType= Experian _SubscriberCode= 2681655 /> <CREDIT_REPOSITORY _SourceType= TransUnion _SubscriberCode= B 2509348 /> </CREDIT_TRADE_REFERENCE> <CREDIT_COMMENT...Additional Comment Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-31

Credit Response Section By Section CREDIT COMMENT Element Usage: Merge = YES RMCR = YES Score Only = NO Required? No. Purpose: Provides any type of additional comment text. The source could be the credit bureau, the repository bureau, the borrower or other source. Restrictions: None. Sample CREDIT COMMENT Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT _SourceType="Borrower"> <_Text> CONSUMER COMMENT: The reason I have very little credit is that I always pay cash. Now that I am trying to get a mortgage, I should not be penalized for practicing sound financial management in the past. </_Text> </CREDIT_COMMENT> <CREDIT_COMMENT...Additional Comment Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-32

Credit Response Section By Section CREDIT CONSUMER REFERRAL Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: Provides contact information for each of the credit data repositories used in the credit report. Restrictions: None. Sample CREDIT CONSUMER REFERRAL Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <CREDIT_BUREAU...Data Goes Here.../> <CREDIT_REPORT_PRICE...Data Goes Here.../> <CREDIT_REPOSITORY_INCLUDED...Data Goes Here.../> <REQUESTING_PARTY...Data Goes Here.../> <CREDIT_REQUEST_DATA...Data Goes Here.../> <CREDIT_ERROR_MESSAGE...Data Goes Here.../> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY... Data Goes Here.../> <CREDIT_FILE... Data Goes Here.../> <CREDIT_SCORE... Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL _Name="TRANS UNION - CREDIT BUREAU CENTRAL" _StreetAddress="2355 RED ROCK ST." _StreetAddress2="SUITE 200" _City="LAS VEGAS" _State="NV" _PostalCode="89102"> <CONTACT_DETAIL> <CONTACT_POINT _Type="Phone" _Value="7028713331"/> </CONTACT_DETAIL> </CREDIT_CONSUMER_REFERRAL> <CREDIT_CONSUMER_REFERRAL _Name="EQUIFAX CREDIT INFORMATION SERVICES" _StreetAddress="P O BOX 740241" _StreetAddress2="1150 LAKE HEARN DRIVE STE 460" _City="ATLANTA" _State="GA" _PostalCode="303740241"> <CONTACT_DETAIL> <CONTACT_POINT _Type="Phone" _Value="8006851111"/> </CONTACT_DETAIL> </CREDIT_CONSUMER_REFERRAL> <CREDIT_SUMMARY...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> </CREDIT_RESPONSE> Page 3-33

Credit Response Section By Section CREDIT SUMMARY Element Usage: Merge = YES RMCR = YES Score Only = NO Required? No. Purpose: Provides two methods for providing summary data. First is repeating _DATA_SET elements, each with a _Name and _Value attribute pairs. The second method is through a more traditional _Text element. The sample below shows both methods for the same set of summary data. When more than one CREDIT_SUMMARY element is provided, its optional _Name attribute can be used to label or describe each set of summary data. There is no industry standard, format or requirement for credit summary data. This structure allows complete flexibility in how summary data is expressed. Restrictions: None. Sample CREDIT SUMMARY Data <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY...Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <CREDIT_TRADE_REFERENCE...Data Goes Here.../> <CREDIT_COMMENT...Data Goes Here.../> <CREDIT_CONSUMER_REFERRAL...Data Goes Here.../> <CREDIT_SUMMARY _Name= Itemized Summary Data > <_DATA_SET _Name="Accts Paid As Agreed" _Value="61"/> <_DATA_SET _Name="Accts Currently Delinquent" _Value="6"/> <_DATA_SET _Name="All Delinquent Accts" _Value="10"/> <_DATA_SET _Name="Total Inquiries" _Value="27"/> <_DATA_SET _Name="Total Public Records" _Value="3"/> <_DATA_SET _Name="Total Liens" _Value="0"/> <_DATA_SET _Name="Total Judgments" _Value="3"/> <_DATA_SET _Name="Total Foreclosures" _Value="0"/> <_DATA_SET _Name="Total Bankruptcies" _Value="0"/> </CREDIT_SUMMARY> <CREDIT_SUMMARY _Name= Text Summary Data > <_Text> ACCOUNTS PAID AS AGREED: 61 PUBLIC RECORDS BREAKDOWN ACCOUNTS CURRENTLY DELINQUENT: 6 LIENS: 0 ALL DELINQUENT ACCOUNTS: 10 JUDGMENTS: 3 INQUIRIES: 27 FORECLOSURES: 0 PUBLIC RECORDS: 3 BANKRUPTCIES: 0 </_Text> </CREDIT_SUMMARY> </CREDIT_RESPONSE> Page 3-34

Credit Response Section By Section REGULATORY PRODUCT Element Usage: Required? Purpose: Merge = YES RMCR = YES Score Only = YES No. Provides results of database search using borrower demographic data to meet government regulatory requirements. One source of the regulatory product data is the Office of Foreign Assets Control (OFAC), a division of the U.S. Department of Treasury, which administers and enforces economic and trade sanctions based on U.S. foreign policy and national security goals. OFAC maintains a list of Specially Designated Nationals and Blocked Persons and the REGULATORY PRODUCT element shows the results of the search of that list. Restrictions: Available only for Version 2.3 and later. (In earlier versions the OFAC Alert data appears in the CREDIT FILE / ALERT MESSAGE elements.) Sample Credit Response with REGULATORY PRODUCT Element <CREDIT_RESPONSE MISMOVersionID="2.3" CreditReportIdentifier="A0000000560000" CreditReportFirstIssuedDate="2002-12-01" CreditReportType="MergePlus"> <BORROWER BorrowerID="BORID001" _BirthDate="1957-07-30" _FirstName="Usama" _LastName="Bin Laden" MaritalStatusType="Married"> <_RESIDENCE _StreetAddress="Unknown"/> </BORROWER> <REGULATORY_PRODUCT BorrowerID= BORID001 CreditFileID="A0001" CreditRepositorySourceType="TransUnion" _SourceType="OFAC" _ProviderDescription="OFACAdvisor" _ResultText="Possible Name Match Found in OFAC database" _ResultStatusType="Match" _DisclaimerText="THIS INFORMATION IS FOR ALERT PURPOSES ONLY AND IS NOT TO BE USED FOR DETERMINING A CONSUMER&apos;S ELIGIBILITY FOR CREDIT OR ANY OTHER FCRA PERMISSIBLE PURPOSE. PLEASE REFER TO THE OFAC CUSTOMER GUIDE."> <_MATCH _Type="FirstName"/> <_MATCH _Type="LastName"/> </REGULATORY_PRODUCT> </CREDIT_RESPONSE> Page 3-35

Credit Response Section By Section EMBEDDED FILE Element Usage: Merge = YES RMCR = YES Score Only = YES Required? No. Purpose: Provides an optional repeating element for holding a print image of the credit report or some other type of file. Attributes are provided for describing the file format and version. Restrictions: None. Before Version 2.4 Version 2.1.1 and later of EMBEDDED FILE have a MIME Type attribute that provides an industry standard method of identifying the content of the DOCUMENT element. For example, PDF documents have a MIME Type attribute value of application/pdf, and HTML documents are assigned a value of text/html. The current list of MIME Types is maintained on the IANA (Internet Assigned Numbers Authority) web site at: http://www.iana.org/assignments/media-types/. Version 2.1.1 and later also have a _Description that can be used to provide additional information about the embedded document. Sample EMBEDDED FILE Data (before Version 2.4) <CREDIT_RESPONSE MISMOVersionID="2.3" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY... Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <EMBEDDED_FILE _Type="PDF" MIMEType="application/pdf" NEW: Ver 2.1.1 _Version="1.2" _Name="Brick.pdf" _Description="Encoded PDF File" NEW: Ver 2.1.1 _EncodingType="Base64"> <DOCUMENT> <![CDATA[...File Data Goes Here...]]> </DOCUMENT> </EMBEDDED_FILE> </CREDIT_RESPONSE> Page 3-36

Credit Response Section By Section Version 2.4 and Later The EMBEDDED FILE element is now used in a number of other MISMO transactions. Beginning with Version 2.4 several additional attributes were added to this element to enhance its use in the Credit Response and other transactions. Version 2.4 and later added a required MISMOVersionID attribute to identify the MISMO version of the EMBEDDED FILE element structure being used. Version 2.4 and later changed _EncodingType from a text attribute to an enumerated attribute with the following valid values: Base64, QuotedPrintable. DeflateBase64, GzipBase64, and Other. When Other is used, enter the character set name into the _EncodingTypeOtherDescription attribute. Version 2.4 and later added a _CharacterEncodingSetType attribute to describe the character encoding set used for the embedded document, which may be different than the character encoding set used for the XML document. The valid values are: ISO88591, USASCII, UTF8, UTF16 and Other. When Other is used, enter the character set name into the _CharacterEncodingSetTypeOtherDescription attribute. Sample EMBEDDED FILE Data (Version 2.4 and later) <CREDIT_RESPONSE MISMOVersionID="2.4" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2002-01-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY... Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <EMBEDDED_FILE _Type="PDF" MISMOVersionID="2.4" NEW: Ver 2.4 MIMEType="application/pdf" _Version="1.2" _Name="Brick.pdf" _Description="Encoded PDF File" _EncodingType="Base64" _CharacterEncodingSetType="UTF8"> NEW: Ver 2.4 <DOCUMENT> <![CDATA[...File Data Goes Here...]]> </DOCUMENT> </EMBEDDED_FILE> </CREDIT_RESPONSE> Page 3-37

Credit Response Section By Section ALERT MESSAGE Element Usage: Required? Purpose: Merge = YES RMCR = YES Score Only = YES No. Provides an optional repeating element for holding alert messages reported by the repository bureaus or by the credit bureau. Restrictions: Available only for Version 2.4 and later. (In earlier versions the _ALERT_MESSAGE element could only appear as a child element of CREDIT_FILE. Beginning with Version 2.4 the _ALERT_MESSAGE element could appear as a child element of both CREDIT_RESPONSE and CREDIT_FILE.) Version 2.4.1.1 and later added BorrowerID and CreditFileID attributes to identify which Borrower(s) and which Credit File that the Alert Message was associated with. The example below shows _ALERT_MESSAGE elements returned as child elements of CREDIT_RESPONSE. For examples of CREDIT_FILE _ALERT_MESSAGE elements, see the earlier CREDIT FILE section of this chapter. Sample ALERT MESSAGE Elements Under CREDIT_RESPONSE <CREDIT_RESPONSE MISMOVersionID="2.4.1.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportFirstIssuedDate="2007-10-08" CreditReportType="Merge" CreditReportMergeType="Blend"> <BORROWER...Data Goes Here.../> <CREDIT_LIABILITY...Data Goes Here.../> <CREDIT_PUBLIC_RECORD...Data Goes Here.../> <CREDIT_INQUIRY... Data Goes Here.../> <CREDIT_FILE...Data Goes Here.../> <EMBEDDED_FILE...Data Goes Here.../> <_ALERT_MESSAGE _AdverseIndicator="N" _CategoryType="SSNVerification" BorrowerID="Bor001" CreditFileID="CF002"> <_Text> TUC: SSN from Request Issued: 1971-1972 State: OH </_Text> </_ALERT_MESSAGE> <_ALERT_MESSAGE _AdverseIndicator="Y" _CategoryType="DemographicsVerification" _Code="1503" _Type="TransUnionHAWKAlert" BorrowerID="Bor001" CreditFileID="CF003"> <_Text> HAWK ALERT: (1503) TUC FILE PREVIOUS ADDRESS HAS BEEN REPORTED MISUSED AND REQUIRES FURTHER INVESTIGATION </_Text> </_ALERT_MESSAGE> </CREDIT_RESPONSE> Page 3-38

Credit Error Response Chapter 4: Credit Error Response Currently errors in the XML Credit Request or errors that occur during processing can be reported in the CREDIT ERROR MESSAGE element of CREDIT RESPONSE. The RESPONSE element of the Response Transaction Envelope also contains a STATUS element that can also be used for reporting errors codes and descriptions. A recommended list of standard codes and descriptions are shown on the next page. This is the same list that is used in the ANSI X12 824 Application Advise Transaction. The sample data below demonstrates how to report an error in the credit request. Sample Error Report <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE RESPONSE_GROUP SYSTEM "CreditResponse_v2_1.dtd"> <RESPONSE_GROUP MISMOVersionID="2.1"> <RESPONDING_PARTY _Name="ABC Credit Services"/> <RESPONSE ResponseDateTime="2001-11-15T12:38:40" InternalAccountIdentifier="GEP9999"> <RESPONSE_DATA> <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CreRpt0001" CreditReportType="Error"> <CREDIT_BUREAU _Name="ABC Credit Services"/> <CREDIT_ERROR_MESSAGE _SourceType="CreditBureau"> <_Text> Transaction Type: XML REQUEST ERROR </_Text> <_Text> Missing Borrower Address </_Text> </CREDIT_ERROR_MESSAGE> </CREDIT_RESPONSE> </RESPONSE_DATA> <STATUS _Code= E005 _Condition= Request Failed _Description= Invalid or Missing Street Address /> </RESPONSE> </RESPONSE_GROUP> Page 4-1

Credit Error Response List of Suggested Error Codes and Descriptions Error Code E001 E002 E003 E004 E005 E006 E007 E008 E010 E011 E012 E013 E014 E015 E016 E017 E018 E019 E020 E021 E022 E023 E024 E025 E026 E027 E028 E029 E030 E031 E032 E033 Error Description Unable to process request at this time Invalid or Missing Borrower First Name Invalid or Missing Borrower Last Name Invalid or Missing Borrower SSN Invalid or Missing Street Address Invalid or Missing City Name Invalid or Missing State Code Invalid or Missing Postal Code Invalid or Missing Co-borrower First Name Invalid or Missing Co-borrower Last Name Invalid or Missing Co-borrower SSN Invalid or Missing Previous Street Address Invalid or Missing Previous City Name Invalid or Missing Previous State Code Invalid or Missing Previous Postal Code Invalid House or Box Number Invalid Street Type Invalid Address Direction Invalid Apartment Number Invalid Borrower Middle Name Invalid Borrower Generation Invalid Borrower Date of Birth Invalid Co-borrower Middle Name Invalid Co-borrower Generation Invalid Co-borrower Date of Birth Invalid Previous Apartment Number Invalid Previous Address Type Invalid Previous House or Box Number Invalid Previous Street Type Invalid Previous Address Direction Invalid Product or Service Type Invalid Action Type Page 4-2

Credit Error Response Error Code E034 E035 E036 E037 E038 E046 E051 E061 E062 Error Description Invalid Report Type Invalid Credit Request Type Individual / Joint Invalid Client Account Identifier Invalid Password Invalid Login or Password Invalid Login ID Client Account Not Active Reissue Request Demographics Do Not Match Original Report Missing Requested By Name E101 E102 File Is Not Well Formed XML File Does Not Validate Against DTD or Schema E900 E901 E902 E903 E999 Repository Not Available Experian Not Available Trans Union Not Available Equifax Not Available Other Error Page 4-3

Credit Status Response Chapter 5: Credit Status Response When a lender sends a Status Query Request (see page 2-11), the Credit Bureau may elect to send an electronic response. To generate a status response, set the CREDIT RESPONSE element s Credit Report Type attribute to Status, and supply the value for the Credit Report Identifier attribute. The RESPONSE element of the Response Transaction Envelope also contains a STATUS element that can also be used for reporting status codes and descriptions. The next page has a list of status codes and descriptions that have been established by the Credit Work Group. The sample data below demonstrates how to request and report the status of an existing request. Sample Status Query Request <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE REQUEST_GROUP SYSTEM "CreditRequest_v2_1.dtd"> <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="MFC Mortgage"/> <RECEIVING_PARTY _Name="ABC Services"/> <REQUEST RequestDatetime="2002-01-25T15:44:12" InternalAccountIdentifier="ABC-0732"> <REQUEST_DATA> <CREDIT_REQUEST_DATA CreditReportRequestActionType="StatusQuery" CreditReportType="RMCR" CreditReportIdentifier= 02-0027388 /> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Sample Status Response <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE RESPONSE_GROUP SYSTEM "CreditResponse_v2_1.dtd"> <RESPONSE_GROUP MISMOVersionID="2.1"> <RESPONDING_PARTY _Name="ABC Credit Services"/> <RESPOND_TO_PARTY _Name="MFC Mortgage"/> <RESPONSE ResponseDateTime="2002-01-25T15:45:16" InternalAccountIdentifier="ABC-0732"> <RESPONSE_DATA> <CREDIT_RESPONSE MISMOVersionID="2.1" CreditReportIdentifier="02-0027388" CreditReportType="Status"> </CREDIT_RESPONSE> </RESPONSE_DATA> <STATUS _Code= S006 _Condition= Still Processing _Description= Waiting for Employment Verification /> <STATUS _Code= S007 _Condition= Still Processing _Description= Waiting for Landlord Verification /> </RESPONSE> </RESPONSE_GROUP> Page 5-1

Credit Status Response List of Suggested Status Codes and Descriptions Status Code S001 S002 S003 S004 S005 S006 S007 Status Description Initial Request Not Found Waiting for Equifax Data Waiting for Experian Data Waiting for Trans Union Data Waiting for Public Records Data or Verification Waiting for Employment Data or Verification Waiting for Landlord Data or Verification S010 S011 S012 File Is Being Processed File Is On Hold In Final Review Before Delivery S999 Other Status Page 5-2

Credit Reporting DTD Change List Chapter 6: Credit Reporting DTD Change List Version 2.1.1 The following table summarizes the changes to the MISMO Credit Reporting DTD since Version 2.1. Details of the changes in each release version are contained in the CreditReportingChangeList#_#.doc document that is issued with each updated DTD. Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.1.1 2002-10-12 Ver. 2.1.1 Update PREFERRED RESPONSE PREFERRED RESPONSE Use Embedded File Indicator MIME Type Added Indicates whether or not the response format being requested should be contained in the EMBEDDED FILE element ( Y ), or whether it should be provided as a separate response file ( N ). Added Used to more accurately represent the type of response data being requested. CREDIT REQUEST SERVICE PAYMENT Added Facilitates billing of online consumer reports using a credit card or other payment method. CREDIT REQUEST DATA CREDIT REQUEST DATA Credit Report Request Action Type Credit Report Product Description Added enumerations An additional enumeration value, Retrieve is being added to the Credit Report Request Action Type attribute to allow an existing, completed report to be retrieved and delivered. Other is being added when the values in the enumerated list do not contain the desired action type. The action description text for Other will be stored in the new Credit Report Request Action Type Other Description attribute. Added More clearly describes the credit report product being requested. The attribute could be used to specify print image type, sort order or a credit-bureauspecific product name. Page 6-1

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.1.1 2002-10-12 Ver. 2.1.1 Update EMPLOYER LANDLORD CREDIT INQUIRY CREDIT COMMENT Added In a request for update or verification of liability or public record data, the user can use the CREDIT COMMENT element to specify what needs to be updated or verified. CREDIT REQUEST CREDIT INQUIRY Added Used to request an update or verification of the status of a credit inquiry that had appeared on an earlier credit response. CREDIT SCORE MODEL NAME CREDIT LIABILITY UNMERGED LIABILITY CURRENT RATING HIGHEST ADVERSE RATING MOST RECENT ADVERSE RATING PRIOR ADVERSE RATING CREDIT LIABILITY UNMERGED LIABILITY CREDIT PUBLIC RECORD UNMERGED PUBLIC RECORD Type Months Remaining Count Type Charge Off Date Bankruptcy Adjustment Percent Bankruptcy Repayment Percent Bankruptcy Exempt Amount Bankruptcy Type Added enumerations Update Credit Score Model Name Type attributes in the Credit Request and Credit Response to add the following Fair Isaac Next Gen score models: o ExperianFairIsaacAdvanced o TransUnionPrecision NOTE: Equifax Pinnacle, also a Next Gen score model, was added in the original Version 2.1. Added A calculated data item that shows the number of months remaining until payoff on monthly installment accounts. Added enumerations Update the rating type attributes to add three new enumerations to the Rating Type attributes: o BankruptcyOrWageEarnerPlan o ForeclosureOrRepossession o CollectionOrChargeOff Added This is the date that the creditor put the account in a charge off status and declared the account balance as uncollectable. Added Several new bankruptcyrelated attributes were added to the public record structure. Page 6-2

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.1.1 2002-10-12 Ver. 2.1.1 Update CREDIT INQUIRY EMBEDDED FILE Street Address Street Address 2 City State Postal Code Description MIME Type Added Identify the address of the entity making the credit inquiry. Added The Description attribute provides additional information about the embedded file, such as the software version that generated the file. The MIME Type was added to more accurately represent the type of the response data in the DOCUMENT element. Page 6-3

Credit Reporting DTD Change List Version 2.3 Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.3 2003-06-22 Ver. 2.3 Update REQUEST GROUP SUBMITTING PARTY Modified More than one occurrence of this element is now allowed. SUBMITTING PARTY SUBMITTING PARTY SUBMITTING PARTY RECEIVING PARTY PREFERRED RESPONSE REQUEST LOAN APPLICATION CREDIT REQUEST CREDIT RESPONSE CREDIT REQUEST DATA Identifier Sequence Identifier Login Account Identifier Login Account Password Identifier Version Identifier Requesting Party Branch Identifier (multiple elements and attributes) DATA INFORMATION Credit Report Transaction Identifier Added Identifier that is assigned to the SUBMITTING PARTY, as defined by the trading partners. Added Unique identifier assigned to each SUBMITTING PARTY to indicate the order in which they handled the transaction. Added These attributes are supplied when Requesting Party needs to pass validation data of a portal to the Receiving Party. Added Identifier that is assigned to the RECEIVING PARTY, as defined by the trading partners. Added Designates what version of a response the Requesting Party would like to receive. Added This branch identifier is sometimes required for billing purposes. Added Updated numerous elements and attributes for AUS Versions 2.2 and 2.3. Added Allows identification of version of data structures that were used in the creation of the Credit Request and Credit Response. Added Uniquely identifies a specific instance of a credit report transaction. CREDIT BUREAU Disclaimer Text Added Provides a location to store the legal disclaimer that normally appears on printed credit reports. CREDIT INQUIRY Credit Liability ID Added Links the Credit Inquiry to a Credit Liability that resulted from the inquiry, if it exists. Page 6-4

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.3 2003-06-22 Ver. 2.3 Update CREDIT INQUIRY CREDIT LIABILITY Credit Loan Type Added enumerations New values added were: o DeferredStudentLoan o ConstructionLoan o SecondMortgage o BiMonthlyMortgageTermIn Years o SemiMonthlyMortgagePayment CREDIT LIABILITY Account Balance Date Added The date that the liability s unpaid balance was reached. CREDIT LIABILITY CREDIT LIABILITY / LATE COUNT CREDIT PUBLIC RECORD CREDIT SCORE MODEL NAME CREDIT SCORE Balloon Payment Due Date PERIODIC LATE COUNT Account Ownership Type Type. Model Name Type Added The date that the full balance is due on the account. Added This element provides the number of times the account has been 30, 60, 90 or 120 days delinquent for each of the previous three years. Added Describes the ownership relation of the borrower(s) to the public record. The enumeration values are: o Individual o Joint o Terminated Added enumerations Options for new Equifax score models are being added: o EquifaxBeacon5.0 o EquifaxBeacon5.0Auto o EquifaxBeacon5.0BankCard o EquifaxBeacon5.0 Installment o EquifaxBeacon5.0Personal Finance o EquifaxPinnacle2.0 CREDIT SCORE Exclusion Reason Type Added enumerations Two additional values: o NotScoredRequirementNot Met o NotScoredFileCannotBe Scored CREDIT COMMENT Reported Date Added The date that comment was reported by the credit bureau. Page 6-5

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.3 2003-06-22 Ver. 2.3 Update CREDIT COMMENT CREDIT FILE / BORROWER CREDIT FILE / BORROWER CREDIT FILE / BORROWER CREDIT RESPONSE Type Type Other Description ALIAS EMPLOYER RESIDENCE REGULATORY PRODUCT Added Enumerations of this new attribute describe the type of comment: o BureauRemarks o ConsumerStatement o Instruction o Other o PublicRecordText Added Provides element for storing parsed Alias or AKA (Also Known As) names. Added Provides element for storing parsed employer data in addition to the existing Unparsed Employment attribute. Added Provides element for storing parsed residence address in addition to the existing Unparsed Address attribute. Added This element stores the results of a search of the borrower demographic data in the U.S. Dept Treasury OFAC database. This is used to identify individuals on a list of Specially Designated Nationals or Blocked Persons. EMBEDDED FILE ID Added Unique identifier for each embedded file element. Page 6-6

Credit Reporting DTD Change List Version 2.3.1 Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.3.1 2004-12-03 Ver. 2.3.1 Update CREDIT LIABILITY CREDIT FILE ALERT MESSAGE CREDIT FILE ALERT MESSAGE CREDIT FILE ALERT MESSAGE CREDIT FILE ALERT MESSAGE Credit Counseling Indicator Adverse Indicator Category Type Category Type Other Description Type Added This indicator is set to Y when the credit liability is being managed by a credit counseling agency. Added This indicator is set to Y when the Credit File Alert Message contains information which may be considered adverse and may require further investigation or other action. Added Describes the general category of the alert message. This allows for automated processing by systems reading the credit alert messages. The enumeration values are: o CreditFileSuppressed o DeathClaim o DemographicsVerification o FACTAActiveDuty o FACTAAddressDiscrepancy o FACTAFraudVictim Extended o FACTAFraudVictimInitial o FACTARiskScoreValue o Other o SSNVerification Added When Credit File Alert Message Category Type is set the Other, enter its value in this data element. Added enumerations Two additional values: o TransUnionHighRiskFund Alert o TransUnionIDMismatchAle rt Page 6-7

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.3.1 2004-12-03 Ver. 2.3.1 Update CREDIT FILE Result Status Type Added Describes the resulting status of the request for a credit file from a credit repository bureau. The full reason for a Credit File not being returned will be reported in the Credit Error Message data element. The enumeration values are: o FileReturned o NoFileReturnedCreditFreez e o NoFileReturnedBorrowerIs A Minor o NoFileReturnedNoHit o NoFileReturnedThinFile o NoFileReturnedFraudulent RequestData o NoFileReturnedBadAccess Code o NoFileReturnedInadequate RequestData o NoFileReturnedError o Other CREDIT FILE CREDIT REPOSITORY CREDIT SCORE Result Status Type Other Description Source Type Other Description FACTA Inquiries Indicator Added When Credit File Result Status Type is set to Other, enter its value in this data element. Added When Credit Repository Source Type is set to Other, enter its value in this data element. Added This indicator is set to Y when the borrower s Credit Risk Score Value was negatively affected by the presence of credit inquiry records on their credit report. There may be FACT Act compliance requirements related to this alert message. Page 6-8

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.3.1 2004-12-03 Ver. 2.3.1 Update CREDIT SCORE Model Name Type Added enumerations Twelve additional values: o ExperianFairIsaacAdvanced 2.0 o ExperianScorexPLUS o FICOExpansionScore o FICORiskScoreClassic98 o FICORiskScoreClassicAuto 98 o FICORiskScoreClassic Bankcard98 o FICORiskScoreClassic InstallmentLoan98 o FICORiskScoreClassic Personal Finance98 o FICORiskScoreClassic04 o FICORiskScoreNextGen00 o FICORiskScoreNextGen03 o TransUnionPrecision03 Page 6-9

Credit Reporting DTD Change List Version 2.4 Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update REQUEST GROUP RECEIVING PARTY Modified (by Enveloping Work Group) Previously only a single optional RECEIVING PARTY element was allowed, now multiple RECEIVING PARTY elements can be appear. REQUEST GROUP _Identifier Added (by Enveloping Work Group) REQUESTING PARTY _TransactionIdentifier _ID Added (by Enveloping Work Group) RECEIVING PARTY _ID Added (by Enveloping Work Group) SUBMITTING PARTY RESPONSE GROUP RESPONDING PARTY RESPOND TO PARTY CONTACT DETAIL _TransactionIdentifier _ID SUBMITTING PARTY _Identifier _TransactionIdentifier _ID _TransactionIdentifier _ID _Identifier _FirstName _LastName _MiddleName _NameSuffix _SequenceIdentifier _ID Added (by Enveloping Work Group) Added (by Enveloping Work Group) Added (by Enveloping Work Group) Added (by Enveloping Work Group) Added (by Enveloping Work Group) CONTACT POINT _RoleType Added Enumeration (by Enveloping Work Group) Added one value: o Other CONTACT POINT _RoleTypeOther Description Added (by Enveloping Work Group) Page 6-10

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update PREFERRED RESPONSE PREFERRED RESPONSE _Format _ID Added Enumeration (by Enveloping Work Group) Added one value: o TIFF Added (by Enveloping Work Group) REQUEST _Identifier Added (by Enveloping Work Group) RESPONSE _Identifier Added (by Enveloping Work Group) KEY _ID Added (by Enveloping Work Group) DATA VERSION CREDIT BUREAU CREDIT REQUEST DATA _Name _Number _TechnologyProvider Name _ADDON Modified Previously these attributes were required, now they are optional. Added New optional, repeating element for additional product info descriptions. _ADDON _ID Added Unique identifier for each ADDON element. _ADDON _ADDON Credit Request Product Name Addon Identifier Credit Request Product Name Addon Description Added The vendor s identifier for the add-on product. Added The vendor s description for the add-on product. CREDIT RESPONSE _ALERT_MESSAGE Added The _ALERT_MESSAGE element is currently used as a child element of CREDIT_FILE. In this release, it now also appears as a child of CREDIT_RESPONSE. This allows alert messages that are not related to a credit file. _ALERT_MESSAGE _Type Added Enumeration One new value: o ExperianFraudShield CREDIT_RESPONSE/ BORROWER _AgeAtApplicationYears Added This attribute has been added for the Credit Response. It already is used in the Credit Request Borrower element. Page 6-11

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update CREDIT SCORE MODEL NAME CREDIT SCORE MODEL NAME _Type CreditScoreCategoryType CreditScoreCategoryType OtherDescription Added Enumerations The following new score model names have been added: o ExperianFICOClassicV3 o EquifaxBankruptcy NavigatorIndex02781 o EquifaxBankruptcy NavigatorIndex02782 o EquifaxBankruptcy NavigatorIndex02783 o EquifaxBankruptcy NavigatorIndex02784 o EquifaxVantageScore o ExperianVantageScore o TransUnionVantageScore o EquifaxVantageScore Added The Category Type is an enumerated list that allows credit score models to be identified by their general category: o Bankruptcy o CreditRepository o FICO o FICONextGen o ThinFile o Other CREDIT SCORE _ModelNameType Added Enumerations The following new score model names have been added: o ExperianFICOClassicV3 o EquifaxBankruptcy NavigatorIndex02781 o EquifaxBankruptcy NavigatorIndex02782 o EquifaxBankruptcy NavigatorIndex02783 o EquifaxBankruptcy NavigatorIndex02784 o EquifaxVantageScore o ExperianVantageScore o TransUnionVantageScore o EquifaxVantageScore Page 6-12

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update CREDIT SCORE CREDIT SCORE _CategoryType _CategoryTypeOther Description _MaximumValue _MinimumValue _ProviderName _ProviderAddress _ProviderAddress2 _ProviderCity _ProviderState _ProviderPostalCode _ProviderURL Description Added The Category Type is an enumerated list that allows credit score models to be identified by their general category: o Bankruptcy o CreditRepository o FICO o FICONextGen o ThinFile o Other Added These attributes were added to allow the credit bureau to supply data that lenders need to report in consumer letters regarding their credit scores. CREDIT COMMENT _Type Added Enumeration The following new value was added to hold the Experian Status Code value for the credit comment text: o StatusCode CREDIT INQUIRY CREDIT LIABILITY UNMERGED LIABILITY CreditLoanType Added Enumerations The following new loan types have been added: o Camper o ConditionalSalesContract Refinance o HomeEquity o ManufacturedHome o MobilePhone o UtilityCompany Page 6-13

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update CREDIT INQUIRY _PurposeType Added New attribute that identify the purpose of the credit inquiry,with the following enumerations: o AutomatedMortgage Report o CreditGranting o CreditGrantingPossible AdditionalOffers o CheckingAccount o CheckingOrSavings PossibleAdditionalOffers o CreditWatch o FACTInquiryFraudCheck Requested o HAWKMatchReceived o InsuranceUnderwriting o LegitimateBusiness Purpose o Licensing o ManualMortgage o PermissiblePurposeID Profile o ServiceActivationPossible AdditionalOffers o SkipTrace o UtilityCompany o Other CREDIT INQUIRY _PurposeTypeOther Description Added Used for description when Purpose Type is Other. CREDIT INQUIRY _ResultType Added Use this in place of existing _InquiryResultType attribute which is being deprecated. It has the same enumerated list: o AccountClosed o ApplicationPending o Declined o DidNotInquire o NoOpenAccount o NotALender o OpenAccountNumberNot Issued o OpenDiscovered o OpenPrimaryAccount o ReportingAgencyInquiry o Unknown CREDIT INQUIRY _InquiryResultType Deprecated Use _ResultType instead of this attribute. Page 6-14

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update CREDIT LIABILITY UNMERGED LIABILITY CREDIT PUBLIC RECORD UNMERGED PUBLIC RECORD CREDIT PUBLIC RECORD UNMERGED PUBLIC RECORD CREDIT PUBLIC RECORD UNMERGED PUBLIC RECORD EMBEDDED FILE EMBEDDED_FILE EMBEDDED_FILE _AccountOwnershipType CONTACT_DETAIL _StreetAddress _StreetAddress2 _City _State _PostalCode _Type _EncodingType _EncodoingTypeOther Description _CharacterSetEncoding Type _CharacterSetEncoding TypeOtherDescription _SequenceIdentifier _CreatedDateTime _MISMOVersionID Added Enumeration One new value: o Deceased Added This element was added to hold phone number and other contact info for the court reporting the public record data. Added These attributes were added to hold the address for the court reporting the public record data. Added Enumerations The following new values were added: o ChildSupport o FamilySupport o MechanicsLien o MedicalLien o SpouseSupport Modified This attribute was changed from a text attribute to an enumerated attribute with the following values: o Base64 o QuotedPrintable o DeflateBase64 o GzipBase64 o Other Added These attributes were added to identify the character set used for the embedded file document. The enumerated values are: o ISO88591 o USACSII o UTF8 o UTF16 o Other Added New attributes. LOAN APPLICATION (various changes) Updated to AUS v2.4 Specification Page 6-15

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4 2007-01-04 Ver. 2.4 Update LOAN_APPLICATIO N/ BORROWER LOAN_APPLICATIO N/ BORROWER/ _RESIDENCY EMPLOYER _FirstName _LastName _SSN BorrowerResidencyBasis Type CREDIT_COMMENT VERIFICATION Modified These attributes were previously defined as required, but now are optional. Added Enumeration One new value: o Unknown Added These two elements were added to allow additional comments and verification status to be used for supplemental or corrected reports. Page 6-16

Credit Reporting DTD Change List Version 2.4.1.1 Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4.1.1 2007-10-30 Ver. 2.4.1.1 Update CREDIT REQUEST CREDIT REQUEST DATA CREDIT BUREAU EMBEDDED FILE Credit Report Request Action Type FNM Credit Bureau Identifier Added This is the same structure currently used in the CREDIT RESPONSE element. It has been added to the CREDIT REQUEST element to allow borrower authorizations, loan applications in a print format to be included with a request. Changed enumeration definition The following value s definition was updated: o Submit: Submit or add as a new request. May be subject to duplicate checking. Duplicate checking is the process where the credit bureau determines if the report data already exists on their system, and may return this previously pulled data instead of requesting new repository data. Added enumerations The following new values were added: o ForceNew: Add as a new request and force new data to be requested from the repository bureaus. o SecondaryUseNotification: This option notifies the Credit Bureau that the previously issued credit response (specify Credit Report Identifier) has been reviewed by the additional users (specify in KEY element). A response transaction does not need to be returned by the Credit Bureau. Added - This is the numeric identifier assigned by Fannie Mae to the credit bureau providing the credit report. Page 6-17

Credit Reporting DTD Change List Ver. Issue Date Parent Element ELEMENT or Attribute Change Description 2.4.1.1 2007-10-30 Ver. 2.4.1.1 Update ALERT MESSAGE Borrower ID Credit File ID Added These attributes have been added to the existing ALERT MESSAGE element so that the alert message can be linked to the related borrower(s) and to the source credit file(s). The ALERT MESSAGE element is a child of both the CREDIT RESPONSE and CREDIT FILE elements. Page 6-18

Questions and Answers Chapter 7: Questions and Answers What are the minimum elements required for a Merge Credit Report? There are several data elements that are required to successfully process a request for a Merge Credit Report. Individual credit bureaus may have additional minimum requirements. Internal Account Identifier (attribute of REQUEST element) This is the Account ID assigned by the credit bureau. This ID allows the credit bureau to retrieve your trading partner profile and properly bill for services. Requesting Party Requested By Name (attribute of CREDIT REQUEST element) Identifies who requested the credit report. This name normally appears on the credit report and sometimes on the credit bureau invoice. Credit Request Options (attributes of CREDIT REQUEST DATA) o o o o Set BorrowerID values for each borrower included in this request. Set Credit Report Requested Action Type value to Submit. Set Credit Report Type value to Merge. Set the credit repositories that are to be accessed. Borrower Data (part of LOAN APPLICATION element) Set the full borrower name (including generation), current address, SSN and a BorrowerID value. Complete the same data for co-borrower, if applicable. Sample Minimal Merge Credit Request File (MISMO Version 2.1): <REQUEST_GROUP MISMOVersionID="2.1"> <REQUEST InternalAccountIdentifier="ABC-0732"> <REQUEST_DATA> <CREDIT_REQUEST MISMOVersionID="2.1" RequestingPartyRequestedByName="Sean R"> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" BorrowerID="Bor1" CreditRequestDateTime="2002-01-08T17:19:01" CreditReportRequestActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <LOAN_APPLICATION> <BORROWER BorrowerID="Bor1" _BirthDate="1972-03-09" _FirstName="MARION" _LastName="BRICK" _SSN="530889999"> <_RESIDENCE _StreetAddress="3750 S BRANDES AV # 242" _City="LAS VEGAS" _State="NV" _PostalCode="89103"/> </BORROWER> </LOAN_APPLICATION> </CREDIT_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Page 7-1

Questions and Answers What is the MISMO XML equivalent to the X12 Rating Remarks? The X12 Rating Remarks code was an attempt to summarize all of the information about a liability record into a single remark code. For example, on a single liability there could be a Dispute flag, an Insurance Claim, a Past Due amount and a MOP indicating Not Paid As Agreed. All are valid X12 Rating Remarks. Should we pick the "worst" of the possible X12 Rating Codes that match one of the above? In another example, there might be a liability that shows a MOP of Current - Pays as Agreed and a comment that shows that in the past the account had been in Foreclosure. Which X12 Rating Remarks code do you pick in this case? In the MISMO XML credit report we provide elements for all of the rating data reported by the repositories. Then, the automated underwriting and other credit rating engines can select the data they want to use in their business rules to arrive at a credit decision. The X12 Rating Remarks list was too limiting and placed too much evaluation in the hands of the credit bureau software. The MISMO XML Credit Reporting standard provides a palette of data for the evaluation engines to choose from. Which credit response elements indicate that a request to a credit repository failed? In the response transaction sample below, three repositories were requested as shown in the CREDIT REQUEST DATA container, but data from only two repositories were returned as indicated in the CREDIT RESPONSE container. The CREDIT ERROR MESSAGE container displays the reason for the data not being returned from the third repository. Sample Showing Repositories Requested and Repositories Reported: <CREDIT_RESPONSE MISMOVersionID="2.1" CreditReportType="Merge"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="N" _TransUnionIndicator="Y"/> <CREDIT_REQUEST_DATA CreditRequestID="CRReq0001" CreditReportType="Merge" CreditRequestType="Individual"> <CREDIT_REPOSITORY_INCLUDED _EquifaxIndicator="Y" _ExperianIndicator="Y" _TransUnionIndicator="Y"/> </CREDIT_REQUEST_DATA> <CREDIT_ERROR_MESSAGE _SourceType="Experian"> <_Text>Experian: Invalid Security Password</_Text> </CREDIT_ERROR_MESSAGE> <...Other Data Goes Here.../> </CREDIT_RESPONSE> Page 7-2

Questions and Answers Where is the Whose File flag for liabilities, public records, etc.? During several Credit Work Group meetings, the methods of identifying ownership of liabilities, public records, risk scores and inquiries were discussed. The conclusion was that the method of using Borrower / Coborrower / Joint for ownership codes had reached the end of its useful life. Throughout the MISMO DTD the "Borrower / Coborrower / Joint" coding that was used in X12 was dropped. Using Borrower ID attribute rather than the "B/C/J" code, allows an XML "loan package" to have multiple borrower sets, with a credit report for each borrower or borrower pair, using Borrower ID to link credit report data to the correct borrowers. The sample credit report files that can be downloaded from the MISMO web site contain numerous examples of the borrower ID/IDREF usage. If users feel more comfortable with the Borrower/Coborrower labels, they can still identify one borrower as Borrower ID="Borrower", and the other as Borrower ID="Coborrower". Then in the liability, public record, inquiry, hit level, or score records that refer to the borrower and/or coborrower, they would use the proper attribute: BorrowerID="Borrower" BorrowerID="Coborrower" BorrowerID="Borrower Coborrower" (for joint ownership). Alternatively, the Borrower ID could be set to the borrower s SSN or name. If the first borrower was Jonathan Consumer and his spouse was Mary Consumer, and we used their names as the Borrower ID values, then the Borrower ID values in liability records would refer to whichever borrower they were associated with. In the data sample below, the American Express account belongs to Jonathan, the Ford Motor Credit account belongs to Mary and the Countrywide account belongs to both of them. Sample Data Showing Which Borrower Owns a Liability: <BORROWER BorrowerID="Jonathan_Consumer" _FirstName="JONATHAN" _LastName="CONSUMER" _SSN="548603388"/> <BORROWER BorrowerID="Mary_Consumer" _FirstName="MARY" _LastName="CONSUMER" _SSN="556600290"/> <CREDIT_LIABILITY BorrowerID="Jonathan_Consumer" <_CREDITOR _Name="AMERICAN EXPRESS"/> <!-- Other Liability Data Elements --> </CREDIT_LIABILITY> <CREDIT_LIABILITY BorrowerID="Mary_Consumer" <_CREDITOR _Name="FORD MOTOR CREDIT"/> <!-- Other Liability Data Elements --> </CREDIT_LIABILITY> <CREDIT_LIABILITY BorrowerID="Jonathan_Consumer Mary_Consumer" <_CREDITOR _Name="COUNTRYWIDE"/> <!-- Other Liability Data Elements --> </CREDIT_LIABILITY> Page 7-3

Questions and Answers Why is the list of Loan App Liability Types different from the Loan Types used in the Credit Response? The Liability Type enumerations used in the Loan Application contain items like Alimony, Child Care, HELOC, Installment, Mortgage Loan, Open 30 Day Charge Account, and Revolving. These enumerations are okay for their use as a general description of Section 6 Liabilities of the loan application. But from a Credit Reporting perspective they are a mix of reason for the loan (such as Alimony Child Care, HELOC, Mortgage Loan) and the contractual loan repayment methods (such as Installment, Open 30 Day Charge, Revolving). The Credit Liability element splits this list into several attributes: Credit Liability Loan Type (the reason for the loan) and Credit Liability Account Type (contractual loan repayment method). The attributes used in Credit Liability more closely match the data types that lenders report to the credit data repositories (Equifax, Experian and Trans Union) and offer much more detailed information about the liability account, which is necessary for credit reporting purposes. Page 7-4

Credit Report Freeze Laws Chapter 8: Credit Report Freeze Laws Recommendation Background California In 2002, the California state legislature enacted SB 168 (Bowen), which provides for the consumer initiated "freezing" of credit reports. The law requires that the Credit Repositories (Equifax, Experian, Trans Union etc.) provide, at the consumer s request, a Personal Identification Number (PIN), which can be used to freeze or un-freeze the consumer s credit file. The PIN number is to be submitted with credit inquiries, to enable the return of that consumer s file; otherwise a "locked file" response is generated. Here is an excerpt from the web site: http://www.fightidentitytheft.com/legislation_california_sb168.html Credit Report Freeze SB 168 also prevents identity theft by giving people the right to "freeze" access to their credit reports. Placing a security freeze on your credit reports means an identity thief, even one who has your name, address, Social Security number, birth date and more, will not be able to get new loans and credit in your name. That's because lenders, retailers, utilities and other businesses need access to a credit report to review and approve new credit, loans, and services. At the same time, SB 168 makes sure people who've frozen their credit reports can still get new loans and credit for themselves. Credit bureaus are required to set up a PIN-based system to allow people with frozen credit reports to contact the credit bureau, provide a PIN or password, and allow their credit report to be released to a specific lender or for a specific period of time. Credit bureaus are obligated to release the report within three business days of such a request. The credit report freeze provisions of SB 168 become effective January 1, 2003. To support the CA Credit Report Freeze law, Equifax and Trans Union will supply borrowers with an alphanumeric PIN, which can contain up to 8 characters for Trans Union and 4 characters for Equifax. Equifax accepts one PIN per credit request, while Trans Union can supply one PIN per borrower. At the current time Experian does not use a PIN for unfreezing the borrower credit file. Experian will unfreeze a credit file for specific creditors at the borrower s request. Page 8-1

Credit Report Freeze Laws Texas September 1, 2003 the Texas state legislature enacted SB 473 that contains many provisions similar to the California law regarding a Credit Report Freeze. Unlike the current California law the Texas bill s security alert provisions require the user of a credit file that contains a security alert to take reasonable steps to verify the consumer s identity before the user can lend money, extend credit or authorize and application Credit bureaus are required to notify users who request a report of the existence of a security alert on the credit file, and to deliver any contact telephone number provided by the consumer. A person who receives notification of a security alert must take reasonable steps to verify the consumer s identify before entering into a transaction with the consumer, including steps to contact the consumer using the contact telephone number of the consumer provided one. Equifax has enacted a procedure for allowing Texas consumers to release their credit data to a specific lender, similar to the procedure they implemented for support of the California law. Users will provide a four-digit consumer PIN that will authorize the release of their credit data to a specific lender. Consumers may also lift the credit freeze for a period of time by contacting Equifax. Trans Union is using the same procedures for Texas consumers that were enacted for California consumers. Experian will continue to unfreeze a credit file for specific creditors at the borrower s request. MISMO Credit Work Group Recommendations At the MISMO Credit Work Group meeting on September 10, 2003 in Detroit, the group agreed to use the same procedures developed for passing PIN values in XML and X12 request transactions for California consumers, and use these for Texas or any other states that enact Credit Freeze laws. During follow-up emails on the Credit Reporting List Serve over the next couple of weeks, the decision was made to eliminate the state name in the XML Key Name or X12 Reference Description. Since some companies may have already implemented this for California with the state name in place, this will still be allowed for California for backward compatibility. Page 8-2

Credit Report Freeze Laws Recommendation MISMO XML Formats When transmitting PIN values in the credit request using the MISMO XML formats, the MISMO Credit Work Group recommends using a standard adaptation of the existing KEY Name/Value pairs that are part of the REQUEST element. Using standard Key Name values will make sending the PIN values easier for the lenders that use multiple credit vendors, and will work with all existing MISMO versions without requiring any DTD changes. Here are the original values recommended values for the Key Names for California that was originally approved in late 2002. Key Names for California PIN values Equifax: California PIN-EFX (SSN of 1 st Borrower that the PIN applies to) California PIN-EFX (SSN of 2 nd Borrower that the PIN applies to) Trans Union: California PIN-TUC (SSN of 1 st Borrower that the PIN applies to) Experian: California PIN-TUC (SSN of 2 nd Borrower that the PIN applies to) California PIN-EXP (SSN of 1 st Borrower that the PIN applies to) California PIN-EXP (SSN of 2 nd Borrower that the PIN applies to) NOTE: Below is a sample implementation for other states that does not include the state name. The passing of California PIN values can be implemented either way with California (as shown above), or without the state name (as shown below). Key Names for Other State s PIN values Equifax: PIN-EFX (SSN of 1 st Borrower that the PIN applies to) PIN-EFX (SSN of 2 nd Borrower that the PIN applies to) Trans Union: PIN-TUC (SSN of 1 st Borrower that the PIN applies to) PIN-TUC (SSN of 2 nd Borrower that the PIN applies to) Experian: PIN-EXP (SSN of 1 st Borrower that the PIN applies to) PIN-EXP (SSN of 2 nd Borrower that the PIN applies to) Page 8-3

Credit Report Freeze Laws Sample MISMO 1.x Credit Request with California PIN values: <MORTGAGEDATA MISMOVersionID="1.1"> <REQUESTGROUP> <RequestDateTime>2003-01-02T17:27:33</RequestDateTime> <REQUEST RequestType="Credit"> <InternalAccountIdentifier>MFC0001</InternalAccountIdentifier> <PARTY PartyType="ReceivingParty"> <PartyName>ABC Credit Services</PartyName> </PARTY> <KEY> <KeyName>MFC Transaction ID</KeyName><KeyValue>70240023</KeyValue> </KEY> <KEY> <KeyName>California PIN-EFX (222334444)</KeyName> <KeyValue>8992</KeyValue> </KEY> <KEY> <KeyName>California PIN-TUC (222334444)</KeyName> <KeyValue>22Ac0023</KeyValue> </KEY> <KEY> <KeyName>California PIN-TUC (555667777)</KeyName> <KeyValue>31bM7885</KeyValue> </KEY> <REQUEST_DATA> </REQUEST> <PARTY PartyType="RequestingParty"> <PartyName>MFC Mortgage</PartyName> </PARTY> </REQUESTGROUP> <CREDITREQUEST>... BODY OF REQUEST GOES HERE... </CREDITREQUEST> </MORTGAGEDATA> Sample MISMO 2.x Credit Request with California PIN values: <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="MFC Mortgage"/> <RECEIVING_PARTY _Name="ABC Credit Services"/> <REQUEST RequestDatetime="2003-01-02T17:27:33" InternalAccountIdentifier="MFC0001"> <KEY _Name="MFC Transaction ID" _Value="70240023"/> <KEY _Name="California PIN-EFX (222334444)" _Value="8992"/> <KEY _Name="California PIN-TUC (222334444)" _Value="22Ac0023"/> <KEY _Name="California PIN-TUC (555667777)" _Value="31bM7885"/> <REQUEST_DATA>... BODY OF REQUEST GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Page 8-4

Credit Report Freeze Laws Sample MISMO 2.x Credit Request with any state s PIN values: <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="MFC Mortgage"/> <RECEIVING_PARTY _Name="ABC Credit Services"/> <REQUEST RequestDatetime="2003-09-02T10:22:03" InternalAccountIdentifier="MFC0001"> <KEY _Name="MFC Transaction ID" _Value="70247759"/> <KEY _Name="PIN-EFX (222334444)" _Value="2252"/> <KEY _Name="PIN-TUC (222334444)" _Value="13xK0928"/> <KEY _Name="PIN-TUC (555667777)" _Value="43Kd4028"/> <REQUEST_DATA>... BODY OF REQUEST GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Page 8-5

Chapter 9: Reissue / Secondary Use Reporting Background NOTE: In 2000, MISMO developed the Credit Request Transaction, an electronic format using XML (Extensible Markup Language.) This Recommendation describes how the existing MISMO Credit Request Transaction format may be used to provide the information needed by Credit Bureaus to report to the Repositories certain third-party users of credit reports. Credit Requests, including requests for Reissues and Secondary Use Notifications, are subject to the Fair Credit Reporting Act, as amended ( FCRA ). The information presented here is not intended as legal advice of any kind regarding compliance with FCRA or any other law or regulation, and users are urged to confirm the information provided with counsel well-versed in the subject matters of this Recommendation. As with all MISMO guidance, use of this Recommendation document is purely voluntary. Users of credit reports are also subject to policies of the Credit Bureau that issues a credit report. These policies may reflect agreements between the Credit Bureau and a Repository. A Credit Bureau s policies will determine the treatment of third-party users of credit reports as Additional End- Users, as defined below. Therefore, credit report users are advised to consult with Credit Bureaus on their policies. MISMO, AND THIS DOCUMENT, EXPRESS NO VIEW ON THE APPROPRIATE CLASSIFICATION OF ANY THIRD-PARTY AS AN ADDITIONAL END- USER OF A CREDIT REPORT OR THE CONSEQUENCES OF SUCH CLASSIFICATION. THIS DOCUMENT ALSO INCLUDES INFORMATION REGARDING PRESENTATION OF BILLING INSTRUCTIONS THAT A USER OF THE CREDIT REPORT MAY SEND TO A CREDIT BUREAU. MISMO EXPRESSES NO VIEW ON THE APPROPRIATENESS OF CHARGING A CREDIT REPORT REISSUE OR RECORDING FEE OR ANY FEE ASSOCIATED WITH A MORTGAGE TRANSACTION. Page 9-1

Reissue / Secondary Use Reporting Repositories and Credit Bureaus Defined Before getting into the details of the credit report reissue process, it s probably a good idea to identify and define two of the parties involved in the process. Repositories The credit data Repositories are the companies that collect and store credit data on individuals. Equifax, Experian SM and Trans Union are the three primary Repositories for credit files. Credit Bureau The Credit Bureau is the agency that creates the credit report for the lender. They are also sometimes referred to as the Credit Reporting Agency (CRA), or sometimes as the Credit Vendor. For consistency between this document, the MISMO DTD and the MISMO LDD, we will always use the term Credit Bureau. Advantage Credit, Equifax Mortgage Services, Fiserv CredStar, First American Credco, Kroll Factual Data, LandSafe Credit Services, LandAmerica Credit Services and LSI Credit Services are examples of Credit Bureaus. Reissue Reporting Overview New Credit Reports Typically a lender or mortgage broker (identified as the Requesting Party in the Credit Request transaction) will send the initial request for a borrower s credit report to a Credit Bureau. The Credit Bureau will then request raw credit files from one or more of the Repositories (Equifax, Experian and Trans Union), process and format the raw credit file(s) into a credit report, and finally return the credit report to the lender or broker. When the Credit Bureau requests the raw credit files from one or more of the Repositories, it also provides the Repositories with the name of the Requesting Party. For a new credit report, the Repositories will post a hard inquiry in the borrower s credit file, which records the date, permissible purpose and name of the credit report s Requesting Party. Hard inquiries may have an effect on a borrower s credit score. Reissues and Secondary Use Notifications A Credit Bureau may deem a Reissue to occur when it provides all or any portion of a previously issued credit report directly to an entity other than the original Requesting Party for whom that credit report was originally prepared. In this document, each recipient of a reissued credit report we will be referred to as an Additional End-User. Page 9-2

Reissue / Secondary Use Reporting In some cases, the Requesting Party may have provided all or a portion of the original credit report to a third-party that the Credit Bureau also may deem an Additional End-User. In these situations, either the Requesting Party or the Additional End-User(s) may be required to send the Credit Bureau a Secondary Use Notification, which identifies the names of the Additional End-User(s) of the credit report. NOTE: A Credit Bureau s agreement with a Repository may require that each Additional End-User of credit report data execute a contract with each Credit Bureau that provided the original credit report. The Requesting Party or Additional End-User should verify the requirements of the Credit Bureau. The Credit Bureaus report each Additional End-User to the Repositories, and they will post a soft inquiry in the borrower s credit file for each Additional End-User, recording the date, permissible purpose and name of the Additional End-User of the credit report. Soft inquiries only appear on reports issued directly to the consumer and do not have an effect on a borrower s credit score. The remaining sections of this document discuss how the existing MISMO Credit Request Transaction format can be used by Requesting Parties and Additional End-Users to provide the information used by the Credit Bureaus to report Additional End-Users to the Repositories. Page 9-3

Reissue / Secondary Use Reporting MISMO Support for Identifying Additional End-Users Submit Credit Request In the standard MISMO Submit Credit Request (CreditRequestActionType="Submit") the Requesting Party, referenced by the REQUEST element s Internal Account Identifier and/or Login Account Identifier/Password, is considered the original end-user of the credit report (as opposed to the Additional End-User). Examples on the next page show how the standard Submit Credit Request can also use the KEY element to identify one or more Additional End-Users in a single Submit transaction. Reissue Credit Request In the standard MISMO Reissue Credit Request (CreditRequestActionType= "Reissue"), the Requesting Party referenced by the REQUEST element s Internal Account Identifier and/or Login Account Identifier/Password may or may not be an Additional End-User. (The Credit Bureau is responsible for making this determination by comparing this entity to the Requesting Party that requested the report initially.) Examples on the next page show how the standard Reissue Credit Request can use the KEY element to identify multiple Additional End-Users in a single Reissue transaction. Secondary Use Notification Credit Request To identify an Additional End-User that has already received a copy of the credit report, a new MISMO Secondary Use Notification Credit Request can now be sent to the Credit Bureau. It is similar to a Reissue request except that a copy of the credit report is not returned. Its purpose is only to identify one or more Additional End-Users to the Credit Bureau. Examples on the next pages show how the Secondary Use Notification Credit Request can use the KEY element to identify multiple Additional End-Users. Credentials & Authentication This document also details how to include credentials for each Additional End-User using the KEY element, if those credentials are available. This provision for credentialing will enable a Credit Bureau to: (a) authenticate each Additional End-User before it provides a credit report and (b) charge a Reissue Recording Fee for Additional End-Users at its sole discretion. Page 9-4

Reissue / Secondary Use Reporting Backward Compatibility In order to identify Additional End-Users in a way that will work with all existing MISMO versions, the MISMO Credit Reporting Work Group recommends using the REQUEST element s repeating KEY element structure with a specific _Name attribute format. In order for the Credit Bureau to be able to verify that each Additional End- User is a valid client, the requesting party should to include either the (a) Additional End-User s Internal Account Identifier, and/or (b) the Additional End-User s Login Account Identifier and Login Account Password, if they are available. Each Credit Bureau will advise its customer which data to include. The requesting party also needs to include the Additional End-User s Name. This is provided for convenience when viewing the XML (it eliminates the need to decode the Additional End-User s Internal Account Identifier or the Additional End-User s Login Account Identifier, as the case may be). KEY Element Using Internal Account Identifier When using this method both the Additional End-User s Name and Internal Account Identifier must be reported. Each set of data is identified with a number surrounded by parenthesis. Here are two sets of KEY elements to show how the _Name attribute should be formatted. <KEY _Name="Additional End-User (1) Name" _Value="Lender, Inc"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="Lender001"/> <KEY _Name="Additional End-User (2) Name" _Value="Investor, Inc"/> <KEY _Name="Additional End-User (2) Internal Account Identifier" _Value="Investor001"/> NOTE: To reduce security risks, Credit Bureaus should NOT echo back the Additional End-User (#) Internal Account Identifier KEY element(s) in the Credit Response. Page 9-5

Reissue / Secondary Use Reporting KEY Element Using Login Account Identifier / Password When using this method both the Additional End-User s Name, Login Account Identifier and Login Account Password must be reported. Each set of data is identified with a number surrounded by parenthesis. Here are two sets of KEY elements to show how the _Name attribute should be formatted. <KEY _Name="Additional End-User (1) Name" _Value="Lender, Inc"/> <KEY _Name="Additional End-User (1) Login Account Identifier" _Value="Lender1"/> <KEY _Name="Additional End-User (1) Login Account Password" _Value="abc123"/> <KEY _Name="Additional End-User (2) Name" _Value="Investor, Inc"/> <KEY _Name="Additional End-User (2) Login Account Identifier" _Value="Invstr1"/> <KEY _Name="Additional End-User (2) Login Account Password" _Value="efg456"/> NOTE: To reduce security risks, Credit Bureaus should NOT echo back the Additional End-User (#) Login Account Password KEY elements in the Credit Response. Using a KEY Element for Specifying a Billing Instruction Normally, the Requesting Party is billed for services or products requested in a Credit Request transaction. In some scenarios, the Requesting Party may want to identify another party that is to be billed for any fees that may be involved with a reissue or secondary use notification. This can be accomplished using a Billing Instruction KEY element that has a _Value attribute set to either Total Price or Reissue Recording Fee, as shown in the following examples. NOTE: The examples in this section are neither intended as legal advice nor as endorsements of any particular actions or policies. Compliance questions should be directed to your company s management and legal counsel. Page 9-6

Reissue / Secondary Use Reporting All Fees Paid By Requesting Party In this first example, there is no Billing Instruction KEY element present, so the Requesting Party, ABC Lender will be billed for all fees related to the services requested. Sample Reissue Credit Request (No Billing Instruction) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="ABC Lender"/> <RECEIVING_PARTY _Name="ABC Credit Bureau"/> <REQUEST InternalAccountIdentifier="ABCLndr001"> <KEY _Name="Additional End-User (1) Name" _Value="ABC Mortgage Broker"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="ABCMB001"/> <REQUEST_DATA>... CREDIT REQUEST & LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> All Fees Paid By Additional End-User In this example, a Billing Instruction KEY element has been added to the KEY elements that identify the Additional End-User. Since the Billing Instruction KEY _Value is set to Total Price, the Additional End-User (1), ABC Mortgage Broker, will be billed for all fees related to the services requested. Sample Reissue Credit Request (Total Price - Billing Instruction) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="ABC Lender"/> <RECEIVING_PARTY _Name="ABC Credit Bureau"/> <REQUEST InternalAccountIdentifier="ABCLndr001"> <KEY _Name="Additional End-User (1) Name" _Value="ABC Mortgage Broker"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="ABCMB001"/> <KEY _Name="Additional End-User (1) Billing Instruction" _Value="Total Price"/> <REQUEST_DATA>... CREDIT REQUEST & LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Page 9-7

Reissue / Secondary Use Reporting Reissue Recording Fees Paid By Additional End-User In this example, the Billing Instruction KEY _Value is set to Reissue Recording Fee, which means that the Additional End-User (1), ABC Mortgage Broker, will be billed only for any reissue recording fees that may be charged by the Repositories, and other fees related to the services requested will be paid by the Requesting Party. Sample Reissue Credit Request (Reissue Recording Fee Billing Instruction) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="ABC Lender"/> <RECEIVING_PARTY _Name="ABC Credit Bureau"/> <REQUEST InternalAccountIdentifier="ABCLndr001"> <KEY _Name="Additional End-User (1) Name" _Value="ABC Mortgage Broker"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="ABCMB001"/> <KEY _Name="Additional End-User (1) Billing Instruction" _Value="Reissue Recording Fee"/> <REQUEST_DATA>... CREDIT REQUEST & LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Page 9-8

Reissue / Secondary Use Reporting Using MISMO Requests for Reissues and Secondary Use Notifications There are a variety of Reissue scenarios that can occur in the mortgage industry. They can be divided into the three following basic scenarios: Request a previously prepared credit report to one or more Additional End-Users. Request a new credit report and simultaneously provide it to one or more Additional End-Users. Send a Secondary Use Notification to a Credit Bureau. Following are examples of these scenarios. The MISMO Credit Request is shown where applicable. NOTE: The examples in this section are only intended to illustrate the use of the KEY elements as documented in these guidelines. The examples are neither intended as indicative of legal advice nor as endorsements of any particular actions or policies. Compliance questions should be directed to your company s management and legal counsel. Request a Previously Prepared Credit Report for One or More Additional End-Users In the following example, a new credit report is requested from a Credit Bureau by a Mortgage Broker. A Lender subsequently orders a Reissue of that previously prepared credit report for its use, as well as for the use of its Mortgage Insurer. It is assumed that the Credit Bureau has a direct client relationship with the Mortgage Broker, Lender and Mortgage Insurer.. 1. Borrower goes to a Mortgage Broker and fills out a loan application. 2. Mortgage Broker sends a standard Submit Credit Request to a Credit Bureau using the Mortgage Broker s Internal Account Identifier and/or Login Account Identifier/Password. Sample Submit Credit Request (Simplified) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="Mortgage Broker"/> <RECEIVING_PARTY _Name="Credit Bureau"/> <REQUEST InternalAccountIdentifier="MtgBrkr001"> <REQUEST_DATA> <CREDIT_REQUEST> <CREDIT_REQUEST_DATA CreditRequestActionType="Submit"/> </CREDIT_REQUEST>... LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> 3. Credit Bureau validates the Mortgage Broker s Internal Account Identifier and/or Login Account Identifier/Password. Page 9-9

Reissue / Secondary Use Reporting 4. Credit Bureau requests raw credit files from the Repositories, processes the raw credit files and returns a credit report along with the Credit Report Identifier. 5. Mortgage Broker wants a Lender to fund the loan and notifies a Lender of the credit report s Credit Report Identifier. 6. Lender sends a Reissue Credit Request, including the Credit Report Identifier, to the Credit Bureau using the Lender s Internal Account Identifier and/or Login Account Identifier/Password. This identifies the Lender as an Additional End-User. The Lender also uses KEY elements to identify its Mortgage Insurer as an Additional End-User. Sample Reissue Credit Request (Simplified) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="Lender"/> <RECEIVING_PARTY _Name="Credit Bureau"/> <REQUEST InternalAccountIdentifier="Lndr001"> <KEY _Name="Additional End-User (1) Name" _Value="Mortgage Insurer"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="MtgIns001"/> <REQUEST_DATA> <CREDIT_REQUEST> <CREDIT_REQUEST_DATA CreditRequestActionType="Reissue" CreditReportIdentifier="07031113"/> </CREDIT_REQUEST>... LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> o o o o Credit Bureau validates: o o Lender s Internal Account Identifier and/or Login Account Identifier/Password. Mortgage Insurer s Additional End-User (1) Internal Account Identifier. Credit Bureau provides the Reissue of the credit report referenced by the Credit Report Identifier to the Lender. Credit Bureau posts reissue transactions to the appropriate repositories, for the: o o Lender Mortgage Insurer Lender provides the credit report to the Mortgage Insurer evaluates the credit report and issues a loan decision. Page 9-10

Reissue / Secondary Use Reporting Request a New Credit Report and Simultaneously Provide It to One or More Additional End-Users In the following example, a new credit report is requested from a Credit Bureau by a Mortgage Broker through a Lender s web portal. In addition to the Lender using the credit report, the Lender will provide the credit report to its Mortgage Insurer for its use. It is assumed that the Credit Bureau has direct client relationships with the Mortgage Broker, Lender and Mortgage Insurer. 1. Borrower goes to a Mortgage Broker and fills out a loan application. 2. Mortgage Broker wants a Lender to fund the loan, so the Mortgage Broker orders a new credit report through a Lender s web portal. 3. Lender sends a Submit Credit Request to a Credit Bureau using the Mortgage Broker s Internal Account Identifier and/or Login Account Identifier/Password. The Lender also uses KEY elements to identify ITSELF and its Mortgage Insurer as Additional End-Users. o Sample Submit Credit Request with Additional End-Users (Simplified) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="Mortgage Broker"/> <RECEIVING_PARTY _Name="Credit Bureau"/> <REQUEST InternalAccountIdentifier=" MtgBrkr001"> <KEY _Name="Additional End-User (1) Name" _Value="Lender"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="Lndr001"/> <KEY _Name="Additional End-User (2) Name" _Value="Mortgage Insurer"/> <KEY _Name="Additional End-User (2) Internal Account Identifier" _Value="MtgIns001"/> <REQUEST_DATA> <CREDIT_REQUEST> <CREDIT_REQUEST_DATA CreditRequestActionType="Submit"/> </CREDIT_REQUEST>... LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> Credit Bureau validates: o o o Mortgage Broker s Internal Account Identifier and/or Login Account Identifier/Password. Lender s Additional End-User (1) Internal Account Identifier. Mortgage Insurer s Additional End-User (2) Internal Account Identifier. Page 9-11

Reissue / Secondary Use Reporting o o o Credit Bureau requests raw credit files from Repositories, processes the raw credit files and returns a credit report. Credit Bureau posts reissue transactions to the appropriate repositories for the: o o Lender Mortgage Insurer NOTE: In this example, the Mortgage Broker is the Requesting Party, not an Additional End-User. Therefore, the Credit Bureau does NOT post reissue transactions to the Repositories for the Mortgage Broker. Lender provides the credit report to the Mortgage Broker and the Mortgage Insurer evaluates the credit report and issues a loan decision. Send a Secondary Use Notification Request to a Credit Bureau In this example, a new credit report is requested from a Credit Bureau by a Lender. A Lender subsequently sends a Mortgage Insurance Application Request to a Mortgage Insurer. This transaction includes Credit Score data from the credit data originally ordered by the Lender. The Mortgage Insurer does not need the credit report to be reissued by the Credit Bureau. The Lender must notify the credit bureau about the Mortgage Insurer s secondary use of the credit report data. 1. Borrower goes to a Lender and fills out a loan application. 2. The Lender sends a standard Submit Credit Request to a Credit Bureau using their Internal Account Identifier and/or Login Account Identifier/Password. Sample Submit Credit Request (Simplified) <REQUEST_GROUP MISMOVersionID="2.1"> <REQUESTING_PARTY _Name="Lender"/> <RECEIVING_PARTY _Name="Credit Bureau"/> <REQUEST InternalAccountIdentifier="Lender001"> <REQUEST_DATA> <CREDIT_REQUEST> <CREDIT_REQUEST_DATA CreditRequestActionType="Submit"/> </CREDIT_REQUEST>... LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> 3. Credit Bureau validates the Lender s Internal Account Identifier and/or Login Account Identifier/Password. 4. Credit Bureau requests raw credit files from the Repositories, processes the raw credit files and returns a credit report along with the Credit Report Identifier. Page 9-12

Reissue / Secondary Use Reporting 5. The Lender pre-approves the loan and submits the Credit Score data from the credit report to a Mortgage Insurer as part of a Mortgage Insurance Application Request transaction. 6. The Lender sends a Secondary Use Notification Credit Request, including the Credit Report Identifier, to the Credit Bureau using the Lender s Internal Account Identifier and/or Login Account Identifier/Password. The Lender also uses KEY elements to identify the Mortgage Insurer as an Additional End-User. 7. Sample Secondary Use Notification Credit Request (Simplified) <REQUEST_GROUP MISMOVersionID="2.4.1.1"> <REQUESTING_PARTY _Name="Lender"/> <RECEIVING_PARTY _Name="Credit Bureau"/> <REQUEST InternalAccountIdentifier="Lndr001"> <KEY _Name="Additional End-User (1) Name" _Value="Mortgage Insurer"/> <KEY _Name="Additional End-User (1) Internal Account Identifier" _Value="MtgIns001"/> <REQUEST_DATA> <CREDIT_REQUEST> <CREDIT_REQUEST_DATA CreditReportIdentifier="07031113" CreditRequestActionType="SecondaryUseNotification"/> </CREDIT_REQUEST>... LOAN_APPLICATION DATA GOES HERE... </REQUEST_DATA> </REQUEST> </REQUEST_GROUP> o o Credit Bureau validates: o o Lender s Internal Account Identifier and/or Login Account Identifier/Password. Mortgage Insurer s Additional End-User (1) Internal Account Identifier. Credit Bureau posts reissue transactions to the appropriate repositories, for the: o Mortgage Insurer Page 9-13

Reissue / Secondary Use Reporting Setting Secondary Use Notification Action Type for Various MISMO Versions Because the Secondary Use Notification request is being added to the MISMO standards for the first time in Version 2.4.1.1, this section will show how the Credit Report Request Action Type attribute is formatted for each MISMO Version. Version 2.4.1.1 & Later: o Set CreditReportRequestActionType= SecondaryUseNotification Versions 2.1.1, 2.3, 2.3.1 and 2.4: o Set CreditReportRequestActionType= Other o Set CreditReportRequestActionTypeOtherDescription= SecondaryUseNotification Version 2.1: o Since Credit Request Version 2.1 did not contain a CreditReportRequestActionType attribute of Other, the following changes would be needed: o Set MISMOVersionID= 2.1.1 o Set CreditReportRequestActionType= Other o Set CreditReportRequestActionTypeOtherDescription= SecondaryUseNotification Page 9-14

Reissue / Secondary Use Reporting Reporting Additional End-User Authentication Errors When the credit bureau receives a credit request that contains the Additional End-User credentials (either Internal Account Identifier or the Login Account Identifier/Password), the credit bureau then verifies that these credentials are valid. When invalid credentials are detected a MISMO Credit Error Response transaction should be generated by the credit bureau and returned to the requesting party. There are existing MISMO error codes for invalid credentials shown in the table below. The complete list of MISMO error codes is available in Chapter 4 of the MISMO XML Implementation Guide: Credit Reporting Version 2. MISMO Error Codes and Descriptions Related to Authentication Error Code E036 E037 E038 E046 Error Description Invalid Client Account Identifier Invalid Password Invalid Login or Password Invalid Login ID Select the appropriate code and identify which Additional End-User set contained the invalid information. The example below shows the Credit Response section of an error response transaction with an invalid Client Account Identifier on the second Additional End-User Internal Account Identifier. Sample Authentication Error Report <CREDIT_RESPONSE MISMOVersionID="2.1" CreditResponseID="CreRpt0771" CreditReportType="Error"> <CREDIT_BUREAU _Name="ABC Credit Services"/> <CREDIT_ERROR_MESSAGE _Code="E036" _SourceType="CreditBureau"> <_Text>Invalid Client Account Identifier</_Text> <_Text>Additional End-User (2) Internal Account Identifier</_Text> </CREDIT_ERROR_MESSAGE> </CREDIT_RESPONSE> Page 9-15

Risk Based Pricing Disclosures Chapter 10: Risk Based Pricing Disclosure Recommendation Background Repositories and Credit Bureaus Defined Before getting into the details of the credit report reissue process, it s probably a good idea to identify and define two of the parties involved in the process. Repositories The credit data Repositories are the companies that collect and store that credit data on individuals. Equifax, Experian and Trans Union are the three primary Repositories for credit files. Credit Bureau The Credit Bureau is the agency that creates the credit report for the lender. They are also sometimes referred to as the Credit Reporting Agency (CRA), or sometimes as the Credit Vendor. For consistency between this document, the MISMO DTD and the MISMO LDD, we will always use the term Credit Bureau. Advantage Credit, Equifax Mortgage Services, Fiserv CredStar, First American Credco, Kroll Factual Data, LandSafe Credit Services, LandAmerica Credit Services and LSI Credit Services are examples of Credit Bureaus. Score Model The Score Model is the type of risk score that was requested by the Credit Reporting Agency on behalf of the requesting party (e.g.: Mortgage Originator, Lender, and Servicer). A score model will consist of a numerical value representing the applicant s credit risk level along with the primary reason codes for the score value. Equifax Beacon 5.0, Experian Classic04 and Transunion Empirica are examples of score models. For more information please refer to the document entitled Credit Score Model Name Type Table at: http://www.mismo.org/specs/specs-downloads/doc_download/122-creditscore-model-name-v2.html Page 10-1

Risk Based Pricing Disclosures Risk Based Pricing Overview The Federal Reserve Board and Federal Trade Commission have issued Risk- Based Pricing Rules, effective 1/1/2011. The rules require lenders to notify a consumer if the consumer is charged more based on information, including a credit score or scores, in a credit report. MISMO Support for Risk Based Pricing KEY Element for Credit Score Ranking When using this method for describing the Credit Score Rank the Credit Response Id and Score Id must be included. A KEY element must be included for each score model that was pulled with the credit report. <KEY _Name="CreditScoreRankPercent_CRRept0001_CRScoXPN02" _Value="40" /> <KEY _Name="CreditScoreRankPercent_CRRept0002_CRScoXPN02" _Value="27" /> Sample XML for Credit Score Ranking (Simplified) <RESPONSE ResponseDateTime="2004-10-13T09:41:22"> <KEY _Name="CreditScoreRank_CRRept0001_CRScoXPN01" _Value="40%"/> <RESPONSE_DATA> <CREDIT_RESPONSE MISMOVersionID="2.3.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportTransactionIdentifier="06-0577777.01" CreditReportFirstIssuedDate="2000-03-08" CreditReportType="Merge" CreditReportMergeType="Blend" CreditRatingCodeType="Equifax"> <CREDIT_SCORE CreditScoreID="CRScoXPN01" BorrowerID="BorRec0001" CreditFileID="CRFilXPN01" _ModelNameType="ExperianFairIsaac" _Value="725" CreditRepositorySourceType="Experian" _FACTAInquiriesIndicator="Y"> <_FACTOR _Code="38" _Text="Serious delinquency and public record or collection filed"/> <_FACTOR _Code="14" _Text="Length of time accounts have been established"/> <_FACTOR _Code="21" _Text="Amount past due on accounts"/> <_FACTOR _Code="02" _Text="Delinquency reported on accounts"/> </CREDIT_SCORE> <CREDIT_SCORE CreditScoreID="CRScoXPN02" BorrowerID="BorRec0002" CreditFileID="CRFilXPN02" _ModelNameType="ExperianFairIsaac" _Value="745" CreditRepositorySourceType="Experian" _FACTAInquiriesIndicator="Y"> <_FACTOR _Code="38" _Text="Serious delinquency and public record or collection filed"/> <_FACTOR _Code="14" _Text="Length of time accounts have been established"/> <_FACTOR _Code="21" _Text="Amount past due on accounts"/> <_FACTOR _Code="02" _Text="Delinquency reported on accounts"/> </CREDIT_SCORE> </ CREDIT_RESPONSE > </RESPONSE_DATA> </ RESPONSE > KEY Element for Credit Score Range When using this method for describing the Credit Score Range, the Model Name Type needs to be included. Each Model Name Type should correspond to one of the enumerations defined for the _ModelNameType of the CREDIT_SCORE node of the Page 10-2

Risk Based Pricing Disclosures CREDIT_RESPONSE DTD that you are implementing. A KEY element must be included for each score model that was pulled with the credit report. <KEY _Name= ModelNameType_MinimumValue _Value= XXX /> <KEY _Name= ModelNameType_MaximumValue _Value= XXX /> Sample XML for Credit Score Ranges (Simplified) <RESPONSE ResponseDateTime="2004-10-13T09:41:22"> <KEY _Name="ExperianFairIssac_MinimumValue" _Value="100"/> <KEY _Name="ExperianFairIssac_MaximumValue" _Value="760"/> <RESPONSE_DATA> <CREDIT_RESPONSE MISMOVersionID="2.3.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportTransactionIdentifier="06-0577777.01" CreditReportFirstIssuedDate="2000-03-08" CreditReportType="Merge" CreditReportMergeType="Blend" CreditRatingCodeType="Equifax"> <CREDIT_SCORE CreditScoreID="CRScoXPN01" BorrowerID="BorRec0001" CreditFileID="CRFilXPN01" _ModelNameType="ExperianFairIsaac" _Value="725" CreditRepositorySourceType="Experian" _FACTAInquiriesIndicator="Y"> <_FACTOR _Code="38" _Text="Serious delinquency and public record or collection filed"/> <_FACTOR _Code="14" _Text="Length of time accounts have been established"/> <_FACTOR _Code="21" _Text="Amount past due on accounts"/> <_FACTOR _Code="02" _Text="Delinquency reported on accounts"/> </CREDIT_SCORE> </ CREDIT_RESPONSE > </RESPONSE_DATA> </ RESPONSE > KEY Element for Histogram Information When using this method for describing the Credit Score Ranges as a Histogram the Model Name Type needs to be included along with (a) Interval Count represents the number of bars shown on the graph, (b) Interval(x) identifier for the specific bar within the graph, (c) Low Value the lowest value of the bar, (d) High Value highest value of the bar, and (e) OccurencePercent represents the percentage of consumers with a score value within the range. Each Model Name Type should correspond to one of the enumerations defined for the _ModelNameType of the CREDIT_SCORE node of the CREDIT_RESPONSE DTD you are implementing. <KEY _Name= CreditScoreRange_ModelNameType_IntervalCount _Value= 6 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval1_LowValue _Value= 0 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval1_HighValue _Value= 100 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval1_OccurencePercent _Value= 10 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval2_LowValue _Value= 101 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval2_HighValue _Value= 200 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval2_OccurencePercent _Value= 15 /> Page 10-3

Risk Based Pricing Disclosures <KEY _Name= CreditScoreRange_ModelNameType_Interval3_LowValue _Value= 201 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval3_HighValue _Value= 300 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval3_OccurencePercent _Value= 20 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval4_LowValue _Value= 301 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval4_HighValue _Value= 400 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval4_OccurencePercent _Value= 20 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval5_LowValue _Value= 401 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval5_HighValue _Value= 500 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval5_OccurencePercent _Value= 15 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval6_LowValue _Value= 501 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval6_HighValue _Value= 600 /> <KEY _Name= CreditScoreRange_ModelNameType_Interval6_OccurencePercent _Value= 20 /> Sample XML for Histogram Information (Simplified) <RESPONSE ResponseDateTime="2004-10-13T09:41:22"> <KEY _Name= CreditScoreRange_ExperianFairIsaac_IntervalCount _Value= 2 /> <KEY _Name= CreditScoreRange_ExperianFairIsaac_Interval1_LowValue _Value= 0 /> <KEY _Name= CreditScoreRange_ExperianFairIsaac_Interval1_HighValue _Value= 100 /> <KEY _Name= CreditScoreRange_ExperianFairIsaac_Interval1_OccurencePercent _Value= 50 /> <KEY _Name= CreditScoreRange_ExperianFairIsaac_Interval2_LowValue _Value= 101 /> <KEY _Name= CreditScoreRange_ExperianFairIsaac_Interval2_HighValue _Value= 200 /> <KEY _Name= CreditScoreRange_ExperianFairIsaac_Interval2_OccurencePercent _Value= 50 /> <RESPONSE_DATA> <CREDIT_RESPONSE MISMOVersionID="2.3.1" CreditResponseID="CRRept0001" CreditReportIdentifier="06-0577777" CreditReportTransactionIdentifier="06-0577777.01" CreditReportFirstIssuedDate="2000-03-08" CreditReportType="Merge" CreditReportMergeType="Blend" CreditRatingCodeType="Equifax"> <CREDIT_SCORE CreditScoreID="CRScoXPN01" BorrowerID="BorRec0001" CreditFileID="CRFilXPN01" _ModelNameType="ExperianFairIsaac" _Value="725" CreditRepositorySourceType="Experian" _FACTAInquiriesIndicator="Y"> <_FACTOR _Code="38" _Text="Serious delinquency and public record or collection filed"/> <_FACTOR _Code="14" _Text="Length of time accounts have been established"/> <_FACTOR _Code="21" _Text="Amount past due on accounts"/> <_FACTOR _Code="02" _Text="Delinquency reported on accounts"/> </CREDIT_SCORE> </ CREDIT_RESPONSE > </RESPONSE_DATA> </ RESPONSE > EMBEDDED File for Histogram Graphic When using this method for including an actual graph you need to format the graph as a jpeg image and include the Model Name Type. The value of the Model Name Type should correspond to one of the enumerations defined for the _ModelNameType of the CREDIT_SCORE node of the CREDIT_RESPONSE DTD you are implementing. For Page 10-4

Risk Based Pricing Disclosures those entities that are using version 2.3.1 or higher of the Credit Reporting Response you may choose to also include the _Description attribute. <EMBEDDED_FILE _Type= image/jpeg _Name= CreditScoreHistogram_ModelNameType _EncodingType= Base64 > <DOCUMENT> <![CDATA[The encoded image of the histogram goes here]]> </DOCUMENT> </EMBEDDED_FILE> EMBEDDED File for Risk Based Disclosure Letter When using this method for including the Risk Based (Credit Score) Disclosure Letter you need to create the letter in an agreed upon output of format (e.g.: PDF or HTML) for each of the applicants associated with the credit request. The _Name attribute consists of a static value of RiskBasedDisclosureNotice_ and the dynamic value of the borrower identifier that is specified in the CREDIT_REQUEST_DATA node. For those entities that are using version 2.3.1 or higher of the Credit Reporting Response you may choose to also include the _Description attribute. <EMBEDDED_FILE _Type= pdf _Name= RiskBasedDisclosureNotice_BorrowerIdentifier _EncodingType= Base64 > <DOCUMENT> <![CDATA[...]]> </DOCUMENT> </EMBEDDED_FILE> Page 10-5

2026 © DocPlayer.net Privacy Policy | Terms of Service | Feedback  | Do Not Sell My Personal Information