1. A. Insurance providers must submit book of business (BOB) files to LAIVS by the seventh calendar day of each month. Insurance providers whose web services do not support VIN broadcasting or are not hosting a web service must provide BOB data on a weekly basis. Insurers providing weekly BOB data can submit the data on any day of the week including the weekend. Insurance providers that issue coverage for less than 500 vehicles in Louisiana shall either submit BOB files via FTP or report BOB data using the LAIVS website. Follow the guidelines and procedures explained in the sections below when providing the BOB files to LAIVS.

2. B. BOB Data to Be Reported. Report the following information when submitting the BOB files:

   1. 1. all active LA motor vehicle insurance policies with the minimum liability coverage required by the state of Louisiana and the associated vehicles and customers;
   2. 2. both private passenger and commercial motor vehicle insurance policies shall be reported. The VIN is not required for fleet policies. A fleet policy is a policy insuring a business with a fleet of five or more vehicles registered in LA for which VIN information is not maintained on each vehicle. However, if the insurance provider does maintain the VIN of the vehicles within the fleet, the VINs must be reported in the book of business file;
   3. 3. the vehicle types that should be reported are provided in Appendix C.

3. C. BOB File Structure. The BOB file structure is based upon Version 1.1 of the Insurance Data Transfer Guide published by the IICMVA on August 23, 2011. The BOB file is a text file with rows of fixed length. All rows will be 300 characters long with spaces used as filler. Follow each row with a carriage return line feed character (Hexadecimal ‘0D 0A’). Submit a separate file for each NAIC number.

   1. 1. File Name. The file name should include the following fields.

      1. a. NAIC Number: Insurance provider’s NAIC Number
      2. b. File Creation Date: Date file was created in the YYYYMMDD format
      3. c. Environment: “P”Production; “T”Test
      4. d. Extension: File extension such as “pgp”, “asc”, ”txt” or any other 3 character file extension
      5. e. File Name format should be in the NAIC_ Date_Environment.extension format. For example: 12345_20110815_P.pgp

   2. 2. Detail Rows. The detail rows show the policy data being submitted by the insurance provider. Generate one record per customer, vehicle, and policy combination. For example, if policy number 12345 is associated with customers Jane and John Doe on a 2004 Jeep and a 2005 GMC, then four records with the following combinations should be created.

      1. a. Jane Doe, 2004 Jeep, policy 12345
      2. b. Jane Doe, 2005 GMC, policy 12345
      3. c. John Doe, 2004 Jeep, policy 12345
      4. d. John Doe, 2005 GMC, policy 12345

      5. e. Each field’s length is specified in the table below with any unused length filled by trailing spaces. Any fields for which a value is not being provided should be filled with spaces. Provide the following fields in each row.

         Field Id	Field Name	Length	Begin	End	Type (AN –Alpha numeric N- Numeric)	Mandatory/ Optional	Description
         1	POLICY TYPE	2	1	2	AN	M	‘VS’ = Vehicle Specific ‘NS’ = Non Vehicle Specific (Fleet Policies)
         2	NAIC	5	3	7	N	M	NAIC Code
         3	POLICY NUMBER	30	8	37	AN	M	Policy Number
         4	EFFECTIVE DATE	8	38	45	N	M	Effective Date – YYYYMMDD format Date coverage was added for the vehicle. There should not be any time out of force (lapse of coverage) between the Effective Date and the transmission date. If the vehicle had any time out of force, then the effective date that coverage was resumed or reinstated should be reported.
         5	VIN	25	46	70	AN	O	VIN (optional for non-vehicle specific fleet policy)
         6	LAST NAME or ORGANIZATION	40	71	110	AN	M
         7	PREFIX NAME ABBR	3	111	113	AN	O
         8	MIDDLE NAME	20	114	133	AN	O
         9	FIRST NAME	40	134	173	AN	O	Mandatory if customer is an individual
         10	SUFFIX NAME	3	174	176	AN	O	Abbreviated Name Suffix (JR, SR, etc.)
         11	FEIN	9	177	185	AN	O
         12	ADDRESS	50	186	235	AN	M
         13	CITY	35	236	270	AN	M
         14	STATE	2	271	272	AN	M
         15	ZIP	5	273	277	N	M
         16	COMMERCIAL INDICATOR	1	278	278	AN	O	"Y" for commercial policies
         17	FILLER	1	279	279	AN	O
         18	POLICY EXPIRATION DATE	8	280	287	N	O	Future expiration/renewal date of the current policy term. Format is YYYYMMDD.
         19	FILLER	13	288	300	AN	M	Space Filled

   3. 3. Trailer Row. Each file should have one trailer row
      with the following fields.

      Field Name	Length	Begin	End	Type	Mandatory/ Optional	Description
      TYPE	2	1	2	AN	M	TR’ = Trailer
      RECORD COUNT	12	3	14	N	M	Record count not including Trailer Record
      PROCESS DATE	8	15	22	N	M	Date the file was created – YYYYMMDD Format
      FILLER	278	23	300	AN	M	Space Filled

4. D. BOB File Submission. Each insurance provider will be assigned an FTP account (see Section 2.5). There will be two folders under each FTP account. Place all BOB files into the BOB_Inbound folder. All return files created by LAIVS in response to the BOB files will be placed in the BOB_Outbound folder.

