XML Implementation Guide: Credit Reporting

(1)

XML Implementation Guide:

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)

XML Implementation Guide:

Credit Reporting

Document Revision Date: January 10, 2001

TABLE OF CONTENTS

CHAPTER 1: INTRODUCTION... 1-1

PURPOSE OF THIS DOCUMENT... 1-1 Version and Release... 1-1 Comments... 1-1 OVERVIEW... 1-1

CHAPTER 2: CREDIT REQUEST – SECTION BY SECTION... 2-1

CREDIT REQUEST SECTIONS ... 2-1 REQUESTGROUP... 2-2 CREDITREQUEST ... 2-2 Typical Credit Request Options ... 2-3 Selecting Number of Bureaus To Be Requested ... 2-3 Reissue Request... 2-4 Upgrade to RMCR Request... 2-4 Requesting Credit For Multiple Borrowers on a Loan ... 2-4 PARTY ... 2-6 BORROWER... 2-7 APPLICATION ... 2-9 ASSET ... 2-9 BORROWERRECONCILEDLIABILITY... 2-9 INCOME... 2-10 PROPERTY... 2-10

CHAPTER 3: CREDIT RESPONSE – SECTION BY SECTION... 3-1

CREDIT REPORT SECTIONS... 3-1 RESPONSE ... 3-2 CREDITREQUEST ... 3-2 PARTY ... 3-3 BORROWER... 3-4 ASSET ... 3-5 INCOME... 3-5 PROPERTY... 3-5 CREDITREPORT... 3-6 MERGEDLIABILITY... 3-7 Merged Liability and Repository Liability Data ... 3-8 Credit Late Dates and Payment Pattern Data ... 3-9 MERGEDPUBLICRECORD ... 3-10 CREDITINQUIRY ... 3-11 CREDITFILEVARIATION ... 3-12 CREDITSUMMARY ... 3-13 CREDITERRORMESSAGE ... 3-13 CREDITCOMMENT... 3-14 CREDITSCORE ... 3-15

CHAPTER 4: CREDIT ERROR RESPONSE... 4-1 CHAPTER 5: CREDIT REPORTING ELEMENTS AND ATTRIBUTES... 5-1

(4)

CHAPTER 6: CREDIT REPORTING DTD CHANGE LIST ... 6-1 CHAPTER 7: QUESTIONS AND ANSWERS... 7-1

WHAT ARE THE MINIMUM REQUIRED ELEMENTS FOR REQUESTING A MERGE CREDIT REPORT? ... 7-1 WHAT IS THE MISMO XML EQUIVALENT TO THE X12 RATING REMARKS? ... 7-2 WHERE IS THE “WHOSE FILE” FLAG FOR LIABILITIES, PUBLIC RECORDS, ETC.?... 7-2 WHY IS THE CREDITREQUEST CONTAINER SEPARATE FROM THE REQUESTGROUP? ... 7-3 WHY IS THE CREDITREQUEST CONTAINER INCLUDED IN RESPONSE TRANSACTIONS? ... 7-4 WHICH CREDIT RESPONSE ELEMENTS INDICATE THAT A REQUEST TO A REPOSITORY BUREAU FAILED? ... 7-4 WHAT IS THE PURPOSE OF HAVING THE ALIAS CONTAINER IN THE CREDIT REPORTING DTD?... 7-5 WHAT IS THE PURPOSE OF THE REPOSITORYLIABILITY CONTAINER?... 7-5

(5)

Chapter 1: Introduction

Purpose of this Document

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 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 – INFO1 [[email protected]]

Bill Parker – First American Interactive [[email protected]

]

Overview

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.

(6)

CREDIT REPORT DTD

ELEMENT USAGE

X = Element Is Used

Primary COMPONENT NAMES Mer

g

e R

e

quest

Score Only Request RM

CR Re

que

s

t

Merge Response Score Only Response RMCR Response Error Re

port

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.

(7)

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 www.mismo.org 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>

(8)

REQUESTGROUP

Usage:

MERGE SCORE

Only RMCR

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:

CREDITREQUEST

Usage:

MERGE SCORE

Only RMCR

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” />

(9)

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”>

(10)

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>02-2030409</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>01-0023991</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 1.0.1 or later, since it requires the use of the

(11)

Sample Credit Request – Multiple Borrower Sets:

<?xml version="1.0"?>

<!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0.1"> <REQUESTGROUP> <RequestDateTime>2000-11-19T16:59:11</RequestDateTime> <REQUEST RequestType="Credit"> <InternalAccountIdentifier> ABC9024 </InternalAccountIdentifier> </REQUEST> </REQUESTGROUP> <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Joint" TransUnionIncludedIndicator="Y" BORROWERIDREF=”BorRec0001 BorRec0002”/> <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual" TransUnionIncludedIndicator="Y" BORROWERIDREF=”BorRec0003”/> <CREDITREQUEST CreditReportRequestedActionType="Submit" CreditReportType="Merge" CreditRequestType="Individual" TransUnionIncludedIndicator="Y" BORROWERIDREF=”BorRec0004”/> <BORROWER BORROWERID="BorRec0001"> <FirstName>John</FirstName> <LastName>Doe</LastName> <NameSuffix>JR</NameSuffix> <SSN>123457001</SSN>

