XML Implementation Guide: Credit Reporting

Transcription

1 : Credit Reporting

2 Copyright 2000 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.

3 Table of Contents XML Implementation Guide: Credit Reporting TABLE OF CONTENTS Document Revision Date: January 10, 2001 CHAPTER 1: INTRODUCTION PURPOSE OF THIS DOCUMENT Version and Release Comments OVERVIEW CHAPTER 2: CREDIT REQUEST SECTION BY SECTION CREDIT REQUEST SECTIONS REQUESTGROUP CREDITREQUEST Typical Credit Request Options Selecting Number of Bureaus To Be Requested Reissue Request Upgrade to RMCR Request Requesting Credit For Multiple Borrowers on a Loan PARTY BORROWER APPLICATION ASSET BORROWERRECONCILEDLIABILITY INCOME PROPERTY CHAPTER 3: CREDIT RESPONSE SECTION BY SECTION CREDIT REPORT SECTIONS RESPONSE CREDITREQUEST PARTY BORROWER ASSET INCOME PROPERTY CREDITREPORT MERGEDLIABILITY Merged Liability and Repository Liability Data Credit Late Dates and Payment Pattern Data MERGEDPUBLICRECORD CREDITINQUIRY CREDITFILEVARIATION CREDITSUMMARY CREDITERRORMESSAGE CREDITCOMMENT CREDITSCORE CHAPTER 4: CREDIT ERROR RESPONSE CHAPTER 5: CREDIT REPORTING ELEMENTS AND ATTRIBUTES Page i

4 Table of Contents CHAPTER 6: CREDIT REPORTING DTD CHANGE LIST CHAPTER 7: QUESTIONS AND ANSWERS WHAT ARE THE MINIMUM REQUIRED ELEMENTS FOR REQUESTING A MERGE CREDIT REPORT? WHAT IS THE MISMO XML EQUIVALENT TO THE X12 RATING REMARKS? WHERE IS THE WHOSE FILE FLAG FOR LIABILITIES, PUBLIC RECORDS, ETC.? WHY IS THE CREDITREQUEST CONTAINER SEPARATE FROM THE REQUESTGROUP? WHY IS THE CREDITREQUEST CONTAINER INCLUDED IN RESPONSE TRANSACTIONS? WHICH CREDIT RESPONSE ELEMENTS INDICATE THAT A REQUEST TO A REPOSITORY BUREAU FAILED? WHAT IS THE PURPOSE OF HAVING THE ALIAS CONTAINER IN THE CREDIT REPORTING DTD? WHAT IS THE PURPOSE OF THE REPOSITORYLIABILITY CONTAINER? Page ii

5 Introduction Chapter 1: Introduction Purpose of this Document Overview This document is designed to assist individuals who are implementing the Credit Reporting process area of the MISMO XML standards. Numerous examples with sample credit data are provided throughout the guide. General information and an overview of the MISMO XML architecture is provided in a separate document titled: MISMO XML Implementation Guide: General Information. Version and Release This implementation guide is based on versions 1.x of the MISMO standard. The MISMO Data Dictionary, Data Models, and DTDs (commented and uncommented) can be downloaded from the 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 INFO1 [[email protected]] Bill Parker First American Interactive [[email protected]] This guide focuses on implementing the Credit Reporting DTD for specific uses. The DTD provides data elements for generating: Merge Request and Response (instant return of credit data on file with repository bureaus - Equifax, Experian, Trans Union) Score Only Request and Response (Risk Scores Only) RMCR Request and Response (fully verified credit data, employment data sometimes includes verified assets and income) Error Report shows request or processing errors. The table below shows which of the various Credit Reporting DTD containers are applicable for each type of use. The first three columns show the containers generally used for the purposes of requesting a service from a credit bureau. The last four columns show the containers normally returned by a credit bureau for each type of response. Page 1-1

6 Introduction CREDIT REPORT DTD ELEMENT USAGE X = Element Is Used Primary COMPONENT NAMES Merge Request Score Only Request RMCR Request Merge Response Score Only Response RMCR Response Error Report APPLICATION X ASSET X X BORROWER X X X X X X BORROWER RECONCILED LIABILITY X CREDIT REPORT X X X CREDIT REQUEST X X X X X X X CREDIT SCORE X X X INCOME X X PARTY X X X X X PROPERTY (REO & SUBJECT PROPERTY) X X REQUEST GROUP X X X RESPONSE X X X X The remainder of this guide provides a section-by-section breakdown of a credit request and a credit report and XML samples for each. Page 1-2

7 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. Detailed descriptions about individual elements and attributes used in the Credit Reporting DTD are contained in the commented version of the DTD CreditReportingComment#_#.dtd. The latest version can be downloaded from the web site. CREDIT REQUEST SECTIONS The XML sample below shows the major component elements of the credit report request transactions. Not all components will appear in every credit request, and not all components are used in every type of credit request. See the Overview section on page 1-1 for a breakdown by credit request type. (If you are viewing an electronic version of this document, you can click on a highlighted component element name to go directly to that section of this chapter.) The elements immediately under the Mortgage Data container (the primary containers) may appear in any order. The order shown in the sample below is one possible order. Major Credit Request Elements <?xml version="1.0"?> <!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0"> <REQUESTGROUP/> <CREDITREQUEST/> <PARTY/> <BORROWER/> <APPLICATION/> <ASSET/> <BORROWERRECONCILEDLIABILITY/> <INCOME/> <PROPERTY/> </MORTGAGEDATA> Page 2-1

8 Credit Request Section By Section REQUESTGROUP CREDITREQUEST Required? No. Purpose: This element container provides the information about the entity requesting the credit report. This information could instead be provided in an envelope outside the MISMO data, such as a SOAP envelope. Request Group Sample Data: <REQUESTGROUP> <REQUESTINGPARTY PARTYIDREF="PrtyID0001"/> <RequestDateTime> T13:10:22</RequestDateTime> <REQUEST RequestType="Credit" CREDITREQUESTIDREF="CreReq0001"> <InternalAccountIdentifier> MRU1302 </InternalAccountIdentifier> <RECEIVINGPARTY PARTYIDREF="PrtyID0002"/> <KEY> <KeyName>Loan ID</KeyName> <KeyValue> HB</KeyValue> </KEY> </REQUEST> </REQUESTGROUP> Required? Not required if credit request parameters are always the same for a customer and on file with the credit bureau. Purpose: Specifies the Credit Report Type, Credit Request Type, Bureaus Requested, etc. Sample Merged Request (MISMO Version 1.0): <CREDITREQUEST CREDITREQUESTID="CrdReq1581" CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" TransUnionIncludedIndicator="Y"/> Sample Merged Request (MISMO Version 1.0.1): <CREDITREQUEST CREDITREQUESTID="CrdReq1581" CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" TransUnionIncludedIndicator="Y" BORROWERIDREFS="BorRec0001 BorRec0002 /> Page 2-2

