La. Admin. Code tit. 55 § III-1768

Current through Register Vol. 50, No. 11, November 20, 2024

Section III-1768 - Insurance Provider Web Services

A. All insurance providers, except those granted an exemption, are required to implement web services capable of correctly verifying the existence of mandatory insurance for vehicles registered in LA. Insurance providers covering less than 500 vehicles registered in LA are encouraged, but are not required, to provide a web service.

B. Web Service Structure. The LAIVS Online Verification client is based upon the model developed by the IICMVA that allows a jurisdiction to use web services hosted by insurance providers to verify insurance. This section describes the overall structure of the web services to be hosted by the insurance providers.

1. Web Services Description Language (WSDL) File. A WSDL file is an XML file that describes the public interface to a web service. The IICMVA has created WSDL files for Java, .Net, and Universal web service implementations. To make the verification process as fast as possible, LAIVS uses these WSDL files and does not attempt to read the WSDL file at each web service every time a verification request is initiated. LAIVS manages the endpoints, which are uniform resource locators (URLs), from a local configuration file.

2. Schema. An XML schema describes the structure of an XML message. LAIVS currently supports the ANSI ASC X12 Insurance Committees XML schema for online insurance verification. Case is not specified in the schema. If an insurance provider has particular requirements for upper or lower case, the message payload must be converted to the required case. Also, the policy number must be converted to the required format.

3. Extensible Markup Language (XML) Messages. The XML messages for the insurance verification request and response are derived from the schema. Appendix A contains a sample verification request message and a sample verification response message.

4. Simple Object Access Protocol (SOAP) SOAP is an XML based protocol that is used by web services to wrap around the XML messages making them platform and language independent. SOAP 1.1 is required.

5. Hypertext Transfer Protocol (HTTP) over Transmission Control Protocol/Internet Protocol (TCP/IP). The XML messages will be transported over the internet via HTTP. Verification requests will utilize HTTP 1.1 and it is strongly suggested that it be used for the verification responses as well.

6. Security. The XML messages will be encrypted via the Secure Sockets Layer (SSL). LAIVS will maintain Class 3 X.509 certificates identifying both the test and production environments. The certificate will be presented in each connection handshake so that the insurance provider can authenticate the client.

C. Expected Level of Service

1. Insurance providers web services are required to respond to verification requests on a 24/7/365 basis. Although a reasonable amount of downtime to maintain and upgrade systems may occur, the web service availability, measured on a monthly basis, shall be at least 99 percent.

2. Scheduled downtime must be reported via e-mail to support@LAIVS.org as early as possible, describing the reason for the downtime, the time the web service will become unavailable, and the time it is expected to become available again.

3. Unscheduled downtime must be reported via e-mail to support@LAIVS.org immediately, describing the reason for the downtime, the time the web service became unavailable, and the estimated time it will become available again.

4. Each online LAIVS transaction should take no more than five seconds from the time that the verification request message is initiated by the users system until the response reaches the users system. In order to achieve the overall five second response time, each insurance provider should design its web service to provide a response within two seconds of receipt of an inquiry. Contributing factors to slow responses outside the control of the insurance providers, such as Internet response time, will be taken into account. Responses not received in a timely manner will be logged and used for evaluating the insurance provider's web services performance.

5. Accuracy is critical to the success of the program. Therefore, each insurance providers web service must provide the correct response to an inquiry. Each web service will be monitored and tested for accurate responses, including testing for false confirmations.

D. The Verification Request and Response

1. LAIVS supports the current and previous versions of the IICMVA specifications and plans to include future versions as they are issued. Prior to implementation of a schema, a WSDL created from the schema must be tested and approved.

2. The Verification Request

a. The verification request is sent to the appropriate insurance provider by LAIVS in the XML message format that is valid for the schema employed by the insurance providers web service. Verification that the request is from an authorized entity can be established from the certificate that LAIVS will present when the connection is initiated.

