MISMO Flood 2.4 Implementation Guide

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.


I. MISMO Flood 2.4 Structure
1. Document Type Definition and XML Schema
1. MISMO MXCompliance
2. Request Types
1. Original
1.1. Account Information
1.2. Product Information
1.3. Loan Information
1.4. Property Information
1.5. Reference Information
1.6. Contact Information
1.7. Common Fields Combined
2. StatusQuery
3. Upgrade
4. Change
5. Cancellation
6. Reissue
7. Dispute
3. Response Types
1. Complete
2. In Research
3. Additional Info Needed
4. Duplicate
5. Cancelled
6. Pending List
7. Error
4. FEMA Standard Flood Hazard Determination Form
1. Requesting a FEMA Form
1.1. Fax/Email
1.2. Embedded File
2. FEMA Form-to-XML Mapping
2.1. Section I - Loan Information
2.2. Section II.A - NFIP Community Jurisdiction
2.3. Section II.B - NFIP Data Affecting Building/Mobile Home
2.4. Section II.C - Federal Flood Insurance Availability
2.5. Section II.D - Determination
2.6. Section II.E - Comments
2.7. Section II.F - Preparer's Information
II. CoreLogic Connectivity
5. SOAP Web Service
6. Plain XML over HTTPS
7. SSL Certificate
8. Debugging Tools
III. Test Cases
9. Responses
1. Completed Orders
1.1. In Flood Zone
1.2. Not In Flood Zone
1.3. Community Status
1.4. LOMR
1.5. CBRA
1.6. Product Specific
2. Pending Orders
10. Miscellaneous
1. Rejected Addresses
2. Related Orders
3. Special Characters
4. Embedded PDF

Part I. MISMO Flood 2.4 Structure

Chapter 1. Document Type Definition and XML Schema

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.

1. MISMO MXCompliance

This implementation has passed the MISMO MXCompliance Response Export certification process.

Chapter 2. Request Types

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.

1. Original

Request a new flood determination.

Example 2.1. Original Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
      LoginAccountPassword="AskForPassword"/>                   
  <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”.

1.1. Account Information

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 SUBMITTING_PARTY 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.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
      LoginAccountPassword="AskForPassword"/>
  <REQUEST InternalAccountIdentifier="AskForAccount">
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4" 
          _ActionType="Original">
        <_PRODUCT/>
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>

                    

1.2. Product Information

Note

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

DescriptionCode
Basic Flood DeterminationF
Life-of-Loan Flood DeterminationFL
Life-of-Loan with CensusFLC
Life-of-Loan Related LoanFLR

Example 2.3. Product


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY/>
  <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>
                            

1.3. Loan Information

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

1.4. Property Information

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

1.5. Reference Information

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.

1.5.1. Branch

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">
  <SUBMITTING_PARTY/>
  <REQUEST RequestingPartyBranchIdentifier="MyCostCenterId">
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4">
        <_PRODUCT/>                            
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>                            
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>
              
                            

1.5.2. Additional Reference Identifier

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">
  <SUBMITTING_PARTY/>
  <REQUEST>
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4" 
          FEMAAdditionalLenderDescription="MyRefNum">
        <_PRODUCT/>                            
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>                            
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>
                                         
                            

1.5.3. Tracking Identifier

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

                            

1.5.4. Lender Identifier

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">
  <SUBMITTING_PARTY/>
  <REQUEST>
    <REQUEST_DATA>
      <FLOOD_REQUEST RegulatoryAgencyLenderIdentifier="MyLenderId" MISMOVersionID="2.4">
        <_PRODUCT/>                            
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>                            
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>

                            

1.5.5. Borrower Email Address Identifier

For notification order product types (N in product code) placed on accounts configured to email the Borrower Notice, the data can be submitted using a KEY element with the name "FAFDS.BorrowerEmailAddressIdentifier". The data will be returned in responses in a KEY element with the same name. It will not print on the FEMA form.  

Example 2.11. Borrower Email Address Identifier

                                
<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY/>
  <REQUEST>
    <KEY _Name="FAFDS.BorrowerEmailAddressIdentifier" _Value="MyBorrowerEmailAddressId@gmail.com"/>
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4">
        <_PRODUCT/>
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>

                            

1.6. Contact Information

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.12. 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>                        
  <SUBMITTING_PARTY/>
  <REQUEST>
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4">
        <_PRODUCT/>                            
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>                            
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>

                

1.7. Common Fields Combined

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.13. 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>
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin"
      LoginAccountPassword="AskForPassword"/>
  <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>

                

2. StatusQuery

Look up an existing determination, usually to check if an in-research item has been completed.

