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.1 specification.
Part I, “MISMO Flood 2.1 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.
Part III, “Test Cases” provides an overview of common things to test.
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.1 Document Type Definition (DTD). A DTD is a set of rules used to define the valid structure of an XML document.
The Flood 2.1 DTDs are broken up by request and response. Each has an "enveloping" part and a "data" part. The data part contains the flood request or response data, while the enveloping part provides information about the parties involved and how they interface (login info, preferred response types, etc.) The enveloping DTDs include the respective data DTDs in their definitions, so for validation purposes, it is only necessary to refer to the enveloping DTDs.
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.
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.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1" _ActionType="Original">
<_PRODUCT _CategoryDescription="Flood">
<_NAME _Identifier="FL"/>
</_PRODUCT>
<BORROWER _FirstName="Joe" _LastName="Tester">
<_RESIDENCE/>
</BORROWER>
<MORTGAGE_TERMS LenderCaseIdentifier="LoanNum123"/>
<PROPERTY _StreetAddress="7600 Hunters Mill Rd"
_StreetAddress2=""
_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 go in the corresponding LoginAccountIdentifier and LoginAccountPassword attributes of the REQUEST element. 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.
Account information is required for all request types.
Example 2.2. Login Credentials
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_ActionType="Original">
<_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.1.1">
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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.1.1">
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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.1.1">
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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.1.1">
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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 cost center to which the request will be billed can be submitted using a KEY element with the name "FAFDS.Branch". It will print on the FEMA form in Section I, Box 1.
Example 2.7. Branch
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST>
<REQUEST_DATA>
<KEY _Name="FAFDS.Branch" _Value="MyCostCenterId"/>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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. It can be submitted using a KEY element with the name "FAFDS.AdditionalReferenceIdentifier". 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.1.1">
<REQUEST>
<REQUEST_DATA>
<KEY _Name="FAFDS.AdditionalReferenceIdentifier" _Value="MyRefNum"/>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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.1.1">
<REQUEST>
<REQUEST_DATA>
<KEY _Name="FAFDS.TrackingIdentifier" _Value="MyTrackingId"/>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_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.1.1">
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST RegulatoryAgencyLenderIdentifier="MyLenderId" MISMOVersionID="2.1">
<_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.1.1">
<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.1">
<_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.1.1">
<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 LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<KEY _Name="FAFDS.TrackingIdentifier" _Value="MyTrackingId"/>
<KEY _Name="FAFDS.AdditionalReferenceIdentifier" _Value="MyRefNum"/>
<FLOOD_REQUEST MISMOVersionID="2.1"
_ActionType="Original"
RegulatoryAgencyLenderIdentifier="MyLenderId">
<_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.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_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.
To retrieve a list of researched items that require additional information or have been completed, simply submit a status query without specifying any FloodCertificationIdentifier. A list of pending items will be returned as described in Section 6, “Pending List”. Each item in the returned list can then be retrieved with an individual status query using the FloodCertificationIdentifier as shown above.
Example 2.14. StatusQuery Request (Pending Items)
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_ActionType="StatusQuery"/>
</REQUEST_DATA>
</REQUEST>
</REQUEST_GROUP>
Upgrade an existing basic determination to a life-of-loan determination.
Example 2.15. Upgrade Request
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_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.16. Change Request
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_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.17. Cancellation Request
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_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.18. Reissue Request
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_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.19. Dispute Request
<REQUEST_GROUP>
<REQUEST LoginAccountIdentifier="AskForLogin"
LoginAccountPassword="AskForPassword"
InternalAccountIdentifier="AskForAccount"
RequestDateTime="2003-01-20T23:10:56">
<REQUEST_DATA>
<KEY _Name="FAFDS.Dispute.DisputedItems" _Value="ZONE"/>
<KEY _Name="FAFDS.Dispute.SupportingDocuments" _Value="ELEVATION_CERTIFICATE, SURVEY"/>
<KEY _Name="FAFDS.Dispute.Description" _Value="This is a test."/>
<FLOOD_REQUEST MISMOVersionID="2.1"
_ActionType="Dispute"
_RushIndicator="N"
FloodCertificationIdentifier="0987654321"/>
</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 a KEY element with the name "FAFDS.Dispute.DisputedItems". The valid values are shown in the following table. If the item that is being disputed is not one of the following, just include it in the list anyway and it will be marked as "OTHER".
Table 2.2. Disputed Items
| Value | Description |
|---|---|
| ZONE | flood zone |
| COMMUNITY | community number |
| PANEL | map panel |
| MAP_DATE | map date |
| CBRA_STATUS | Coastal Barrier Resource Area status |
Supporting Documents: A comma-separated list containing the types of supporting documentation for the dispute goes in a KEY element with the name "FAFDS.Dispute.SupportingDocuments". The valid values are shown in the following table. Again, if the item to be submitted is not one of the following, include it in the list anyway and it will be marked as "OTHER".
Table 2.3. Supporting documentation
| Value | Description |
|---|---|
| LOCATOR_MAP | |
| SURVEY | |
| APPRAISAL | |
| COMMUNITY_LETTER | |
| FEMA_LETTER | |
| ELEVATION_CERTIFICATE |
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.
Description: A brief text description explaining the situation and the reason for the dispute goes in a KEY element with the name "FAFDS.Dispute.Description".
Rush Indicator: This indicates if the dispute request is to be expedited. The "Y" or "N" value goes in the _RushIndicator attribute of the FLOOD_REQUEST element.
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. |
| S0015 | The pending list query was processed successfully. |
Table 3.2. Error Status Codes
| Code | Meaning |
|---|---|
| E0000 | Server is not able to accept and process requests. |
| E0002 | An unexpected error has occurred. |
| E0010 | The login id and/or password are not present. |
| E0011 | The login id and/or password are not valid. |
| 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.1">
<RESPONSE ResponseDateTime="2006-08-22T14:15:28-0500">
<RESPONSE_DATA>
<FLOOD_RESPONSE MISMOVersionID="2.1">
<BORROWER _FirstName="Joe" _LastName="Tester"/>
<LENDER_extension _City="Austin"
_PostalCode="78758"
_State="TX"
_StreetAddress="123 Lender Blvd"
_UnparsedName="First Lender, Inc"/>
<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-0500">
<_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>
</FLOOD_RESPONSE>
<STATUS _Condition="Success"
_Code="S0010"
_Name="Complete"
_Description="comments..."/>
</RESPONSE_DATA>
</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.1">
<RESPONSE ResponseDateTime="2006-08-22T14:30:33-0500">
<RESPONSE_DATA>
<FLOOD_RESPONSE MISMOVersionID="2.1">
<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>
<STATUS _Condition="Success"
_Code="S0011"
_Name="In Research"
_Description="Order 9999999999 submitted for research
at 02:30 PM CDT on 08/22/2006..."/>
</RESPONSE_DATA>
</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.1">
<RESPONSE ResponseDateTime="2006-08-22T14:30:33-0500">
<RESPONSE_DATA>
<FLOOD_RESPONSE MISMOVersionID="2.1">
<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>
<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_DATA>
</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.1">
<RESPONSE ResponseDateTime="2006-08-22T14:15:28-0500">
<RESPONSE_DATA>
<FLOOD_RESPONSE MISMOVersionID="2.1">
<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>
<STATUS _Condition="Success"
_Code="S0013"
_Name="Duplicate"
_Description="S0010:Complete"/>
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
The determination has been cancelled.
Example 3.5. Cancelled Response
<RESPONSE_GROUP MISMOVersionID="2.1">
<RESPONSE ResponseDateTime="2006-08-22T14:15:28-0500">
<RESPONSE_DATA>
<FLOOD_RESPONSE MISMOVersionID="2.1">
<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>
<STATUS _Condition="Success"
_Code="S0014"
_Name="Cancelled"
_Description="This certification was cancelled on 08/22/2006..."/>
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
List of all researched items that require additional information or have been completed but not yet retrieved. Each item in the list can then be retrieved with an individual status query as described in Section 2, “StatusQuery”.
Example 3.6. Pending List Response (Multiple Items)
<RESPONSE_GROUP>
<RESPONSE ResponseDateTime="2003-02-24T10:47:01-0500">
<RESPONSE_DATA>
<EXTENSION>
<EXTENSION_SECTION>
<EXTENSION_SECTION_DATA>
<PENDING_LIST>
<PendingItem FloodCertificationIdentifier="1111111111" LenderCaseIdentifier="1234567" StatusCode="S0012"/>
<PendingItem FloodCertificationIdentifier="2222222222" LenderCaseIdentifier="2342341" StatusCode="S0010"/>
</PENDING_LIST>
</EXTENSION_SECTION_DATA>
</EXTENSION_SECTION>
</EXTENSION>
<STATUS _Code="S0015" _Condition="Success" _Description="Pending list request processed" _Name="Processed"/>
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
Example 3.7. Pending List Response (One Item)
<RESPONSE_GROUP>
<RESPONSE ResponseDateTime="2003-02-24T10:47:01-0500">
<RESPONSE_DATA>
<EXTENSION>
<EXTENSION_SECTION>
<EXTENSION_SECTION_DATA>
<PENDING_LIST>
<PendingItem FloodCertificationIdentifier="1111111111" LenderCaseIdentifier="1234567" StatusCode="S0012"/>
</PENDING_LIST>
</EXTENSION_SECTION_DATA>
</EXTENSION_SECTION>
</EXTENSION>
<STATUS _Code="S0015" _Condition="Success" _Description="Pending list request processed" _Name="Processed"/>
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
Example 3.8. Pending List Response (Zero Items)
<RESPONSE_GROUP>
<RESPONSE ResponseDateTime="2003-02-24T10:47:01-0500">
<RESPONSE_DATA>
<EXTENSION>
<EXTENSION_SECTION>
<EXTENSION_SECTION_DATA>
<PENDING_LIST/>
</EXTENSION_SECTION_DATA>
</EXTENSION_SECTION>
</EXTENSION>
<STATUS _Code="S0015" _Condition="Success" _Description="Pending list request processed" _Name="Processed"/>
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
There are a number of different error responses. The error information is represented by the STATUS element.
Example 3.9. Login Error Response
<RESPONSE_GROUP MISMOVersionID="2.1">
<RESPONSE ResponseDateTime="2006-08-22T16:03:44-0500">
<STATUS _Condition="Error"
_Code="E0011"
_Name="Error"
_Description="Invalid User ID or Password"/>
</RESPONSE>
</RESPONSE_GROUP>
Example 3.10. Invalid Request Type Error Response
<RESPONSE_GROUP MISMOVersionID="2.1">
<RESPONSE ResponseDateTime="2006-08-22T16:06:04-0500">
<RESPONSE_DATA>
<STATUS _Condition="Error"
_Code="E0030"
_Name="Error"
_Description="Invalid action type: Transfer"/>
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
Example 3.11. Business Logic Error (PO Box) Response
<RESPONSE_GROUP MISMOVersionID="2.1">
<RESPONSE ResponseDateTime="2006-08-22T16:08:17-0500">
<RESPONSE_DATA>
<STATUS _Condition="Error"
_Code="E0040"
_Name="Error"
_Description="Post office box is not a valid property address" />
</RESPONSE_DATA>
</RESPONSE>
</RESPONSE_GROUP>
Example 3.12. Business Logic Error (Invalid Product) Response
<RESPONSE_GROUP MISMOVersionID="2.1">
<RESPONSE ResponseDateTime="2006-08-22T16:08:17-0500">
<RESPONSE_DATA>
<STATUS _Condition="Error"
_Code="E0040"
_Name="Error"
_Description="Invalid order type for this account" />
</RESPONSE_DATA>
</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.1.1">
<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.1">
<_PRODUCT/>
<BORROWER/>
<MORTGAGE_TERMS/>
<PROPERTY/>
</FLOOD_REQUEST>
</REQUEST_DATA>
</REQUEST>
</REQUEST_GROUP>
To embed the FEMA form in the XML response, specify a PREFERRED_RESPONSE entry in the REQUESTING_PARTY element.
The _Format attribute should be 'PDF' (only format currently supported), the _Method attribute should be 'File', and the _UseEmbeddedFileIndicator should be 'Y'.
If there is no such PREFERRED_RESPONSE entry, or if the _UseEmbeddedFileIndicator is 'N' or not present, then the embedded file will not be returned in the response.
Example 4.2. Embedded File FEMA Form Request
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUESTING_PARTY>
<PREFERRED_RESPONSE _Format="PDF"
_Method="File"
_UseEmbeddedFileIndicator="Y"/>
</REQUESTING_PARTY>
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1">
<_PRODUCT/>
<BORROWER/>
<MORTGAGE_TERMS/>
<PROPERTY/>
</FLOOD_REQUEST>
</REQUEST_DATA>
</REQUEST>
</REQUEST_GROUP>
An embedded PDF will only be returned if a PREFERRED_RESPONSE indicates it in the request, regardless of the type of request (Original, StatusQuery, Change, etc.) The example above is exactly the same for any request type where a PDF should be returned in the response.
In particular, this means that StatusQuery requests must include a PREFERRED_RESPONSE in order to receive a PDF embedded in the response.
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.3. Embedded File FEMA Form Response
<RESPONSE_GROUP MISMOVersionID="2.1">
<RESPONSE>
<RESPONSE_DATA>
<FLOOD_RESPONSE MISMOVersionID="2.1">
<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/>
</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.1 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_extension/@_UnparsedName
Street: //LENDER_extension/@StreetAddress
City: //LENDER_extension/@City
State: //LENDER_extension/@State
PostalCode: //LENDER_extension/@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
//_BUILDING_INFORMATION/@NFIPLetterOfMapDate
If there is a LOMA/LOMR date, the box on the form will be checked and the date will be filled in.
//_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".
CoreLogic exposes a SOAP Web Service with a very simple interface. It consists of a single operation called "request" that takes 3 string parameters and returns a single string result. From a Java-centric point of view, it corresponds to the following method signature:
public String request(String requestXmlString,
String requestVersion,
String responseVersion);
The first parameter is the actual flood request. This is an XML representation of the information required by CoreLogic to make a flood determination, as described in Part I, “MISMO Flood 2.1 Structure”.
The second parameter is a key that identifies to which version of the
DTD the XML in the requestXmlString
parameter corresponds. This allows us to adopt new versions of the
DTDs as they are published, while continuing to support existing
clients using older versions. For Flood 2.1:
-//First American Flood Data Services//DTD Flood Request v2.1//EN
The third parameter identifies the version of the DTD to which the XML response corresponds. Again, this allows the support of both old and new versions of the MISMO DTDs. For Flood 2.1:
-//First American Flood Data Services//DTD Flood Response v2.1//EN
The result is a string that contains an XML response conforming to the
DTD version specified in the responseVersion parameter.
Though the web service receives and returns XML in string form, that does not imply that the request must be initially built up as a string. XML toolkits, available on practically all development platforms, should be used when building the request to avoid common structural and encoding problems. Then just serialize to a string before making the web service call.
We provide a Web Services Description Language (WSDL) file to help simplify the building of a SOAP client for the CoreLogic web service.
At the highest level, a WSDL document is an XML description of a web service that includes the location of the service and what operations are supported by that service. Many SOAP toolkits can use a WDSL description to automatically generate client code that greatly simplifies interaction with the described service.
The general process for generating a client from a WSDL file involves the following steps. Examples are shown using the Java-based Axis SOAP Toolkit, but the process for Microsoft .NET and other toolkits is similar.
Download a copy of the WSDL file to your local environment. (Do not link to the live URL on the CoreLogic server.)
Use a SOAP toolkit to generate client bindings from the WSDL file.
> java org.apache.axis.wsdl.WSDL2Java file:Flood_wsdl_v1_0_2.wsdl
Use the generated bindings to develop a client application.
// Axis classes
import org.apache.axis.*;
// Axis-generated classes
import com.floodcert.soap.wsdl.Flood_wsdl_v1_0_2_wsdl.*;
/**
* Simple example of using WSDL-generated classes in a client app.
* It is not meant in any way to suggest how to implement
* production code or error handling.
*/
public class FloodClient
{
public static void main(String[] args) throws Exception
{
// Request Version
String reqVer = "-//First American Flood Data Services//DTD Flood Request v2.1//EN";
// Response Version
String respVer = "-//First American Flood Data Services//DTD Flood Response v2.1//EN";
// Request XML String
// Request would typically be constructed using xml api, then
// serialized to string before service call. Just using
// minimal valid request string here for demo purposes...
String reqXmlStr = "<REQUEST_GROUP MISMOVersionID='2.1'/>";
try {
// Get service proxy using toolkit-generated classes
Flood service = new FloodServiceLocator().getFlood();
// Make call with appropriate parameters
String respXmlStr = service.request(reqXmlStr, reqVer, respVer);
// Process results
System.out.println("respXmlStr = " + respXmlStr);
System.out.println();
// Response string would be typically parsed back to DOM or other
// object model for for further processing...
}
catch (AxisFault e) { // Handle Fault
System.out.println("SOAP Fault Occurred");
System.out.println(" faultActor: " + e.getFaultActor());
System.out.println(" faultCode: " + e.getFaultCode());
System.out.println(" faultString: " + e.getFaultString());
}
}
}
For more details on WSDL, see the W3 Schools WSDL Overview and W3C Note sites.
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.
Authentication information is submitted in the request payload as described in Section 1.1, “Account Information”. These credentials will be provided by your CoreLogic account representative.
The TESTING URL is
https://betasoap.floodcert.com/soap/servlet/mismo21
The PRODUCTION URL is
https://soap.floodcert.com/soap/servlet/mismo21
When an HTTP POST is successfully received, the HTTP response code is '200 OK' and the response payload contains a MISMO document formatted as described in Chapter 3, Response Types, including the error responses.
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 an HTTP server error message, not a MISMO XML document.
These errors are as follows:
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.
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”. Once it has been completed or if more information is required, it will show up in the pending list response on your next pending list query (see Section 2, “StatusQuery”.)
Verify that your polling process can retrieve 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.11, “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 10.1. Original Request (Related Loan)
<REQUEST_GROUP MISMOVersionID="2.1.1">
<REQUEST>
<REQUEST_DATA>
<FLOOD_REQUEST MISMOVersionID="2.1"
_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.