Copyright © 2006-2010 CoreLogic Flood Services
Abstract
This document contains the basic information needed in order to interact with the CoreLogic Flood Services implementation of the Mortgage Insurance Standards Maintenance Organization (MISMO) Flood 2.4 specification.
Part I, “MISMO Flood 2.4 Structure” describes the structure of the data format used to exchange flood requests and responses.
Part II, “CoreLogic Connectivity” covers the technical aspects of interacting with the CoreLogic web service, including how to provide login credentials for authentication.
Part III, “Test Cases” provides an overview of common things to test, including receipt of updated or completed orders.
The CoreLogic Flood Services interface is based on the exchange of XML request and response documents. The structure of these documents is defined by the Mortgage Insurance Standards Maintenance Organization (MISMO) Flood 2.4 Document Type Definition (DTD). A DTD is a set of rules used to define the valid structure of an XML document. An XML Schema is an alternate to DTD that allows richer definition of data constraints.
The Flood 2.4 DTD files and corresponding XML Schema files are available for download from the MISMO website.
XML development platforms usually provide a mechanism to validate an XML document against either a DTD or XML Schema. Validation should be used at least during initial development to make sure that all of the files that are sent and received through the CoreLogic XML interface are well-formed and valid against the appropriate DTD.
This implementation has passed the MISMO MXCompliance Response Export certification process.
All actions by the client are initiated via an XML flood request document. The type of action being requested is specified in the _ActionType attribute of the FLOOD_REQUEST element. The _ActionType attribute can be Original, StatusQuery, Cancellation, Reissue, Dispute, or Upgrade. The Transfer action is not currently supported.
The available request action types are described below, with a brief XML example for each type highlighting the required fields.
Request a new flood determination.
Example 2.1. Original Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount" RequestDatetime="2003-01-20T23:10:56"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Original"> <_PRODUCT _CategoryDescription="Flood"> <_NAME _Identifier="FL"/> </_PRODUCT> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="7600 Hunters Mill Rd" _City="Blacksburg" _State="VA" _PostalCode="24060"> </PROPERTY> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
The basic information needed in an Original request is the account information, the flood product being requested, the loan information, and the property information. The following brief examples highlight each of these separately. For a more complete Original request, see Section 1.7, “Common Fields Combined”.
Each client is given a login account and password when the account is set up. These credentials do not belong in the xml. They are submitted via the HTTP Basic Authentication mechanism as described in Chapter 5, Plain XML over HTTPS.
If the login account is ordering on behalf of another account, called an "internal account", then that internal account is specified in the InternalAccountIdentifier attribute of the REQUEST element.
Example 2.2. Request with InternalAccountIdentifier
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
A flood product is optional in the request. If there is no product specified then the default product on the CoreLogic account is used.
The product is indicated in the _PRODUCT element by specifying the CoreLogic product code in the _Identifier attribute of the _NAME child element. The most common product codes are listed in the table below. For a complete list of products geared to your business, please contact the Account Management department at 800-447-1772.
Table 2.1. Common Product Codes
Description | Code |
---|---|
Basic Flood Determination | F |
Life-of-Loan Flood Determination | FL |
Life-of-Loan with Census | FLC |
Life-of-Loan Related Loan | FLR |
Example 2.3. Product
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT _CategoryDescription="Flood"> <_NAME _Identifier="FL"/> </_PRODUCT> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
Borrower name and loan number are not strictly required, but they are recommended. The borrower's name goes in the _FirstName and _LastName attributes of the BORROWER element. The loan number goes in the LenderCaseIdentifier attribute of the MORTGAGE_TERMS element.
Example 2.4. Loan
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
Basic property information is required. The address of the property for which the flood determination is being requested maps to the attributes of the PROPERTY element.
Example 2.5. Property
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY _StreetAddress="7600 Hunters Mill Rd" _City="Blacksburg" _State="VA" _PostalCode="24060"/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
In addition, an optional assessor's parcel number or legal description may be specified to help identify the property if the order needs to be researched.
The assessor's parcel number goes in the AssessorsParcelIdentifier attribute of PROPERTY, while the legal description goes in the _LEGAL_DESCRIPTION child element of PROPERTY. The _Type attribute of _LEGAL_DESCRIPTION is always "Other" and the _TextDescription attribute contains the actual text of the description.
Example 2.6. Legal Description and Assessor's Parcel Identifier
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY _StreetAddress="7600 Hunters Mill Rd" _City="Blacksburg" _State="VA" _PostalCode="24060" AssessorsParcelIdentifier="myApn123"> <_LEGAL_DESCRIPTION _Type="Other" _TextDescription="legal desc"/> </PROPERTY> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
There are a few data items that are not required, but may be helpful to the client for billing or tracking purposes. These reference fields are described below.
The RequestingPartyBranchIdentifier attribute of the REQUEST element identifies the cost center to which the request will be billed. It will print on the FEMA form in Section I, Box 1.
Example 2.7. Branch
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST RequestingPartyBranchIdentifier="MyCostCenterId"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
The additional reference identifier is a single piece of information that will be stored in our system along with the flood determination. By default, it will print on the FEMA form in Section I, Box 1. If you do not want it displayed on the form, a CoreLogic account representative can change that preference.
Example 2.8. Additional Reference Identifier
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" FEMAAdditionalLenderDescription="MyRefNum"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
If an item of data needs to be stored with the order, but it is not a normal field on the FEMA form, then that data can be submitted using a KEY element with the name "FAFDS.TrackingIdentifier". The data will be returned in all responses in a KEY element with the same name. This field can be used to store identifiers that clients can use to match requests to responses. It will not print on the FEMA form.
Example 2.9. Tracking Identifier
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <KEY _Name="FAFDS.TrackingIdentifier" _Value="MyTrackingId"/> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
The lender identifier is the value that prints on the FEMA form in Section I, Box 3.
A default lender identifier can be configured for an CoreLogic account. This default value will automatically print on the FEMA form created by CoreLogic. Please contact the Account Management department at 800-447-1772 to set this up.
Alternatively, a lender identifier can be submitted on a request-by-request basis using the RegulatoryAgencyLenderIdentifier attribute of the FLOOD_REQUEST element as shown in the following example. However, this is not necessary if there is a default lender identifier configured for the account.
Example 2.10. Lender Identifier
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST RegulatoryAgencyLenderIdentifier="MyLenderId" MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
If the account is set up to allow it, a fax and/or email request for additional information can be sent to the processor when an order that is being researched requires more data to complete the determination. The relevant fax/email information that is on the account can be overridden by specifying a CONTACT_DETAIL in the REQUESTING_PARTY element.
Within that CONTACT_DETAIL, the CONTACT_POINT with _RoleType "Work" and _Type "Email" is the email address to which requests for additional information will be emailed. The CONTACT_POINT with _RoleType 'Work" and _Type "Fax" is the fax number to which requests for additional information will be faxed.
Example 2.11. Contact Information
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUESTING_PARTY> <CONTACT_DETAIL _Name="Mary Processor"> <CONTACT_POINT _RoleType="Work" _Type="Phone" _Value="512-555-1234"/> <CONTACT_POINT _RoleType="Work" _Type="Fax" _Value="512-555-2345"/> <CONTACT_POINT _RoleType="Work" _Type="Email" _Value="mp@mydomain.com"/> </CONTACT_DETAIL> </REQUESTING_PARTY> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
The following example combines the fields shown separately in previous sections to provide a representative sample of a complete Original request. Refer to those sections for detailed explanations of each field.
Example 2.12. Common Fields Combined
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUESTING_PARTY> <CONTACT_DETAIL _Name="Mary Processor"> <CONTACT_POINT _RoleType="Work" _Type="Phone" _Value="512-555-1234"/> <CONTACT_POINT _RoleType="Work" _Type="Fax" _Value="512-555-2345"/> <CONTACT_POINT _RoleType="Work" _Type="Email" _Value="mp@mydomain.com"/> </CONTACT_DETAIL> <PREFERRED_RESPONSE _Format="PDF" _Method="File" _UseEmbeddedFileIndicator="Y"/> </REQUESTING_PARTY> <REQUEST InternalAccountIdentifier="AskForAccount" RequestingPartyBranchIdentifier="MyCostCenterId" RequestDatetime="2003-01-20T23:10:56"> <KEY _Name="FAFDS.TrackingIdentifier" _Value="MyTrackingId"/> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Original" RegulatoryAgencyLenderIdentifier="MyLenderId" FEMAAdditionalLenderDescription="MyRefNum"> <_PRODUCT _CategoryDescription="Flood"> <_NAME _Identifier="FL"/> </_PRODUCT> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="7600 Hunters Mill Rd" _City="Blacksburg" _State="VA" _PostalCode="24060"> </PROPERTY> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
Look up an existing determination, usually to check if an in-research item has been completed.
Example 2.13. StatusQuery Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="StatusQuery" FloodCertificationIdentifier="9999999999"> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
All that is needed is the flood certification number of the order to query. This is contained in the FloodCertificationIdentifier attribute of the FLOOD_REQUEST element.
Upgrade an existing basic determination to a life-of-loan determination.
Example 2.14. Upgrade Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Upgrade" FloodCertificationIdentifier="9999999999"> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
All that is needed is the FloodCertificationIdentifier of the order that is to be upgraded.
Edit an existing determination in order to provide additional information or correct existing information.
Example 2.15. Change Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Change" FloodCertificationIdentifier="9999999999"> <MORTGAGE_TERMS LenderCaseIdentifier="MyUpdatedLoanNum123"/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
The FloodCertificationIdentifier of the order to edit must be specified. The fields to be changed must be specified according to the following rules:
If a value is specified in an element or attribute, that will become the new value.
If an element or attribute is empty or missing completely, the original value will not change.
In the previous example, the loan number will be updated to MyUpdatedLoanNum123 and all other values on the original order will remain unchanged.
Cancel an existing determination.
Example 2.16. Cancellation Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Cancellation" FloodCertificationIdentifier="9999999999"> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
All that is needed is the FloodCertificationIdentifier of the order that is to be cancelled.
Reactivate an existing cancelled determination.
Example 2.17. Reissue Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Reissue" FloodCertificationIdentifier="9999999999"> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
All that is needed is the FloodCertificationIdentifier of the order that is to be reissued.
Dispute the results of an existing flood determination.
Example 2.18. Dispute Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST InternalAccountIdentifier="AskForAccount"> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Dispute" FloodCertificationIdentifier="9999999999"> <_DISPUTE _ItemType="Zone" _SupportingDocumentsDescription="Survey" _Description="This is a test."/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
In addition to the FloodCertificationIdentifier of the order to dispute, the information needed for a Dispute request is as follows.
Disputed Item: The item to dispute goes in the _ItemType attribute of the _DISPUTE element. The value must come from the enumerated list specified in the DTD.
Supporting Documents: A comma-separated list containing the types of supporting documentation for the dispute goes in the _SupportingDocumentsDescription of the _DISPUTE element. Common documents types include Locator Map, Survey, Appraisal, Community Letter, FEMA Letter, and Elevation Certificate.
Description: A brief text description explaining the situation and the reason for the dispute goes in the _Description attribute of the _DISPUTE element.
The supporting documents themselves are not submitted via XML. Once the dispute request has been submitted, the supporting documents specified in the request must be faxed to CoreLogic.
The STATUS element is where the response type information is returned, along with any comments or error messages. The STATUS element has 4 attributes:
_Condition: Success or Error
_Code: Code representing a given status
_Name: More user-friendly representation of the status than the code
_Description: Comments or error messages regarding the status
The following tables list the status codes for the various Success and Error responses. The codes are the official indicators of the status state. They are unique and constant. The names associated with each code are human-friendly representations of the codes and are not guaranteed to remain unchanged.
Table 3.1. Success Status Codes
Code | Meaning |
---|---|
S0010 | The flood determination is complete. |
S0011 | The flood determination is currently in research. |
S0012 | The flood determination has been researched, but needs more information. |
S0013 | The request is a duplicate of an existing determination. |
S0014 | The determination has been cancelled. |
Table 3.2. Error Status Codes
Code | Meaning |
---|---|
E0000 | Server is not able to accept and process requests. |
E0002 | An unexpected error has occurred. |
E0020 | A required data item is missing. |
E0030 | An invalid data item has been submitted. |
E0040 | Business logic error such as an attempt to cancel a cancelled determination, provide a PO box as the property address, etc. |
The flood determination is complete.
Example 3.1. Complete Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T14:15:28-05:00"> <RESPONSE_DATA> <FLOOD_RESPONSE MISMOVersionID="2.4"> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="7600 HUNTERS MILL RD" _City="BLACKSBURG" _State="VA" _County="MONTGOMERY" _PostalCode="24060"> <_IDENTIFICATION CountyFIPSCode="121" StateFIPSCode="51"/> </PROPERTY> <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999" SpecialFloodHazardAreaIndicator="N" FloodPartialIndicator="N" _LifeOfLoanIndicator="Y" FloodProductCertifyDate="2006-08-22T14:15:28-05:00"> <_LOAN_INFORMATION RegulatoryAgencyLenderIdentifier="1232456"/> <_COMMUNITY_INFORMATION NFIPCommunityIdentifier="510100" NFIPCommunityName="BLACKSBURG, TOWN OF" NFIPCommunityParticipationStartDate="1980-05-15" NFIPCounty="MONTGOMERY" NFIPStateCode="VA"/> <_BUILDING_INFORMATION NFIPFloodZoneIdentifier="C" NFIPMapIndicator="Y" NFIPMapPanelDate="1980-05-15" NFIPMapIdentifier="510100" NFIPMapPanelIdentifier="0006" NFIPMapPanelSuffixIdentifier="B"/> <_INSURANCE_INFORMATION NFIPCommunityParticipationStatusType="Regular" ProtectedAreaIndicator="N"/> </FLOOD_DETERMINATION> <LENDER _UnparsedName="ABC Lender" _StreetAddress="123 Main Blvd" _City="Austin" _State="TX" _PostalCode="78758-1234"/> </FLOOD_RESPONSE> </RESPONSE_DATA> <STATUS _Condition="Success" _Code="S0010" _Name="Complete" _Description="comments..."/> </RESPONSE> </RESPONSE_GROUP>
The determination could not be completed automatically, so it has been sent to research.
Example 3.2. In Research Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T14:30:33-05:00"> <RESPONSE_DATA> <FLOOD_RESPONSE MISMOVersionID="2.4"> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="76XYZ00 HUNTERS MILL RD" _City="BLACKSBURG" _State="VA" _County="MONTGOMERY" _PostalCode="24060"/> <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999" _LifeOfLoanIndicator="Y"/> </FLOOD_RESPONSE> </RESPONSE_DATA> <STATUS _Condition="Success" _Code="S0011" _Name="In Research" _Description="Order 9999999999 submitted for research at 02:30 PM CDT on 08/22/2006..."/> </RESPONSE> </RESPONSE_GROUP>
The research staff needs additional information, such as a legal description, in order to complete the determination.
Example 3.3. Additional Info Needed Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T14:30:33-05:00"> <RESPONSE_DATA> <FLOOD_RESPONSE MISMOVersionID="2.4"> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="76XYZ00 HUNTERS MILL RD" _City="BLACKSBURG" _State="VA" _County="MONTGOMERY" _PostalCode="24060"/> <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999" _LifeOfLoanIndicator="Y"/> </FLOOD_RESPONSE> </RESPONSE_DATA> <STATUS _Condition="Success" _Code="S0012" _Name="Additional Info Needed" _Description="We have attempted to complete this order with all available resources, however, we need additional information to locate the subject property..."/> </RESPONSE> </RESPONSE_GROUP>
The duplicate-checking algorithm has determined that the request is a duplicate of an existing determination. Account options control the strictness of the duplicate-checking algorithm and how duplicates are handled.
The original order can be retrieved with a status query on the provided flood certification number contained in the FloodCertificationIdentifier attribute of the FLOOD_DETERMINATION element.
Example 3.4. Duplicate Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T14:15:28-05:00"> <RESPONSE_DATA> <FLOOD_RESPONSE MISMOVersionID="2.4"> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="7600 HUNTERS MILL RD" _City="BLACKSBURG" _State="VA" _County="MONTGOMERY" _PostalCode="24060"> </PROPERTY> <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999" _LifeOfLoanIndicator="Y"> <_LOAN_INFORMATION RegulatoryAgencyLenderIdentifier="1232456"/> </FLOOD_DETERMINATION> </FLOOD_RESPONSE> </RESPONSE_DATA> <STATUS _Condition="Success" _Code="S0013" _Name="Duplicate" _Description="Duplicate of order 9999999999"/> </RESPONSE> </RESPONSE_GROUP>
The determination has been cancelled.
Example 3.5. Cancelled Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T14:15:28-05:00"> <RESPONSE_DATA> <FLOOD_RESPONSE MISMOVersionID="2.4"> <BORROWER _FirstName="Joe" _LastName="Tester"/> <MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/> <PROPERTY _StreetAddress="7600 HUNTERS MILL RD" _City="BLACKSBURG" _State="VA" _County="MONTGOMERY" _PostalCode="24060"> </PROPERTY> <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999" _LifeOfLoanIndicator="Y"> </FLOOD_DETERMINATION> </FLOOD_RESPONSE> </RESPONSE_DATA> <STATUS _Condition="Success" _Code="S0014" _Name="Cancelled" _Description="This certification was cancelled on 08/22/2006..."/> </RESPONSE> </RESPONSE_GROUP>
There are a number of different error responses. The error information is represented by the STATUS element.
Example 3.6. Invalid Request Type Error Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T16:06:04-05:00"> <STATUS _Condition="Error" _Code="E0030" _Name="Error" _Description="Invalid action type: Transfer"/> </RESPONSE> </RESPONSE_GROUP>
Example 3.7. Business Logic Error (PO Box) Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T16:08:17-05:00"> <STATUS _Condition="Error" _Code="E0040" _Name="Error" _Description="Post office box is not a valid property address" /> </RESPONSE> </RESPONSE_GROUP>
Example 3.8. Business Logic Error (Invalid Product) Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2006-08-22T16:08:17-05:00"> <STATUS _Condition="Error" _Code="E0040" _Name="Error" _Description="Invalid order type for this account" /> </RESPONSE> </RESPONSE_GROUP>
Other errors just differ in code and description.
A FEMA Standard Flood Hazard Determination Form (FEMA form) is available with completed determinations.
A completed flood determination form can be faxed, emailed, or embedded in the XML response as a Base64-encoded PDF file.
To fax and/or email the FEMA form, specify a PREFERRED_RESPONSE entry for each method in the REQUESTING_PARTY element.
The _Format attribute should be 'PDF' (only format currently supported), the _Method attribute should be 'Fax' for fax and 'SMTP' for email, and the _Destination should contain the fax number or email address to which the completed form should be sent.
Example 4.1. Fax/Email FEMA Form Request
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUESTING_PARTY> <PREFERRED_RESPONSE _Format="PDF" _Method="Fax" _Destination="512-555-1234"/> <PREFERRED_RESPONSE _Format="PDF" _Method="SMTP" _Destination="me@mydomain.com"/> </REQUESTING_PARTY> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4"> <_PRODUCT/> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
The embedded FEMA form is returned in the response as a Base64-encoded PDF file. The Base64 data is contained in the DOCUMENT child element of the EMBEDDED_FILE element. The attributes of the EMBEDDED_FILE element provide information such as the MIME type of the file, the encoding type, and the version of the format that the file is created as. For example, the response below contains a file that is in the Adobe Pdf v1.3 format, with MIME type "application/pdf", that is encoded using Base64. Using this information, the client should be able to process the embedded data to regenerate the PDF file.
Example 4.2. Embedded File FEMA Form Response
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE> <RESPONSE_DATA> <FLOOD_RESPONSE MISMOVersionID="2.4"> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> <EMBEDDED_FILE MIMEType="application/pdf" _Description="Adobe Pdf" _Version="1.3" _Extension="pdf" _EncodingType="Base64" _Name="Certificate_999999999"> <DOCUMENT> JVBERi0xLjM ... more Base64 data ... </DOCUMENT> </EMBEDDED_FILE> <FLOOD_DETERMINATION/> <LENDER/> </FLOOD_RESPONSE> </RESPONSE_DATA> <STATUS/> </RESPONSE> </RESPONSE_GROUP>
The following is a mapping of the FEMA Standard Flood Hazard Determination Form fields to the contents of the MISMO Flood 2.4 Response. It is organized according to the sections, subsections, and fields of the FEMA form.
If a form field maps directly to an XML element or attribute, an XPath fragment that describes the XML location is provided. If the mapping is computed from one or more fields, then the computation is described. A form field that cannot be mapped to the XML response at all is marked 'Not Available'.
Name: //LENDER/@_UnparsedName
Street: //LENDER/@StreetAddress
City: //LENDER/@City
State: //LENDER/@State
PostalCode: //LENDER/@PostalCode
Street: //PROPERTY/@StreetAddress
City: //PROPERTY/@City
County: //PROPERTY/@County
State: //PROPERTY/@State
PostalCode: //PROPERTY/@PostalCode
Map Number:
//_BUILDING_INFORMATION/@NFIPMapIdentifier
Panel:
//_BUILDING_INFORMATION/@NFIPMapPanelIdentifier
Panel Suffix:
//_BUILDING_INFORMATION/@NFIPMapPanelSuffixIdentifier
Date: //_BUILDING_INFORMATION/@NFIPLetterOfMapDate
Case Number: //RESPONSE/KEY[@_Name="FAFDS.LetterOfMapIdentifier"]/@_Value
If there is a LOMA/LOMR date then the YES box on the form will be checked, the date will be filled in, and the case number will be filled in if it is available.
//_INSURANCE_INFORMATION/@NFIPCommunityParticipationStatusType
This box will be checked on the form if the value is
Regular
, Emergency
, or
Probation
. If it is Regular
or
Emergency
, the corresponding secondary box for
that type will also be checked.
//_INSURANCE_INFORMATION/@NFIPCommunityParticipationStatusType
This box will be checked on the form if the value is
Suspended
or
Non-Participating
.
//FLOOD_DETERMINATION/@FloodProductCertifyDate
The date is returned in ISO 8601 time/date format, but is formatted on the form as "MM/DD/YY at HH:MM AM/PM TZ".
We provide a "plain XML over HTTPS" interface to allow a MISMO XML payload to be submitted directly via HTTP POST. The key points are summarized below.
The request must be submitted via HTTP POST.
The "Content-Type" HTTP Header must be set to "text/xml".
The request payload is simply the MISMO XML document.
Login credentials are submitted via the HTTP Basic Authentication mechanism (the "Authorization" HTTP header.) These credentials will be provided by your CoreLogic account representative.
The initial synchronous response will be an acknowledgment as described in Section 1, “Acknowledgment Format”. The actual payload response (Chapter 3, Response Types) will subsequently be delivered asynchronously to the client listener.
The TESTING URL is
https://betaasync.floodcert.com/async/receiver
The PRODUCTION URL is
https://async.floodcert.com/async/receiver
When a client successfully posts an HTTP request to the asynchronous interface, the interface returns a '200 OK' HTTP response. The Content-Type header of the response is "text/xml", and the body contains an acknowledgment that is structured as a minimal MISMO Flood 2.4 document.
The same acknowledgment format is expected in response when we post back to the client.
Example 5.1. MISMO Flood 2.4 Acknowledgment Format
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime=""> <STATUS _Code="" _Name="" _Condition="" _Description="" /> </RESPONSE> </RESPONSE_GROUP>
The fields returned in the acknowledgment are defined as follows:
The response datetime is a timestamp in ISO 8601 format.
The condition is simply a flag indicating 'Success' or 'Error'.
The code is a unique and constant indicator of a specific acknowledgment type. These codes are for use in both CoreLogic and client acknowledgments. Some interfaces may not use all of them, but at a minimum S0015 (Success) and E0040 (General Error) should be implemented.
Table 5.1. Acknowledgment Status Codes
Code | Meaning |
---|---|
S0015 | The request was received successfully. |
E0000 | Server is not able to accept and process requests. |
E0002 | An unexpected error has occurred. |
E0020 | A required data item is missing. |
E0030 | An invalid data item has been submitted. |
E0040 | Other error. |
The name is a human-friendly representation of the code.
The description is a field for comments or error messages.
The first example below shows a successful receipt. The second example shows a failure caused by invalid client data. The third example shows a failure caused by an unexpected processing error that prevented successful receipt of the request.
Example 5.2. Successfully Received
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2005-03-07T13:36:05-06:00"> <STATUS _Condition="Success" _Code="S0015" _Name="Processed" _Description="Request received" /> </RESPONSE> </RESPONSE_GROUP>
Example 5.3. Invalid Request
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2005-03-07T13:36:05-06:00"> <STATUS _Condition="Error" _Code="E0030" _Name="Error" _Description="No content found in request" /> </RESPONSE> </RESPONSE_GROUP>
Example 5.4. Server Error
<RESPONSE_GROUP MISMOVersionID="2.4"> <RESPONSE ResponseDateTime="2005-03-07T13:36:05-06:00"> <STATUS _Condition="Error" _Code="E0002" _Name="Error" _Description="Internal Server Error" /> </RESPONSE> </RESPONSE_GROUP>
Some errors occur at the HTTP server level, before the request ever reaches the processing application. These errors are indicated by HTTP response codes other than the '200 OK' response described above. Since these responses are generated outside of the processing application, they will contain a server error message, not a MISMO Flood 2.4 acknowledgment. The Content-Type Header will not be "text/xml" in this case, since the HTTP server returns its error messages as "text/html".
These errors are as follows:
The incorrect login/password information was submitted in the request.
A method other than HTTP POST was used to sumbit the request. Only HTTP POST is allowed (ie, not HTTP GET).
The Content-Type Header of the request was something other than 'text/xml'.
An unexpected server error occurred.
CoreLogic uses a DigiCert certificate on its SSL-enabled servers. Because DigiCert is one of the major Certificate Authorities (CA), it is already registered by default in many system trust stores. This means that it should not be necessary to manually import the CoreLogic Flood Services certificate into your local trust store in order to connect to us via HTTPS.
For debugging purposes, it is sometimes necessary to see just exactly what is being generated and how it is being sent over the wire. In these cases, a TCP trace tool can be used to intercept the traffic between the client and the server and display the actual HTTP requests/responses that pass through. HTTP headers and XML structures can be examined if something seems to be failing at the client level.
Developers using Apache Axis can use the TCPMonitor utility as described in the Axis documentation, while those using Microsoft tools can use TcpTrace or similar utilities.
There are several different data scenarios to test when an order is completed. A list of addresses to trigger each scenario is available from your CoreLogic technical contact.
In each case, the data returned corresponds to the mapping as described in Section 2, “FEMA Form-to-XML Mapping”. For example, the flood zone will be returned as mapped in Section 2.3.4, “Box 4. Flood Zone”. The following sections point to the unique aspects of each scenario.
See Section 2.5.1, “Is Building in Special Flood Hazard Area?”. Value will be
Y
.
See Section 2.5.1, “Is Building in Special Flood Hazard Area?”. Value will be
N
.
See Section 2.4.1, “Box 1. Federal Flood Insurance Available” and Section 2.4.2, “Box 2. Federal Flood Insurance Not Available”
Special attention should be paid to the 'Non-Participating' case. Since there is no data available for a Non-Participating community, the following values are returned.
//_INSURANCE_INFORMATION/@NFIPCommunityParticipationStatusType
is Non-Participating
.
//_BUILDING_INFORMATION/@NFIPFloodZoneIdentifier
is NONE
.
//_BUILDING_INFORMATION/@NFIPMapIndicator
is
N
.
//_BUILDING_INFORMATION/@NFIPMapPanelIdentifier
is 0001
.
//_BUILDING_INFORMATION/@NFIPMapPanelSuffixIdentifier
is N
.
Some data items in the response are only returned for certain product types. See See Section 1.2, “Product Information” for more information on products.
//PROPERTY/_IDENTIFICATION/@CountyFIPSCode
//PROPERTY/_IDENTIFICATION/@StateFIPSCode
//PROPERTY/_IDENTIFICATION/@CensusTractIdentifier
//PROPERTY/_IDENTIFICATION/@MSAIdentifier
If an order must be manually researched, the initial response will be as described in Section 2, “In Research”. From there, the research department will either manually complete it, or request additional information as described in Section 3, “Additional Info Needed”. When the status of an order changes, it will be posted back to the client listener.
Verify that your listener receives items that initially went to research but have since been completed, or require more information to complete. Your CoreLogic technical contact will coordinate with you to simulate these various order states in our test environment.
There are certain addresses such as P.O. boxes that are rejected up front. They will return an error response (see Example 3.7, “Business Logic Error (PO Box) Response”.)
For orders that relate to a previous completed order (such as a related loan order, FLR) either the flood certification number or the loan number of the original order must be used to tie the new order to the original. Only one or the other is required. If ordering this type of product, test that the new order successfully matches up with the existing order.
Example 9.1. Original Request (Related Loan)
<REQUEST_GROUP MISMOVersionID="2.4"> <REQUEST> <REQUEST_DATA> <FLOOD_REQUEST MISMOVersionID="2.4" _ActionType="Original" FloodCertificationIdentifier="9999999999" OriginalFloodDeterminationLoanIdentifier="origLoanNum"> <_PRODUCT _CategoryDescription="Flood"> <_NAME _Identifier="FLR"/> </_PRODUCT> <BORROWER/> <MORTGAGE_TERMS/> <PROPERTY/> </FLOOD_REQUEST> </REQUEST_DATA> </REQUEST> </REQUEST_GROUP>
There are characters that have special meaning in XML. These are basically characters that are used in the structure of XML itself, like "<", "&", and quotation marks. These special characters need to be translated to codes in order to not be confused with the actual XML infrastructure. The official explanation of this issue is at http://www.w3.org/TR/REC-xml/#syntax. In general, XML toolkits should be used for building/parsing because they automatically handle these issues properly, but if the XML is being built by hand (string concatenation), then the characters must be explicitly translated as follows:
& --> & " --> " ' --> ' < --> < > --> >
For example, you would submit the following XML containing the common special character "&"
<ABC xyz="Jack & Jill"/>as
<ABC xyz="Jack & Jill"/>
If requesting embedded PDFs as described in Section 1.2, “Embedded File”, test that they can be Base64 decoded and viewed, and test that the PDF is returned in responses to StatusQuery requests if expected.