5. E. BOB Return Files Generated for Insurance Providers. This section describes the types of files that may be generated by LAIVS and placed in the BOB_Outbound folder of the insurance provider. These files will inform insurance providers if their files were successfully processed or if any errors were encountered in the processing. For each BOB file submitted by the insurance provider, at least one of the following files will be generated by LAIVS:

   1. 1. OK File. If there are no errors in the BOB file submitted by the insurance provider, an OK file will be generated. The OK file name will be named
      OK_NAIC_DatetimeStamp.pgp (e.g. OK_12345_ 20110806121501.pgp).

   2. 2. Decryption Error File. This file will be generated if a PGP decryption error occurs. Decryption errors can happen for the following reasons.

      1. a. File sent by insurance provider was not encrypted.
      2. b. File sent by insurance provider was improperly encrypted.
      3. c. File sent by insurance provider was encrypted using the wrong PGP key.
      4. d. Decryption error file will be identified based on the file name prefix DE. The file will be named
         DE_NAIC_DatetimeStamp.pgp (e.g. DE_12345_ 20110806121501.pgp).

   3. 3. Reject File. This file will be generated if LAIVS cannot read the file or if the file is improperly formatted and the whole file is being rejected. The file may be rejected for the following reasons.

      1. a. File is not formatted properly.
      2. b. Trailer has a non-zero record count but detail records of the file are missing.
      3. c. Length of each record (line) is not up to the length specified in this guide.
      4. d. End of a record missing carriage return and line feed (Hexadecimal ‘0D 0A’).
      5. e. The reject file will contain the description of the error at the top followed by the contents of the file.
      6. f. The reject file can be identified based on the file name prefix REJ. File will be named REJ_ NAIC_ DatetimeStamp (e.g. REJ_12345_ 20110806121501.pgp).

   4. 4. Row Error File. Row error files are generated when the overall file format sent by the insurance provider is okay but some of the rows have errors including:

      1. a. mandatory fields missing;
      2. b. invalid field formats;
      3. c. the row error file will contain only the records that are in error. The remaining records sent with the original file will be processed by LAIVS and will not appear in the file. Each error record will have the original row sent by the insurance provider followed by a 3 digit Error Code. The format of the Error Code will be E followed by the Field ID of the invalid/missing field. For example, the Error Code for a row with an invalid NAIC number will be “E02”. A complete list of Error Codes is provided in Appendix D;
      4. d. the Row Error file can be identified based on the file name prefix ERR. File will be named ERR_ NAIC_ DatetimeStamp (e.g. ERR_12345_20110806121501.pgp);

   5. 5. VIN No-Match File. The VIN No–Match files are generated if any of the VINs submitted by the insurance provider do not match VINs of vehicles registered in LA. The VIN No-Match file will include all the records where the VIN did not match. Each record will have the original row sent by the insurance provider followed by “E05”, the 3 digit Error Code indicating VIN mismatch. VIN No-Match files are sent to insurance providers for informational purposes and insurance providers are not required to take action based on these files.

      1. a. The VIN No-Match file can be identified based on the file name prefix VIN. File will be named
         VIN_NAIC_DatetimeStamp (e.g. VIN_12345_ 20110806121501.pgp).

6. F. FTP Accounts and PGP Encryption. Insurance providers must send text files to LAIVS using File Transfer Protocol (FTP). FTP accounts will be created for each insurance provider after registering with LAIVS. If the insurance provider prefers, the same FTP account can be shared by providers with different NAIC numbers that are under the same insurance group. Login information and the IP addresses of the FTP servers will be provided after registration.

   1. 1. Each FTP account will have the following folders:

      1. a. BOB_Inbound;
      2. b. BOB_Outbound.
   2. 2. All files exchanged between LAIVS and insurance providers will be encrypted by the Pretty Good Privacy (PGP) digital data encryption program. Public PGP keys will be exchanged with the LAIVS Help Desk prior to exchanging insurance data. In addition, insurance providers will have the option to use SFTP (Secure File Transfer Protocol using SSH) instead of FTP for transmission layer security.

7. G. BOB File Testing Process. Before testing begins, each insurance provider participating in LAIVS must register on the LAIVS website as described in Section 5. After completing registration, insurance providers will be contacted by the LAIVS team to schedule a conference call to discuss the testing process and address any questions about the LAIVS reporting requirements. FTP User IDs and passwords will be provided and public PGP keys will be exchanged. The testing process includes the following:

   1. 1. Connectivity Testing. The insurance provider should be able to connect to the designated LAIVS FTP server, log in to the insurance provider’s FTP account, and transfer files to the appropriate folders. The insurance provider should be able to retrieve LAIVS return files.
   2. 2. Decryption. LAIVS should be able to successfully decrypt files. The insurance provider should be able to successfully decrypt LAIVS return files.
   3. 3. File Format. The insurance provider files should be formatted according to LAIVS requirements.
   4. 4. File Content. The insurance provider file should contain valid test data and the data elements should meet the LAIVS rules. During testing, it is not necessary to provide production data (in force policies).
   5. 5. Insurance providers must pass the above tests before submitting production data. The LAIVS team will work with insurance providers and provide information to assist in resolution of any errors.

Authority Note

AUTHORITY NOTE: Promulgated in accordance with R.S. 32:863.2.

Historical Note

HISTORICAL NOTE: Promulgated by the Department of Public Safety and Corrections, Office of Motor Vehicles, LR 41:2682 (December 2015).