Example 2.14. StatusQuery Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
      LoginAccountPassword="AskForPassword"/>
  <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.

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.15. StatusQuery Request (Pending Items)


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
      LoginAccountPassword="AskForPassword"/>
  <REQUEST InternalAccountIdentifier="AskForAccount">
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4" 
          _ActionType="StatusQuery"/>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>

                        

3. Upgrade

Upgrade an existing basic determination to a life-of-loan determination.

Example 2.16. Upgrade Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
      LoginAccountPassword="AskForPassword"/>
  <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.

4. Change

Edit an existing determination in order to provide additional information or correct existing information.

Example 2.17. Change Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
      LoginAccountPassword="AskForPassword"/>
  <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.

5. Cancellation

Cancel an existing determination.

Example 2.18. Cancellation Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
                    LoginAccountPassword="AskForPassword"/>
  <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.

6. Reissue

Reactivate an existing cancelled determination.

Example 2.19. Reissue Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
                    LoginAccountPassword="AskForPassword"/>
  <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.

7. Dispute

Dispute the results of an existing flood determination.

Example 2.20. Dispute Request


<REQUEST_GROUP MISMOVersionID="2.4">
  <SUBMITTING_PARTY LoginAccountIdentifier="AskForLogin" 
                    LoginAccountPassword="AskForPassword"/>
  <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.

Note

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.

Chapter 3. Response Types

The STATUS element is where the response type information is returned, along with any comments or error messages. The STATUS element has 4 attributes:

  1. _Condition: Success or Error

  2. _Code: Code representing a given status

  3. _Name: More user-friendly representation of the status than the code

  4. _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

CodeMeaning
S0010The flood determination is complete.
S0011The flood determination is currently in research.
S0012The flood determination has been researched, but needs more information.
S0013The request is a duplicate of an existing determination.
S0014The determination has been cancelled.
S0015The pending list query was processed successfully.

Table 3.2. Error Status Codes

CodeMeaning
E0000Server is not able to accept and process requests.
E0002An unexpected error has occurred.
E0010The login id and/or password are not present.
E0011The login id and/or password are not valid.
E0020A required data item is missing.
E0030An invalid data item has been submitted.
E0040Business logic error such as an attempt to cancel a cancelled determination, provide a PO box as the property address, etc.

1. Complete

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>

                        

2. In Research

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>

                    

3. Additional Info Needed

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>

                    

4. Duplicate

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>

                    

5. Cancelled

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>

                    

6. Pending List

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 MISMOVersionID="2.4">
  <RESPONSE ResponseDateTime="2006-08-22T15:04:46-05:00">
    <RESPONSE_DATA>
      <FLOOD_RESPONSE MISMOVersionID="2.4">
        <MORTGAGE_TERMS LenderCaseIdentifier="MyLoanNum321"/>
        <FLOOD_DETERMINATION FloodCertificationIdentifier="8888888888"/>
      </FLOOD_RESPONSE>
    </RESPONSE_DATA>
    <RESPONSE_DATA>
      <FLOOD_RESPONSE MISMOVersionID="2.4">
        <MORTGAGE_TERMS LenderCaseIdentifier="MyLoanNum123"/>
        <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999"/>
      </FLOOD_RESPONSE>
    </RESPONSE_DATA>
    <STATUS _Condition="Success" 
        _Code="S0015" 
        _Name="Processed"
        _Description="Pending list request processed"/>
  </RESPONSE>
</RESPONSE_GROUP>

                    

Example 3.7. Pending List Response (One Item)


<RESPONSE_GROUP MISMOVersionID="2.4">
  <RESPONSE ResponseDateTime="2006-08-22T15:04:46-05:00">
    <RESPONSE_DATA>
      <FLOOD_RESPONSE MISMOVersionID="2.4">
        <MORTGAGE_TERMS LenderCaseIdentifier="MyLoanNum123"/>
        <FLOOD_DETERMINATION FloodCertificationIdentifier="9999999999"/>
      </FLOOD_RESPONSE>
    </RESPONSE_DATA>
    <STATUS _Condition="Success" 
        _Code="S0015" 
        _Name="Processed"
        _Description="Pending list request processed"/>
  </RESPONSE>
</RESPONSE_GROUP>

                    

Example 3.8. Pending List Response (Zero Items)


<RESPONSE_GROUP MISMOVersionID="2.4">
  <RESPONSE ResponseDateTime="2006-08-22T15:04:46-05:00">
    <STATUS _Condition="Success" 
        _Code="S0015" 
        _Name="Processed"
        _Description="Pending list request processed"/>
  </RESPONSE>
</RESPONSE_GROUP>

                    