...Borrower Residence Elements... </BORROWER>

<BORROWER BORROWERID="BorRec0002">

<FirstName>Jane</FirstName> <LastName>Doe</LastName> <SSN>123457002</SSN>

...Borrower Residence Elements... </BORROWER> <BORROWER BORROWERID="BorRec0003"> <FirstName>John</FirstName> <LastName>Doe</LastName> <NameSuffix>SR</NameSuffix> <SSN>123456001</SSN>

...Borrower Residence Elements... </BORROWER> <BORROWER BORROWERID="BorRec0004"> <FirstName>Henry</FirstName> <LastName>Block</LastName> <NameSuffix>III</NameSuffix> <SSN>123456002</SSN>

...Borrower Residence Elements... </BORROWER>

(12)

PARTY

Usage:

MERGE SCORE

Only RMCR

Required? No.

Purpose:

This element container provides name, address, contact, phone,

fax and email 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>7048473995</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>

(13)

BORROWER

Usage:

MERGE SCORE

Only RMCR

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>344767777</SSN> <ALIAS> <AccountIdentifier>23592-1</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>8848273373</ContactPointValue> </CONTACTPOINT> <CONTACTPOINT ContactPointType="Email" PreferenceIndicator=”Y”>

<ContactPointValue>[email protected]</ContactPointValue> </CONTACTPOINT>

(14)

<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>356704444</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>

(15)

APPLICATION

Usage:

MERGE

SCORE Only

RMCR

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> 2000-11-05 </ApplicationInterviewerSignedDate> <BorrowerApplicationSignedDate> 2000-11-05 </BorrowerApplicationSignedDate> </APPLICATION>

ASSET

Usage:

MERGE

SCORE Only

RMCR

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>2923750-23</AssetAccountIdentifier> <AssetCashOrMarketValueAmount> 11278 </AssetCashOrMarketValueAmount> </ASSET>

BORROWERRECONCILEDLIABILITY

Usage:

MERGE

SCORE Only

RMCR

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:

(16)

INCOME

Usage:

MERGE

SCORE Only

RMCR

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

Usage:

MERGE

SCORE Only

RMCR

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>

(17)

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 www.mismo.org 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

<!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>

(18)

RESPONSE

Usage:

MERGE SCORE

Only RMCR

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> ftp://mfDVM:[email protected]/MF9234/out/2325.xml </ResponseDestinationDescription> </RESPONSEPARTY> <RECEIVINGPARTY PARTYIDREF="PrtyID0002"/> <KEY> <KeyName>Loan ID</KeyName> <KeyValue>232-239588HB</KeyValue> </KEY> <ResponseDateTime>2000-11-06T13:10:34</ResponseDateTime> </RESPONSE>

CREDITREQUEST

Usage:

MERGE SCORE

Only RMCR

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"/>

(19)

PARTY

Usage:

MERGE SCORE

Only RMCR

Required? No.

Purpose:

This element container provides name, address, contact, phone,

fax and email 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>8232263230</ContactPointValue> </CONTACTPOINT> <CONTACTPOINT ContactPointType="Email" 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>7048473995</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>

(20)

BORROWER

Usage:

MERGE SCORE

Only RMCR

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>344767777</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>2000-11-05</VerifiedByDate> <VerifiedByName>SBT</VerifiedByName> </VERIFICATION> </EMPLOYMENT> </BORROWER> <BORROWER BORROWERID="BorRec0002"> <UnparsedName>MARC SCHNEIDNER</UnparsedName> <FirstName>MARC</FirstName> <LastName>SCHNEIDNER</LastName> <SSN>356704444</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>

(21)

ASSET

Usage:

MERGE

SCORE Only

RMCR

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>2923750-23</AssetAccountIdentifier> <AssetCashOrMarketValueAmount> 11278 </AssetCashOrMarketValueAmount> <VERIFICATION VerificationStatusType=”Verified” VerificationType=”Asset”> <VerifiedByName>Jennifer B</VerifiedByName> <VerifiedDate>2000-11-05</VerifiedDate> </VERIFICATION> </ASSET>

INCOME

Usage:

MERGE

SCORE Only

RMCR

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

Usage:

MERGE

SCORE Only

RMCR

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>

(22)

CREDITREPORT

Usage:

MERGE

SCORE Only

RMCR

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>

(23)

MERGEDLIABILITY

Usage:

MERGE

SCORE Only

RMCR

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>5993522222</AccountIdentifier> <AccountOpenedDate>1996-06</AccountOpenedDate> <CreditorName>Juniper MC</CreditorName> <HighCreditAmount>704</HighCreditAmount> <LastActivityDate>2000-10</LastActivityDate> <Late30DaysCount>2</Late30DaysCount> <Late60DaysCount>1</Late60DaysCount> <Late90DaysCount>0</Late90DaysCount> <MonthsReviewedCount>16</MonthsReviewedCount> <MonthlyPaymentAmount>36</MonthlyPaymentAmount> <PastDueAmount>0</PastDueAmount> <PaymentPatternData> CCCCCCCCCCCCCCC12CC1CCCC </PaymentPatternData> <PaymentPatternStartDate>1998-11</PaymentPatternStartDate> <ReportedDate>2000-10</ReportedDate> <TermsDescription>$36/MO</TermsDescription> <UnpaidBalanceAmount>625</UnpaidBalanceAmount> <CREDITLATEDATES DelinquencyRatingType="Late30Days"> <LateDate>2000-02</LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late60Days"> <LateDate>2000-03</LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late30Days"> <LateDate>2000-06</LateDate> </CREDITLATEDATES> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Lates Prior To 11/98</Comment> </CREDITCOMMENT>

<CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Revolving Charge Account</Comment> </CREDITCOMMENT>

(24)

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>2000-10</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>2000-10</ReportedDate> <UnpaidBalance>1425</UnpaidBalance> <REPOSITORYLIABILITY DataRepositorySourceType=”Equifax”> <CreditorName>AMEX</CreditorName> <ReportedDate>2000-10</ReportedDate> <UnpaidBalance>1425</UnpaidBalance> </REPOSITORYLIABILITY> <REPOSITORYLIABILITY DataRepositorySourceType=”TransUnion”> <CreditorName>AMERICAN EXPRESS</CreditorName> <ReportedDate>2000-09</ReportedDate> <UnpaidBalance>1100</UnpaidBalance> </REPOSITORYLIABILITY> <REPOSITORYLIABILITY DataRepositorySourceType=”Experian”> <CreditorName>AMER EXP</CreditorName> <ReportedDate>2000-10</ReportedDate> <UnpaidBalance>1400</UnpaidBalance> </REPOSITORYLIABILITY> </MERGEDLIABILITY>

(25)

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>

<CREDITLATEDATES DelinquencyRatingType="Late90Days"> <LateDate>1996-02</LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late60Days"> <LateDate>1996-01</LateDate> </CREDITLATEDATES> <CREDITLATEDATES DelinquencyRatingType="Late30Days"> <LateDate>1995-12</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

(26)

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 1995.

Sample Liability with Payment Pattern Data:

<MERGEDLIABILITY MERGEDLIABILITYID="CRLiab0004"> <CreditorName>BAY COMPANY</CreditorName>

<PaymentPatternData>CC321CCCCCCCCC</PaymentPatternData> <PaymentPatternStartDate> 1996-04 </PaymentPatternStartDate> </MERGEDLIABILITY>

MERGEDPUBLICRECORD

Usage:

MERGE

SCORE Only

RMCR

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>1997-10-29</DispositionDate> <DocketIdentifier>9700000RJK</DocketIdentifier> <FiledDate>1997-07</FiledDate> <PaidDate>1997-10-29</PaidDate> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Bankruptcy CH 7</Comment> </CREDITCOMMENT> <CREDITCOMMENT CommentSource="RepositoryBureau"> <Comment>Discharged 10/29/97</Comment> </CREDITCOMMENT> </MERGEDPUBLICRECORD>

(27)

CREDITINQUIRY

Usage:

MERGE

SCORE Only

RMCR

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 1.0.1 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>2000-05-13</InquiryDate> </CREDITINQUIRY> <CREDITINQUIRY CREDITINQUIRYID="CRInqu0002" DataRepositorySourceType="Experian" BORROWERIDREFS="BorRec0001"> <InquiringPartyName>CAPITAL ONE</InquiringPartyName> <InquiryDate>2000-03-22</InquiryDate> </CREDITINQUIRY> <CREDITINQUIRY CREDITINQUIRYID="CRInqu0003" DataRepositorySourceType="Equifax" BORROWERIDREFS="BorRec0001">

<InquiringPartyName>CAP ONE BANK</InquiringPartyName> <InquiryDate>2000-03-22</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>1999-11-26</InquiryDate> </CREDITINQUIRY> <CREDITINQUIRY CREDITINQUIRYID="CRInqu0019" DataRepositorySourceType="Experian" BusinessType=”Banking” CreditLoanType=”CheckCreditOrLineOfCredit” BORROWERIDREFS="BorRec0002"> <InquiringPartyName>CHASE ADVG</InquiringPartyName> <InquiryDate>1999-11-16</InquiryDate> </CREDITINQUIRY>