9 Credit Request Section By Section Sample Merged Request (MISMO Version 1.1) showing SCORE MODEL NAME Elements: <CREDITREQUEST CREDITREQUESTID="CrdReq1581" CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" TransUnionIncludedIndicator="Y" BORROWERIDREFS="BorRec0001 BorRec0002"> <SCOREMODELNAME ScoreModelNameType="EquifaxEnhancedBeacon"/> <SCOREMODELNAME ScoreModelNameType="EquifaxMarketMax"/> <SCOREMODELNAME ScoreModelNameType="TransUnionEmpirica"/> <SCOREMODELNAME ScoreModelNameType="Other"> <OtherScoreModelName> ExperianFairIsaac2001 </OtherScoreModelName> </SCOREMODELNAME> </CREDITREQUEST> Typical Credit Request Options The most common type of report in use today is the three-bureau merge file. To submit a new request, the Requested Action Type is set to Submit, and the Report Type is set to Merge. If ordering a combined credit report for a borrower spouse pair, set the Credit Request Type attribute to Joint, otherwise set the attribute s value to Individual. Sample Three Bureau Merge Credit Request: <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" TransUnionIncludedIndicator="Y"/> Selecting Number of Bureaus 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 bureaus 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 Showing Bureaus Selected Count: <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType= Merge CreditRequestType= Joint > <RepositoryBureausSelectedCount>2</RepositoryBureausSelectedCount> </CREDITREQUEST> Page 2-3

10 Credit Request Section By Section 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 CreditReportIdentifier element. The Requested Action Type is set to Reissue. Sample Reissue Credit Request: <CREDITREQUEST CreditReportRequestedActionType="Reissue"> <CreditReportIdentifier> </CreditReportIdentifier> </CREDITREQUEST> Upgrade to RMCR Request Commonly a loan broker will order a one, two or three bureau 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 Requested Action Type is set to Upgrade, the Credit Report Type is set to RMCR and the original Merge report number is entered in the CreditReportIdentifier element. Sample Upgrade to RMCR Credit Request: <CREDITREQUEST CreditReportRequestedActionType="Upgrade" CreditReportType="RMCR" CreditRequestType="Joint"> <CreditReportIdentifier> </CreditReportIdentifier> </CREDITREQUEST> Requesting Credit For Multiple Borrowers on a Loan The majority of loans involve a single borrower or a married borrower pair. For mortgage loans, however it is not uncommon to have additional borrowers on the loan. When requesting credit for a loan with multiple borrower sets, each borrower set must be entered in a separate Credit Request. A joint credit request may include a married borrower pair; otherwise, it is an individual credit request. Separate credit response will be returned for each Credit Request that was submitted. The sample file on the next page includes three borrower sets one married couple (John Doe Jr. and Jane Doe), and two single unmarried relatives (John Doe Sr. and Henry Block III). The married couple is referenced in one of the credit requests, and each of the unmarried relatives has their own credit request for a total of three credit requests. NOTE: Generating multiple credit requests from a single loan file requires MISMO Version or later, since it requires the use of the BORROWERIDREFS attribute of the CREDIT REQUEST container. Page 2-4

11 Credit Request Section By Section Sample Credit Request Multiple Borrower Sets: <?xml version="1.0"?> <!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0.1"> <REQUESTGROUP> <RequestDateTime> T16:59:11</RequestDateTime> <REQUEST RequestType="Credit"> <InternalAccountIdentifier> ABC9024 </InternalAccountIdentifier> </REQUEST> </REQUESTGROUP> <CREDITREQUEST <CREDITREQUEST <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" TransUnionIncludedIndicator="Y" BORROWERIDREF= BorRec0001 BorRec0002 /> CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual" TransUnionIncludedIndicator="Y" BORROWERIDREF= BorRec0003 /> CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual" TransUnionIncludedIndicator="Y" BORROWERIDREF= BorRec0004 /> <BORROWER BORROWERID="BorRec0001"> <FirstName>John</FirstName> <LastName>Doe</LastName> <NameSuffix>JR</NameSuffix> <SSN> </SSN>...Borrower Residence Elements... </BORROWER> <BORROWER BORROWERID="BorRec0002"> <FirstName>Jane</FirstName> <LastName>Doe</LastName> <SSN> </SSN>...Borrower Residence Elements... </BORROWER> <BORROWER BORROWERID="BorRec0003"> <FirstName>John</FirstName> <LastName>Doe</LastName> <NameSuffix>SR</NameSuffix> <SSN> </SSN>...Borrower Residence Elements... </BORROWER> <BORROWER BORROWERID="BorRec0004"> <FirstName>Henry</FirstName> <LastName>Block</LastName> <NameSuffix>III</NameSuffix> <SSN> </SSN>...Borrower Residence Elements... </BORROWER> </MORTGAGEDATA> Page 2-5

12 Credit Request Section By Section PARTY Required? No. Purpose: This element container provides name, address, contact, phone, fax and data for parties to the loan. The sample data below shows a Requesting Party, a Receiving Party (the credit bureau) an Employment Party, and a Liability Holder (referenced from Borrower Reconciled Liabilities). Sample Party Data in a Credit Request (MISMO Version 1.0): <PARTY PARTYID="PrtyID0001" PartyType="RequestingParty"> <PartyName>Mortgages R Us</PartyName> <Address1>239 N Hillside</Address1> <City>Brenton</City> <State>TN</State> <PostalCode>54022</PostalCode> <CONTACTDETAIL> <ContactName>Lisa Jones</ContactName> </CONTACTDETAIL> </PARTY> <PARTY PARTYID="PrtyID0002" PartyType="ReceivingParty"> <PartyName>First Credit Info Data Services</PartyName> <Address1>1220 Main ST</Address1> <Address2>Suite 203</Address2> <City>Centerville</City> <State>KS</State> <PostalCode>60204</PostalCode> <CONTACTDETAIL> <ContactName>JENNY TURK</ContactName> </CONTACTDETAIL> </PARTY> <PARTY PARTYID="PrtyID0003" PartyType="Employer"> <PartyName>CHICAGO TRANSIT AUTHORITY</PartyName> <CONTACTDETAIL> <CONTACTPOINT ContactPointType="Phone" <ContactPointValue> </ContactPointValue> </CONTACTPOINT> </CONTACTDETAIL> </PARTY> <PARTY PARTYID="PrtyID0004" PartyType="LiabilityHolder"> <PartyName>ANNA SCHNIEDNER</PartyName> <Address1>3775 Copper Circle East</Address1> <City>Jacksonville</City> <State>FL</State> <PostalCode>32207</PostalCode> </PARTY> Page 2-6