b. The following data elements will be in the verification request message:

i. tracking/reference number (ties the request to the response);

ii. National Association of Insurance Commissioners (NAIC) code (identifies insurance provider);

iii. vehicle identification number (VIN);

iv. policy number ("UNKNOWN" will be provided, if not available);

v. verification date. The verification date may be the current date or a date in the past. Insurance providers are required to maintain at least six months history. When a data element is required by the schema, if that data element is not available, LAIVS will send the following default value:

(a). "UNKNOWN" in any mandatory field where text is expected;

(b). zeroes in any mandatory field where numbers are expected.

3. The Verification Response

a. For each verification request sent by LAIVS, a verification response is issued by the insurance providers web service. Because of front end edits, LAIVS will not send inquiries that would result in a response from the insurance provider that the request was invalid.

b. If minimum financial responsibility coverage is present and the policy is active on the requested verification date, the insurance provider responds with the following coverage confirmation result: CONFIRMED.

c. If minimum financial responsibility coverage is not present or the policy is not active on the requested verification date, the insurance provider responds with the following coverage confirmation result: UNCONFIRMED.

d. The required data element in a verification response is:

i. ResponseCode.

e. We also recommend including the following data elements. However, these data elements are not mandatory.

i. Unconfirmed Reason Code

ii. TrackingNumber (return the number received in the verification request)

iii. NAIC

iv. VerificationDate

v. UniqueKey (policy number)

vi. PolicyState

E. Web Service Testing

1. Before testing begins, each insurance provider will have to register on the LAIVS website as described in Section 5. After registration is complete, the insurance provider will be contacted by the LAIVS team to schedule a conference call to discuss the testing process and address any questions about the LAIVS requirements. The following information will be collected during the call:

a. NAIC codes and the corresponding names of the underwriting insurance providers that will be responding to verification requests through the web service;

b. the web service URL(s);

c. a time frame during which insurance providers would like to conduct the testing.

2. Following the call, the insurance provider will be sent the following:

a. the SSL certificates that identify the LAIVS web service client;

b. the IP addresses that identify the source of the verification requests.

3. Although it is not required, the insurance provider can also send its SSL certificate for installation in the LAIVS trust store.

4. The testing will consist of the following steps.

a. Basic Connectivity Test. Connectivity between endpoints is tested via "ping" to ensure that endpoints are reachable.

b. Test ability to send and receive messages. Test verification requests and responses formatted in XML and wrapped in SOAP are exchanged.

c. Testing with security. The SSL encryption and authentication via the X.509 certificates will be enabled. Testing will be done to ensure that the functionality is not impacted. To properly authenticate the certificate from the jurisdiction, each insurance provider must install the public key from the jurisdictions certificate and the root certificate from the issuing certificate authority.

d. Test Cases and Data. LAIVS will run the Insurance providers Web service through a set of test cases. If required, the insurance provider will provide the data necessary for these test cases. After all the above testing has been completed, the insurance provider can make their production Web Services available to LAIVS for insurance verification.

F. VIN Broadcasting

1. If the VIN in the verification request message matches an insured vehicle but the policy number in the request does not match the insurance policy number, then the insurance providers web service should be able to indicate that the vehicle is covered (this is known as "VIN Broadcasting" or "Unknown Carrier Request"). The insurance provider can indicate that the vehicle is covered in one of the following ways:

a. Returning a value of "UNCONFIRMED" in the Response Code field and a value of "10" or "VIN3" in the UnconfirmedReasonCode field of the CoverageResponse document.

b. Returning a value of "CONFIRMED" in the Response Code field of the Coverage Response document.

2. It is recommended that insurance provider web services support VIN broadcasting. If an insurance provider web service does not support VIN broadcasting, then they are required to provide BOB data on a weekly basis.

La. Admin. Code tit. 55, § III-1768

Promulgated by the Department of Public Safety and Corrections, Office of Motor Vehicles, LR 412684 (12/1/2015).

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