Florida Surplus Lines Service Office - www.fslso.com

In addition to adhering to the current XML Schema for surplus lines agent/agency or IPC filings, there are certain business rules that must be followed for your submission to be properly processed.

Although the business rules addressed here are partially captured in the logic of the XML Schema, several are not, due to the limitations of XML Schemas. For this reason, we recommend validating your files against the schema prior to submitting (see instructions to do so here).

Some items will cause your transactions to be questioned (noted as TIQ), and some will cause the entire file to be rejected (noted as REJ).

Agent Submissions

General

  • Your file must adhere to the provided XML Schema(s). Failure to do so will cause a file to be rejected. It is recommended that you validate your file against the current schema before submission to prevent this. Instructions available here. (REJ)
  • It is highly recommended that you utilize UTF-8 encoding for your files. A Byte Order Mark (BOM) is not allowed at the beginning of your file. (REJ)

Brokerage/Agency Section

  • The license number of the Brokerage must be registered with the FSLSO as an active Brokerage. (REJ)
  • The batch filing credentials used to submit the file must be associated with the Brokerage. (REJ)

Broker/Agent

  • The license numbers and names of all Brokers must be registered with the FSLSO as active Brokers. (REJ)
  • Transactions as reported for a specific broker/agent must bear effective dates during periods that said broker/agent is listed with an active license/appointment status.

Policy Node(s)

  • The value of the County element must match one of the counties in the schema's CountyType enumeration list. This list is also available here. (REJ)
  • In cases of Multi-state batch files, the HomeState field must always be 'FL'. (REJ)

Transaction Node(s)

  • Valid Transaction Types (REJ)
    • 1 - New Business
    • 2 - Additional Premium
    • 3 - Returned Premium
    • 4 - Cancellation
    • 5 - Renewal
    • 6 - Reinstatement
    • 11 - Backout of New Business
    • 12 - Backout of Additional Premium
    • 13 - Backout of Returned Premium
    • 14 - Backout of Cancellation
    • 15 - Backout of Renewal
    • 16 - Backout of Reinstatement
  • For Transaction Type 1, 2, 5, 6, 13, and 14, Net Premium and Policy Fees values must be positive. For Transaction Type 3, 11, 12, 15, and 16, Net Premium and Policy Fees values must be negative. (REJ)
  • For Transaction Type 4 (Cancellation), Net Premium and Policy Fees values must be negative or zero, and the policy's expiration date field must match the Cancellation's effective date. (REJ)
  • Backout transactions are used ONLY to negate transactions that have already been submitted. For a backout transaction to be considered valid, it must be submitted with the EXACT policy and transaction information that the transaction you are trying to back out contains. (REJ)
  • A reinstatement transaction (type 6) can be submitted for a policy only when the last transaction (by effective date) was an active cancellation with exact same coverage code and Insurer. (REJ)
  • The effective date of a reinstatement transaction (type 6) must be greater than the previous cancellation effective date. (REJ)
  • If a policy is reinstated with an effective date equal to a previously submitted cancellation, you must use a transaction type 14 (backout of cancellation). (REJ)
  • No transactions for a specific policy may be submitted with an effective date between cancellation and a reinstatement. (REJ)
  • A reinstatement transaction cannot be backed out if there are any subsequent transactions (by effective date). (REJ)
  • If a reinstatement transaction is backed out, then the policy expiration date must equal the previous cancellations' expiration date. (REJ)
  • Coverage Codes must be from the allowed coverage codes list. (REJ)
  • If the LateExempt element is set to 'Y', the IssueDate element is required. (REJ)
  • If the LateExempt element is set to 'Y', the LateReason field is required and must be from the enumeration list. (REJ)
  • Certain coverage codes required additional Supplemental Homeowners Data (SHD) fields. The applicable coverage codes are 1003, 1006, and all 2000 level coverage codes except 2013, 2014, or 2015. The SHD fields are HurricaneDeductible, WsCoverage, WspEligible, AopDeductible, and PrimaryAmount. Inclusion of the SHD fields where not applicable are not allowed as well. (REJ)

StateAllocations Node (Multistate files only)

  • Values for the StateAllocation element must be from the StateCodeType enumeration list in the schema. (REJ)
  • The total of all the PremiumAllocation elements for a particular transaction's StateAllocations node must equal to the transaction's Premium element. (REJ)
  • The total of all the PolicyFeeAllocation elements for a particular transaction's StateAllocations node must equal to the transaction's PolicyFee element. (REJ)

Insurer Node(s)

  • While the Name of the Insurer/Carrier is not required in the Insurer node, the NAICNumber must be from the Florida provided list of eligible insurers or federally authorized insurers. (TIQ)
  • If the insurer used for a particular transaction is not on these lists, you should use "FSLSONAIC" for the NAICNumber element. Any transactions submitted with "FSLSONAIC" will be automatically questioned. (TIQ)
  • If the NAICNumber is that of Lloyd's of London (AA1122000), the UMR field must be included, and it must follow the standard pattern of a UMR. (REJ)
  • If the NAICNumber is NOT that of Lloyd's of London (AA1122000), the UMR field is not allowed. (REJ)