13 Credit Request Section By Section BORROWER Required? Yes. Purpose: Provides borrower-identifying data required for any credit transaction. Borrower data for a Merge or Score Only Request includes the full name, plus current and recent previous Residence Addresses. RMCR Request Borrower data also includes Alias, BorrowerAsset, BorrowerLiability, Contact Detail, Declarations, Demographics and Employment data. Sample Borrower Element Data (MISMO Version 1.0): <BORROWER BORROWERID="BorRec0001"> <UnparsedName>TRACY A GRACEY</UnparsedName> <FirstName>TRACY</FirstName> <MiddleName>A</MiddleName> <LastName>GRACEY</LastName> <SSN> </SSN> <ALIAS> <AccountIdentifier> </AccountIdentifier> <CreditorName>K.B. JEWELERS</CreditorName> <AliasName>TRACEY WILLIAMS</AliasName> </ALIAS> <BORROWERASSET ASSETIDREF= Asset00001 /> <BORROWERLIABILITY BORRWERRECONCILEDLIABILITYIDREF= BorRecLiab001 /> <BORROWERRESIDENCE> <Address1>777 HILLSIDE AVE</Address1> <City>ELMHURST</City> <State>IL</State> <PostalCode>60126</PostalCode> <PARSEDSTREETNAME> <HouseNumber>777</HouseNumber> <StreetName>HILLSIDE AVE</StreetName> </PARSEDSTREETNAME> </BORROWERRESIDENCE> <CONTACTDETAIL> <CONTACTPOINT ContactPointType="Phone" ContactPointRoleType= Home > <ContactPointValue> </ContactPointValue> </CONTACTPOINT> <CONTACTPOINT ContactPointType=" " PreferenceIndicator= Y > <ContactPointValue>[email protected]</ContactPointValue> </CONTACTPOINT> </CONTACTDETAIL> Page 2-7

14 Credit Request Section By Section <DECLARATIONS CitizenshipResidencyType= UnitedStatesCitizen AlimonyChildSupportObligationsIndicator= N BankruptcyPastSevenYearsIndicator= N BorrowedDownPaymentIndicator= Y ComakerEndorserOfNoteIndicator= Y HomeownerPastThreeYearsIndicator= Y LoanForeclosureOrJudgmentIndicator = N OutstandingJudgmentsIndicator= N PartyToLawsuitIndicator= N PresentlyDelinquentIndicator= N PropertyForeclosurePastSevenYearsIndicator= N /> <DEMOGRAPHICS MaritalStatusType="Married"> <DependentCount>1</DependentCount> </DEMOGRAPHICS> <EMPLOYMENT CurrentEmploymentIndicator= Y PARTYIDREF= PrtyID0003 INCOMEIDREFS= Income0001 > <PositionDescription> Station Manager </PositionDescription> </EMPLOYMENT> </BORROWER> <BORROWER BORROWERID="BorRec0002"> <UnparsedName>MARC SCHNEIDNER</UnparsedName> <FirstName>MARC</FirstName> <LastName>SCHNEIDNER</LastName> <SSN> </SSN> <BORROWERRESIDENCE> <Address1>777 HILLSIDE AVE</Address1> <City>ELMHURST</City> <State>IL</State> <PostalCode>60126</PostalCode> <PARSEDSTREETNAME> <HouseNumber>777</HouseNumber> <StreetName>HILLSIDE AVE</StreetName> </PARSEDSTREETNAME> </BORROWERRESIDENCE> <DECLARATIONS CitizenshipResidencyType= UnitedStatesCitizen AlimonyChildSupportObligationsIndicator= Y BankruptcyPastSevenYearsIndicator= N BorrowedDownPaymentIndicator= Y ComakerEndorserOfNoteIndicator= Y HomeownerPastThreeYearsIndicator= Y LoanForeclosureOrJudgmentIndicator = N OutstandingJudgmentsIndicator= N PartyToLawsuitIndicator= N PresentlyDelinquentIndicator= N PropertyForeclosurePastSevenYearsIndicator= N /> </BORROWER> Page 2-8

15 Credit Request Section By Section APPLICATION Required? No. Purpose: Provides date elements for identifying when Interviewer and Loan Applicants signed the loan application. This information is sometimes useful to credit investigators who need to verify borrower-supplied data on the loan application. Sample Application Data: <APPLICATION ApplicationTakenMethodType= FaceToFace > <ApplicationInterviewerSignedDate> </ApplicationInterviewerSignedDate> <BorrowerApplicationSignedDate> </BorrowerApplicationSignedDate> </APPLICATION> ASSET Required? Only if Asset data needs to be verified by the credit bureau. Purpose: In the RMCR Request, this container provides the assets to be verified. Sample RMCR Asset: <ASSET ASSETID= Asset00001 AssetType= CheckingAccount PARTYIDREFS= PrtyID0056 > <AssetAccountIdentifier> </AssetAccountIdentifier> <AssetCashOrMarketValueAmount> </AssetCashOrMarketValueAmount> </ASSET> BORROWERRECONCILEDLIABILITY Required? Only the data that needs verification. Purpose: In the RMCR Request, this container provides the liabilities list supplied by the borrower on the loan application. Sample RMCR Borrower Liability Data: <BORROWERRECONCILEDLIABILITY BORRWERRECONCILEDLIABILITYID= BorRecLiab002 LiabilityPayoffStatusType= NotPaidContinue LiabilityType= Alimony PARTYIDREFS= PrtyID0004 > <LiabilityMonthlyPaymentAmount>800</LiabilityMonthlyPaymentAmount> <LiabilityRemainingTermMonths>28</LiabilityRemainingTermMonths> </BORROWERRECONCILEDLIABILITY> Page 2-9

16 Credit Request Section By Section INCOME Required? Only if Income data needs to be verified by the credit bureau. Purpose: In the RMCR Request, this container provides the income to be verified (usually employment income). Sample RMCR Income Data: <INCOME IncomeTimeType= Current INCOMEID= Income0001 > <IncomeAmount>3200</IncomeAmount> </INCOME> PROPERTY Required? No. Purpose: The Subject Property address is provided only for reference purposes. Sample RMCR Property Data (MISMO Version 1.0): <PROPERTY PropertyType="Subject"> <Address1>1616 Brickell Avenue</Address1> <City>Miami</City> <State>FL</State> <PostalCode>33127</PostalCode> </PROPERTY> Page 2-10

17 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. Detailed descriptions about individual elements and attributes used in the Credit Reporting DTD are contained in the commented version of the DTD CreditReportingComment#_#.dtd. The latest version can be downloaded from the web site. CREDIT REPORT SECTIONS The XML sample shown below shows the major component elements of the credit report response transactions. Not all components will appear in every credit report, and not all components are used in every type of credit report. See the Overview section on page 1-1 for a breakdown by credit report type. (If you are viewing an electronic version of this document, you can click on a highlighted component element name to go directly to that section of this chapter.) The elements immediately under the Mortgage Data container (the primary containers) may appear in any order. The order shown in the sample below is one possible order. The elements of containers that are not primary containers, like Credit Report, must be in the order specified in the DTD as shown in the sample structure below. Major Credit Report Elements <?xml version="1.0"?> <!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0"> <RESPONSE/> <CREDITREQUEST/> <PARTY/> <BORROWER/> <ASSET/> <INCOME/> <PROPERTY/> <CREDITREPORT> <CREDITREPORTPRICE/> <MERGEDLIABILITY/> <MERGEDPUBLICRECORD/> <CREDITINQUIRY/> <CREDITFILEVARIATION/> <CREDITSUMMARY/> <CREDITERRORMESSAGE/> <CREDITCOMMENT/> </CREDITREPORT> <CREDITSCORE/> </MORTGAGEDATA> Page 3-1