7. Error

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.4">
  <RESPONSE ResponseDateTime="2006-08-22T16:03:44-05:00">
    <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.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.11. 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.12. 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.

Chapter 4. FEMA Standard Flood Hazard Determination Form

A FEMA Standard Flood Hazard Determination Form (FEMA form) is available with completed determinations.

1. Requesting a FEMA Form

A completed flood determination form can be faxed, emailed, or embedded in the XML response as a Base64-encoded PDF file.

1.1. Fax/Email

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>                        
  <SUBMITTING_PARTY/>
  <REQUEST>
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4">
        <_PRODUCT/>                            
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>                            
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>
                        
            

1.2. Embedded File

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.4">
  <REQUESTING_PARTY>
    <PREFERRED_RESPONSE _Format="PDF" 
        _Method="File" 
        _UseEmbeddedFileIndicator="Y"/>
  </REQUESTING_PARTY>                        
  <SUBMITTING_PARTY/>
  <REQUEST>
    <REQUEST_DATA>
      <FLOOD_REQUEST MISMOVersionID="2.4">
        <_PRODUCT/>                            
        <BORROWER/>
        <MORTGAGE_TERMS/>
        <PROPERTY/>                            
      </FLOOD_REQUEST>
    </REQUEST_DATA>
  </REQUEST>
</REQUEST_GROUP>

                

Note

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

                    

2. FEMA Form-to-XML Mapping

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

2.1. Section I - Loan Information

2.1.1. Box 1. Lender Name and Address

  • Name: //LENDER/@_UnparsedName

  • Street: //LENDER/@StreetAddress

  • City: //LENDER/@City

  • State: //LENDER/@State

  • PostalCode: //LENDER/@PostalCode

2.1.2. Box 2. Collateral Property Address

  • Street: //PROPERTY/@StreetAddress

  • City: //PROPERTY/@City

  • County: //PROPERTY/@County

  • State: //PROPERTY/@State

  • PostalCode: //PROPERTY/@PostalCode

2.1.3. Box 3. Lender Id No

//_LOAN_INFORMATION/@RegulatoryAgencyLenderIdentifier

2.1.4. Box 4. Loan Identifier

//MORTGAGE_TERMS/@LenderCaseIdentifier

2.1.5. Box 5. Amount of flood insurance required

Not Available

2.2. Section II.A - NFIP Community Jurisdiction

2.2.1. Box 1. NFIP Community Name

//_COMMUNITY_INFORMATION/@NFIPCommunityName

2.2.2. Box 2. County(ies)

//_COMMUNITY_INFORMATION/@NFIPCounty

2.2.3. Box 3. State

//_COMMUNITY_INFORMATION/@NFIPStateCode

2.2.4. Box 4. NFIP Community Number

//_COMMUNITY_INFORMATION/@NFIPCommunityIdentifier

2.3. Section II.B - NFIP Data Affecting Building/Mobile Home

2.3.1. Box 1. NFIP Map Number or Community Panel

  • Map Number: //_BUILDING_INFORMATION/@NFIPMapIdentifier

  • Panel: //_BUILDING_INFORMATION/@NFIPMapPanelIdentifier

  • Panel Suffix: //_BUILDING_INFORMATION/@NFIPMapPanelSuffixIdentifier

2.3.2. Box 2. NFIP Map Panel Effective/Revised Date

//_BUILDING_INFORMATION/@NFIPMapPanelDate

2.3.3. Box 3. LOMA/LOMR

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

2.3.4. Box 4. Flood Zone

//_BUILDING_INFORMATION/@NFIPFloodZoneIdentifier

2.3.5. Box 5. No NFIP Map

//_BUILDING_INFORMATION/@NFIPMapIndicator

The field on the form is marked with an 'X' if the value is N. It is left blank if the value is Y.

2.4. Section II.C - Federal Flood Insurance Availability

2.4.1. Box 1. Federal Flood Insurance 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.

2.4.2. Box 2. Federal Flood Insurance Not Available

//_INSURANCE_INFORMATION/@NFIPCommunityParticipationStatusType

This box will be checked on the form if the value is Suspended or Non-Participating.

2.4.3. Box 3. CBRA/OPA Status and Date

  • Protected Area Indicator: //_INSURANCE_INFORMATION/@ProtectedAreaIndicator

  • Designation Date: //_INSURANCE_INFORMATION/@ProtectedAreaDesignationDate

If there is a CBRA/OPA date, the box on the form will be checked and the date will be filled in.

2.5. Section II.D - Determination

2.5.1. Is Building in Special Flood Hazard Area?

//FLOOD_DETERMINATION/@SpecialFloodHazardAreaIndicator