(28)

CREDITFILEVARIATION

Usage:

MERGE

SCORE Only

RMCR

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>344767777</SSN> <BorrowerBirthDate>1970-09-21</BorrowerBirthDate> <InfileDate>1988-05</InfileDate> <CREDITFILEADDRESS> <UnparsedAddressData>

Current Address: 777 HILLSIDE, ELMHURST IL 60126, 09/98

</UnparsedAddressData> </CREDITFILEADDRESS> <CREDITFILEEMPLOYMENT> <UnparsedEmploymentData>

Employer: CH TRANSIT AUTH

</UnparsedEmploymentData> </CREDITFILEEMPLOYMENT>

Sample Credit File Error Data:

<CREDITFILEVARIATION CREDITFILEVARIATIONID="CRFilTUC01"> <CREDITERRORMESSAGE ErrorMessageSource="RepositoryBureau"> <Message>

Trans Union: Member Code Missing or Invalid

</Message>

</CREDITERRORMESSAGE> </CREDITFILEVARIATION

(29)

CREDITSUMMARY

Usage:

MERGE

SCORE Only

RMCR

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:

ACCT TYPE NBR W/BAL BALANCES PAYMENTS PAST DUE 30 60 90+ REAL ESTATE 2 1 $125583 $1154 $0 0 0 0 INSTALLMENT 43 21 $57112 $1038 $0 15 4 13 REVOLVING 22 38 $20635 $611 $20 21 8 6 COLLECTION 0 $0 $0 $0 - - - OTHER 3 2 $47 $0 $47 1 0 0 TOTAL 70 42 $203377 $2803 $67 37 12 19 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

Usage:

MERGE

SCORE Only

RMCR

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>

(30)

CREDITCOMMENT

Usage:

MERGE

SCORE Only

RMCR

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>

(31)

CREDITSCORE

Usage:

MERGE SCORE

Only RMCR

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>

<ScoreFactorIdentifier>10</ScoreFactorIdentifier> <ScoreFactorDescription>

Proportion of balances to credit limits is too high on bank revolving or other revolving accounts

<ScoreFactorIdentifier>08</ScoreFactorIdentifier> <ScoreFactorDescription>

Too many inquiries last 12 months

(32)

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

error-reporting 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:

<!DOCTYPE MORTGAGEDATA SYSTEM "CreditReporting1_0.DTD"> <MORTGAGEDATA MISMOVersionID="1.0"> <RESPONSE> <RESPONSEPARTY ResponseFormatType="XML" ResponseMethodType="FTP" PARTYIDREF="PrtyID12"/> <RECEIVINGPARTY PARTYIDREF="PrtyID15"/> <ResponseDateTime>2000-10-23T16: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>

(33)

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 www.mismo.org 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)>

<!ELEMENT PaymentPatternStartDate (#PCDATA)>

<!ELEMENT ReportedDate (#PCDATA)>

<!ELEMENT TermMonths (#PCDATA)>

<!ELEMENT TermsDescription (#PCDATA)>

<!— (for example, 360 months at $820 per month). --> <!ELEMENT UnpaidBalanceAmount (#PCDATA)>

(34)

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

1.0 2000-07-07 Original Version

1.0.1 2000-09-27

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 MERGEDLIABILITY

REPOSITORYLIABILITY CREDITINQUIRY

This new attribute identifies the type of business of the either the liability holder or entity requesting the credit report.

PublicRecordType MERGEDPUBLICRECORD REPOSITORYUBLICRECORD

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.

(35)

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>2000-11-10T13: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>321884361</SSN> <BORROWERRESIDENCE ResidencyType="Current">

<Address1>555 Adams ST</Address1>

<City>Fantasy Island</City> <State>IL</State> <PostalCode>60750</PostalCode> </BORROWERRESIDENCE> </BORROWER> </MORTGAGEDATA>

(36)

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

(37)

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>548603388</SSN> </BORROWER> <BORROWER BORROWERID="Mary_Consumer" > <UnparsedName>MARY CONSUMER</UnparsedName> <FirstName>MARY</FirstName> <LastName>CONSUMER</LastName> <SSN>556600290</SSN> </BORROWER> <MERGEDLIABILITY BORROWERIDREFS="Jonathan_Consumer” > <CreditorName>American Express</CreditorName>

</MERGEDLIABILITY>

<MERGEDLIABILITY BORROWERIDREFS="Mary_Consumer” > <CreditorName>Ford Motor Credit</CreditorName>

</MERGEDLIABILITY>

<MERGEDLIABILITY BORROWERIDREFS="Jonathan_Consumer Mary_Consumer” > <CreditorName>Countrywide</CreditorName>

</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.

(38)

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 wer