18 Credit Response Section By Section RESPONSE Required? No Purpose: This element container provides the identifiers for the party generating the response, the receiving party, the date and time the response was generated and any reference values that had been sent with the original request file. Sample Response Element Data: <RESPONSE> <RESPONSEPARTY ResponseFormatType="XML" ResponseMethodType="FTP" PARTYIDREF="PrtyID0001"> <ResponseDestinationDescription> </ResponseDestinationDescription> </RESPONSEPARTY> <RECEIVINGPARTY PARTYIDREF="PrtyID0002"/> <KEY> <KeyName>Loan ID</KeyName> <KeyValue> HB</KeyValue> </KEY> <ResponseDateTime> T13:10:34</ResponseDateTime> </RESPONSE> CREDITREQUEST Required? No, provided in response transactions only for reference purposes. Purpose: Repeats Credit Report Type, Credit Request Type, Bureaus Requested, etc. that were set in the original request transaction. Sample Credit Request Element Data (MISMO Version 1.0): <CREDITREQUEST CREDITREQUESTID="CrdReq1581" CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" TransUnionIncludedIndicator="Y"/> Page 3-2

19 Credit Response Section By Section PARTY Required? No. Purpose: This element container provides name, address, contact, phone, fax and data for parties to the loan. The sample data below shows a Response Party, Receiving Party, one liability Credit Trade Reference and one public record Credit Trade Reference. Sample Party Data from a Credit Response (MISMO Version 1.0): <PARTY PARTYID="PrtyID0001" PartyType="ResponseParty"> <PartyName>First Credit Info Data Services</PartyName> <Address1>1220 Main ST</Address1> <Address2>Suite 203</Address2> <City>Centerville</City> <State>KS</State> <PostalCode>60204</PostalCode> <CONTACTDETAIL> <ContactName>JENNY TURK</ContactName> <CONTACTPOINT ContactPointType="Phone" ContactPointRoleType= Work > <ContactPointValue> </ContactPointValue> </CONTACTPOINT> <CONTACTPOINT ContactPointType=" " PreferenceIndicator= Y > <ContactPointValue> [email protected] </ContactPointValue> </CONTACTPOINT> </CONTACTDETAIL> </PARTY> <PARTY PARTYID="PrtyID0002" PartyType="ReceivingParty"> <PartyName>Mortgages R Us</PartyName> <Address1>239 N Hillside</Address1> <City>Brenton</City> <State>TN</State> <PostalCode>54022</PostalCode> </PARTY> <PARTY PARTYID="PrtyID0003" PartyType="Employer"> <PartyName>CHICAGO TRANSIT AUTHORITY</PartyName> <CONTACTDETAIL> <CONTACTPOINT ContactPointType="Phone" <ContactPointValue> </ContactPointValue> </CONTACTPOINT> </CONTACTDETAIL> </PARTY> <PARTY PARTYID="PrtyID0004"PartyType="CreditTradeReference"> <PartyName>Juniper MC</PartyName> <Address1>PO Box 1534</Address1> <City>Deposit</City> <State>NY</State> <PostalCode>13754</PostalCode> </PARTY> Page 3-3

20 Credit Response Section By Section BORROWER Required? Yes, except for reports that mask the borrower s identity. Purpose: Provides borrower-identifying data required for any credit transaction. RMCR Response BORROWER data also includes DEMOGRAPHICS and verified EMPLOYMENT data. The sample below includes employment data for the first borrower. Sample Borrower Element Data (MISMO Version 1.0): <BORROWER BORROWERID="BorRec0001"> <UnparsedName>TRACY A GRACEY</UnparsedName> <FirstName>TRACY</FirstName> <MiddleName>A</MiddleName> <LastName>GRACEY</LastName> <SSN> </SSN> <BORROWERRESIDENCE> <Address1>777 HILLSIDE AVE</Address1> <City>ELMHURST</City> <State>IL</State> <PostalCode>60126</PostalCode> <PARSEDSTREETNAME> <HouseNumber>777</HouseNumber> <StreetName>HILLSIDE AVE</StreetName> </PARSEDSTREETNAME> </BORROWERRESIDENCE> <DEMOGRAPHICS MaritalStatusType="Married"> <DependentCount>1</DependentCount> </DEMOGRAPHICS> <EMPLOYMENT CurrentEmploymentIndicator= Y PARTYIDREF= PrtyID0003 INCOMEIDREFS= Income0001 > <PositionDescription> Station Manager </PositionDescription> <VERIFICATION VerificationStatusType= Verified VerificationType= Employment > <VerifiedByDate> </VerifiedByDate> <VerifiedByName>SBT</VerifiedByName> </VERIFICATION> </EMPLOYMENT> </BORROWER> <BORROWER BORROWERID="BorRec0002"> <UnparsedName>MARC SCHNEIDNER</UnparsedName> <FirstName>MARC</FirstName> <LastName>SCHNEIDNER</LastName> <SSN> </SSN> <BORROWERRESIDENCE> <Address1>777 HILLSIDE AVE</Address1> <City>ELMHURST</City> <State>IL</State> <PostalCode>60126</PostalCode> <PARSEDSTREETNAME> <HouseNumber>777</HouseNumber> <StreetName>HILLSIDE AVE</StreetName> </PARSEDSTREETNAME> </BORROWERRESIDENCE> </BORROWER> Page 3-4

21 Credit Response Section By Section ASSET Required? Only verified Asset data needs to be reported. Purpose: In the RMCR Response, this container provides the verified assets (plus the VERIFICATION data). Sample RMCR Asset Element with Verification: <ASSET AssetType= CheckingAccount PARTYIDREFS= PrtyID0056 > <AssetAccountIdentifier> </AssetAccountIdentifier> <AssetCashOrMarketValueAmount> </AssetCashOrMarketValueAmount> <VERIFICATION VerificationStatusType= Verified VerificationType= Asset > <VerifiedByName>Jennifer B</VerifiedByName> <VerifiedDate> </VerifiedDate> </VERIFICATION> </ASSET> INCOME Required? Only verified Income data needs to be reported. Purpose: In the RMCR Response, this container provides the verified employment income. Sample RMCR Income Element Data: <INCOME IncomeTimeType= Current INCOMEID= Income0001 > <IncomeAmount>3200</IncomeAmount> </INCOME> PROPERTY Required? No. Purpose: The Subject Property address is provided only for reference purposes. Sample RMCR Property Element Data (MISMO Version 1.0): <PROPERTY PropertyType="Subject"> <Address1>1616 Brickell Avenue</Address1> <City>Miami</City> <State>FL</State> <PostalCode>33127</PostalCode> </PROPERTY> Page 3-5