If the value is Y, then the YES box on the form will be checked. Otherwise, the NO box will be checked.

2.6. Section II.E - Comments

//STATUS/@_Description

2.7. Section II.F - Preparer's Information

2.7.1. Name, Address, Telephone Number

Not Available

2.7.2. Date of Determination

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

2.7.3. FloodCert Number

//FLOOD_DETERMINATION/@FloodCertificationIdentifier

This is the number used by CoreLogic to uniquely identify each order.

Part II. CoreLogic Connectivity

Chapter 5. SOAP Web Service

CoreLogic exposes a SOAP Web Service with a very simple interface. It consists of one operation called "makeRequest" that takes a single string parameter and returns a single string result. From a Java-centric point of view, it corresponds to the following method signature:

public String makeRequest(String requestXmlString);
                    

The input parameter is a string that contains a MISMO Flood 2.4 representation of the information required by CoreLogic to make a flood determination, as described in Chapter 2, Request Types. The result is a string that contains a MISMO Flood 2.4 response, as described in Chapter 3, Response Types

Note

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 should be used to build and validate the request to avoid common structural and encoding problems, serializing to a string just 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 JAX-WS SOAP Toolkit, but the process for Microsoft .NET and other toolkits is similar.

  1. Download a copy of the WSDL file to your local environment. (Do not link to the live URL on the CoreLogic server.)

  2. Edit the local WSDL file to configure the appropriate url.

    • The BETA URL is https://betasoap.floodcert.com/wssoap/v2/floodcert?schemaId=mismo24

    • The PRODUCTION URL is https://soap.floodcert.com/wssoap/v2/floodcert?schemaId=mismo24

  3. Use a SOAP toolkit to generate client bindings from the local WSDL file.

    > wsimport FloodZoneDeterminationService.wsdl 

  4. Use the generated bindings to develop a client application.

    
    import v2.service.determination.floodzone.*; // jax-ws generated
    
    /**
     * Simple example of using WSDL-generated classes in a client app.
     */
    public class Client
    {
        public static final void main(String[] args)
        {
            FloodZoneDeterminationService service = new FloodZoneDeterminationService();
    
            FloodZoneDeterminationInterface proxy = service.getFloodZoneDeterminationEndpoint();
    
            // 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 request = "<REQUEST_GROUP MISMOVersionID='2.4'/>";
    
            String response = proxy.makeRequest(request);
    
            System.out.println(response);
        }
    }
    
                            

For more details on WSDL, see the W3 Schools WSDL Overview and W3C Note sites.

Chapter 6. Plain XML over HTTPS

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/wspost/v2/floodcert?schemaId=mismo24

  • The PRODUCTION URL is https://soap.floodcert.com/wspost/v2/floodcert?schemaId=mismo24

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:

405 Method Not Allowed

A method other than HTTP POST was used to sumbit the request. Only HTTP POST is allowed (ie, not HTTP GET).

415 Unsupported Media Type

The Content-Type Header of the request was something other than 'text/xml'.

500 Internal Server Error

An unexpected server error occurred.

Chapter 7. SSL Certificate

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.

Chapter 8. Debugging Tools

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.

Part III. Test Cases

Chapter 9. Responses

1. Completed Orders

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.

1.2. Not In Flood Zone

See Section 2.5.1, “Is Building in Special Flood Hazard Area?”. Value will be N.

1.3. Community Status

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.

1.6. Product Specific

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.

1.6.1. Census

  • //PROPERTY/_IDENTIFICATION/@CountyFIPSCode

  • //PROPERTY/_IDENTIFICATION/@StateFIPSCode

  • //PROPERTY/_IDENTIFICATION/@CensusTractIdentifier

  • //PROPERTY/_IDENTIFICATION/@MSAIdentifier

1.6.2. Proximity/Elevation

  • //_BUILDING_INFORMATION/@BaseFloodElevationFeetCount

  • //_BUILDING_INFORMATION/@PropertyElevationFeetCount

  • //_BUILDING_INFORMATION/@SpecialFloodHazardAreaDistanceFeetCount

2. Pending Orders

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.

Chapter 10. Miscellaneous

1. Rejected Addresses

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

2. Related Orders

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.4">
  <SUBMITTING_PARTY/>
  <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>
                                            
                        

3. Special Characters

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:

& --> &amp;                   
" --> &quot;
' --> &apos;
< --> &lt;
> --> &gt;

For example, you would submit the following XML containing the common special character "&"

<ABC xyz="Jack & Jill"/>
as
<ABC xyz="Jack &amp; Jill"/>

4. Embedded PDF

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.