22 Credit Response Section By Section CREDITREPORT Required? Yes, for Merge and RMCR responses. Purpose: Provides basic information about the credit report, such as the Credit Report Type, Issue Date, Bureaus Included, Price and the Credit Report ID. It also acts as the container for Liabilities, Public Record, Inquiries, File Variation data, Summary data, Error messages and miscellaneous Comment data. When used in the CREDIT REPORT container, the Equifax / Experian / Trans Union Included Indicator attributes identify which repository bureau s credit files were included in the report (as opposed to which one s were requested in the CREDIT REQUEST container. For an RMCR response, the Credit Report Type attribute value in the sample data below would be set to RMCR. (Also the Credit Report Price would be higher.) Sample Credit Report Response Data: <CREDITREPORT CREDITREPORTID="CrdRpt0001" CreditReportType="Merge" MergeType="Blend" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" <CreditReportIdentifier> </CreditReportIdentifier> <FirstIssuedDate> </FirstIssuedDate> <CREDITBUREAU PARTYIDREF="PrtyID0001"/> <CREDITREPORTPRICE CreditReportPriceType="Net"> <CreditReportPriceAmount> </CreditReportPriceAmount> </CREDITREPORTPRICE> <!-- MERGEDLIABILITY containers go here --> <!-- MERGEDPUBLICRECORD containers go here --> <!-- CREDITINQUIRY containers go here --> <!-- CREDITFILEVARIATION containers go here --> <!-- CREDITSUMMARY containers go here --> <!-- CREDITERRORMESSAGE containers go here --> <!-- CREDITCOMMENT containers go here --> </CREDITREPORT> Page 3-6

23 Credit Response Section By Section MERGEDLIABILITY Required? Only if there is liability data to report. Purpose: Provides liability data merged from duplicate liabilities reported by multiple repository bureaus (Equifax, Experian, Trans Union). This container is also used when there is only data from a single repository bureau. More information about Merged liability data and Repository liability data appears on the pages that follow the sample liability shown below. RMCR liabilities may also include a VERIFICATION container. Sample Merged Liability Data: <MERGEDLIABILITY MERGEDLIABILITYID="CRLiab0024" AccountOwnershipType="Individual" AccountType="Revolving" CreditLoanType="ChargeAccount" CurrentDelinquencyRatingType="AsAgreed" DerogatoryDataIndicator="Y" BORROWERIDREFS="BorRec0002" PARTYIDREF="PrtyID0004"> <AccountIdentifier> </AccountIdentifier> <AccountOpenedDate> </AccountOpenedDate> <CreditorName>Juniper MC</CreditorName> <HighCreditAmount>704</HighCreditAmount> <LastActivityDate> </LastActivityDate> <Late30DaysCount>2</Late30DaysCount> <Late60DaysCount>1</Late60DaysCount> <Late90DaysCount>0</Late90DaysCount> <MonthsReviewedCount>16</MonthsReviewedCount> <MonthlyPaymentAmount>36</MonthlyPaymentAmount> <PastDueAmount>0</PastDueAmount> <PaymentPatternData> CCCCCCCCCCCCCCC12CC1CCCC </PaymentPatternData> <PaymentPatternStartDate> </PaymentPatternStartDate> <ReportedDate> </ReportedDate> <TermsDescription>$36/MO</TermsDescription> <UnpaidBalanceAmount>625</UnpaidBalanceAmount> <CREDITLATEDATES DelinquencyRatingType="Late30Days"> <LateDate> </LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late60Days"> <LateDate> </LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late30Days"> <LateDate> </LateDate> </CREDITLATEDATES> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Lates Prior To 11/98</Comment> </CREDITCOMMENT> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Revolving Charge Account</Comment> </CREDITCOMMENT> </MERGEDLIABILITY> Page 3-7

24 Credit Response Section By Section Merged Liability and Repository Liability Data The MERGED LIABILITY container 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 MERGED LIABILITY container. The following sample is an abridged example of a single merged liability record. Sample Merged Liability: <MERGEDLIABILITY DataRepositorySourceType="MergedData"> <CreditorName>AMERICAN EXPRESS</CreditorName> <ReportedDate> </ReportedDate> <UnpaidBalance>1425</UnpaidBalance> </MERGEDLIABILITY> The REPOSITORY LIABILITY container is normally used only for quality control reports, or for customers who want to see the "merged data plus the original "repository" data duplicates. In this case, there is normally a MERGEDLIABILITY container that holds the "merged" data, and within that container there are multiple REPOSITORY LIABILITY containers - one for each liability record returned by a repository bureau. The following data sample demonstrates a typical display of "merged" data followed by the three original "repository" liabilities as received from the repository bureaus. Sample Merged Liability with Repository Liabilities: <MERGEDLIABILITY DataRepositorySourceType= MergedData > <CreditorName>AMERICAN EXPRESS</CreditorName> <ReportedDate> </ReportedDate> <UnpaidBalance>1425</UnpaidBalance> <REPOSITORYLIABILITY DataRepositorySourceType= Equifax > <CreditorName>AMEX</CreditorName> <ReportedDate> </ReportedDate> <UnpaidBalance>1425</UnpaidBalance> </REPOSITORYLIABILITY> <REPOSITORYLIABILITY DataRepositorySourceType= TransUnion > <CreditorName>AMERICAN EXPRESS</CreditorName> <ReportedDate> </ReportedDate> <UnpaidBalance>1100</UnpaidBalance> </REPOSITORYLIABILITY> <REPOSITORYLIABILITY DataRepositorySourceType= Experian > <CreditorName>AMER EXP</CreditorName> <ReportedDate> </ReportedDate> <UnpaidBalance>1400</UnpaidBalance> </REPOSITORYLIABILITY> </MERGEDLIABILITY> Page 3-8

25 Credit Response Section By Section Credit Late Dates and Payment Pattern Data The MISMO Credit Reporting DTD provides two methods for displaying a borrowers monthly payment history Credit Late Dates and Payment Pattern Data. The Credit Late Dates consist of a CREDITLATEDATES container for each month that the borrower was delinquent in making payments to a creditor. Each container has the date of the delinquency plus a Delinquency Rating 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 Late Dates: <MERGEDLIABILITY MERGEDLIABILITYID="CRLiab0004"> <CreditorName>BAY COMPANY</CreditorName> <!-- Other Liability Data Elements --> <CREDITLATEDATES DelinquencyRatingType="Late90Days"> <LateDate> </LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late60Days"> <LateDate> </LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late30Days"> <LateDate> </LateDate> </CREDITLATEDATES> </MERGEDLIABILITY> 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 PaymentPatternStartDate element. Each subsequent payment pattern character is for the next previous month. The following rating characters are used in the payment pattern: C = Current 1 5 = Number of months delinquent 7 = Wage Earner Plan 8 = Repossession 9 = Collection N = No Activity X = No data available Page 3-9

26 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 1996, the Payment Pattern Start date. The previous month, March 1996 also had a current rating of C. The next character in the pattern, 3, indicates that the borrower was three months late in February. The 2 indicates that the borrower was two months late in January, and finally one month late in December Sample Liability with Payment Pattern Data: <MERGEDLIABILITY MERGEDLIABILITYID="CRLiab0004"> <CreditorName>BAY COMPANY</CreditorName> <!-- Other Liability Data Elements --> <PaymentPatternData>CC321CCCCCCCCC</PaymentPatternData> <PaymentPatternStartDate> </PaymentPatternStartDate> </MERGEDLIABILITY> MERGEDPUBLICRECORD Required? Only if there is public record data to report. Purpose: Provides public record data merged from duplicate public records from more than one or more repository bureaus (Equifax, Experian, Trans Union). This container is also used when there is only data from a single repository bureau. When it is necessary to report the original repository public record data, the REPOSITORYPUBLICRECORD containers are used. RMCR Public Records may include a VERIFICATION container. Sample Merged Public Record Data: <MERGEDPUBLICRECORD MERGEDPUBLICRECORDID="CRPubR0001" DataRepositorySourceType="Equifax" PublicRecordDispositionType="Discharged" PublicRecordType="BankruptcyChapter7" BORROWERIDREFS="BorRec0001"> <CourtName>US BKPT CT MN MINNEAPO</CourtName> <DispositionDate> </DispositionDate> <DocketIdentifier> RJK</DocketIdentifier> <FiledDate> </FiledDate> <PaidDate> </PaidDate> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Bankruptcy CH 7</Comment> </CREDITCOMMENT> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Discharged 10/29/97</Comment> </CREDITCOMMENT> </MERGEDPUBLICRECORD> Page 3-10

27 Credit Response Section By Section CREDITINQUIRY Required? Only if there is inquiry data to report that meets the requester s inquiry age parameters (for example: less than 90 days old). Purpose: Provides a list of companies who have requested credit data on the referenced borrower. The Version sample inquiry data includes Business Type and Credit Loan Type data attributes that identify the type of credit being applied for by the borrower. Sample Inquiry Data (MISMO Version 1.0): <CREDITINQUIRY CREDITINQUIRYID="CRInqu0001" DataRepositorySourceType="Equifax" BORROWERIDREFS="BorRec0001"> <InquiringPartyName>FNANB/CIRC</InquiringPartyName> <InquiryDate> </InquiryDate> </CREDITINQUIRY> <CREDITINQUIRY CREDITINQUIRYID="CRInqu0002" DataRepositorySourceType="Experian" BORROWERIDREFS="BorRec0001"> <InquiringPartyName>CAPITAL ONE</InquiringPartyName> <InquiryDate> </InquiryDate> </CREDITINQUIRY> <CREDITINQUIRY CREDITINQUIRYID="CRInqu0003" DataRepositorySourceType="Equifax" BORROWERIDREFS="BorRec0001"> <InquiringPartyName>CAP ONE BANK</InquiringPartyName> <InquiryDate> </InquiryDate> </CREDITINQUIRY> Sample Inquiry Data (MISMO Version 1.0.1) <CREDITINQUIRY CREDITINQUIRYID="CRInqu0018" DataRepositorySourceType="Equifax" BusinessType= DepartmentAndMailOrder CreditLoanType= ChargeAccount BORROWERIDREFS="BorRec0001"> <InquiringPartyName>RNB-TARGET</InquiringPartyName> <InquiryDate> </InquiryDate> </CREDITINQUIRY> <CREDITINQUIRY CREDITINQUIRYID="CRInqu0019" DataRepositorySourceType="Experian" BusinessType= Banking CreditLoanType= CheckCreditOrLineOfCredit BORROWERIDREFS="BorRec0002"> <InquiringPartyName>CHASE ADVG</InquiringPartyName> <InquiryDate> </InquiryDate> </CREDITINQUIRY> Page 3-11

28 Credit Response Section By Section CREDITFILEVARIATION 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 bureau such as employment data, current and previous addresses. When identifying data in a credit file varies from the identifying data in the credit request, those variations are reported in the VARIATION TYPE container. If a credit file is not returned by a repository bureau, an error message will appear in the data as shown in the second sample below. Sample Credit File Data: <CREDITFILEVARIATION CREDITFILEVARIATIONID="CRFilEFX01" DataRepositorySourceType="Equifax" BORROWERIDREF="BorRec0001" CREDITSCOREIDREFS="CRScoEFX01"> <UnparsedName>TRACY A MOORE</UnparsedName> <FirstName>TRACY</FirstName> <MiddleName>A</MiddleName> <LastName>MOORE</LastName> <SSN> </SSN> <BorrowerBirthDate> </BorrowerBirthDate> <InfileDate> </InfileDate> <CREDITFILEADDRESS> <UnparsedAddressData> Current Address: 777 HILLSIDE, ELMHURST IL 60126, 09/98 </UnparsedAddressData> </CREDITFILEADDRESS> <CREDITFILEEMPLOYMENT> <UnparsedEmploymentData> Employer: CH TRANSIT AUTH </UnparsedEmploymentData> </CREDITFILEEMPLOYMENT> <VARIATIONTYPE VariationIndicator="DifferentLastName"/> </CREDITFILEVARIATION> Sample Credit File Error Data: <CREDITFILEVARIATION CREDITFILEVARIATIONID="CRFilTUC01"> <CREDITERRORMESSAGE ErrorMessageSource="RepositoryBureau"> <Message> Trans Union: Member Code Missing or Invalid </Message> </CREDITERRORMESSAGE> </CREDITFILEVARIATION Page 3-12

29 Credit Response Section By Section CREDITSUMMARY Required? No. Purpose: Provides text data summarizing key credit data in the credit report. There is no industry standard, format or requirement for credit summary data. Sample Credit Summary Data: <CREDITSUMMARY> <Summary> ACCT TYPE NBR W/BAL BALANCES PAYMENTS PAST DUE REAL ESTATE 2 1 $ $1154 $ INSTALLMENT $57112 $1038 $ REVOLVING $20635 $611 $ COLLECTION 0 $0 $0 $ OTHER 3 2 $47 $0 $ TOTAL $ $2803 $ REVOLVING CREDIT AVAILABLE: 3% OF $21445 ACCOUNTS PAID AS AGREED: 61 PUBLIC RECORDS BREAKDOWN ACCOUNTS CURRENTLY DELINQUENT: 6 LIENS: 0 ALL DELINQUENT ACCOUNTS: 10 JUDGEMENTS: 3 INQUIRIES: 27 FORECLOSURES: 0 PUBLIC RECORDS: 3 BANKRUPTCIES: 0 OTHER: 0 </Summary> </CREDITSUMMARY> CREDITERRORMESSAGE 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. Sample Error Message Data: <CREDITERRORMESSAGE ErrorMessageSource="CreditBureau"> <Message>Borrower SSN Missing</Message> </CREDITERRORMESSAGE> Page 3-13

30 Credit Response Section By Section CREDITCOMMENT Required? No. Purpose: Provides any type of additional comment text. The source could be the credit bureau, repository bureau, the borrower or other source. Sample Credit Comment Data: <CREDITCOMMENT CommentSource="Borrower"> <Comment> 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. </Comment> </CREDITCOMMENT> Page 3-14

31 Credit Response Section By Section CREDITSCORE 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. Sample Credit Score Data: <CREDITSCORE CREDITSCOREID="CRScoEFX01" DataRepositorySourceType="Equifax" ScoreModelNameType="EquifaxBeacon" BORROWERIDREFS="BorRec0001" CREDITFILEVARIATIONIDREFS="CRFilEFX01"> <CreditScoreValue>666</CreditScoreValue> <CREDITSCOREFACTOR> <ScoreFactorIdentifier>38</ScoreFactorIdentifier> <ScoreFactorDescription> Serious delinquency, and derogatory public record or collection filed </ScoreFactorDescription> </CREDITSCOREFACTOR> <CREDITSCOREFACTOR> <ScoreFactorIdentifier>14</ScoreFactorIdentifier> <ScoreFactorDescription> Length of time accounts have been established </ScoreFactorDescription> </CREDITSCOREFACTOR> <CREDITSCOREFACTOR> <ScoreFactorIdentifier>10</ScoreFactorIdentifier> <ScoreFactorDescription> Proportion of balances to credit limits is too high on bank revolving or other revolving accounts </ScoreFactorDescription> </CREDITSCOREFACTOR> <CREDITSCOREFACTOR> <ScoreFactorIdentifier>08</ScoreFactorIdentifier> <ScoreFactorDescription> Too many inquiries last 12 months </ScoreFactorDescription> </CREDITSCOREFACTOR> </CREDITSCORE> Page 3-15

32 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 CREDITERRORMESSAGE element of CREDITREPORT. Eventually, MISMO may develop a common errorreporting format for all transactions, but for now the credit error message container provides a method for reporting errors in the existing DTD. The sample data below demonstrates how to report an error in the credit request. Sample Error Report: <?xml version="1.0"?> <!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0"> <RESPONSE> <RESPONSEPARTY ResponseFormatType="XML" ResponseMethodType="FTP" PARTYIDREF="PrtyID12"/> <RECEIVINGPARTY PARTYIDREF="PrtyID15"/> <ResponseDateTime> T16:00:32</ResponseDateTime> </RESPONSE> <CREDITREQUEST CREDITREQUESTID="CreReq001"/> <PARTY PARTYID="PrtyID12" PartyType="ResponseParty"> <PartyName>INFO1 Bureau</PartyName> </PARTY> <PARTY PARTYID="PrtyID15" PartyType="ReceivingParty"/> <CREDITREPORT CreditReportType="Other"> <OtherCreditReportTypeDescription> Error Report </OtherCreditReportTypeDescription> <CREDITBUREAU PARTYIDREF="PrtyID12"/> <CREDITERRORMESSAGE ErrorMessageSource="CreditBureau"> <Message>Borrower SSN Missing</Message> </CREDITERRORMESSAGE> </CREDITREPORT> </MORTGAGEDATA> Page 4-1

33 Credit Reporting Elements and Attributes Chapter 5: Credit Reporting Elements and Attributes Detailed descriptions about individual elements and attributes used in the Credit Reporting DTD are contained in the commented version of the DTD CreditReportingComment#_#.dtd. The latest version can be downloaded from the web site. The web site also has copies of the Logical Data Dictionary for Credit Reporting CreditReportingDictionary#_#.htm. The following sample is an excerpt from the commented DTD. Sample DTD Section From CreditReportingComment1_0_1.dtd: <!ELEMENT PaymentPatternData (#PCDATA)> <!-- Subelement: PaymentPatternData --> <!-- Datatype: String --> <!-- Description: This is a set of previous monthly payment --> <!-- ratings beginning with the Payment Pattern --> <!-- Start Date. C=Current, 1-6=# Months Late, --> <!-- 7=Wage Earner Plan, 8=Repossession, --> <!-- 9=Collection, N=No Activity, X=No Data. --> <!ELEMENT PaymentPatternStartDate (#PCDATA)> <!-- Subelement: PaymentPatternStartDate --> <!-- Datatype: Date/Time --> <!-- Description: The date of the beginning of the data in --> <!-- the Credit Liability Payment Pattern Data. --> <!ELEMENT ReportedDate (#PCDATA)> <!-- Subelement: ReportedDate --> <!-- Datatype: Date/Time --> <!-- Description: The date that the credit liability data was --> <!-- reported by the liability holder. --> <!ELEMENT TermMonths (#PCDATA)> <!-- Subelement: TermMonths --> <!-- Datatype: Numeric --> <!-- Description: The total number of months established as --> <!-- terms for repayment of a loan. --> <!ELEMENT TermsDescription (#PCDATA)> <!-- Subelement: TermsDescription --> <!-- Datatype: String --> <!-- Description: A text description for the loan terms --> <! (for example, 360 months at $820 per month). --> <!ELEMENT UnpaidBalanceAmount (#PCDATA)> <!-- Subelement: UnpaidBalanceAmount --> <!-- Datatype: Money --> <!-- Description: The balance owed on a liability account --> <!-- as of the Date Reported by a repository bureau or credit --> <!-- bureau. --> Page 5-1

34 Credit Reporting DTD Change List Chapter 6: Credit Reporting DTD Change List The following table summarizes the changes to the MISMO Credit Reporting DTD since Version 1.0. Details of the changes are contained in the CreditReportingChangeList#_#.doc document that is issued with each updated DTD. Version Issue Date Element or Attribute Container(s) Affected Change Description Original Version CreditLoanType CREDITINQUIRY Added the existing attribute to CREDITINQUIRY to allow identification of the type of loan that was the subject of the inquiry. OtherLiabilityTypeDescription CREDITINQUIRY This existing element was added to CREDITINQUIRY to hold the loan type description when CreditLoanType = Other. BusinessType PublicRecordType MERGEDLIABILITY REPOSITORYLIABILITY CREDITINQUIRY MERGEDPUBLICRECORD REPOSITORYUBLICRECORD This new attribute identifies the type of business of the either the liability holder or entity requesting the credit report. Added RealEstateRecording as a new enumeration of the existing PublicRecordType attribute. BORROWERIDREFS CREDITREQUEST Added the existing attribute to CREDITREQUEST to allow borrowers for each credit request to be identified, when there are more than one borrower or borrower pair on a loan. Page 6-1

35 Questions and Answers Chapter 7: Questions and Answers What are the minimum required elements for requesting a Merge Credit Report? There are several data elements that are required to successfully process a request for a Merge Credit Report. Different credit bureaus may have additional minimum requirements. InternalAccountIdentifier Element (REQUEST container) 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. Credit Request Options (Report Type= Merge, Action= Submit, plus which repository bureaus to be included in the report. Contact Name (from a Requesting Party PARTY container) Identifies who requested the credit report. This name normally appears on the credit report and sometimes on the billing invoice from the credit bureau. Borrower Data (Full Name with Suffix), Current Address, SSN. Sample Minimal Merge Credit Request File (MISMO Version 1.0.1): <?xml version="1.0"?> <!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0.1"> <REQUESTGROUP> <REQUESTINGPARTY PARTYIDREF="PrtyID0001"/> <RequestDateTime> T13:28:21</RequestDateTime> <REQUEST RequestType="Credit"> <InternalAccountIdentifier>ABC9024</InternalAccountIdentifier> </REQUEST> </REQUESTGROUP> <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual" TransUnionIncludedIndicator="Y" BORROWERIDREF= BorRec0182 /> <PARTY PARTYID="PrtyID0001" PartyType="RequestingParty"> <PartyName>ABC MORTGAGE COMPANY</PartyName> <CONTACTDETAIL> <ContactName>BRETT SMITH</ContactName> </CONTACTDETAIL> </PARTY> <BORROWER BORROWERID="BorRec0182"> <FirstName>John</FirstName> <LastName>Curly</LastName> <NameSuffix>SR</NameSuffix> <SSN> </SSN> <BORROWERRESIDENCE ResidencyType="Current"> <Address1>555 Adams ST</Address1> <City>Fantasy Island</City> <State>IL</State> <PostalCode>60750</PostalCode> </BORROWERRESIDENCE> </BORROWER> </MORTGAGEDATA> Page 7-1

36 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 you could get a Dispute flag, an Insurance Claim, a Past Due amount and a MOP indicating Not Paid As Agreed. Do we pick the "worst" of the possible X12 Rating Codes that match one of the above? In another example, you could have 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. 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 BORROWERIDREFS 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 IDREFs 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 BORROWERID="Borrower", and the other as BORROWERID="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 IDREF attribute: BORROWERIDREFS="Borrower" BORROWERIDREFS="Coborrower" BORROWERIDREFS="Borrower Coborrower" (for joint ownership). Alternatively, the BORROWERID could be set to the borrower s SSN or name. If the first borrower was Jonathan Consumer and his spouse was Mary Page 7-2

37 Questions and Answers Consumer, and we used their names as the BORROWERID values, then the BORROWERIDREFS 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"> <UnparsedName>JONATHAN CONSUMER</UnparsedName> <FirstName>JONATHAN</FirstName> <LastName>CONSUMER</LastName> <SSN> </SSN> </BORROWER> <BORROWER BORROWERID="Mary_Consumer"> <UnparsedName>MARY CONSUMER</UnparsedName> <FirstName>MARY</FirstName> <LastName>CONSUMER</LastName> <SSN> </SSN> </BORROWER> <MERGEDLIABILITY BORROWERIDREFS="Jonathan_Consumer > <CreditorName>American Express</CreditorName> <!-- Other Liability Data Elements --> </MERGEDLIABILITY> <MERGEDLIABILITY BORROWERIDREFS="Mary_Consumer > <CreditorName>Ford Motor Credit</CreditorName> <!-- Other Liability Data Elements --> </MERGEDLIABILITY> <MERGEDLIABILITY BORROWERIDREFS="Jonathan_Consumer Mary_Consumer > <CreditorName>Countrywide</CreditorName> <!-- Other Liability Data Elements --> </MERGEDLIABILITY> Why is the CREDITREQUEST container separate from the REQUESTGROUP? In the original pre-1.0 versions of the MISMO DTD, the CREDITREQUEST container was within the REQUESTGROUP/REQUEST containers. Before the 1.0 release, CREDITREQUEST was moved out to reside directly under the root MORTGAGEDATA container. This was done to make it simpler for implementations using an envelope structure around the MISMO XML data, like Biztalk or SOAP. In these environments, much of the request and response data is contained in the envelope structure. By removing CREDITREQUEST from the MISMO request structure, it allows implementations using outside envelopes to still use the credit request data without having to navigate through an unnecessary REQUESTGROUP and REQUEST container. Implementations that use the MIMSO Request/Response containers will still have easy access to the credit request data. Page 7-3

38 Questions and Answers Why is the CREDITREQUEST container included in response transactions? Including the original CREDITREQUEST data in the response transaction allows quick reference to the original parameters specified in the request. This is similar to showing the quantity ordered on a packing list accompanying goods shipment. Which credit response elements indicate that a request to a repository bureau failed? In the response transaction sample below, three repository bureaus were requested as shown in the CREDITREQUEST container, but only two bureaus were returned as shown in the CREDITREPORT container. The CREDITERRORMESSAGE container displays the reason for the data not being returned from the third repository bureau. Sample Showing Bureaus Requested and Bureaus Reported: <MORTGAGEDATA MISMOVersionID="1.0"> <CREDITREQUEST CreditRequestType="Individual" EquifaxIncludedIndicator="Y" ExperianIncludedIndicator="Y" TransUnionIncludedIndicator="Y"/>... Borrower data could appear here... <CREDITREPORT CreditReportType="Merge" EquifaxIncludedIndicator="Y" TransUnionIncludedIndicator="Y"> <CreditReportIdentifier> </CreditReportIdentifier> <FirstIssuedDate> </FirstIssuedDate>... Liability data could appear here Public Record data could appear here Inquiry data could appear here... <CREDITERRORMESSAGE ErrorMessageSource="RepositoryBureau"> <Message>Experian: Invalid Security Password</Message> </CREDITERRORMESSAGE> </CREDITREPORT> </MORTGAGEDATA> Page 7-4

39 Questions and Answers What is the purpose of having the ALIAS container in the Credit Reporting DTD? The ALIAS container under BORROWER mimics the data from Alternate Name lines at the end of Section VI of the 1003/65 Loan Application. Like the paper loan application, it has Alias Name, Creditor Name and Account # fields. This data is only normally supplied on RMCR (Residential Mortgage Credit Report) requests to a credit bureau, where a more detailed credit investigation is performed. In an RMCR investigation, credit bureaus will normally pull credit files on the alias names in addition to the borrower names supplied in the loan application. It is not used for processing the normal Merge credit reports. Sample Alias Data from an RMCR Credit Request: <ALIAS> <AccountIdentifier> </AccountIdentifier> <CreditorName>KMART</CreditorName> <AliasName>Rainman</AliasName> </ALIAS> What is the purpose of the REPOSITORYLIABILITY container? This container is normally used only for quality control reports or for reports where it is necessary to show all of the data elements that were used to create the blended or merged liability record data within the MERGEDLIABILITY container element. More discussion on this topic can be referenced on page 3-8 of this guide. Page 7-5