commercial driverâ€™s license information system

4301 Wilson Boulevard, Suite 400 Arlington, VA 22203 (703) 522-1300 Fax (703) 522-1553

Commercial Driver’s License Information System

(CDLIS)

Master Specifications Document

Release 5.1.0

January 2010

CDLIS System Specification (Release 5.1.0)

ii

AAMVA Ŕ Official Use Only

The American Association of Motor Vehicle Administrators (AAMVA) produced this document. No part of this

document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including

photocopying, recording, or information storage or retrieval systems, for any purpose other than the intended use by

AAMVA, without the express written permission of AAMVA.

© 2009 AAMVA. All rights reserved.


iii


Table of Contents

1 INTRODUCTION _______________________________________________ 1

1.1 DOCUMENT SCOPE AND PURPOSE _______________________________________ 1

1.2 CDLIS MODERNIZATION WORKING GROUP _______________________________ 1

1.3 OTHER CDLIS DOCUMENTATION ________________________________________ 2

1.4 AAMVA CONTACT INFORMATION _______________________________________ 2

2 TRANSACTION DESIGN _________________________________________ 3

2.1 AMIE MESSAGE FORMAT _______________________________________________ 3

2.2 DATA ELEMENTS ______________________________________________________ 5

3 NETWORK INTERFACE Ŕ UNIFIED NETWORK INTERFACE (UNI) _____ 7

3.1 CALL LIST INTERFACE _________________________________________________ 9

3.2 CALL LIST FORMAT ____________________________________________________ 9

3.3 UNI SUB-SYSTEM CODE ________________________________________________ 9

3.4 MESSAGE GROUPING _________________________________________________ 10

3.5 APPLICATION MESSAGE FILE __________________________________________ 10

3.6 MESSAGE RETRY _____________________________________________________ 10

3.7 PACING MESSAGES ___________________________________________________ 11

3.8 HARD MANUAL DOWN ________________________________________________ 11

3.9 PURGE CRITERIA FOR UNI LOGS _______________________________________ 11

3.10 ERROR RESOLUTION _________________________________________________ 12

4 CDLIS ERROR PROCESSING ____________________________________ 13

4.1 CDLIS DATA ELEMENTS USED AS ERROR FLAGS OR ERROR CODES ______ 13

4.2 CDLIS ERROR BLOCK (25/1) ____________________________________________ 13

4.3 TYPES OF ERRORS ____________________________________________________ 28

5 SYSTEM OPERATION __________________________________________ 33

5.1 HOURS OF OPERATION ________________________________________________ 33

5.2 PERFORMANCE REQUIREMENTS _______________________________________ 33

5.3 SECURITY REQUIREMENTS ____________________________________________ 33

6 CENTRAL SITE LOGICAL DATA MODEL (LDM) ___________________ 34

6.1 POINTER AND RELATED DATA _________________________________________ 36

6.2 LOG DATA ____________________________________________________________ 41

6.3 SUPPORTIVE DATA ____________________________________________________ 44


iv


7 INTERACTIVE PROCESS DESCRIPTIONS _________________________ 46

7.1 PROCESS IMPLEMENTATION CHART CONVENTIONS _____________________ 46

7.2 NAME COMPARISON ___________________________________________________ 46

7.3 COMMON PROCESS DESCRIPTIONS _____________________________________ 47

7.4 BACKWARD COMPATIBILITY DURING TRANSITION ______________________ 49

CD01 SEARCH INQUIRY ___________________________________________________ 51

CD02 VERIFICATION INQUIRY _____________________________________________ 63

CD03 STATE-TO-STATE STATUS REQUEST __________________________________ 76

CD04 STATE-TO-STATE HISTORY REQUEST _________________________________ 92

CD05 AKA DATA INQUIRY ________________________________________________ 97

CD06 EMPLOYER INQUIRY _______________________________________________ 109

CD07 ADD NEW DRIVER _________________________________________________ 119

CD08 CHANGE STATE OF RECORD ________________________________________ 134

CD09 CHANGE DATA ____________________________________________________ 168

CD10 DELETE MASTER POINTER RECORD _________________________________ 186

CD11 REPORT OUT-OF-STATE CONVICTION _______________________________ 195

CD12 NEGATE OUT-OF-STATE CONVICTION _______________________________ 216

CD14 MARK DRIVER UNIQUE _____________________________________________ 233

CD15 UPDATE AKA DATA ________________________________________________ 243

CD16 REPORT OUT-OF-STATE WITHDRAWAL ______________________________ 257

CD17 NEGATE OUT-OF-STATE WITHDRAWAL ______________________________ 282

CD18 MINIMAL DATA DRIVER SEARCH INQUIRY __________________________ 299

CDA1 DUPLICATE DRIVER PROCESS ______________________________________ 310

CDB1 PROCESS STATUS RECEIVED (STATE OF INQUIRY (SOI)) ______________ 333

CDC1 ASSIST IN ERROR RESOLUTION (CDLIS CENTRAL SITE) ______________ 340

CDD1 RESOLVE STATUS ERRORS (STATE OF RECORD (SOR)) _______________ 341

CDE1 RESOLVE HISTORY ERRORS (STATE OF RECORD (SOR)/OLD SOR) _____ 342

CDF1 CREATE AKA FROM UPDATE MESSAGE (CDLIS CENTRAL SITE) ________ 344

CDG1 CREATE AKA FROM MASTER POINTER DATA (CDLIS CENTRAL SITE) __ 347

CDH1 SEARCH INQUIRY RETRIEVAL (CDLIS CENTRAL SITE) ________________ 349

CDI1 PROVIDE DETAIL ON REQUESTED DRIVER (STATE OF RECORD (SOR)) _ 353

CDJ1 AUTHORIZATION, IMPLEMENTATION VERIFICATION (CDLIS CENTRAL

SITE) ___________________________________________________________________ 360


v


CDL1 PROCESS HISTORY REQUEST (STATE OF RECORD (SOR)/OLD STATE OF

RECORD (OSOR)) ________________________________________________________ 362

CDM1 PROCESS HISTORY RESPONSE (INQUIRER) __________________________ 380

CDN1 APPLY COMMON VALIDATIONS (CDLIS COMMON VALIDATION

PROCESSOR) ____________________________________________________________ 394

8 BATCH PROCESS DESCRIPTIONS ______________________________ 417

CD30 BATCH INQUIRY ___________________________________________________ 418

CD31 MPR DATA QUALITY VALIDATION AND VERIFICATION _______________ 441

CD32 (PILOT) DHR DATA QUALITY VALIDATION AND VERIFICATION _______ 451

APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE ______________ 483

APPENDIX B - BLOCKS BY MESSAGE TYPE _______________________ 557

APPENDIX C - DATA ELEMENTS BY BLOCK ______________________ 580

APPENDIX D - DATA DICTIONARY _______________________________ 597

APPENDIX D.1 - DATA ELEMENTS _________________________________________ 597

APPENDIX E Ŕ PERSON NAME FORMATTING ______________________ 673

APPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULES ______________ 673

APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008) __________________ 678

APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008) VALIDATIONS ____ 684

APPENDIX E.4 Ŕ NAMES STORED ON JURISDICTIONS' SYSTEMS _____________ 686

APPENDIX F ŔWITHDRAWAL IDS AND CONVICTION IDS ___________ 687

APPENDIX G - GLOSSARY _______________________________________ 691


vi


THIS PAGE INTENTIONALLY LEFT BLANK


1 INTRODUCTION 1


1 INTRODUCTION

The Commercial Driverřs License Information System (CDLIS) is a nationwide system composed of:

A central site identifying the State of Record (SOR) for each driver commercially licensed in the United States

(SORs include the 50 U.S. states and the District of Columbia);

Detailed driver data distributed across the SORs;

The associated computer and communication hardware that comprises the network; and

The associated software used to manage the system.

Authorized users can report and access commercial driver identification information, commercial driverřs license

information, and driver history information needed to regulate commercial drivers in the U.S. CDLIS enables the

jurisdictions to satisfy the requirements of federal laws and regulations related to commercial drivers.

1.1 DOCUMENT SCOPE AND PURPOSE

This document, prepared by the American Association of Motor Vehicle Administrators (AAMVA), presents the

functional specifications for CDLIS. The objective is to provide the information necessary for the CDLIS Central Site

Operator, jurisdictions, and other users to develop the system. It provides guidance on the technical aspects of CDLIS as

mandated by the Commercial Motor Vehicle Safety Act (CMVSA) of 1986, the Transportation Equity Act for the 21st

Century (TEA-21) of 1998, the Interstate Commerce Commission Termination Act of 1995 (ICCTA), and the Motor

Carrier Safety Improvement Act (MCSIA) of 1999 and further defined by Title 49, Sections 383-384 and the CDLIS

architecture. This document does not address other CMVSA, NAFTA, ICCTA, and MCSIA requirements outside the

scope of the information system.

The CDLIS Specifications document is intended to be used in conjunction with other CDLIS documentation noted

below. Together, these documents represent the suite of reference material necessary for the operation and maintenance

of CDLIS by CDLIS users.

The material contained in this document is based upon work supported by the U.S. Department of

Transportation/Federal Motor Carrier Safety Administration under Operation, Management, Administration, and

Modernization Cooperative Agreement. Any opinions, findings, conclusions or recommendations expressed in this

publication are those of the Author(s) and do not necessarily reflect the view of the U.S. Department of Transportation.

1.2 CDLIS MODERNIZATION WORKING GROUP

Functional enhancements reflected in this document are a direct result of research, analysis and input provided by the

CDLIS Modernization Working Group. The following entities have been actively involved in this process and have

contributed significantly to the development of enhanced functionality deployed as part of the CDLIS Modernization

effort.

Arkansas Office of Driver Services

California Department of Motor Vehicles

Colorado Division of Motor Vehicles

Georgia Department of Driver Services

Maine Bureau of Motor Vehicles

Maryland Motor Vehicle Administration

Mississippi Department of Public Safety

Missouri Division of Motor Vehicle and Driver Licensing

New Jersey Motor Vehicle Commission

New York Department of Motor Vehicles

North Carolina Division of Motor Vehicles

North Dakota Department of Transportation

Wisconsin Division of Motor Vehicles


1 INTRODUCTION 2


1.3 OTHER CDLIS DOCUMENTATION

For additional information regarding the functionality of CDLIS, refer to the following documents (available from

AAMVA):

Other CDLIS documentation (available from AAMVA):

CDLIS Reports

CDLIS State Procedures Manual

CDLIS Third-Party Employer Inquiry Specification

AAMVA Code Dictionary (ACD) Manual

Unified Network Interface (UNI) Documentation

1.4 AAMVA CONTACT INFORMATION

Jurisdictions may direct CDLIS questions to their assigned AAMVA Operations Help Desk Point-of-Contact (POC).

Other CDLIS users and jurisdictions unable to contact their POC may refer questions to the AAMVA Operations Help

Desk:

Hours: 8:00 a.m. - 6:00 p.m. Eastern Time

Telephone: 1-888-AAMVA-80 (1-888-226-8280)

Fax: 1-703-522-1553

E-mail: [email protected]

Website: www.aamva.org

Address: AAMVA, Inc, 4301 Wilson Boulevard, Suite 400, Arlington, Virginia 22203


2 TRANSACTION DESIGN 3


2 TRANSACTION DESIGN

A CDLIS transaction is a set of pre-defined CDLIS messages containing data element values sent between AAMVAnet

nodes for a business or network-maintenance purpose of the Commercial Driverřs Licensing program (see "APPENDIX

A Ŕ DATA ELEMENTS BY MESSAGE TYPE"). CDLIS has two categories of transactions, physical and business. A

physical transaction contains an unsolicited message and any messages returned in response to the initial message. A

business transaction is a set of messages that are needed to perform a business function.

A business transaction may involve one or more physical transactions. For example, a business transaction may involve

an inquiry message from one jurisdiction to another and the response going back, which is one physical transaction. A

more complicated business transaction may have an inquiry going from a jurisdiction to the CDLIS Central Site, which

routes the inquiry to the jurisdiction that holds the driverřs record, i.e., the Current State of Record (SOR). The

responses would then be sent from the current state of record to the state originating the inquiry. The first physical

transaction involves the messages from the inquirer to the CDLIS Central Site and the final response to the inquirer.

The second physical transaction involves the CDLIS Central Site and the SOR.

The most common type of business transaction consists of an initial message and its response message(s). This is used

on inquiries where the response(s) return the data, and on updates where the response returns a confirmation of the

update. A business transaction may consist of multiple initial messages and their responses, but this type of transaction

is less common. The last type of business transaction involves a message to which no response is sent. Normally this is

only used for non-critical notification messages.

When a transaction has optional response messages, a mechanism is included in the messages to indicate the quantity of

each type of response message being sent. This is needed because the receiver of the responses needs to be able to

determine when all the responses have been received. The elements used to convey this information are referred to as

Adjustment fields. As each jurisdictionřs CDLIS application defines the messages in a specific transaction, the

application also defines which fields are used for the adjustment processing.

2.1 AMIE MESSAGE FORMAT

Messages in CDLIS transactions are sent in the AAMVAnet Message Interchange Envelope (AMIE) message format.

The AMIE format is used to exchange data between network nodes using the Network Control Software (NCS). Each

message follows the same basic format but contains different data depending on the purpose of the message.

The AMIE format defines message types of variable length containing blocks of position-defined data that are 66 bytes

(i.e., characters) long (see ŖAPPENDIX B - BLOCKS BY MESSAGE TYPEŗ). Due to early network limitations, up to

55 blocks are allowed within a message, resulting in a maximum message length of 3630 bytes.

Each message begins with a Network Control Block (NCB), which contains information about the message type,

routing, length, and other relevant data. Subsequent blocks are part of the application text block pool. A message may

contain zero to 54 application text blocks. Each block is not a separate message (or packet), but the NCB and related

application text blocks are bundled together as a single network message.

A typical business message contains the following blocks:

One Network Control Block (NCB)

Application Text Blocks

o One Message Verification Block on each message

o One Message Exchange Control (MEC) block on each message.

o One to 52 business application blocks may be used, depending on the message type. The application

blocks contain the details specific to the application. Normally these blocks hold the application's

business data, but they may also be used to hold technical information (e.g. a Return as Received block).

o Zero to five error blocks may be used, depending on the number of errors detected. See Ŗ4 CDLIS

ERROR PROCESSINGŗ for details.

The following figure depicts the blocks of an AMIE message and their lengths.

< NCB ><Text block 1><Text block 2> to <Text block n>

<-----66-----><-----66-----><-----66-----> to <-----66----->




Each application text block consists of a 5-byte text block key and the 61-byte text block data area. The following

figure depicts the application text block and the lengths of its components.

< Text Block>

< Text Block Key ><Text Block Data>

<Type><SubT><Line>

<02> <1> <02> <--------- 61 --------->

The application text block key uniquely identifies a block. It consists of the block identifier and a line number. The

block identifier consists of the block type and sub-type. When a block is being referenced, it is often described as

type/sub-type. When the same block type/sub-type is used multiple times within a message, the line number is used to

distinguish the occurrences of the block type/sub-type. The line numbers are allocated sequentially, starting with 01, for

a given block type/sub-type occurrence within a message.

Blocks in a message are ordered by block type. As the block type is numeric, this order can be applied to all platforms.

The block sub-type may be a number or a letter. Because of the different computer architectures, there is no guarantee

that blocks sub-types always have the same order (e.g. the block sort order on an IBM is 30/A, 30/1; while on a UNIX

box the order would be 30/1, 30/A).

Messages are often defined with application text blocks that are optional. To improve efficiency, only application text

blocks that contain application data should be transmitted.

Each block contains pre-defined positions for data element values (see ŖAPPENDIX C - DATA ELEMENTS BY

BLOCKŗ). The following sections contain a discussion of the types of blocks in a message and the noteworthy data

element fields in the blocks.

2.1.1 Network Control Block

Every message contains a Network Control Block (NCB), which contains information used by the Network Control

Software (NCS) to identify and route the message. Many of the data element fields are automatically populated by a

network interface tool, such as AAMVAřs Unified Network Interface (UNI) tool (see Ŗ3 NETWORK INTERFACE Ŕ

UNIFIED NETWORK INTERFACE (UNI)ŗ). The remainder of the data element fields need to be filled by the

application programs.

The NCB block has no text block key, however it is often referred to as block '00/0'.

Message addressing is accomplished through the use of three data element fields in the Network Control Block:

Message Destination. Indicates to which node the message is to be sent.

Message Origin. Indicates which node sent the message.

Transaction Originator. Indicates the initiator of the transaction of which the message is a part.

Since the contents are shifted between the message address fields during response processing, all of these fields have the

same 7 byte alpha-numeric format. The first three bytes of the address are known as the GAP (Government/Application

Provider) Code and the last 4 bytes of the address contain the User Extension. The address has the following layout:

G G G U U U U

The Primary Address occupies the first 2 bytes of the GAP code and the Interface Code occupies the third, so an

alternate view of the layout is:

P P I U U U U

The Primary Address is the 2-character code for jurisdictions (normally the postal abbreviation) and AAMVA

processing sites. The Interface Code is used to distinguish between different AAMVA applications at one primary

address. For example, in some jurisdictions the driver licensing and vehicle registration applications are operated on

different physical machines. The Interface Codes would be different for each. The Interface Code does not support two

implementations of a CDLIS application at the same site.

The User Extension field of the Primary User description can be used at the discretion of the users, within the normal

parameters for AMIE messages. This field is frequently used to identify a particular workstation that originated the

message and therefore should receive the response. Other uses are possible depending on the needs of the users.




AAMVA manages the addresses and therefore is responsible for assigning all values as necessary for the GAP Codes.

2.1.2 Message Exchange Control Block

The Message Exchange Control (MEC) block is counted as one of the Application Text Blocks. It contains fields that

are commonly used while processing. The fields in the block tend to be used to manage a transaction (i.e., both an

initial message and its responses). The use of most of the fields in the MEC block is dependent on the type of message,

so their use is described in the processing description sections of the specification. The Message Locator element

(GMSLOC) of the MEC block is used in all messages.

See the Source Code definitions in ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for a description of

how the elements in the block are populated and used in each message.

The MEC block has a text block type of '02'.

2.1.3 Other Application Text Blocks

The other application text blocks in a message contain the business information, such as the Driverřs license number, or

error information. The majority of the other application text blocks are used once within a message. However instances

exist where an AMIE text block is used multiple times within a message. These multiple repetitions exist when:

A field is too long to fit in a single 61 byte block. For example a 108 byte residence address is transmitted in

two AMIE text blocks. The first 61 bytes are sent in the first block and the final 47 bytes are sent in the second

block.

The application data is needed multiple times, where a single occurrence of the data fits into one block. The

number of blocks correspond to the number of occurrences of the data.

The data is needed multiple times; however the total length of the data to be repeated exceeds one block. In

these situations the number of AMIE text blocks used is the product of the number of blocks used to hold a

single occurrence, times the number of occurrences.

To be unique, the Text Block Key uses an incremented line number to distinguish between the multiple occurrences of

block types and maintain the sort sequence.

2.2 DATA ELEMENTS

Data element values in a particular block in a particular message are filled based on the data elementřs definition, data

type, and allowable values, which are specified for each CDLIS data element in ŖAPPENDIX D - DATA

DICTIONARYŗ.

2.2.1 Printable Characters

The CDLIS standard is that data element values must consist of printable characters, which means that non-printable

bytes are not allowed in any AMIE message. Nevertheless, non-printable characters may sometimes be sent to the

CDLIS Central Site, so the CDLIS Central Site software must be able to receive them.

The printable character limitation has been imposed because different types of computers use different data encoding

schemes. Therefore, to communicate, only characters that are common on all the computers connected to the network

can be used.

For example, IBM mainframes store character data in EBCDIC, while UNIX, Unisys, Bull, and most other computer

types store character data in ASCII. Translation between these code sets is performed as part of the network

transmission to or from an ASCII based machine. The translation occurs by replacing a bit pattern from one code set

with the corresponding bit pattern from the other code set. As the translation is performed on each byte of data

traveling on the data path without regard to the content of the data, non-printable data would be corrupted when the bit

patterns were replaced as if the byte contained character data.

All application data elements must contain printable characters that can be used in both ASCII and common versions of

EBCDIC (such as US-EBCDIC). The printable characters are:

space




a to z

A to Z

0 to 9

! " # $ % & ' ( ) * + , - . / : ; < = > ? @ \ _ ` { | } ~

Other characters are not printable in ASCII and common versions of EBCDIC, and must be excluded. The user needs

to determine if the non-printable characters are omitted or substituted with another character. The recommendation for

the Spanish characters is to convert them to similar English characters (e.g., a 'N' with a '~' above it (ñ) is converted to

'N') in accordance with the transliteration table in "APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)".

Note that the allowable characters within name fields for CDLIS implementations older than version 5.1 are still

specified by the requirements in ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ.

To ensure only printable bytes exist in a message, all unused areas of each block must be initialized with spaces.

This ensures unaddressable areas, such as the reserved bytes at the end of most blocks, contain valid AMIE data. Fields

with a defined value of 'blank' must likewise be initialized with spaces. Unused fields should also be initialized to

spaces regardless of the data type of the field. For example, a date field is normally numeric, yet if the field is not a

valid part of the message being built, the field should contain spaces rather than zeroes. Do not initialize AMIE blocks

or fields to LOW-VALUES or HIGH-VALUES, as these are binary zeroes or ones, respectively, and do not represent

printable data.

2.2.2 Dates

All dates sent in the application specific blocks of the messages are passed as eight character fields in 'ccyymmdd' form,

(e.g., '19951231').

2.2.3 Numbers

All numeric data sent in a message is passed in an unpacked form with leading zeros (e.g., a field with six integer digits

and a value of '1234' is transmitted as '001234' in an alpha-numeric field). This allows for the exchange of data between

users regardless of the compatibility of their internal numeric storage formats.

Unpacked numbers are used because different machine types store computational numeric data in a format native to the

processor. Assuming numeric data could move between AAMVAnet nodes without adulteration, the data would

probably be unusable by the destination node unless the origination and destination nodes happen to be compatible

machine types.

Eventually exceptions to this rule may be required to allow movement of complex data in an efficient manner, possibly

using encoding and compression schemes. At that time, specific exceptions will be defined and documented to an

extent that potentially affected users will be aware of their limitations. However, the general rule will still apply to all

other messages which may be sent between nodes running on different computer types.

2.2.4 Text

Normally alphanumeric or textual elements do not have any leading spaces (i.e., they are left justified). Elements

needing other justifications may specify it in the element definition.

Most textual elements use upper-case letters. Elements needing lower-case letters may specify this in the element

definition.

Elements that represent codes will use the specified values listed for the individual element definition in the

ŖAPPENDIX D - DATA DICTIONARYŗ.


3 NETWORK INTERFACE Ŕ UNIFIED NETWORK INTERFACE (UNI) 7


3 NETWORK INTERFACE – UNIFIED NETWORK INTERFACE (UNI)

Messages in CDLIS are sent between user nodes on AAMVAnet, AAMVAřs telecommunications network (see the

CDLIS State Procedures Manual for an overview of AAMVAnet and its CDLIS users). Each user of the AAMVAnet

network requires network interface software to provide a two-way, real-time bridge between messages on the network

supporting CDLIS and the system participant's internal host data processing and communications system (see following

figure). The network interface acts as an interpreter between the network message format, the AMIE format, and the

system participant's application program. It handles the conversion of information between the system participant's

internal data format and the AMIE format.

To enable the jurisdictions to work with many different organizations and systems and implement any of the

applications that are being developed for use on the network, AAMVA developed the Unified Network Interface (UNI).

UNI is a uniform application interface which provides the translation between the AMIE message structure (required for

transaction and message formatting) and some form of data element mapping (e.g., a call list) used by the user's

application programs. It also provides for a variety of other application interface support features such as message

grouping, routing validation, and queuing. Specifically, UNI has both a pseudo-batch interface and store-and-forward

capabilities.

The following is a summary of the network interfaces in CDLIS:

Jurisdictions may choose a network interface package or customized softwareŕnearly all use UNI

The Central Site uses a customized network interface

The Mexican Access uses a network interface package (UNI)

The Canadian Bridge uses a network interface package (UNI)

Service providers need a network interface; this may be a package or customized software

FMCSA (CDLIS Access) uses a network interface package (UNI)




Although using AAMVAnet's network interface tool, the Unified Network Interface (UNI), is not a requirement, most

jurisdictions use the UNI. UNI has several valuable functions available to assist the developers (such as message

control, routing validation, logging, audit trails, and message grouping). UNI also can populate some fields in a

message.

For a given field, UNI may:

Calculate the field.

Fill the field from the parameter list destination table.

Fill the field from a configuration constants copy member.

Derive the field based on a default for this application.

Derive the field based on a value from the parameter list.




See the Source Code definitions in ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for a description of

how the elements in the block are populated and used.

A jurisdiction's network interface team needs to understand UNI's functions to avoid duplicating those functions within

the application.

The purpose of this section is to supplement the UNI documentation by calling attention to several UNI features that

users have found particularly useful. Although they are documented in the UNI Application Developer's Reference, a

brief synopsis is included here along with suggested settings, where applicable.

AAMVA's web site (www.aamva.org) has an up-to-date listing of the platforms on which UNI runs.

3.1 CALL LIST INTERFACE

The call list is the COBOL layout of data passed between UNI and the application programs. It is used for data coming

to and from UNI. Depending on the UNI options selected, the call list data may be passed in files or queues.

The UNI group at AAMVA is responsible for distributing UNI and the COBOL Copy books containing the call list(s).

Developers who are not using COBOL may request the Offset reports from the UNI group. The offset reports provide

the addresses of the elements within the call list. When contacting the UNI Help Desk for copies of Call list(s) or Offset

Report(s), please specify the application(s) and the release of the application.

3.2 CALL LIST FORMAT

There is a record type indicator in the Driver Call List (CLMF-DESC-RECORD-TYPE) that is populated by UNI when

a message is received. This indicator is used to identify how much of the variable length Call List is being used. When

the indicator contains a:

"L" the type of record is a long record.

"S" the type of record is a short record.

"R" the type of record is a return as received

Under normal operation, the indicator need not be checked. In an exceptional case where data is expected in the long

part of the call list, but no data is received for the long part, application programs could encounter problems.

Addressing an element in the long part of the call list when only a short call list exists may cause the application

program crash.

3.3 UNI SUB-SYSTEM CODE

UNI has a table in which each site has its type classified for an application (e.g., this site is a Jurisdiction). This

classification is recorded in the UNI sub-system code. The table is used when messages are sent and received to ensure

the Message Type can be sent or received from that class of site. When configuring UNI for a given environment and

application, the sub-systems codes must be setup correctly for each site with which messages will be exchanged.

UNI uses the sub-system codes for checking if messages can be sent and received. If a particular sub-system code

allows a given message type, UNI will allow the message to be processed. If a message type is not configured for a

particular sub-system code, UNI will record the error in its error file then stop processing the message. The sub-system

code is not used to control which elements are in a message.

The CDLIS sub-system codes are:

0 = PASS THRU

1 = UNUSED

2 = UNUSED

3 = CDLIS HOST = CDLIS Central Site (all releases of the specifications)

4 = IRE/BRIDGE = IRE Bridge to Canada (all releases of the specifications)

5 = 3RD PARTY = Third Party Access (all releases of the specifications)

6 = UNUSED




7 = UNUSED

8 = STATE = State (all releases of the specifications)

9 = UNUSED

This information is also located in the ŘRead Meř text provided with each UNI release.

3.4 MESSAGE GROUPING

When a site initiates a transaction by sending a message, UNI creates a message control record (the first 16 characters of

the message locator field, which is the first 26 characters of the MEC block). A sample Message Locator containing a

Message Control Record and its components are shown below:

SAMPLE MESSAGE LOCATOR

Ř01050213231200011UNIIUDř

where:

Ř0105021323120001ř is the message Control Record

Ř010502ř is the date (yymmdd)

Ř132312ř is the time (hhmmss)

Ř0001ř is the sequence number

Ř1ř is the occurrence of the destination in the PARM-DESC-TABLE-DEST of the parameter list

ŘUNIř is a constant

ŘUDř is the message type

When the responses to the message are received, UNI groups the responses under the same message control record.

This allows an application to identify all the response messages received for a given transaction.

UNI keeps track of all responses, using the message locator field on the messages. It uses the locator to look up the

message control record, which is used to identify the messages belonging to a transaction.

When all expected responses have been received, UNI can notify the site that the transaction is complete. Alternately, a

site may configure UNI to notify the application as each reply is received.

3.5 APPLICATION MESSAGE FILE

Messages leaving or entering a UNI site are recorded in the application message file. The application message file

holds the messages in call list form. The files key provides indexing that groups the messages belonging to a given

transaction. A full description of the file is given in the UNI documentation.

3.6 MESSAGE RETRY

It is recommended that users configure the parameter list of all online update messages to attempt up to three retries in

the event the messages are undeliverable. When set, UNI retry is performed automatically. Users should keep in mind

that automatic retry may not be appropriate for messages where the jurisdiction prefers to control retries either manually

or programmatically through the application (as may be the case with inquiry messages).

The PARM-CNT-RETRY-MAX field in the UNI parameter list controls the maximum number of times that UNI will

attempt to send an outbound message to its destination. This is a 1-digit numeric field (i.e., valid values range from '0'

to '9').

If the number of retries is set to '0' and the outbound message is returned as undeliverable, UNI will not retry the

message. If the number of retries is set to a non-zero value, UNI will hold the message in its undeliverable message file

until such time as UNI determines that the destination's node or application is again available. UNI actively checks the

status of retry destinations and does not attempt a retry until a positive status is attained. UNI checks the status of all

other nodes on the network by issuing IN messages at regular intervals and interrogating the RN responses. The default

interval is 20 minutes, but this is configurable. UNI will attempt to resend until it has exhausted the maximum number




of retries designated.

For most applications, a maximum number of '3' retries should be sufficient and is the recommended value.

3.7 PACING MESSAGES

If a State uses the message pending process to send multiple messages to the CDLIS Central Site, the messages must

Řpacedř to prevent them from negatively impacting system response time. If messages are not paced properly, it is

possible for backups to occur at the State, at NCS, and/or at the CDLIS Central Site. Please contact the AAMVA

Operations Help Desk for proper pacing settings based on your particular installation and line speed.

3.8 HARD MANUAL DOWN

Setting a siteřs status to 'hard manual down' causes UNI to treat a destination node as though it were down even when it

is not. This can be used, for example, when a jurisdiction must store online transactions while it runs its batch

processes. Issuing a hard manual down on the destination node causes online transactions to that node to go to the

message pending process given message retry is configured. Transactions will continue to queue up in message

pending until the hard manual down is manually removed.

Hard manual downs are issued from the UTT200 Network/Application Status screen by adding the site ID of the

destination to be downed to the application status list. First, enter an action code of 'A', the network ID of the

destination, and the appropriate application number. The down reason will be set to 'soft manual' by the system. To

change the down reason to 'hard manual', enter an action code of 'M'. The 'M' action code toggles between a soft and a

hard manual down. To delete a hard manual down, enter an action code of 'D'. Message pending will initiate release of

messages at the next IN/RN interval.

Before issuing a hard manual down, jurisdictions should estimate the amount of space needed to store the message

pending file. Steps should be taken to ensure that enough space will be available to hold the estimated number of

pending messages.

3.9 PURGE CRITERIA FOR UNI LOGS

The UNI files record messages and transactions processed by UNI. If UNI files are not purged in a timely manner, the

files will fill up, causing UNI to abort. In order to prevent a jurisdictionřs production system from failing, the

jurisdiction must estimate its CDLIS volume, calculate at what point its UNI files will become full, and set up its UNI

purge jobs to run at the appropriate intervals. The process for specifying purge criteria is described in the UTB20

Message Control Purge section of the UNI Batch Utilities User Manual. UNI provides a few options in the

configuration of its purge criteria. Jurisdictions may opt to purge UNI files in their entirety or they may set purge

parameters to exclude messages that meet certain criteria.

Jurisdictions may wish to consider using the conditional criteria for the messages used in transactions that may take

more than 8 hours to complete. This can prevent the initial messages in an incomplete transaction from being purged,

then having the response arriving hours later and erroring off because the original data can no longer be found.

A simple yet safe option for the purge criteria is to set the retention age to 4 days for Complete, Incomplete and Errored

transactions, for all message types. If a jurisdiction has issues with the volume of messages in the files, then they may

want to set shorter retention periods for some of the message types. The following transactions contain messages with

specific retention period requirements and care should be taken if a decision is made to shorten their periods:

In a Change State of Record (CD08), the New SOR has 96 hours to post the driver history to its database.

However special retention requirements for the messages in this transaction may not be needed because in UNI

the messages are grouped into 2 sub-transactions. The first includes the messages used up to the point where the

history is posted. The second sub-transaction includes the confirmations sent after the history is posted. So for

many jurisdictions no special retention requirements are needed for this transaction. If a jurisdiction wishes to

coordinate the purge of the two sub-transactions, the Depending Messages option of the purge process can be

used. When an error is detected in the History data, the Old SOR needs to be able to resend the corrected

message. The resent messages will need the control data from the original messages, so jurisdictions may need to

keep some or all of the history messages for 96 hours.

In the Report Out Of State Conviction (CD11), the SOR has 10 days to post the conviction to its database [49

CFR §384.225]. In this case the jurisdiction reporting the conviction sends a Report Out-of-State Conviction




(HA) message within 10 days of the conviction date [49 CFR §384.209] and expects a CS confirmation message.

Jurisdictions may wish to use the conditional purge criteria to keep incomplete Report Out-of-State Conviction

(HA) transactions in their files, so details like the DLN can be retrieved form the Report Out-of-State Conviction

(HA) message. Depending on how the jurisdiction receiving the conviction builds the CA message, it may be

advantageous for the jurisdiction to keep the Forward Out-of-State Conviction (HF) message around while the

conviction is posted.

The Negate Out Of State Conviction (CD12), Report Out Of State Withdrawal (CD16) and Negate Out Of State

Withdrawal (CD17) are similar in their operation to the Report Out Of State Conviction, so a jurisdiction will

probably pick similar purge options for the messages in these transactions.

In the Duplicate Driver Resolution (CDA1) the CDLIS Central Site uses an overnight process to make the

update, so the jurisdictions may wish to hold on to the NA, UC, UE or UG till the NE is returned the next day.

As the NA message may be part of a number of other transactions (UA, UD, UC & UK), these other transactions

may need keeping to preserve the NA.

Application errors must not be purged from the UNI log file until the error is captured offline or the error is

resolved.

3.10 ERROR RESOLUTION

A jurisdiction that receives a message returned with an error must have a process in place to detect and resolve the error.

For UNI jurisdictions, the process involves configuring UNI and may involve the development of application programs.

UNI provides many options for processing errors so a site will need to select the options that best meets its needs and

configure UNI accordingly. Configuring UNI error processing is described in the UNI Application Developers Manual.

If further assistance with the configuration is needed, contact the UNI Help Desk.


4 CDLIS ERROR PROCESSING 13


4 CDLIS ERROR PROCESSING

Whenever a CDLIS message is sent over the AAMVA network from one point to another, it is possible that an error

may be encountered during the transmission or processing of that message. The CDLIS entities that may detect such an

error are:

The CDLIS Central Site application

The CDLIS application at a Jurisdiction or other CDLIS user

The AAMVA-provided ŘUnified Network Interfaceř (UNI) Software at a user site

The Network Control Software (NCS), which controls the AAMVA Network

Any entity that normally receives CDLIS messages must be prepared to detect errors on inbound messages, and, when

errors are found, to insert the required error information into those messages and return them to the message originator.

Any entity that normally sends CDLIS messages must be prepared to receive, process, and resolve any of its messages

that are returned to it with error information.

The error information that must be inserted into a message when an error is found, and the information that must be

interpreted by the message originator when a message is returned with errors, are in the form of:

New values for certain existing data elements within the message, and

One to five Error Description Blocks (25/1) appended to the original message.

The following is a general discussion about the error flags and error messages in CDLIS, as well as the types of errors.

4.1 CDLIS DATA ELEMENTS USED AS ERROR FLAGS OR ERROR CODES

CDLIS has four data elements that contain error processing information:

NCB Error Code (GNCBER) in the NCB Block - A flag indicating whether an error has been detected on a

given message. All entities that detect an error must set this data element accordingly before returning a

message.

Network Status (GNETST) in the NCB Block Ŕ A code indicating the status of the network. Only NCS or UNI

will set this data element when it detects an error. A value of other than blanks or Ř00ř indicates an error

condition. See "APPENDIX D.1 - DATA ELEMENTS"

Processing Status (GPROST) in the MEC Block Ŕ A code indicating the current processing status of the

transaction. A value of other than blanks or Ř00ř indicates that an error condition was encountered. See

"APPENDIX D.1 - DATA ELEMENTS" for valid values, which will be different depending on the entity that

detected the error. NCS does not update this data element.

APPLICATION STATUS (GAPPST) in the NCB Block Ŕ A code indicating the CDLIS application readiness.

A value of other than blank or zero indicates an error condition.

The significance of these codes in resolving errors are discussed in "4.3 TYPES OF ERRORSŗ.

4.2 CDLIS ERROR BLOCK (25/1)

The CDLIS Error Block (25/1) identifies the data element in error. The block also contains a text explanation of the

error.

4.2.1 Number of Blocks

The AMIE message format can support a maximum of 55 blocks within a given message. In most cases, when an error

is encountered, the message can be returned to the originator in its entirety with one or more Error Description Blocks

appended. If the AMIE limit of 55 blocks will be exceeded by appending one or more Error Description Blocks, the

following minimum requirements must be adhered to.

the NCB Error Code (GNCBER), Network Status Indicator (GNETST), Application Status Indicator (GAPPST),

Processing Status Code (GPROST), and/or MEC Match fields must be set as specified in the process detail

section.

at least one Error Description Block must be appended to the message. If this would cause the message to




exceed the AMIE limit of 55 blocks, then the last business block should be removed to accommodate the Error

Description Block.

4.2.2 Error Block Formats

An Error Block (25/1) will use one of three formats:

AMIE

Call List

UNI

The three formats differ only in the contents of the 1st 5 positions within the 61-characters of data in the Error

Description Block (25/1). For all formats, positions 6 and 7 contain a 2-character error code, and positions 8 to 61

contain a text description of the error.

As the network interface for the jurisdiction/user systems, UNI handles the conversion of messages from AMIE block

(network) format to Call List format for incoming messages, and from Call List format to AMIE block format for

outgoing messages. During this process, UNI converts the first 5 characters of error blocks from AMIE to Call List

format, and vice versa. When converting from AMIE to Call List, UNI derives the Element Number from the

combination of the Block Type, Block Subtype, Line Number, and Error Subtype Code. When converting from Call

List to AMIE format, UNI derives the Block Type, Block Subtype and Line Number from the Element Number and the

Error Subtype Code. During this conversion, UNI makes no changes either to the 2-digit Error Code or to the Text

Description in the error block. The following diagram shows the format of a message going from a UNI to a UNI site in

call list (CL) and AMIE formats.

4.2.2.1 AMIE Format

All messages that are transmitted over the AAMVA Network are required to be in AMIE Block format. Error

Description Blocks appended to a message that is in AMIE format should also be in AMIE format.

The format can be identified by the fifth character of the block containing a number. All error blocks sent by the

CDLIS Central Site are in AMIE format. The block format contains:

A pointer to the other AMIE block within the original message that contains the data element that is the primary

cause of the error. This pointer is in the form: Error Block Type (GERBTY), Error Block Sub-type (GERBST)

and Error Block Line Number (GERLIN) are set to the block identifier of the block that contains the element in

error. For errors that are not attributable to a single block within the message, it contains all nines or all zeroes.

The Error Block Line Number (GERLIN) is used when an element occurs multiple times in a message and

identifies which occurrence of the block contains the element in error.

Error Code (GERCOD) is set to a code identifying the error. The number is unique within a given block/block

subtype, thus identifying the data element within the block that was in error.

Error Text (GERMSG) containing the description of the error

4.2.2.2 Call List Format

AMIE messages coming to the user from the AAMVA network are usually converted from AMIE format to a Call List

(GEROUT) format, and processed by the user in that format. This conversion is performed at most user sites by the

AAMVA-provided UNI (Unified Network Interface) software. On the outbound side, UNI similarly converts each

message created by the user in Call List format to AMIE format before sending it over the AAMVA network.




Conversion of the Error Description Blocks from AMIE to Call List format is done by combining the 25/1 Blockřs

ErrorBlockType/Subtype/LineNumber with the 2-digit Error code (GERCOD), and translating that to a 4-digit ŘCall

List Element Numberř together with the same 2-digit Error Code.

The CDLIS Call List is a single COBOL data structure, or its equivalent in another programming language, that can

contain all the data in any CDLIS message. In this Call List, an ŘError Description Blockř is a 61-position data area

within the structure, which may occur zero to 5 times for a single message. Error Description Blocks within a message

that is in Call List format may also be in Call List format.

The first 4 of these positions shall contain a Call List Element Number that points to the data element within the Call

List that caused the error; otherwise it should contain a default value of 9999 or 0000. The 5th

position of the Error

Description Block is blank.

The format can be identified because position 5 contains a space. The block format contains:

The first four positions contain the Error Element Number (GERELN), which is set to the number of the data

element within the Call List that cased the error (see the list of CDLIS Element Numbers below on the 'CDLIS

Call List Element Numbers'; for a list of Error Subtype Codes applicable to each Element, please see the separate

section below on 'Error Description Block -Error Codes and Messages'). The default Error Code (GERCOD)

value is '99', and the default Internal CS Error # value is '9999'. The fifth position is blank.

Error Code (GERCDO) is set to a code identifying the error.

Error Text (GERMSO) containing the description of the error

4.2.2.3 UNI Format

The UNI (GERUEB) format can be recognized by a ŘUř in position 5 (GERUCD) of the Error Description Block, and is

the same regardless of whether the rest of the message is in AMIE or CALL LIST format. Positions 1 through 4 contain

a UNI error code. The errors reported in these blocks are ones that were identified and reported by UNI.

The block format contains:

UNI Error Code (GERUEC) is set to the UNI error (see the UNI documentation for details).

UNI Error Indicator (GERUCD) is set to "U" which identifies the format as a UNI error

Error Sub-Code (GERU2C) is set to a code which provides additional details about the error (see the UNI

documentation for details).

Error Text (GERMSG) containing the description of the error

4.2.2.4 Examples

The different formats of the error blocks are illustrated in examples below. The way to differentiate the formats is to

look at the fifth character of the block:

Format Error (25/1) block1

Meaning

AMIE

(GERPDP)

0910103SSN REQUIRED GERBTY=09; GERBST=1; GERLIN=01; GERCOD =03;

GERMSG=SSN REQUIRED

Call List

(GEROUT)

1605_03SSN REQUIRED GERELN=1605; GERCDO=03=GERCOD; GERMSO=SSN

REQUIRED

UNI

(GERUEB)

0054U01APPLICATION WINDOW

IS CLOSED

GERUEC=0054; GERUCD=U; GERU2C=54; GERMSG =

APPLICATION WINDOW IS CLOSED

1Fifth character is shown in bold, underline font

Appendix C contains the layout for the 25/1 error block. It shows the format for both application and UNI errors (the

UNI error format redefines the application error format). In either event, the error message must be interpreted and

appropriate action taken to correct and/or resend the message.

4.2.2.5 Central Site Error Messages

When the CDLIS Central Site issues an error, it returns the message to the inquirer with the error blocks set to the




appropriate values (up to 5 occurrences). The Central Site Error Messages table below reflects a list of the error codes

generated by the CDLIS Central Site along with the corresponding descriptions.

The table column headings are:

The ŘError Code’ (GERCOD) is the 2-digit error code used in the AMIE-format 25/1 Error blocks that are

appended to messages and sent out by the Central Site. In the Call List format, the Error Code (GERCDO) is

equal to the AMIE-format Error Code (GERCOD) in the 25/1 Error block and is used with the element number

to identify the data element that was in error.

The 'Internal CS Error Number' is the corresponding 4-digit error number used internally at the CDLIS

Central Site that categorizes the type of error, as shown in the following table. The CS error number is shown on

the Central Site System Error file and on the Central Site User Error file.

Types of Internal Central Site Error Numbers

Range of Error #s Type of Error

0001 to 2499 Edit Errors

2500 to 2599 Security Errors

3000 to 3999 Fatal Logic Errors

4000 to 4999 Other Logic Errors

5000 to 5499 Non-Fatal Duplicate Errors

5500 to 5999 Fatal Duplicate Errors

6000 to 9999 System Errors

The 'Error Message' is the text string in the Error 25/1 block that is left-justified in the 55-character Error

Message field and that describes the specific error. The Error Message is unique for each internal CS Error

Number.

Central Site Error Messages

Error Code

(GERCOD)

Internal CS

Error #

Error Message

01 0011 MSG LENGTH <> ACTUAL LENGTH

0028 INVALID USER FEE

0030 INVALID STATE CODE

0051 INVALID NAME COUNT

0060 BLOCK SEQUENCE ERROR

0701 STATE-OF-CONVICTION CODE REQUIRED

0901 STATE-OF-WITHDRAWAL CODE REQUIRED

3000 COMM ADDRESSABILITY NOT ESTABLISHED

02 0013 INVALID DESTINATION

0032 DRIVER LICENSE NUMBER REQUIRED

0056 NAME COUNT DOESNT MATCH NUM NAMES

0702 CITATION DATE REQUIRED

0902 WITHDRAWAL EFFECTIVE DATE REQUIRED





Error Code

(GERCOD)

Internal CS

Error #

Error Message

3001 ERROR GETTING ADDR FOR TM WORK STOR

03 0029 USER FEE IS REQUIRED

0034 SSN REQUIRED

0703 CONVICTION DATE REQUIRED

0903 WITHDRAWAL TYPE DETAIL REQUIRED

3002 ERROR CALLING WAASDATE

04 0014 INVALID ORIGIN

0031 STATE CODE REQUIRED

0704 CONVICTION COURT TYPE REQUIRED

0904 WITHDRAWAL BASIS REQUIRED

3003 ERROR LOADING MESSAGE CONTROL TABLE

05 0033 INVALID SSN

0046 REQUIRED DRIVERS LICENSE COUNT

0705 COMMERCIAL VEHICLE INDICATOR REQUIRED

0905 WITHDRAWAL DUE PROCESS STATUS REQUIRED

3004 ERROR STARTING TRANSACTION

06 0001 INVALID TRANS TYPE

0035 EITHER SSN OR STDLN REQUIRED

0047 INVALID DRIVERS LICENSE COUNT

0706 HAZMAT INDICATOR REQUIRED

0906 ACD WITHDRAWAL REASON CODE REQUIRED

3005 MESSAGE NOT FOUND IN TABLE

5502 INVALID TRANSACTION TYPE

07 0048 REQUIRED SSN COUNT

0707 SOC COURT REPORT ID REQUIRED

0907 WITHDRAWAL ELIGIBILITY DATE REQUIRED

3006 INVALID RETURN CODE FROM MODULE

08 0049 INVALID SSN COUNT

0708 SOC OFFENSE CODE REQUIRED

0908 WITHDRAWAL EXTENT ID REQUIRED

3007 PGM CODE NOT FOUND IN MSG CTRL TBL

09 0036 INVALID DOB

0050 REQUIRED NAME COUNT





Error Code

(GERCOD)

Internal CS

Error #

Error Message

0709 ACD CONVICTION CODE REQUIRED

0909 WITHDRAWAL JURISDICTION REPORT ID REQUIRED

3008 NOTAUTH ERROR DURING LINK

10 0037 DOB REQUIRED

0054 DLN COUNT DOESNT MATCH NUM OF DLNS

0910 WITHDRAWAL REASON REFERENCE REQUIRED

3009 PGMIDERR DURING LINK

11 0038 SEX CODE REQUIRED

0055 SSN COUNT DOESNT MATCH NUM OF SSNS

3010 ACTION CODE NOT FOUND

12 0039 SEX CODE INVALID

0600 PASSWORD RCVD IS NOT VALID PASSWORD

3011 INVAL DATA RECEIVE IN TBL IDX ENTRY

13 0002 AN EXTRA BLOCK RECEIVED IN MESSAGE

0040 INVALID HEIGHT

3012 SIZE ERROR COMPUTING RECORD LENGTH

14 0004 INVALID BLOCK TYPE

0041 REQUIRED HEIGHT

3013 BAD RETURN FROM GROUP NBR GEN PGM

15 0005 STATE ORIGINATING TXN NOT EQUAL SOR

0042 INVALID WEIGHT

0066 INVALID SYSTEM RELEASE CODE

3014 MPR HAS CSOR IN PROG OR FLAG AS DUP

16 0007 INVALID TRANSACTION DATE

0043 REQUIRED WEIGHT

0067 SYSTEM RELEASE CODE REQUIRED

3102 INVAL BLK FOUND IN MSG PROC TBLE

17 0008 INVALID TRANSACTION HOURS

0044 INVALID EYE COLOR

3103 OUT MSG NOT FOUND IN OUT MSG TBL

18 0009 INVALID TRANSACTION MINUTES

0045 REQUIRED EYE COLOR

3104 BLK LIST NOT FOUND IN MSG PROC TBL





Error Code

(GERCOD)

Internal CS

Error #

Error Message

19 0010 INVALID TRANSACTION SECONDS

0052 INVALID NAME

3105 ERR CODE NOT FOUND IN ERR CODE TBL

20 0012 MESSAGE DESTINATION IS REQUIRED

0053 REQUIRED NAME

0720 INVALID STATE-OF-CONVICTION CODE

0920 INVALID STATE-OF-WITHDRAWAL CODE

4000 THE MSTR PTR REC RQSTD NOT ON FILE

21 0015 MESSAGE ORIGIN IS REQUIRED

0721 INVALID CITATION DATE

0921 INVALID WITHDRAWAL EFFECTIVE DATE

4001 SYSTEM ABEND DETECTED

22 0016 INVALID MESSAGE DATE

0722 INVALID CONVICTION DATE

0922 INVALID WITHDRAWAL TYPE

3107 SYSTEM ABEND DETECTED

5004 DUPLICATE CNT GREATER OR EQUAL TO 3

5005 MAX DUPLICATES/MATCHES EXCEEDED

23 0017 INVALID MESSAGE HOURS

0723 INVALID CONVICTION COURT TYPE

0923 INVALID WITHDRAWAL BASIS

24 0018 INVALID MESSAGE MINUTES

0724 INVALID COMMERCIAL VEHICLE INDICATOR

0924 INVALID WITHDRAWAL PROCESS STATUS

25 0019 INVALID MESSAGE SECONDS

0725 INVALID HAZMAT INDICATOR

0925 INVALID WITHDRAWAL ACD REASON CODE

26 0020 INVALID APPLICATION ID

0726 INVALID ACD CONVICTION CODE

0926 INVALID ELIGIBILITY DATE

6000 REQUESTED RECORD NOT FOUND

27 0021 NUMBER OF SEGMENTS MUST BE NUMERIC

0927 INVALID WITHDRAWAL EXTENT ID





Error Code

(GERCOD)

Internal CS

Error #

Error Message

6001 RECORD IS PRESENT BUT SHOULD NOT BE

28 0022 LAST SEGMENT INDICATOR MUST BE Y

0928 INVALID REINSTATEMENT DATE

8000 CDLIS FILES CURRENTLY UNAVAILABLE

29 0023 INVALID NUMBER OF TEXT BLOCKS

8001 RETURN CODE FROM WRITE WAS INVALID

30 0024 NUMBER OF TEXT BLOCKS REQUIRED

8002 BAD LOAD OF USER ID/TXN CODE TABLE

31 0025 INVALID SESSION INDICATOR

8003 BAD LOAD OF MSG PROC TABLE

32 0026 INVALID TEST/PROD INDICATOR

8004 DELETE WAS NOT SUCCESSFUL

33 0027 ERROR INDICATOR IS ON

8005 DATA SET ID ERROR OCCURRED

34 0057 INVALID NCB SEG NUMBER VALUE

8006 ILLOGICAL SEQUENCE OF COMMANDS

35 0058 INVALID XMIT CODE

8007 INVALID REQUEST

36 0059 INVALID BILLING ID

8008 CICS REGION DISABLED

37 0061 STATE ORIGINATING TXN EQUAL SOR

8009 END OF FILE REACHED

38 0062 CHANGE OF STATE NOT ALLOWED ON CHANGE TXN

0100 REQUESTED TXN TYPE INVALID AT CDLIS

8010 GENERIC ERROR

39 0063 PRIMARY AND MAX AKAS PRESENT ON CHANGE TXN

2590 USER ID RCVD NOT VALID CDLIS USER

8011 RECORD NOT FOUND ON FILE

40 0064 IF ST IS PRESENT, SO MUST DLN AND VICE VERSA

0740 SOC AND TRANSACTION ORIGINATOR DO NOT MATCH

0940 SOW AND TRANSACTION ORIGINATOR DO NOT MATCH

2591 USER ID/PASSWORD MISMATCH

8012 DUPLICATE RECORD ON FILE





Error Code

(GERCOD)

Internal CS

Error #

Error Message

41 2592 MSG CODE NOT VALID OR NOT ALLOWED

0741 CITATION DATE MUST NOT BE LATER THAN CONV DATE

0941 EFFEC DATE MUST BE EARLIER THAN ELIG DATE

8013 NO SPACE ON FILE

42 0742 CONV DATE MUST NOT BE LATER THAN MESSAGE DATE

2593 MSG SENT OUTSIDE OF CDLIS PROCESSING WINDOW

8014 DUPLICATE KEY EXIST ON FILE

43 0743 CONV CMV IND MUST = 1 IF CONV HAZMAT IND = 1

0943 INVALID EFFECTIVE DATE FOR WDRAW ACD

8015 SYSYTEM ID ERROR

44 0744 CONV CMV INDICATOR MUST = 1 FOR ACD CONV CODE

0944 REINSTATE DATE MUST NOT BE LATER THAN MESSAGE DATE

8016 ISC INVALID REQUEST

45 0745 CONV HAZMAT IND MUST = 1 FOR ACD CONV CODE

8017 NOT AUTHORIZED

46 0746 CONV HAZMAT IND MUST = 2 OR 9 FOR ACD CONV CODE

For citations on/after January 1, 2008:

CONV HAZMAT IND MUST = 2 FOR ACD CONV CODE

8018 RECORD LENGTH ERROR

47 0747 ACD CONV CODE VALUE REQUIRES BLANK CONV OFF DET

8019 REWRITE WAS UNSUCCESSFUL

48 0748 INVALID CONV OFF DETAIL FOR ACD CONV CODE = A11

8020 BAD CICS UNLOCK COMMAND

49 0749 INVALID CONV OFF DET FOR ACD CONV CODES S01-S91

8021 PROGRAM ILLOGIC IN MESSAGE EDITOR

50 0750 INVALID CONV OFF DETAIL FOR ACD CONV CODE = S92

8022 FILE NEEDED FOR PROCESSING NOT OPEN

8023 BAD TABLE LOAD

51 0751 INVALID CONV OFF DETAIL FOR GIVEN ACD CONV CODE

55 2594 MAX SECURITY EXCEPTIONS EXCEEDED

56 0756 INVALID CITATION DATE FOR CONV ACD

3015 ERROR RETRIEVING MESSAGE

57 3106 BAD RETURN FROM WAASBITX PGM





Error Code

(GERCOD)

Internal CS

Error #

Error Message

58 3108 RC=10 FROM MODULE LINKED TO BY TM

59 3109 RC NE +1 FROM DISCLOSURE MODULE

60 3110 ERROR LOADING WAASDATE FROM TM

61 3111 GROUP NUM NDX TRLR NOT FOUND

62 5006 DUP CNT OF REC IN DUP/UNQ TBL IS 5

63 5504 CDID NOT FOUND ON DUP LIST FOR UG

64 5506 MPR UNQ COUNTER EQUALS 10

65 5508 CDID NOT ON UNQ LIST FOR UE TXN

66 5510 ENQUEUE COUNTERS ARE NOT THE SAME

67 8024 ADDRESSABILITY NOT ESTABLISHED

68 8025 BAD BEGIN BROWSE

69 8026 BAD END BROWSE

70 8027 BAD PROGRAM FUNCTION

71 4002 DUPLICATE ST/DLN ON FILE

72 4003 MASTER POINTER ALREADY ON FILE

73 5514 ATTEMT TO ADD DUP CDID TO DUP LIST

74 3112 INVALID DELETE - CHG SOR IN PROCESS

75 4004 MORE THAN ONE MATCH EXISTS ON FILE

76 4005 PARTIAL MATCH EXISTS ON FILE

77 4006 NO MATCH EXISTS ON FILE

99 0003 A REQUIRED BLOCK IS MISSING

0006 AKA AND PRIMARY CHANGES ENTERED

0065 OLD ST/DLN DOES NOT MATCH THE MPR AKA ST/DLN

3016 MESSAGE RETURNED AS UNDELIVERABLE

3017 INVALID NCB ERROR CODE

3018 OUTBOUND NETWORK ACCESS IS DOWN

3019 MPR DOES NOT INDICATE CHANGE SOR IN PROGRESS

5007 CDID IN NEW MPRS DUP LIST NOT FOUND

6002 MPR AKA NOT MATCHED WITH GRP INDX

9999 TM DETERMINED THAT A280 IS ABENDING

INVALID CHARACTER IN FIELD where 'FIELD' is 'FIRST NAME',

'MIDDLE NAME' or 'LAST NAME' as applicable

LAST NAME REQUIRED

INVALID SPACE AT LEFTMOST POSITION IN FIELD where 'FIELD' is





Error Code

(GERCOD)

Internal CS

Error #

Error Message

'FIRST NAME', 'MIDDLE NAME' or 'LAST NAME' as applicable

INVALID ADJACENT SPACES IN FIELD where 'FIELD' is 'FIRST NAME',

'MIDDLE NAME' or 'LAST NAME' as applicable

INVALID SUFFIX

INVALID SPACE AT LEFTMOST POSITION IN SUFFIX

INVALID ADJACENT SPACES IN SUFFIX

INVALID TRUNCATION IND

INVALID TRANSLITERATION IND

TRUNCATION IND REQUIRED FOR LAST NAME

TRUNCATION IND REQUIRED FOR FIRST NAME

TRUNCATION IND NOT ALLOWED WITHOUT FIRST NAME

TRUNCATION IND REQUIRED FOR MIDDLE NAME

TRUNCATION IND NOT ALLOWED WITHOUT MIDDLE NAME

TRANSLITERATION IND REQUIRED FOR LAST NAME

TRANSLITERATION IND REQUIRED FOR FIRST NAME

TRANSLITERATION IND NOT ALLOWED WITHOUT FIRST NAME

TRANSLITERATION IND REQUIRED FOR MIDDLE NAME

TRANSLITERATION IND NOT ALLOWED WITHOUT MIDDLE NAME

4.2.2.6 Call List Element Error Numbers

When a UNI node returns an error, it uses the Call List-format 25/1 error block. The following list provides a cross-

reference between the data element numbers used in the Call List-format 25/1 error block, to the Data Dictionary

appendix of this specification, to the Call List Name. The list contains columns for:

The ŘCall List Element #ř is the Call List Element Number (GERELN), the four digit number used to identify the

data element in error in the Call List-format 25/1 Error block. The Call List Element Number is functionally

similar to the AMIE-format combination of data elements (Block-type, Block subtype, sequence number, and

Error Code Number)ŕboth identify the data element in error, but if the block type/subtype occurs more than

once in the message or if the data element occurs more than once in the block type/subtype, the Call List format

of the 25/1 Error block cannot identify which occurrence of the data element type is in error.

The ŘData Element Codeř is the code name of the data element used to identify elements in the Data Dictionary

appendix

The ŘCall List Nameř is the data element name in the call list

For most numbers the list includes the corresponding six-character element code and the call list name. On a couple of

lines blanks are shown, where the element number describe components of a group element (e.g., the element code

GMSDAT describes the whole date which has components made up of the year, month, and day).

AAMVA no longer supports the UNI table that converts error numbers to and from block numbers, so UNI will deliver

new errors with the default error number of Ŗ9999ŗ.




Call List Element Numbers, Codes, and Names

Call List Element # Data Element Code Call List Name

0005 GTXNPR CLMF-DESC-NCB-TXN-PROG

0010 GMSLEN CLMF-NUMB-NCB-MSG-LEN

0015 GMSDST CLMF-CODE-MSG-DEST

0020 GMSORG CLMF-CODE-ORIGIN

- GMSDAT -

0025 - CLMF-DATE-NCB-MSG-YY

0030 - CLMF-DATE-NCB-MSG-MM

0035 - CLMF-DATE-NCB-MSG-DD

- GMSTIM -

0040 - CLMF-TIME-NCB-MSG-HH

0045 - CLMF-TIME-NCB-MSG-MM

0050 - CLMF-TIME-NCB-MSG-SS

0055 GMSSEQ CLMF-DESC-NCB-MSG-SEQ-ID

0060 GAPPID CLMF-CODE-NET-APPL-ID

0065 GMSTYP CLMF-CODE-MSG-TYPE

0070 GSGSEQ CLMF-NUMB-NCB-SEG

0075 GLSEGI CLMF-INDC-NCB-LAST-SEG

0080 GNBTXT CLMF-CNT-NCB-NUM-TXT-BLKS

0090 GNETSI CLMF-INDC-NET-SESSION

0095 GXMODC CLMF-CODE-NCB-XMIT-MODE

0100 GTPIND CLMF-INDC-TST-PROD

0105 GNCBER CLMF-CODE-NCB-ERROR

0110 GTRORG CLMF-CODE-NCB-BILLING-ID

0410 GMSCNT CLMF-CNT-MEC-MATCH

0415 GMSIND CLMF-INDC-MEC-MATCH

0420 GMSMSI CLMF-NUMB-MEC-MATCH-SEQ-ID

0425 GPROST CLMF-CODE-MEC-PROCESS-STATUS

0430 GMSLMI CLMF-INDC-MEC-LAST-MATCH

0435 GMSLEI CLMF-INDC-MEC-MATCH-LIMIT-EX

0440 GMSSOR CLMF-CODE-MEC-SOR

0445 GMSPSW CLMF-CODE-MEC-PASSWORD

0450 GMSSCH CLMF-INDC-MEC-CHANGE-SOR

0455 GMSDUP CLMF-INDC-MEC-DUPE-FLAG

0460 GMSPRF CLMF-NUMB-MEC-PROCESS-FEE






0465 GMSCDL CLMF-MEC-CNT-DLN

0470 GMSCSS CLMF-MEC-CNT-SSN

0475 GMSCNM CLMF-MEC-CNT-NAME

0805 DDVNM1 CLMF-NAME-OLD-PRIMARY

0810 DDVNAM CLMF-NAME-CURRENT

0820 DDVNM3 CLMF-NAME-DUPE

0825 DDVKNM CLMF-NAME-AKA1

0830 DDVKN2 CLMF-NAME-AKA2

0835 DDVKN3 CLMF-NAME-AKA3

1005 DDVDO1 CLMF-DOB-OLD-PRIMARY

1010 DDVDOB CLMF-DOB-CURRENT

1015 DDVDO2 CLMF-DOB-DUPE

1020 DDVKDB CLMF-DOB-AKA1

1025 DDVKD2 CLMF-DOB-AKA2

1030 DDVKD3 CLMF-DOB-AKA3

- DDVDS3 CLMF-DESC-INFO-OLD:

1100 DDVDNP CLMF-DATE-PURGE-NAME(1)

1105 DDVSEX CLMF-CODE-SEX(1)

1110 DDVHG1 CLMF-DESC-HEIGHT-FT(1)

1115 DDVHG2 CLMF-DESC-HEIGHT-IN(1)

1120 DDVWGT CLMF-DESC-WEIGHT(1)

1125 DDVEYE CLMF-DESC-EYE-COLOR(1)

- DDVDSC CLMF-DESC-INFO-CURRENT:


1205 DDVSX3 CLMF-CUR-CODE-SEX

- DDVHT3 CLMF-CUR-DESC-HEIGHT



1220 DDVWT3 CLMF-CUR-DESC-WEIGHT

1225 DDVEY3 CLMF-CUR-DESC-EYE-COLOR

- DDVDS2 CLMF-DESC-INFO-DUPE:


1305 DDVSX2 CLMF-DUP-CODE-SEX

- DDVHT2 CLMF-DUP-DESC-HEIGHT








1320 DDVWT4 CLMF-DUP-DESC-WEIGHT

1325 DDVEY2 CLMF-DUP-DESC-EYE-COLOR

1500 DDLJD1 CLMF-CODE-STDLN-OLD-PRIMARY

1505 DDLJDL CLMF-CODE-STDLN-CURRENT

1510 DDLJD5 CLMF-CODE-STDLN-DUPE

1515 DDLJD2 CLMF-CODE-STDLN-AKA1



1600 DDVSS1 CLMF-NUMB-SSN-OLD-PRIMARY

1605 DDVSS6 CLMF-CODE-SSN-CURRENT

1610 DDVSS2 CLMF-CODE-SSN-DUPE

1615 DDVKSS CLMF-CODE-SSN-AKA1

1700 BJUCD1 CLMF-CODE-SOR

1800 GRRECV CLMF-DESC-RETURN-AS-RECEIVED

1900 GEREL9 CLMF-DESC-ERROR-ELEM-NUM

1905 GERCDO CLMF-DESC-ERROR-CODE-OUT

1910 GERMSO CLMF-DESC-ERROR-MSG-OUT

2000 DDLNMP CLMF-NUMB-PERMITS

2005 DDLCL2 CLMF-DESC-CDL-CLASS

2010 DDLEN1 CLMF-DESC-DL-ENDORSE

2015 DDLISS CLMF-DATE-DL-ISSUE

2020 DDLEXP CLMF-DATE-DL-EXPIRE

2025 DDLNTS CLMF-DESC-NON-CDL-STATUS

2030 DDLCTS CLMF-DESC-CDL-STATUS

2035 DDLWDP CLMF-INDC-DL-WDRAW-PEND

2040 DDLNMR CLMF-NUMB-DL-RESTR

2045 DDVMED CLMF-INDC-MED-HX

2055 DDTTCS CLMF-NUMB-CONV-SENT

2060 DDTTCR CLMF-NUMB-CONV-RECORD

2065 DDTTAS CLMF-NUMB-ACC-SENT

2070 DDTTAR CLMF-NUMB-ACC-RECORD

2075 DDTTWS CLMF-NUMB-WDRAW-SENT






2080 DDTTWR CLMF-NUMB-WDRAW-RECORD

2090 DDVCPI CLMF-INDC-CDLIS-POINTER

2200 DDLPC2 CLMF-DESC-PERM-CLASS

2205 DDLEP1 CLMF-DESC-PERM-ENDORSE

2210 DDLPID CLMF-DATE-PERM-ISSUE

2215 DDLPED CLMF-DATE-PERM-EXPIRE

2220 DDLPST CLMF-DESC-PERM-STATUS

2225 DDLRPN CLMF-NUMB-PERM-RESTR

2300 DDVADD CLMF-DRVHIST-MAILING-ADDR

2400 DDVRAD CLMF-DRVHIST-RESIDE-ADDR

2405 DDLRSC CLMF-CODE-LIC-RESTR

2410 DDLRSD CLMF-DATE-LIC-RESTR-END

2415 DDLRSE CLMF-DESC-LIC-EXPL

2500 DDLRP1 CLMF-CODE-P1-RESTR

2505 DDLPD1 CLMF-DATE-P1-RESTR-END

2510 DDLPE1 CLMF-DESC-P1-EXPL







2800 DCVJUR CLMF-CODE-CONV-JUR

2805 DCIDCI CLMF-DATE-CITATION

2810 - CLMF-CODE-CONV-OFFENSE

2820 DCVDCV CLMF-DATE-CONV

2825 DCVCRT CLMF-CODE-COURT-TYPE

2830 DCVCOM CLMF-INDC-COMM-VEHICLE-OFF

2835 DCVHAZ CLMF-INDC-HAZ-MATERIAL-OFF

2840 DCVCLO CLMF-DESC-CONV-OFF-LOC

2845 DCVCOR CLMF-DESC-CONV-OFF-REF

2850 DCVCC2 CLMF-ACD-CONV-OFF

2855 DCVCDA CLMF-ACD-CONV-OFF-DETAIL

2860 DCICHI CLMF-CITATION-CDL-IND






2900 DACJUR CLMF-CODE-ACC-JUR

2905 DACDAT CLMF-DATE-ACC

2910 DACSEV CLMF-INDC-ACC-SEVERITY

2915 DDACOM CLMF-INDC-ACC-COMM

2920 DDAHAZ CLMF-INDC-ACC-HAZ-MAT

2925 DACLOC CLMF-INDC-ACC-LOC

3000 DWDJUR CLMF-CODE-WDRAW-JUR

3005 DWDDWD CLMF-DATE-WDRAW

3010 DWDWDT CLMF-CODE-WDRAW-TYPE

3015 DWDWRS CLMF-CODE-WDRAW-REASON

3020 DWDWDE CLMF-DATE-WDRAW-ELIG

3025 DWDWDR CLMF-DATE-WDRAW-REINST

3030 DWDWEX CLMF-CODE-WDRAW-EXTENT

3035 DWDWLO CLMF-CODE-WDRAW-LOC

3040 DWDWRR CLMF-CODE-WDRAW-REF

3045 DWDWTD CLMF-CODE-WDRAW-DETAIL

4.3 TYPES OF ERRORS

When a node receives a message, the message received may indicate an error was detected during processing of that

message. The error itself may be a network error (e.g., the network switch reports the node to which the message was

sent is down), a system error (e.g., UNI reports a site is not configured for an application), or an application error (e.g., a

siteřs CDLIS program reports a required element is missing).

The following sections are an overview of these types of errors in CDLIS. For each type of error, the discussion

includes the steps required of the processor node when it identifies an error and the steps required by processor node

when it receives a message returned in error.

There are exceptions to these procedures for some messages. See the detailed process descriptions in sections for the

messages that differ.

4.3.1 NETWORK ERRORS

Network errors occur when the origination or destination node drops from the network, the network itself encounters a

failure, or there is a problem with the format of the message. AAMVAnetřs availability requirements minimize

occurrences of this nature, but occasionally a failure does occur.

4.3.1.1 Issuing Network Errors

Network errors are issued by the Network Control Software (NCS). Neither the network interface software (e.g., UNI)

nor the CDLIS application software issues network errors. However, the network interface software must alert the

processing node internally when:

NCS issues an error

the processing node tries to originate a message and the node is not connected to the network

the network is completely down




NCS checks for certain conditions and performs its undeliverable processing if an error is encountered. When this

happens, NCS:

swaps the origin (GMSORG) and destination (GMSDST)

sets the NCB Error Code (GNCBER) to 'U' (message undeliverable)

records the error reason in the Network Status (GNETST) by setting the code to a value other than zero (see

following table)

attempts to return the message to the originator

Error codes that may be set in the Network Status (GNETST) by the NCS

Code Explanation

01 The destination's connection (or terminals in the case of LU2 sites) is not active to the NCS.

02 The destination is not a valid jurisdictional site. This code no longer applies, as all jurisdictions are defined in

the NCS state code table.

03 The destination is not a valid destination (not defined to NCS).

04 The origin is invalid (not defined to NCS).

05 The Message Length field in the NCB contains a value that is less than the minimum (66) or the message length

specified in the NCB and the actual data length computed by the NCS do not match.

06 Applies only when the destination is the NCS (GAP code 'II'). The origin ID and the billing ID do not match.

07 The NCS received an undeliverable message (a 'U' in the NCB Error Code field).

08 The message type received was not IN or IX. Applies only when the destination is NCS (GAP code 'II'). The

only message types that are valid for destination to the NCS are IN or IX.

4.3.1.2 Receiving or Detecting Network Errors

As mentioned above, users must be able to detect a network error (an error indicating the originating node has a

problem or the network is down). When a message is received, the receiving site must check the NCB Error Code

(GNCBER). If the Error Code is set to ŘUř, indicating a network error, the jurisdiction must check the Network Status

Indicator (GNETST) to determine the reason for the error (see table above).

To maintain data integrity, when any condition prevents an update message from being sent and delivered, the message

must be resent later. Inquiry messages may be resent at the discretion of the originating site.

AAMVA's UNI network interface tool offers this functionality. It detects when there is a problem with the originating

node or the network and automatically invokes its message pending process to temporarily store messages. If the

destination node or application is down, UNI detects the error, notifies the originator, and again sets the message(s)

aside for later transmission. Many of the parameters governing this process are configurable by the originating site.

See the UNI documentation for more information.

4.3.2 SYSTEM ERRORS

System errors occur when program problems, database errors, program aborts, system availability issues, or failed

authorization checks are encountered. Many system errors are caused by an incorrect setup of the environment or

incorrect message parameters in the programs. Hence, system errors are common during development, but they should

occur infrequently in production.

System errors may be generated by the network interface or the application. UNI handles both inbound and outbound

system errors. UNI processes system errors according to the options configured in the UNI setup.

4.3.2.1 Issuing System Errors

In accordance with AAMVAnet and CDLIS requirements, a processing node that receives a message must check for

system error conditions. If it detects system error conditions, it must return the original message with the appropriate




indicators to inform the originator of the problem. When returning the message, the node must:

Swap the origin (GMSORG) and destination (GMSDST)

Set the NCB Error Code (GNCBER) to 'Y' (Error detected by application or network interface)

Set the Processing Status (GPROST) to '02' (System error)

Set the Application Status Code (GAPPST) to the appropriate value, if applicable (see valid values as described

earlier in this section and also in the GAPPST entry in "APPENDIX D.1 - DATA ELEMENTS")

Attach a 25/1 error block indicating the error (see the description of the 25/1 error block in Ŗ4.2 CDLIS ERROR

BLOCK (25/1)ŗ)

Attempt to return the message to the originator

UNI can issue errors for the following:

Invalid message types

Failed message origin authorization checks

Message received outside the application's operating hours

The system is unavailable. The Network Status (GNETST) code is set as follows:

o 98 - Network window closed

o 99 - Local network down

Other system errors that may be reported when program or environmental problems occur

The most common UNI error codes (GERUEC) issued for system errors are:

Code Description Meaning

0007 TABLE ENTRY NOT

FOUND

The message origin is unknown to the site receiving the message

0025 ROUTING VALIDATION

ERROR - CANNOT

RECEIVE

A message is sent to a site and the site is not allowed to receive the message

type. Error 0025 is issued when an update message is received during the

inquiry only window

0026 ROUTING VALIDATION

ERROR - CANNOT SEND

The message origin is not allowed to send the message type

0052 ORIGIN/DEST NOT

VALID FOR BRIDGE

UNI cannot match the origin or destination (depending on whether the message

is being sent inbound or outbound) with the values in the UNI bridge table. The

bridge option is used by a site that needs to operate as multiple sites, e.g. the site

that operates the bridge to the Canadian jurisdictions.

0053 APPLICATION IS

CURRENTLY

UNAVAILABLE

A message is received by a site but the application program is unavailable, the

message is normally issued when a message is sent outside of the normal hours

of operation

0054 APPLICATION WINDOW

IS CURRENTLY

CLOSED

A message is sent outside of the hours of operation defined in UNI's Application

table.

The list above does not include every UNI error nor does it include all causes for the errors listed. See the UNI

documentation for complete information.

4.3.2.2 Receiving and Resolving System Errors

When a message is received, the recipient must check the NCB error code (GNCBER), Network Status Indicator

(GNETST), the Processing Status (GPROST), Application Status Code (GAPPST), and the 25/1 error block area of the

message. For a System Error, the NCB Error code is set to ŘYř and the Processing Status (GPROST) is set to Ř02ř.

Inspecting the first five bytes (i.e., characters) of the error block will reveal whether the error is an application error or a

UNI error.




If the fifth byte contains a 'U', the error was issued by UNI. UNI returns the error number in the first four bytes. For

example, the following error block was issued by UNI:

123456789112345678921234567893123456789412345678951234567896123456

0025U25ROUTING VALIDATION ERROR - CANNOT RECEIVE

If the fifth byte does not contain a 'Uř, the error was issued by the CDLIS application. For example, the following error

block was issued by the application:

123456789112345678921234567893123456789412345678951234567896123456

1230112TRANSACTION NOT COMPLETED, CALL THE HELP DESK

Most UNI errors describe a problem with the system that will negatively impact message processing. It is

recommended that the receiving program issue an immediate alert so the problem can be investigated promptly. UNI's

System Error Utility Screen provides a listing of system errors, a detailed description of each error, and its probable

cause (see UNI documentation for details).

4.3.3 APPLICATION ERRORS

Application errors occur when an AAMVAnet nodeřs internal CDLIS application software is unable to process a

message. Up to 5 errors may be reported by an application. For programming efficiency, some errors may not be

checked because of a previous error (i.e., a record is not found check may not be performed if a required search field is

missing). Validations may be performed in a different order than they occur in the specification. Application error

categories are:

Edit errors: Edit or syntax errors are a result of missing or incorrectly formatted data encountered during message

editing

Security errors: Security errors are issued when unauthorized transactions are attempted

Logic errors: Logic errors include situations that preclude normal processing of the message, such as when a

necessary record cannot be found, or a record that should not exist is already present in the system

If any user determines that there are error conditions other than those listed in this specification, please contact

AAMVA so that standard coding can be created to handle all potential conditions.

4.3.3.1 Issuing Application Errors

When an application error is encountered, the recipient should:

Swap the origin (GMSORG) and destination (GMSDST)

Set the NCB Error Code (GNCBER) to 'Y' (Error detected by application)

Set the Processing Status (GPROST) to the appropriate value, if applicable (for valid values, see the GPROST

table in "4.1 CDLIS Data Elements Used as Error Flags or Error Codes" or the GPROST entry in "APPENDIX

D.1 - DATA ELEMENTS")

Set the Application Status (GAPPST) to the appropriate code, if applicable (for valid values, see the GAPPST

table in "4.1 CDLIS Data Elements Used as Error Flags or Error Codes" or the GAPPST entry in APPENDIX

D.1 - DATA ELEMENTS"

Attach up to five 25/1 error blocks describing the error (see the description of the 25/1 error block in Ŗ4.2

CDLIS ERROR BLOCK (25/1)ŗ)

Return the original message or the response

In addition to these error elements, CDLIS also uses some elements in the MEC block to indicate whether a matching

driver record is found for a given inquiry or request. These elements are:

Message Match Indicator (GMSIND) Ŕ a Y/N flag indicating whether a matching driver record was found for a

given inquiry or request

Message Match Sequence ID (GMSMSI) Ŕ a code identifying a given driver record that matches the inquiry,

which allows a set of messages about a given driver to be easily identified

Last Match Indicator (GMSLMI) Ŕ a Y/N flag indicating whether the message contains the last driver record

matching the inquiry or request




The match elements usage varies from message to message; they are described in the processes when they are set.

4.3.3.2 Receiving and Resolving Application Errors

When a jurisdiction receives a message, it must check the NCB Error Code (GNCBER) and check whether the code is

set to ŘYř (an error condition exists). When a message is received with the NCB error code set to 'Y', the receiving

jurisdiction must check the processing Status (GPROST), the Application Status Code (GAPPST), and the 25/1 error

block. To know whether the message contains a system error or an application error the jurisdiction must check the first

several characters of the error block itself. Use the process described above for determining whether a system or

application error has been received. For details about application errors, see the error processing sections in the

following sections that specify the CDLIS transactions.

Jurisdictions that receive a message returned with an application error must detect, capture, and interpret the error and

must take appropriate action to correct and/or resend the message.

4.4 Confirmation Errors

Confirmation messages may be returned in error, but are not shown on the PICs or described in the processing sections.

When any message is returned in error to the CDLIS Central Site, the CDLIS Central Site writes the error message to

the System Error Log (CD2E). Unless indicated otherwise for a specific message, the CDLIS Central Site performs no

further processing of the error message and takes no action on the error message. The AAMVA Operations Help Desk

monitors the System Error Log (CD2E) for messages with error(s) and engages the relevant parties for resolution.

When any message is returned in error to a given participant other than the CDLIS Central Site (Jurisdiction, FMCSA,

Third Party Vendor), the participant must log the message returned in error and engage the relevant parties for

resolution.


5 SYSTEM OPERATION 33


5 SYSTEM OPERATION

5.1 HOURS OF OPERATION

The CDLIS Central Site operation hours, including production and test regions, are posted on the AAMVA website

(www.aamva.org). The CDLIS Central site must be available 24 hours per day, 7 days per week, and 365 days per year.

The Ŗuptimeŗ requirement is to be available 99.9% of operational hours, excluding regularly scheduled maintenance.

Periodic server maintenance should be no more than once per week and no greater than 3 hours per scheduled

maintenance period.

Jurisdiction computer systems must be available to respond to CDLIS queries during the same periods of availability of

the CDLIS Central Site.

5.2 PERFORMANCE REQUIREMENTS

As a distributed information system, the performance specifications for each segment of CDLIS (the jurisdiction

information systems, AAMVAnet, National Driver Registry (NDR), and the CDLIS Central Site) must combine to

produce response times which are consistent with the real-time processing objective of the CDLIS design. The primary

consideration for this objective was providing the jurisdiction's field office officials with the capability to comply with

the CMVSA requirements to query CDLIS and NDR while the CDL applicant stood at the counter.

Since the response times of the CDLIS Central Site, AAMVAnet, and NDR are well defined, the variability of the

round-trip inquiry response time to the originating field office terminal will depend primarily on two factors:

the State of Inquiry's internal elapsed time for processing both the outbound inquiry and the inbound response(s);

and,

a State of Record's elapsed time for processing a status response.

The first factor is a consideration which lies within the State of Inquiry's own province and cannot of course be subject

to the nationwide objectives of CDLIS. The second factor however, represents the foundation of the distributed system

design and is the focus of each State's CDLIS performance requirements. Assuming that the CDLIS inquiry resulted in

a status request being received by a matched driver's State of Record, the actual implementation of the distributed

architecture of CDLIS will be realized when the real-time status response is generated to the State of Inquiry. It is this

State of Record status response portion of the total elapsed time that propels the minimum on-line requirement which all

States must meet.

The performance levels for the CDLIS Central Site, AAMVAnet, and NDR are as follows:

CDLIS Central Site - 1.5 sec - Receipt of the message at the network interface, message processing, transmission

of the response

AAMVAnet - 2.0 sec - Receipt of message at origin's network interface, network traverse time including NCS

processing, arrival of message at destination's network interface

NDR - 2.0 sec - Receipt of the message at the network interface, message processing, and transmission of the

response.

Since each State information system is a unique environment in itself, a single specification which would define a

performance requirement to be met by all the States would have no basis in the CMVSA and would oppose the spirit of

the CDL program. As such, rigid performance guidelines will not be specified for the State information systems. In

order to achieve the overall performance objectives however, the State of Record status response processing times must

be commensurate with the specifications shown above.

5.3 SECURITY REQUIREMENTS

All messages sent to the CDLIS Central Site must have a password. New and existing users of the system must contact

the AAMVA Operations Department to obtain or change their CDLIS password.

When a message is received by the Central Site, additional validation is performed to ensure the message meets security

requirements. The Central Site verifies the Message Originator (GMSORG), Message Sender Password (GMSPSW)

and Message Type (GMSTYP). Messages that fail the security checks are returned to the sender with an error

description.

http://www.aamva.org/


6 CENTRAL SITE LOGICAL DATA MODEL (LDM) 34


6 CENTRAL SITE LOGICAL DATA MODEL (LDM)

This section describes that portion of the Logical Data Model (LDM) for the CDLIS Central Site that supports the

processes described within this document. It is a generic representation of the data maintained at the Central Site and

can be adapted to any physical implementation and environment. The physical data model may include additional

elements, such as a unique identifier representing a driver.

Each data store is assigned a unique, four character identifier. This identifier should not be confused with the four

character identifier used to uniquely identify a given interactive process within the CDLIS application.

The LDM includes the following information about each data store;

A brief description

Attributes

Accesses

Relationships to other data stores

Content

o A distinction is made between content that is required only until all Jurisdictions have implemented

version 5.1 or greater (to support backward compatibility) Ŕ denoted by the term ŖRequired During

Transitionŗ, and

o Content that will be required even after all Jurisdictions have implemented version 5.1 or greater Ŕ

denoted by the term ŖRequiredŗ.

The following is a list of the most commonly used icons and a brief description.

Rectangle with Rounded Corners: Data store

Solid Arrow (into upper left corner of data store): Unique identifier

Grayed Arrow (into right side of data store): Alternate access




6.1 POINTER AND RELATED DATA

CD20 MASTER POINTER

Description:

This data store identifies (points to) the jurisdiction where a person is licensed, was licensed, or was convicted of an

offense while driving a Commercial Motor Vehicle (CMV). Pointer information is captured for the following

individuals:

Drivers who currently possess a Commercial Drivers License (CDL) or CDL permit

Drivers who no longer possess a CDL, but whose records are still subject to the CDLIS data retention

requirements

People convicted of an offense while driving a CMV

For privacy reasons, only a partial Social Security Number is stored on the Central Site.

Unique Identifier:

1. DDLJUR - Driver Licensing Jurisdiction

DDLNUM - Driver License Number

Alternate Accesses:

1. BPESSD Ŕ Person SSN Last 5 Digits

Duplicates possible.

2. Accessed from any associated AKA Name (CD22)

3. Accessed from any associated Duplicate Pointer (CD23)

4. Accessed from any associated AKA ST-DLN (CD24)

The following additional alternate access must be supported until all Jurisdictions have implemented version 5.1 or

greater.

5. BPENGP Ŕ Person Name Group

BPEDOB Ŕ Person Date of Birth


6. DDVSSN Ŕ Driver SSN

Content:

The Master Pointer (CD20) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER

CLEAR NAME / DESCRIPTION (R)equired (R)equired During

Transition

1 DDLJUR JURISDICTION CODE - LICENSING R

2 DDLNUM DRIVER LICENSE NUMBER R

3 DDVSEX DRIVER SEX R

4 GMSSCH MESSAGE SOR CHANGE IN

PROGRESS IND

R

5 DDVSSN DRIVER SOCIAL SECURITY

NUMBER

R

6 BPESSD PERSON SSN LAST 5 DIGITS R




NUM ELEMENT

IDENTIFIER


Transition

7 BPEDOB PERSON DATE OF BIRTH R

8

9 BPENGP PERSON NAME GROUP R

10 DDVSSI DRIVER SSN TYPE R

11 GRCCDT RECORD CREATION DATE R

12 GRCCTM RECORD CREATION TIME R

13 GRCUDT DATE OF LAST UPDATE R

14 GRCUTM TIME OF LAST UPDATE R

Transitional Note:

The following fields are stored on the Master Pointer Record (CD20) for the transitional period only. Once the last state

has implemented CDLIS 5.1, these fields will be removed from the Central Site:

Driver Sex (DDVSEX)

Driver Social Security Number (DDVSSN)




CD22 AKA NAME

Description:

This data store contains AKA Name information.

Unique Identifier:

1. Identifier of the associated parent Master Pointer (CD20)

BPENG3 - Person AKA Name Group

Alternate Accesses:



2. BPENG3 - Person AKA Name Group


Referential Integrity:

1. An AKA Name (CD22) requires an associated parent Master Pointer (CD20) to exist.

Content:

The AKA Name (CD22) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER

CLEAR NAME /

DESCRIPTION

(R)equired (R)equired During

Transition

1 BPENG3 Person AKA Name Group R








CD23 DUPLICATE POINTER

Description:

This data store contains information when a pointer record has been identified as a possible duplicate of another pointer

record.

Unique Identifier:


DDLJU6 - Duplicate Driver Licensing Jurisdiction

DDLNU5 - Duplicate Driver License Number

Alternate Accesses:



2. DDLJU6 - Duplicate Driver Licensing Jurisdiction

DDLNU5 - Duplicate Driver License Number



1. A Duplicate Pointer (CD23) requires an associated parent Master Pointer (CD20) to exist.

Content:

The Duplicate Pointer (CD23) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER


Transition

1 DDLJU6 DUPLICATE LICENSING JURIS

CODE

R

2 DDLNU5 DUPLICATE DRIVER LICENSE

NUMBER

R

3 DCDPUI MASTER POINTER UNIQUE

INDICATOR

R








CD24 AKA ST-DLN

Description:

This data store contains AKA State-Driver License Number information. The AKA ST-DLN Status indicates whether

the ST-DLN record was replaced via the Update AKA Data (CD15) transaction (the status of replaced ST-DLN records

becomes Řinactiveř).

Unique Identifier:


DDLJU2 - Driver Licensing AKA Jurisdiction

DDLNU1 - Driver License AKA Number

Alternate Accesses:



2. DDLJU2 - Driver Licensing AKA Jurisdiction

DDLNU1 - Driver License AKA Number

GRCUDT - Date of Last Update

GRCUTM - Time of Last Update


1. An AKA ST-DLN (CD24) requires an associated parent Master Pointer (CD20) to exist.

Content:

The AKA ST-DLN (CD24) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER


Transition

1 DDLJU2 DRIVER LICENSING AKA JURISDICTION R

2 DDLNU1 DRIVER LICENSE AKA NUMBER R

3 DDLKST AKA ST-DLN STATUS R








6.2 LOG DATA

CD29 MESSAGE LOG

Description:

This data store captures all messages sent and received by the site. It uses the same layout as the UNI Message Log.

CDLIS participants that do not use UNI may define their own layout for this log, but the layout must include, at a

minimum, all data listed below.

The Central Site application may use Message Log data for a variety of processes and functions, such as reporting and

redriving online messages.

The UNI Message Log layout is comprised of UNI control data, network control data, and variable length application

data.

Unique Identifier:

1. GUNLDT - UNI Log Date

GUNLTM - UNI Log Time

GUNLSQ - UNI Log Sequence

Alternate Access:

1. GTPIND - Test/Production Indicator

GAPPID - Application ID

GMSTYP - Message Type

GMSDST - Message Destination

DDLJDL - Driver License Number (part of GUNNFD Ŕ UNI Network Format Data)1


Content:

The Message Log (CD29) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER


Transition

NETWORK MESSAGE LOG HEADER INFORMATION (comprised of the following data elements)

1 GUNOCC UNI OCCURENCE COUNT R

2 GUNLKY UNI MESSAGE LOG RECORD KEY

(comprised of the following data elements)

R

2.a GUNLDT UNI LOG DATE R

2.b GUNLTM UNI LOG TIME R

2.c GUNLSQ UNI LOG SEQUENCE R

1 The specific elements that make up the UNI Network Format Data (GUNNFD) are not represented here because they

vary by message type.




NUM ELEMENT

IDENTIFIER


Transition

3 GUNMOD UNI MODULE NAME R

NETWORK MESSAGE (comprised of the following data elements)

4 B000 NETWORK MESSAGE NCB R

4.a GTXNPR TRANSACTION CODE R

4.b GMSLEN MESSAGE LENGTH R

4.c GMSDST MESSAGE DESTINATION R

4.d GMSORG MESSAGE ORIGIN R

4.e GMSDAT MESSAGE DATE R

4.f GMSTIM MESSAGE TIME R

4.g GMSSEQ MESSAGE SEQUENCE ID R

4.h GAPPID APPLICATION ID R

4.i GMSTYP MESSAGE TYPE R

4.j GSGSEQ SEGMENT SEQUENCE NUMBER R

4.k GLSEGI LAST SEGMENT INDICATOR R

4.l GNBTXT NUMBER OF TEXT BLOCKS COUNT R

4.m GNETSI NETWORK SESSION INDICATOR R

4.n GTPIND TEST/PRODUCTION INDICATOR R

4.o GXMODC TRANSMIT MODE CODE R

4.p GNCBER NCB ERROR CODE R

4.q GTRORG TRANSACTION ORIGINATOR R

4.r GNETST NETWORK STATUS R

4.s GAPPST APPLICATION STATUS R

5 GUNNFD UNI NETWORK FORMAT DATA R




CD2E SYSTEM ERROR LOG

Description:

This data store captures all system errors sent and received by the site. It uses the same layout as the UNI System Error

Log. CDLIS participants that do not use UNI may define their own layout for this log, but the layout must include, at a

minimum, all data listed below.

The UNI System Error Log layout is comprised of UNI control data, header data, and variable length application data.

The application data may be captured in a variety of different formats, depending on the point in time when the system

error is encountered.

Unique Identifier:

1. GUNSED - UNI System Error Date

GUNSET - UNI System Error Time

GUNSES - UNI System Error Sequence Number

Content:

The System Error Log (CD2E) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER


Transition

UNI SYSTEM ERROR HEADER INFORMATION (comprised of the following data elements)

1 GUNSEK UNI SYSTEM ERROR KEY (comprised of

the following data elements)

R

1.a GUNSED UNI SYSTEM ERROR DATE R

1.b GUNSET UNI SYSTEM ERROR TIME R

1.c GUNSES UNI SYSTEM ERROR SEQUENCE

NUMBER

R

2 GUNSER UNI SYSTEM ERROR CODE R

3 GUNNER UNI NATIVE ERROR CODE R

4 GAPPID APPLICATION ID R

5 GMSTYP MESSAGE TYPE R

6 GUNLMD UNI LAST MODULE NAME R

7 GUNLDS UNI LAST DATA STORE R

8 GUNLSC UNI LAST SECTION IN MODULE R

9 GMSCKY MESSAGE CONTROL KEY R

10 GUNFMT UNI MESSAGE FORMAT INDICATOR R

APPLICATION MESSAGE CONTENT (in the format specified by GUNFMT)

11 APPGRP APPLICATION MESSAGE R




6.3 SUPPORTIVE DATA

CD2C PARTICIPANT

Description:

This data store contains information about CDLIS subscribers. The CDLIS Central Site uses it for security and

processing decisions.

Unique Identifier:

1. BJUCDE - Jurisdiction Code

Alternate Access:

1. GMSANI - AAMVAnet Network ID

This key is unique.

Content:

The Participant (CD2C) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER

CLEAR NAME /

DESCRIPTION

(R)equired (R)equired During

Transition

1 BJUCDE JURISDICTION CODE R

2 BJUNAM JURISDICTION NAME R

3 GMSANI AAMVANET NETWORK ID R

4 GMSPSW MESSAGE SENDER

PASSWORD

R








CD2D AUTHORIZED FUNCTION

Description:

This data store identifies specific functionality that a given CDLIS participant is authorized to perform.

Unique Identifier:

1. Identifier of the associated parent Participant (CD2C)

BJUAFN - Authorized Function Code

Required Fields:

BJUAFN - Authorized Function

GMSIRL - Implementation Release Code

GRCCDT - Record Creation Date

GRCCTM - Record Creation Time

GRCUDT - Date of Last Update

GRCUTM - Time of Last Update

Content:

The Authorized Function (CD2D) data store consists of the following data elements:

NUM ELEMENT

IDENTIFIER


Transition

1 BJUAFN AUTHORIZED FUNCTION R

2 GMSIRL IMPLEMENTATION RELEASE

CODE

R






7 INTERACTIVE PROCESS DESCRIPTIONS 46


7 INTERACTIVE PROCESS DESCRIPTIONS

7.1 PROCESS IMPLEMENTATION CHART CONVENTIONS

This section describes the online processes that are performed within CDLIS. For each process, the following

information is provided;

A high level business description of the process

A Process Implementation Chart (PIC) Ŕ graphical, logical representation of the process

A detailed logical description of each sub-process that, taken together, comprise the overall process.

PIC DESCRIPTION:

The PIC shows what occurs within a process and when it occurs. The timeframe and steps for completing the process

are shown in chronological order from the top to the bottom of the chart. Timeframe and triggering event are

documented in the leftmost column of the PIC.

The PIC also reflects the various processors that are involved in performing one or more functions in support of the

overall process. Processors are listed across the top of the chart from left to right. A given processor's responsibilities

are portrayed within the processorřs column boundaries on the PIC.

The flow of information between processors is represented by arrows. A single-headed arrow means one message is

transmitted. A multi-headed arrow means that more than one message may be transmitted.

Each function is labeled with a number that corresponds to a section in the detailed logical description that follows the

PIC. Common functions used by multiple processes are slightly smaller and shaded to differentiate them from process-

specific functions.

ICONS USED:

The following is a list of the most commonly used icons and a brief description.

`

Terminal: Initiating event

Rectangle: Manual, interactive, or automated function

Shaded Rectangle with Solid Border: Called common process

Shaded Rectangle with Dashed Border: Called common process

Media Symbol: Automated file or database

Solid Arrow: Inquiry, update, or response message flow

Dashed Arrow: Error message flow

Dotted Arrow: Call to common process

Grayed Arrow: Automated file transfer

7.2 NAME COMPARISON

The algorithm used to compare name information at the CDLIS Central Site varies over time, as dictated by the needs of

the system to provide more accurate results. This section describes the minimum standard for accuracy.

Given two names, positions 1 - 5 of the respective Person Last Name (BPENLT) fields, excluding spaces and all other

non-alpha and non-numeric characters, must match. If there are fewer than 5 characters in the last names, the entire last

names must match.

Transitional Note:

Given a Driver Name (DDVNAM) and a Person Name Group (BPENGP), identify the last name in the Driver Name




(DDVNAM). See ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ for information on how to

identify the last name when the AAMVA Person Name Format is used. Positions 1 - 5 of the Driver Name

(DDVNAM), excluding spaces, periods, hyphens, and single quotes, must match positions 1 - 5 of the Person Last

Name (BPENLT) associated with the Person Name Group (BPENGP), excluding spaces and all other non-alpha and

non-numeric characters. If there are fewer than 5 characters in the last names, the entire last names must match.

7.3 COMMON PROCESS DESCRIPTIONS

To support maintainability and consistency across processes, functionality that is performed by more than one

transaction is described in a single Řcommonř section that is referenced wherever it is used.

The table below shows which common processes are performed by which transactions:

Transaction Legend Common Process Legend

CD01 Search Inquiry CDA1.1 Identify Possible Duplicate Drivers

CD02 Verification Inquiry CDA1.3 Process Resolved Duplicates

CD03 State-to-State Status Request CDB1 Process Status Received

CD04 State-to-State History Request CDC1 Assist in Error Resolution

CD05 AKA Data Inquiry CDD1 Resolve Status Errors

CD06 Employer Inquiry CDE1 Resolve History Errors

CD07 Add New Driver CDF1 Create AKA from Update Message

CD08 Change State of Record CDG1 Create AKA from Master Pointer Data

CD09 Change Data CDH1 Search Inquiry Retrieval

CD10 Delete Master Pointer Record CDI1 Provide Detail on Requested Driver

CD11 Report Out-of-State Conviction CDJ1 Authorization, Implementation Verification

CD12 Negate Out-of-State Conviction CDL1 Process History Request

CD14 Mark Driver Unique CDM1 Process History Response

CD15 Update AKA Data CDN1 Apply Common Validations

CD16 Report Out-of-State Withdrawal

CD17 Negate Out-of-State Withdrawal

CD18 Minimal Data Driver Search Inquiry




Common Processes

Tra

nsa

ctio

ns

CDA1.

1

CDA1.

3

CDB1 CDC1 CDD1 CDE1 CDF1 CDG1 CDH1 CDI1 CDJ1 CDL1 CDM1 CDN1

CD01 X X X X X X

CD02 X X X X X

CD03 X

CD04 X X X X

CD05 X X X X X X

CD06 X

CD07 X X X

CD08 X X X X X X X

CD09 X X X X X

CD10 X X

CD11 X

CD12 X

CD14 X X

CD15 X X X

CD16 X

CD17 X

CD18 X




7.4 BACKWARD COMPATIBILITY DURING TRANSITION

The primary goal of CDLIS Modernization (Release 5.1) is to transition the Central Site to newer technology. However,

it also includes several functional improvements and enhancements that impact both the Central Site and other CDLIS

users. The following applies to all users, but talks in terms of jurisdictions (states), since they make up the majority of

users.

The modernized CDLIS will be implemented over a period of time. As with past releases, there will not be a

simultaneous 'cutover' for all jurisdictions. Rather, once the Central Site is moved to production (the 'go live' date), each

state will implement the new 5.1 functionality as it completes the required coding and structure testing.

The modernized Central Site solution is designed to accommodate all jurisdictions during a 'transition period' that

begins when the first state implements and ends when the last state implements. During the transition period, the

Central Site must be backwards compatible for states that have not implemented, meaning it must function no

differently than it did before. Simultaneously, it must perform new functions for states that have implemented the new

5.1 changes.

Although the objective is to minimize changes to jurisdictions, achieving truly transparent backwards compatibility

means that both the Central Site and states who have implemented the 5.1 changes must perform some functions that

will no longer be necessary once the last state comes on board. This transitional functionality will be removed as part of

the first release that takes place after the transition period ends.

In the meantime, the 5.1 specification must describe the functionality needed to accommodate all users during the

transition period. Where applicable, functionality based on the implementation status of a given participant is clearly

denoted. Functionality specific to the transition period is also clearly denoted.



CD01 SEARCH INQUIRY


CD01 SEARCH INQUIRY

Business Process Overview

Description

The Search Inquiry is a request for a driverřs Master Pointer Record (MPR) and license status. The transaction enables

the inquirer to determine whether a driver already exists on the CDLIS Central Site. It is used when it is not known

whether a given individual is on the CDLIS Central Site. The Search Inquiry retrieves driver records that match, exactly

or approximately, on any of the search fields. The Search Inquiry is a broader inquiry than the Verification Inquiry.Ref1

The Search Inquiry may be implemented using one of two message types, both of which are identical, except for the

message type name. Message type names are used for transaction reporting, to keep track of the purpose of the

inquiries used. For jurisdictions who want to track and/or report on Search Inquiries conducted prior to adding a new

driver, for example, the Search Inquiry Preceding an Add Driver (IO) message may be used. The message types

defined for the Search Inquiry are the following:

Search Inquiry Preceding an Add Driver (IO)

All other uses of the Search Inquiry (IM)

Participants

State of Inquiry (SOI)

o U.S. jurisdiction

CDLIS Central Site

State of Record (SOR)

o U.S. jurisdiction

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending a Search Inquiry message to the CDLIS Central Site.

Upon receipt of the Search Inquiry, the CDLIS Central Site:

o Validates the driver identification information in the message

o Retrieves MPRs that match, exactly or approximately, on any of the search fields provided

o Returns information from the Central Site to the inquirer

o If one, and only one, record is retrieved and the driverřs SOR is not also the inquirer, the CDLIS Central

Site sends a status request message to the SOR. If the driverřs SOR is the inquirer, there is no need to

send a status request because the inquirer can check its own Driver History Record (DHR).

Upon receipt of the status request message, the SOR:

o Validates the message data

o Retrieves the DHR

o Returns status information* to the inquirer

* If the SOR has implemented the Medical Certificate requirements, the status information includes information

pertaining to the driverřs medical certificate, where available.

Upon receipt of the status information from the SOR, the inquirer checks the messages for errors.

Inputs

The Search Inquiry includes the driverřs name and date of birth. It may optionally include the licensing jurisdiction code

and driver's license number combination, the driver's Social Security Number, and up to three AKA names.

If the driverřs Social Security Number is provided as input, the State must first verify the driverřs name, date of birth



CD01 SEARCH INQUIRY


and Social Security Number combination with the Social Security Administration (SSA).

Outputs from Standard Processing

Central Site to the inquirer:

o The Central Site returns information on the number of matches found, along with the MPR data for each

match, up to 15 drivers. Only those AKA fields essential in determining the match are returned (unlike

the AKA Data Inquiry,Ref2

which returns all AKA fields).

Central Site to the SOR:

o When there is one, and only one, match, the Central Site sends driver identification information to the

SOR for lookup

SOR to the inquirer:

o The SOR sends the driverřs history status data (i.e. data identifying and describing the driver, including

driving privileges with associated dates and contact details) and permit restrictions

Error ProcessingRef3

Central Site

o If the Search Inquiry does not pass the edit validations performed by the CDLIS Central Site, the Central

Site returns an error to the inquirer. No further processing is performed.

SOR

o If the SOR cannot locate the driver upon receipt of a status request, the SOR returns an error to the

CDLIS Central Site.

Inquirer

o If a response from the SOR does not pass the edit validations performed by the inquirer, the inquirer

returns an error to the SOR.

Post-Requisites

If more than 15 matches are found and none of the first 15 matches returned can be determined with certainty to

be the driver in question, the inquirer can change the search criteria to reduce the number of matches (e.g.,

eliminate AKA data).

The inquirer evaluates the status information and permit restriction information (if applicable) and considers

them when deciding on future courses of action.

References

Reference

#

Document Section Notes

Ref1 CDLIS System

Specifications

CD02 VERIFICATION INQUIRY

Ref2 CDLIS System

Specifications

CD05 AKA DATA INQUIRY

Ref3 CDLIS System

Specifications




CD01 SEARCH INQUIRY


Standard Processing Messages

Message Type Message Name Cardinality

IM Search Inquiry

IO Search Inquiry Preceding Add New Driver

RC Number of Status Responses from Inquiry 1

RD MPR Data for Match on Inquiry Transaction 0 - 15

SC Status Request 0 - 1

HC Status Response 0 - 1

H6 Permit Restrictions 0 - 1



CD01 SEARCH INQUIRY


CD01.1 Request Search for Driver (State of Inquiry (SOI))

CD01.1.1 Introduction

The Search Inquiry (IM) message initiates a broad search that returns a driverřs status if exactly one match is found by


The Search Inquiry Preceding Add New Driver (IO) message functions exactly the same as a Search Inquiry (IM)

message. The Search Inquiry Preceding Add New Driver (IO) message was originally intended to be sent prior to

initiating the Add New Driver (CD07) process, but may be sent prior to any CDLIS transaction. The Search Inquiry

(IM) and Search Inquiry Preceding Add New Driver (IO) messages are identical and may be used interchangeably. All

references in this document are to the Search Inquiry (IM) message.

CD01.1.2 Transmission of Search Inquiry (IM) Message

The Search Inquiry (IM) message must include:

Message Sender Password (GMSPSW) set to the password assigned to the message originator.

Driver Date of Birth (DDVDOB) set to the driver's date of birth

Person Name Group (BPENGP) set to the driver's name

The Search Inquiry (IM) message may optionally include:

Driver License Jurisdiction Number (DDLJDL) set to the issuing jurisdiction code and driver's CDL number

Driver SSN - CDLIS (DDVSS6) set to the driver's Social Security Number

Driver AKA Date of Birth (DDVKDB) set to another date of birth the driver may have used

Driver AKA 2nd Date of Birth (DDVKD2) set to another date of birth the driver may have used

Driver AKA 3rd Date of Birth (DDVKD3) set to another date of birth the driver may have used

Return as Received Text/Block (GRRECV) set to any value desired by the State of Inquiry (SOI)

The first occurrence of Person AKA Name Group (BPENG3) set to the first name by which the driver may be

known other than the current name

The second occurrence of Person AKA Name Group (BPENG3) set to the second name by which the driver may

be known other than the current name

The third occurrence of Person AKA Name Group (BPENG3) set to the third name by which the driver may be


Note: If AKA Name and AKA DOB is transmitted, each AKA Name must be paired with an AKA Date of

Birth. The first occurrence must be populated before the second occurrence, which must be populated before the

third occurrence.

See ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for remaining NCB (00/0) and MEC (02/2) block

values.

CD01.2 Research Driver (CDLIS Central Site)

CD01.2.1 Reception of Search Inquiry (IM) Message

Upon receipt of a Search Inquiry (IM) message from an inquirer, the CDLIS Central Site initiates validation processing.

The Central Site may alternatively receive a Search Inquiry Preceding Add New Driver (IO) message, which is

processed in the same way as a Search Inquiry (IM) message.

CD01.2.2 Validation on Received Message

The CDLIS Central Site performs the following validations on the Search Inquiry (IM) message. If errors are detected,

the Central Site stops processing and returns the original message to the sender with error fields set. The sender must



CD01 SEARCH INQUIRY


correct the errors and resend the Search Inquiry (IM) message. Up to five validation failures may be reported on a single

error message. The Central Site must report as many problems as it can to minimize the number of resends.

Validate the password and determine the implementation status of the State of Inquiry (SOI) by performing ŘCDJ1.2

Verification of Message Originatorř using the following input:

Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Search Inquiry (IM) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Search

Inquiry (IM) message

Authorization Function (BJUAFN) set to ŖIMŗ

Implementation Release Code (GMSIRL) set to Ŗ51ŗ

CD01.2.2.1 System Errors

See Ŗ4 CDLIS ERROR PROCESSINGŗ for information on returning system errors.

CD01.2.2.2 Required Data Errors

For all States of Inquiry (SOI), regardless of the version implemented:

Driver Date of Birth (DDVDOB) must be present.

Error Text: 'DOB REQUIRED'

For those States of Inquiry (SOI) at version 5.1 or greater:

At least one component field of Person Name Group (BPENGP) must be present

Error Text: 'REQUIRED NAME'

For those States of Inquiry (SOI) at a version older than 5.1:

Driver Name (DDVNAM) must be present


CD01.2.2.3 Invalid Data Errors


Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL), if present, must contain one of the valid

values in the "United States" list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID STATE CODE'

Driver Date of Birth (DDVDOB) must be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID DOB'

Driver SSN - CDLIS (DDVSS6), if present, must pass the following validations:

Must be numeric

Positions 1 - 3 must be between Ř000ř and Ř999ř, inclusive



Error Text: 'INVALID SSN'



CD01 SEARCH INQUIRY


Driver AKA Date of Birth (DDVKDB), if present, must be a valid date and formatted as specified in



Driver AKA 2nd Date of Birth (DDVKD2), if present, must be a valid date and formatted as specified in



Driver AKA 3rd Date of Birth (DDVKD3), if present, must be a valid date and formatted as specified in




Person Name Group (BPENGP) must conform to the requirements listed in "APPENDIX E.3 - AAMVA

PERSON NAME STANDARD (2008) VALIDATIONS"

See "APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008)

VALIDATIONS" for specific error text associated with this error.

If at least one component field of the first occurrence of Person AKA Name Group (BPENG3) is present, then

the first occurrence of Person AKA Name Group (BPENG3) must conform to the requirements listed in

"APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008) VALIDATIONS"



If at least one component field of the second occurrence of Person AKA Name Group (BPENG3) is present, then

the second occurrence of Person AKA Name Group (BPENG3) must conform to the requirements listed in




If at least one component field of the third occurrence of Person AKA Name Group (BPENG3) is present, then

the third occurrence of Person AKA Name Group (BPENG3) must conform to the requirements listed in





Driver Name (DDVNAM) must conform to the requirements listed in "APPENDIX E.1 Ŕ AAMVA PERSON

NAME FORMATTING RULES"

Error Text: 'INVALID NAME'

Driver AKA Name (DDVKNM), if present, must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ

AAMVA PERSON NAME FORMATTING RULESŗ


Driver AKA 2nd Name (DDVKN2), if present, must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ





CD01 SEARCH INQUIRY


Driver AKA 3rd Name (DDVKN3), if present, must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ



CD01.2.2.4 Data Cross-Check Errors


If positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) contain a value, then positions 3 - 27

must also contain a value.

Error Text: 'IF ST IS PRESENT, SO MUST DLN AND VICE VERSA'





If Driver AKA Date of Birth (DDVKDB) is present, at least one component field of the first occurrence of

Person AKA Name Group (BPENG3) must also be present.


If at least one component field of the first occurrence of Person AKA Name Group (BPENG3) is present, Driver

AKA Date of Birth (DDVKDB) must also be present.


If Driver AKA 2nd Date of Birth (DDVKD2) is present, at least one component field of the second occurrence of



If at least one component field of the second occurrence of Person AKA Name Group (BPENG3) is present,

Driver AKA 2nd Date of Birth (DDVKD2) must also be present.


If Driver AKA 3rd Date of Birth (DDVKD3) is present, at least one component field of the third occurrence of



If at least one component field of the third occurrence of Person AKA Name Group (BPENG3) is present, Driver

AKA 3rd Date of Birth (DDVKD3) must also be present.



If the Driver AKA Date of Birth (DDVKDB) is present, Driver AKA Name (DDVKNM) must also be present.


If the Driver AKA Name (DDVKNM) is present, Driver AKA Date of Birth (DDVKDB) must also be present.




CD01 SEARCH INQUIRY


If the Driver AKA 2nd Date of Birth (DDVKD2) is present, Driver AKA 2nd Name (DDVKN2) must also be

present.


If the Driver AKA 2nd Name (DDVKN2) is present, Driver AKA 2nd Date of Birth (DDVKD2) must also be

present.


If the Driver AKA 3rd Date of Birth (DDVKD3) is present, Driver AKA 3rd Name (DDVKN3) must also be

present.


If the Driver AKA 3rd Name (DDVKN3) is present, Driver AKA 3rd Date of Birth (DDVKD3) must also be

present.


CD01.2.3 Retrieval

If the Search Inquiry (IM) message is valid, perform the ŖCDH1 SEARCH INQUIRY RETRIEVAL (CDLIS

CENTRAL SITE)ŗ common process.

If the CDLIS Central Site finds exactly one Master Pointer (CD20) match and the Jurisdiction Code - Licensing

(DDLJUR) on the CD20 record does not equal the Message Originator (GMSORG) on the Search Inquiry (IM)

message, the CDLIS Central Site determines the implementation status of the State of Record (SOR) by performing

ŘCDJ1.3 Verification of Additional Transaction Participant' using the following input;

Jurisdiction Code (BJUCDE) set to the Jurisdiction Code Ŕ Licensing (DDLJUR) on the CD20 record

Authorization Function (BJUAFN) set to ŖSCŗ


CD01.2.4 Transmission

Once retrieval is complete based on the search criteria submitted in the inquiry, the CDLIS Central Site creates and

sends response message(s) to the inquirer along with a request for status to the State of Record (SOR) where there is a

single match.

CD01.2.4.1 Transmission of Number of Status Responses from Inquiry (RC) Message

The Central Site returns a single Number of Status Responses from Inquiry (RC) message indicating how many matches

were found. This match count equals the number of MPR Data for Match on Inquiry Transaction (RD) messages that

will be sent. If there are zero matches, the Number of Status Responses from Inquiry (RC) message is the only response

to the State of Inquiry (SOI) and the transaction is considered complete.

The Number of Status Responses from Inquiry (RC) must include:


Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Search Inquiry (IM)

message

Processing Status (GPROST) set to Ř00ř

Message Match Count (GMSCNT) set to the number of matching Master Pointer (CD20) records being

sent ('00' - '15')

Message Match Indicator (GMSIND) set to 'Y' if at least one matching Master Pointer (CD20) record is

found; otherwise set to 'N'



CD01 SEARCH INQUIRY


Message Match Sequence ID (GMSMSI) set to Ř01ř

Last Match Indicator (GMSLMI) set to 'Y' if there are zero to 1 matching Master Pointer (CD20) records;

otherwise set to ŘNř

Message Match Limit Exceeded Indicator (GMSLEI) set to 'Y' if more than 15 matches are found;


Message SOR Change in Progress Indicator (GMSSCH) set to 'N' if there are no matching Master Pointer

(CD20) records; otherwise set to the Message SOR Change in Progress Indicator (GMSSCH) of the first

matching CD20 record

Driver Duplicate Indicator (GMSDUP), set to ŘNř if:

o There are no matching Master Pointer (CD20) records; or

o The first matching CD20 record has no associated Duplicate Pointer (CD23) records; or

o All associated CD23 records for the first matching CD20 record have Master Pointer Unique

Indicator (DCDPUI) equal to ŘUř (Mark Unique Complete)

Driver Duplicate Indicator (GMSDUP), set to ŘYř if:

o The first matching CD20 record has at least one associated Duplicate Pointer (CD23) record with

Master Pointer Unique Indicator (DCDPUI) equal to ŘDř (Possible Duplicate) or ŘPř (Mark Unique

Pending)

The Number of Status Responses from Inquiry (RC) message may optionally include:


Jurisdiction Code - State of Record (GMSSOR) set to spaces if no Master Pointer (CD20) matches are

found; otherwise set to the Jurisdiction Code - Licensing (DDLJUR) of the first matching CD20 record

If at least one matching Master Pointer (CD20) record is found, the first occurrence of State of Record

(BJUCD1) is set to the Jurisdiction Code - Licensing (DDLJUR) of the first matching CD20 record; the

second occurrence of State of Record (BJUCD1) is set to the Jurisdiction Code - Licensing (DDLJUR) of

the second matching CD20 record and so forth up to a maximum of 15 occurrences

Return as Received Text/Block (GRRECV) set to the value(s) on the original message, if present (up to 5

occurrences are returned in the order received)


values.

CD01.2.4.2 Transmission of MPR Data for Match on Inquiry Transaction (RD) Message(s)

One MPR Data for Match in Inquiry Transaction (RD) message is returned for each match found on the Master Pointer

(CD20) data store.

The MPR Data for Match in Inquiry Transaction (RD) must include:


Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Search Inquiry (IM)

message



sent ('00' - '15')

Message Match Indicator (GMSIND) set to 'Y'

Message Match Sequence ID (GMSMSI) set to the number representing the order in which the record was

identified as a match ('00' - '15')

Last Match Indicator (GMSLMI) set to 'Y' if the record is the final one returned; otherwise set to 'N'


otherwise set to 'N'



CD01 SEARCH INQUIRY


Message AKA DLN Count (GMSCDL) set to the number of AKA ST-DLN (CD24) records being sent on

the message, up to a maximum of 3

Message AKA Name Count (GMSCNM) set to the number of AKA Name (CD22) records being sent on



Message AKA SSN Count (GMSCSS) set to spaces because AKA SSN is no longer stored at the Central

Site

The MPR Data for Match in Inquiry Transaction (RD) message must include the following from the Master Pointer

(CD20) record:


Driver License Jurisdiction Number (DDLJDL) set to the CD20 Jurisdiction Code - Licensing (DDLJUR)

concatenated with the CD20 Driver License Number (DDLNUM)

Jurisdiction Code - State of Record (GMSSOR) set to the CD20 Jurisdiction Code - Licensing (DDLJUR)

Message SOR Change In Progress Indicator (GMSSCH)

Driver Date of Birth (DDVDOB)


The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) set to the CD20 Person SSN Last 5 Digits

(BPESSD)

Person Name Group (BPENGP) set to the CD20 Person Name Group (BPENGP)


Driver Name (DDVNAM) set to the CD20 Person Name Group (BPENGP) converted into the format

specified in ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ

Driver SSN - CDLIS (DDVSS6) set to the CD20 Driver Social Security Number (DDVSSN)

Driver Current Sex (DDVSX3) set to the CD20 Driver Sex (DDVSEX)

The MPR Data for Match in Inquiry Transaction (RD) message must also include:


Driver Duplicate Indicator (GMSDUP), set to ŘNř if:

o The CD20 has no associated Duplicate Pointer (CD23) records; or

o All associated CD23 records have Master Pointer Unique Indicator (DCDPUI) equal to ŘUř (Mark

Unique Complete)


o The CD20 record has at least one associated Duplicate Pointer (CD23) record with Master Pointer

Unique Indicator (DCDPUI) equal to ŘDř (Possible Duplicate) or ŘPř (Mark Unique Pending)

The MPR Data for Match in Inquiry Transaction (RD) message must include the following from the three most recent

AKA Name (CD22) records (based on Date of Last Update (GRCUDT) and Time of Last Update (GRCUTM))

associated with the CD20 record, where present and used to determine the match:


The first occurrence of Person AKA Name Group (BPENG3) set to the most recent CD22 Person AKA

Name Group (BPENG3)

The second occurrence of Person AKA Name Group (BPENG3) set to the second most recent CD22

Person AKA Name Group (BPENG3)

The third occurrence of Person AKA Name Group (BPENG3) set to the third most recent CD22 Person

AKA Name Group (BPENG3)



CD01 SEARCH INQUIRY



The Driver AKA Name (DDVKNM), set to the most recent CD22 Person AKA Name Group (BPENG3)

converted into the format specified in ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING

RULESŗ

The Driver AKA 2nd Name (DDVKN2), set to the second most recent CD22 Person AKA Name Group

(BPENG3) converted into the format specified in ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME

FORMATTING RULESŗ

The Driver AKA 3rd Name (DDVKN3), set to the third most recent CD22 Person AKA Name Group


FORMATTING RULESŗ


AKA ST-DLN (CD24) records associated with the CD20 record, where present, the AKA ST-DLN Status (DDLKST)

= ŘAř, and used to determine the match:


AKA Driver License Jurisdiction Number (DDLJD2) set to the AKA Jurisdiction Code - Licensing

(DDLJU2) concatenated to the AKA Driver License Number (DDLNU1) of the most recent CD24

AKA 2nd Driver License Jurisdiction Number (DDLJD3) set to the AKA Jurisdiction Code - Licensing

(DDLJU2) concatenated to the AKA Driver License Number (DDLNU1) of the second most recent CD24

AKA 3rd Driver License Jurisdiction Number (DDLJD4) set to the AKA Jurisdiction Code - Licensing

(DDLJU2) concatenated to the AKA Driver License Number (DDLNU1) of the third most recent CD24


values.

CD01.2.4.3 Transmission of Status Request (SC) Message

One Status Request (SC) message is sent if:

The CDLIS Central Site finds exactly one Master Pointer (CD20) match and

The Jurisdiction Code - Licensing (DDLJUR) on the CD20 record does not equal the Message Originator

(GMSORG) on the Search Inquiry (IM) message

The Status Request (SC) message must include:

For all States of Record (SOR), regardless of the version implemented:


Message Match Sequence ID (GMSMSI) set to '01'

The Status Request (SC) message must also include the following from the CD20 record:


Message Destination (GMSDST) set to the Jurisdiction Code - Licensing (DDLJUR) on the Master

Pointer (CD20)



Driver Date of Birth (DDVDOB) set to the CD20 Driver Date of Birth (DDVDOB)

If both the State of Inquiry (SOI) and the State of Record (SOR) are at version 5.1 or greater:


The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) set to the CD20 Person Last 5 Digits (BPESSD)

If the State of Inquiry (SOI) is at a version older than 5.1 and the State of Record (SOR) is at a version 5.1 or

greater:




CD01 SEARCH INQUIRY




If the State of Record (SOR) is at a version older than 5.1, regardless of the version that the State of Inquiry

(SOI) is implemented:






values.

CD01.2.4.4 Transmission of Search Inquiry (IM) Message with Errors

If the CDLIS Central Site encounters errors on the original Search Inquiry (IM) message that preclude further

processing, the Central Site returns the original Search Inquiry (IM) message to the inquirer with Error Block appended

(up to 5 occurrences).

If the Search Inquiry Preceding Add New Driver (IO) message was received instead of the Search Inquiry (IM)

message, the Central Site returns the original Search Inquiry Preceding Add New Driver (IO) message to the inquirer

with Error Block appended (up to 5 occurrences).

See Ŗ4 CDLIS ERROR PROCESSINGŗ for information on formatting error messages.

See ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for remaining elements in the NCB (00/0) and MEC

(02/2) blocks.

CD01.3 Provide Detail on Requested Driver (State of Record (SOR))

Upon receipt of the Status Request (SC) message, the SOR performs the ŖCDI1 PROVIDE DETAIL ON

REQUESTED DRIVER (STATE OF RECORD (SOR))ŗ process.

CD01.4 Process Status Received (State of Inquiry (SOI))

Once an inquiry has been sent to the CDLIS Central Site, the SOI performs the ŖCDB1 PROCESS STATUS

RECEIVED (STATE OF INQUIRY (SOI))ŗ process.

CD01.5 Assist in Error Resolution (CDLIS Central Site)

Upon receipt of a Status Request (SC) message in error, the CDLIS Central Site performs the ŖCDC1 Assist in Error

Resolution (CDLIS Central Site)ŗ process.

CD01.6 Resolve Status Errors (State of Record (SOR))

If errors are encountered on the Status Response (HC) message or the Permit Restrictions (H6) message, the message

containing the errors is returned to the originator of the Status Response (HC) message or the Permit Restrictions (H6)

message (i.e., the SOR) with the NCB Error Code (GNCBER) set to 'Y' and the error(s) identified. The SOR performs

the ŖCDD1 RESOLVE STATUS ERRORS (STATE OF RECORD (SOR))ŗ process.







Description

The Verification Inquiry is a request for a driverřs Master Pointer Record (MPR) and license status. The transaction

enables an inquirer to verify the existence of a given driver. The Verification Inquiry searches for driver records that

match, exactly or approximately, on any of the search fields. It is used when a driver is known to exist on CDLIS, such

as when a driver is transferring licensure to another jurisdiction. Compared to the Search Inquiry, the Verification

Inquiry:

Returns more information

Requires more mandatory input fields and consequently is a narrower search than the Search InquiryRef1

The Verification Inquiry may be implemented using one of six message types, all of which are identical save for the

message type name. Message type names are used for transaction reporting, to keep track of the purpose of the

inquiries used. The message types defined for the Verification Inquiry are the following:

Verification Inquiry Preceding Change Data/Mark Driver Unique (IA)

Verification Inquiry Preceding Delete Master Pointer Record (IB)

Verification Inquiry Preceding Change State of Record (IC)

Verification Inquiry Preceding Report Out-of-State Conviction (ID)

Verification Inquiry Preceding State-to-State History Request (IE)

All other uses of the Verification Inquiry (IN)

Participants


o U.S. jurisdiction

CDLIS Central Site


o U.S. jurisdiction

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending a Verification Inquiry message to the CDLIS Central Site.

Upon receipt of the Verification Inquiry, the CDLIS Central Site:


o Retrieves MPRs that match, exactly or approximately, on any of the search fields


o For each of the MPRs retrieved, where the driverřs SOR is not also the inquirer, the CDLIS Central Site

sends a status request message to the SOR. If the driverřs SOR is the inquirer, there is no need to send a

status request because the inquirer can check its own Driver History Record (DHR).

Upon receipt of the status request message, the SOR:


o Retrieves the DHR









Inputs

The Verification Inquiry includes the driverřs name and date of birth. It also includes one or both of the following:

The licensing jurisdiction code and driver's license number combination

The driver's Social Security Number (SSN)






match, up to 5 drivers


o The Central Site sends driver identification information to each SOR for lookup


o The SOR sends the driverřs history status data (i.e. data identifying and describing the driver, driving

privileges and associated dates, and contact details) and permit restrictions


Central Site

o If the Verification Inquiry does not pass the edit validations performed by the CDLIS Central Site, the

Central Site returns an error to the inquirer. No further processing is performed.

SOR


CDLIS Central Site.

Inquirer



Post-Requisites

If more than 5 matches are found and none of the first 5 matches returned can be determined with certainty to be

the driver in question, the inquirer submits a Search Inquiry. Ref2

The Search Inquiry returns a broader set of

matches from which the inquirer may be able identify the driver in question.

The inquirer evaluates the status information and permit restriction information (if applicable) and considers

them when deciding on future courses of action.

References

Reference

#


Ref1 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref2 CDLIS System

Specifications








IN Verification Inquiry

IA Verification Inquiry Preceding Change Data/Mark Driver Unique

IB Verification Inquiry Preceding Delete Master Pointer Record

IC Verification Inquiry Preceding Change State of Record

ID Verification Inquiry Preceding Report Out-of-State Conviction

IE Verification Inquiry Preceding State-to-State History Request







CD02.1 Request Verification of Driver (State of Inquiry (SOI))


The Verification Inquiry transactions are designed to verify the existence of a commercial driver already on the CDLIS

Central Site. The jurisdictions use this transaction to either confirm or deny the existence of a CDLIS Master Pointer

Record (MPR) for the driver.

CD02.1.2 Transmission of Verification Inquiry (IN) Message

The Verification Inquiry (IN) message must include:




In addition, the message must include one or both of the following:


Driver SSN - CDLIS (DDVSS6) set to the driver's Social Security Number (SSN)

The Verification Inquiry (IN) message may optionally include:

Return as Received Text/Block (GRRECV) set to any value desired by the State of Inquiry (SOI)


values.

CD02.2 Verify Driver (CDLIS Central Site)

CD02.2.1 Reception of Verification Inquiry (IN) Message

Upon receipt of a Verification Inquiry (IN) message from an inquirer, the CDLIS Central Site initiates validation

processing.

The Central Site may alternatively receive the following inquiries, which are processed in the same way as a

Verification Inquiry (IN) message:

Verification Inquiry Preceding Change Data/Mark Driver Unique (IA) message

Verification Inquiry Preceding Delete Master Pointer Record (IB) message

Verification Inquiry Preceding Change State of Record (IC) message

Verification Inquiry Preceding Report Out-of-State Conviction (ID) message

Verification Inquiry Preceding State-to-State History Request (IE) message


The CDLIS Central Site performs the following validations on the Verification Inquiry (IN) message. If errors are

detected, the Central Site stops processing and returns the original message to the sender with error fields set. Up to five

validation failures may be reported on a single error message. The Central Site must report as many problems as it can

to minimize the number of resends.



Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Verification Inquiry (IN)

message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Verification

Inquiry (IN) message

Authorization Function (BJUAFN) set to ŖINŗ












Either the Driver License Jurisdiction Number (DDLJDL) or the Driver SSN - CDLIS (DDVSS6) must be

present.

Error Text: 'A REQUIRED FIELD IS MISSING'


At least one component field of Person Name Group (BPENGP) must be present.









DICTIONARYŗ.



DICTIONARYŗ.



Must be numeric















Driver Name (DDVNAM) must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ AAMVA PERSON

NAME FORMATTING RULESŗ










CD02.2.3 Retrieval

For each valid Verification Inquiry (IN) message, the Central Site retrieves up to a maximum of 5 records from the

Master Pointer (CD20) data store based on exact matches of information sent in the Verification Inquiry (IN) message.

The Central Site returns the first 5 unique records retrieved from Master Pointer (CD20) and verified to exactly match

the information sent in the Verification Inquiry (IN) message. Once 5 unique matching records are retrieved, additional

searches need not be performed.

If Driver License Jurisdiction Number (DDLJDL) is present on the Verification Inquiry (IN) message, check both the

master pointer and AKA data stores for exact matches. Where an AKA match is found, retrieve the associated master

pointer record.

Access the Master Pointer (CD20) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL) from the Verification Inquiry (IN) message; and

Driver License Number (DDLNUM) using positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL) from the Verification Inquiry (IN) message

Access AKA ST-DLN (CD24) by:

Driver Licensing AKA Jurisdiction (DDLJU2) using positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL) from the Verification Inquiry (IN) message; and

Driver License AKA Number (DDLNU1) using positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL) from the Verification Inquiry (IN) message

Retrieve the CD24 record only if it:

Is among the three most recent for its associated Master Pointer (CD20) record (based on the AKAřs Date of

Last Update (GRCUDT) and Time of Last Update (GRCUTM)); and

Has an AKA ST-DLN Status (DDLKST) is set to ŘAř.

Access the associated CD20 record.

Otherwise, if Driver License Jurisdiction Number (DDLJDL) is not present,

Access the Master Pointer (CD20) data store by the following field using the last 5 positions of the Driver SSN - CDLIS

(DDVSS6):

Person SSN Last 5 Digits (BPESSD)

If Driver SSN - CDLIS (DDVSS6) from the Verification Inquiry (IN) message is all 9s (Substitute SSN), retrieve only





those CD20 records where the Driver SSN Type (DDVSSI) is ŘSř. Otherwise, retrieve only those CD20 records where

the Driver SSN Type (DDVSSI) is not = ŘSř to avoid matches on substitute SSNs (all 9řs).

Each Master Pointer (CD20) record retrieved above is a potential match. To confirm whether or not it constitutes an

exact match, and is therefore returned in the response, all of the following comparisons between the data on the

Verification Inquiry (IN) and each retrieved master pointer record are performed and must be satisfied.

The name information on the Verification Inquiry (IN) message must correspond with the name information on

the existing Master Pointer (CD20). The comparison is performed as described in 7.2 Name Comparison.


The Driver Date of Birth (DDVDOB) on the Verification Inquiry (IN) message must exactly match the Person

Date of Birth (BPEDOB) on the existing Master Pointer (CD20) record.


If Driver License Jurisdiction Number (DDLJDL) is not present but Driver SSN Ŕ CDLIS (DDVSS6) is present

on the Verification Inquiry (IN) message, the last 5 positions of the Driver SSN - CDLIS (DDVSS6) on the

Verification Inquiry (IN) message must exactly match the Person SSN Last 5 Digits (BPESSD) on the existing

Master Pointer (CD20) record.


If Driver License Jurisdiction Number (DDLJDL) is not present but Driver SSN Ŕ CDLIS (DDVSS6) is present

on the Verification Inquiry (IN) message, the last 5 positions of the Driver SSN - CDLIS (DDVSS6) on the

Verification Inquiry (IN) message must exactly match the Person SSN Last 5 Digits (BPESSD) on the existing

Master Pointer (CD20) record.

For each Master Pointer (CD20) record match where the Jurisdiction Code - Licensing (DDLJUR) on the CD20 record

does not equal the Message Originator (GMSORG) on the Verification Inquiry (IN) message, the CDLIS Central Site

determines the implementation status of the State of Record (SOR) by performing ŘCDJ1.3 Verification of Additional

Transaction Participantř using the following input;






sends response message(s) to the inquirer and a request for status to each State of Record (SOR).




will be sent. If there are zero matches, the Number of Status Responses from Inquiry (RC) message is the only response

to the State of Inquiry (SOI) and the transaction is considered complete.

The only difference between the Number of Status Responses from Inquiry (RC) message returned here and the Number

of Status Responses from Inquiry (RC) message returned in Search Inquiry (CD01) transaction is the maximum number

of matches returned.



Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Verification Inquiry (IN)

message



sent ('00' - '05')















Driver Duplicate Indicator (GMSDUP), set to 'N' if:





Driver Duplicate Indicator (GMSDUP), set to 'Y' if:



Pending)












values.



(CD20) data store.

The only difference between the MPR Data for Match on Inquiry Transaction (RD) messages returned here and the

MPR Data for Match on Inquiry Transaction (RD) messages returned in Search Inquiry (CD01) transaction is the

maximum number of matches (RD messages) returned.

The MPR Data for Match in Inquiry Transaction (RD) message must include:


Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Verification Inquiry (IN)

message



sent ('00' - '05')
















Message AKA SSN Count (GMSCSS) set to spaces

The MPR Data for Match in Inquiry Transaction (RD) message must include the following:






Driver Date of Birth (DDVDOB) set to the CD20 Driver Date of Birth





Driver Name (DDVNAM), set to the CD20 Person Name Group (BPENGP) converted into the format









Unique Complete)






associated with the CD20 record, where present and used to determine the match:



Name Group (BPENG3)










The Driver AKA Name (DDVKNM), set to the most recent CD22 Person AKA Name Group (BPENG3)


RULESŗ

The Driver AKA 2nd Name (DDVKN2), set to the second most recent CD22 Person AKA Name Group


FORMATTING RULESŗ

The Driver AKA 3rd Name (DDVKN3), set to the third most recent CD22 Person AKA Name Group


FORMATTING RULESŗ

The MPR Data for Match in Inquiry Transaction (RD) message must include the following from the three most

recent AKA ST-DLN (CD24) records associated with the CD20 record, where present, the AKA ST-DLN Status

(DDLKST) = ŘAř, and used to determine the match:









values.


One Status Request (SC) message is sent for each Master Pointer (CD20) record match where the Jurisdiction Code -

Licensing (DDLJUR) on the CD20 record does not equal the Message Originator (GMSORG) on the Verification

Inquiry (IN) message.

The only difference between the Status Request (SC) messages sent here and the Status Request (SC) message sent in

Search Inquiry (CD01) transaction is the maximum number of requests (SC messages) sent.




Message Match Sequence ID (GMSMSI) set to '01' for the first Status Request (SC) message; for each

subsequent Status Request (SC) message, the value is incremented by +1 (to a maximum of Ř05ř)

The Status Request (SC) message must include the following from the CD20 record:



Pointer (CD20)











(BPESSD)

If the State of Inquiry (SOI) is at a version older than 5.1 and the State of Record (SOR) is at version 5.1 or

greater:




(BPESSD)






Driver Current Sex (DDVSX3) set to the D20 Driver Sex (DDVSEX)


values.

CD02.2.4.4 Transmission of Verification Inquiry (IN) Message with Errors

If the CDLIS Central Site encounters errors on the original Verification Inquiry (IN) message that preclude further

processing, the Central Site returns the original Verification Inquiry (IN) message to the inquirer with Error Block

appended (up to 5 occurrences).

If one of the following messages was received instead of the Verification Inquiry (IN) message, the Central Site returns

the original message it received to the inquirer with Error Block appended (up to 5 occurrences).

Verification Inquiry Preceding Change Data/Mark Driver Unique (IA) message

Verification Inquiry Preceding Delete Master Pointer Record (IB) message

Verification Inquiry Preceding Change State of Record (IC) message

Verification Inquiry Preceding Report Out-of-State Conviction (ID) message, or

Verification Inquiry Preceding State-to-State History Request (IE) message



(02/2) blocks.












CD03 STATE-TO-STATE STATUS REQUEST




Description

A State-to-State Status Request enables an inquirer to obtain status information on a Commercial Driverřs License

(CDL) holder directly from the State of Record (SOR) without inquiring through the CDLIS Central Site.

A typical use of this transaction is to obtain the status information for a driver who was one of several returned as

matches on a Search Inquiry.Ref1

Since status requests are not sent when a Search Inquiry results in more than one

match, the State-to-State Status Request gives the inquirer a tool for obtaining the status for any or all of the matched

drivers.

This transaction may also be used to verify the status of a CDL when an out-of-state license is presented to a

jurisdiction.

The inquirer may request the status for only one driver at a time with this transaction.

Participants


o U.S. jurisdiction

o FMCSA

o FMCSA-authorized entity

o Canadian jurisdiction - cannot send inquiry to Mexico


o U.S. jurisdiction

o Canadian jurisdiction

o Licencia Federal Information Systema (LIFIS) (the Mexican National Database) and Federal Convictions

and Withdrawal Database (FCWD) - cannot receive inquiry from Canadian jurisdiction

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending a State-to-State Status Request message to the SOR.

Upon receipt of the State-to-State Status Request, the SOR:


o Retrieves the status information


Upon receipt of the response messages from the SOR, the inquirer checks the messages for errors.



Inputs

The State-to-State Status Request includes the licensing jurisdiction code and driver's license number combination. It

may optionally include the driver name, date of birth, and Social Security Number.



o The SOR sends the driverřs current status data (i.e. data identifying and describing the driver, driving

privileges and associated dates, contact details), and permit restrictions





Error Processing Ref2

SOR

o If the State-to-State Status Request does not pass the edit validations or if the SOR cannot locate the

driver, the SOR returns an error to the inquirer

o If a jurisdiction receives a State-to-State Status Request and is not the current SOR, it must return an error

to the inquirer. The only exception is when the jurisdiction is the Old SOR during a Change State of

Record (CSOR) transactionRef3

. In this case, the Old SOR must respond to status requests from the New

SOR until the CSOR is complete. These rules differ from the PDPS rules where all jurisdictions respond

to all status requests.

Inquirer

o If a status response does not pass the edit validations performed by the inquirer, the inquirer returns an

error to the SOR.

Post-Requisites

The inquirer evaluates the status information and permit restriction information (if applicable) received and uses

it as desired.

References

Reference

#


Ref1 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref2 CDLIS System

Specifications


Ref3 CDLIS System

Specifications

CD08 CHANGE STATE OF RECORD







SG State Request for Status

HG Status Response 0 - 1






CD03.1 Request Driver Status (State of Inquiry (SOI))


Prior to sending a State Request for Status (SG) message, the State of Inquiry (SOI) should initiate the Search Inquiry

process (CD01) to ensure the State Request for Status (SG) message is sent to the current State of Record (SOR).

CD03.1.2 Transmission of the State Request for Status (SG) Message

The State Request for Status (SG) message must include:


The State Request for Status (SG) message may optionally include:

Driver Date of Birth (DDVDOB) set to the date of birth of the driver

Driver SSN - CDLIS (DDVSS6) set to the driverřs Social Security Number (SSN)

Return as Received Text Block (GRRECV) set to any value desired by the State of Inquiry (SOI)

Person Name Group (BPENGP) set to the name of the driver

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) is providing the

driver name on the State Request for Status (SG) message, it must provide it in both the old and new formats.

After all Jurisdictions have implemented version 5.1 or greater, the driver name in old format will no longer be

supported on the State Request for Status (SG) message.

Driver Name (DDVNAM) set to the name of the driver


values.

CD03.2 Process Status Request (State of Record (SOR))

CD03.2.1 Reception of the State Status Request (SG) Message

The State Request for Status (SG) message must include:

Driver License Jurisdiction Number (DDLJDL)

The State Request for Status (SG) message may optionally include:



Driver SSN - CDLIS (DDVSS6)

Return as Received Text Block (GRRECV)


Person Name Group (BPENGP)

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) is providing

the driver name on the State Request for Status (SG) message, it will provide it in both the old and new

formats. After all Jurisdictions have implemented version 5.1 or greater, the driver name in old format

will no longer be supported on the State Request for Status (SG) message.

Driver Name (DDVNAM)







CD03.2.2 Validation

The validation checks described below should be performed on the State Request for Status (SG) message. If any errors

are detected, the error fields should be set, the original message is returned to its sender, and the jurisdiction's

processing stops.

The standard for reporting errors that preclude processing is to return the original messages (the State Request for Status

(SG) message) with the description of the error text. In this transaction, some jurisdictions report these errors using the

Status Response (HG) message. See Ŗ4 CDLIS ERROR PROCESSINGŗ for information on returning errors.




The Driver License Jurisdiction Number (DDLJDL) must be present.

Error Text: 'ST/DLN REQUIRED'


Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) must contain one of the following:

ŘMXř

ŘCNř or one of the valid values in the ŖCanadaŗ list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX

D - DATA DICTIONARYŗ

One of the valid values in the "United States" list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D -

DATA DICTIONARYŗ



Must be numeric





Driver Date of Birth (DDVDOB), if present, must be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.


If at least one component field of Person Name Group (BPENGP) is present, the Person Name Group (BPENGP) must

conform to the requirements listed in "APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008)

VALIDATIONS"

See "APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008) VALIDATIONS" for

specific error text associated with this error.

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) has implemented version

5.1 and is providing the driver name on the State Request for Status (SG) message, it will provide it in both the old and

new formats. If the State of Inquiry has not yet implemented version 5.1, if it is providing the driver name on the State

Request for Status (SG) message, it will provide it in the old format. After all Jurisdictions have implemented version

5.1 or greater, the driver name in the old format will no longer be supported on the State Request for Status (SG)





message.

Driver Name (DDVNAM), if present, must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ



CD03.2.2.4 Retrieved Records Match Errors

The SOR attempts to locate the requested record using the Driver License Jurisdiction Number (DDLJDL) contained in

the inquiry message. Additional verifications on the Person Name Group (BPENGP)/Driver Name (DDVNAM), Driver

Date of Birth (DDVDOB) and Driver SSN - CDLIS (DDVSS6) are not permitted.

If the record is not found,

Error Text: ‘REQUESTED RECORD NOT FOUND’

Otherwise, the SOR must determine whether or not a Change State of Record (CSOR) is currently in progress involving

the given driver. Refer to Section 8.4.1.1 Reception of the Confirm CSOR in Progress (CG) Message and Section 8.7.1

Reception of the Confirm CSOR Complete (CE) Message of this specification for a logical description of the related

updates to the Jurisdictionřs database during the execution of a Change State of Record (CSOR) transaction that allow

this determination to take place.

If a Change State of Record (CSOR) is currently in progress involving the given driver, and if the Jurisdiction is the Old

SOR, it can only respond with driver information if the Transaction Originator (GTRORG) of the inquiry message

corresponds to the New SOR.

Error Text: ‘NOT CURRENT SOR’

If a Change State of Record (CSOR) is currently in progress involving the given driver, and if the Jurisdiction is the

New SOR, it cannot respond with status information until the Change State of Record (CSOR) has successfully

completed. In addition to returning the following error text, the Jurisdiction populates the Processing Status Flag

(GPROST) = Ř05ř.

Error Text: ‘CONFIRMATION OF NEW SOR, BUT DHR NOT READY’

If a Change State of Record (CSOR) is not currently in progress involving the given driver, and the Jurisdiction had

been but is no longer the current SOR,


If the jurisdiction has multiple matches on the Driver License Jurisdiction Number (DDLJDL) for a commercial driver,

it requires special attention. If identical Driver License Jurisdiction Number (DDLJDL)s can exist in a jurisdiction's

environment, this condition needs to be examined closely to assess its impact on the CDLIS application. Typically,

duplicates occur when a jurisdiction recycles old Driver License Numbers (DLN)s. In this situation, the match with the

most recent Driver License Issue Date (DDLISS) must be returned.


The SOR sends the Status Response (HG) message to the SOI when a match is found.

If a match is not found, the SOR returns the State Request for Status (SG) message or sends the Status Response (HG)

message.

Also see the CDLIS State Procedures Manual for rules when transmitting the driver history.

CD03.2.3.1 Transmission of Status Response (HG) Message

If the driver record is located by the SOR, the Status Response (HG) message must include:

Message Destination (GMSDST) set to the Message Origin (GMSORG) on the State Request for Status (SG)

message





Application Status (GAPPST) set to '00'

NCB Error Code (GNCBER) set to 'N'

Message Locator/Header (GMSLOC) from the original message

Message Match Count (GMSCNT) set to '01'


Message Match Sequence Identifier (GMSMSI) set to '01'

If the driver record is involved in a Change State of Record transaction at the time the inquiry is processed, and if

the associated driver history has not yet been posted to the driver's record:

o Processing Status (GPROST) set to '05'

o NCB Error Code set to 'Y'

o Error text: "DRIVER HISTORY NOT COMPLETE"

Otherwise,


o NCB Error Code (GNSBER) set to 'N'

Note: Even though the NCB Error Code is set to 'Y', the other fields in the Status Response (HG) message are

still populated as if no error has occurred.

Last Match Indicator (GMSLMI) set to 'Y'

Message AKA DLN Count (GMSCDL) set to the number of AKA DLNs being sent

Message AKA SSN Count (GMSCSS) set to the number of AKA SSNs being sent

Message AKA Name Count (GMSCNM) set to the number of AKA Names being sent

Driver Date of Birth (DDVDOB) set to the date of birth on the SOR's database

Driver License Jurisdiction Number (DDLJDL) set to the driver license number of the SOR's driver

Driver License Number of Permits (DDLNMP) set to the number of permits on the driver's record

Driver License Commercial Class Code (DDLCL2) set to the appropriate commercial class(es) on the driver's

record

Driver License Non-Commercial Class Code (DDLCL3) set to the appropriate non-commercial class(es) on the

driver's record

Driver License Endorsement Code (DDLEND) set to the appropriate endorsements on the driver's record (up to

5)

Driver License Issue Date (DDLISS) set to the date on which the driver's license was last issued or renewed

Driver License Expiration Date (DDLEXP) set to the date after which the driver's license is no longer valid

Driver License Non-Commercial Status (DDLNTS) set to the current status of the driver's non-commercial

license

Driver License Commercial Status (DDLCTS) set to the current status of the driver's commercial license

Driver License Privilege Type Withdrawal Pending (DDLWDP) set to the appropriate value indicating whether

the driver has a withdrawal action pending or not

Number of Driver License Restrictions (DDLNMR) set to the number of licensing restrictions on the driver's

record

Driver Medical History Indicator (DDVMED) set to the appropriate value indicating whether a medical history

exists for the driver or not. The Driver Medical History Indicator (DDVMED) has no relationship to Medical

Certificate requirements.

Total Convictions Sent (DDTTCS) set to '00'

Total ACD Convictions on Record (DDTTCR) set to the number of convictions with a current ACD code on the

SOR's database for the driver*

Total Accidents Sent (DDTTAS) set to '00'





Total Accidents on Record (DDTTAR) set to the number of accidents on the SOR's database for the driver2

Total Withdrawals Sent (DDTTWS) set to '00'

Total Withdrawals on Record (DDTTWR) set to the number of withdrawals with a current ACD code on the

SOR's database for the driver*

Driver Mailing Address (DDVADD) set to the mailing address of the driver

If neither the Person Name Group (BPENGP) nor the Driver Name (DDVNAM) are present on the State Request

for Status (SG) message:

Person Name Group (BPENGP) set to the driver's name on the SOR's database

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) did not

provide the Person Name Group (BPENGP) or the Driver Name (DDVNAM) on the State Request for

Status (SG) message, the State of Record (SOR) must provide the driver name on the Status Response

(HG) message in both the old and new formats. After all Jurisdictions have implemented version 5.1 or

greater, the driver name in the old format will no longer be supported on the Status Response (HG)

message.

Driver Name (DDVNAM) set to the name on the SOR's database

If the Person Name Group (BPENGP) and the Driver Name (DDVNAM) are present on the State Request for

Status (SG) message:


Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) has

implemented version 5.1 or greater, it will include both the Person Name Group (BPENGP) and the

Driver Name (DDVNAM) on the State Request for Status (SG) message. After all Jurisdictions have

implemented version 5.1 or greater, the driver name in the old format will no longer be supported on the

State Request for Status (SG) message.

If only the Driver Name (DDVNAM) is present on the State Request for Status (SG) message:


Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) has not yet

implemented version 5.1, it will include only the Driver Name (DDVNAM) on the State Request for

Status (SG) message. After all Jurisdictions have implemented version 5.1 or greater, the driver name in

the old format will no longer be supported on the State Request for Status (SG) message or on the Status

Response (HG) message.

The Status Response (HG) message must also include all available data on the SOR's database for the following:

Driver AKA Date of Birth (DDVKDB) set to the first recorded DOB for the driver (other than the current DOB)

Driver AKA 2nd Date of Birth (DDVKD2) set to the second recorded DOB for the driver (other than the current

DOB)

Driver AKA 3rd Date of Birth (DDVKD3) set to the third recorded DOB for the driver (other than the current

DOB)

Driver Current Sex (DDVSX3) set to the current sex of the driver

2 These fields are limited to a maximum value of '99' for transmission on the Status Response (HG) message.

Jurisdictions must maintain all convictions, accidents, and withdrawals on their databases consistent with data retention

requirements.





Driver Current Height (DDVHT3) set to the current height of the driver

Driver Current Weight (DDVWT3) set to the current weight of the driver

Driver Current Eye Color (DDVEY3) set to the current eye color of the driver

AKA Driver License Jurisdiction Number (DDLJD2) set to the first recorded ST/DLN for the driver (other than

the current ST/DLN)

AKA 2nd Driver License Jurisdiction Number (DDLJD3) set to the second recorded ST/DLN for the driver

(other than the current ST/DLN)

AKA 3rd Driver License Jurisdiction Number (DDLJD4) set to the third recorded ST/DLN for the driver (other

than the current ST/DLN)

Driver SSN - CDLIS (DDVSS6) set to the Social Security Number on the SOR's database.

Driver AKA Social Security Number (DDVKSS) set to the first recorded SSN for the driver (other than the

current SSN) when the response is being returned to a jurisdiction. For other recipients, jurisdiction privacy

rules dictate whether or not the SSN is included

Driver Residence Address (DDVRAD) set to the residence address of the driver (if different than the mailing

address)

Driver TSA HME Threat Determination (DTHTSD) set to the appropriate code, if a TSA Threat Determination

has been completed. This data element is required if available

Driver License Hazmat Endorsement Exp Date (DDLHED) set to the appropriate date, if a TSA Threat

Determination has been completed. This data element is required if available

If neither the Person Name Group (BPENGP) nor the Driver Name (DDVNAM) are present on the State Request

for Status (SG) message:

The first occurrence of Person AKA Name Group (BPENG3) set to the first name by which the driver has

been known (other than the current name)

The second occurrence of Person AKA Name Group (BPENG3) set to the second name by which the

driver has been known (other than the current name)

The third occurrence of Person AKA Name Group (BPENG3) set to the third name by which the driver

has been known (other than the current name)

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) did not

provide the Person Name Group (BPENGP) or the Driver Name (DDVNAM) on the State Request for

Status (SG) message, and if the State of Record (SOR) is providing AKA name(s) on the Status Response

(HG) message, it must provide it in both the old and new formats. After all Jurisdictions have

implemented version 5.1 or greater, AKA name(s) in old format will no longer be supported on the Status


The Driver AKA Name (DDVKNM) set to the first name by which the driver has been known (other than

the current name)

The Driver AKA 2nd Name (DDVKN2) set to the second name by which the driver has been known

(other than the current name)

The Driver AKA 3rd Name (DDVKN3) set to the third name by which the driver has been known (other

than the current name)

If the Person Name Group (BPENGP) and the Driver Name (DDVNAM) are present on the State Request for

Status (SG) message:

The first occurrence of Person AKA Name Group (BPENG3) set to the first name by which the driver has

been known (other than the current name)


driver has been known (other than the current name)


has been known (other than the current name)





Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) has

implemented version 5.1 or greater, it will include both the Person Name Group (BPENGP) and the

Driver Name (DDVNAM) on the State Request for Status (SG) message. After all Jurisdictions have


State Request for Status (SG) message.

If only the Driver Name (DDVNAM) is present on the State Request for Status (SG) message:


Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) has not yet

implemented version 5.1, it will include only the Driver Name (DDVNAM) on the State Request for

Status (SG) message. After all Jurisdictions have implemented version 5.1 or greater, the driver name in

the old format will no longer be supported on the State Request for Status (SG) message or on the Status


The Driver AKA Name (DDVKNM) set to the first name by which the driver has been known (other than

the current name)

The Driver AKA 2nd Name (DDVKN2) set to the second name by which the driver has been known

(other than the current name)

The Driver AKA 3rd Name (DDVKN3) set to the third name by which the driver has been known (other

than the current name)

The details of up to three permits may be included in the Status Response (HG) message. If the driver has no permits,

the following are not populated. For each permit on the driver's record, include the following details on the Status

Response (HG) message:

Driver License Permit Classification Code (DDLPC2) set to class(es) of vehicles for which the driver has a

permit

Driver License Permit Endorsement Group Code (DDLEP1) set to endorsement(s) for which the driver has a

permit

Driver License Permit Issue Date (DDLPID) set to the date on which a permit was issued

Driver License Permit Expiration Date (DDLPED) set to the date after which the driver's permit is no longer

valid

Driver License Permit Status (DDLPST) set to the current status of the driver's permit

Driver License Number of Permit Restrictions (DDLRPN) set to the number of permit restrictions included on

each permit

The details of up to 12 driver license restrictions may be included in the Status Response (HG) message. If the driver

has no driver license restrictions, the following details are not populated. For each driver license restriction on the

driver's record, include the following details on the Status Response (HG) message:

Driver License Restriction Code (DDLRSC) set to the restrictions applicable to the driver's license

Driver License Restriction End Date (DDLRSD) set to the date after which a restriction longer exists; if the

period of the restriction is indefinite, the date is left blank

Driver License Restriction Explanation (DDLRSE) set to the text describing the restriction; only entered if the

Driver License Restriction Code (DDLRSC) is set to either ŘIř (ŖRestricted Ŕ Otherŗ) or 'J' ("Other")

The following element may optionally be included on the Status Response (HG) message:

Return as Received Text/Block (GRRECV) set to the value on the original State Request for Status (SG)

message (up to 5 occurrences)


values.

If Medical Certificate information is available, the Status Response (HG) message must include the following required





Medical Certificate fields:

CDL Medical Self Certification Code (DDLSCT) set to the appropriate code indicating the driverřs self

certification

Medical Certificate Status Code (DMCCTC) set to the appropriate code indicating status of the driverřs medical

certification

If Medical Certificate information is available, the Status Response (HG) message must also include all available data

on the SORřs database for the following optional Medical Certificate fields:

Medical Examiner Name Group (BMPNGP) set to the name of the medical examiner

Medical Licensing Jurisdiction Code (BMPJO1) set to the code of the jurisdiction that issued the medical

examinerřs license

Medical Examiner License Number (BMPLI1) set to the medical examinerřs license number

Medical Examiner Telephone Num (BMPTP1) set to the medical examinerřs phone number

Medical Examiner Specialty Code (BMPSP1) set to the appropriate code indicating the medical examinerřs

specialty

Medical Certificate Issue Date (DMCPED) set to the date the medical examinerřs certificate was issued

Medical Certificate Expiration Date (DMCEDT) set to the expiration date of the medical examinerřs certificate

Medical Certificate Restriction Code (DMCRES) set to any restrictions imposed by the medical examiner (up to

ten occurrences)

If FMCSA-approved variance information is available, the Status Response (HG) message must also include all

available data on the SORřs database for the following optional FMCSA variance fields:

Driver Waiver/Exempt Effective Date (DDLWSD) set to the effective date of the driver waiver/exemption.

Driver Waiver/Exempt Expiration Date (DDLWED) set to the expiration date of the driver waiver/exemption.

Driver Skill Performance Evaluation Effective Date (DDLSSD) set to the effective date of the driver Skill

Performance Evaluation (SPE)

Driver Skill Performance Evaluation Expiration Date (DDLSED) set to the expiration date of the driver Skill


Note: The final rule published by FMCSA on December 1, 2008 requires that the ŖDate the medical examinerřs

certificate was posted to the CDLIS driver recordŗ be sent in history. Further discussions revealed that the date the

information on the medical examiner's certificate is posted on CDLIS driver record does not need to be transmitted. It

only needs to be maintained for compliance review.

Notes:

A jurisdiction must not issue a hazardous materials endorsement (including the combined Tank/HAZMAT) on a permit.

A Tank endorsement by itself would be valid (see 49 CFR 383.23(c)(3)).

The counts for convictions, withdrawals, and linkages sent on the Status Response (HG), State-to-State History Request

(HB), and CSOR Driver History Response (HD) response messages must only include those

convictions/withdrawals/linkages that can be sent via CDLIS. The intent of the ŘTotal Sentř and ŘTotal on Recordř (for

convictions it is now ŘTotal ACD Convictions on Recordř; for withdrawals it includes the ŘW00ř code) is to notify the

recipient jurisdiction that more convictions, withdrawals and/or linkages exist on the driverřs record than could be

transmitted. The SOR then mails all of the convictions, withdrawals and/or linkages to the recipient jurisdiction. As of

October 1, 2005, if the SOR has not yet implemented Release 4.0.1, these counts may be different because some of the

conviction/withdrawals may contain or reference convictions/withdrawals with new ACD codes that the SOR is not able

to transmit via CDLIS.

The CDLIS Central Site does not validate information sent by the SOR to an SOI in a status response message.

According to 49 CFR 384.210 ŖLimitation on licensing statesŗ a jurisdiction may not issue a CDL to a person during a

period in which ŖAny type of driver's license held by such person is suspended, revoked, or canceled by the State where

the driver is licensed for any State or local law related to motor vehicle traffic control (other than parking violations).ŗ

Therefore, when deciding whether to issue a CDL, a commercial or non-commercial status of ŘNOTř precludes





issuance, regardless of the reason for the status.

The current SOR is responsible for determining the commercial status using the driverřs complete history. Even when a

driver moves and downgrades his/her license, the SOR must be able to maintain the driverřs CDL status based on the

driverřs history. If a commercial driver has received a lifetime disqualification, their commercial status has to stay

ŘNOTř for 55 years. Additional convictions and withdrawals may be sent to the SOR after the person no longer holds a

CDL and these also affect a personřs commercial status.

A commercial status of ŘNOTř requires at least one open withdrawal (one without a reinstatement date).

CD03.2.3.2 Transmission of Permit Restrictions (H6) Message

Restrictions on permits are optional. If permit restriction information is kept, the Permit Restrictions (H6) message

must be sent.

The Permit Restrictions (H6) message must include the following:

Message Destination (GMSDST) set to the Message Origin (GMSORG) on the State Request for Status (SG)

message

Message Locator/Header (GMSLOC) set to the value on the original message




Processing Status (GPROST) set to '00'


Driver License Jurisdiction Number (DDLJDL) set to the driver license number in the SOR's database

The Permit Restrictions (H6) message may optionally include the following:

Driver SSN - CDLIS (DDVSS6) set to the Social Security Number in the SOR's database.

Up to three permits may be sent on the Permit Restrictions (H6) message. If these permits have restrictions, up to 12

restrictions may be sent for each permit. Permit restriction details from the SOR's database are sent on the in the

following elements:

Driver License 1st Permit Restrict Code (DDLRP1)

Driver License 1st Permit Restrict End Date (DDLPD1)

Driver License 1st Permit Restrict Explanation (DDLPE1)

Driver License 2nd Permit Restrict Code (DDLRP2)

Driver License 2nd Permit Restrict End Date (DDLPD2)

Driver License 2nd Permit Restrict Explanation (DDLPE2)

Driver License 3rd Permit Restrict Code (DDLRP3)

Driver License 3rd Permit Restrict End Date (DDLPD3)

Driver License 3rd Permit Restrict Explanation (DDLPE3)

See ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for remaining NCB (00/0) and MEC (02/2)

block values.

CD03.2.3.3 Transmission of State Request for Status (SG) Message with Errors

If errors are encountered which preclude processing or the SOR cannot locate a record based on the information

submitted by the SOI (a 'no hit'), the SOR returns the original State Request for Status (SG) message to the SOI. The

State Request for Status (SG) message is returned exactly as received with the following exceptions:

NCB Error Code (GNCBER) set to 'Y'

Processing Status Code (GPROST) set to '01' (logic error) if the driver could not be located; '03' (syntax error) if

processing could not be performed





Error Block set to the appropriate error messages (up to 5 occurrences)



values.

CD03.3 Process Status Response (State of Inquiry (SOI))

Upon receipt of the inquiry responses from the SOR, the SOI is responsible for confirming that the driver represented in

the response messages is the appropriate driver before taking any update actions (since the driver was selected by the

SOR based on DLN only). This is accomplished by verifying the primary driver identifying data (Name, Date of Birth

and Social Security Number) matches. The SOI may also consider secondary driver identifying data, such as Sex,

Height, Weight, and Eye Color.

CD03.3.1 Reception

The SOI receives one or two messages in response to the original State Request for Status (SG) message:

If the State-of-Record (SOR) was able to locate the record on its database, the SOR sends a Status Response

(HG) message and, if permit restriction information is maintained by the SOR for drivers, a Permit Restrictions

(H6) message. A value greater than zero in the Number of Permit Restrictions (DDLRPN) for any of the permits

on the Status Response (HG) message indicates a Permit Restrictions (H6) message will be received.

If the State-of-Record (SOR) detected an error or was unable to locate the desired driver, either the Status

Response (HG) or State Request for Status (SG) message is sent with the appropriate error message(s). The SOI

should examine the description of the error to determine the appropriate course of action to take. Because state-

to-state error messages are not standardized in this transaction, any error message text may be received. The

error messages described in this section are examples of messages the SOI may receive from the SOR.

CD03.3.1.1 Reception of Status Response (HG) Message

When the SOR locates the record and sends the requested information, the Status Response (HG) message must include:


Application Status (GAPPST)

Message Locator/Header (GMSLOC)

Message Match Count (GMSCNT)

Message Match Indicator (GMSIND)

Message Match Sequence Identifier (GMSMSI)

Processing Status (GPROST)

Last Match Indicator (GMSLMI)

Message AKA DLN Count (GMSCDL)

Message AKA SSN Count (GMSCSS)

Message AKA Name Count (GMSCNM)



Driver License Number of Permits (DDLNMP)

Driver License Commercial Class Code (DDLCL2)

Driver License Non-Commercial Class Code (DDLCL3)

Driver License Endorsement Code (DDLEND)

Driver License Issue Date (DDLISS)

Driver License Expiration Date (DDLEXP)





Driver License Non-Commercial Status (DDLNTS)

Driver License Commercial Status (DDLCTS)

Driver License Privilege Type Withdrawal Pending (DDLWDP)

Number of Driver License Restrictions (DDLNMR)

Driver Medical History Indicator (DDVMED)

Total Convictions Sent (DDTTCS)

Total ACD Convictions on Record (DDTTCR)

Total Accidents Sent (DDTTAS)

Total Accidents on Record (DDTTAR)

Total Withdrawals Sent (DDTTWS)

Total Withdrawals on Record (DDTTWR)

Driver Mailing Address (DDVADD)

Driver TSA HME Threat Determination (DTHTSD)

Driver License Hazmat Endorsement Exp Date (DDLHED)



Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the State of Record (SOR), if it has

implemented version 5.1 or greater, will provide the driver name on the Status Response (HG) message

either in both the old and the new formats, or only in the new format. After all Jurisdictions have


Status Response (HG) message.




Note: The Total Convictions Sent (DDTTCS), Total Accidents Sent (DDTTAS), and Total Withdrawals Sent

(DDTTWS) will always be zero since no conviction, accident, or withdrawal information is sent in status responses.

The Status Response (HG) message may optionally include:


Driver AKA Date of Birth (DDVKDB)

Driver AKA 2nd Date of Birth (DDVKD2)

Driver AKA 3rd Date of Birth (DDVKD3)

Driver Current Sex (DDVSX3)

Driver Current Height (DDVHT3)

Driver Current Weight (DDVWT3)

Driver Current Eye Color (DDVEY3)

AKA Driver License Jurisdiction Number (DDLJD2)

AKA 2nd Driver License Jurisdiction Number (DDLJD3)

AKA 3rd Driver License Jurisdiction Number (DDLJD4)


Driver AKA Social Security Number (DDVKSS)

Driver License Permit Classification Code (DDLPC2)





Driver License Permit Endorsement Group Code (DDLEP1)

Driver License Permit Issue Date (DDLPID)

Driver License Permit Expiration Date (DDLPED)

Driver License Permit Status (DDLPST)

Driver License Number of Permit Restrictions (DDLRPN)

Driver Residence Address (DDVRAD)

Driver License Restriction Code (DDLRSC)

Driver License Restriction End Date (DDLRSD)

Driver License Restriction Explanation (DDLRSE)

Return as Received Text/Block (GRRECV)


For those States of Record (SOR) at version 5.1 or greater:

The first occurrence of Person AKA Name Group (BPENG3)

The second occurrence of Person AKA Name Group (BPENG3)

The third occurrence of Person AKA Name Group (BPENG3)

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Record (SOR) has

implemented version 5.1 or greater and is providing AKA name(s) on the Status Response (HG) message,

it will provide it in both the old and new formats, or only in the new format. After all Jurisdictions have

implemented version 5.1 or greater, AKA name(s) in old format will no longer be supported on the Status


Driver AKA Name (DDVKNM)

Driver AKA 2nd Name (DDVKN2)

Driver AKA 3rd Name (DDVKN3)

For those States of Record (SOR) at a version older than 5.1:




The Status Response (HG) message must contain all available data for the following Medical Certificate information:

CDL Medical Self Certification Code (DDLSCT)

Medical Certificate Status Code (DMCCTC)

The Medical Examiner Name Group (BMPNGP)

Medical Licensing Jurisdiction Code (BMPJO1)

Medical Examiner License Number (BMPLI1)

Medical Examiner Telephone Num (BMPTP1)

Medical Examiner Specialty Code (BMPSP1)

Medical Certificate Issue Date (DMCPED)

Medical Certificate Expiration Date (DMCEDT)

Medical Certificate Restriction Code (DMCRES), up to ten occurrences

Driver Skill Performance Evaluation Effective Date (DDLSSD)

Driver Skill Performance Evaluation Expiration Date (DDLSED)

Driver Waiver/Exempt Effective Date (DDLWSD)





Driver Waiver/Exempt Expiration Date (DDLWED)


CD03.3.1.2 Reception of Permit Restrictions (H6) Message

The Permit Restrictions (H6) message must include:




Message Match Sequence ID (GMSMSI)




The Permit Restrictions (H6) message may optionally include the following:











Note: A Permit Restrictions (H6) message will follow the Status Response (HG) message if and only if the Number of

Permits (DDLNMP) on the Status Response (HG) message is greater than zero and any of the three Number of Permit

Restrictions (DDLRPN) is also greater than zero.

CD03.3.1.3 Reception of State Request for Status (SG) Message with Errors

If the SOR was unable to locate the driver, the State Request for Status (SG) message is returned to the SOI. See Ŗ4

CDLIS ERROR PROCESSINGŗ for information on returning errors.


If errors are encountered on the Status Response (HG) message or the Permit Restrictions (H6) message, the message

containing the errors is returned to the originator of the Status Response (HG) message or the Permit Restrictions (H6)





CD04 STATE-TO-STATE HISTORY REQUEST




Description

A State-to-State History Request enables an inquirer to obtain the Driver History Record (DHR) on a Commercial

Driverřs License (CDL) holder directly from the State of Record (SOR) without inquiring through the CDLIS Central

Site

Typically, a U.S. licensing jurisdiction uses this transaction on a driver being considered for a Change State-of-Record

(CSOR),Ref1

after first identifying the driver and the driver's SOR with a Search Inquiry,Ref2

Verification Inquiry,Ref3

or

Verification Inquiry Preceding State-to-State History Request.Ref3

The inquirer may request the history for only one driver at a time with this transaction.

Participants


o U.S. jurisdiction

o FMCSA


CDLIS Common Validation Processor


o U.S. jurisdiction


and Withdrawal Database (FCWD)

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending a State-to-State History Request message to the SOR.

Upon receipt of the State-to-State History Request, the SOR:


o Retrieves the DHR

o Returns driver history information* to the inquirer

The CDLIS Common Validation Processor performs edits on the history information before forwarding it to the


Upon receipt of the response message from the State of Record (SOR) via the CDLIS Common Validation

Processor, the State of Inquiry (SOI) performs any additional required validations not already performed by the

CDLIS Common Validation Processor.

* If the SOR has implemented the Medical Certificate requirements, the driver history information includes

information pertaining to the driverřs medical certificate, where available.

Inputs

The State-to-State History Request includes the licensing jurisdiction code and driver's license number combination. It

may optionally include the driver name, date of birth, and Social Security Number



o The SOR sends the driverřs history data. The messages include information identifying and describing the

person, and the license, permits, and up to 50 convictions, 50 accidents, 50 withdrawals, and 50





withdrawal-convictions linkages, if available and allowed under jurisdiction law. If the driver has more

than 50 ACD convictions, withdrawals or withdrawal-conviction(s) linkages on record, the SOR transmits

the 50 most recent ACD convictions, withdrawals and withdrawal-conviction(s) linkages, and mails all

the ACD convictions, withdrawals, and linkages.Ref4


SOR

o If the State-to-State History Request does not pass the edit validations or if the SOR cannot locate the

driver, the SOR returns an error to the inquirer.

o If a jurisdiction receives a State-to-State History Request and is not the current SOR, it must return an

error to the inquirer. The only exception is when the jurisdiction is the Old SOR during a Change State of

Record (CSOR) transactionRef6

. In this case, the Old SOR must respond to history requests from the New

SOR until the CSOR is complete. These rules differ from the PDPS rules where all jurisdictions respond

to all history requests.

Inquirer

o If a history response does not pass the edit validations performed by the inquirer, the inquirer returns an

error to the SOR.

Post Requisites

When an SOI receives the driver history, it determines whether any information in the history precludes it from granting

a license or requires it to conduct additional processing. For instance, unless the history shows that a 10-year history

check has already been completed, one is initiated.

References

Reference

#


Ref1 CDLIS System

Specifications


Ref2 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref3 CDLIS System

Specifications


Ref4 CDLIS State

Procedures Manual

Appendix C, Procedures for Mailing Driver

History

Ref5 CDLIS System

Specifications


Ref6 CDLIS System

Specifications








SB Driver History Request

HB Driver History Response 0 - 1

H2 Driver History Permit Info 0 Ŕ 1

H3 Driver History Convictions 0 Ŕ 1

H4 Driver History Accidents 0 Ŕ 1

H5 Driver History Withdrawals 0 Ŕ 1

H7 Driver History Withdrawal-Conviction Links 0 - 1





CD04.1 Request Driver History (Typically, the State of Inquiry (SOI))


Prior to initiating the State-to-State History Request (CD04) process, the SOI should submit a Verification Inquiry (IN

or IE) message (see "CD02 VERIFICATION INQUIRY") to ensure the SB is sent to the current State of Record (SOR).

If a State Request for Status (SG) message (see "CD03 STATE-TO-STATE STATUS REQUEST") was submitted

before the Driver History Request (SB), the Verification Inquiry may not be required.

CD04.1.2 Transmission of Driver History Request (SB) Message

The Driver History Request (SB) message must include:

System Release Code (GMSSRL) set to a valid value (ŘFř or ŘHř) to indicate capabilities of the SOI to receive

and process the driver history data elements introduced in Release 4.0.1.

Driver License Jurisdiction Number (DDLJDL) set to the following two data elements that compose the driver's

license jurisdiction number:

o Driver License Current Jurisdiction Code (DDLJU1) set to the SOR's jurisdiction code

o Driver License Number (DDLNUM) set to the license number of the driver on whom the inquiry is being

submitted

The Driver History Request (SB) message may optionally include:

Driver Date of Birth (DDVDOB) set to the date of birth of the driver on whom the inquiry is being submitted

Driver SSN - CDLIS (DDVSS6) set to the Social Security Number of the driver on whom the inquiry is being

submitted

Person Name Group (BPENGP) set to the name of the driver on whom the inquiry is being submitted

Driver Name (DDVNAM) set to the name of the driver

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, if the State of Inquiry (SOI) is providing the

driver name on the Driver History Request (SB) message, it must provide it in both the old and new formats.

After all Jurisdictions have implemented version 5.1 or greater, the driver name in old format will no longer be

supported on the Driver History Request (SB) message.

Return as Received Text Block (GRRECV) set to any value desired by the SOI

Note: The System Release Code (GMSSRL) enables jurisdictions that have implemented Release 4.0.1 or later to

maintain backward compatibility with jurisdictions that have not implemented Release 4.0.1 or later. If the SOI leaves

the field set to a space (a valid value meaning the jurisdiction is on CDLIS Release 2.0.0), it cannot receive information

implemented in Release 4.0.1. If it sets the field to ŘFř, it can receive information about the 10-year history check and

the withdrawal-convictions linkages. If it sets the field to ŘHř, it can receive all possible information, including

information about the 10-year history check, the withdrawal-convictions linkages, and information about the TSA

Threat Determination.


values.

CD04.2 Process History Request (State of Record (SOR))

Upon receipt of a Driver History Request (SB) message, the State of Record (SOR) performs the ŖCDL1 PROCESS

HISTORY REQUEST (STATE OF RECORD (SOR)/Old State of Record (OSOR))ŗprocess.

CD04.3 Process History Response (State of Inquiry (SOI))

Upon receipt of history information, the SOI performs the ŖCDM1 PROCESS HISTORY RESPONSE

(INQUIRER)ŗprocess.





CD04.4 Resolve History Errors (State of Record (SOR))

If errors are encountered on the Driver History Response (HB) message, the message is returned to the originator of the

Driver History Response (HB) message (i.e., the SOR) with the error(s) identified. The SOR performs the ŖCDE1

RESOLVE HISTORY ERRORS (STATE OF RECORD (SOR)/OLD SOR)ŗ process.

CD04.5 Apply Common Validations (CDLIS Common Validation Processor)

The CDLIS Common Validation Processor performs validations on response messages as specified in ŖCDN1 APPLY

COMMON VALIDATIONS (CDLIS COMMON VALIDATION PROCESSOR)ŗ.







Description

The AKA Data Inquiry transaction functions exactly the same as the Search InquiryRef1

except that all AKA data present

on any matching Master Pointer Record (MPR) is returned on the response, as opposed to only those AKA fields

essential in determining the match.

Participants


o U.S. jurisdiction

o FMCSA


CDLIS Central Site


o U.S. jurisdiction

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending an AKA Inquiry message to the CDLIS Central Site.

Upon receipt of the AKA Inquiry, the CDLIS Central Site:


o Retrieves MPRs that match, exactly or approximately, on any of the search fields


o If one, and only one, record is retrieved and the driverřs SOR is not also the inquirer, the CDLIS Central

Site sends a status request message to the SOR. If the driverřs SOR is the inquirer, there is no need to

send a status request because the inquirer can check its own Driver History Record (DHR).

Upon receipt of a status request message, the SOR:


o Retrieves the DHR





Inputs

The AKA Inquiry message includes the driverřs name and date of birth. It may optionally include the licensing

jurisdiction code and driver's license number combination, the driver's Social Security Number (SSN), and up to three

AKA names or dates of birth.










match, up to 15 drivers


o When there is one, and only one, match, the Central Site sends driver identification information to the

SOR for lookup


o The SOR sends the driverřs history status data (i.e. data identifying and describing the driver, driving

privileges and associated dates, contact details) and permit restrictions


Central Site

o If the AKA Data Inquiry does not pass the edit validations performed by the CDLIS Central Site, the


SOR


CDLIS Central Site.

Inquirer



Post-Requisites

None

References

Reference

#


Ref1 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref2 CDLIS System

Specifications








IK Inquiry for AKA Data










CD05.1 Request Search for AKA Data (State of Inquiry (SOI))

CD05.1.1 Transmission of Inquiry for AKA Data (IK) Message

The Inquiry for AKA Data (IK) message must include:




The Inquiry for AKA Data (IK) message may optionally include:




Driver License Jurisdiction Number (DDLJDL) set to the ST/DLN (combination of jurisdiction code and driver's

license number) of the driver








Return as Received Text/Block (GRRECV) set to any value desired by the SOI

Note: If AKA Name and AKA DOB is transmitted, each AKA Name must be paired with an AKA Date of Birth. The

first occurrence must be populated before the second occurrence, which must be populated before the third occurrence.


values.

CD05.2 Research Driver for AKA Data (CDLIS Central Site)

CD05.2.1 Reception of Inquiry for AKA Data (IK) Message

Upon receipt of an Inquiry for AKA Data (IK) message from an inquirer, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Inquiry for AKA Data (IK) message. If errors are






Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Inquiry for AKA Data (IK)

message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Inquiry for

AKA Data (IK) message

Authorization Function (BJUAFN) set to ŖIKŗ







See Ŗ4 CDLIS ERROR PROCESSINGŗ for more information on returning system errors.

CD05.2.2.2 Required-Data Errors








Driver Name (DDVNAM) must be present.






DICTIONARYŗ.



DICTIONARYŗ.



Must be numeric





Driver AKA Date of Birth (DDVKDB), if present, must be a valid date and formatted as specified in



Driver AKA 2nd Date of Birth (DDVKD2), if present, must be a valid date and formatted as specified in



Driver AKA 3rd Date of Birth (DDVKD3), if present, must be a valid date and formatted as specified in












If at least one component field of the first occurrence of Person AKA Name Group (BPENG3) is present, the

first occurrence of Person AKA Name Group (BPENG3) must conform to the requirements listed in




If at least one component field of the second occurrence of Person AKA Name Group (BPENG3) is present, the

second occurrence of Person AKA Name Group (BPENG3) must conform to the requirements listed in




If at least one component field of the third occurrence of Person AKA Name Group (BPENG3) is present, the

third occurrence of Person AKA Name Group (BPENG3) must conform to the requirements listed in





Driver Name (DDVNAM) must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ AAMVA

PERSON NAME FORMATTING RULESŗ


Driver AKA Name (DDVKNM), if present, must conform to the requirements listed in ŖAPPENDIX E.1

Ŕ AAMVA PERSON NAME FORMATTING RULESŗ


Driver AKA 2nd Name (DDVKN2), if present, must conform to the requirements listed in ŖAPPENDIX

E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ


Driver AKA 3rd Name (DDVKN3), if present, must conform to the requirements listed in ŖŖAPPENDIX



CD05.2.2.4 Data Cross-check Errors


If Driver AKA Date of Birth (DDVKDB) is present, at least one component field of the first occurrence of







If at least one component field of the first occurrence of Person AKA Name Group (BPENG3) is present, Driver

AKA Date of Birth (DDVKDB) must also be present.


If Driver AKA 2nd Date of Birth (DDVKD2) is present, at least one component field of the second occurrence of



If at least one component field of the second occurrence of Person AKA Name Group (BPENG3) is present,

Driver AKA 2nd Date of Birth (DDVKD2) must also be present.


If Driver AKA 3rd Date of Birth (DDVKD3) is present, at least one component field of the third occurrence of



If at least one component field of the third occurrence of Person AKA Name Group (BPENG3) is present, Driver

AKA 3rd Date of Birth (DDVKD3) must also be present.



If Driver AKA Date of Birth (DDVKDB) is present, Driver AKA Name (DDVKNM) must also be present.


If the Driver AKA Name (DDVKNM) is present, Driver AKA Date of Birth (DDVKDB) must also be present.


If Driver AKA 2nd Date of Birth (DDVKD2) is present, Driver AKA 2nd Name (DDVKN2) must also be

present.


If the Driver AKA 2nd Name (DDVKN2) is present, Driver AKA 2nd Date of Birth (DDVKD2) must also be

present.


If Driver AKA 3rd Date of Birth (DDVKD3) is present, Driver AKA 3rd Name (DDVKN3) must also be

present.


If the Driver AKA 3rd Name (DDVKN3) is present, Driver AKA 3rd Date of Birth (DDVKD3) must also be

present.






CD05.2.3 Retrieval

If the Inquiry for AKA Data (IK) message is valid, perform the ŖCDH1 SEARCH INQUIRY RETRIEVAL (CDLIS

CENTRAL SITE)ŗ common process.

If the CDLIS Central Site finds exactly one Master Pointer (CD20) match and the Jurisdiction Code - Licensing

(DDLJUR) on the CD20 record does not equal the Message Originator (GMSORG) on the Inquiry for AKA Data (IK)

message, the CDLIS Central Site determines the implementation status of the State of Record (SOR) by performing

ŘCDJ1.3 Verification of Additional Transaction Participantř using the following input;






sends response message(s) to the inquirer and a request for status to the State of Record (SOR) where there is a single

match.




will be sent. If there are zero matches, the Number of Status Responses from Inquiry (RC) message will be the only

response to the State of Inquiry (SOI) and the transaction is considered complete.

There is no difference between the Number of Status Responses from Inquiry (RC) message returned here and the

Number of Status Responses from Inquiry (RC) message returned by the Search Inquiry (CD01) transaction.



Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Inquiry for AKA Data

(IK) message



sent ('00' - '15')























Pending)












values.



(CD20) data store.

The only differences between the MPR Data for Match on Inquiry Transaction (RD) returned here and the MPR Data

for Match on Inquiry Transaction (RD) message returned by the Search Inquiry (CD01) transaction are the conditions

under which AKA data is included on the message.

The MPR Data for Match in Inquiry Transaction (RD) message must include:


Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Inquiry for AKA Data

(IK) message



sent ('00' - '15')













The MPR Data for Match in Inquiry Transaction (RD) message must include the following from the Master Pointer

(CD20) record:



concatenated with the CD20 Driver License Number (D,DLNUM)











(BPESSD)











Unique Complete)






associated with the CD20 record, where present:



Name Group (BPENG3)



The third occurrence of Person AKA Name Group (BPENG3), set to the third most recent CD22 Person



Driver AKA Name (DDVKNM) set to the most recent CD22 Person AKA Name Group (BPENG3)


RULESŗ

Driver AKA 2nd Name (DDVKN2) set to the second most recent CD22 Person AKA Name Group


FORMATTING RULESŗ

Driver AKA 3rd Name (DDVKN3), set to the third most recent CD22 Person AKA Name Group


FORMATTING RULESŗ


AKA ST-DLN (CD24) records associated with the CD20 record, where present and the AKA ST-DLN Status

(DDLKST) = ŘAř:













values.


One Status Request (SC) message is sent if:

The CDLIS Central Site finds exactly one Master Pointer (CD20) match

The Jurisdiction Code - Licensing (DDLJUR) on the CD20 record does not equal the Message Originator

(GMSORG) on the AKA Data (IK) message

There is no difference between the Status Request (SC) message sent here and the Status Request (SC) message sent by

the Search Inquiry (CD01) transaction.





The Status Request (SC) message must include the following from the CD20 record:



Pointer (CD20)







(BPESSD)

If the State of Inquiry (SOI) is at a version older than 5.1 and the State of Record (SOR) is at version 5.1 or

greater:




(BPESSD)












values.

CD05.2.4.4 Transmission of Inquiry for AKA Data (IK) Message with Errors

If the CDLIS Central Site encounters errors on the original Inquiry for AKA Data (IK) message that preclude further

processing, the Central Site returns the message to the inquirer with Error Block appended (up to 5 occurrences).



(02/2) blocks.

















CD06 EMPLOYER INQUIRY




Description

The Employer Inquiry is a request for a driverřs current State of Record (SOR). The Commercial Motor Vehicle Safety

Act of 1986, states "Employers are prohibited from knowingly allowing a driver with multiple licenses to operate

company vehicles". The Employer Inquiry transaction provides the first step for employers to check a driverřs identity

and ensure compliance with the law. An employer seeking to conduct a background check uses this transaction to locate

the SOR that holds the applicant's Driver History Record (DHR). This inquiry does not provide the State of Recordřs

(SORřs) driver history data.

Participants

Third Party Provider

o Employer

o Third-Party Service Provider (TPSP) (on behalf of an employer)

CDLIS Central Site

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending an Employer Inquiry message to the CDLIS Central Site.

Upon receipt of the Employer Inquiry, the CDLIS Central Site:


o Retrieves MPRs that match on the Social Security Number (SSN) and the first five characters of the last

name


Inputs

The Employer Inquiry message includes the driverřs name and SSN.



o If a match is found, the Central Site returns the driver's license number and jurisdiction code combination,

name, date of birth, gender, and the available AKA information


Central Site

o If the Employer Inquiry does not pass the edit validations performed by the CDLIS Central Site, the


Post-Requisites

If an inquirer has access to jurisdiction driver histories, it may retrieve the appropriate driver history from the

SOR returned from the CDLIS search. Alternatively, the inquirer may contact the SOR on its own to obtain more

detailed information about the driver.





References

Reference

#


Ref1 CDLIS System

Specifications


Federal Regulations

Regulation # Description

49 CFR 384.225(e)(4) Record of Violations







IW Employer Inquiry

RW Employer Inquiry Response 1





CD06.1 Request Employer Search (Third-Party Provider)

CD06.1.1 Transmission of Employer Inquiry (IW) Message

The Third-Party Provider initiates the employer inquiry process by sending an Employer Inquiry (IW) message to the

CDLIS Central Site.

The Employer Inquiry (IW) message must include:

For all inquirers, regardless of the version implemented:


For those inquirers at version 5.1 or greater:


For those inquirers at a version older than 5.1:

Driver Name (DDVNAM) set to the driver's name

The Employer Inquiry (IW) message may optionally include:


Return as Received Text/Block (GRRECV) set to any value desired by the third-party provider


values.

CD06.2 Perform Employer Search (CDLIS Central Site)

CD06.2.1 Reception of Employer Inquiry (IW) Message

Upon receipt of an Employer Inquiry (IW) message from an inquirer, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Employer Inquiry (IW) message. If errors are


validation failures may be reported on a single error message. The Central Site must report as many errors as it can to

minimize the number of resends.

Validate the password and determine the implementation status of the Third Party Provider by performing ŘCDJ1.2


Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Employer Inquiry (IW)

message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Employer

Inquiry (IW) message

Authorization Function (BJUAFN) set to ŖIWŗ










Driver SSN - CDLIS (DDVSS6) must be present.

Error Text: 'SSN REQUIRED'





The Driver Name (DDVNAM) must be present.

Error Text: 'REQUIRED BLOCK IS MISSING'




Must be numeric





Driver SSN - CDLIS (DDVSS6), if present, must pass the following additional validation:

All the digits cannot be all 9s

Error Text: 'PARTIAL MATCH EXISTS ON FILE'










CD06.2.2.4 Data Look-up Errors



Person SSN Last 5 Digits (BPESSD) using the last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) on the

Employer Inquiry (IW) message. Do not retrieve any record that contains a Substitute SSN (all 9řs).

Retrieve only those records where the Driver SSN Type (DDVSSI) is not = ŘSř.

At least one record must exist.

Error Text: 'NO MATCH EXISTS ON FILE'





If more than one record exists

Error Text: 'MORE THAN ONE MATCH EXISTS ON FILE’



Driver Social Security Number (DDVSSN) using the Driver SSN - CDLIS (DDVSS6) on the Employer

Inquiry (IW) message.

A record must exist.

Error Text: 'NO MATCH EXISTS ON FILE'


Access all Duplicate Pointer (CD23) records associated with the above Master Pointer (CD20) record where the

Master Pointer Unique Indicator (DCDPUI) equals ŘDř (Possible Duplicate) or ŘPř (Mark Unique Pending).

A record must not exist.

Error Text: 'MORE THAN ONE MATCH EXISTS ON FILE’

CD06.2.2.5 Retrieved Record Match Errors


The name information on the Employer Inquiry (IW) message must correspond with the name information on the

existing Master Pointer (CD20). The comparison is performed as described in 7.2 Name Comparison

Error Text: 'PARTIAL MATCH EXISTS ON FILE'

CD06.2.3 Retrieval

CD06.2.3.1 Retrieval of AKA ST-DLNs

Access the three most recent AKA ST-DLN (CD24) records associated with the above Master Pointer (CD20) record by

Date of Last Update (GRCUDT) and Time of Last Update (GRCUTM), where AKA ST-DLN Status (DDLKST) = ŖAŗ.

CD06.2.3.2 Retrieval of AKA Names

Access the three most recent AKA Name (CD22) records associated with the above Master Pointer (CD20) record by

Date of Last Update (GRCUDT) and Time of Last Update (GRCUTM).


CD06.2.4.1 Transmission of Employer Inquiry Response (RW) Message

The Central Site returns an Employer Inquiry Response (RW) message if one, and only one, Master Pointer (CD20)

record is found.

The Number of Employer Inquiry Response (RW) message must include:


Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Employer Inquiry (IW)

message


Message Match Count (GMSCNT) set to Ř01ř















In addition, the Employer Inquiry Response (RW) message must include the following from the Master Pointer (CD20)

record:






For those Inquirers at version 5.1 or greater:



(BPESSD)

For those Inquirers at a version older than 5.1:





In addition, the Employer Inquiry Response (RW) message must include the following from the three most recent AKA

Name (CD22) records (based on Date of Last Update (GRCUDT) and Time of Last Update (GRCUTM)) associated

with the CD20 record, where present:



Name Group (BPENG3)






Driver AKA Name (DDVKNM), set to the most recent CD22 Person AKA Name Group (BPENG3)


RULESŗ

Driver AKA 2nd Name (DDVKN2) set to the second most recent CD22 Person AKA Name Group


FORMATTING RULESŗ

Driver AKA 3rd Name (DDVKN3) set to the third most recent Person AKA Name Group (BPENG3)






RULESŗ

In addition, the Employer Inquiry Response (RW) message must include the following from the three most recent AKA

ST-DLN (CD24) records associated with the CD20 record, where present and the AKA ST-DLN Status (DDLKST) =

ŘAř:








In addition, the Employer Inquiry Response (RW) message may optionally include:





values.

CD06.2.4.2 Transmission of Employer Inquiry (IW) Message with Errors

If the CDLIS Central Site encounters errors on the original Employer Inquiry (IW) message that preclude further




(02/2) blocks.

CD06.3 Process Employer Search Results (Third-Party Provider)


In response to the Employer Inquiry (IW) message, the Third-Party Provider may receive one of two separate messages:

Employer Inquiry Response (RW) message

Employer Inquiry (IW) message returned with errors

CD06.3.2 Reception

CD06.3.2.1 Reception of the Employer Inquiry Response (RW)

When the CDLIS Central Site has located one, and only one, driver matching the inquiry criteria, the Central Site sends

the Employer Inquiry Response (RW) message to the requester.

The Employer Inquiry Response (RW) message includes:






Message Match Sequence Indicator (GMSMSI)

Message Match Limit Exceeded Indicator (GMSLEI)






Jurisdiction Code - State of Record (GMSSOR)


Message Driver Duplicate Indicator (GMSDUP)




The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6)





Driver Name (DDVNAM




The Employer Inquiry Response (RW) may optionally include:














CD06.3.2.2 Reception of the Employer Inquiry (IW) Message with Errors

If errors are encountered in the original Employer Inquiry (IW) message, it is returned in its original state with the

addition of up to five explanations in the error block. When an error is encountered, Master Pointer Record information

is not be provided. Therefore, the error conditions must be corrected and another Employer Inquiry (IW) message

transmitted to retrieve driver data.

CD06.3.3 Notes

The identification data provided by the Third-Party CDLIS transaction is a small subset of all available information on a

driver. The Third-Party CDLIS provider may seek additional information from the driver's current state of record

(SOR).

Because certain circumstances may prevent the complete transfer of previous convictions and withdrawals from one





jurisdiction to another, the Third-Party CDLIS provider may also follow up with the driver's previous SORs (indicated

by any AKA DLNs provided on the Employer Inquiry Response (RW) message) for additional convictions or

withdrawals that their Motor Vehicle Records may contain.



CD07 ADD NEW DRIVER


CD07 ADD NEW DRIVER


Description

The Add New Driver transaction enables a State of Record (SOR) to add a Master Pointer Record (MPR) to the CDLIS

Central Site. An MPR is added to CDLIS within 10 days of issuing a Commercial Drivers License (CDL) to a driver

who is believed to have never previously held one or when a non-commercial driver is convicted of a violation in a

commercial motor vehicle.

Participants


o U.S. jurisdiction

CDLIS Central Site

Pre-Requisites

The SOR uses the transaction after complying with federal regulations regarding the issuance of a CDL, such as

checking CDLIS and PDPS. Ref1

To help ensure the success of the transaction, a prospective SOR submits a Search Inquiry,Ref2

Search Inquiry Preceding

Add New Driver, Ref2

or a Verification Inquiry Ref3

to the CDLIS Central Site to verify that no MPR exists for the driver.

Standard Processing

An SOR sends an Add Driver message to the CDLIS Central Site.

Upon receipt of the Add Driver message, the CDLIS Central Site:


o Checks to see if the jurisdiction code and driverřs license number combination already exists

o Checks to see if any drivers can be considered possible duplicates for the new driver; if so, issues

notifications of possible duplicate driver to all SORs affected, including the SOR that submitted the Add

Driver messageRef4

o Adds the new MPR to the Central Site

o Returns a confirmation to the SOR

Inputs

The Add Driver message includes all driver identification information required to be stored at the CDLIS Central Site.

Optionally, the message may include other descriptive and AKA data.





o A confirmation message that the driver was successfully added

o A notification message if a possible duplicate driver already exists

Central Site to other SORs:

o If one or more possible duplicate drivers already exist, the Central Site sends notifications to the SORs for

those drivers


Central Site

o If the Add Driver message does not pass the edit validations performed by the CDLIS Central Site, the



CD07 ADD NEW DRIVER



Post-Requisites

Once the MPR is added to the CDLIS Central Site, the SOR is responsible for maintaining the data on the driver

and responding to inquiries.

Upon receipt of a notification of possible duplicate driver, the SOR works with the other SORs to resolve the

duplicate. Please refer to the Business Process Overview section of ŖCDA1 DUPLICATE DRIVER

PROCESSŗ.

References

Reference

#


Ref1 CDLIS State

Procedures Manual

Section 7, Procedures for Issuing a Commercial

Driverřs License

Ref2 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref3 CDLIS System

Specifications


Ref4 CDLIS System

Specifications

CDA1 DUPLICATE DRIVER PROCESS

Ref5 CDLIS System

Specifications


Federal Regulations


49 CFR §384.207 Notification of Licensing

49 CFR §383.73(f) State Procedures

http://www.fmcsa.dot.gov/rules-regulations/administration/fmcsr/fmcsrruletext.asp?section=383.73#49CFR383.73(f)



CD07 ADD NEW DRIVER


Messages related to Process 7.2.3 (CDA1.1) are described in the CDA1 PIC.



UA Add Driver

CB Confirm Driver Added 1

NA Possible Duplicate 0 - 5



CD07 ADD NEW DRIVER


CD07.1 Request Addition of Driver (State of Record (SOR))


The Add New Driver transaction enables a State of Record (SOR) to add a Master Pointer Record (MPR) to the CDLIS

Central Site. An MPR is added to CDLIS within 10 days of issuing a Commercial Drivers License (CDL) to a driver

who is believed to have never previously held one or when a non-commercial driver is convicted of a violation in a

commercial motor vehicle.

CD07.1.2 Transmission of Add Driver (UA) Message

The Add Driver (UA) message must include:


Driver License Jurisdiction Number (DDLJDL) set to the DLN established by the jurisdiction

Driver SSN - CDLIS (DDVSS6) set to the SSN provided by the applicant

Driver Date of Birth (DDVDOB) set to the date of birth provided by the applicant

Person Name Group (BPENGP) set to the name provided by the applicant

Driver Current Sex (DDVSX3) set to the driver sex

The Add Driver (UA) message may optionally include:

AKA Driver License Jurisdiction Number (DDLJD2) set to another driver license number previously held by the

driver

AKA 2nd Driver License Jurisdiction Number (DDLJD3) set to a second driver license number previously held

by the driver

AKA 3rd Driver License Jurisdiction Number (DDLJD4) set to a third driver license number previously held by

the driver

Message AKA DLN Count (GMSCDL) set to the number of other driver's licenses associated with the new

driver







Message AKA Name Count (GMSCNM) set to the number of other names associated with the new driver

Driver AKA Social Security Number AKA (DDVKSS)

Message AKA Social Security Number Count (GMSCSS) set to the number of other SSNs associated with the

new driver


Note that while the above data elements are listed as optional, if the information is available, jurisdictions must

provide it.


values.

Transitional note:

After all Jurisdictions are at version 5.1 or greater, the following information will no longer be supported on the Add

Driver (UA) message:




CD07 ADD NEW DRIVER


CD07.2 Add New Driver (CDLIS Central Site)

CD07.2.1 Reception of Add Driver (UA) Message

Upon receipt of an Add Driver (UA) message from a jurisdiction, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Add Driver (UA) message. If errors are detected, the

Central Site stops processing and returns the original message to the sender with error fields set. Up to five validation

failures may be reported on a single error message. The Central Site must report as many problems as it can to minimize

the number of resends.

Validate the password and determine the implementation status of the State of Record (SOR) by performing ŘCDJ1.2


Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Add Driver (UA) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Add Driver

(UA) message

Authorization Function (BJUAFN) set to ŖUAŗ






The code identifying the jurisdiction must be present in positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL).

Error Text: 'STATE CODE REQUIRED'

The driverřs license number must be present in positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL).

Error Text: 'DRIVER LICENSE NUMBER REQUIRED'








Transitional note:

Until such time as all Jurisdictions have implemented version 5.1 or greater, a State of Record (SOR) that has

implemented version 5.1 or greater will include the Driver Current Sex (DDVSX3) on the Add Driver (UA)



CD07 ADD NEW DRIVER


message. Once all Jurisdictions have implemented version 5.1 or later, the Add Driver (UA) message will no

longer support Driver Current Sex (DDVSX3).

Driver Current Sex (DDVSX3) must be present.

Error Text: 'SEX CODE REQUIRED'




Driver Current Sex (DDVSX3) must be present.

Error Text: 'SEX CODE REQUIRED'





DICTIONARYŗ.


Driver Date of Birth (DDVDOB) be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.


Driver SSN - CDLIS (DDVSS6) must pass the following validations:

Must be numeric





Positions 1 - 2 of the AKA Driver License Jurisdiction Number (DDLJD2), if present, must contain one of the

following:

ŘMXř




DATA DICTIONARYŗ


Positions 1 - 2 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3) , if present, must contain one of

the following:

ŘMXř






CD07 ADD NEW DRIVER


DATA DICTIONARYŗ


Positions 1 - 2 of the AKA 3rd Driver License Jurisdiction Number (DDLJD4) , if present, must contain one of

the following:

ŘMXř




DATA DICTIONARYŗ


Message AKA DLN Count (GMSCDL) must be spaces or valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID DRIVERS LICENSE COUNT'

Message AKA Name Count (GMSCNM) must be spaces or valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID NAME COUNT'



PERSON NAME STANDARD (2008) VALIDATIONS".





"APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008) VALIDATIONS".







for specific error text associated with this error.






Transitional note:

Until such time as all Jurisdictions have implemented version 5.1 or greater, a State of Record (SOR) that has

implemented version 5.1 or greater will include the Driver Current Sex (DDVSX3) on the Add Driver (UA)

message. Once all Jurisdictions have implemented version 5.1 or later, the Add Driver (UA) message will no



CD07 ADD NEW DRIVER


longer support Driver Current Sex (DDVSX3).

Driver Current Sex (DDVSX3) must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID SEX CODE'





Driver Current Sex (DDVSX3) must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.


If present, Driver AKA Name (DDVKNM) must conform to the requirements listed in ŖAPPENDIX E.1



If present, Driver AKA 2nd Name (DDVKN2) must conform to the requirements listed in ŖAPPENDIX



If present, Driver AKA 3rd Name (DDVKN3) must conform to the requirements listed in ŖAPPENDIX





The value in positions 1 - 2 of the Message Originator (GMSORG) must match the value in positions 1 - 2 of the

Driver License Jurisdiction Number (DDLJDL).

Error Text: 'STATE ORIGINATING TXN NOT EQUAL SOR'

If AKA Driver License Jurisdiction Number (DDLJD2) is present, the Message AKA DLN Count (GMSCDL)

must match the actual number of AKA ST/DLNs received in AKA Driver License Jurisdiction Number

(DDLJD2), AKA 2nd Driver License Jurisdiction Number (DDLJD3), and AKA 3rd Driver License Jurisdiction

Number (DDLJD4).

Error Text: 'DLN COUNT DOESNT MATCH NUM OF DLNS'

If positions 1 - 2 of the AKA Driver License Jurisdiction Number (DDLJD2) contain a value, then positions 3 -

27 must also contain a value.







CD07 ADD NEW DRIVER


If positions 1 - 2 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3) contain a value, then positions

3 - 27 must also contain a value.


If positions 3 - 27 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3) contain a value, then

positions 1 - 2 must also contain a value.


If positions 1 - 2 of the AKA 3rd Driver License Jurisdiction Number (DDLJD4) contain a value, then positions








Message AKA Name Count (GMSCNM) must match the actual number of Person AKA Name Group

(BPENG3) occurrences received.

Error Text: 'NAME COUNT DOESNT MATCH NUM NAMES'


If Driver AKA Name (DDVKNM) is present, the Message AKA Name Count (GMSCNM) must match the

actual number of AKA names received in Driver AKA Name (DDVKNM), Driver AKA 2nd Name (DDVKN2),

and Driver AKA 3rd Name (DDVKN3).



Ensure the Master Pointer (CD20) record being added does not already exist. Access the Master Pointer (CD20) data

store by:


(DDLJDL) from the Add Driver (UA) message; and


(DDLJDL) from the Add Driver (UA) message

No record should exist.

Error Text: 'DUPLICATE ST/DLN ON FILE'

Ensure the Master Pointer (CD20) record being added does not already exist as an AKA record. Access the AKA ST-

DLN (CD24) data store by:

Driver Licensing AKA Jurisdiction (DDLJU2) using positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL) from the Add Driver (UA) message; and

Driver License AKA Number (DDLNU1) using positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL) from the Add Driver (UA) message

Access the associated Master Pointer (CD20).

Access the three most recent AKA ST-DLN (CD24) occurrences associated with the Master Pointer (CD20)



CD07 ADD NEW DRIVER


where AKA ST-DLN Status (DDLKST) = ŘAř. The three most recent occurrences are determined by the Date of

Last Update (GRCUDT) and Time of Last Update (GRCUTM).

The AKA ST-DLN (CD24) accessed above using the Driver License Jurisdiction Number (DDLJDL) from the

Add Driver (UA) message must not be one of the three most recent active AKA ST-DLN (CD24) occurrences.


Ensure that any new AKA ST-DLN (CD24) records being added do not already exist on the Master Pointer (CD20) or

AKA ST-DLN (CD24) data stores:

First AKA State-Driver License Number

If AKA Driver License Jurisdiction Number (DDLJD2) is present on the Add Driver (UA) message, access the

Master Pointer (CD20) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the AKA Driver License Jurisdiction

Number (DDLJD2) from the Add Driver (UA) message; and

Driver License Number (DDLNUM) using positions 3 - 27 of the AKA Driver License Jurisdiction

Number (DDLJD2) from the Add Driver (UA) message



If AKA Driver License Jurisdiction Number (DDLJD2) is present on the Add Driver (UA) message, access the

AKA ST-DLN (CD24) data store by:

Driver Licensing AKA Jurisdiction (DDLJU2) using positions 1 - 2 of the AKA Driver License

Jurisdiction Number (DDLJD2) from the Add Driver (UA) message; and

Driver License AKA Number (DDLNU1) using positions 3 - 27 of the AKA Driver License Jurisdiction









Second AKA State-Driver License Number

If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the Add Driver (UA) message, access

the Master Pointer (CD20) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the AKA 2nd Driver License


Driver License Number (DDLNUM) using positions 3 - 27 of the AKA 2nd Driver License Jurisdiction




If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the Add Driver (UA) message, access

the AKA ST-DLN (CD24) data store by:

Driver Licensing AKA Jurisdiction (DDLJU2) using positions 1 - 2 of the AKA 2nd Driver License




CD07 ADD NEW DRIVER


Driver License AKA Number (DDLNU1) using positions 3 - 27 of the AKA 2nd Driver License

Jurisdiction Number (DDLJD3) from the Add Driver (UA) message








Third AKA State-Driver License Number

If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the Add Driver (UA) message, access


Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the AKA 3rd Driver License


Driver License Number (DDLNUM) using positions 3 - 27 of the AKA 3rd Driver License Jurisdiction




If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the Add Driver (UA) message, access


Driver Licensing AKA Jurisdiction (DDLJU2) using positions 1 - 2 of the AKA 3rd Driver License


Driver License AKA Number (DDLNU1) using positions 3 - 27 of the AKA 3rd Driver License

Jurisdiction Number (DDLJD4) from the Add Driver (UA) message








CD07.2.3 Perform the Duplicate Driver Process

If the Add Driver (UA) message is valid, perform "CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)ŗ

in the ŖCDA1 DUPLICATE DRIVER PROCESSŗ to check for possible duplicate drivers.

Pass the following information to the ŖCDA1 DUPLICATE DRIVER PROCESSŗ:




Message Locator (GMSLOC)

For those Initiating SORs at version 5.1 or greater:




CD07 ADD NEW DRIVER


For those Initiating SORs at a version older than 5.1:



Upon completion, the ŖCDA1 DUPLICATE DRIVER PROCESSŗ returns information that is used to set fields on the

Confirm Driver Added (CB) message.

CD07.2.4 Updates

If the Add Driver (UA) message is valid, add a new record to the Master Pointer (CD20) data store using the following

fields from the Add Driver (UA) message:


CD20 Jurisdiction Code - Licensing (DDLJUR) set to positions 1 - 2 of the Driver License Jurisdiction

Number (DDLJDL)

CD20 Driver License Number (DDLNUM) set to positions 3 - 27 of the Driver License Jurisdiction

Number (DDLJDL)

Person Date of Birth (BPEDOB) set to the Driver Date of Birth (DDVDOB)

Person SSN Last 5 Digits (BPESSD) set to the last 5 positions of Driver SSN - CDLIS (DDVSS6)

Driver SSN Type (DDVSSI) set to ŘSř if the Driver SSN - CDLIS (DDVSS6) is all 9s; set to ŘPř if the

Driver SSN Ŕ CDLIS (DDVSS6) begins with Ř000'; and otherwise set to ŘAř


Person Name Group (BPENGP) set to the Driver Name (DDVNAM)

Transitional note:

Until such time as all Jurisdictions have implemented version 5.1 or greater, the CDLIS Central Site must

set the Driver Social Security Number (DDVSSN) as specified below, in addition to setting the Person

SSN Last 5 Digits (BPESSD) as specified above. Once all Jurisdictions have implemented version 5.1 or

later, the CDLIS Central Site will set only the Person SSN Last 5 Digits (BPESSD).

Driver Social Security Number (DDVSSN) set to the Driver SSN - CDLIS (DDVSS6)

Transitional note:


set the Driver Sex (DDVSEX) as specified below. Once all Jurisdictions have implemented version 5.1

or later, the CDLIS Central Site will not set this field any more.

Driver Sex (DDVSEX) set to the Driver Current Sex (DDVSX3)

Transitional note:


set the Driver Date of Birth (DDVDOB) as specified below, in addition to setting the Person Date of Birth

(BPEDOB) as specified above. Once all Jurisdictions have implemented version 5.1 or later, the CDLIS

Central Site will set only the Person Date of Birth (BPEDOB).

Driver Date of Birth (DDVDOB) set to the Driver Date of Birth (DDVDOB)


Person Name Group (BPENGP) set to the Driver Name (DDVNAM) converted into the format specified

in APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008) (with the transliteration and

truncation codes set to "U")




Set other fields on the new Master Pointer (CD20) record as follows:



CD07 ADD NEW DRIVER


Message SOR Change in Progress Indicator (GMSSCH) set to ŘNř

Record Creation Date (GRCCDT) set to current system date

Record Creation Time (GRCCTM) set to current system time

Date of Last Update (GRCUDT) set to current system date

Time of Last Update (GRCUTM) set to current system time

If any of the following fields are included on the Add Driver (UA) message:










The first occurrence of Person AKA Name Group (BPENG3), set to Driver AKA Name (DDVKNM) on

the Add Driver (UA) message as converted into the format specified in APPENDIX E.2 - AAMVA

PERSON NAME STANDARD (2008) (with the transliteration and truncation codes set to "U")

The second occurrence of Person AKA Name Group (BPENG3) , set to Driver AKA 2nd Name

(DDVKN2) on the Add Driver (UA) message as converted into the format specified in APPENDIX E.2 -

AAMVA PERSON NAME STANDARD (2008) (with the transliteration and truncation codes set to "U")

The third occurrence of Person AKA Name Group (BPENG3) , set to Driver AKA 3rd Name (DDVKN3)

on the Add Driver (UA) message as converted into the format specified in APPENDIX E.2 - AAMVA

PERSON NAME STANDARD (2008) (with the transliteration and truncation codes set to "U")

Perform the ŖCDF1 CREATE AKA FROM UPDATE MESSAGE (CDLIS Central Site)ŗ process.


CD07.2.5.1 Transmission of Confirm Driver Added (CB) Message

When updates are successfully completed, the CDLIS Central Site sends a Confirm Driver Added (CB) message to the

State of Record (SOR).

The Confirm Driver Added (CB) message must include:

Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Add Driver (UA) message


Message Match Count (GMSCNT) set to the Number of Duplicate Drivers Identified which is returned by the

ŖCDA1 DUPLICATE DRIVER PROCESSŗ, up to a maximum of Ř5ř

Message Match Indicator (GMSIND) set to 'Y' if the Number of Duplicate Drivers Identified is greater than Ř0ř;



Last Match Indicator (GMSLMI) set to 'Y' if the Number of Duplicate Drivers Identified is Ř0ř or Ř1ř; otherwise

set to ŘNř

Message Match Limit Exceeded Indicator (GMSLEI) set to 'Y' if the Number of Duplicate Drivers Identified is

greater than Ř5ř; otherwise set to ŘNř

Message SOR Change in Progress Indicator (GMSSCH) set to 'N' if Number of Duplicate Drivers Identified is

Ř0ř; otherwise set to the First Dup CSOR Indicator returned by the ŖCDA1 DUPLICATE DRIVER PROCESSŗ



CD07 ADD NEW DRIVER


Message Driver Duplicate Indicator (GMSDUP) set to 'N' if Number of Duplicate Drivers Identified is Ř0ř;

otherwise set to 'Y'

The Confirm Driver Added (CB) message may optionally include:


Jurisdiction Code - State of Record (GMSSOR) set to the First Dup SOR returned by the ŖCDA1

DUPLICATE DRIVER PROCESSŗ



Message AKA DLN Count (GMSCDL) set to the number of AKA ST-DLNs on the original Add New

Driver (UA) message.

Message AKA Name Count (GMSCNM) set to the number of AKA Names on the original Add New

Driver (UA) message.




values.

CD07.2.5.2 Transmission of Add Driver (UA) Message with Errors

If the CDLIS Central Site encounters errors on the original Add Driver (UA) message that preclude further processing,

the Central Site returns the message to the inquirer with Error Block appended (up to 5 occurrences).



(02/2) blocks.

CD07.3 Process Add Driver Responses (State of Record (SOR))


During the creation of a new driver pointer on the CDLIS Central Site, the prospective SOR receives one of two

messages:

Confirm Driver Added (CB)

Add Driver (UA) returned with errors

If the Confirm Driver Added (CB) message is received, the prospective SOR may additionally receive one or more

Possible Duplicate (NA) messages, indicating that the driver has been identified as a possible duplicate driver. See

section ŘCDA1 DUPLICATE DRIVER PROCESSř for details.

CD07.3.2 Reception

CD07.3.2.1 Reception of Confirm Driver Added (CB) Message

Once the new driver has been added to the CDLIS Central Site, the Central Site sends a Confirm Driver Added (CB)

message to the SOR.

The Confirm Driver Added (CB) message includes:







CD07 ADD NEW DRIVER







The Confirm Driver Added (CB) message may optionally include:





Upon receipt of the Confirm Driver Added (CB) message, the prospective SOR becomes the SOR and is responsible for

maintaining the required driver history.

The SOR should check the Message Driver Duplicate Indicator to determine whether the new driver has any possible

duplicates which must be resolved.

CD07.3.2.2 Reception of Add Driver (UA) Message with Errors

If errors are encountered in the original Add Driver (UA) message, it is returned in its original state with the addition of

up to five explanations in the error block. When an error is encountered, the driver is not be added. Therefore, the error

conditions must be corrected and another Add Driver (UA) message transmitted to add the driver.







Description

The Change State of Record (CSOR) transaction is used to transfer a Driver History Record (DHR) from an Old State

of Record (Old SOR) to a New State of Record (New SOR) and to reflect this change in the Master Pointer Record

(MPR).

The new jurisdiction officially becomes the New SOR when the CSOR transaction is initiated. Simultaneously, the old

jurisdiction becomes the Old SOR. The new roles are reflected on the MPR once the CDLIS Central Site retrieves and

updates the MPR.

To simplify this description, the terms ŖNew SORŗ and ŖOld SORŗ are used to refer to the new and old jurisdictions,

respectively, regardless of whether or not the CSOR has been initiated.

The CSOR transaction is not used when Canadian or Mexican CDL holders move to the U.S. In these cases, the driver

is added as a new driver.Ref1

The previous CDLřs jurisdiction code and driverřs license number combination may be

entered in the corresponding AKA fields. The transaction is also not used for U.S. CDL holders moving to Mexico or

Canada.

When a driver is downgrading from a CDL to a non-CDL license, the issuing state must initiate the CSOR process and

accept responsibility as the New State of Record.

Participants

New State of Record (SOR)

o U.S. jurisdiction

CDLIS Central Site

CDLIS Common Validation Processor

Old State of Record (SOR)

o U.S. jurisdiction

Pre-Requisites

The New SOR:

o Submit a Verification Inquiry,Ref2

Verification Inquiry Preceding Change State of Record,Ref2

or a Search

Inquiry Ref3

and verify the response to ensure the driver is identified correctly and to check the driver

status

o Submit a PDPS Inquiry to the National Driver Register's (NDR) Problem Driver Pointer System (PDPS)

Ref4

o Initiate a "10-year history check", if one has not been completed Ref5

It is recommended that the New SOR:

o Submit a Search InquiryRef3

with the changed data prior to initiating the CSOR if any primary

identification data is to be changed during the CSOR. This allows the New SOR to identify any potential

duplicate drivers before the CSOR is initiated

o Submit a State-to-State History Request Ref6

and review the driver history.

o Work with the Old SOR to resolve any data problems identified during the inquiry and review process

before initiating the CSOR.

Standard Processing

The New SOR sends a CSOR update message to the CDLIS Central Site.





Upon receipt of the CSOR update message, the CDLIS Central Site:


o If the New SOR is changing the driverřs name, date of birth, and/or Social Security Number (SSN),

checks to see if any drivers can be considered possible duplicates for the new driver; if so, issues

notifications of possible duplicate driver to all SORs affected, including the SOR that submitted the

CSOR update messageRef7

o Retrieves the driverřs MPR

o Updates the MPR by noting the initiator of the CSOR transaction as the New SOR and the recipient of the

CSOR request as the Old SOR

o Returns a confirmation to the New SOR

o Sends a DHR request to the Old SOR*

Upon receipt of the DHR request, the Old SOR:


o Retrieves the DHR

o Adds the New SOR's jurisdiction code and driver license number combination to its DHR so it can

respond to status and history requests from the New SOR until such time as the CSOR is complete**

o Returns driver history information*** to the New SOR

The CDLIS Common Validation Processor performs edits on the history information before forwarding it to the

New State of Record (SOR)

Upon receipt of the response message from the Old State of Record (SOR) via the CDLIS Common Validation

Processor, the New State of Record (SOR) performs any additional required validations not already performed

by the CDLIS Common Validation Processor.

The New SOR performs the following within 96 hours:

o Issues a CDL or denies the application

o Creates the DHR and post the history

o Sends a confirmation to the CDLIS Central Site

Upon receipt of the confirmation from the New SOR, the CDLIS Central Site:

o Validates the information

o Verifies the information matches the updated MPR

o Sends confirmations to both the New SOR and Old SOR that the CSOR is complete

* Once the Central Site has forwarded a DHR Request to the Old SOR, the transaction cannot be aborted or

reversed; it is carried through to its normal conclusion. Even if the New SOR denies the application and does not issue a

CDL, the CSOR is completed.

** The New SOR is permitted to submit status and history requests to the Old SOR until the CSOR is complete.

*** If the SOR has implemented the Medical Certificate requirements, the driver history information includes

information pertaining to the driverřs medical certificate, where available.

Inputs

The CSOR includes the driverřs identification data (driver's license number and jurisdiction code combination, name,

date of birth, Social Security Number) consistent with the information returned from the inquiries performed prior to

submission of the update.Ref8

It also includes the New SORřs jurisdiction code and driverřs license number combination.

The CSOR optionally includes changes or corrections to the driver identification information. Alternatively the New

SOR can initiate a Change Data transaction after completion of the CSOR.Ref9

The driverřs name, date of birth and Social Security Number combination must first be verified with the Social Security

Administration (SSA).


Central Site to the New SOR:





o A confirmation message that the CSOR is in progress

o A notification message if driver identification data was changed and a possible duplicate driver already

exists. Please refer to the Business Process Overview section of ŖCDA1 DUPLICATE DRIVER

PROCESSŗ.

Central Site to the Old SOR:

o The Central Site sends driver identification information to the SOR for lookup

Old SOR to the New SOR:

o The Old SOR sends the driverřs history data*. The messages include information identifying and

describing the person, and the license, permits, and up to 50 convictions, 50 accidents, 50 withdrawals,

and 50 withdrawal-convictions linkages, if available and allowed under jurisdiction law. If the driver has

more than 50 ACD convictions, withdrawals or withdrawal-conviction(s) linkages on record, the SOR

transmits the 50 most recent ACD convictions, withdrawals and withdrawal-conviction(s) linkages, and

mails all the ACD convictions, withdrawals, and linkages.Ref10

New SOR to the CDLIS Central Site:

o A confirmation message that the driver history was successfully received and processed

Central Site to the New SOR and Old SOR:

o A confirmation message that the CSOR is complete

* If the Old SOR has implemented the Medical Certificate requirements, the driverřs history data includes

information pertaining to the driverřs medical certificate, where available


Central Site

o If the CSOR update message does not pass the edit validations performed by the CDLIS Central Site, the

Central Site returns an error to the message originator. No further processing is performed (e.g., the SOR

is not changed at the CDLIS Central Site even if a new license has been issued prior to the receipt of

history).

Old SOR*

o If the Old SOR cannot locate the driver upon receipt of a DHR request, the Old SOR returns an error.

New SOR*

o If a driver history response does not pass the edit validations performed by the New SOR, the New SOR

returns an error to the Old SOR.

CDLIS Central Site

o If a completion confirmation received from a New SOR does not pass the edit validations performed by

the CDLIS Central Site, the CDLIS Central Site returns an error to the New SOR.

* When the Old SOR issues or receives an error as described above, the Old SOR may request that the Central Site

resend driver identification information for lookup.

The identification of possible duplicate drivers does not halt processing of the CSOR transaction, nor does it prevent a

redrive request from being processed.

Post-Requisites

New SOR

o Once a New SOR has initiated a Change State of Record transaction, the New SOR has taken ownership

of the individualřs CDLIS Master Pointer Record. It is neither possible to abort nor reverse the process.

The process must be carried through to its normal conclusion. This is true even if data problems on the

DHR cause the CSOR to be put in suspense.

o If the New SOR desires to undo the effect of the Change State of Record after it is complete, there are two

methods that may be employed. The Old SOR may be contacted and asked to do either of the following.

In both cases, the two SORs must work closely to ensure the pointer and all driver history are in their

original, pre-CSOR form.





initiate another Change State of Record transaction to resume ownership of the driverřs CDLIS

Master Pointer Record. In this case the original Old SOR will need to submit a Change Data

(CD09) or Update AKA Data (CD15) transaction to correct any AKA data modified during the

CSORs (at a minimum, the AKA DLNs will have been changed). Extreme care must be taken to

ensure the history received from the original New SOR contains only information included on the

driverřs history prior to the erroneous CSOR.

recreate the pointer after deletion of the MPR by the New SOR.

o After a CSOR, if a New SOR cannot determine whether any previous SOR took any required driver

control action based on an underlying conviction, the New SOR takes driver control action. If optional

linkages (for conviction ACD codes that are not federally mandated) are not maintained on the DHR and

transmitted in history, the New SOR either:

Manually (by mail or phone) contacts the previous SOR to determine whether any driver control

action was required, and, if so, taken, under the previous SORřs laws, or

Takes driver control action, unless the driver can obtain proof from the previous SOR that any

driver control action either was not required or was already taken.

Old SOR

o Once the CSOR is initiated, the Old SOR:

No longer owns, and therefore can no longer update, the MPR data

o Returns all State-to-State Status Requests and State-to-State History Requests to the inquirer in error

unless the request was sent by the New SOR prior to completion of the CSOR transaction

o Once the CSOR is completed, the Old SOR:

Does not respond to an inquiry on a driver for which it is no longer the SOR, but returns all

inquiries in error

Clearly annotates its DHR to indicate it is no longer the SOR

References

Reference

#


Ref1 CDLIS System Specifications CD07 ADD NEW DRIVER

Ref2 CDLIS System Specifications CD02 VERIFICATION INQUIRY

Ref3 CDLIS System Specifications CD01 SEARCH INQUIRY

Ref4 PDPS System Specifications

Ref5 PDPS Driver's License Number

Survey Transaction

Implementation Planning Guide

10-Year History Check

Supplement to the PDPS State

Procedures Manual

Ref6 CDLIS System Specifications CD04 STATE-TO-STATE HISTORY

REQUEST

Ref7 CDLIS System Specifications CDA1 DUPLICATE DRIVER

PROCESS

Ref8 CDLIS State Procedures Manual Section 8.3, Jurisdiction Changes Driver

Identification Information





References

Reference

#


Ref9 CDLIS System Specifications CD09 CHANGE DATA

Ref10 CDLIS State Procedures Manual Appendix C, Procedures for Mailing

Driver History

Ref11 CDLIS System Specifications 4 CDLIS ERROR PROCESSING

Federal Regulations


49CFR 384.207(c) The transaction must be completed within 10 days.





Messages related to Process 8.2.3 (CDA1.1) are described in "CDA1 DUPLICATE DRIVER PROCESS".


Message

Type

Message Name Cardinality Message

Type

Message Name Cardinality

UD Change State of Record H4 Driver History Accidents 0 - 1

CG Confirm CSOR In Progress 1 H5 Driver History Withdrawals 0 - 1

SD CSOR History Request 1 H7 Driver History Withdrawal-Conviction

Links

0 - 1

HD CSOR Driver History Response 1 CC Confirm DHR Received/Processed 1

H2 Driver History Permit Info 0 - 1 CE Confirm CSOR Complete 1

H3 Driver History Convictions 0 - 1 NF Confirm CSOR Complete 1






Message

Type

Message Name Cardinality Message

Type

Message Name Cardinality




SR Redrive Request

SD Redriven CSOR History Request 1







SD Redriven CSOR History Request 1





CD08.1 Request Change State of Record (New State of Record (NSOR))


Initiation of the Change State of Record (CSOR) transaction represents the new jurisdiction's decision to issue a

Commercial Driver License (CDL) and accept the responsibility as the State of Record or accept the responsibility as

the State of Record when downgrading to a non-CDL*. Before initiating this transaction the New SOR (NSOR) must

verify the existence of the driver at the CDLIS Central Site via the Search Inquiry (CD01) transaction, the Verification

Inquiry (CD02) transaction, or the Verification Inquiry Preceding Change State of Record (CD02) transaction, and

perform the required checks as noted in the Business Process Overview above.

* The issuing state must accept responsibility as the New State of Record when the driver is downgrading from a CDL

to a non-CDL license.

Upon receipt of the inquiry responses from the Old SOR, the New SOR is responsible for confirming that the driver

represented in the response messages is the appropriate driver before taking any update actions (since the driver was

selected by the Old SOR based on DLN only). This is accomplished by verifying the primary driver identifying data

(Name, Date of Birth and Social Security Number) matches. The New SORI may also consider secondary driver

identifying data, such as Sex, Height, Weight, and Eye Color.

CD08.1.2 Transmission of Change State of Record (UD) Message

The SOR requesting the change submits the Change State of Record (UD) message to the CDLIS Central Site. The

Change State of Record (UD) message must contain:

System Release Code (GMSSRL) set to a valid value (ŘFř, or ŘHř) to indicate capabilities of the New SOR to

receive and process the driver history data elements introduced in Release 4.0.1.

Driver License Old Jurisdiction Number (DDLJD1) set to the following two data elements that compose the

existing driver license jurisdiction number:

o Old Jurisdiction Code (DDLJU5) set to the jurisdiction code of the Old SOR

o Old Driver License Number (DDLNU4) set to the driverřs license number in the Old SOR

Driver License Jurisdiction Number (DDLJDL) set to the following two data elements that compose the new

driver license jurisdiction number:

o Driver License Current Jurisdiction Code (DDLJU1) set to the jurisdiction code of the New SOR

o Driver License Number (DDLNUM) set to the driver's license number in the New SOR

Driver Old Date of Birth (DDVDO1) set to the date of birth of the applicant on the existing license

Driver Old Social Security Number (DDVSS1) set to the driver's SSN as recorded by the Old SOR

Person Old Name Group (BPENG1) set to the name of the applicant on the existing license


values.

If a correction to the driver information is needed, the Change State of Record (UD) message must additionally contain:

Driver Date of Birth (DDVDOB) set to the corrected driver date of birth

Driver SSN - CDLIS (DDVSS6) set to the corrected driver SSN

Person Name Group (BPENGP) set to the corrected driver name

Driver Current Sex (DDVSX3) set to the corrected driver sex

The Change State of Record (UD) message may optionally contain:

Return as Received Text/Block (GRRECV) set to any value desired by the New SOR.

Transitional note:

After all Jurisdictions are at version 5.1 or greater, the following information will no longer be supported on the

Change State of Record (UD) message:






CD08.2 Process CSOR Request (CDLIS Central Site)

CD08.2.1 Reception of Change State of Record (UD) Message

Upon receipt of a Change State of Record (UD) message from a jurisdiction, the CDLIS Central Site initiates validation

processing.

The Change State of Record (UD) message contains the following information, based on the implementation status of

the New SOR.

For all New States of Record (NSOR), regardless of the version implemented:

The Change State of Record (UD) message must contain:

System Release Code (GMSSRL)

Driver License Old Jurisdiction Number (DDLJD1)


Driver Old Date of Birth (DDVDO1)

Driver Old Social Security Number (DDVSS1)

The Change State of Record (UD) message may additionally contain:




For those New States of Record (NSOR) at version 5.1 or greater:


Person Old Name Group (BPENG1)




For those New States of Record (NSOR) at a version older than 5.1:


Driver Old Name (DDVNM1)







Transitional note:

After all Jurisdictions are at version 5.1 or greater, the following information will no longer be supported on the

Change State of Record (UD) message:










The CDLIS Central Site performs the following validations on the Change State of Record (UD) message. If errors are




Validate the password and determine the implementation status of the New State of Record (NSOR) by performing

ŘCDJ1.2 Verification of Message Originatorř using the following input:

Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Change State of Record (UD)

message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Change State

of Record (UD) message

Authorization Function (BJUAFN) set to ŖUDŗ



See "4 CDLIS ERROR PROCESSING" for more information on returning system errors.



The code identifying the old jurisdiction must be present in positions 1 - 2 of the Driver License Old Jurisdiction

Number (DDLJD1).


The old driverřs license number must be present in positions 3 - 27 of the Driver License Old Jurisdiction

Number (DDLJD1) must be present.


Driver Old Date of Birth (DDVDO1) must be present.


Driver Old SSN (DDVSS1) must be present.


The code identifying the new jurisdiction must be present in positions 1 - 2 of the Driver License Jurisdiction

Number (DDLJDL).


The new driverřs license number must be present in positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL).



At least one component field of Person Old Name Group (BPENG1) must be present







Driver Old Name (DDVNM1) must be present




Positions 1 - 2 of the Driver License Old Jurisdiction Number (DDLJD1) must contain one of the valid values in

the "United States" list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.


Driver Old Date of Birth (DDVDO1) must be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.


Driver Old SSN (DDVSS1) must be numeric and cannot be all zeroes.


Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) must contain one of the valid values in the

"United States" list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.


Driver Date of Birth (DDVDOB), if present, must be a valid date and formatted as specified in ŖAPPENDIX D -

DATA DICTIONARYŗ.



Must be numeric






System Release Code (GMSSRL), if present, must contain one of the valid values listed in ŖAPPENDIX D -

DATA DICTIONARYŗ.

Error Text: 'INVALID SYSTEM RELEASE CODE'

If present, Driver Current Sex (DDVSX3) must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.



Person Old Name Group (BPENG1) must conform to the requirements listed in "APPENDIX E.3 - AAMVA








If at least one component field of Person Name Group (BPENGP) is present, then Person Name Group

(BPENGP) must conform to the requirements listed in "APPENDIX E.3 - AAMVA PERSON NAME

STANDARD (2008) VALIDATIONS".




Driver Old Name (DDVNM1) must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ AAMVA



If present, Driver Name (DDVNAM) must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ




The value in positions 1 - 2 of the Message Originator (GMSORG) must match the value in positions 1 - 2 of the Driver

License Jurisdiction Number (DDLJDL).


The Driver SSN - CDLIS (DDVSS6), if present, can be all 9s only if the Driver Old Social Security Number (DDVSS1)

is all 9s.




Ensure that the Řoldř Master Pointer (CD20) record to be updated already exists. Access the Master Pointer

(CD20) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the Driver License Old Jurisdiction

Number (DDLJD1) from the Change State of Record (UD) message; and

Driver License Number (DDLNUM) using positions 3 - 27 of the Driver License Old Jurisdiction

Number (DDLJD1) from the Change State of Record (UD) message


Error Text: 'THE MSTR PTR REC RQSTD NOT ON FILE'

NOTE: The CDLIS Central Site searches only the Master Pointer (CD20) for a match. The ST-DLN Pointer

(CD24) is not searched.

Ensure that the Řnewř Master Pointer (CD20) record does not already exist. Access the Master Pointer (CD20)

data store by:


(DDLJDL) from the Change State of Record (UD) message; and


(DDLJDL) from the Change State of Record (UD) message







Access the ST-DLN Pointer (CD24) data store by:

Driver Licensing AKA Jurisdiction (DDLJU2) using positions 1 - 2 of the Driver License Jurisdiction

Number (DDLJDL) from the Change State of Record (UD) message; and

Driver License AKA Number (DDLNU1) using positions 3 - 27 of the Driver License Jurisdiction

Number (DDLJDL) from the Change State of Record (UD) message

No record should exist unless it is a Driver Licensing AKA Jurisdiction (DDLJU2) and Driver License AKA

Number (DDLNU1) combination previously used by the same driver. The CDLIS Central Site allows the reuse

of a ST-DLN, but only for the same driver.




The following data on the Change State of Record (UD) message must match the corresponding data on the

existing Master Pointer (CD20) record:

The Driver Old Date of Birth (DDVDO1) must match the CD20 Person Date of Birth (BPEDOB)

If the New State of Record (NSOR) is at version 5.1 or greater

Error Text: 'DATE OF BIRTH DOES NOT MATCH'

If the New State of Record (NSOR) is at a version older than 5.1


Additionally, the name information on the Change State of Record (UD) message must correspond with the

name information on the existing Master Pointer (CD20). The comparison is performed as described in 7.2

Name Comparison.


Error Text: 'NAME DOES NOT MATCH'

If the New State of Record (NSOR is at a version older than 5.1


The Message SOR Change in Progress Indicator (GMSSCH) on the existing Master Pointer (CD20) record must

equal ŘNř.

Error Text: 'MPR HAS CSOR IN PROG OR FLAG AS DUP'

The Řoldř Master Pointer (CD20) must not reflect the driver to be a possible duplicate. Access the Duplicate

Pointer (CD23) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the Driver License Old Jurisdiction

Number (DDLJD1) from the Change State of Record (UD) message; and

Driver License Number (DDLNUM) using positions 3 - 27 of the Driver License Old Jurisdiction

Number (DDLJD1) from the Change State of Record (UD) message

If a record is found, the Master Pointer Unique Indicator (DCDPUI) must equal ŘUř (Mark Unique Complete).









The last five positions of Driver Old SSN (DDVSS1) must match the CD20 Person SSN Last 5 Digits

(BPESSD)

Error Text: 'SSN DOES NOT MATCH'




Driver Old SSN (DDVSS1) must match the CD20 Driver Social Security Number (DDVSSN)


The CDLIS Central Site determines the implementation status of the Old State of Record (OSOR) by performing


Jurisdiction Code (BJUCDE) set to the Jurisdiction Code Ŕ Licensing (DDLJUR) on the CD20 record prior to

update

Authorization Function (BJUAFN) set to ŖSDŗ



If the Change State of Record (UD) message is valid, perform the Ŗ





CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)ŗ to check for possible duplicate drivers.

Pass the following information from the Change State of Record (UD) message (or from the Master Pointer (CD20)

where indicated) to the ŖCDA1 DUPLICATE DRIVER PROCESSŗ:


If present, Driver Date of Birth (DDVDOB), otherwise Driver Old Date of Birth (DDVDO1)

If present, Driver SSN - CDLIS (DDVSS6), otherwise Driver Old Social Security Number (DDVSS1)



If present, Person Old Name Group (BPENG1), otherwise Person Name Group (BPENGP)


If present, Driver Name (DDVNAM), otherwise Driver Old Name (DDVNM1)

If present, Driver Current Sex (DDVSX3), otherwise the CD20 Driver Sex (DDVSEX)


Confirm CSOR In Progress (CG) message.

CD08.2.4 Updates

If the Change State of Record (UD) message is valid, perform the ŖCDG1 CREATE AKA FROM MASTER

POINTER DATA (CDLIS Central Site)ŗ process.

Update the existing Master Pointer (CD20) data store using the following fields from the Change State of Record (UD)

message:

CD20 Jurisdiction Code - Licensing (DDLJUR) set to positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL)

CD20 Driver License Number (DDLNUM) set to positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL)

Set the following fields from the Change State of Record (UD) message, if present. If not present, retain the existing

value on CD20:




Driver Social Security Number (DDVSSN) set to Driver SSN - CDLIS (DDVSS6)


Driver SSN Type (DDVSSI) set to ŘSř if the Driver SSN - CDLIS (DDVSS6) is all 9s; set to ŘPř if the

Driver SSN Ŕ CDLIS (DDVSS6) begins with Ř000ř; and otherwise set to ŘAř

Driver Sex (DDVSEX) set to Driver Current Sex (DDVSX3)




Person Name Group (BPENGP) set to the Driver Name (DDVNAM) after conversion into the format

specified in 'APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)' (with the transliteration

and truncation codes set to "U")

Other fields are set as follows on the updated Master Pointer (CD20) record:

Message SOR Change in Progress Indicator (GMSSCH) set to ŘYř








Once updates and the ŖCDA1 DUPLICATE DRIVER PROCESSŗ are successfully completed, the CDLIS Central Site

creates and sends a response message to the New State of Record (NSOR) and a request for history to the Old State of

Record. Some of the elements on the request for history must be obtained from the Master Pointer (CD20) record prior

to update.

CD08.2.5.1Transmission of Confirm CSOR In Progress (CG) Message

The Confirm CSOR In Progress (CG) message must include:

Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Change State of Record (UD)

message


Message Match Count (GMSCNT) set to the Number of Duplicate Drivers Identified returned by the ŖCDA1

DUPLICATE DRIVER PROCESSŗ, up to a maximum of Ř5ř





set to ŘNř




Ř0ř; otherwise set to the First Dup CSOR Indicator as returned by the ŖCDA1 DUPLICATE DRIVER

PROCESSŗ



The Confirm CSOR In Progress (CG) message may optionally include:

Jurisdiction Code - State of Record (GMSSOR) set to the First Dup SOR returned by the ŖCDA1 DUPLICATE

DRIVER PROCESSŗ




values.

CD08.2.5.2 Transmission of CSOR History Request (SD) Message

The CSOR History Request (SD) message must include:



System Release Code (GMSSRL) set to the value on the Change State of Record (UD) message, which may be a

space.

The CSOR History Request (SD) message must include the following from the CD20 record prior to update:


Driver License Old Jurisdiction Number (DDLJD1) set to the CD20 Jurisdiction Code - Licensing

(DDLJUR) concatenated with the CD20 Driver License Number (DDLNUM)

Driver Old Date of Birth (DDVDO1) from the CD20 Driver Date of Birth (DDVDOB)





When both the Old SOR and New SOR are at version 5.1 or greater:

Person Old Name Group (BPENG1) from the CD20 Person Name Group (BPENGP)

The last 5 positions of Driver Old SSN (DDVSS1) from the CD20 Person SSN Last 5 Digits (BPESSD)

When both the Old SOR and New SOR are at a version older than 5.1:

Driver Old Name (DDVNM1) set to the value on the CD20 Person Name Group (BPENGP) as converted

into the format specified in ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ

Driver Old SSN (DDVSS1) from the CD20 Driver Social Security Number (DDVSSN)

When the Old SOR is at a version older than 5.1 but the New SOR is at version 5.1 or greater:



Driver Old SSN (DDVSS1) from the CD20 Driver Social Security Number (DDVSSN)

When the Old SOR is at version 5.1 or greater but the New SOR is at a version older than 5.1:



The last 5 positions of Driver Old SSN (DDVSS1) from the CD20 Person SSN Last 5 Digits (BPESSD)

The CSOR History Request (SD) message must include the following from the CD20 record after update:

For all New States of Record (SOR), regardless of the version implemented:


Pointer (CD20)



Driver Date of Birth (DDVDOB) from the CD20 Driver Date of Birth (DDVDOB)

When both the Old SOR and New SOR are at version 5.1 or greater:

Person Name Group (BPENGP) from the CD20 Person Name Group (BPENGP)

The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) from the CD20 Person SSN Last 5 Digits

(BPESSD)

When both the Old SOR and New SOR are at a version older than 5.1:

Driver Name (DDVNAM) set to the value from the CD20 Person Name Group (BPENGP) as converted


Driver SSN - CDLIS (DDVSS6) from the CD20 Driver Social Security Number (DDVSSN)

Driver Current Sex (DDVSX3) from the CD20 Driver Sex (DDVSEX)

When the Old SOR is at a version older than 5.1 but the New SOR is at version 5.1 or greater:



Driver SSN - CDLIS (DDVSS6) from the CD20 Driver Social Security Number (DDVSSN)

Driver Current Sex (DDVSX3) from the CD20 Driver Sex (DDVSEX)

When the Old SOR is at version 5.1 or greater but the New SOR is at a version older than 5.1:



The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) from the CD20 Person SSN Last 5 Digits

(BPESSD)






values.

CD08.2.5.3 Transmission of Change State of Record (UD) Message with Errors

If the CDLIS Central Site encounters errors on the original Change State of Record (UD) message that preclude further

processing, the Central Site returns the message to the inquirer with Error Block appended (up to 5 occurrences)

See "4 CDLIS ERROR PROCESSING" for information on formatting error messages.


(02/2) blocks.

CD08.3 Process History Request (Old State of Record)

Upon receipt of a CSOR History Request (SD) message, the SOR becomes the Old SOR. The Old SOR validates the

message, locates the requested driver's record, and, if no errors are found, the SOR transmits the history to the New

SOR. If the Old SOR finds any errors, the Old SOR returns an error message to the Central Site. This is done by

performing the ŖCDL1 PROCESS HISTORY REQUEST (STATE OF RECORD (SOR)/Old State of Record

(OSOR))ŗprocess.

CD08.4 Process History Received (New State of Record (NSOR))


After submitting the Change State of Record (UD) message, the New SOR receives one of two messages:

Confirm CSOR In Progress (CG) message

Change State of Record (UD) message returned with errors

If the Confirm CSOR In Progress (CG) message is received, the New SOR may additionally receive one or more

Possible Duplicate (NA) messages, indicating that the driver has been identified as a possible duplicate driver. See

section ŘCDA1 DUPLICATE DRIVER PROCESSř for details.

CD08.4.2 Reception

CD08.4.2.1 Reception of the Confirm CSOR In Progress (CG) Message

By sending the Confirm CSOR in Progress (CG) message to the New SOR, the CDLIS Central Site acknowledges the

CSOR is in-progress. The Confirm CSOR in Progress (CG) message contains:




Message Match Sequence Id (GMSMSI)






System Release Code (GMSSRL), if available

After receiving the Confirm CSOR in Progress (CG) message, the Inquirer becomes the New SOR and must respond to

requests for driver information as the SOR. Until the CSOR is completed and the New SOR has the complete driver

history, however, the New SOR must respond to a request for driver information with an error indicating

ŖCONFIRMATION OF NEW SOR, BUT DHR NOT READYŗ and Processing Status Flag (GPROST) = Ř05ř. The

New SOR may therefore have to update its driver record to indicate that the CSOR is currently in progress until it has





posted all driver history and received the associated Confirm CSOR Complete (CE) message

CD08.4.2.2 Reception of History Message(s)

Upon receipt of history information, the inquirer performs the ŖCDM1 PROCESS HISTORY RESPONSE

(INQUIRER)ŗ process.

CD08.4.2.3 Reception of Change State of Record (UD) Message with Errors

If the CDLIS Central Site detects an error or is unable to locate the driver requested on the Change State of Record

(UD), the CDLIS Central Site returns the Change State of Record (UD) as originally submitted with the following

exceptions:

NCB Error Block (GNCBER) set to 'Y'

Process Status (GPROST) set to '01' (logic error)




After receiving and processing a valid driver's history, the New SOR transmits a Confirm DHR Received/Processed

(CC) message to the CDLIS Central Site. If errors are encountered in the driver history, the New SOR returns the

CSOR Driver History Response (HD) message or the erroneous history message, to the Old SOR.

CD08.4.3.1 Transmission of Confirm DHR Received/Processed (CC) Message

The Confirm DHR Received/Processed (CC) message must include:


Driver Old Date of Birth (DDVDO1) set to the value on the original Change State of Record (UD) message

Driver Date of Birth (DDVDOB) set to the driver's current DOB (if not changed, this will be the same as

DDVDO1)

Driver License Old Jurisdiction Number (DDLJD1) set to the value on the original Change State of Record (UD)

message

Driver License Jurisdiction Number (DDLJDL) set to the ST/DLN (combination of jurisdiction code and driver's

license number)

Driver Old Social Security Number (DDVSS1) set to the value on the original Change State of Record (UD)

message

Driver SSN - CDLIS (DDVSS6) set to the driver's current SSN (if not changed, this will be the same as

DDVSS1)

Person Old Name Group (BPENG1) set to the value on the original Change State of Record (UD) message

Person Name Group (BPENGP) set to the driver's current name (if not changed, this will be the same as Person

Old Name Group (BPENG1))

Transitional Note:

Until all states have implemented this transaction, the Confirm DHR Received/Processed (CC) message may

optionally include:

Driver Current Sex (DDVSX3) set to the value on the original Change State of Record (UD) message

Once all states have implemented, Driver Current Sex (DDVSX3) will no longer be supported on the Confirm

DHR Received/Processed (CC) message.


values.

The Confirm DHR Received/Processed (CC) message may optionally include the following:





Return as Received Text/Block (GRRECV) set to the value on the original message

CD08.5 Resolve History Errors (State of Record (SOR)/Old SOR)

If errors are encountered on the CSOR Driver History Response (HD) message, the message is returned to the originator

of the CSOR Driver History Response (HD) message (i.e., the SOR) with the error(s) identified. The SOR/Old SOR

performs the ŖCDE1 RESOLVE HISTORY ERRORS (STATE OF RECORD (SOR)/OLD SOR)ŗ process.

CD08.6 Process SOR Responses (CDLIS Central Site)

CD08.6.1 Reception

The CDLIS Central Site receives one of two messages:

Confirm DHR Received/Processed (CC) message from the New State of Record (SOR), if it successfully

received the driver history from the Old SOR

CSOR History Request (SD) message with error(s) from the Old SOR in response to the originally submitted

CSOR History Request (SD) message, if the Old SOR finds an error and cannot process the request

Upon receipt of a Confirm DHR Received/Processed (CC) message, the CDLIS Central Site initiates validation

processing.

Upon receipt of a CSOR History Request (SD) with error(s), no validations are performed.

The Confirm DHR Received/Processed (CC) message will contain the following information:










Transitional Note:

Until all states have implemented this transaction, the Confirm DHR Received/Processed (CC) message

may optionally include:

Driver Current Sex (DDVSX3) set to the value on the original Change State of Record (UD) message

Once all states have implemented, Driver Current Sex (DDVSX3) will no longer be supported on the

Confirm DHR Received/Processed (CC) message.








The validation checks described below are performed on the Confirm DHR Received/Processed (CC) message. If

errors are detected, the Central Site stops processing and returns the original message to the sender with error fields set.





Up to five validation failures may be reported on a single error message. The Central Site must report as many problems

as it can to minimize the number of resends.

Validate the password and determine the implementation status of the New State of Record (NSOR) by performing


Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Confirm DHR

Received/Processed (CC) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Confirm DHR

Received/Processed (CC) message

Authorization Function (BJUAFN) set to ŖCCŗ



See "4 CDLIS ERROR PROCESSING" for information on returning system errors.




Number (DDLJD1).










(DDLJDL).



(DDLJDL).





At least one component field of Person Old Name Group (BPENG1) must be present.









Driver Old Name (DDVNM1) must be present.










DICTIONARYŗ.


Driver Old SSN (DDVSS1) must pass the following validations:

Must be numeric







DICTIONARYŗ.



Must be numeric





Transitional Note:

Until all states have implemented this transaction, the following validation must be performed. Once all states

have implemented, Driver Current Sex (DDVSX3) will no longer be supported on the Confirm DHR

Received/Processed (CC) message.

Driver Current Sex (DDVSX3), if present, must contain one of the valid values listed in ŖAPPENDIX D -

DATA DICTIONARYŗ.







Person Old Name Group (BPENG1) must conform to the requirements listed APPENDIX E.3 - AAMVA

PERSON NAME STANDARD (2008) VALIDATIONS.


for specific error text associated with this error.

Person Name Group (BPENGP) must conform to the requirements listed APPENDIX E.3 - AAMVA PERSON

NAME STANDARD (2008) VALIDATIONS.



For all New States of Record (NSOR) at a version older than 5.1:




Driver Name (DDVNAM), must conform to the requirements listed in the ŖAPPENDIX E.1 Ŕ AAMVA




The Transaction Originator (GTRORG) must match the Message Originator (GMSORG).

Error Text: 'INVALID BILLING ID'




The Driver SSN - CDLIS (DDVSS6) can be all 9s only if the Driver Old Social Security Number (DDVSS1) is all 9s.





(DDLJDL) from the Confirm DHR Received/Processed (CC) message; and


(DDLJDL) from the Confirm DHR Received/Processed (CC) message



Access the AKA ST-DLN (CD24) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the Driver License Old Jurisdiction Number

(DDLJDL1) from the Confirm DHR Received/Processed (CC) message; and

Driver License Number (DDLNUM) using positions 3 - 27 of the Driver License Old Jurisdiction Number





(DDLJD1) from the Confirm DHR Received/Processed (CC) message

One or more records associated with the existing Master Pointer (CD20) must exist with the AKA ST-DLN Status

(DDLKST) set to ŘAř.

Error Text: 'OLD ST/DLN DOES NOT MATCH THE MPR AKA ST/DLN'

If more than one record is found, select the record with the most recent Date of Last Update (GRCUDT) and Time of

Last Update (GRCUTM).


The name information on the Confirm DHR Received/Processed (CC) message must correspond with the name

information on the existing Master Pointer (CD20). The comparison is performed as described in 7.2 Name

Comparison





The following data on the Confirm DHR Received/Processed (CC) message must match the corresponding data on the



The Driver Date of Birth (DDVDOB) must match the CD20 Person Date of Birth (BPEDOB)






The last five positions of Driver SSN Ŕ CDLIS (DDVSS6) must match the Person SSN Last 5 Digits

(BPESSD)






Driver SSN - CDLIS (DDVSS6) must match the Driver Social Security (DDVSSN)


The CDLIS Central Site determines the implementation status of the Old State of Record (OSOR) by performing


Jurisdiction Code (BJUCDE) set to the Jurisdiction Code Ŕ Licensing (DDLJUR) on the CD20 record prior to

update





Authorization Function (BJUAFN) set to ŖNFŗ


CD08.6.3 Updates

CD08.6.3.1 Updates After Receiving the Confirm DHR Received/Processed (CC) Message

If the Confirm DHR Received/Processed (CC) message is valid, update the existing Master Pointer (CD20) record:

Message SOR Change in Progress Indicator (GMSSCH) set to ŘNř



CD08.6.3.2 Updates After Receiving the CSOR History Request (SD) Message in Error

The CDLIS Central Site treats a received CSOR History Request (SD) message with error(s) as explained in '4.4

Confirmation Errors'. The CDLIS Central Site stops processing the Change State of Record transaction for the CSOR

History Request (SD) message.

CD08.6.4 Transmission Upon Receipt of Confirm DHR Received/Processed (CC) Message

When updates are successfully completed, the CDLIS Central Site notifies both the New State of Record and the Old

State of Record that the Change State of Record (CSOR) is complete.

CD08.6.4.1 Transmission of Confirm CSOR Complete (NF) Message to the Old SOR

The Confirm CSOR Complete (NF) message is not sent if the Confirm DHR Received/Processed (CC) is returned with

errors.

The Confirm CSOR Complete (NF) message must include:

Processing Status (GPROST) set toŘ00ř

Message Destination (GMSDST) set to the Driver License Old Jurisdiction Number (DDLJDL) on the Confirm

DHR Received/Processed (CC) message

The Confirm CSOR Complete (NF) message must include the following from the corresponding field on the Confirm

DHR Received/Processed (CC) message:

For all Old States of Record (SOR), regardless of the version implemented:



For those Old States of Record (SOR) at version 5.1 or greater:


The last 5 positions of Driver Old SSN (DDVSS1)

For those Old States of Record (SOR) at a version older than 5.1:


Driver Old SSN (DDVSS1)


values.

Note: The Confirm CSOR Complete (NF) message is not sent if the Confirm DHR Received Processed (CC) message

is returned with errors.





CD08.6.4.2 Transmission of Confirm CSOR Complete (CE) Message to the New SOR

The Confirm CSOR Complete (CE) message must include:


Message Destination (GMSDST) set to the Message Originator (GMSORG) on the Confirm DHR

Received/Processed (CC) message.

The Confirm CSOR Complete (CE) message may optionally include:




values.

Note: The Confirm CSOR Complete (CE) message is not sent if the Confirm DHR Received Processed (CC) message

is returned with errors.

CD08.6.4.3 Transmission of Confirm DHR Received/Processed (CC) Message with Errors

If the CDLIS Central Site encounters errors on the original Confirm DHR Received/Processed (CC) message that

preclude further processing, the Central Site returns the message to the inquirer with Error Block appended (up to 5

occurrences).



(02/2) blocks.

CD08.7 Confirm CSOR Complete (New SOR)

If no errors are encountered on the Confirm DHR Received/Processed (CC) message, the CDLIS Central Site will

notify the New SOR that the Change State of Record transaction is complete via the Confirm CSOR Complete (CE)

message. The New SOR no longer may send driver status or history requests to the Old SOR for the driver who has

transferred.

If the CDLIS Central Site encounters errors on the Confirm DHR Received/Processed (CC) message, the message is

returned to the New SOR. The New SOR must correct the errors and retransmit the Confirm DHR Received/Processed

(CC) to the Central Site.

CD08.7.1 Reception of the Confirm CSOR Complete (CE) Message

The Confirm CSOR Complete (CE) message will contain:



The Confirm CSOR Complete (CE) message may optionally contain:


After receiving the Confirm CSOR Complete (CE) message, the New SOR must respond to history requests by

providing the appropriate response messages. The Processing Status (GPROST) will no longer be set to Ř05ř. The

New SOR may therefore have to update its driver record to indicate that the CSOR has successfully completed.

CD08.7.2 Reception of Confirm DHR Received/Processed (CC) Message with Errors

If the CDLIS Central Site encounters errors on the Confirm DHR Received/Processed (CC) message, the message is

returned to the New SOR.

The Confirm DHR Received/Processed (CC) message with errors includes:
















The Confirm DHR Received/Processed (CC) message with errors may optionally include:


Transitional Note:

Until all states have implemented this transaction, the Confirm DHR Received/Processed (CC) message with

errors may optionally include:


Once all states have implemented, Driver Current Sex (DDVSX3) will no longer be supported on the Confirm

DHR Received/Processed (CC) message with errors.


CD08.8 Confirm CSOR Complete (Old SOR)

Upon reception of the Confirm DHR Received/Processed (CC) message, the CDLIS Central Site notifies the Old SOR

that the Change State of Record transaction is complete via the Confirm CSOR Complete (NF) message. While the Old

SOR must respond to the New SOR prior to receiving the Confirm CSOR Complete (NF) message, after its receipt, the

Old SOR must now respond to any request for information about the driver who has transferred with ŖNOT CURRENT

SORŗ.

CD08.8.1 Reception of the Confirm CSOR Complete (NF) Message

The Confirm CSOR Complete (NF) message contains:





The last 5 positions of Driver Old SSN (DDVSS1)


CD08.8.2 Updates

Upon receipt of the Confirm CSOR Complete (NF) message, the Old SOR must remove the New SORřs jurisdiction

code and driver license number from its on-line record or somehow reflect that the CSOR is now complete. After this

record update, the Old SOR must no longer respond to status or history requests from any sources, including the New

SOR.

Upon successful completion of the CSOR, the Old SOR must ensure it retains all required records for the appropriate

length of time (see CDLIS State Procedures Manual).





CD08.8.3 Notes

Upon successful completion of the CSOR, the Old SOR must ensure it retains all required records for the appropriate

length of time (see State Procedures Manual) and mark its database to indicate that it is no longer the SOR.

In rare circumstances, a jurisdiction will have an MPR for a driver for whom it no longer maintains a driver history (a

'broken pointer'). At this stage of the transaction, this can only occur if the driver history is deleted after the driver

history has been sent to the New SOR. In this case, the jurisdiction will not be able to locate the driver on its database

and will return the Confirm CSOR Complete (NF) in error. If the Confirm CSOR Complete (NF) is returned, it will be

exactly as received with the following exceptions (also see "4 CDLIS ERROR PROCESSING"):



Message Match Indicator (GMSIND) set to 'N'


Processing Status (GPROST) set to '01' (logic error)


CD08.9 Send Redrive Request (Old State of Record or New State of Record)


When a Change State of Record (CSOR) transaction suspends, the Redrive Request (SR) message provides an Ŗon

demandŗ mechanism for either the Old State of Record or the New State of Record to request that the CSOR History

Request (SD) message be resent from the Central Site to the Old SOR.

Prior to sending Redrive Request (SR), the initiator of the Redrive Request (SR) message must confirm that the Old

SOR has corrected the problem that caused the Change State of Record (CSOR) transaction to suspend.

An automated CSOR History Request (SD) message redrive is also available. It provides redrives on a scheduled basis

whenever a Master Pointer Record is in suspense. The Ŗon demandŗ redrive can be used when the problem that caused

the suspension has been corrected before the automated redrive is due to be sent.

CSOR suspensions can occur for a variety of reasons, but the Redrive Request (SR) message is typically used in the

following circumstances:

The Old SOR did not reply to the original CSOR History Request (SD) message

The Old SOR returned the original CSOR History Request (SD) message in error

The Old SOR received one or more of the driver history messages in error

Redrive requests cannot be used to address Change State of Record (UD) errors. They also cannot be used for errors that

occur after the Message SOR Change in Progress Indicator (GMSSCH) is reset to ŘNř (upon successful processing of a

valid Confirm DHR Received/Processed (CC) message). Both these error situations must be resolved using the

conventional methods described in the CDLIS State Procedures Manual.

CD08.9.2 Transmission of Redrive (SR) Message

Either the OSOR or the NSOR submits the Redrive Request (SR) message to the CDLIS Central Site. The Redrive

Request (SR) message must contain business data as it appeared on the original CSOR History Request (SD) message.

The Redrive Request (SR) message must contain the following values:

Driver License Old Jurisdiction Number (DDLJD1) set to the following two data elements:

o Old Jurisdiction Code (DDLJU5) set to the jurisdiction code of the Old SOR

o Old Driver License Number (DDLNU4) set to the old license number for the driver


Driver License Jurisdiction Number (DDLJDL) set to the following two data elements:

o Driver License Current Jurisdiction Code (DDLJU1) set to the jurisdiction code of the New SOR





o Driver License Number (DDLNUM) set to the driver's license number for the driver at the New SOR


values.

CD08.10 Process Redrive Request (Central Site)

CD08.10.1 Reception of Redrive (SR) Message

Upon receipt of a Redrive (SR) message from a jurisdiction, the CDLIS Central Site initiates validation processing.

CD08.10.2 Validation on Redrive (SR) Message

The CDLIS Central Site performs the following validations on the Redrive (SR) message.

Validate the password and determine the implementation status of the initiator of the Redrive (SR) message) by

performing ŘCDJ1.2 Verification of Message Originatorř using the following input;

Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Redrive Request (SR) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Redrive

Request (SR) message

Authorization Function (BJUAFN) set to ŖSRŗ





The code identifying the Old SOR must be present in positions 1 - 2 of the Driver License Old Jurisdiction Number

(DDLJD1).


The old driverřs license number must be present in positions 3 - 27 of the Driver License Old Jurisdiction Number

(DDLJD1) must be present.


The code identifying the New SOR must be present in positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL).


The driverřs license number must be present in positions 3 - 27 of the Driver License Jurisdiction Number (DDLJDL).





Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) must contain one of the valid values in the "United

States" list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.






Person Old Name Group (BPENG1) must conform to the requirements listed in "APPENDIX E.3 - AAMVA PERSON

NAME STANDARD (2008) VALIDATIONS"




Ensure the redrive request is for a valid MPR matching the New SORřs ST-DLN present on the Redrive Request (SR)

message:



(DDLJDL) from the Redrive Request (SR) message; and


(DDLJDL) from the Redrive Request (SR) message



Ensure the valid MPR has at least one AKA ST-DLN:

Access the AKA ST-DLN (CD24) data store associated with the existing Master Pointer (CD20). One or more

records must exist with the AKA ST-DLN Status (DDLKST) = ŘA. Select the record with the most recent Date

of Last Update (GRCUDT) and Time of last Update (GRCUTM).

Error Text: 'THE AKA REC RQSTD NOT ON FILE'

Ensure an original CSOR History Request (SD) message matching the New SORřs ST-DLN exists on the Central Site

message log:

Access the Message Log (CD29) data store by:

Driver License Number (DDLJDL) using Driver License Number (DDLJDL) from the Redrive Request

(SR) message

Test/Production Indicator (GTPIND) using a value of ŘPř

Application ID (GAPPID) using a value of Ř02ř

Message Type (GMSTYP) using a value of ŘSDř

Message Destination (GMSDST) using positions 1 - 2 of the Driver License Old Jurisdiction Number

(DDLJD1) from the Redrive Request (SR) message

Select the message with the most recent UNI Log Date (GUNLDT), UNI Log Time (GUNLTM), and UNI Log

Sequence (GUNLSQ).

Error Text: 'ORIGINAL SD NOT FOUND'


If the Central Site finds a valid MPR matching the New SORřs ST-DLN:

Verify the MPR match by ensuring the AKA ST-DLN matches the Old SORřs ST-DLN present on the Redrive

Request (SR) message:

The following data on the Redrive Request (SR) message must match the corresponding data on the

selected AKA ST-DLN (CD24) record:

o Positions 1 - 2 of the Driver License Old Jurisdiction Number (DDLJDL1) from the Redrive

Request (SR) message must match the CD24 AKA Jurisdiction Code Ŕ Licensing (DDLJU2)

o Positions 3 - 27 of the Driver License Old Jurisdiction Number (DDLJD1) from the Redrive

Request (SR) message must match the CD24 AKA Driver License Number (DDLNU1)





Error Text: 'OLD ST/DLN DOES NOT MATCH THE MPR AKA ST/DLN'

Ensure the MPR reflects that a CSOR is in progress:

The Message SOR Change in Progress Indicator (GMSSCH) on the existing Master Pointer (CD20)

record must not equal ŘNř.

Error Text: 'REDRIVE NOT AVAILABLE – CSOR FLAG = N'

If the Central Site finds a valid original CSOR History Request (SD) message matching the New SORřs ST-DLN on the

Central Site message log:

Ensure the original CSOR History Request (SD) is for the driver represented on the inbound Redrive Request

(SR):

The following fields on the inbound Redrive Request (SR) message must match the corresponding fields

on the CSOR History Request (SD) message selected from the Message Log (CD29):

Driver License Old Jurisdiction Number (DDLJDL1)



o Person Old Name Group (BPENG1). The comparison is performed as described in 7.2 Name

Comparison


Ensure the original CSOR History Request (SD) selected from the Message Log (CD29) is within the redrive

eligibility window (no more than 60 days old):

Compare the current date against the Message Locator (GMSLOC) on the CSOR History Request (SD)

message selected from the Message Log (CD29) message. The Message Locator (GMSLOC) must be no

more than 60 calendar days old.

Error Text: 'REDRIVE NOT AVAILABLE – SD > 60 DAYS OLD'

The Duplicate Driver Process is not performed upon receipt of a Redrive Request (SR) message.


CD08.10.3.1 Transmission of Redrive Request (SD)

For each valid Redrive Request (SR) message, the CDLIS Central Site redrives the CSOR History Request (SD) to the

Old State of Record by resending the original CSOR History Request (SD) message selected from the Message Log

(CD29).

CD08.10.3.2 Transmission of Redrive Request (SR) Message with Errors

If the CDLIS Central Site encounters errors on the original Redrive Request (SR) message that preclude further

processing, the Central Site returns the message to the Old SOR with Error Block appended (up to 5 occurrences).



(02/2) blocks.

CD08.11 Process Automated Redrive (Central Site)

The Automated Redrive process allows the CDLIS Central Site to automatically redrive CSOR History Request (SD)

messages to the Old SOR to complete suspended Change State of Record (CSOR) transactions.





An Ŗon demandŗ CSOR History Request (SD) message redrive is also available to either the OSOR or the NSOR. The

Ŗon demandŗ redrive can be used when the problem that caused the suspension has been corrected before the automated

redrive is due to be sent.

The following logical description assumes a scheduled batch approach, but the process may be technically implemented

in a variety of ways.

CD08.11.1 Retrieval

The CDLIS Central Site must be able to determine when an automated CSOR History Request (SD) is due to be

redriven and whether eligibility criteria are satisfied. Then it must format and redrive the message. The approach

described below is not meant to outline programming steps, but to describe the conditions and criteria under which an

automated redrive should occur.

Select all CSOR History Request (SD) messages from the Message Log (CD29) that are eligible for automated redrive.

Identify all master pointers where a CSOR suspension has occurred by selecting all records from the Master Pointer

(CD20) data store where the Message SOR Change in Progress Indicator (GMSSCH) is not equal to ŘNř.

For each retrieved Master Pointer (CD20), access the associated AKA ST-DLN (CD24) data store. One or more

records must exist with the AKA ST-DLN Status (DDLKST) = ŘAř. Select the record with the most recent Date of

Last Update (GRCUDT) and Time of last Update (GRCUTM).

Select the most recently sent CSOR History Request (SD) message from the Central Site message log for each

retrieved Master Pointer (CD20) record.

Access the Message Log (CD29) data store by:

o Test/Production Indicator (GTPIND) using a value of ŘPř

o Application ID (GAPPID) using a value of Ř02ř

o Message Type (GMSTYP) using a value of ŘSDř

o Message Destination (GMSDST) using the AKA Jurisdiction Code - Licensing (DDLJU2) from the

associated CD24 record selected above

o Driver License Number (DDLJDL) using the concatenated Jurisdiction Code - Licensing (DDLJUR)

and Driver License Number (DDLNUM) from the CD20 record

Select the CSOR History Request (SD) message with the most recent UNI Log Date (GUNLDT), UNI Log Time

(GUNLTM), and UNI Log Sequence (GUNLSQ).

For each CSOR History Request (SD) message selected, ensure the message is within the redrive eligibility

window.

Compare the current date against the date in positions 1 - 8 of the Message Locator (GMSLOC) on the CSOR

History Request (SD) message. The date in the Message Locator (GMSLOC) represents the date the original

CSOR History Request (SD) message was sent and the start of the eligibility window.

Ignore all Message Log (CD29) messages where the Message Locator (GMSLOC) is outside the eligibility

window. The recommended eligibility window is 60 days.

For each selected CSOR History Request (SD) message that is inside the eligibility window, ensure an

automated redrive is due to be sent:

o Compare the current date against the UNI Log Date (GUNLDT) on the CSOR History Request (SD)

message and compute the number of business days that have elapsed since the message was sent.

o Compare the number of business days elapsed against the Jurisdiction Automated Redrive Interval

(BJUARI) from the Authorized Function (CD2D) record selected above.

o Ignore all CSOR History Request (SD) messages where the number of business days elapsed is less

than the Jurisdiction Automated Redrive Interval (BJUARI).

The following table provides an example based on a current date of Ř20091211ř.





UNI Log Date

(GUNLDT)

Number of business

days elapsed without

Redrive

Jurisdiction

Automated Redrive

Interval (BJUARI)

Automated CSOR History

Request (SD) message

redrive due to be sent?

20091211 0 3 N

20091210 1 3 N

20091209 2 3 N

20091208 3 3 Y

20091207 4 3 Y

Note that an Řon demandř redrive causes the number of business days elapsed to be reset to 0. In other

words, an SD message that was redriven Řon demandř will not be redriven through the automated process

until the full redrive interval has been exceeded again Ŕ this assuming that the associated Change State of

Record did not complete successfully.

CD08.11.2 Transmission of Redriven CSOR History Request (SD)

The CDLIS Central Site redrives each CSOR History Request (SD) message that is eligible for automated redrive to the

Old State of Record.

CD08.11.3 Reporting.

The CDLIS Central Site reports on the outcome of this process each time it is run. The purpose of the report is to

facilitate process control, exception reporting, and statistical tracking.

CD08.12 Apply Common Validations (CDLIS Common Validation Processor)

The CDLIS Common Validation Processor performs validations on response messages as specified in ŖCDN1 APPLY

COMMON VALIDATIONS (CDLIS COMMON VALIDATION PROCESSOR)ŗ.



CD09 CHANGE DATA


CD09 CHANGE DATA


Description

The Change Data transaction is enables a State of Record (SOR) to update or correct data on a Master Pointer Record

(MPR) at the CDLIS Central Site.

Participants


o U.S. jurisdiction

CDLIS Central Site

Pre-Requisites

The SOR must comply with federal regulations to ensure the correct MPR will be updated. Ref1

To help ensure the success of the transaction, an SOR submits a Verification InquiryRef2

or a Verification Inquiry

Preceding Change Data/Mark Driver UniqueRef2

to the CDLIS Central Site to verify that the correct MPR is

identified.

Standard Processing

An SOR sends a Change Data message to the CDLIS Central Site.

Upon receipt of the Change Data message, the CDLIS Central Site:


o Checks to see if a possible duplicate is created; if so, issues notifications of possible duplicate driver to

all SORs affected, including the SOR that submitted the Change Data messageRef3

o Retrieves and updates the MPR as requested, unless a Change State of Record (CSOR) is in progress. If

both primary and AKA driver identification data is changing, the CDLIS Central Site first applies the

AKA data changes, and then applies the changes to the primary identification data. The update to primary

identification data moves the existing identification data (at the CDLIS Central Site) to the most recent

AKA identification data before adding the new identification data. The SOR takes this into account when

submitting changes to both primary and AKA driver identification data.


o Evaluates all changes to determine whether any drivers previously identified as possible duplicates will

no longer be duplicates once the record is updated; if so, issues notifications of duplicate resolution to all

SORs affected Ref4

Inputs

The Change Data message includes the driverřs identification data (driver's license number, Social Security Number,

name, date of birth) consistent with the information returned from the inquiries performed prior to submission of the

update. It also includes a count reflecting the number of new AKA values sent. All other MPR values are optionally

sent depending on what is being updated.



If no primary data element is changing, the jurisdiction may use the Update AKA Data transaction,Ref5

which provides

the ability to replace AKA data without affecting the primary Master Pointer Record data elements.


CDLIS Central Site to the SOR:

o A confirmation message that the driver was successfully updated

o A notification message if a possible duplicate driver already exists



CD09 CHANGE DATA


o A notification message if a duplicate driver was resolved

CDLIS Central Site to other SORs:

o A notification message if a driver that possibly duplicates a driver already established by the other SOR

was created on the CDLIS Central Site



Central Site

o If the Change Data message does not pass the edit validations performed by the CDLIS Central Site, the


Post-Requisites

Upon receipt of a notification of possible duplicate driver, the SOR works with other SORs to resolve the

duplicate. Please refer to the Business Process Overview section of ŖCDA1 DUPLICATE DRIVER

PROCESSŗ.

References

Reference

#


Ref1 CDLIS State

Procedures Manual

Section 8.3, Jurisdiction Changes Driver


Ref2 CDLIS System

Specifications


Ref4 CDLIS System

Specifications


Ref5 CDLIS System

Specifications

CD15 UPDATE AKA DATA

Ref6 CDLIS System

Specifications




CD09 CHANGE DATA


Messages related to Processes 9.2.3 (CDA1.1) and 9.2.5 (CDA1.3) are described in "CDA1 DUPLICATE DRIVER

PROCESS".



UC Change Data

CD Confirm Change Data Complete 1


NE Duplicate Resolved 0 - 5



CD09 CHANGE DATA


CD09.1 Request Change to Driver Data (SOR)


CDLIS provides an automated means for a SOR to change or correct data that exists on a Master Pointer Record at the

CDLIS Central Site. When a jurisdiction determines incorrect or missing driver information must be corrected or added

on the CDLIS Master Pointer Record, the SOR submits a Change Data (UC) message.

CD09.1.2 Transmission of Change Data (UC) Message

The Change Data (UC) message must include the following:


Message AKA DLN Count (GMSCDL) set to the number of AKA driver licenses being sent

Message AKA Name Count (GMSCNM) set to the number of AKA names being sent

Driver License Old Jurisdiction Number (DDLJD1) set to the current driver license number

Drivers Old Social Security Number (DDVSS1) set to the current driver SSN

Driver Old Date of Birth (DDVDO1) set to the current driver date of birth

Person Old Name Group (BPENG1) set to the current driver name

The Change Data (UC) message may optionally include the following (only those elements to be updated should be

sent):

Driver Date of Birth (DDVDOB) set to the corrected driver date of birth

Driver License Jurisdiction Number (DDLJDL) set to the corrected driver license number

AKA Driver License Jurisdiction Number (DDLJD2) set to the first ST/DLN (combination of jurisdiction code

and driver's license number) associated with the driver other than the current ST/DLN

AKA 2nd

Driver License Jurisdiction Number (DDLJD3) set to the second ST/DLN associated with the driver

other than the current driver's license number

AKA 3rd

Driver License Jurisdiction Number (DDLJD4) set to the third ST/DLN associated with the driver

other than the current ST/DLN

Driver SSN - CDLIS (DDVSS6) set to the corrected driver SSN

Person Name Group (BPENGP) set to the corrected driver name







Driver Current Sex (DDVSX3) set to the corrected driver sex

Return as Received Text/Block (GRRECV) set to any value desired by the message originator


values.

Transitional note:

After all Jurisdictions are at version 5.1 or greater, the following information will no longer be supported on the Change

Data (UC) message:




CD09 CHANGE DATA


CD09.2 Update Driver Record (CDLIS Central Site)

CD09.2.1 Reception of Change Data (UC) Message

Upon receipt of a Change Data (UC) message from a jurisdiction, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Change Data (UC) message. If errors are detected,

the Central Site stops processing and returns the original message to the sender with error fields set. Up to five





Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Change Data (UC) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Change Data

(UC) message

Authorization Function (BJUAFN) set to ŖUCŗ







Number (DDLJD1).







Drivers Old SSN (DDVSS1) must be present.




Error Text: 'NAME REQUIRED'






CD09 CHANGE DATA








DICTIONARYŗ.






DICTIONARYŗ.


Driver Date of Birth (DDVDOB), if present, must be a valid date and formatted as specified in ŖAPPENDIX D -

DATA DICTIONARYŗ.



Must be numeric







following:

ŘMXř




DATA DICTIONARYŗ


Positions 1 - 2 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3), if present, must contain one of

the following:

ŘMXř




DATA DICTIONARYŗ



CD09 CHANGE DATA



Positions 1 - 2 of the AKA 3rd Driver License Jurisdiction Number (DDLJD4), if present, must contain one of

the following:

ŘMXř




DATA DICTIONARYŗ


Message AKA DLN Count (GMSCDL) must be spaces or valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.


Message AKA Name Count (GMSCNM) must be spaces or valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.


Transitional note:

After all Jurisdictions are at version 5.1 or greater, the Driver Current Sex (DDVSX3) will no longer be

supported on the Change Data (UC) message.

Driver Current Sex (DDVSX3), if present, must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'SEX CODE INVALID'






If at least one component of Person Name Group (BPENGP) is present, the Person Name Group (BPENGP)

must conform to the requirements listed in "APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008)

VALIDATIONS".













CD09 CHANGE DATA
















Driver AKA Name (DDVKNM), if present, must conform to the requirements listed in the ŖAPPENDIX



Driver AKA 2nd Name (DDVKN2), if present, must conform to the requirements listed in the

ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ


Driver AKA 3rd Name (DDVKN3), if present, must conform to the requirements listed in the



















CD09 CHANGE DATA














Number (DDLJD4).


If the Driver License Jurisdiction Number (DDLJDL) is present, AKA 3rd Driver License Jurisdiction Number

(DDLJD4) must be spaces.

Error Text: 'PRIMARY AND MAX AKAS PRESENT ON CHANGE TXN'

The value in positions 1 - 2 of the Driver License Old Jurisdiction Number (DDLJD1) must be the same as

positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL).

Error Text: 'CHANGE OF STATE NOT ALLOWED ON CHANGE TXN'



Message AKA Name Count (GMSCNM) must match the actual number Person AKA Name Group (BPENG3)

occurrences received.


If at least one component field of the Person Name Group (BPENGP) is present, all component fields of the third

occurrence of Person AKA Name Group (BPENG3) must be spaces.







If the Driver Name (DDVNAM) is present, the Driver AKA 3rd Name (DDVKN3) must be spaces.



Ensure that the Řoldř Master Pointer (CD20) record to be updated already exists. Access the Master Pointer (CD20) data



CD09 CHANGE DATA


store by:


(DDLJD1) from the Change Data (UC) message; and


(DDLJD1) from the Change Data (UC) message



Ensure that the Řnewř Master Pointer (CD20) record does not already exist. If Driver License Jurisdiction Number

(DDLJDL) is present on the Change Data (UC) message, access the Master Pointer (CD20) data store by:


(DDLJDL) from the Change Data (UC) message; and


(DDLJDL) from the Change Data (UC) message






If AKA Driver License Jurisdiction Number (DDLJD2) is present on the Change Data (UC) message, access the

Master Pointer (CD20) data store by:


Number (DDLJD2) from the Change Data (UC) message; and


Number (DDLJD2) from the Change Data (UC) message

No record should exist except for the Master Pointer (CD20) retrieved above.


If AKA Driver License Jurisdiction Number (DDLJD2) is present on the Change Data (UC) message, access the

AKA ST-DLN (CD24) data store by:


Jurisdiction Number (DDLJD2) from the Change Data (UC) message; and



No record should exist where AKA ST-DLN Status (DDLKST) = ŘAř aside from those AKA ST-DLN (CD24)

records associated with the Master Pointer (CD20) retrieved above.



If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the Change Data (UC) message, access








CD09 CHANGE DATA




If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the Change Data (UC) message, access





Jurisdiction Number (DDLJD3) from the Change Data (UC) message





If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the Change Data (UC) message, access








If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the Change Data (UC) message, access





Jurisdiction Number (DDLJD4) from the Change Data (UC) message





The name information on the Change Data (UC) message must correspond with the name information on the existing

Master Pointer (CD20). The comparison is performed as described in 7.2 Name Comparison

If the State of Record (SOR) is at version 5.1 or greater


If the State of Record (SOR) is at a version older than 5.1


The following data on the Change Data (UC) message must match the corresponding data on the existing Master

Pointer (CD20) record:





CD09 CHANGE DATA







The last 5 digits of Driver Old SSN (DDVSS1) must match the CD20 Person SSN Last 5 Digits

(BPESSD)





The Message SOR Change in Progress Indicator (GMSSCH) on the existing Master Pointer (CD20) record must equal

ŘNř.


CD09.2.3 Updates

If the Change Data (UC) message is valid, add the new driver details to the Central Site as follows:

If any of the following fields are included on the Change Data (UC) message:













Then perform the ŖCDF1 CREATE AKA FROM UPDATE MESSAGE (CDLIS Central Site)ŗ process.

If any of the following fields are included on the Change Data (UC) message:




Driver SSN Ŕ CDLIS (DDVSS6)





CD09 CHANGE DATA




Then first perform the ŖCDG1 CREATE AKA FROM MASTER POINTER DATA (CDLIS Central Site)ŗ

process

Next update the existing Master Pointer (CD20) data store using the following fields from the Change Data (UC)

message, if present. If not present, retain the existing value on CD20:


CD20 Jurisdiction Code - Licensing (DDLJUR) set to positions 1 - 2 of the Driver License

Jurisdiction Number (DDLJDL)

CD20 Driver License Number (DDLNUM) set to positions 3 - 27 of the Driver License

Jurisdiction Number (DDLJDL)



Driver SSN Type (DDVSSI) set to ŘSř if the Driver SSN - CDLIS (DDVSS6) is all 9s; set to ŘPř if

the Driver SSN Ŕ CDLIS (DDVSS6) begins with Ř000ř; and otherwise set to ŘAř


Person Name Group (BPENGP) set to the driver name

Transitional note:

Until such time as all Jurisdictions have implemented version 5.1 or greater, the CDLIS Central

Site must set the Driver Social Security Number (DDVSSN) as specified below, in addition to

setting the Person SSN Last 5 Digits (BPESSD) as specified above. Once all Jurisdictions have

implemented version 5.1 or later, the CDLIS Central Site will set only the Person SSN Last 5

Digits (BPESSD).


Transitional note:


Site must set the Driver Sex (DDVSEX) as specified below. Once all Jurisdictions have

implemented version 5.1 or later, the CDLIS Central Site will not set this field any more.


Transitional note:


Site must set the Driver Date of Birth (DDVDOB) as specified below, in addition to setting the

Person Date of Birth (BPEDOB) as specified above. Once all Jurisdictions have implemented

version 5.1 or later, the CDLIS Central Site will set only the Person Date of Birth (BPEDOB).



Person Name Group (BPENGP) set to Driver Name (DDVNAM) as converted into the format

specified in 'APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)' (with the

transliteration and truncation codes set to "U")

Driver Date of Birth (DDVDOB) set to Driver Date of Birth (DDVDOB)

Driver Sex (DDVSEX) set to Driver Current Sex (DDVSX3)

Driver Social Security Number (DDVSSN) set to Driver SSN - CDLIS (DDVSS6)

Set other fields on the new Master Pointer (CD20) record as follows:




CD09 CHANGE DATA





CD09.2.4 Process Resolved Duplicates

If the Change Data (UC) message is valid and any of the following fields are present on the Change Data (UC) message:


















Use "CDA1.3 Process Resolved Duplicates (CDLIS Central Site)" in the ŖCDA1 DUPLICATE DRIVER PROCESSŗ

to check if any possible duplicate records have been resolved, and to send the associated Duplicate Resolved (NE)

messages.

Pass the following information from the Change Data (UC) message (or from the Master Pointer (CD20) where

indicated) to the ŖCDA1 DUPLICATE DRIVER PROCESSŗ:

If present, Driver License Jurisdiction Number (DDLJDL), otherwise DL Old Jurisdiction Number (DDLJD1)









CD09.2.5 Identify Possible Duplicate Drivers

If the Change Data (UC) message is valid and any of the following fields are present on the Change Data (UC) message:





CD09 CHANGE DATA

















Use "



CD09 CHANGE DATA


CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)" in the ŖCDA1 DUPLICATE DRIVER PROCESSŗ

to check for possible duplicate drivers.

Pass the following information from the Change Data (UC) message (or from the Master Pointer (CD20) where


If present, Driver License Jurisdiction Number (DDLJDL), otherwise DL Old Jurisdiction Number (DDLJD1)










Confirm Change Data Complete (CD) message.


CD09.2.6.1 Transmission of Confirm Change Data Complete (CD) Message

When updates and the ŖCDA1 DUPLICATE DRIVER PROCESSŗ are successfully completed, the CDLIS Central Site

sends a Confirm Change Data Complete (CD) message to the State of Record (SOR).

The Confirm Change Data Complete (CD) message must include:


Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Change Data (UC)

message


Message Match Count (GMSCNT) set to the Number of Duplicate Drivers Identified returned by the

ŖCDA1 DUPLICATE DRIVER PROCESSŗ, up to a maximum of Ř5ř

Message Match Indicator (GMSIND) set to 'Y' if the Number of Duplicate Drivers Identified is greater

than Ř0ř; otherwise set to ŘNř


Last Match Indicator (GMSLMI) set to 'Y' if the Number of Duplicate Drivers Identified is Ř0ř or Ř1ř;


Message Match Limit Exceeded Indicator (GMSLEI) set to 'Y' if the Number of Duplicate Drivers

Identified is greater than Ř5ř; otherwise set to ŘNř

Message SOR Change in Progress Indicator (GMSSCH) set to 'N' if Number of Duplicate Drivers

Identified is Ř0ř; otherwise set to the First Dup CSOR Indicator returned by the ŖCDA1 DUPLICATE

DRIVER PROCESSŗ

Message Driver Duplicate Indicator (GMSDUP) set to 'N' if Number of Duplicate Drivers Identified is

Ř0ř; otherwise set to 'Y'

The Confirm Change Data Complete (CD) message may optionally include:







CD09 CHANGE DATA






values.

CD09.2.6.2 Transmission of Change Data (UC) Message with Errors

If the CDLIS Central Site encounters errors on the original Change Data (UC) message that preclude further processing,

the Central Site returns the message to the inquirer with Error Block appended (up to 5 occurrences).



(02/2) blocks.

CD09.3 Process Change Data (State of Record (SOR))


After submitting the Change Data (UC) message, the SOR receives one of two messages:

Confirm Change Data Complete (CD) message

Change Data (UC) message returned with errors

If the Confirm Change Data Complete (CD) message is received, the SOR may additionally receive;

one or more Possible Duplicate (NA) messages, indicating that the driver has been identified as a possible

duplicate driver and/or

one or more Duplicate Resolved (NE) messages, indicating that one or more possible duplicates have been

resolved. See section ŘCDA1 DUPLICATE DRIVER PROCESSř for details.

CD09.3.2 Reception

CD09.3.2.1 Reception of Confirm Change Data Complete (CD) Message

The Confirm Change Data Complete (CD) message includes:
















CD09 CHANGE DATA


CD09.3.2.2 Reception of Change Data (UC) Message with Errors

If the CDLIS Central Site encountered errors which preclude processing, the Change Data (UC) message is returned to

the SOR exactly as submitted with the following data elements set:

NCB Error Code (GNCBER)


Error Block appended ((up to 5 occurrences)




CD10 DELETE MASTER POINTER RECORD




Description

The Delete Master Pointer Record transaction enables a State of Record (SOR) to delete a Master Pointer Record

(MPR) from the CDLIS Central Site.

An MPR is only deleted after it is eligible for purging. An MPR is eligible for purging under the following conditions:

The MPR is no longer subject to CDLIS data retention requirements. The SOR cannot delete the MPR until all

convictions, accidents and withdrawals individually are no longer subject to CDLIS data retention requirements. Ref1

The pointer record was created in error

If an Add New Driver was performed when a CSOR should have been performed (thus creating a duplicate

driver), the last MPR to be created is deleted. A CSOR is then completed and any missing history is added to the

Driver History Record (DHR).

The Delete Master Pointer Record transaction is not used to delete an unwanted MPR if the driver possesses a

commercial license document or was convicted of an offense in a CMV. Once an Add New DriverRef3

message is

successfully processed by the CDLIS Central Site, the driverřs record must remain on both the CDLIS Central Site and

the SORřs database until it is eligible for deletion.

If it is suspected that the same person has two pointers, neither of the pointers should be deleted until it is confirmed that

both pointers are, in fact, for the same person. Once this has been confirmed, the SORs must determine which

jurisdiction Řownsř the driver. The jurisdiction that will be keeping the driver will need to obtain the history from the

other. Only after this can the extraneous pointer be deleted. Until that time, the AKA names, and AKA jurisdiction

code and driverřs license number combinations are to be maintained for both pointers using the CDLIS Change DataRef4

or the Update AKA DataRef5

transactions

Participants


o U.S. jurisdiction

CDLIS Central Site

Pre-Requisites

To help ensure the success of the transaction, an SOR submits a Search Inquiry,Ref6

Verification Inquiry, Ref7

or a

Verification Inquiry Preceding Delete Master Pointer RecordRef7

to the CDLIS Central Site to verify that the correct

MPR is identified.

Standard Processing

An SOR sends a Delete Master Pointer Record message to the CDLIS Central Site.

Upon receipt of the Delete Master Pointer Record message, the CDLIS Central Site:


o Retrieves and updates the MPR as requested


o Determines whether any drivers previously identified as possible duplicates will no longer be duplicates

once the record is deleted; if so, issues notifications of duplicate resolution to all SORs affected Ref8

Inputs

The Delete Master Pointer Record message includes the driverřs identification data (driver's license number and

jurisdiction code combination, Social Security Number, name, and date of birth) consistent with the information

returned from the inquiries performed prior to submission of the update. Ref9







o A confirmation message that the driver was successfully deleted





Central Site

o If the Delete Master Pointer Record message does not pass the edit validations performed by the CDLIS

Central Site, the Central Site returns an error to the inquirer. No further processing is performed.

Post-Requisites

None

References

Reference

#


Ref1 CDLIS State Procedures

Manual

Section 5.2, CDLIS Data Retention and

Availability

8.6.1, Data Retention Requirements Satisfied

AAMVA Code Dictionary

(ACD) Manual

Section 3.2.5, Validating Indicator Information

for ŖOldŗ and ŖNewŗ Convictions

Ref2 CDLIS System

Specifications


CDLIS State Procedures

Manual

Section 6.8, Change State of Record

Section 7.6, CDLIS Driver Changes Jurisdiction

Ref3 CDLIS System

Specifications

CD07 ADD NEW DRIVER

Ref4 CDLIS System

Specifications

CD09 CHANGE DATA

Ref5 CDLIS System

Specifications


Ref6 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref7 CDLIS System

Specifications


Ref8 CDLIS System

Specifications


Ref9 CDLIS State Procedures

Manual

Section 8.3, Jurisdiction Changes Driver






References

Reference

#


Ref10 CDLIS System

Specifications









UE Delete Master Pointer Record

CF Confirm Delete MPR Complete 1






CD10.1 Delete Driver (State of Record (SOR))


Prior to any Delete Master Pointer Record (UE) transaction, the SOR must initiate an Inquiry to the CDLIS Central Site,

using either the Verification Inquiry (IN) or Verification Inquiry Preceding Delete Master Pointer Record (IB) message

format. The allowable input data combinations are described in "CD02.2 Verify Driver (CDLIS Central Site)" Verify

Driver. The purpose of the inquiry is to identify the MPR record and check if the record is eligible for deletion.

When a commercial driver's full record is eligible for purge, the SOR must first delete the pointer record at the CDLIS

Central Site and then purge the driver's record from the jurisdiction's system. This procedure avoids the potential for a

broken pointer condition. After the SOR receives confirmation that the pointer record was deleted, it may then initiate

the purge procedure for its own system. The SOR must not remove the driver's record from its database until the

confirmation from the CDLIS Central Site has been received.

CD10.1.2 Transmission of Delete Master Pointer Record (UE) Message

The Delete Master Pointer Record (UE) message must include:


Positions 1-2 of the Driver License Jurisdiction Number (DDLJDL) set to the state in which the driver is licensed

Positions 3-27 of the Driver License Jurisdiction Number (DDLJDL) set to the driverřs license number of the

driver

Driver SSN - CDLIS (DDVSS6) set to the Social Security Number of the driver

Driver Date of Birth (DDVDOB) set to the date of birth of the driver


The Delete Master Pointer Record (UE) message may optionally include:



values.

CD10.2 Delete Master Pointer Record (CDLIS Central Site)

CD10.2.1 Reception of Delete Master Pointer Record (UE) Message

Upon receipt of a Delete Master Pointer Record (UE) message from a jurisdiction, the CDLIS Central Site initiates

validation processing.


The CDLIS Central Site performs the following validations on the Delete Master Pointer Record (UE) message. If






Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Delete Master Pointer Record

(UE) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Delete Master

Pointer Record (UE) message

Authorization Function (BJUAFN) set to ŖUEŗ











(DDLJDL).



(DDLJDL).


















DICTIONARYŗ.



Must be numeric


















Driver Current Sex (DDVSX3), if present, must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'SEX CODE INVALID'






Ensure that the Master Pointer (CD20) record to be deleted exists. Access the Master Pointer (CD20) data store by:


(DDLJDL) from the Delete Master Pointer Record (UE) message; and


(DDLJDL) from the Delete Master Pointer Record (UE) message




The name information on the Delete Master Pointer Record (UE) message must correspond with the name information

on the existing Master Pointer (CD20). The comparison is performed as described in 7.2 Name Comparison





The Driver Date of Birth (DDVDOB) on the Delete Master Pointer Record (UE) message must match the CD20 Person

Date of Birth (BPEDOH) on the existing Master Pointer (CD20) record:









The Driver SSN Ŕ CDLIS (DDVSS6) on the Delete Master Pointer Record (UE) message must match the corresponding

data on the existing Master Pointer (CD20) record:


The last 5 digits of Driver SSN - CDLIS (DDVSS6) must match the CD20 Person SSN Last 5 Digits

(BPESSD)


If the State of Record (SOR) at a version older than 5.1:

Driver SSN - CDLIS (DDVSS6) must match the CD20 Driver Social Security Number (DDVSSN)



The Message SOR Change in Progress Indicator (GMSSCH) on the existing Master Pointer (CD20) record must

equal ŘNř.


CD10.2.3 Process Resolved Duplicates


to delete any applicable Duplicate Pointer (CD23) records, and to send the associated Duplicate Resolved (NE)

messages.

Pass the following information from the Delete Master Pointer Record (UE) message (or from the Master Pointer

(CD20) where indicated) to the ŖCDA1 DUPLICATE DRIVER PROCESSŗ:.









CD10.2.4 Updates

Delete the existing Master Pointer (CD20) and all associated AKA records from:

CDLIS Name Pointer (CD22)

ST-DLN Pointer (CD24)


CD10.2.5.1 Transmission of Confirm Delete MPR Complete (CF) Message

The Confirm Delete MPR Complete (CF) message must include:






The Confirm Delete MPR Complete (CF) message may optionally include:




values.

CD10.2.5.2 Transmission of Delete Master Pointer Record (UE) Message with Errors

If the CDLIS Central Site encounters errors on the original Delete Master Pointer Record (UE) message that preclude

further processing, the Central Site returns the message to the inquirer with Error Block appended (up to 5 occurrences).



(02/2) blocks.

CD10.3 Receive Confirmation (State of Record (SOR))


After submitting the Delete Master Pointer Record (UE) message, the SOR receives one of two messages:

Confirm Delete MPR Complete (CF) message

Delete Master Pointer Record (UE) message returned with errors

If the Confirm Delete MPR Complete (CF) message is received, the SOR may additionally receive one or more

Duplicate Resolved (NE) messages, indicating that one or more possible duplicates have been resolved. See section

ŘCDA1 DUPLICATE DRIVER PROCESSř for details.

Upon receipt of the Confirm Delete MPR Complete (CF) message from the CDLIS Central Site, the SOR may purge the

driver's record from the jurisdiction's database. If the Delete Master Pointer Record (UE) message is returned with

errors, the SOR must correct it and resubmit the Delete Master Pointer Record (UE).

CD10.3.2 Reception

CD10.3.2.1 Reception of Confirm Delete MPR Complete (CF) Message

The Confirm Delete MPR Complete (CF) message must include:



The Confirm Delete MPR Complete (CF) message may optionally include:


CD10.3.2.2 Reception of Delete Master Pointer Record (UE) Message with Errors

If errors are encountered in the original Delete Master Pointer Record (UE) message, it is returned in its original state

with the addition of up to five explanations in the error block. If an error is encountered, the driver is not be deleted.

Therefore, the error conditions must be corrected and another Delete Master Pointer Record (UE) message transmitted

to delete the driver.



CD11 REPORT OUT-OF-STATE CONVICTION




Description

The Report Out-of-State Conviction transaction is used to report an ACD conviction (one at a time) on an out-of-state

CDLIS driver to the State of Record (SOR)*. Because conviction(s) may cause the driver's license to be withdrawn, the

State of Conviction (SOC) transmits complete and accurate conviction reports within the required time limits.Ref1

Additional underlying convictions may also be reported by the State of Withdrawal (SOW) through the Report Out-of-

State Withdrawal transaction.Ref2

The transaction enables jurisdictions to comply with the federal requirement [49 CFR §384.209] that the SOC must

report to the SOR all convictions that meet the following criteria:

The conviction was for a violation of any jurisdiction or local law relating to motor vehicle traffic control (other

than a parking violation)

The conviction was for a violation committed by a:

o Person required to have a Commercial Driverřs License (CDL), i.e., a non-CDL holder convicted of a

violation while operating a Commercial Motor Vehicle (CMV)**, including a vehicle transporting

hazardous materials

o CDL holder in any vehicle

Mexican and Canadian driver Master Pointer Records (MPRs) are not stored on the CDLIS Central Site. If a Mexican

driver gets a US conviction, the conviction is reported, either via CDLIS or via mail, to Mexico. U.S. convictions of

Canadian drivers are not sent via CDLIS, but should be mailed.

For CDLIS to work properly, all convictions and withdrawals in the U.S. have to be sent to the current SOR so that

proper penalties are applied and history accumulated. This is equally true for Licencia Federal de Conductor

(LFC) drivers.

The Federal Conviction Withdrawal Database ( FCWD) is the SOR for all LFC drivers. An LFC driver has a record

established in the LIFIS database when he/she obtains an LFC license.

The FCWD, as the SOR for all LFC drivers, contains all U.S. convictions and U.S. withdrawals on LFC drivers (their

DHR), as well as the driverřs commercial status based on that history***. This information allows border and

enforcement personnel to determine whether or not a particular LFC driver should be allowed to drive in the U.S.

If States establish a pointer on CDLIS for an LFC driver, the associated conviction(s) and/or withdrawal(s) do not

become part of the LFC driver's DHR, potentially allowing a driver who should be barred from driving on U.S.

highways to enter the U.S. undetected.

If the jurisdiction knows the driver has a pointer on CDLIS (e.g., a former CDL holder who has down-graded to a non-

CDL), jurisdictions may also report to the SOR an ACD conviction whether or not the driver currently holds a CDL. A

jurisdiction does not submit a non-ACD conviction (a conviction that does not have a current conviction ACD code) via

CDLIS. There is no requirement to query CDLIS to determine if a driver has a pointer for convictions of non-CMV,

non-CDL holder violations.

* Convictions are transmitted electronically or as a paper copy via mail, but not both.Ref3

Convictions submitted

electronically and returned in error are corrected by the SOC before being resubmitted (or sent by paper copy); sending

such convictions via paper copy without correction is not allowed.

** When the SOC convicts a non-CDL holder in a CMV and the operator possesses and presents a non-commercial

driverřs license at the time of citation and/or conviction, the SOC sends the conviction to the SOR either through

CDLIS or by mail. The SOR creates a Driver History Record (DHR) and posts the conviction to the DHR. If the non-

CDL driver does not have an MPR on CDLIS, the SOR adds one.

*** The status of an LFC driver is determined by looking at both the LFC driver's Mexican status in the LIFIS

database and the status as calculated by FMCSA's contractor based on convictions and withdrawals in the FCWD. An

MX history includes the same status received in a status message, plus all convictions and withdrawals





from FMCSA's FCWD. As an example, a driver with a status of "LIC" in the LIFIS database and a status of "NOT" in

the FCWD will reflect a CDLIS status of "NOT" and a restriction saying the license is "not valid in the U.S.".

Participants

State of Conviction (SOC)

o U.S. jurisdiction

CDLIS Central Site


o U.S. jurisdiction



Pre-Requisites

To help ensure the success of the transaction, an SOC submits a Search Inquiry,Ref4

a Verification Inquiry,Ref5

or

a Verification Inquiry Preceding Report Out-of-State ConvictionRef5

to the CDLIS Central Site to verify that the

correct MPR is identified

If no license is presented at either the time of citation or conviction, the SOC becomes the SOR, creates the DHR

at the jurisdiction, adds the MPR for the driver at the CDLIS Central Site, and posts the conviction to the DHR.

Standard Processing

The SOC sends a Report Out-of-State Conviction message to the CDLIS Central Site.

Upon receipt of the Report Out-of-State Conviction message, the CDLIS Central Site:

o Validates the driver identification and conviction information in the message


o Forwards the conviction to the SOR*

Upon receipt of the conviction information, the SOR performs the following within 96 hours **:

o Validates the driver

o Validates the conviction data using current rules

o Verifies the conviction is not a duplicate

o Retrieves the DHR

o Adds the conviction to the DHR


Upon receipt of the confirmation from the SOR, the CDLIS Central Site:


o Sends a confirmation to the SOC that the transaction is complete

* If the driver is currently in the process of changing his/her SOR, the CDLIS Central Site forwards the conviction

information to the New SOR.

** Federal regulations allow 10 days from receipt to post conviction information. However, if the Central Site does

not receive the confirmation message within 96 hours, AAMVA notifies the SOR.

Inputs

The Report Out-of-State Conviction includes the driverřs license number and jurisdiction code combination, name, and

date of birth consistent with the information returned from the inquiries performed prior to submission of the update. It

also includes the SOC, citation date and conviction data (not the information on the citation, if different). The message

may optionally contain the driverřs Social Security Number and ACD code detail (as allowed or required by the code

definition).









o The Central Site sends driver identification and conviction information received from the SOC to the

SOR

SOR to the Central Site:

o The SOR sends a confirmation that the conviction has been posted to the DHR

Central Site to the SOC:

o A confirmation message that the posting of the conviction is complete


Central Site

o If the Report Out-of-State Conviction message does not pass the edit validations performed by the CDLIS

Central Site, the Central Site returns an error to the SOC. No further processing is performed.

o If the SOR returns an error after receiving the conviction information, the Central Site forwards the error

to the SOC

SOR

o If the SOR cannot locate the driver upon receipt of conviction information or there are problems with the

conviction data itself, the SOR returns an error to the CDLIS Central Site.

Post-Requisites

SOC

o To be able to perform negation and to answer any questions about the original conviction, the SOC

maintains the original record on any conviction according to CDLIS data retention rules.

SOR

o Correctly interpret the information on the CDLIS DHR to determine whether any withdrawal action is

required, and, if so, what federal minimum applies

o Take any necessary driver control actions, as if the conviction had occurred in the SORřs own

jurisdiction, i.e., based on its own laws

o Maintain the conviction on the CDLIS DHR according to CDLIS data retention rules

References

Reference

#


Ref1 CDLIS State

Procedures Manual

Section 9.1, Rules for Driver Convictions

Ref2 CDLIS System

Specifications

CD16 REPORT OUT-OF-STATE WITHDRAWAL

Ref3 CDLIS State

Procedures Manual

Appendix C, Procedures for Mailing Driver History

Ref4 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref5 CDLIS System

Specifications


Ref6 CDLIS System

Specifications






Federal Regulations


49 CFR 383.5 Definitions Defines the terms driverřs license, CDL, non-resident CDL,

CMV, non-CMV

49 CFR 383, 384, U.S. Federal Motor Carrier Safety

Administration (FMCSA) Policy Memorandum

CDL-04-001*

Explain details of the federally mandated requirements for

conviction reporting; A copy of FMCSAřs Policy Memorandum

is available from FMCSA

* Jurisdictions consult their own laws and regulations for additional guidance on reporting convictions and taking

driver-control actions within the scope of their CDL programs. They also consult the relevant interstate

compacts/agreements, including the following:

The Driver's License Compact (DLC)

The Non-Resident Violators Compact (NRVC)

The Driver's License Agreement (DLA)

Copies of these documents are available from the AAMVA Programs Division. These sources also provide guidance

for reporting convictions for offenses committed by non-CDL holders in non-CMVs, which is beyond the scope of the

CDL program.

In all cases involving the DLC, NRVC and DLA, if the compacts conflict with federal regulations or FMCSA policy

memoranda, the federal regulations and FMCSA policy memoranda take precedence.







HA Report Out-of-State Conviction

HF Forward Report Out-of-State Conviction 1

CA Confirm Out-of-State Action 1

CS Confirm Receipt of CA 1





CD11.1 Report Conviction (State of Conviction SOC))


The Report Out-of-State Conviction Transaction enables the SOC to report an out-of-state conviction to the SOR. To

determine which convictions must be reported with this transaction, see the following:

AAMVA Code Dictionary (ACD) Manual (available from the AAMVA Operations Help Desk)

U.S. Code of Federal Regulations Part 49 Sections 383 and 384 (available from the FMCSA)

the FMCSA Policy Memorandum CDL-004-001 (available from FMCSA)

the Drivers License Compact (DLC) (available from the AAMVA Programs Division)

the Non-Resident Violators Compact (NRVC) (available from the AAMVA Programs Division)

the Drivers License Agreement (DLA) (available from the AAMVA Programs Division)

In all cases involving the DLC, NRVC and DLA, if the compacts conflict with federal regulations or FMCSA

policy memoranda, the federal regulations and FMCSA policy memoranda must take precedence.

Prior to any Report Out-of-State Conviction transaction for drivers in CDLIS, the SOC must initiate a verification

inquiry (see "CD02 VERIFICATION INQUIRY") or a search inquiry (see "CD01 SEARCH INQUIRY") to the CDLIS

Central Site to ensure positive identification of the driver. The verification inquiry may use the IN or ID message (see

"CD02 VERIFICATION INQUIRY" for formatting instructions) or the Search Inquiry (IM) message, which uses a less

restrictive search algorithm (see "CD01 SEARCH INQUIRY" for formatting instructions).

Upon receipt of the inquiry responses from the SOR, the SOC is responsible for confirming that the driver represented

in the response messages is the appropriate driver before taking any update actions (since the driver was selected by the

SOR based on DLN only). This is accomplished by verifying the primary driver identifying data (Name, Date of Birth

and Social Security Number) matches. The SOC may also consider secondary driver identifying data, such as Sex,

Height, Weight, and Eye Color.

The SOC is not required to review the inquiry response that precedes the Report Out-of-State Conviction (HA) message

to ascertain the CDLIS-version capability of the SOR, because the SOR leaves the System Release Code (GMSSRL) set

to a space in the inquiry response message. When reporting an out-of-state conviction, the SOC must assume that the

SOR accepts new ACD codes, and the SOC must send the out-of-state conviction electronically via CDLIS. If the SOR

rejects the message, because it canřt accept new ACD codes, the SOC must mail the conviction.

Because Mexican drivers are not maintained on the CDLIS Central Site, the SOC must not initiate a verification or

search inquiry to the CDLIS Central Site before initiating a Report Out-of-State Conviction on a Mexican driver. The

SOC must just send the conviction message with Driver License Current Jurisdiction Code (DDLJU1) set to ŘMXř. The

CDLIS Central Site will forward the conviction message to ŘMXř without checking for a matching MPR.

Currently, convictions of Canadian drivers cannot be submitted electronically to Canada via CDLIS, so the SOC must

send a paper copy of the conviction to the Canadian jurisdiction, when reporting is required by Federal regulations. It is

recommended that in cases involving disqualifying convictions, the SOC also maintain the driver and conviction

information on its own database and add a pointer for the driver to the CDLIS Central Site file (see "CD07 ADD NEW

DRIVER" for details). Convictions of U.S. drivers cannot be submitted electronically via CDLIS by Mexico or Canada.

In accordance with 49 CFR 384.209, through September 30, 2008, the jurisdiction must report a conviction within 30

days of the conviction date, and beginning on October 1, 2008, the jurisdiction must report a conviction within 10 days

of the conviction date. In accordance with 49 CFR §384.225, the conviction be posted to the driverřs record within 10

days of receipt of the conviction by the MVA, either from an out-of-state source or from an in-state source.

Jurisdictions must not send transactions that are not final, according to jurisdiction law, to avoid having to reverse them,

and jurisdictions must not send FTAs, FTPs, and FTCs until any grace period has ended, according to jurisdiction law.

Besides reporting the conviction to the SOR, the SOC must also maintain the original record on any conviction for as

long as the conviction is retained on the CDLIS driver history by the SOR, to be able to perform negation and to answer

any questions about the original conviction. Along with the original record, the SOC must maintain the identifying

driver information and the six identifying conviction values (SOC jurisdiction code, the State Native Code, and the SOC

Court Report ID, ACD code, citation date, and conviction date). When the conviction is purged from CDLIS driver





history, the original record can be destroyed. See the ACD for data retention requirements for ACD convictions.

In accordance with FMCSA policy Memorandum CDL-04-001, if a jurisdiction issues a failure to appear (FTA) or a

failure to pay (FTP) or failure to comply (FTC) for an out-of-state CDL driver for an underlying ACD citation or

offense, the jurisdiction issuing the FTA or FTP or FTC must report the failure to the SOR. If both the jurisdiction

issuing the failure and the SOR are members of the NRVC, the issuing jurisdiction may report the failure using the

NRVC paper form. If either the jurisdiction issuing the failure or the SOR is not an NRVC member, the issuing

jurisdiction must send a Report Out-of-State Conviction (HA) message, or an equivalent paper form, to the SOR with

the appropriate ACD Offense Code (e.g., 'D56' "Failure to answer a citation, pay fines, penalties and/or costs related to

the original violation"). If the FTA/FTP/FTC conviction date is after October 2, 2005, the ACD detail code must be set

to the ACD Offense Code for the underlying citation or offense (e.g., 'A04 ' "Driving under the influence of alcohol

with BAC at or over .04"). If the FTA/FTP/FTC conviction date is on or before October 2, 2005, the ACD detail field

may be blank or may be set to the ACD Offense Code for the underlying citation or offense. If the underlying citation

or offense is a non-ACD violation, the jurisdiction must not report the FTA/FTP/FTC as a conviction to the SOR.

CD11.1.2 Transmission of Report Out-of-State Conviction (HA) Message

The Report Out-of-State Conviction (HA) message must contain the following:


System Release Code (GMSSRL) set to space or 'F' ( A space indicates the SOC has not yet implemented

changes required by CDLIS Release 4.0.1, while a value of 'F' indicates the SOC has implemented the changes).

Driver Date of Birth (DDVDOB) set to the driver's DOB


o Driver License Current Jurisdiction Code (DDLJU1) set to the jurisdiction code of the driver's license

o Driver License Number (DDLNUM) set to the driver's license number*

*The Driver License Number (DDLNUM) may be the DLN on the Master Pointer (CD20) record or the

DLN on the citation for which the driver was convicted. The Central Site functionality is designed to

accommodate cases where the driver moved before he/she was convicted, so any license number

associated with the driver should result in successful processing of the Report Out-of-State Conviction

(HA) message. In all cases, an inquiry must be performed prior to sending the Report Out-of-State

Conviction (HA) message ensure the conviction is sent on the correct driver.

Jurisdiction Code - Convicting (DCVJUR) set to the jurisdiction code of the SOC

Citation Date (DCIDCI) set to the date the original citation (e.g., court ruling of an FTC, administrative ruling of

an Admin per se, etc.) was issued

Conviction Date (DCVDCV) set to the date on which the conviction, such as an FTC or Admin per se, was

finally adjudicated, according to SOC laws

Conviction Court Type (DCVCRT) set to the appropriate code for the type of court that finalized the conviction

Conviction Commercial Vehicle Indicator (DCVCOM)

o If the Citation Date (DCIDCI) is on or after January 1, 2008

set to '1' if a commercial vehicle was being used when the offense was committed,

set to '2' if a commercial vehicle was not being used when the offense was committed, or if

unknown,

o If the Citation Date (DCIDCI) is prior to January 1, 2008


set to '2' if a commercial vehicle was not being used when the offense was committed,

set to '9' if the above is unknown

Conviction HAZMAT Indicator (DCVHAZ)


set to '1' if the violation occurred while the driver was carrying hazardous materials,

set to '2' if the driver was not carrying hazardous materials when the violation occurred, or if





unknown



set to '2' if the driver was not carrying hazardous materials when the violation occurred,


Conviction Jurisdiction Court Report ID (DCVCLO) set to the unique identifier for the conviction report from

the SOC court or State Authority

Conviction Jurisdiction Offense Code (DCVCOR) set to the native SOC code for the offense

Conviction Offense ACD Code (DCVCCA) set to the AAMVA Code Dictionary code describing the offense


The Report Out-of-State Conviction (HA) message may optionally contain the following:


Conviction Offense Detail - ACD (DCVCDA) set if the ACD code requires or allows additional details about the

offense (see the current AAMVA Code Dictionary (ACD) Manual for details)


values.

Note: Jurisdictions must have procedures in place to ensure duplicate convictions are not sent. The SORřs automated

procedures will not be able to detect that even small changes (e.g., extra spaces, extra hyphens, leading zeroes on any of

the six identifying elements) to the same conviction are, in fact, a duplicate and will make the SOR believe it is a new

conviction.

CD11.2 Validate Conviction Information (CDLIS Central Site)

CD11.2.1 Reception of Report Out-of-State Conviction (HA) Message

Upon receipt of a Report Out-of-State Conviction (HA) message from a jurisdiction, the CDLIS Central Site initiates



The CDLIS Central Site performs the following validations on the Report Out-of-State Conviction (HA) message. If




Validate the password and determine the implementation status of the State of Conviction (SOC) by performing


Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Report Out-of-State

Conviction (HA) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Report Out-

of-State Conviction (HA) message

Authorization Function (BJUAFN) set to ŖHAŗ





For all States of Conviction (SOC), regardless of the version implemented:






(DDLJDL).



(DDLJDL).




Jurisdiction Code - Convicting (DCVJUR) must be present.

Error Text: 'STATE-OF-CONVICTION CODE REQUIRED'

Citation Date (DCIDCI) must be present.

Error Text: 'CITATION DATE REQUIRED'

Conviction Date (DCVDCV) must be present.

Error Text: 'CONVICTION DATE REQUIRED'

Conviction Court Type (DCVCRT) must be present.

Error Text: 'CONVICTION COURT TYPE REQUIRED'

Conviction Commercial Vehicle Indicator (DCVCOM) must be present.

Error Text: 'COMMERCIAL VEHICLE INDICATOR REQUIRED'

Conviction HAZMAT Indicator (DCVHAZ) must be present.

Error Text: 'HAZMAT INDICATOR REQUIRED'

Conviction Jurisdiction Court Report ID (DCVCLO) must be present.

Error Text: 'SOC COURT REPORT ID REQUIRED'

Conviction Jurisdiction Offense Code (DCVCOR) must be present.

Error Text: 'SOC OFFENSE CODE REQUIRED'

Conviction Offense ACD Code (DCVCCA) must be present.

Error Text: 'ACD CONVICTION CODE REQUIRED'

For those States of Conviction (SOC) at version 5.1 or greater:



For those States of Conviction (SOC) at a version older than 5.1:









Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) must contain ŘMXř or one of the valid


DICTIONARYŗ.



DICTIONARYŗ.



Must be numeric





Jurisdiction Code - Convicting (DCVJUR) must contain one of the valid values in the "United States" list under

Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.

Error Text: 'INVALID STATE-OF-CONVICTION CODE'

Citation Date (DCIDCI) must be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID CITATION DATE'

Conviction Date (DCVDCV) must be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID CONVICTION DATE'

Conviction Court Type (DCVCRT) must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID CONVICTION COURT TYPE'

Conviction Commercial Vehicle Indicator (DCVCOM) must contain one of the valid values listed in


Error Text: 'INVALID COMMERCIAL VEHICLE INDICATOR'

Conviction HAZMAT Indicator (DCVHAZ) must contain one of the valid values listed in ŖAPPENDIX D -

DATA DICTIONARYŗ.

Error Text: 'INVALID HAZMAT INDICATOR'

Conviction Offense ACD Code (DCVCCA) must be valid as specified in the current AAMVA Code Dictionary

(ACD) Manual and must not be one of the codes reserved for withdrawals: W00, W01, W30, W31, W40, W41,

W45, W50, W51, W52, W60, W61, W72, W80 and W81.

Error Text: 'INVALID ACD CONVICTION CODE'





System Release Code (GMSSRL) must be space or 'F'.













The value in positions 1 - 2 of the Transaction Originator (GTRORG) must match the Jurisdiction Code -

Convicting (DCVJUR).

Error Text: 'SOC AND TRANSACTION ORIGINATOR DO NOT MATCH'

Citation Date (DCIDCI) must be equal to or earlier than the Conviction Date (DCVDCV).

Error Text: 'CITATION DATE MUST NOT BE LATER THAN CONV DATE'

Conviction Date (DCVDCV) must be equal to or earlier than the Message Date (GMSDAT).

Error Text: 'CONV DATE MUST NOT BE LATER THAN MESSAGE DATE'

If the Citation Date (DCIDCI) is on or after January 1, 2008, then the Conviction Commercial Vehicle Indicator

(DCVCOM) must be '1' or Ř2ř.

Error Text: ‘CONV CMV IND MUST = 1 OR 2, FOR CITATN DATE >

20071231’

If the Citation Date (DCIDCI) is on or after January 1, 2008, then the Conviction HAZMAT Indicator

(DCVHAZ) must be '1' or Ř2ř.

Error Text: ‘CONV HAZ IND MUST = 1 OR 2, FOR CITATN DATE >

20071231’

If the value of the Conviction HAZMAT Indicator (DCVHAZ) is '1', then the Conviction Commercial Vehicle

Indicator (DCVCOM) must be '1'.

Error Text: 'CONV CMV IND MUST = 1, IF CONV HAZMAT IND = 1'

If the Conviction Offense ACD Code (DCVCCA) value is in the group (B19, B27, B56, E03, E04, E06, E33,

E36, E53, E56, U09, U10), the Conviction Commercial Vehicle Indicator (DCVCOM) must be '1':

Error Text: 'CONV CMV INDICATOR MUST = 1 FOR ACD CONV CODE'

If the Conviction Offense ACD Code (DCVCCA) value is in the group (E03, E04, E33, E53), the Conviction

HAZMAT Indicator (DCVHAZ) must be "1":





Error Text: 'CONV HAZMAT IND MUST = 1 FOR ACD CONV CODE'

If the Citation Date (DCIDCI) is on or after January 1, 2008 and Conviction Offense ACD Code (DCVCCA)

value is in the group (E06, E36, E56), the Conviction HAZMAT Indicator (DCVHAZ) must be "2":

Error Text: 'CONV HAZMAT IND MUST = 2 FOR ACD CONV CODE'

If the Conviction Offense ACD Code (DCVCCA) is ŘB78ř, S14ř, ŘU27ř or ŘU28ř, the Citation Date (DCIDCI)

must be on or after November 9, 2009.

Error Text: 'INVALID CITATION DATE FOR CONV ACD'

If the given Conviction Offense ACD Code (DCVCCA) is not in the group ('A11', 'D45', 'D53' or 'D56') and is

not in the range 'S01'-'S92', the Conviction Offense Detail - ACD (DCVCDA) must have all spaces.

Error Text: 'ACD CONV CODE VALUE REQUIRES BLANK CONV OFF DET'

If the given Conviction Offense ACD Code (DCVCCA) is 'A11', the Conviction Offense Detail - ACD

(DCVCDA) must have numeric values in the range '01'-'99' in the first 2 positions and all spaces or all zeroes in

the remaining three positions.

Error Text: 'INVALID CONV OFF DETAIL FOR ACD CONV CODE = A11'

If the given Conviction Offense ACD Code (DCVCCA) is 'D45' or 'D53' or 'D56', the first three positions of the

Conviction Offense Detail - ACD (DCVCDA) must have a valid ACD Conviction Code that must not be 'D45',

'D53', 'D56' or ŘW70ř; and the remaining two positions must have spaces.

Error Text: 'INVALID CONV OFF DETAIL FOR GIVEN ACD CONV CODE'

If the given Conviction Offense ACD Code (DCVCCA) is in the range 'S01'-'S91', the Conviction Offense Detail

- ACD (DCVCDA) must have one of the following two formats (Note: The format of "zeroes for null values"

does not conform to the AAMVA standard of "spaces for null values" and is rejected in error):

all spaces (for null values) or

numeric values in the range '05'-'90' in the first 2 positions and all spaces or all zeroes in the last three

positions.

Error Text: 'INVALID CONV OFF DET FOR ACD CONV CODES S01-S91'

If the given Conviction Offense ACD Code (DCVCCA) is 'S92', the Conviction Offense Detail - ACD

(DCVCDA) must have a numeric value in the range '05'-'90' in the first two positions and a numeric value in the

last three positions that is less than '300' and greater than the numeric value in the first two positions.

Error Text: 'INVALID CONV OFF DETAIL FOR ACD CONV CODE = S92'



Perform the remaining data lookups described in this section only if positions 1 - 2 of the Driver License

Jurisdiction Number (DDLJDL) on the Report Out-of-State Conviction (HA) message are not ŘMXř. If positions

1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Report Out-of-State Conviction (HA) message

areŘ MXř, proceed directly to the transmission section.



(DDLJDL) from the Report Out-of-State Conviction (HA) message; and


(DDLJDL) from the Report Out-of-State Conviction (HA) message





If a Master Pointer (CD20) record is found, perform the retrieved record match edits described in CD11.2.2.6

Retrieved Record Match Errors. If no Master Pointer (CD20) record is found or if a CD20 is found but fails the

retrieved record match edits, perform the AKA ST-DLN (CD24) access described below.

Access the AKA ST-DLN (CD24) by the following fields from the Report Out-of-State Conviction (HA)

message:


Number (DDLJDL)


Number (DDLJDL)

One or more records associated with the existing AKA ST-DLN (CD24) must exist.


If more than one AKA ST-DLN (CD24) record is retrieved, select the record with the most recent Date of Last

Update (GRCUDT) and Time of Last Update (GRCUTM). Access the associated Master Pointer (CD20), then

perform the CD11.2.2.6 Retrieved Record Match Errors below.



The name information on the Report Out-of-State Conviction (HA) message must correspond with the name

information on the existing Master Pointer (CD20). The comparison is performed as described in "7.2 Name

Comparison"

If the State of Conviction (SOC) is at version 5.1 or greater


If the State of Conviction (SOC) is at a version older than 5.1


The following data on the Report Out-of-State Conviction (HA) message must match the corresponding data on the









If present, the last 5 digits of Driver SSN - CDLIS (DDVSS6) must match the CD20 Person SSN Last 5

Digits (BPESSD)



If present, Driver SSN - CDLIS (DDVSS6) must match the CD20 Driver Social Security Number

(DDVSSN)






The CDLIS Central Site determines the implementation status of the State of Record (SOR) by performing ŘCDJ1.3

Verification of Additional Transaction Participantř using the following input;

Jurisdiction Code (BJUCDE) set to positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the

Report Out-of-State Conviction (HA) message if the values are ŘMXř; otherwise set to the Jurisdiction Code Ŕ

Licensing (DDLJUR) on the retrieved Master Pointer (CD20) record

Authorization Function (BJUAFN) set to ŖHFŗ



CD11.2.3.1 Transmission of Forward Report of Out-of-State Conviction (HF) Message

If the Report Out-of-State Conviction (HA) message is valid, the CDLIS Central Site sends a Forward Report of Out-of-

State Conviction (HF) message to the State of Record (SOR).

The Forward Report of Out-of-State Conviction (HF) message must include:


The Forward Report of Out-of-State Conviction (HF) message must include the following information as provided on

the Report Out-of-State Conviction (HA) message:



Message Destination (GMSDST) set to positions 1 - 2 of the Driver License Jurisdiction Number

(DDLJDL) on the Report Out-of-State Conviction (HA) message if the values are ŘMXř; otherwise set to

the Jurisdiction Code - Licensing (DDLJUR) from the retrieved Master Pointer (CD20) record *

Transaction Originator (GTRORG)

System Release Code (GMSSRL), if present

Jurisdiction Code - Convicting (DCVJUR)

Citation Date (DCIDCI)

Conviction Date (DCVDCV)

Conviction Court Type (DCVCRT)



Conviction Jurisdiction Court Report ID (DCVCLO)

Conviction Jurisdiction Offense Code (DCVCOR)

Conviction Offense ACD Code (DCVCCA)

Conviction Offense Detail - ACD (DCVCDA)

The Forward Report of Out-of-State Conviction (HF) message must include the following from the Master Pointer

(CD20) record:


Message Destination (GMSDST) set to the Jurisdiction Code - Licensing (DDLJUR)*






(BPESSD)







Driver SSN Ŕ CDLIS (DDVSS6) set to the CD20 Driver SSN (DDVSSN)




*If one or more Change State of Record (CD08) transactions occurred since the offense took place, the jurisdiction code

in positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Report Out-of-State Conviction (HA)

message will not match the Jurisdiction Code - Licensing (DDLJUR) on the Master Pointer (CD20). In this case, the

CDLIS Central Site transmits the conviction to the SOR on the CD20 record. Old SOR(s) will not be notified.


values.

CD11.2.3.2 Transmission of the Report Out-of-State Conviction (HA) Message with Errors

If the CDLIS Central Site encounters errors on the original Report Out-of-State Conviction (HA) message that preclude




(02/2) blocks.

CD11.3 Process Conviction (State of Record (SOR))


Upon receipt of the Forward Out-of-State Conviction (HF) message, the SOR must locate the driver on its database and

edit the conviction itself for errors. If the SOR finds no errors, it must post the information to the driver's history record

and evaluate whatever driving privilege withdrawal action may be necessary.

CD11.3.2 Reception of Forward Out-of-State Conviction (HF) Message

The Forward Out-of-State Conviction (HF) message contains:



System Release Code (GMSSRL) (note that a space is a valid value)

Driver License Jurisdiction Number (DDLJDL) composed of the following two elements:

o Driver License Current Jurisdiction Code (DDLJU1)

o Driver License Number (DDLNUM)

















The Forward Out-of-State Conviction (HF) message may optionally contain:


CD11.3.3 Validation

The SOR performs the following validation checks on the Forward Out-of-State Conviction (HF) message. If the SOR

detects any errors, it sets the error fields (see Ŗ4 CDLIS ERROR PROCESSINGŗ for details), returns the original

message to its sender for correction, and stops processing the transaction.


A Driver History Record must exist for the Driver License Jurisdiction Number (DDLJDL). Additional verifications on

the Person Name Group (BPENGP)/Driver Name (DDVNAM), Driver Date of Birth (DDVDOB) and Driver SSN -

CDLIS (DDVSS6) are not permitted .If the SOR does not find a match, issue an error.

Error Text: 'DRIVER HIST REC RQSTD NOT ON FILE'

CD11.3.3.2 Duplicate Conviction Error

When entering an in-state or out-of-state conviction, the SOR must check that the conviction is not already present on

the CDLIS driver history, as defined by a match on the following data elements (which uniquely identify a specific

conviction):

Jurisdiction Code Ŕ Convicting (DCVJUR)






If a duplicate exists, the SOR must issue an error.

Error Text: 'DUPLICATE CONVICTION'

Notes:

If a jurisdiction receives a conviction that matches on 5 or fewer of the identifying data elements, the jurisdiction must

record the conviction as a unique conviction. However, if the conviction matches an existing conviction for 4 or 5 of

the identifying data elements, as a best practice, the SOR should check with the SOC to ensure the conviction is indeed

unique.

The jurisdiction must have a procedure in place to check for duplicate convictions when entering paper

convictions. If either a paper or electronic conviction is suspected as a duplicate, the SOR should contact the

SOC and manually determine why the potential duplicate conviction was sent, especially if the potential

duplicate conviction and the existing conviction contain differing values for data elements other than the six

listed above.

CD11.3.4 Updates

The SOR will not post the conviction to the driver history if any errors are encountered in the Forward Out-of-State

Conviction (HF) message. If no errors are found, the SOR posts the information in the Forward Out-of-State

Conviction (HF) message to the driver history record.

The SOR also determines the value of the following data element and post it to the driver history record with the





conviction information:

Citation CDL Holder Indicator (DCICHI), set to the value ('1' or '2') indicating whether or not the driver held a

CDL at the time of the violation (see "CD04 STATE-TO-STATE HISTORY REQUEST", "CD08 CHANGE

STATE OF RECORD", "APPENDIX D.1 - DATA ELEMENTS" and the CDLIS State Procedures Manual for

details about the Citation CDL Holder Indicator).

For Convictions with a citation date on or before September 30, 2005, the Citation CDL Holder Indicator value in the

driver history must be Řblankř, Ř1ř, Ř2ř, or Ř9ř. For Convictions with a citation date in the period October 1, 2005

through December 31, 2007, the Citation CDL Holder Indicator value in the driver history must be Ř1ř, Ř2ř, or Ř9ř. For

convictions with a citation date on or after January 1, 2008, the value must be Ř1ř or Ř2řŕunknown values must be

changed to Ř2ř and the SOR must document its research to determine the value. Slightly different rules apply for the

Conviction Commercial Vehicle Indicator (DCVCOM) and the Conviction HAZMAT Indicator (DCVHAZ) (see

"APPENDIX D.1 - DATA ELEMENTS").

Jurisdictions are not required to track a CDL license holderřs effective date and termination date in a previous

jurisdiction. In cases where the citation date is not within the renewal cycle of the current license (the period between

the issue date and expiration date of current license), jurisdictions must make a good-faith effort to manually determine

whether its driver had a CDL at the time of the citation (i.e., violation), within 96 hours of receipt. The jurisdiction

must have documented procedures and a method of tracking the attempts made to determine the driverřs CDL status at

the time of the citation.

The SOR must also record in its internal database the "date the conviction was received" and the "date the conviction

was posted to the driver history" for all convictions, including in-state convictions sent by the SOR's courts to the MVA.

In nearly all cases when the conviction is transmitted via CDLIS, these dates will be the same, or within 1 day of each

other. If the conviction is transmitted via mail, the dates may differ by more than 1 day. FMCSA compliance reviewers

will check these dates when they check that the SOR is posting convictions within 10 days of the reception date, as

required by MCSIA. The SOR must consult the correct version of the AAMVA Code Dictionary (ACD) Manual , ACD

Implementation Guides, and the CDLIS State Procedures Manual for further guidance on posting convictions.

When the SOR posts the conviction, the SOR must evaluate whatever driving privilege withdrawal action may be

required in accordance with the Federal regulations and policies (see 49 CFR §383 and §384 and Policy Memorandum

CDL-04-001) and its own regulations and procedures that govern the driver improvement action. In addition, SORs that

are members of the DLC, the NRVC, and/or the DLA, must consult the compacts, as appropriate, with the

understanding that Federal regulations and policies take precedence over conflicts in the DLC, NRVC, and DLA.

Any driving privilege withdrawal action taken will require an update to the driver history. The SOR must consult the

AAMVA Code Dictionary (ACD) Manual , ACD Implementation Guides, and the CDLIS State Procedures Manual for

further guidance on posting driving privilege withdrawal actions, such as disqualifications.

In some cases the SOC will send the SOR a disqualification (i.e., a withdrawal) that was the result of the conviction, or

the SOR will take a withdrawal based on the conviction. In these cases, the SOR must internally link the withdrawal to

the reported conviction and any other convictions that resulted in the withdrawal (for withdrawals with an effective date

on or after November 1, 2005 where the driver has a pointer on CDLIS). When transmitting the driver history in

subsequent Change State-of-Record, History Search Inquiry, and State-to-State History Request transactions, the SOR

must uniquely identify these convictions in the Driver History Convictions (H3) message and identify the linkages

between a withdrawal and its underlying convictions in the Driver History Withdrawal-Conviction Links (H7) message

(see "CD04 STATE-TO-STATE HISTORY REQUEST" and "CD08 CHANGE STATE OF RECORD" for details). As

a best practice to enable an SOR to efficiently meet these requirements, the SOR should assign a unique internal ID to a

conviction when the SOR enters it in the driver history.

Notes:

In accordance with FMCSA policy Memorandum CDL-04-001, if an SOC issues a Failure to Appear (FTA) or a

Failure to Pay (FTP) or Failure to Comply (FTC) for an out-of-state CDL driver, the SOC will send the failure to

the SOR as an electronic or paper conviction report. When the SOR receives the report, the SOR must enter the

report in the driver history as a conviction for an FTA or FTP or FTC (e.g., 'D56' - "Failure to answer a citation,

pay fines, penalties and/or costs related to the original violation") with the Conviction Offense Detail - ACD

(DCVCDA) set to the ACD offense code for the underlying citation (e.g., 'A04' - "Driving under the influence of

alcohol with BAC at or over .04"). The SOR must then act on the report as if the failure occurred within the





SOR.

The SOC jurisdiction code, the State Native Code, and the SOC Court Report ID are required to be set by the SOC and

to be stored by the current SOR for each conviction. This information allows the SOR and any future SOR to contact

the SOC and request information about the original record of the citation and conviction. This information also enables

the SOC to negate the conviction if necessary. The SOR must not substitute SOR values for this information, because a

future SOR would have a problem even identifying the jurisdiction that had the original record, and the SOC would not

be able to negate the conviction when necessary.


If the SOR posts the conviction, the SOR transmits a Confirm Out-of-State Action (CA) message to the CDLIS Central

Site. If the SOR doesn't post the conviction, the SOR returns the Forward Out-of-State Conviction (HF) message in

error to the CDLIS Central Site.

CD11.3.5.1 Transmission of Confirm Out-of-State Action (CA) Message

After the SOR posts the conviction, the SOR generates the Confirm Out-of-State Action (CA) message to the CDLIS

Central Site.

The Confirm Out-of-State Action (CA) message must include:



Message Sender Password (GMSPSW) set to the password for the SOR


values.

Note: If the conviction results in a disqualification or the conviction is required by NHTSA to be reported to PDPS, a

pointer must to be added to the Problem Driver Pointer System (PDPS), and in some cases, an out-of-state withdrawal

must be added to the CDLIS driver history. See the PDPS documentation for guidance and instructions on the messages

for adding the driver's disqualification to PDPS. See "CD16 REPORT OUT-OF-STATE WITHDRAWAL" for

instructions and guidance on the messages for posting an out-of-state withdrawal in CDLIS.

CD11.3.5.2 Transmission of the Forward Report of Out-of-State Conviction (HF) Message with Errors

The SOR returns the original Forward Report of Out-of-State Conviction (HF) message to the CDLIS Central Site and

does not post the conviction to the driver history if the SOR:

Finds any validation errors on the original Forward Out-of-State Conviction (HF) message

Is unable to locate the driver in its database

Determines that the conviction is already posted

The Forward Out-of-State Conviction (HF) message is unchanged with the following exceptions depending on the

condition encountered:


Message Match Count (GMSCNT) set to:'

o '00' if the SOR is unable to locate the driver

o '01' if the SOR finds one or more validation errors or the conviction is already posted

Message Match Indicator (GMSIND) set to:

o 'Y' if the SOR finds one or more validation errors or the conviction is already posted

o 'N' if the SOR is unable to locate the driver

Message Match Sequence Indicator (GMSMSI) set to:


o '01' if the SOR finds one or more validation errors or the conviction is already posted





Processing Status (GPROST) set to:

o '01' (logic error) if the SOR is unable to locate the driver or the conviction is already posted

o '03' (syntax error) if the SOR finds one or more validation errors

Last Match Indicator (GMSLMI) set to:

o 'Y' if the SOR is unable to locate the driver in its database

o 'N' if the SOR finds one or more validation errors or the conviction is already posted


System Release Code (GMSSRL) set either to a space if the SOR has implemented Release 2.0.0 or earlier or to

'F' if the SOR has implemented Release 4.0.1 or later

Error Block appended (up to 5 occurrences)



values.

CD11.4 Forward Confirmation Information (CDLIS Central Site)

CD11.4.1 Reception

The CDLIS Central Site receives one of two messages from the State of Record (SOR) in response to the originally

submitted Forward Report Out-of-State Conviction (HF) message:

Confirm Out-of-State Action (CA) message, if the driver record is located and the conviction is successfully

posted

Forward Report Out-of-State Conviction (HF) message with error(s), if the previous conditions cannot be

satisfied


Determine the implementation status of the State of Conviction (SOC) by performing ŘCDJ1.2 Verification of Message

Originatorř using the following input:

Jurisdiction Code (BJUCDE) set to the Transaction Originator (GTRORG) from either the Confirm Out-of-State

Action (CA) message or the Forward Report Out-of-State Conviction (HF) message returned in error,

whichever is received

Authorization Function (BJUAFN) set to ŖCAŗ


CD11.4.2.1 Transmission of Confirm Receipt of CA (CS) Message

Upon receipt of a Confirm Out-of-State Action (CA) message from the State of Record (SOR), the CDLIS Central Site

sends a Confirm Receipt of CA (CS) message to the State of Conviction (SOC).

The Confirm Receipt of CA (CS) message must include:


Message Locator (GMSLOC) set to the Message Locator (GMSLOC) from the original Report Out-of-

State Conviction (HA) message.

Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Confirm Out-of-

State Action (CA) message



values.





CD11.4.2.2 Transmission of Report Out-of-State Conviction (HA) Message with Errors

If the SOR returns the Forward Report Out-of-State Conviction (HF) message to the CDLIS Central Site in error, the

CDLIS Central Site forwards the original associated Report Out-of-State Conviction (HA) message back to the SOC

with the Forward Report Out-of-State Conviction (HF) error message(s) appended. All Report Out-of-State Conviction

(HA) values should contain the original values as received with the following exceptions:


Transaction Originator (GTRORG) set to the value on the Forward Report Out-of-State Conviction (HF)

message

Message Sender Password (GMSPSW) set to spaces

Message Origin (GMSORG) set to the CDLIS Central Site Subscriber ID

Message Destination (GMSDST) set to the Transaction Originator (GTRORG) from the Forward Report

Out-of-Conviction (HF) error message

Processing Status (GPROST) set to the value from the associated Forward Report Out-of-Conviction

(HF) message in error

Message Match Count (GMSCNT) set to the value from the associated Forward Report Out-of-

Conviction (HF) message in error

Message Match Indicator (GMSIND) set to the value from the associated Forward Report Out-of-

Conviction (HF) message in error

Message Match Sequence Indicator (GMSMSI) set to the value from the associated Forward Report Out-

of-Conviction (HF) message in error

Last Match Indicator (GMSLMI) set to the value from the associated Forward Report Out-of-Conviction

(HF) message in error




(02/2) blocks.

CD11.5 Process OOS Confirmation Information (State of Conviction (SOC))

CD11.5.1 Reception

The SOC receives one of two messages from the CDLIS Central Site in response to the originally submitted Report

Out-of-State Conviction (HA) message:

Confirm Receipt of CA (CS) message, if the conviction is successfully posted to the driver's record

Report Out-of-State Conviction (HA) message with errors, if the Central Site or the SOR finds an error and the

conviction is not posted to the driver's record

CD11.5.1.1 Reception of Confirm Receipt of CA (CS) Message

Receipt of the Confirm Receipt of CA (CS) message indicates successful completion of the posting of the conviction to

the driver's record by the State of Record (SOR). No further action is required by the SOC.

The Confirm Receipt of CA (CS) message includes:



CD11.5.1.2 Reception of Report Out-of-State Conviction (HA) Message with Errors

Receipt of the Report Out-of-State Conviction (HA) message with errors indicates one of the following:

The CDLIS Central Site found errors in the Report Out-of-State Conviction (HA) message





The driver could not be located on the CDLIS Central Site or the SOR's database

Either the SOC or the SOR is not authorized for the transaction

The SOR had a problem posting the conviction to the driver's record

The SOC reviews any error messages, works with the SOR to correct any problems, and retransmit the original Report

Out-of-State Conviction (HA) message or sends the conviction report by mail.

If the CDLIS Central Site finds an error in the Report Out-of-State Conviction (HA) message, the CDLIS Central Site

returns the Report Out-of-State Conviction (HA) message to the SOC exactly as submitted with error values for:





If the SOR returns the Forward Out-of-State Conviction (HF) message in error to the CDLIS Central Site, the CDLIS

Central Site returns the Report Out-of-State Conviction (HA) message in error to the SOC exactly as submitted except

for the following:

Message Sender Password (GMSPSW)









CD11.5.2 Notes

If the CDLIS Central Site is unable to locate the driver's record based on the driver license number, the conviction

information is returned to the SOC. If the SOC verifies that the driver license number provided to the CDLIS Central

Site is the same number on the conviction record, either an error was made previously or the license may be a fraud.

The SOC may pursue alternative approaches to the problem by using any of the Search Inquiry, State Status Request,

History Request, or History Search Inquiry transactions using all available driver identification data. The goal of further

searches is to obtain a driver license number that can be associated with the convicted driver.



CD12 NEGATE OUT-OF-STATE CONVICTION




Description

Federally mandated convictions are defined in the AAMVA Code Dictionary (ACD) Manual. The Negate Out-of-State

Conviction transaction provides a means for the State of Conviction (SOC) that convicted a driver to notify the State of

Record (SOR) that an ACD conviction previously posted to the Driver History Record (DHR) must be negated (i.e.,

either actually removed or marked as removed) from the driver history.*

* Conviction negations are sent only once and are transmitted either electronically or as a paper copy via mail, but

not both.Ref1

Conviction negations submitted electronically and returned in error are corrected by the SOC before being

resubmitted (or sent by paper copy); sending such conviction negations via paper copy without correction is not

allowed.

If the Negate Out-of-State Conviction is used to correct previously reported incorrect conviction information, the SOC

negates the conviction, then reports the conviction again with the correct information using the Report Out-of-State

Conviction transaction.Ref2

Participants

State of Conviction (SOC)

o U.S. jurisdiction

CDLIS Central Site


o U.S. jurisdiction



Pre-Requisites

To help ensure the success of the transaction, an SOC submits a Search InquiryRef3

or a Verification InquiryRef4

to

the CDLIS Central Site to verify that the correct MPR is identified, and submits a State to State History

RequestRef5

to ensure that the conviction is on the DHR.

Standard Processing

The SOC sends a Negate Out-of-State Conviction message to the CDLIS Central Site.

Upon receipt of the Negate Out-of-State Conviction message, the CDLIS Central Site:

o Validates the driver identification and conviction information in the message*


o Forwards the negate conviction request to the SOR

Upon receipt of the conviction information, the SOR performs the following within 96 hours:

o Validate the driver identification and conviction information in the message

o Retrieve the DHR and locate the conviction

o Negate the conviction

o Send a confirmation to the CDLIS Central Site



o Sends a confirmation to the SOC that the transaction is complete

* The CDLIS Central Site will reject the Negate Out-of-State Conviction message if one of the required fields is

blank. If one of the required fields was blank on the Report Out-of-State Conviction message (possible because the key

data required changed when the Motor Carrier Safety Improvements Act (MCSIA) was implemented), the jurisdiction





sends the conviction negation via mail.

Inputs

The Negate Out-of-State Conviction includes the driverřs license number and jurisdiction code combination, name and

date of birth consistent with the information returned from the inquiries performed prior to submission of the update

(not the information on the citation, if different). It also includes the conviction data exactly as it was originally sent

when reported. The message may optionally contain the driverřs Social Security Number and ACD code detail (as

allowed or required by the code definition).





o The Central Site sends driver identification and conviction negation information received from the SOC

to the SOR


o The SOR sends a confirmation that the conviction has been negated

Central Site to the SOC:

o A confirmation message that the conviction negation is complete


Central Site

o If the Negate Out-of-State Conviction message does not pass the edit validations performed by the CDLIS

Central Site, the Central Site returns an error to the SOC. No further processing is performed.

o If the SOR returns an error after receiving the conviction negation information, the Central Site forwards

the error to the SOC

SOR

o If the SOR cannot locate the driver or conviction upon receipt of conviction negation information, the

SOR returns an error to the CDLIS Central Site.

Post-Requisites

SOC

o In order to answer any questions about the conviction and its negation, the SOC must maintain the

original record of the conviction negation for as long as the conviction would have been maintained as

specified in the AAMVA Code Dictionary (ACD) Manual.

SOR

o The SOR is responsible for determining whether any corrective driver control actions are required based

on the negation of the conviction. After negating the conviction, the SOR interprets the information and

reverses any driver control action in which the conviction resulted (e.g., if the conviction was the sole

cause of a license withdrawal and no additional convictions have been reported, the license is reinstated if

the conviction is negated)

o The SOR is not required to maintain any information about a conviction negation.





References

Reference

#


Ref1 CDLIS State

Procedures Manual


Ref1 CDLIS System

Specifications


Ref3 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref4 CDLIS System

Specifications


Ref5 CDLIS System

Specifications

CD04 STATE TO STATE HISTORY REQUEST

Ref6 CDLIS System

Specifications








HH Negate Out-of-State Conviction

HX Forward Negate Conviction 1

CX Acknowledge Negate Conviction 1

CO Confirm Receipt of CX 1





CD12.1 Request Negation of Conviction (State of Conviction (SOC))


The Negate Out-of-State Conviction Transaction enables the SOC to negate an out-of-state conviction in the DHR

maintained by the SOR. See the following documents for regulations and requirements about negating a conviction:

AAMVA Code Dictionary (ACD) (Release 2.1) Manual (available from the AAMVA Operations Help Desk)


The FMCSA Policy Memorandum CDL 2004-001 (available from FMCSA)

The Drivers License Compact (DLC) (available from the AAMVA Programs Division)

The Non-Resident Violators Compact (NRVC) (available from the AAMVA Programs Division)

The Drivers License Agreement (DLA) (available from the AAMVA Programs Division)


memoranda, the federal regulations and FMCSA policy memoranda must take precedence.

Prior to any Negate Out-of-State Conviction transaction, the SOC initiates a verification or search inquiry to the Central

Site to ensure positive identification of the driver. The verification inquiry may use the Verification Inquiry (IN) or

Verification Inquiry Preceding Report Out-of-State Conviction (ID) message (see "CD02 VERIFICATION INQUIRY"

for formatting instructions) or the Search Inquiry (IM) message, which uses a less restrictive search algorithm (see

"CD01 SEARCH INQUIRY" for formatting instructions).

Upon receipt of the inquiry responses from the SOR, the SOC is responsible for confirming that the driver represented


SOR based on DLN only). This is accomplished by verifying the primary driver identifying data (Name, Date of Birth,

Social Security Number) matches. The SOC may also consider secondary driver identifying data, such as Sex, Height,

Weight, and Eye Color.

Because Mexican drivers are not maintained on the CDLIS Central Site, the SOC does not initiate a verification inquiry

to the Central Site before sending a Negate Out-of-State Conviction on Mexican drivers. The SOC just sends a State-to-

State Status Request (SG) message to 'MX' (to ensure the negation is for the correct driver) and then sends the negate

conviction message. The negate conviction messages will pass through the CDLIS Central site with no MPR-matching

and go directly to 'MX'.

Currently, conviction negations on Canadian drivers cannot be submitted electronically via CDLIS to Canada, so the

SOC must send a paper copy of the conviction negation to the Canadian jurisdiction, when negation is required by

Federal regulations. Similarly, conviction negations on U.S. drivers cannot be submitted electronically via CDLIS by

jurisdictions in Mexico or Canada.

If the SOC is unable to negate an out-of-state conviction electronically via CDLIS, and the SOC is required by

jurisdiction or federal regulations to negate the conviction, the SOC must arrange with the SOR to send the conviction

negation report via mail. If any one of the required conviction data elements is blank for a conviction in the history, the

SOC cannot negate the conviction electronically via CDLIS. Such a conviction can be negated by mail.

CD12.1.2 Transmission of Negate Out-of-State Conviction (HH) Message

The Negate Out-of-State Conviction (HH) message must contain the following:

Message Sender Password (GMSPSW) set to the password assigned to the message originator

System Release Code (GMSSRL) set to space or 'F' (A space indicates the SOC has not implemented Release

4.0.1, while a value of ŘFř typically indicates the SOC has implemented Release 4.0.1 or later; however, an SOC

that has not implemented Release 4.0.1 may set the value to space or ŘFř.)















Jurisdiction Code - Convicting (DCVJUR) set to the jurisdiction code of the SOC

Citation Date (DCIDCI) set to the date on which the original citation was issued

Conviction Date (DCVDCV) set to the date on which the conviction was issued

Conviction Jurisdiction Court Report ID (DCVCLO) set to the unique identifier for the conviction report from

the SOC court

Conviction Jurisdiction Offense Code (DCVCOR) set to the SOC's native code for the type of offense, which

maps to the Conviction Offense ACD Code (DCVCCA)

Conviction Offense ACD Code (DCVCCA) set to the AAMVA Code Dictionary code describing the offense



values.

The Negate Out-of-State Conviction (HH) message may optionally contain the following:


Conviction Court Type (DCVCRT) set to the type of court that finalized the conviction

Conviction Commercial Vehicle Indicator (DCVCOM) set to '1' if a commercial vehicle was being used when

the offense was committed; '2' if not; '9' if unknown

Conviction HAZMAT Indicator (DCVHAZ) set to '1' if the violation occurred while the driver was carrying

hazardous materials; '2' if not; '9' if unknown

Conviction Offense Detail - ACD (DCVCDA) set if the ACD code requires or allows additional details about the

offense (see the ACD for details)

CD12.2 Validate Conviction Negation Data (CDLIS Central Site)

CD12.2.1 Reception of Negate Out-of-State Conviction (HH) Message

Upon receipt of a Negate Out-of-State Conviction (HH) message from a jurisdiction, the CDLIS Central Site initiates



The CDLIS Central Site performs the following validations on the Negate Out-of-State Conviction (HH) message. If




The CDLIS Central Site does fewer non-key validation checks on the Negate Out-of-State Conviction (HH) message

than on the Report Out-of-State Conviction (HA) message. Some convictions are posted with missing, incorrect, or

invalid data. This can happen, for example, with convictions that are posted by mail. The less stringent Negate Out-of-

State Conviction (HH) message validation checks allow such convictions to be negated.

Validate the password and determine the implementation status of the State of Conviction (SOC) by performing


Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Negate Out-of-State

Conviction (HH) message





Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Negate Out-

of-State Conviction (HH) message

Authorization Function (BJUAFN) set to ŖHHŗ







(DDLJDL).



(DDLJDL).




Jurisdiction Code - Convicting (DCVJUR) must be present.


Citation Date (DCIDCI) must be present.


Conviction Date (DCVDCV) must be present.


Conviction Jurisdiction Court Report ID (DCVCLO) must be present.


Conviction Jurisdiction Offense Code (DCVCOR) must be present.


Conviction Offense ACD Code (DCVCCA) must be present.
















DICTIONARY".



DICTIONARYŗ.



Must be numeric





Jurisdiction Code - Convicting (DCVJUR) must contain one of the valid values in the "United States" list under

Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.


System Release Code (GMSSRL) must be space or 'F'.














Convicting (DCVJUR).

Error Text: 'SOC AND TRANSACTION ORIGINATOR DO NOT MATCH'








Jurisdiction Number (DDLJDL) on the Negate Out-of-State Conviction (HH) message are not ŘMXř. If

positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Negate Out-of-State Conviction

(HH) message are ŘMXř, proceed directly to the transmission section.



(DDLJDL) from the Negate Out-of-State Conviction (HH) message; and


(DDLJDL) from the Negate Out-of-State Conviction (HH) message




Access the AKA ST-DLN (CD24) by the following fields from the Negate Out-of-State Conviction (HH)

message:


Number (DDLJDL)


Number (DDLJDL)








The name information on the Negate Out-of-State Conviction (HH) message must correspond with the name

information on the existing Master Pointer (CD20). The comparison is performed as described in 7.2 Name

Comparison





The following data on the Negate Out-of-State Conviction (HH) message must match the corresponding data on the













If present, the last 5 digits of Driver SSN - CDLIS (DDVSS6) must match the CD20 Person SSN Last 5

Digits (BPESSD)




(DDVSSN)





Negate Out-of-State Conviction (HH) message if the values are ŘMXř; otherwise set to the Jurisdiction Code Ŕ


Authorization Function (BJUAFN) set to ŖHXŗ



CD12.2.3.1 Transmission of Forward Negate Conviction (HX) Message

If the Negate Out-of-State Conviction (HH) message is valid, the CDLIS Central Site sends a Forward Negate Out-of-

State Conviction (HX) message to the State of Record (SOR).

The Forward Negate Out-of-State Conviction (HX) message must include:


The Forward Negate Conviction (HX) message must include the following from the Negate Out-of-State Conviction

(HH) message:




(DDLJDL) on the Negate Out-of-State Conviction (HH) message if the values are ŘMXř; otherwise set to



System Release Code (GMSSRL), if present




Conviction Court Type (DCVCRT), if present

Conviction Commercial Vehicle Indicator (DCVCOM), if present

Conviction HAZMAT Indicator (DCVHAZ), if present








Conviction Offense Detail - ACD (DCVCDA), if present

The Forward Negate Conviction (HX) message must include the following from the Master Pointer (CD20) record:


Message Destination (GMSDST) set to the Jurisdiction Code - Licensing (DDLJUR)*






(BPESSD)







*If one or more Change State of Record (CD08) transactions occurred since the negation took place, the jurisdiction

code in positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Negate Out-of-State Conviction

(HH) message will not match the Jurisdiction Code - Licensing (DDLJUR) on the Master Pointer (CD20). In this case,

the CDLIS Central Site transmits the conviction to the SOR on the CD20 record. Old SOR(s) will not be notified.


values.

CD12.2.3.2 Transmission of Negate Out-of-State Conviction (HH) Message with Errors

If the CDLIS Central Site encounters errors on the original Negate Out-of-State Conviction (HH) message that preclude




(02/2) blocks.

CD12.3 Process Conviction Negation (State of Record (SOR))


Upon receipt of the Forward Negate Conviction (HX) message, the SOR validates the message, locates the driver and

the associated conviction on its database, and, if found, negates the conviction from the driver's history record. The

SOR must then evaluate whatever licensing action may be necessary.

Note: If the SOR is unable to negate a conviction electronically via CDLIS, and the SOR is required by jurisdiction or

federal regulations to negate an out-of-state conviction, the SOR must arrange with the SOC to (1) receive the negation

report, (2) negate the conviction, and (3) confirm the negation by mail. The SOR must negate the conviction manually

when it receives the negation. See the CDLIS State Procedures Manual for procedures to negate a conviction by mail.

CD12.3.2 Reception of Forward Negate Out-of-State Conviction (HX) Message

The Forward Negate Out-of-State Conviction (HX) message sent by the CDLIS Central Site contains:









Driver License Jurisdiction Number (DDLJDL) composed of the following two data elements:












The Forward Negate Conviction (HX) message may optionally contain:





CD12.3.3 Validation

The SOR performs the following validation checks on the Forward Negate Conviction (HX) message. If the SOR

detects any errors, it sets the error fields (see Ŗ4 CDLIS ERROR PROCESSINGŗ for details), returns the original

message to its sender for correction, and stops processing the transaction.

Note: The SOR must not return the Forward Negate Conviction (HX) message for an invalid Conviction Offense ACD

Code, because the original conviction may have had the erroneous code. If the message having a retired ACD code

passes other validation checks and the SOR finds a matching conviction, the SOR must negate the matching conviction.




CDLIS (DDVSS6) are not permitted. If the SOR does not find a match, issue an error.


CD12.3.3.2 Conviction Not Found Error

The SOR must find the conviction on the CDLIS driver history, as defined by a match on the following data elements

(which uniquely identify a specific conviction):

Jurisdiction Code Ŕ Convicting (DCVJUR)










If the SOR determines that the conviction does not match a previously posted conviction, the SOR rejects the conviction

and issues an error. The SOR does not negate the conviction and evaluates any driver control actions taken based on the

conviction.

Error Text: 'CONVICTION NOT FOUND'

If the conviction is not found, the SOR should contact the SOC and manually determine why the negation was sent,

especially if the conviction matches on five or fewer of the identifying data elements.

Note: The jurisdiction must have equivalent procedures in place to handle a "conviction not found" error when entering

paper conviction negations.

If more than one conviction is found by matching on the six data elements, the SOR must reject the conviction negation

report and issue an error. The SOR takes no additional driver-control actions.

Error Text: 'DUPLICATE CONVICTIONS FOUND'

If more than one conviction is found, the SOR should contact the SOC and manually determine why duplicates exist

and why the negation was sent.

Note: The jurisdiction must have equivalent procedures in place to handle a "DUPLICATE CONVICTIONS FOUND"

error when entering paper conviction negations.

CD12.3.4 Updates

The SOR does not negate any conviction from the driver history if errors are encountered in the Forward Negate

Conviction (HX) message. If no errors are found, the SOR negates the conviction from the driver's history record and

evaluates whatever licensing action may be necessary in accordance with federal and jurisdiction laws and rules. Thus,

in addition to removing federally mandated disqualifications based on the conviction, jurisdictions must consult their

own regulations and procedures that govern the driver improvement action. The AAMVA Code Dictionary (ACD)

Manual , ACD Implementation Guides, and the CDLIS State Procedures Manual provide guidance on the convictions

and disqualifications and their removal.


If the SOR posts the conviction, the SOR transmits an Acknowledge Negate Conviction (CX) message to the CDLIS

Central Site. If the SOR doesn't negate the conviction, it returns the Forward Negate Conviction (HX) message in error

to the CDLIS Central Site.

CD12.3.5.1 Transmission of Acknowledge Negate Conviction (CX) Message

After the SOR negates the conviction, the SOR sends the Acknowledge Negate Conviction (CX) message to the CDLIS

Central Site.

The Confirm Negate Conviction (CX) message must include:



Message Sender Password (GMSPSW) set to the password of the SOR


values.

Note: If the conviction results in a disqualification or the conviction is required by NHTSA to be reported to PDPS, a

pointer should have been added to the Problem Driver Pointer System (PDPS). If the underlying conviction is negated,

see the PDPS documentation for guidance and instructions on the messages for deleting the PDPS pointer. In some

cases, an out-of-state withdrawal should have been added to the driver history. If the underlying conviction is negated,

see "CD17 NEGATE OUT-OF-STATE WITHDRAWAL" for guidance and instructions on the messages for negating

an out-of-state withdrawal in CDLIS.





CD12.3.5.2 Transmission of Forward Negate Conviction (HX) Message with Errors

The SOR returns the original Forward Negate Conviction (HX) message to the CDLIS Central Site and does not negate

the conviction on the driver history, if the SOR:

Finds any validation errors on the original Forward Negate Conviction (HX) message


Determines that the conviction cannot be negated (either it was never received or has already been negated)

The Forward Negate Conviction (HX) message is unchanged with the following exceptions:


Message Match Count (GMSCNT) set to:


o '01' if the SOR finds one or more validation errors or determines that the conviction cannot be negated

Message Match Indicator (GMSIND) set to:

o 'Y' if the SOR finds one or more validation errors or the conviction cannot be negated

o 'N' if the SOR is unable to locate the driver in its database

Message Match Sequence Indicator (GMSMSI) set to:

o '00' if the SOR is unable to locate the driver in its database

o '01' if the SOR finds one or more validation errors or the conviction cannot be negated

Processing Status (GPROST) set to:

o '01' (logic error) if the SOR is unable to locate the driver or negate the conviction

o '03' (syntax error) if the SOR finds one or more validation errors

Last Match Indicator (GMSLMI) set to:

o 'Y' if the SOR is unable to locate the driver in its database

o 'N' if the SOR finds one or more validation errors or the conviction cannot be negated

Message Sender Password (GMSSRL) set to the password for the SOR

System Release Code (GMSSRL) set either to a space if the SOR has implemented Release 2.0.0 or earlier or to

'F' if the SOR has implemented Release 4.0.1 or later




values.

CD12.4 Forward Conviction Negation Data (CDLIS Central Site)

CD12.4.1 Reception


submitted Forward Negate Conviction (HX) message:

Acknowledge Negate Conviction (CX) message, if the driver record is located and the conviction is negated

Forward Negate Conviction (HX) message with error(s), if the previous conditions cannot be satisfied


Determine the implementation status of the State of Conviction (SOC) by performing ŘCDJ1.2 Verification of Message

Originatorř using the following input:

Jurisdiction Code (BJUCDE) set to the Transaction Originator (GTRORG) from either the Acknowledge Negate

Conviction (CX) message or the Forward Negate Conviction (HX) message returned in error, whichever is





received

Authorization Function (BJUAFN) set to ŖCXŗ


CD12.4.2.1 Transmission of Confirm Receipt of CX (CO) Message

Upon receipt of an Acknowledge Negate Conviction (CX) message from the State of Record (SOR), the CDLIS Central

Site sends a Confirm Receipt of CX (CO) message to the State of Conviction (SOC).

The Confirm Receipt of CX (CO) message must include:


Message Locator (GMSLOC) set to the Message Locator (GMSLOC) from the original Negate Out-of-

State Conviction (HH) message.

Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Acknowledge

Negate Conviction (CX) message



values.

CD12.4.2.2 Transmission of Negate Out-of-State Conviction (HH) Message with Errors

If the SOR returns the Forward Negate Conviction (HX) message to the CDLIS Central Site in error, the CDLIS Central

Site forwards the original associated Negate Out-of-State Conviction (HH) message back to the SOC with the Forward

Negate Conviction (HX) error message(s) appended. All Negate Out-of-State Conviction (HH) values should contain

the orginal values as received with the following exceptions:


Transaction Originator (GTRORG) set to the value on the Forward Negate Out-of-State Conviction (HX)

message



Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Forward Negate

Conviction (HX) error message

Processing Status (GPROST) set to the value from the associated Negate Out-of-State Conviction (HX)

message in error

Message Match Count (GMSCNT) set to the value from the associated Negate Out-of-State Conviction

(HX) message in error

Message Match Indicator (GMSIND) set to the value from the associated Negate Out-of-State Conviction


Message Match Sequence Indicator (GMSMSI) set to the value from the associated Negate Out-of-State

Conviction (HX) message in error

Last Match Indicator (GMSLMI) set to the value from the associated Negate Out-of-State Conviction




See ŖAPPENDIX A - DATA ELEMENTS BY MESSAGE TYPEŗ for remaining elements in the NCB (00/0) and MEC

(02/2) blocks. All other elements are passed through from the original Negate Out-of-State Conviction (HH) message.





CD12.5 Process Conviction Negation Data (State of Conviction (SOC))


The SOC receives one of two messages from the CDLIS Central Site in response to the originally submitted Negate

Out-of-State Conviction (HH) message:

Confirm Receipt of CX (CO) message, if the conviction is successfully negated from the driver's record

Negate Out-of-State Conviction (HH) message with errors, if the conviction is not successfully negated from the

driver's record

CD12.5.2 Reception

CD12.5.2.1 Reception of Confirm Receipt of CX (CO) Message

Receipt of the Confirm Receipt of CX (CO) message indicates successful completion of the negation of the conviction

from the driver's record by the State of Record (SOR). No further action is required by the SOC.

The Confirm Receipt of CX (CO) message includes:



CD12.5.2.2 Reception of Negate Out-of-State Conviction (HH) Message with Errors

Receipt of the Negate Out-of-State Conviction (HH) message with errors indicates one of the following:

The CDLIS Central Site found errors in the Negate Out-of-State Conviction (HH) message


Either the SOC or the SOR is not authorized for the transaction

The SOR had a problem negating the conviction on the driver's record.

If either the SOC or the SOR is not authorized for the transaction, or if the SOR had a problem negating the conviction

on the driverřs record, the SOC and SOR should work with each other to correct any problems and complete the

negation manually.

If the CDLIS Central Site found errors in the Negate Out-of-State Conviction (HH) message, or if the driver could not

be located on the CDLIS Central Site or the SORřs database, the SOC should review any error messages, work with the

SOR to correct any problems as appropriate, and retransmit the original Negate Out-of-State Conviction (HH) message.

If the CDLIS Central Site was unable to locate the driver's record based on the ST/DLN (combination of jurisdiction

code and driver license number), the negate conviction information is returned to the SOC. If the SOC verifies that the

driver's license number provided to the CDLIS Central Site was the same number on the negate conviction record,

either an error was made previously or the license may be a fraud. The SOC may pursue alternative approaches to the

problem by using any of the Search Inquiry, State Status Request, History Request, or History Search Inquiry

transactions using all available driver identification data. The goal of further searches is to obtain the current

information associated with the convicted driver.

If the CDLIS Central Site or the SOR could not locate the requested driver, the Negate Out-of-State Conviction (HH)

message is returned to the SOC exactly as submitted with the following exceptions:





If the SOR returns the Forward Negate Conviction (HX) message in error to the CDLIS Central Site, the CDLIS Central

Site returns the Negate Out-of-State Conviction (HH) message in error to the SOC exactly as submitted with the

following possible exceptions:















values.



CD14 MARK DRIVER UNIQUE




Description

The CDLIS Central Site checks for possible duplicate drivers based on Social Security Number (SSN) on every Add

New Driver and Update AKA Data transaction. It also performs the check for any Change State of Record (CSOR) and

Change Data transaction if the name, date of birth, or SSN is changed. When duplicates are found, the Master Pointer

Record (MPR) of each possible duplicate driver is marked as such and notifications are sent to the SOR(s) impacted.Ref1

The SORs receiving notifications determine whether or not the drivers are duplicates. If the SORs determine the

matching information on the possible duplicates is accurate and positive determination is been made that the drivers are,

indeed, unique, both SORs initiate the Mark Unique transaction to specify that the two drivers with matching

identification information are not the same.

Once a pair of drivers is marked unique to each other, they will no longer be identified as possible duplicates when

subsequent changes that initiate the duplicate search logic are made to either record. No CDLIS Possible Duplicate

(NA) messages will be sent identifying these two records as potential duplicates.

To simplify this Business Process Overview, the terms ŖInitiating SORŗ and ŖEstablished SORŗ are used to refer to the

two SORs that initiate a Mark Unique transaction. The Initiating SOR is the SOR that submitted the message that

caused a potential duplicate to be created. The Established SOR is the SOR that had a record on the CDLIS Central Site

at the time the Initiating SOR created the potential duplicate.

Participants

Initiating State of Record (SOR) #1

o U.S. jurisdiction

CDLIS Central Site

Established State of Record (SOR) #2

o U.S. jurisdiction

Pre-Requisites

To help ensure the success of the transaction, an SOR may submit a Verification Inquiry Preceding Change

Data/Mark Driver Unique Ref2

to the CDLIS Central Site to verify that the correct MPR is identified.

Standard Processing

Initiating SOR sends a Mark Unique message to the CDLIS Central Site.

Established SOR sends a Mark Unique message to the CDLIS Central Site.

Upon receipt of both Mark Unique messages, the CDLIS Central Site:

o Validates the driver and duplicate driver identification information in both messages

o Removes the duplicate designation on both MPRsRef1

o Issues notifications of duplicate resolution to both SORs

o Returns a confirmation to both SORs

Inputs

The Initiating SOR submits a Mark Unique message that includes all required driver identification information (name,

date of birth, driver's license number and jurisdiction code combination, Social Security Number) for both drivers.

The Established SOR submits a Mark Unique message that includes all required driver identification information

(name, date of birth, driver's license number and jurisdiction code combination, Social Security Number) for both

drivers.








Central Site to the Initiating SOR:

o A confirmation message that the driver has been marked unique

o A notification of duplicate resolution message

Central Site to the Established SOR:

o A confirmation message that the driver has been marked unique

o A notification of duplicate resolution message


Central Site

o If the Mark Unique message does not pass the edit validations performed by the CDLIS Central Site, the

Central Site returns an error to the SOR. No further processing is performed. If the Mark Unique message

of the other SOR passes the edit validations, it is held until a corrected Mark Unique message is received

from the first SOR.

Post-Requisites

None

References

Reference

#


Ref1 CDLIS System

Specifications


Ref2 CDLIS System

Specifications


Ref3 CDLIS System

Specifications









UG Mark Driver Unique







CD14.1 Request Drivers be Marked Unique (States of Record (SORs))


After a determination that two drivers are not duplicates, each SOR involved has the responsibility for marking its

driver unique to the other. An SOR can mark its driver unique to only one other driver with a single Mark Driver

Unique (UG) message. One jurisdiction flagging a pointer record as unique does not clear the 96-hour clock (set at the

CDLIS Central Site when Possible Duplicate (NA) messages are sent).

CD14.1.2 Transmission of Mark Driver Unique (UG) Message

The Mark Driver Unique (UG) message must contain:

Driver Duplicate Date of Birth (DDVDO2) set to the date of birth of the other jurisdiction's driver

Driver Date of Birth (DDVDOB) set to the date of birth of the jurisdiction's driver

Driver License Duplicate Jurisdiction Number (DDLJD5) set to the ST/DLN (combination of jurisdiction code

and driver's license number) of the other jurisdiction's driver

Driver License Jurisdiction Number (DDLJDL) set to the driver's license number of the jurisdiction's driver

Driver Duplicate SSN (DDVSS2) set to the Social Security Number of the other jurisdiction's driver

Driver SSN - CDLIS (DDVSS6) set to the Social Security Number of the jurisdiction's driver

Person Duplicate Name Group (BPENG2) set to the name of the other jurisdiction's driver

Person Name Group (BPENGP) set to the name of the jurisdiction's driver

The Mark Driver Unique (UG) message may optionally contain:

Return as Received Text Block (GRRECV) set to any value desired by the SOR (typically, the key in the SOR's

database for future processing)


values.

CD14.2 Process Mark Unique Request (CDLIS Central Site)

CD14.2.1 Reception of Mark Driver Unique (UG) Message

Upon receipt of a Mark Driver Unique (UG) message from a jurisdiction, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Mark Driver Unique (UG) message. If errors are






Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Mark Driver Unique (UG)

message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Mark Driver

Unique (UG) message

Authorization Function (BJUAFN) set to ŖUGŗ











(DDLJDL).



(DDLJDL).






A code identifying the other jurisdiction must be present in positions 1 - 2 of the Driver Duplicate License

Jurisdiction Number (DDLJD5).


The other driverřs license number must be present in positions 3 - 27 of the Driver Duplicate License Jurisdiction

Number (DDLJD5).


Driver Duplicate Date of Birth (DDVDO2) must be present.


Driver Duplicate SSN (DDVSS2) must be present.





At least one component field of Person Duplicate Name Group (BPENG2) must be present.





Driver Duplicate Name (DDVNM3) must be present.












DICTIONARYŗ.


Driver SSN - CDLIS (DDVSS6) must be numeric and cannot be all zeroes.


Positions 1 - 2 of the Driver Duplicate License Jurisdiction Number (DDLJD5) must contain one of the valid


DICTIONARYŗ.


Driver Duplicate Date of Birth (DDVDO2) must be a valid date and formatted as specified in ŖAPPENDIX D -

DATA DICTIONARYŗ.


Driver Duplicate SSN (DDVSS2) must be valid.







Person Duplicate Name Group (BPENG2) must conform to the requirements listed in "APPENDIX E.3 -

AAMVA PERSON NAME STANDARD (2008) VALIDATIONS".




If present, Driver Name (DDVNAM) must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ

AAMVA PERSON NAME FORMATTING RULESŗ.


If present, Driver Duplicate Name (DDVNM3) must conform to the requirements listed in ŖAPPENDIX

E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ.











Ensure that both the initiating driver and the established driver on the Mark Driver Unique (UG) message already exist

on the Master Pointer (CD20) data store. Each Master Pointer (CD20) must have an associated Duplicate Pointer

(CD23) record indicating that the two drivers are duplicates of each other.

The initiating driver is identified by the Driver License Jurisdiction Number (DDLJDL) on the Mark Driver Unique

(UG) message. Access the Master Pointer (CD20) data store by:


(DDLJDL) from the Mark Driver Unique (UG) message; and


(DDLJDL) from the Mark Driver Unique (UG) message

A record must be found.


Access the Duplicate Pointer (CD23) associated with the primary driverřs CD20 record by:

Duplicate Licensing Jurisdiction Code (DDLJU6) using positions 1 - 2 of the Driver Duplicate License

Jurisdiction Number (DDLJD5) on the Mark Driver Unique (UG) message; and

Duplicate Driver License Number (DDLNU5) using positions 3 - 27 of the Driver Duplicate License Jurisdiction

Number (DDLJD5) on the Mark Driver Unique (UG) message



Error Text: 'DRIVERS NOT FLAGGED AS DUPL OF EACH OTHER’


Error Text: 'CDID NOT FOUND ON DUP LIST FOR UG'

The established driver is identified by the Driver Duplicate License Jurisdiction Number (DDLJD5) on the Mark Driver

Unique (UG) message. Access the Master Pointer (CD20) data store by:

Jurisdiction Code - Licensing (DDLJUR) using positions 1 - 2 of the Driver Duplicate License Jurisdiction

Number (DDLJD5) from the Mark Driver Unique (UG) message; and

Driver License Number (DDLNUM) using positions 3 - 27 of the Driver Duplicate License Jurisdiction Number

(DDLJD5) from the Mark Driver Unique (UG) message



Access the Duplicate Pointer (CD23) associated with the duplicate driverřs CD20 record by:

Duplicate Licensing Jurisdiction Code (DDLJU6) using positions 1 - 2 of the Driver License Jurisdiction

Number (DDLJDL) on the Mark Driver Unique (UG) message; and

Duplicate Driver License Number (DDLNU5) using positions 3 - 27 of the Driver License Jurisdiction Number

(DDLJDL) on the Mark Driver Unique (UG) message











The Message SOR Change in Progress Indicator (GMSSCH) on both existing Master Pointer (CD20) records must

equal ŘNř.


On the retrieved Duplicate Pointer (CD23) for the initiating driver, the Master Pointer Unique Indicator (DCDPUI) must

equal ŘDř (Possible Duplicate) or ŘPř (Mark Unique Pending).





On the retrieved Duplicate Pointer (CD23) for the established driver, the Master Pointer Unique Indicator (DCDPUI)

must equal ŘDř (Possible Duplicate) or ŘPř (Mark Unique Pending).





CD14.2.3 Updates


to do the following:

Update the appropriate Master Pointer Unique Indicators (DCDPUI) on the Duplicate Pointer (CD23) records to

ŘPř (Mark Unique Pending) if they already equal ŘDř (Possible Duplicate), or to ŘUř (Mark Unique Completed) if

they already equal ŘPř (Mark Unique Pending).

Send the associated Duplicate Resolved (NE) messages, if necessary.

Pass the following information from the Mark Driver Unique (UG) message (or from the Master Pointer (CD20) where









CD20 Driver Sex (DDVSEX)







When updates are successfully completed, the CDLIS Central Site sends a Confirm Change Data Complete (CD)

message to the State of Record (SOR).

Because the ŖCDA1 DUPLICATE DRIVER PROCESSŗ does not perform a duplicate creation check, the Confirm

Change Data Complete (CD) message returned here differs from the CD returned in the Change Data (CD09)

transaction in the way some of the message exchange control fields are set.



Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Mark Driver Unique (UG)

message


Message Match Count (GMSCNT) set to the Number of Duplicate Drivers Identified returned by the

ŖCDA1 DUPLICATE DRIVER PROCESSŗ




Message Match Limit Exceeded Indicator (GMSLEI) set to 'N'

Message SOR Change in Progress Indicator (GMSSCH) set to the First Dup CSOR Indicator returned by

the ŖCDA1 DUPLICATE DRIVER PROCESSŗ

Driver Duplicate Indicator (GMSDUP)

set to 'N' if:

The CD20 has no associated Duplicate Pointer (CD23) records; or

All associated Duplicate Pointer (CD23) records have the Master Pointer Unique Indicator

(DCDPUI) equal to ŘUř (Mark Unique Complete)

set to ŘYř if

the CD20 record has at least one associated Duplicate Pointer (CD23) record with Master Pointer


Message AKA DLN Count (GMSCDL) set to the number of ST-DLN Pointer (CD24) records being sent

on the message, up to a maximum of 3

Message AKA Name Count (GMSCNM) set to the number of Name Pointer (CD22) records being sent

on the message, up to a maximum of 3



For those Jurisdictions at a version older than 5.1:






values.

CD14.2.4.2 Transmission of Mark Driver Unique (UG) Message with Errors

If the CDLIS Central Site encounters errors on the original Mark Driver Unique (UG) message that preclude further








(02/2) blocks.

CD14.3 Process Mark Unique Response (State of Record)


Each SOR receives one of two messages from the CDLIS Central Site in response to the originally submitted Mark

Driver Unique (UG) message:

Confirm Change Data Complete (CD) message, if the Mark Driver Unique (UG) message was successfully

processed

Mark Driver Unique (UG) message with errors, if any errors were encountered in validating the UG

If the Confirm Change Data Complete (CD) message is received, the SOR may additionally receive one or more

Duplicate Resolved (NE) messages, indicating that one or more possible duplicates have been resolved. See section

ŘCDA1 DUPLICATE DRIVER PROCESSř for details.

CD14.3.2 Reception


The Confirm Change Data Complete (CD) message includes:














CD14.3.2.2 Reception of Mark Driver Unique (UG) Message with Errors

If the CDLIS Central Site was unable to locate one or both of the drivers referenced on the UG, the UG is returned as

originally submitted with the following exceptions:


Process Status (GPROST)









Description

The Update AKA Data transaction enables a State of Record (SOR) to correct the AKA information on a Master Pointer

Record (MPR) at the CDLIS Central Site. The Update AKA Data transaction removes all existing AKA information

and replaces it with the new AKA information submitted on the Update AKA Data message.

AKA data includes up to 3 occurrences of the name, and up to 3 occurrences of the combined jurisdiction code and

driverřs license number.

The Update AKA Data transaction cannot change any primary data elements on the MPR and only the current SOR can

submit the transaction.

Participants


o U.S. jurisdiction

CDLIS Central Site

Pre-Requisites

To help ensure the success of the transaction, a SOR submits a AKA Data InquiryRef1

to the CDLIS Central Site to

verify that the correct drivers are identified and to confirm the AKA data to be replaced.

A Search Inquiry Ref2

or a Verification Inquiry Ref3

returns only those AKA fields from the MPR that were essential in

determining the match, so neither is sufficient to confirm all the AKA data to be updated.

Standard Processing

An SOR sends an Update AKA Data message to the CDLIS Central Site.

Upon receipt of the Update AKA Data message, the CDLIS Central Site:


o Checks to see if the new AKA data creates a possible duplicate driver; if so, issues notifications of

possible duplicate driver to all SORs affected, including the SOR that submitted the Update AKA Data

messageRef4

o Replaces all existing AKA information on the MPR with the information provided on the Update AKA

Data message, unless a Change State of Record is in progress


o Determines whether any drivers previously identified as possible duplicates will no longer be duplicates

once the AKA data is updated; if so, issues notifications of duplicate resolution to all SORs affected Ref4

Inputs

The Update AKA Data message includes the driverřs identification data (name, date of birth, driver's license number

and jurisdiction code combination, Social Security Number) consistent with the information returned from the AKA

Data Inquiry performed prior to submission of the update.



Care must be taken when using the Update AKA Data transaction, as it deletes the three most recent occurrences of all

AKA data and replaces them with the data provided on the Update AKA Data message. If only one occurrence of

existing AKA data needs to be changed, the remaining data must be included on the Update AKA Data message exactly

as it currently exists on file.

The concept of 'AKA roll down' used by the Change Data transaction,Ref5

does not apply to the Update AKA Data

transaction.





Example

A driver currently has one AKA combined ST-DLN and one AKA name. If only

the AKA combined ST-DLN is to be changed, the AKA name is entered on the

Update AKA Data message using the same value as exists on the MPR. If AKA

name is not included on the message, the AKA name is removed from the MPR.



o A confirmation message that the driver was successfully updated

o A notification message if a possible duplicate driver is created

o A notification message if a duplicate driver is resolved


o If one or more possible duplicate drivers are created, the Central Site sends notifications to the SORs for

those drivers

o If one or more duplicate drivers are resolved, the Central Site sends notifications to the SORs for those

drivers


Central Site

o If the Update AKA Data message does not pass the edit validations performed by the CDLIS Central Site,

the Central Site returns an error to the SOR. No further processing is performed.

Post-Requisites

None

References

Reference

#


Ref1 CDLIS System

Specifications


Ref2 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref3 CDLIS System

Specifications


Ref4 CDLIS System

Specifications


Ref5 CDLIS System

Specifications

CD09 CHANGE DATA

Ref6 CDLIS System

Specifications









UK Update AKA Data








CD15.1 Request Update of AKA Data (State of Record (SOR))


The SOR begins the Update AKA process by initiating an AKA Inquiry (IK) message to the CDLIS Central Site to

determine the existing AKA data and ensure correction of the appropriate elements. If the SOR intends to insert new

values for an AKA Name it must first initiate a Search Inquiry (Search Inquiry (IM)/(IO)) transaction that includes the

new AKA data to determine if other drivers exist with the same AKA data.

CD15.1.2 Transmission of Update AKA Data (UK) Message

The Update AKA Data (UK) message must include:


Driver Old Date of Birth (DDVDO1) set to the current date of birth of the driver

Driver License Old Jurisdiction Number (DDLJD1) set to the current ST/DLN (combination of jurisdiction code

and driver's license number) of the driver

Driver Old Social Security Number (DDVSS1) set to the current SSN of the driver

Person Old Name Group (BPENG1) set to the current name of the driver


values.

The Update AKA Data (UK) message may optionally include:

Message AKA DLN Count (GMSCDL) set to the current number of AKA DLNs being sent on the Update AKA

Data (UK) message

Message AKA Name Count (GMSCNM) set to the current number of AKA Names being sent on the Update

AKA Data (UK) message

AKA Driver License Jurisdiction Number (DDLJD2) set to the first ST/DLN (combination of jurisdiction code

and driver's license number) associated with the driver other than the current ST/DLN

AKA 2nd Driver License Jurisdiction Number (DDLJD3) set to the second ST/DLN associated with the driver


AKA 3rd Driver License Jurisdiction Number (DDLJD4) set to the third ST/DLN associated with the driver


Return as Received Text Block (GRRECV) set to any value desired by the SOR (typically, the key in the SOR's

database for future processing) (up to 5)







CD15.2 Update AKA Data (CDLIS Central Site)

CD15.2.1 Reception of Update AKA Data (UK) Message

Upon receipt of an Update AKA Data (UK) message from a jurisdiction, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Update AKA Data (UK) message. If errors are










Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Update AKA Data (UK)

message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Update AKA

Data (UK) message

Authorization Function (BJUAFN) set to ŖUKŗ






A code identifying the old jurisdiction must be present in positions 1 - 2 of the Driver License Old Jurisdiction

Number (DDLJD1).










At least one component field of Person Old Name Group (BPENG1) must be present















DICTIONARYŗ.





following:

ŘMXř




DATA DICTIONARYŗ


Positions 1 - 2 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3) , if present, must contain one of

the following:

ŘMXř




DATA DICTIONARYŗ


Positions 1 - 2 of the AKA 3rd Driver License Jurisdiction Number (DDLJD4) , if present, must contain one of

the following:

ŘMXř




DATA DICTIONARYŗ


Message AKA DLN Count (GMSCDL), if present, must be valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.


Message AKA Name Count (GMSCNM), if present, must be valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.






























Driver AKA Name (DDVKNM), if present, must conform to the requirements listed in the ŖAPPENDIX



Driver AKA 2nd Name (DDVKN2), if present, must conform to the requirements listed in the



Driver AKA 3rd Name (DDVKN3), if present, must conform to the requirements listed in the

































Number (DDLJD4).




Message AKA Name Count (GMSCNM) must match the actual number of Person AKA Name Group

(BPENG3) occurrences received.








Ensure that the Master Pointer (CD20) record to be updated exists. Access the Master Pointer (CD20) data store by:


(DDLJD1) from the Update AKA Data (UK) message; and


(DDLJD1) from the Update AKA Data (UK) message










If AKA Driver License Jurisdiction Number (DDLJD2) is present on the Update AKA Data (UK) message,

access the Master Pointer (CD20) data store by:


Number (DDLJD2) from the Update AKA Data (UK) message; and


Number (DDLJD2) from the Update AKA Data (UK) message



If AKA Driver License Jurisdiction Number (DDLJD2) is present on the Update AKA Data (UK) message,

access the AKA ST-DLN (CD24) data store by:


Jurisdiction Number (DDLJD2) from the Update AKA Data (UK) message; and







If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the Update AKA Data (UK) message,








If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the Update AKA Data (UK) message,





Jurisdiction Number (DDLJD3) from the Update AKA Data (UK) message





If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the Update AKA Data (UK) message,












If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the Update AKA Data (UK) message,





Jurisdiction Number (DDLJD4) from the Update AKA Data (UK) message




Note: The CDLIS Central Site allows the reuse of a ST-DLN, but only for the same driver.


The Message SOR Change in Progress Indicator (GMSSCH) on the existing Master Pointer (CD20) record must equal

ŘNř.


The name information on the Update AKA Data (UK) message must correspond with the name information on the

existing Master Pointer (CD20). The comparison is performed as described in "7.2 Name Comparison"





The following data on the Update AKA Data (UK) message must match the corresponding data on the existing Master

Pointer (CD20) record:








The last 5 positions of Driver Old SSN (DDVSS1) must match the CD20 Person SSN Last 5 Digits

(BPESSD)










If the Update AKA Data (UK) message is valid, perform





CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)" in the ŖCDA1 DUPLICATE DRIVER PROCESSŗ

to check for possible duplicate drivers.

Pass the following information from the Update AKA Data (UK) message (or from the Master Pointer (CD20) where












Confirm Change Data Complete (CD) message.

CD15.2.4 Updates

If one or more ST-DLN Pointer (CD24) records associated with the retrieved Master Pointer (CD20) are found, set the

AKA ST-DLN Status (DDLKST) to ŘIř on the three most recent CD24 records where the AKA ST-DLN Status

(DDLKST) = ŘAř. Set other fields as follows:



Each ST-DLN Pointer (CD24) record must have a unique Date of Last Update (GRCUDT) and Time of Last Update

(GRCUTM) combination. When setting the Time of Last Update (GRCUTM), if a duplicate date/time will be created,

increment the time by one second until a unique combination is found.

Delete the three most recent AKA Name (CD22) records, if found.

If any of the following fields are included on the Update AKA Data (UK) message, perform the ŖCDF1 CREATE AKA

FROM UPDATE MESSAGE (CDLIS Central Site)ŗ process.



















When updates and the ŖCDA1 DUPLICATE DRIVER PROCESSŗ are successfully completed, the CDLIS Central Site

sends a Confirm Change Data Complete (CD) message to the State of Record (SOR).



Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Update AKA Data (UK)

message


Message Match Count (GMSCNT) set to the Number of Duplicate Drivers Identified returned by the ŖCDA1

DUPLICATE DRIVER PROCESSŗ, up to a maximum of Ř5ř





set to ŘNř




Ř0ř; otherwise set to the First Dup CSOR Indicator returned by the ŖCDA1 DUPLICATE DRIVER PROCESSŗ












values.

CD15.2.5.2 Transmission of Update AKA Data (UK) Message with Errors

If the CDLIS Central Site encounters errors on the original Update AKA Data (UK) message that preclude further




(02/2) blocks.

CD15.3 Process AKA Update Response (State of Record (SOR))


After submitting the Update AKA Data (UK) message, the SOR receives one of two messages:





Confirm Change Data Complete (CD) message

Update AKA Data (UK) message returned with errors

If the Confirm Change Data Complete (CD) message is received, the SOR may additionally receive;

one or more Possible Duplicate (NA) messages, indicating that the driver has been identified as a possible

duplicate driver and/or

one or more Duplicate Resolved (NE) messages, indicating that one or more possible duplicates have been

resolved. See section ŘCDA1 DUPLICATE DRIVER PROCESSř for details.

CD15.3.2 Reception


If the Update AKA Data (UK) message was processed without error, the CDLIS Central Site sends a Confirm Change

Data Complete (CD) message to the SOR.

The Confirm Change Data Complete (CD) message contains:













Return as Received Text/Block (GRRECV) (up to 5)

CD15.3.2.2 Reception of Update AKA Data (UK) Message with Errors

If the CDLIS Central Site encountered errors which preclude processing, the Update AKA Data (UK) message is

returned to the SOR exactly as submitted with the following data elements set:











Description

The Report Out-of-State Withdrawal transaction is used to report driving privilege withdrawals (one at a time) and

underlying ACD convictions on an out-of-state CDLIS driver to the State of Record (SOR)*. Because the State of

Withdrawalřs (SOW's) underlying conviction(s) may lead to a driver's license withdrawal by the SOR, the SOW

transmits complete and accurate withdrawal and underlying conviction reports within the required time limits.

The transaction enables jurisdictions to comply with the federal requirement [49 CFR §394.208] that the SOW must

report to the SOR, within 10 days of the disqualification, any out-of-state disqualification of a Commercial Driverřs

License (CDL) holder that:

Is the result of conviction(s) for violation of any jurisdiction or local law relating to motor vehicle traffic control

(other than a parking violation); and

Has a withdrawal period that is indefinite, permanent or equal to 60 days or more

When the SOW withdraws a non-CDL holder for one or more convictions in a Commercial Motor Vehicle (CMV), the

SOW has defined responsibilities for determining the SOR. See Report Out-of-State Conviction (CD11) Ref2

for more

detailed information.

Although not required, an SOW may also report a withdrawal:

That has a withdrawal period less than 60 days

That is based on a non-traffic, i.e., non-ACD, violation, by using the ACD code ŘW00ř*

On any driver who has a pointer on CDLIS regardless of whether they currently hold a CDL (for example, a

former CDL holder who has down-graded to a non-CDL)

If the withdrawal effective date is after October 31, 2005, the SOW includes all underlying ACD convictions with the

withdrawal except in the following cases:

Not all withdrawals require an underlying conviction. For instance, for a withdrawal for failure to surrender

HAZMAT endorsement, as required by the USA PATRIOT Act, an underlying conviction is optional.

The SOW does not report any non-ACD convictions as underlying convictions. For example, when the

withdrawal is based on a non-traffic conviction, the underlying conviction is not reported.

If there are more than 14 underlying ACD convictions, then the first 14 are transmitted electronically and all are

mailed.Ref1

If the withdrawal effective date is on or after November 1, 2005 and is for federally mandated conviction(s), the SOR

records the linkage on the Driver History Record (DHR). If the conviction(s) are not federally mandated, recording

linkage is optional, but recommended. The linkage associates a withdrawal to the underlying conviction(s) that resulted

in the withdrawal. The linkage is included in response to a CDLIS history request or a Change State of Record (CSOR).

The SOW may include previously unreported underlying convictions in the Report Out-of-State Withdrawal transaction

rather than having to report them first using the Report Out-of-State Conviction transaction. Ref2

For CDLIS to work properly, all convictions and withdrawals in the U.S. have to be sent to the current SOR so that

proper penalties are applied and history accumulated. This is equally true for Licencia Federal de Conductor

(LFC) drivers.

The Federal Conviction Withdrawal Database ( FCWD) is the SOR for all LFC drivers. An LFC driver has a record

established in the LIFIS database when he/she obtains an LFC license.

The FCWD, as the SOR for all LFC drivers, contains all U.S. convictions and U.S. withdrawals on LFC drivers (their

DHR), as well as the driverřs commercial status based on that history**. This information allows border and

enforcement personnel to determine whether or not a particular LFC driver should be allowed to drive in the U.S.

If States establish a pointer on CDLIS for an LFC driver, the associated conviction(s) and/or withdrawal(s) do not

become part of the LFC driver's DHR, potentially allowing a driver who should be barred from driving on U.S.





highways to enter the U.S. undetected.

* A jurisdiction may report a non-ACD withdrawal (a withdrawal that does not have a current Withdrawal Reason

ACD Code) of a CDL holder, but does not submit a non-ACD withdrawal via CDLIS unless it is using the ŘW00ř

withdrawal code.

** The status of an LFC driver is determined by looking at both the LFC driver's Mexican status in the LIFIS

database and the status as calculated by FMCSA's contractor based on convictions and withdrawals in the FCWD. An

MX history includes the same status received in a status message, plus all convictions and withdrawals

from FMCSA's FCWD. As an example, a driver with a status of "LIC" in the LIFIS database and a status of "NOT" in

the FCWD will reflect a CDLIS status of "NOT" and a restriction saying the license is "not valid in the U.S.".

Participants

State of Withdrawal (SOW)

o U.S. jurisdiction

CDLIS Central Site


o U.S. jurisdiction



Pre-Requisites

To help ensure the success of the transaction, an SOW submits a Search InquiryRef3


to the CDLIS Central Site to verify that the correct MPR is identified

Standard Processing

The SOW sends a Report Out-of-State Withdrawal message to the CDLIS Central Site.

Upon receipt of the Report Out-of-State Withdrawal message, the CDLIS Central Site:

o Validates the driver identification and conviction information in the message


o Forwards the withdrawal to the SOR

Upon receipt of the withdrawal information, the SOR performs the following within 96 hours*:

o Validates the driver

o Validates the withdrawal conviction data using current rules

o Verifies the withdrawal is not a duplicate

o Retrieves the DHR

o Adds the withdrawal to the DHR

o Posts the ACD conviction(s) to the driver's record unless the conviction(s) have already been reported,

either via the Report Out-of-State Conviction transactionRef2

or via a paper reportRef1

o Records any required linkage between the withdrawal and its underlying ACD conviction(s)




o Sends a confirmation to the SOW that the transaction is complete

* Federal regulations allow 10 days from receipt to post withdrawal information. However, if the Central Site does

not receive the confirmation message within 96 hours, AAMVA notifies the SOR.

Inputs

The Report Out-of-State Withdrawal includes the driverřs identification data (name, date of birth, driver's license

number and jurisdiction code combination) consistent with the information returned from the inquiries performed prior





to submission of the update (not the information on the citation(s), if different). It also contains driver and withdrawal

information and information on all underlying ACD convictions that were the cause of the withdrawal. The message

may optionally contain the driverřs Social Security Number, the date the privilege driver was reinstated (if available)*,

and details of the ACD code.



There is no "update withdrawal" transaction. If a jurisdiction desires to update a withdrawal to reflect a reinstatement

date, the withdrawal must be negated and then reported again with the reinstatement date included.



o The Central Site sends driver identification and withdrawal information received from the SOW to the

SOR


o The SOR sends a confirmation that the withdrawal has been posted to the DHR

Central Site to the SOW:

o A confirmation message that the posting of the conviction is complete


Central Site

o If the Report Out-of-State Withdrawal message does not pass the edit validations performed by the

CDLIS Central Site, the Central Site returns an error to the SOW. No further processing is performed.

o If the SOR returns an error after receiving the conviction information, the Central Site forwards the error

to the SOW

SOR

o If the SOR cannot locate the driver upon receipt of withdrawal information or there are problems with the

withdrawal or conviction data itself, the SOR returns an error to the CDLIS Central Site.

Post-Requisites

SOW

o To be able to perform negation and to answer any questions about the original conviction, the SOW

maintains the original record on any withdrawal and underlying convictions according to CDLIS data

retention rules.

SOR

o Correctly interpret the information on the CDLIS DHR to determine whether any withdrawal action is

required, and, if so, what federal minimum applies

o Take any necessary driver control actions based on the convictions received as if the offense had occurred

within its own jurisdiction, according to its own laws.

o For each withdrawal with an effective data on or after November 1, 2005 and where a pointer on CDLIS

is required at the time of the withdrawal, the SOR is responsible for:

Maintaining each required linkage between each withdrawal taken and its underlying convictions

(i.e., withdrawals taken by either the SOR or the SOW)

Transmitting each required withdrawal-convictions linkage when responding to driver history

requests





References

Reference

#


Ref1 CDLIS State

Procedures Manual


Ref2 CDLIS System

Specifications


Ref3 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref4 CDLIS System

Specifications


Ref5 CDLIS System

Specifications


Federal Regulations


49 CFR 384.208 Notification of disqualification

49 CFR 383, 384, U.S. Federal Motor Carrier

Safety Administration (FMCSA) Policy

Memorandum CDL-04-001*

Explain details of the federally mandated requirements for reporting

withdrawals and underlying convictions; A copy of FMCSAřs Policy

Memorandum is available from FMCSA

* Jurisdictions consult their own laws and regulations for additional guidance on reporting withdrawals and

underlying convictions and taking driver-control actions within the scope of their CDL programs. They also consult the

relevant interstate compacts/agreements, including the following:




Copies of these documents are available from the AAMVA Programs Division. These sources also provide guidance for

reporting withdrawals based on convictions for offenses committed by non-CDL holders in non-CMVs, which is

beyond the scope of the CDL program.


memoranda, the federal regulations and FMCSA policy memoranda take precedence.







HW Report Out-of-State Withdrawal

HT Forward Report Out-of-State Withdrawal 1

CW Confirm Out-of-State Withdrawal 1

CT Confirm Receipt of CW 1





CD16.1 Report Withdrawal (State of Withdrawal (SOW))


The Report Out-of-State Withdrawal Transaction enables the SOW to report an out-of-state withdrawal to the SOR. In

the transaction, the SOW must also report all underlying ACD convictions (up to a maximum of 14) that resulted in the

withdrawal if the withdrawal effective date is after October 31, 2005. The SOW may report the underlying ACD

convictions in the Report Out-of-State Withdrawal Transaction as an alternative to reporting the convictions in the

Report Out-of-State Conviction Transaction (see "CD11 REPORT OUT-OF-STATE CONVICTION"). However,

convictions must still be reported within the time frames listed in federal regulations. To determine which withdrawals

and convictions must be reported with this transaction, refer to the following documents:







In all cases involving the DLC, NRVC and DLA, if the compacts conflict with federal regulations or FMCSA

policy memoranda, the federal regulations and FMCSA policy memoranda must take precedence.

Prior to initiating a Report Out-of-State Withdrawal transaction for a driver in CDLIS, the SOW must initiate a

verification inquiry or a search inquiry to the CDLIS Central Site to ensure positive identification of the driver. The

verification inquiry may use the Verification Inquiry (IN) or Verification Inquiry Preceding Report Out-of-State

Conviction (ID) message (see "CD02 VERIFICATION INQUIRY" for formatting instructions) or the Search Inquiry

(IM) message, which uses a less restrictive search algorithm (see "CD01 SEARCH INQUIRY" for formatting

instructions).

Upon receipt of the inquiry responses from the SOR, the SOW is responsible for confirming that the driver represented



Social Security Number) matches. The SOW may also consider secondary driver identifying data, such as Sex, Height,


Because Mexican driver records are not maintained on the CDLIS Central Site, the SOW must not initiate a verification

inquiry to the CDLIS Central Site before initiating a Report Out-of-State Withdrawal transaction on a Mexican driver.

The SOW must just send the withdrawal message with the Driver License Current Jurisdiction Code (DDLJU1) set to

'MX'. The CDLIS Central Site will forward the withdrawal message to 'MX' without checking for a matching MPR.

Currently, withdrawals of Canadian drivers cannot be submitted electronically to Canada via CDLIS. The SOW must

send a paper copy of the withdrawal to the Canadian jurisdiction when reporting is required by federal regulations. It is

recommended that the SOW also maintain the driver and withdrawal information on its own database and add a pointer

record for the driver to the Central Site file (see "CD07 ADD NEW DRIVER" for details). Withdrawals of U.S. drivers

cannot be submitted electronically via CDLIS by Mexico or Canada.

If the SOW has not implemented the Report Out-of-State Withdrawal Transaction, and the SOW is required by

jurisdiction or federal regulations to report the withdrawal, the SOW must arrange with the SOR to send the withdrawal

report via mail. The mailed report must conform to the requirements of the CDLIS transaction. For example, to

document that the withdrawal is sent within 10 days, the CDLIS Central Site logs the "date the withdrawal is

transmitted" in the CDLIS transaction, so in a mailed report, the SOW must include the "date the withdrawal is sent" as

one of the information fields in the report and must maintain the date with it original record of the withdrawal. See the

CDLIS State Procedures Manual for more details about the procedure for mailing withdrawals.

In accordance with 49 CFR §384.208, the SOW must report a withdrawal within 10 days of the withdrawal effective

date. See ŖCD11 REPORT OUT-OF-STATE CONVICTIONŗ for the time limits for reporting new underlying

convictions. Jurisdictions must not send withdrawals that are not final, according to jurisdiction law, to avoid having to





reverse them, and jurisdictions must not send FTAs, FTPs, and FTCs until any grace period has ended, according to

jurisdiction law.

Besides reporting the withdrawal and all underlying convictions to the SOR, the SOW must also maintain the original

records of the withdrawal, linkages, and conviction(s) for as long as the withdrawal is retained on the CDLIS driver

history by the SOR, to be able to perform negation and to answer any questions about the original withdrawal. The

SOW must maintain the identifying driver information and the identifying withdrawal values. The SOW must maintain

corresponding conviction information with the original record of each underlying conviction (including the SOC

jurisdiction code, the State Native Code, and the SOC court report ID). When the withdrawal is purged from CDLIS

driver history, the original record of the withdrawal can be destroyed. See the ACD for data retention requirements for

ACD withdrawals and convictions.

In accordance with FMCSA policy Memorandum CDL-04-001, if a jurisdiction issues a disqualification for a failure to

appear (FTA) or a failure to pay (FTP) or failure to comply (FTC) for an out-of-state CDL driver for an underlying

ACD citation or offense, the jurisdiction issuing the FTA or FTP or FTC must report the disqualification and the

conviction for a failure to the SOR. When the SOR receives the report, the SOR must enter the information in the

driver history. The SOR must act on the report as if the failure occurred within the SOR. See "CD11.1.2

Transmission" for details about reporting the FTA or FTP or FTC as a conviction. If an FTA/FTP/FTC withdrawal is

the result of a non-ACD citation or offense, the SOW isn't required to send the withdrawal, but it may send the

withdrawal as a W00 withdrawal.

CD16.1.2 Transmission of Report Out-of-State Withdrawal (HW) Message

The Report Out-of-State Withdrawal (HW) message must contain:


System Release Code (GMSSRL) set to 'F' for CDLIS Release 4.0.0 (see Note)


Driver License Jurisdiction Number (DDLJDL) set to the following two data elements









Jurisdiction Code - Withdrawing (DWDJUR) set to the appropriate code for the jurisdiction that posted the

withdrawal

Driver License Withdrawal Effective Date (DWDDWD) set to the appropriate date

Driver License Withdrawal Type (DWDWTP) set to the appropriate code

Driver License Withdrawal Basis (DWDWBS) set to the appropriate code

Driver License Withdrawal Due Process Status (DWDWPS) set to the appropriate code

Driver License ACD Withdrawal Reason Code (DWDWRS) set to the appropriate code

Driver License Withdrawal Eligibility Date (DWDWDE) set to the appropriate date

Driver License Withdrawal Extent ID - DLC (DWDWEX) set to the appropriate code

Driver License Withdrawal Jurisdiction Report ID (DWDWLO) set to the appropriate reference number

Driver License Withdrawal Reason Reference (DWDWRR) set to the appropriate native state code


The Report Out-of-State Withdrawal (HW) message may optionally include:

Driver License Withdrawal Reinstatement Date (DWDWDR) set to the appropriate date







values.

Note: The System Release Code (GMSSRL) is required to be set to 'F' to indicate the SOW has implemented MCSIA

changes and the ACD (Release 2.1) in the new Report Out-of-State Withdrawal transaction. If the System Release

Code (GMSSRL) is not set to 'F', the CDLIS Central Site will return the Report Out-of-State Withdrawal (HW) message

in error.

The only way to update a withdrawal's reinstatement date is to negate the original withdrawal and send a new

withdrawal message with the updated reinstatement. An SOW may, but is not required to, update the reinstatement date

for an out-of-state withdrawal. The driver may also bring to the SOR proof of the reinstatement from the SOW for the

SOR to update the driver history. The OOS withdrawal is only effective within the SOW and the SOW would know

about the reinstatement.

The Report Out-of-State Withdrawal (HW) message must contain information on underlying ACD conviction(s), if any,

up to a maximum of 14 (see the AAMVA Code Dictionary (ACD) Manual for rules regarding which withdrawal ACD

codes require underlying convictions). For each underlying ACD conviction, the Report Out-of-State Withdrawal

(HW) message must contain the following:

Jurisdiction Code - Convicting, OOSW (DCVJU3) set to the jurisdiction code of the SOW

Citation Date (OOSW) (DCIDC3) set to the date on which the original citation was issued

Conviction Date (OOSW) (DCVDC3) set to the date on which the conviction was finally adjudicated

Conviction Court Type (OOSW) (DCVCR3) set to the appropriate code for the type of court that finalized the

conviction

Conviction Commercial Vehicle Indicator (OOSW) (DCVCO4)




unknown





Conviction HAZMAT Indicator (OOSW) (DCVHA3)



set to '2' if the driver was not carrying hazardous materials when the violation occurred, or if

unknown





Conviction Jurisdiction Court Report ID, OOSW (DCVCL3) set to the unique identifier for the conviction report

from the SOC court or State Authority

Conviction Jurisdiction Offense Code (OOSW) (DCVCO5) set to the native SOC code for the type of offense

Conviction Offense ACD Code (OOSW) (DCVCC3) set to the AAMVA Code Dictionary code describing the

offense

For each underlying conviction, the Report Out-of-State Withdrawal (HW) message may optionally contain the

following:





Conviction Offense Detail - ACD (OOSW) (DCVCD4) set if the ACD code requires or allows additional details

about the offense (see the AAMVA Code Dictionary (ACD) Manual for details)

CD16.2 Validate Withdrawal Information (CDLIS Central Site)

CD16.2.1 Reception of Report Out-of-State Withdrawal (HW) Message

Upon receipt of a Report Out-of-State Withdrawal (HW) message from a jurisdiction, the CDLIS Central Site initiates



The CDLIS Central Site performs the following validation checks on the Report Out-of-State Withdrawal (HW)

message. If errors are detected, the Central Site stops processing and returns the original message to the sender with

error fields set. Up to five validation failures may be reported on a single error message. The Central Site must report as

many problems as it can to minimize the number of resends.

Validate the password and determine the implementation status of the State of Withdrawal (SOW) by performing


Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Report Out-of-State

Withdrawal (HW) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Report Out-

of-State Withdrawal (HW) message

Authorization Function (BJUAFN) set to ŖHWŗ





For all States of Withdrawal (SOW), regardless of the version implemented:


(DDLJDL).



(DDLJDL).




Jurisdiction Code - Withdrawing (DWDJUR) must be present.

Error Text: 'STATE-OF-WITHDRAWAL CODE REQUIRED'

Driver License Withdrawal Effective Date (DWDDWD) must be present.

Error Text: 'WITHDRAWAL EFFECTIVE DATE REQUIRED'

Driver License Withdrawal Type (DWDWTP) must be present.





Error Text: 'WITHDRAWAL TYPE DETAIL REQUIRED'

Driver License Withdrawal Basis (DWDWBS) must be present.

Error Text: 'WITHDRAWAL BASIS REQUIRED'

Driver License Withdrawal Due Process Status (DWDWPS) must be present.

Error Text: 'WITHDRAWAL DUE PROCESS STATUS REQUIRED'

Driver License ACD Withdrawal Reason Code (DWDWRS) must be present.

Error Text: 'ACD WITHDRAWAL REASON CODE REQUIRED'

Driver License Withdrawal Eligibility Date (DWDWDE) must be present.

Error Text: 'WITHDRAWAL ELIGIBILITY DATE REQUIRED'

Driver License Withdrawal Extent ID - DLC (DWDWEX) must be present.

Error Text: 'WITHDRAWAL EXTENT ID REQUIRED'

Driver License Withdrawal Jurisdiction Report ID (DWDWLO) must be present.

Error Text: 'WITHDRAWAL JURISDICTION REPORT ID REQUIRED'

Driver License Withdrawal Reason Reference (DWDWRR) must be present.

Error Text: 'WITHDRAWAL REASON REFERENCE REQUIRED'

System Release Code (GMSSRL) must be present.

Error Text: 'SYSTEM RELEASE CODE REQUIRED'

For those States of Withdrawal (SOW) at version 5.1 or greater:



For those States of Withdrawal (SOW) at a version older than 5.1:



For each underlying ACD conviction in the Report Out-of-State Withdrawal (HW) message:


Jurisdiction Code Ŕ Convicting (OOSW) (DCVJU3) must be present.


Citation Date (OOSW) (DCIDC3) must be present.


Conviction Date (OOSW) (DCVDC3) must be present.






Conviction Court Type (OOSW) (DCVCR3) must be present.

Error Text: 'CONVICTION COURT TYPE REQUIRED'

Conviction Commercial Vehicle Indicator (OOSW) (DCVCO4) must be present.

Error Text: 'COMMERCIAL VEHICLE INDICATOR REQUIRED'

Conviction HAZMAT Indicator (OOSW) (DCVHA3) must be present.

Error Text: 'HAZMAT INDICATOR REQUIRED'

Conviction Jurisdiction Court Report ID (OOSW) (DCVCL3) must be present.


Conviction Jurisdiction Offense Code (OOSW) (DCVCO5) must be present.


Conviction Offense ACD Code (OOSW) (DCVCC3) must be present.






DICTIONARYŗ.



DICTIONARYŗ.



Must be numeric





Jurisdiction Code - Withdrawing (DWDJUR) must contain one of the valid values in the "United States" list

under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.

Error Text: 'INVALID STATE-OF-WITHDRAWAL CODE'

Driver License Withdrawal Effective Date (DWDDWD) must be a valid date and formatted as specified in

ŖAppendix D - Data Dictionaryŗ.

Error Text: 'INVALID WITHDRAWAL EFFECTIVE DATE'

Driver License Withdrawal Type (DWDWTP) must contain one of the valid values listed in ŖAPPENDIX D -





DATA DICTIONARYŗ.

Error Text: 'INVALID WITHDRAWAL TYPE'

Driver License Withdrawal Basis (DWDWBS) must contain one of the valid values listed in ŖAPPENDIX D -

DATA DICTIONARYŗ.

Error Text: 'INVALID WITHDRAWAL BASIS'

Driver License Withdrawal Due Process Status (DWDWPS) must contain one of the valid values listed in


Error Text: 'INVALID WITHDRAWAL PROCESS STATUS'

Driver License ACD Withdrawal Reason Code (DWDWRS) must be valid as specified in the current AAMVA

Code Dictionary (ACD) Manual.

Error Text: 'INVALID WITHDRAWAL ACD REASON CODE'

Driver License Withdrawal Eligibility Date (DWDWDE) must be a valid date and formatted as specified in


Error Text: 'INVALID ELIGIBILITY DATE'

Driver License Withdrawal Extent ID - DLC (DWDWEX) must contain one of the valid values listed in


Error Text: 'INVALID WITHDRAWAL EXTENT ID'

Driver License Withdrawal Reinstatement Date (DWDWDR), if present, must be a valid date and formatted as

specified in ŖAPPENDIX D - DATA DICTIONARYŗ.

Error Text: 'INVALID REINSTATEMENT DATE'

System Release Code (GMSSRL) must be set to 'F'.








Driver Name (DDVNAM) must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ AAMVA PERSON

NAME FORMATTING RULESŗ




Jurisdiction Code Ŕ Convicting (OOSW) (DCVJU3) must contain one of the valid values in the "United

States" list under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.






Citation Date (OOSW) (DCIDC3) must be a valid date and formatted as specified in ŖAPPENDIX D -

DATA DICTIONARYŗ.

Error Text: 'INVALID CITATION DATE'

Conviction Date (OOSW) (DCVDC3) must be a valid date and formatted as specified in ŖAPPENDIX D

- DATA DICTIONARYŗ.

Error Text: 'INVALID CONVICTION DATE'

Conviction Court Type (OOSW) (DCVCR3) must contain one of the valid values listed in ŖAPPENDIX

D - DATA DICTIONARYŗ.

Error Text: 'INVALID CONVICTION COURT TYPE'

Conviction Commercial Vehicle Indicator (OOSW) (DCVCO4) must contain one of the valid values

listed in ŖAPPENDIX D - DATA DICTIONARYŗ.

Error Text: 'INVALID COMMERCIAL VEHICLE INDICATOR'

Conviction HAZMAT Indicator (OOSW) (DCVHA3) must contain one of the valid values listed in


Error Text: 'INVALID HAZMAT INDICATOR'

Conviction Offense ACD Code (OOSW) (DCVCC3) must be valid as specified in the current ACD and

must not be one of the codes reserved for withdrawals: W00, W01, W30, W31, W40, W41, W45, W50,

W51, W52, W60, W61, W72, W80 and W81.

Error Text: 'INVALID ACD CONVICTION CODE'




Withdrawing (DWDJUR).

Error Text: 'SOW AND TRANSACTION ORIGINATOR DO NOT MATCH'

If the Driver License Withdrawal Eligibility Date (DWDWDE) is a date, it must be equal to or later than the

Driver License Withdrawal Effective Date (DWDDWD).

Error Text: 'ELIG DATE MUST BE EQUAL TO OR LATER THAN EFFEC

DATE'

The Driver License Withdrawal Reinstatement Date (DWDWDR), if present, must not be a future date and must

be equal to or earlier than the Message Date (GMSDAT).

Error Text: 'REINSTATE DATE MUST NOT BE LATER THAN MESSAGE DATE'



The Citation Date (OOSW) (DCIDC3) must be equal to or earlier than the Conviction Date (OOSW)

(DCVDC3).

Error Text: 'CITATION DATE MUST NOT BE LATER THAN CONV DATE'





The Conviction Date (OOSW) (DCVDC3) must be equal to or earlier than the Message Date (GMSDAT).

Error Text: 'CONV DATE MUST NOT BE LATER THAN MESSAGE DATE'

Driver License Withdrawal Effective Date (DWDDWD) must be equal to or later than the Conviction Date

(OOSW) (DCVDC3).

Error Text: 'EFFEC DATE MUST BE EQUAL TO OR LATER THAN CONV

DATE'

If the Citation Date (OOSW) (DCIDC3) is on or after January 1, 2008, the Conviction Commercial Vehicle

Indicator (OOSW) (DCVCO4) must be '1' or Ř2ř.

Error Text: ‘CONV CMV IND MUST = 1 OR 2, FOR CITATN DATE >

20071231’

If the Citation Date (OOSW) (DCIDC3) is on or after January 1, 2008, the Conviction HAZMAT Indicator

(OOSW) (DCVHA3) must be '1' or Ř2ř.

Error Text: ‘CONV HAZ IND MUST = 1 OR 2, FOR CITATN DATE >

20071231’

If the value of the Conviction HAZMAT Indicator (DCVHAZ) is '1', then the Conviction Commercial Vehicle

Indicator (DCVCOM) must be '1'.

Error Text: 'CONV CMV IND MUST = 1, IF CONV HAZMAT IND = 1’

If the Conviction Offense ACD Code (OOSW) (DCVCC3) value is one of the following, the Conviction

Commercial Vehicle Indicator (OOSW) (DCVCO4) must be '1':

B19 - Driving while out of service order is in effect and transporting 16 or more passengers, including the

driver and/or transporting hazardous materials that require a placard.

B27 - Driving while an out of service order is in effect (for violations not covered by B19).

B56 - Driving a CMV without obtaining a CDL

E03 - Operating without HAZMAT safety equipment as required by law

E04 - Operating without HAZMAT placards/markings as required by law

E06 - Operating without school bus equipment as required by law

E33 - Defective HAZMAT safety devices

E36 - Defective school bus equipment

E53 - Failure to use HAZMAT safety devices as required

E56 - Failure to use school bus safety equipment as required

U09 - Negligent homicide while operating a CMV

U10 - Causing a fatality through the negligent operation of a CMV

Error Text: 'CONV CMV INDICATOR MUST = 1 FOR ACD CONV CODE'

If the Conviction Offense ACD Code (OOSW) (DCVCC3) value is one of the following, the Conviction

HAZMAT Indicator (OOSW) (DCVHA3) must be "1":

E03 - Operating without HAZMAT safety equipment as required by law

E04 - Operating without HAZMAT placards/markings as required by law

E33 - Defective HAZMAT safety devices





E53 - Failure to use HAZMAT safety devices as required

Error Text: 'CONV HAZMAT INDICATOR MUST = 1 FOR ACD CONV CODE'

If the Citation Date (OOSW) (DCIDC3) is on or after January 1, 2008 and the Conviction Offense ACD Code

(OOSW) (DCVCC3) value is one of the following, the Conviction HAZMAT Indicator(OOSW) (DCVHA3)

must be "2":

E06 - Operating without school bus equipment as required by law

E36 - Defective school bus equipment

E56 - Failure to use school bus safety equipment as required

Error Text: 'CONV HAZMAT INDICATOR MUST = 2 FOR ACD CONV CODE'

Depending on the value of the Conviction Offense ACD Code (OOSW) (DCVCC3) in the following checks, the

Conviction Offense Detail - ACD (OOSW) (DCVCD4) must be spaces, may be present, or must be present:

1) If the given Conviction Offense ACD Code (OOSW) (DCVCC3) is not in the group ('A11', 'D45',

'D53', and 'D56') and is not in the range 'S01'-'S92', the Conviction Offense Detail - ACD (OOSW)

(DCVCD4) must have all spaces.

Error Text: 'ACD CONV CODE VALUE REQUIRES BLANK CONV OFF DETAIL'

2) If the given Conviction Offense ACD Code (OOSW) (DCVCC3) is 'A11', the Conviction Offense

Detail - ACD (OOSW) (DCVCD4) must have numeric values in the range '01'-'99' in the first 2 positions

and all spaces or all zeroes in the remaining three positions.

Error Text: 'INVALID CONV OFF DETAIL FOR ACD CONV CODE = A11'

3) If the given Conviction Offense ACD Code (OOSW) (DCVCC3) is 'D45', 'D53', or 'D56', the first

three positions of the Conviction Offense Detail -ACD (OOSW) (DCVCD4) must have a valid current

ACD Conviction Code that must not be 'D45', 'D53', or 'D56'; and the remaining two positions must have

blanks.

Error Text: 'INVALID CONV OFF DETAIL FOR GIVEN ACD CONV CODE'

4) If the given Conviction Offense ACD Code (OOSW) (DCVCC3) is in the range 'S01'-'S91', the

Conviction Offense Detail -ACD (OOSW) (DCVCD4) must have one of the following two formats

(Note: The format of "zeroes for null values" does not conform to the AAMVA standard of "spaces for

null values" and is rejected in error):

(1) all spaces (for null values) or

(2) numeric values in the range '05'-'90' in the first 2 positions and all spaces or all zeroes in the

last three positions.

Error Text: 'INVALID CONV OFF DETAIL FOR ACD CONV CODES S01-S91'

5) If the given Conviction Offense ACD Code (OOSW) (DCVCC3) is 'S92', the Conviction Offense

Detail - ACD (OOSW) (DCVCD4) must have a numeric value in the range '05'-'90' in the first two

positions and a numeric value in the last three positions that is less than '300' and greater than the numeric

value in the first two positions.

Error Text: 'INVALID CONV OFF DETAIL FOR ACD CONV CODE = S92'

If the Driver License ACD Withdrawal Reason Code (DWDWRS) is ŘW72ř or ŘW00ř there can be no underlying

conviction. If there is an underlying conviction, issue an error.





Error Text: 'NO UNDERLYING CONVICTION ALLOWED FOR WITHDRAWAL

ACD'

Note: In a future release of CDLIS, the CDLIS Central Site will validate that the Withdrawal Reason ACD Code is

correct for the Conviction Offense ACD Codes of the underlying convictions. See the AAMVA Code Dictionary

(ACD) Manual and the CDLIS State Procedures Manual for the best practices when setting the Withdrawal Reason

ACD Code.




Jurisdiction Number (DDLJDL) on the Report Out-of-State Withdrawal (HW) message are not ŘMXř. If

positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Report Out-of-State Withdrawal

(HW) message are ŘMXř, proceed directly to the transmission section.



(DDLJDL) from the Report Out-of-State Withdrawal (HW) message; and


(DDLJDL) from the Report Out-of-State Withdrawal (HW) message




Access the AKA ST-DLN (CD24) by the following fields from the Report Out-of-State Withdrawal (HW)

message:


Number (DDLJDL)


Number (DDLJDL)








If Driver SSN - CDLIS (DDVSS6) is present, the name information on the Report Out-of-State Withdrawal

(HW) message must correspond with the name information on the existing Master Pointer (CD20). The

comparison is performed as described in "7.2 Name Comparison"

If Driver SSN - CDLIS (DDVSS6) is not present, the last name on the Report Out-of-State Withdrawal (HW)

message must match the last name on the existing Master Pointer (CD20).

If the State of Withdrawal (SOW) is at version 5.1 or greater


If the State of Withdrawal (SOW) is at a version older than 5.1






Transitional Note:

When matching last names the CDLIS Central Site shall take into account that the same name may have

slight differences depending on whether it was originally captured in the format described in

ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ or in the format described in

'APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)'.

The following data on the Report Out-of-State Withdrawal (HW) message must match the corresponding data on the









If present, the last 5 positions of Driver SSN - CDLIS (DDVSS6) must match the CD20 Person SSN Last

5 Digits (BPESSD)




(DDVSSN)





Report Out-of-State Conviction (HW) message if the values areŘ MXř; otherwise set to the Jurisdiction Code Ŕ


Authorization Function (BJUAFN) set to ŖHTŗ



CD16.2.3.1 Transmission of Forward Report of Out-of-State Withdrawal (HT) Message

If the Report Out-of-State Withdrawal (HW) message is valid, the CDLIS Central Site sends a Forward Report of Out-

of-State Withdrawal (HT) message to the State of Record (SOR).

The Forward Report of Out-of-State Withdrawal (HT) message must include:


The Forward Report of Out-of-State Withdrawal (HT) message must include the following information as provided on

the Report Out-of-State Withdrawal (HW) message:








(DDLJDL) on the Report Out-of-State Withdrawal (HW) message if the values are ŘMXř; otherwise set to




Jurisdiction Code - Withdrawing (DWDJUR)

Driver License Withdrawal Effective Date (DWDDWD)

Driver License Withdrawal Type (DWDWTP)

Driver License Withdrawal Basis (DWDWBS)

Driver License Withdrawal Due Process Status (DWDWPS)

Driver License ACD Withdrawal Reason Code (DWDWRS)

Driver License Withdrawal Eligibility Date (DWDWDE)

Driver License Withdrawal Extent ID - DLC (DWDWEX)

Driver License Withdrawal Jurisdiction Report ID (DWDWLO)

Driver License Withdrawal Reason Reference (DWDWRR)

Driver License Withdrawal Reinstatement Date (DWDWDR)

The Forward Report of Out-of-State Withdrawal (HT) message must include the following conviction information from

the Report Out-of-State Withdrawal (HW) message for each underlying conviction (up to a maximum of 14):


Jurisdiction Code - Convicting (OOSW) (DCVJU3)

Citation Date (OOSW) (DCIDC3)

Conviction Date (OOSW) (DCVDC3)

Conviction Court Type (OOSW) (DCVCR3)



Conviction Jurisdiction Court Report ID (OOSW) (DCVCL3)

Conviction Jurisdiction Offense Code (OOSW) (DCVCO5)

Conviction Offense ACD Code (OOSW) (DCVCC3)

Conviction Offense Detail - ACD (OOSW) (DCVCD4), if present

The Forward Report of Out-of-State Withdrawal (HT) message must include the following from the Master Pointer

(CD20) record. Note: If positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Report Out-of-

State Withdrawal (HW) message are ŘMXř, use the corresponding information from the Report Out-of-State

Withdrawal (HW) message:







(BPESSD)












in positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Report Out-of-State Withdrawal (HW)


CDLIS Central Site transmits the withdrawal to the SOR on the CD20 record. Old SOR(s) will not be notified.

See "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE" for remaining NCB (00/0) and MEC (02/2) block

values.

CD16.2.3.2 Transmission of the Report Out-of-State Withdrawal (HW) Message with Errors

If the CDLIS Central Site encounters errors on the original Report Out-of-State Withdrawal (HW) message that


occurrences).



(02/2) blocks.

CD16.3 Process Withdrawal (State of Record (SOR))


Upon receipt of the Forward Out-of-State Withdrawal (HT) message, the SOR locates the driver on its database and

validates the withdrawal and any underlying ACD convictions for errors. If the SOR finds no errors, it posts the

information to the driver's history record and evaluates whatever driving privilege withdrawal action may be necessary.

Note: If the SOR is unable to receive and process an out-of-state withdrawal and its linkage electronically via CDLIS

and the SOR is required by jurisdiction law or federal regulations to send any of the information in the Forward Out-of-

State Withdrawal (HT) message, the SOR must arrange with the SOW to receive, validate, and confirm the required

information by mail. When it receives the withdrawal, the SOR either (1) posts the withdrawal manually or (2) stores

the withdrawal and posts the withdrawal as soon as it has the capability. See the CDLIS State Procedures Manual for

procedures to negate a withdrawal by mail.

CD16.3.2 Reception of Forward Out-of-State Withdrawal (HT) Message

The Forward Out-of-State Withdrawal (HT) message contains:




Driver License Jurisdiction Number (DDLJDL) composed of the following two elements:




















The Forward Out-of-State Withdrawal (HT) message may optionally contain:


The Forward Out-of-State Withdrawal (HT) message must contain information on any underlying ACD conviction(s).

For each underlying ACD conviction, the Forward Out-of-State Withdrawal (HT) message contains the following:

Jurisdiction Code - Convicting OOSW (DCVJU3)

Citation Date (OOSW) (DCIDC3)

Conviction Date (OOSW) (DCVDC3)

Conviction Court Type (OOSW) (DCVCR3)



Conviction Jurisdiction Court Report ID, OOSW (DCVCL3)

Conviction Jurisdiction Offense Code (OOSW) (DCVCO5)

Conviction Offense ACD Code (OOSW) (DCVCC3)

For each underlying ACD conviction in the Forward Out-of-State Withdrawal (HT) message, the Forward Out-of-State

Withdrawal (HT) message may optionally contain the following:

Conviction Offense Detail - ACD (OOSW) (DCVCD4)

CD16.3.3 Validation

The SOR performs the following validation checks on the Forward Out-of-State Withdrawal (HT) message. If the SOR

detects any errors, it sets the appropriate error fields (see Ŗ4 CDLIS ERROR PROCESSINGŗ for details), returns the

original message to its sender for correction, and stops processing the transaction.




CDLIS (DDVSS6) are not permitted. If the SOR does not find a match, issue an error.


CD16.3.3.2 Duplicate Withdrawal Error

When entering an in-state or out-of-state withdrawal, the SOR must check that the withdrawal will not duplicate a

withdrawal already on the CDLIS driver history. Duplication is defined by a match on the following data elements

which combined uniquely identify a specific withdrawal:







If a duplicate exists, the SOR rejects the new withdrawal report and issues an error. The SOR does not post the





withdrawal and takes no additional driver control actions.

Error Text: 'DUPLICATE WITHDRAWAL'

Note: The jurisdiction must also have a procedure in place to check for duplicate withdrawals when entering paper

withdrawals. If either an electronic or paper withdrawal is rejected as a duplicate, the SOR should contact the SOW and

manually determine why the duplicate was sent, especially if the duplicate and the existing withdrawal contain differing

information. If the withdrawal matches an existing withdrawal for 4 or 5 of the identifying data elements, it is

recommended that the SOR check with the SOW to ensure the withdrawal is indeed unique.

CD16.3.4 Updates

The SOR does not post any withdrawal or any new underlying ACD conviction to the driver history if the SOR:

Detects any errors on the original Forward Out-of-State Withdrawal (HT) message


Determines that the withdrawal has already been posted

If no errors are found, the SOR posts the withdrawal information to the CDLIS driver history. For each withdrawal

posted to the CDLIS driver history, the SOR also records in its internal database the "date the withdrawal was received

by the MVA" and the "date the withdrawal was posted to the CDLIS driver history". The SOR retains this information

for as long as it remains the SOR, but it does not transmit it in the CDLIS history requests. Note: For withdrawals sent

via CDLIS, these two dates will be within 1 day of each other in nearly all cases. For paper in-state and out-of-state

withdrawals sent via mail, the "date posted to the CDLIS driver history" could be much later than the "date the

withdrawal received by the MVA".

If the withdrawal has any underlying ACD convictions, the SOR must check whether each underlying conviction has

already been posted, because an underlying conviction may have been reported in a previous Report Out-of-State

Withdrawal transaction or a previous Report Out-of-State Conviction transaction. If an underlying conviction is not

already in the DHR, the SOR must post the conviction to the DHR along with a link between the withdrawal and the

underlying conviction. If an underlying conviction is already in the DHR, the SOR does not post the conviction to the

DHR, but it does post a link between the withdrawal and the underlying conviction.

For each underlying ACD conviction that was not previously reported, the SOR posts to the driver history record the

information in the Forward Out-of-State Withdrawal (HT) message and the following:

Citation CDL Holder Indicator (DCICHI), set to the value ('1' or '2') indicating whether or not the driver held a

CDL at the time of the violation (see "CD04 STATE-TO-STATE HISTORY REQUEST", "CD08 CHANGE

STATE OF RECORD", "APPENDIX D.1 - DATA ELEMENTS" and the CDLIS State Procedures Manual for

details about the Citation CDL Holder Indicator (DCICHI))

For each underlying ACD conviction that was not previously reported, the SOR also records in its internal database the

"date the new ACD conviction was received by the MVA" and the "date the ACD conviction was posted to the CDLIS

driver history". See "CD11.3 Process Conviction (State of Record (SOR))" for details about these two internal data

elements that are not transmitted in subsequent history requests.

When the SOR posts the withdrawal, and any new, underlying ACD convictions, the SOR evaluates whatever driving

privilege withdrawal action may be required in accordance with federal regulations and policies (see 49 CFR 383 and

49 CFR 384 and Policy Memorandum CDL-04-001) and its own regulations and procedures that govern the driver

improvement action. In addition, member SORs consult the DLC, NRVC, or DLA, as appropriate, with the

understanding that federal regulations and policies take precedence over the DLC, NRVC, and DLA.

Any driving privilege withdrawal action taken will require an update to the driver history. The SOR must consult the

current AAMVA Code Dictionary (ACD) Manual and the current CDLIS State Procedures Manual for further guidance

on posting driving privilege withdrawal actions, such as disqualifications.

Notes:

In accordance with FMCSA policy Memorandum CDL-04-001, if an SOR receives a disqualification of one of its CDL

drivers from an SOW for a Failure to Appear (FTA), Failure to Pay (FTP) or Failure to Comply (FTC), the SOR must





then act on the report as if the failure occurred within the SOR. See "CD11 REPORT OUT-OF-STATE

CONVICTION" for more details.

If any new conviction results in the SOR taking a disqualification, the SOR may be required to add a pointer record to

the Problem Driver Pointer System (PDPS). See the PDPS documentation for instructions on how to add a pointer to

PDPS.

The SOR is not required to do a PDPS check when it receives an out-of-state withdrawal for driving while suspended

(ACD codes B20-B26). If the SOR opts to do a PDPS check and discovers information that is not in the driverřs

history, the SOR must contact the jurisdiction that posted the PDPS pointer and have the conviction(s) and

withdrawal(s) sent to the SOR. The SOR should also notify the AAMVA Operations Help Desk when information is

showing on PDPS but not in the CDLIS DHR. Only after receiving missing conviction and withdrawal information

from the SOC(s) and SOW(s) can the SOR accurately evaluate out-of-state convictions and withdrawals for driving

while suspended.

Once the information is posted, the SOR transmits each withdrawal, all underlying ACD conviction(s), and the

withdrawal-conviction(s) linkage in a subsequent history response, using unique two-character alphanumeric IDs for the

withdrawal and each conviction in a linkage. Each ID is arbitrarily assigned by the SOR for the transaction, so the SOR

is not required to store the IDs at the time the withdrawal is posted. See "CD04 STATE-TO-STATE HISTORY

REQUEST" and "CD08 CHANGE STATE OF RECORD" for details about transmitting linkages in the history.


If the SOR successfully posts the withdrawal and its links to all underlying convictions, if any, the SOR transmits a

Confirm Out-of-State Withdrawal (CW) message to the CDLIS Central Site. If the SOR does not post the withdrawal

and its links, it returns the Forward Out-of-State Withdrawal (HT) message in error to the CDLIS Central Site.

CD16.3.5.1 Transmission of Confirm Out-of-State Withdrawal (CW) Message

After the SOR posts the withdrawal and any new convictions, the SOR sends the Confirm Out-of-State Withdrawal

(CW) message to the Central Site.

The Confirm Out-of-State Withdrawal (CW) message must include:





values.

CD16.3.5.2 Transmission of the Forward Report of Out-of-State Withdrawal (HT) Message with Errors

If the SOR does not post the withdrawal and links to all underlying convictions, the SOR must return the original

Forward Report of Out-of-State Withdrawal (HT) message to the Central Site. The Forward Report of Out-of-State

Withdrawal (HT) message is unchanged with the following exceptions depending on the condition encountered:

If the SOR locates the driver but finds one or more validation errors on the original Forward Report of Out-of-

State Withdrawal (HT) message, it sets the following:

o NCB Error Code (GNCBER) set to 'Y'

o Message Match Count (GMSCNT) set to '01'

o Message Match Indicator (GMSIND) set to 'Y'

o Message Match Sequence Indicator (GMSMSI) set to '01'


o Last Match Indicator (GMSLMI) set to 'N'

o Message Sender Password (GMSPSW) set to the password for the SOR

o System Release Code (GMSSRL) set to 'F'

o Error Block appended (up to 5 occurrences)






If the SOR is unable to locate the driver in its database, it sets the following:



o Message Match Indicator (GMSIND) set to ŘNř


o Processing Status (GPROST) set to: '01'

o Last Match Indicator (GMSLMI) set to: 'Y'





If the SOR locates the driver and validates the message but determines that the withdrawal has already been

posted, it sets the following:












values.

CD16.4 Forward OOS Withdrawal Confirmation (CDLIS Central Site)

CD16.4.1 Reception


submitted Forward Report Out-of-State Withdrawal (HT) message:

Confirm Out-of-State Withdrawal (CW) message, if the driver record is located and the withdrawal and all

conviction data is posted

Forward Report Out-of-State Withdrawal (HT) message with error(s), if the previous conditions cannot be

satisfied


Determine the implementation status of the State of Withdrawal (SOW) by performing ŘCDJ1.2 Verification of

Message Originatorř using the following input:

Jurisdiction Code (BJUCDE) set to the Transaction Originator (GTRORG) from either the Confirm Out-of-State

Withdrawal (CW) message or the Forward Report Out-of-State Withdrawal (HT) message returned in error,


Authorization Function (BJUAFN) set to ŖCWŗ






CD16.4.2.1 Transmission of Confirm Receipt of CW (CT) Message

Upon receipt of a Confirm Out-of-State Withdrawal (CW) message from the State of Record (SOR), the CDLIS Central

Site sends a Confirm Receipt of CW (CT) message to the State of Withdrawal (SOW).

The Confirm Receipt of CW (CT) message must include:


Message Locator (GMSLOC) set to the Message Locator (GMSLOC) from the original Report Out-of-

State Withdrawal (HW) message.

Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Confirm Out-of-

State Withdrawal (CW) message



values.

CD16.4.2.2 Transmission of Report Out-of-State Withdrawal (HW) Message with Errors

If the SOR returns the Forward Report Out-of-State Withdrawal (HT) message to the CDLIS Central Site in error, the

CDLIS Central Site forwards the original associated Report Out-of-State Withdrawal (HW) message back to the SOW

with the Forward Report Out-of-State Withdrawal (HT) error message(s) appended. All Report Out-of-State

Withdrawal (HW) values should contain the orginal values as received with the following exceptions:


Transaction Originator (GTRORG) set to the value on the Forward Report Out-of-State Withdrawal (HT)

error message



Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Forward Report

Out-of-State Withdrawal (HT) error message

Processing Status (GPROST) set to the value on the Forward Report Out-of-State Withdrawal (HT) error

message

Message Match Count (GMSCNT) set to the value on the Forward Report Out-of-State Withdrawal (HT)

error message

Message Match Indicator (GMSIND) set to the value on the Forward Report Out-of-State Withdrawal

(HT) error message

Message Match Sequence Indicator (GMSMSI) set to the value on the Forward Report Out-of-State

Withdrawal (HT) error message

Last Match Indicator (GMSLMI) set to the value on the Forward Report Out-of-State Withdrawal (HT)

error message




(02/2) blocks. All other elements are passed through from the original Report Out-of-State Withdrawal (HW) message.

CD16.5 Process OOS Withdrawal Confirmation (State of Withdrawal (SOW))

CD16.5.1 Reception

The SOW receives one of two messages from the CDLIS Central Site in response to the originally submitted Report

Out-of-State Withdrawal (HW) message:

Confirm Receipt of CW (CT) message, if the withdrawal (and any new ACD convictions) were successfully




posted to the driver's record

Report Out-of-State Withdrawal (HW) message with errors, if the withdrawal (and any new ACD convictions)

was not posted to the driver's record

CD16.5.1.1 Reception of Confirm Receipt of CW (CT) Message

Receipt of the Confirm Receipt of CW (CT) message indicates successful completion of the posting of the withdrawal

and new ACD conviction(s), if any, to the driver's record by the State of Record (SOR). No further action is required

by the SOW.

The Confirm Receipt of CW (CT) message includes:



CD16.5.1.2 Reception of Report Out-of-State Withdrawal (HW) Message with Errors

Receipt of the Report Out-of-State Withdrawal (HW) message with errors indicates one of the following:

The CDLIS Central Site found errors in the Report Out-of-State Withdrawal (HW) message


Either the SOW or the SOR is not authorized for the transaction

The SOR had a problem posting the withdrawal or new ACD conviction(s), if any, to the driver's record.

The SOW reviews any error messages, works with the SOR to correct any problems, and retransmits the original Report

Out-of-State Withdrawal (HW) message or sends the withdrawal report by mail.

If the Central Site could not locate the requested driver, the Report Out-of-State Withdrawal (HW) message is returned

to the SOW exactly as submitted except the message will return error values for:





If the CDLIS Central Site finds that the SOW or the SOR is not authorized for the Report Out-of-State Withdrawal

Transaction, the Report Out-of-State Withdrawal (HW) message is returned to the SOW exactly as submitted except for

the following:












CD17 NEGATE OUT-OF-STATE WITHDRAWAL




Description

Federally mandated withdrawals and convictions are defined in the AAMVA Code Dictionary (ACD) Manual. The

Negate Out-of-State Withdrawal transaction provides a means for the State of Withdrawal (SOW) to notify the State of

Record (SOR) that the withdrawal previously posted to the Driver History Record (DHR) must be negated (i.e., either

actually removed or marked as removed) from the driver history.*

A Negate Out-of-State Withdrawal message must be sent in the following cases:

The withdrawal was a mistake (i.e., it should not have been sent in the first place)

An underlying conviction is overturned and the withdrawal is rescinded

The withdrawal information must be corrected (i.e., negated and then re-posted with corrected information). An

SOW does not need to update the reinstatement date, because an SOR does not take action on an out-of-state

withdrawal** (only on the underlying convictions).

The SOW must not include the underlying convictions when negating the withdrawal. Negated convictions must be sent

separately via the Negate Out-of-State Conviction transaction.Ref1

* Withdrawal negations must be sent only once and must be transmitted either electronically or as a paper copy via

mail, but not both.Ref2

Withdrawal negations submitted electronically and returned in error are corrected by the SOW

before resubmitted (or sent by paper copy); sending such withdrawal negations via paper copy without correction is not

allowed.

** Although the SOR does not take action on an out-of-state withdrawal, federal regulations still require the

exchange of this information.

Participants

State of Withdrawal (SOW)

o U.S. jurisdiction

CDLIS Central Site


o U.S. jurisdiction



Pre-Requisites

To help ensure the success of the transaction, an SOW submits a Search InquiryRef3


to the CDLIS Central Site to verify that the correct MPR is identified, and submits a State to State History

RequestRef5

to ensure that the withdrawal is on the DHR.

Standard Processing

The SOW sends a Negate Out-of-State Withdrawal message to the CDLIS Central Site.

Upon receipt of the Negate Out-of-State Withdrawal message, the CDLIS Central Site:

o Validates the driver identification and withdrawal/conviction information in the message


o Forwards the negate withdrawal request to the SOR

Upon receipt of the negate withdrawal information, the SOR must do the following within 96 hours*:

o Validate the driver identification and withdrawal information in the message





o Retrieve the DHR and locate the withdrawal and its linkages

o Negate the withdrawal

o Negate the linkages to the underlying convictions

o Send a confirmation to the CDLIS Central Site



o Sends a confirmation to the SOW that the transaction is complete

Inputs

The Negate Out-of-State Withdrawal must include the driverřs identification data (name, date of birth, driver's license

number and jurisdiction code combination) consistent with the information returned from the inquiries performed prior

to submission of the update (not the information on the citation(s), if different). It also must include the withdrawal data

exactly as it was originally sent when reported. The message may optionally contain the driverřs Social Security

Number, the date the driver will be or was reinstated (if available), and withdrawal extent and basis.





o The Central Site sends driver identification and withdrawal negation information received from the SOW

to the SOR


o The SOR sends a confirmation that the withdrawal has been negated

Central Site to the SOW:

o A confirmation message that the withdrawal negation is complete


Central Site

o If the Negate Out-of-State Withdrawal message does not pass the edit validations performed by the

CDLIS Central Site, the Central Site returns an error to the SOW. No further processing is performed.

o If the SOR returns an error after receiving the conviction negation information, the Central Site forwards

the error to the SOW

SOR

o If the SOR cannot locate the driver, withdrawal, or linkages upon receipt of withdrawal negation

information, the SOR returns an error to the CDLIS Central Site.

Post-Requisites

SOW

o In order to answer any questions about the withdrawal and its negation, the SOW must maintain the

original record of the withdrawal negation for as long as the withdrawal would have been maintained as

specified in the AAMVA Code Dictionary (ACD) Manual.

SOR

o Upon notice from the SOW, the SOR must negate the withdrawal and negate any links from the

withdrawal to underlying ACD convictions

o The SOR is not required to maintain any information about a withdrawal negation





References

Reference

#


Ref1 CDLIS System

Specifications


Ref2 CDLIS State

Procedures Manual


Ref3 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref4 CDLIS System

Specifications


Ref5 CDLIS System

Specifications

CD04 STATE TO STATE HISTORY REQUEST

Ref6 CDLIS System

Specifications


Federal Regulations


49 CFR 383, 384, U.S. Federal Motor Carrier Safety

Administration (FMCSA) Policy Memorandum

CDL-04-001*

Explain details of the federally mandated requirements for

negating withdrawals; A copy of FMCSAřs Policy

Memorandum is available from FMCSA

* Jurisdictions should consult their own laws and regulations for additional guidance on negating withdrawals

within the scope of their CDL programs. They should also consult the relevant interstate compacts/agreements,

including the following:




Copies of these documents are available from the AAMVA Programs Division. These sources also provide guidance for

reporting withdrawals based on convictions for offenses committed by non-CDL holders in non-CMVs, which is

beyond the scope of the CDL programs.

If any provisions of the DLC, NRVC, or DLA conflict with the federal regulations or FMCSA policy memoranda, the

federal regulations and policies take precedence.







HY Negate Out-of-State Withdrawal

HV Forward Negate Withdrawal 1

CV Confirm Negate Withdrawal 1

CY Confirm Receipt of CV 1





CD17.1 Request Negation of Withdrawal (State of Withdrawal (SOW))


The Negate Out-of-State Withdrawal Transaction enables the SOW to negate an out-of-state withdrawal and linkage in

the DHR maintained by the SOR. The SOW may not negate the underlying ACD convictions in the Negate Out-of-

State Withdrawal Transaction. See the following documents for regulations and requirements about negating a

withdrawal and its linkage:







Prior to initiating a Negate Out-of-State Withdrawal transaction for a driver in CDLIS, the SOW initiates a verification

inquiry to the Central Site to ensure positive identification of the driver. See "CD02 VERIFICATION INQUIRY" for

formatting instructions for the verification inquiry and "CD01 SEARCH INQUIRY" for formatting instructions for the

search inquiry, which uses a less restrictive search algorithm.

Upon receipt of the inquiry responses from the SOR, the SOW is responsible for confirming that the driver represented



Social Security Number) matches. The SOW may also consider secondary driver identifying data, such as Sex, Height,


Because Mexican driver records are not maintained on the Central Site, the SOW must not initiate a verification inquiry

to the Central Site before initiating a Negate Out-of-State Withdrawal transaction on a Mexican driver. The SOW just

sends a State-to-State Status Request (SG) message to 'MX' (to ensure the negation is for the correct driver) and then

send the negate withdrawal message to the Central Site with the Driver License Current Jurisdiction Code (DDLJU1)

set to 'MX'. The Central Site will forward the negate withdrawal message to 'MX' without checking for a matching

MPR.

If the SOW is unable to negate an out-of-state withdrawal and its linkage electronically via CDLIS and the SOW is

required by jurisdiction or federal regulations to negate the withdrawal, the SOW must arrange with the SOR to send the

withdrawal negation report via mail. Note that if one of the required withdrawal data elements is blank for a withdrawal

in the history, the SOW cannot negate the withdrawal electronically via CDLIS. Such a withdrawal can be negated by

mail.

CD17.1.2 Transmission of Negate Out-of-State Withdrawal (HY) Message

The Negate Out-of-State Withdrawal (HY) message must contain:


System Release Code (GMSSRL) set to 'F'
















withdrawal

Driver License Withdrawal Jurisdiction Report ID (DWDWLO) set to the reference number on the original

withdrawal

Driver License Withdrawal Effective Date (DWDDWD) set to the date on the original withdrawal

Driver License Withdrawal Type (DWDWTP) set to the code on the original withdrawal

Driver License ACD Withdrawal Reason Code (DWDWRS) set to the code on the original withdrawal

Driver License Withdrawal Reason Reference (DWDWRR) set to the native state code on the original

withdrawal


The Negate Out-of-State Withdrawal (HY) message may optionally include:


Driver License Withdrawal Basis (DWDWBS) set to the code on the original withdrawal

Driver License Withdrawal Due Process Status (DWDWPS) set to the code on the original withdrawal

Driver License Withdrawal Eligibility Date (DWDWDE) set to the date on the original withdrawal

Driver License Withdrawal Reinstatement Date (DWDWDR) set to the date on the original withdrawal

Driver License Withdrawal Extent ID - DLC (DWDWEX) set to the code on the original withdrawal


values.

CD17.2 Validate Withdrawal Negation Data (CDLIS Central Site)

CD17.2.1 Reception of Negate Out-of-State Withdrawal (HY) Message

Upon receipt of a Negate Out-of-State Withdrawal (HY) message from a jurisdiction, the CDLIS Central Site initiates



The CDLIS Central Site performs the validation checks described below on the Negate Out-of-State Withdrawal (HY)

message. If errors are detected, the Central Site stops processing and returns the original message to the sender with

error fields set. Up to five validation failures may be reported on a single error message. The Central Site must report as

many problems as it can to minimize the number of resends.

The CDLIS Central Site does fewer non-key validation checks on the Negate Out-of-State Withdrawal (HY) message

than on the Report Out-of-State Withdrawal (HW) message. Some withdrawals are posted with missing, incorrect, or

invalid data. This can happen, for example, with withdrawals that are posted by mail. The less stringent Negate Out-of-

State Withdrawal (HY) message validation checks allow such withdrawals to be negated.

Validate the password and determine the implementation status of the State of Withdrawal (SOW) by performing

ŘCDJ1.2 Verification of Message Originatorř using the following input;

Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Negate Out-of-State

Withdrawal (HY) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Negate Out-

of-State Withdrawal (HY) message

Authorization Function (BJUAFN) set to ŖHYŗ











(DDLJDL).



(DDLJDL).




Jurisdiction Code - Withdrawing (DWDJUR) must be present.

Error Text: 'STATE-OF-WITHDRAWAL CODE REQUIRED'

Driver License Withdrawal Effective Date (DWDDWD) must be present.

Error Text: 'WITHDRAWAL EFFECTIVE DATE REQUIRED'

Driver License Withdrawal Type (DWDWTP) must be present.

Error Text: 'WITHDRAWAL TYPE DETAIL REQUIRED'

Driver License ACD Withdrawal Reason Code (DWDWRS) must be present.

Error Text: 'ACD WITHDRAWAL REASON CODE REQUIRED'

Driver License Withdrawal Jurisdiction Report ID (DWDWLO) must be present.

Error Text: 'WITHDRAWAL JURISDICTION REPORT ID REQUIRED'

Driver License Withdrawal Reason Reference (DWDWRR) must be present.

Error Text: 'WITHDRAWAL REASON REFERENCE REQUIRED'

System Release Code (GMSSRL) must be present.

Error Text: 'SYSTEM RELEASE CODE REQUIRED'















DICTIONARYŗ.



DICTIONARYŗ.


Jurisdiction Code - Withdrawing (DWDJUR) must contain one of the valid values in the "United States" list

under Jurisdiction Code (BJUCDE) in ŖAPPENDIX D - DATA DICTIONARYŗ.

Error Text: 'INVALID STATE-OF-WITHDRAWAL CODE'


Must be numeric





System Release Code (GMSSRL) must be set to 'F'.














Withdrawing (DWDJUR).

Error Text: 'SOW AND TRANSACTION ORIGINATOR DO NOT MATCH'









(DDLJDL) from the Negate Out-of-State Withdrawal (HY) message; and


(DDLJDL) from the Negate Out-of-State Withdrawal (HY) message

If no Master Pointer (CD20) record is found, access the AKA ST-DLN (CD24) by the following fields from the

Negate Out-of-State Withdrawal (HY) message:


Number (DDLJDL)


Number (DDLJDL)





perform the "CD17.2.2.6 Retrieved Record Match Errors" below.



If Driver SSN - CDLIS (DDVSS6) is present, the name information on the Negate Out-of-State Withdrawal

(HY) message must correspond with the name information on the existing Master Pointer (CD20). The

comparison is performed as described in "7.2 Name Comparison".

If Driver SSN - CDLIS (DDVSS6) is not present, the last name on the Negate Out-of-State Withdrawal (HY)

message must match the last name on the existing Master Pointer (CD20).





Transitional Note:

When matching last names the CDLIS Central Site shall take into account that the same name may have slight

differences depending on whether it was originally captured in the format described in ŖAPPENDIX E.1 Ŕ

AAMVA PERSON NAME FORMATTING RULESŗ or in the format described in 'APPENDIX E.2 - AAMVA

PERSON NAME STANDARD (2008)'.

The following data on the Negate Out-of-State Withdrawal (HY) message must match the corresponding data on the













If present, the last 5 positions of the Driver SSN - CDLIS (DDVSS6) must match the CD20 Person SSN

Last 5 Digits (BPESSD)




(DDVSSN)





Negate Out-of-State Withdrawal (HY) message if the values are ŘMXřř; otherwise set to the Jurisdiction Code

Ŕ Licensing (DDLJUR) on the retrieved Master Pointer (CD20) record

Authorization Function (BJUAFN) set to ŖHVŗ



CD17.2.3.1 Transmission of Forward Negate Withdrawal (HV) Message

If the Negate Out-of-State Withdrawal (HY) message is valid, the CDLIS Central Site sends a Forward Negate

Withdrawal (HV) message to the State of Record (SOR).

The Forward Negate Withdrawal (HV) message must include:


The Forward Negate Withdrawal (HV) message must include the following withdrawal information from the Negate

Out-of-State Withdrawal (HY) message:




(DDLJDL) on the Negate Out-of-State Withdrawal (HY) message if the values are ŘMXř; otherwise set to

the Jurisdiction Code - Licensing (DDLJUR) from the retrieved Master Pointer (CD20) record




Driver License Withdrawal Effective Date (DWDDWD), if present

Driver License Withdrawal Type (DWDWTP), if present

Driver License Withdrawal Basis (DWDWBS), if present

Driver License Withdrawal Due Process Status (DWDWPS), if present

Driver License ACD Withdrawal Reason Code (DWDWRS), if present

Driver License Withdrawal Eligibility Date (DWDWDE), if present

Driver License Withdrawal Extent ID - DLC (DWDWEX), if present



Driver License Withdrawal Reinstatement Date (DWDWDR), if present





The Forward Negate Withdrawal (HV) message must include the following from the Master Pointer (CD20) record:







(BPESSD)








in positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) on the Negate Out-of-State Withdrawal (HY)


CDLIS Central Site transmits the withdrawal to the SOR on the CD20 record. Old SOR(s) will not be notified.


values.

CD17.2.3.2 Transmission of Negate Out-of-State Withdrawal (HY) Message with Errors

If the CDLIS Central Site encounters errors on the original Negate Out-of-State Withdrawal (HY) message that


occurrences).



(02/2) blocks.

CD17.3 Process Withdrawal Negation (State of Record (SOR))


Upon receipt of the Forward Negate Withdrawal (HV) message, the SOR validates the message, locates the driver and

the associated withdrawal on its database, and, if found, negates the withdrawal and its linkage to underlying

convictions from the driver history record. The SOR then evaluates whatever licensing action may be necessary.

Note: If the SOR is unable to negate an out-of-state withdrawal and its linkage electronically via CDLIS and the SOR is

required by jurisdiction or federal regulations to negate an out-of-state withdrawal, the SOR arranges with the SOW to

(1) receive the negation report, (2) negate the withdrawal and its linkage, and (3) confirm the negation by mail. The

SOR must negate the withdrawal manually when it receives the negation. See the CDLIS State Procedures Manual for

procedures to negate a withdrawal by mail.

CD17.3.2 Reception of Forward Out-of-State Negate Withdrawal (HV) Message

The Forward Out-of-State Negate Withdrawal (HV) message contains:








Driver License Jurisdiction Number (DDLJDL) composed of the following two data elements:









If available, the Forward Negate Withdrawal (HV) message sent by the CDLIS Central Site also contains the following:









CD17.3.3 Validation

The SOR performs the following validation checks on the Forward Out-of-State Negate Withdrawal (HV) message. If

the SOR detects any errors, it sets the appropriate error fields (see Ŗ4 CDLIS ERROR PROCESSINGŗ for details),

returns the original message to its sender for correction, and stops processing the transaction.

Note: The SOR must not return the Forward Out-of-State Negate Withdrawal (HV) message for an invalid Driver

License ACD Withdrawal Reason Code (DWDWRS), because the original withdrawal may have had the erroneous

code. If the message having a retired ACD code passes other validation checks and the SOR finds a matching

withdrawal, the SOR must negate the matching withdrawal.




CDLIS (DDVSS6) are not permitted. If the SOW does not find a match, issue an error.


CD17.3.3.2 Withdrawal Matching Errors

When entering an in-state or out-of-state withdrawal, the SOR must check that the withdrawal is on the CDLIS driver

history. A withdrawal is found by matching on the following six data elements which combined uniquely identify a

specific withdrawal:

Jurisdiction Code Ŕ Withdrawing (DWDJUR)










If the withdrawal does not exist on the driver history, the SOR must reject the withdrawal negation report and issue an

error. The SOR takes no additional driver control actions.

Error Text: 'WITHDRAWAL NOT FOUND'

If the withdrawal is not found, the SOR should contact the SOW and manually determine why the negation was sent,

especially if the withdrawal matches on five or fewer of the identifying data elements.

Note: The jurisdiction must have equivalent procedures in place to handle a "withdrawal not found" error when

entering paper withdrawal negations.

If more than one withdrawal is found by matching on the six data elements, the SOR must reject the withdrawal

negation report and issue an error. The SOR takes no additional driver-control actions.

Error Text: 'DUPLICATE WITHDRAWALS FOUND'

If more than one withdrawal is found, the SOR should contact the SOW and manually determine why duplicates exist

and why the negation was sent.

Note: The jurisdiction must have equivalent procedures in place to handle a "DUPLICATE WITHDRAWALS

FOUND" error when entering paper withdrawal negations.

CD17.3.4 Updates

The SOR does not negate any withdrawal from the driver history if it finds any errors in the Forward Negate Out-of-

State Withdrawal (HV) message. If no errors are found, the SOR negates the withdrawal and its linkage to underlying

convictions from the driver history record. The SOR also records the date the negation was received and the date the

withdrawal was negated from the driver history.


If the SOR negates the withdrawal and its links to all underlying convictions, if any, the SOR transmits a Confirm

Negate Withdrawal (CV) message to the CDLIS Central Site. If the SOR doesn't negate the withdrawal, it returns the

Forward Negate Out-of-State Withdrawal (HV) message in error to the CDLIS Central Site.

CD17.3.5.1 Transmission of Confirm Negate Withdrawal (CV) Message

After the SOR negates the withdrawal, the SOR sends the Confirm Negate Withdrawal (CV) message to the Central

Site.

The Confirm Negate Withdrawal (CV) message must include:



Message Sender Password (GMSPSW) set to the password of the SOR


values.

CD17.3.5.2 Transmission of Forward Negate Withdrawal (HV) Message with Errors

The SOR returns the original Forward Negate Withdrawal (HV) message to the Central Site and must not negate the

withdrawal and any of its links to underlying convictions on the driver history, if the SOR:

Finds any errors on the original Forward Out-of-State Negate Withdrawal (HV) message


Determines that the withdrawal cannot be negated (either it was never received or has already been negated)

The Forward Negate Out-of-State Withdrawal (HV) message is unchanged with the following exceptions, which depend

on the condition encountered:





If the SOR finds one or more validation errors on the original Forward Negate Out-of-State Withdrawal (HV)

message, it sets the following:











If the SOR is unable to locate the driver in its database, it sets the following:



o Message Match Indicator (GMSIND) set to 'N'



o Last Match Indicator (GMSLMI) set to 'Y'





If the SOR locates the driver and validates the message but determines that the withdrawal cannot be negated, it

sets the following:












values.

CD17.4 Forward Negation Confirmation (CDLIS Central Site)

CD17.4.1 Reception


submitted Forward Negate Out-of-State Withdrawal (HV) message:

Confirm Negate Withdrawal (CV) message, if the driver record is located and the withdrawal is negated





Forward Negate Out-of-State Withdrawal (HV) message with error(s), if the previous conditions cannot be

satisfied


Determine the implementation status of the State of Withdrawal (SOW) by performing ŘCDJ1.2 Verification of

Message Originatorř using the following input:

Jurisdiction Code (BJUCDE) set to the Transaction Originator (GTRORG) from either the Confirm Negate

Withdrawal (CV) message or the Forward Negate Out-of-State Withdrawal (HV) message returned in error,


Authorization Function (BJUAFN) set to ŖCVŗ


CD17.4.2.1 Transmission of Confirm Receipt of CV (CY) Message

Upon receipt of a Confirm Negate Withdrawal (CV) message from the State of Record (SOR), the CDLIS Central Site

sends a Confirm Receipt of CV (CY) message to the State of Withdrawal (SOW).

The Confirm Receipt of CV (CY) message must include:


Message Locator (GMSLOC) set to the Message Locator (GMSLOC) from the original Negate Out-of-

State Withdrawal (HY) message.

Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Confirm Receipt of

CV (CY) message



values.

CD17.4.2.2 Transmission of Negate Out-of-State Withdrawal (HY) Message with Errors

If the SOR returns the Forward Negate Out-of-State Withdrawal (HV) message to the CDLIS Central Site in error, the

CDLIS Central Site forwards the original associated Negate Out-of-State Withdrawal (HY) message back to the SOW

with the Forward Negate Out-of-State Withdrawal (HV) error message(s) appended. All Negate Out-of-State

Withdrawal (HV) values should contain the original values as received with the following exceptions:


Transaction Originator (GTRORG) set to the value on the Forward Negate Out-of-State Withdrawal

(HV) message



Message Destination (GMSDST) set to the Transaction Originator (GTRORG) on the Negate Out-of-

State Withdrawal (HY) error message

Processing Status (GPROST) set to the value on the Forward Negate Out-of-State Withdrawal (HV)

message

Message Match Count (GMSCNT) set to the value on the Forward Negate Out-of-State Withdrawal

(HV) message

Message Match Indicator (GMSIND) set to the value on the Forward Negate Out-of-State Withdrawal

(HV) message

Message Match Sequence Indicator (GMSMSI) set to the value on the Forward Negate Out-of-State

Withdrawal (HV) message

Last Match Indicator (GMSLMI) set to the value on the Forward Negate Out-of-State Withdrawal (HV)





message




(02/2) blocks.

CD17.5 Process Negate OOS Withdrawal Confirmation (State of Withdrawal (SOW))

CD17.5.1 Reception

The SOW receives one of two messages from the CDLIS Central Site in response to the originally submitted Negate

Out-of-State Withdrawal (HY) message:

Confirm Receipt of CV (CY) message, if the withdrawal was successfully negated from the driverřs record

Negate Out-of-State Withdrawal (HY) message with errors, if the withdrawal was not negated from the driver's

record

CD17.5.1.1 Reception of Confirm Receipt of CV (CY) Message

Receipt of the Confirm Receipt of CV (CY) message indicates successful completion of the negation of the withdrawal

from the driver's record by the State of Record (SOR). No further action is required by the SOW.

The Confirm Receipt of CV (CY) message includes:



CD17.5.1.2 Reception of Negate Out-of-State Withdrawal (HY) Message with Errors

Receipt of the Negate Out-of-State Withdrawal (HY) message with errors indicates one of the following:

The CDLIS Central Site found errors in the Negate Out-of-State Withdrawal (HY) message


Either the SOW or the SOR is not authorized for the transaction

The SOR had a problem negating the withdrawal on the driver's record.

If either the SOW or the SOR is not authorized for the transaction, or if the SOR had a problem negating the conviction

on the driverřs record, the SOW and SOR should work with each other to correct any problems and complete the

negation manually.

If the CDLIS Central Site found errors in the Negate Out-of-State Withdrawal (HY) message, or if the driver could not

be located on the CDLIS Central Site or the SORřs database, the SOW should review any error messages, work with the

SOR to correct any problems as appropriate, and retransmit the original Negate Out-of-State Withdrawal (HY) message.

If the Central Site could not locate the requested driver, the Negate Out-of-State Withdrawal (HY) message is returned

to the SOW exactly as submitted except the message will return error values for:





If the CDLIS Central Site finds that the SOW or the SOR is not authorized for the Negate Out-of-State Withdrawal

Transaction, the Negate Out-of-State Withdrawal (HY) message is returned to the SOW exactly as submitted except for

the following:

Error messages are set for the following:





Processing Status (GPROST) set to '03' (syntax error)

See ' See Ŗ4 CDLIS ERROR PROCESSINGŗ for information on formatting error messages.

If the SOR returns the Forward Negate Out-of-State Withdrawal (HY) message in error to the CDLIS Central Site, the

CDLIS Central Site returns the Negate Out-of-State Withdrawal (HY) message to the SOW exactly as submitted with

the following exceptions:












CD18 MINIMAL DATA DRIVER SEARCH INQUIRY




Description

Occasionally FMCSA needs to search for a driver with less than complete information. In these instances FMCSA may

know the driverřs name, approximate age and State of residence, but not the exact ST-DLN or date of birth.

The Minimal Data Driver Search Inquiry transaction is a request for Master Pointer Record (MPR) information when

less than complete information is known. The transaction provides information necessary for FMCSA to obtain driver

history information from the driverřs State of Record (SOR) when driver data is minimal.Ref1

Participants

FMCSA (Restricted FMCSA Personnel)

CDLIS Central Site

Pre-Requisites

None

Standard Processing

FMCSA makes a request by sending a Minimal Data Driver Search Inquiry message to the CDLIS Central Site.

Upon receipt of the Minimal Data Driver Search Inquiry message, the CDLIS Central Site:


o If the driverřs age is present,

Calculates the driverřs year of birth by subtracting the driverřs age from the current calendar year

Calculates the year search range by factoring an age range of +/- n years to the driverřs calculated

year of birth

o Sets the appropriate default values for other matching criteria where not provided explicitly provided by

FMCSA

o Searches the Central Site for potential matches for the person in question

o Responds with the following information:

Details from the Central Site for each match found, up to the maximum number of matches to be

returned

An indicator if more than the maximum number of requested matches exist

If present on the request, the list of jurisdictions searched, in the order that the search was applied.

Number of matches found

Upon receipt of the MPR data, FMCSA validates the message data

Inputs

The Minimal Data Driver Search Inquiry transaction includes the driverřs name. It may optionally include:

The driver's age

The number of years either side of the driverřs computed year of birth to be considered (defaults to 3 if the

driverřs age is present but the number of years either side is not)

Up to 10 licensing jurisdiction codes to be considered; if not present, the CDLIS Central Site searches on all

jurisdictions ordered by the number of CDLIS pointers starting with the maximum number

The number of the first match to be returned (allows continuation of previous search if data on the correct driver

in question not returned on a previous inquiry); for example, if set to Ř25ř the first 24 matches found will not be

returned; if not present, defaults to 1

The maximum number of responses to be returned; if not present, defaults to 15






Central Site to FMCSA:

o The Central Site returns information on the number of matches found, along with all the MPR data for

each match, up to the maximum number of responses.


Central Site

o If the Minimal Data Driver Search Inquiry does not pass the edit validations performed by the CDLIS

Central Site, the Central Site returns an error to FMCSA. No further processing is performed.

Post-Requisites

If more than the maximum number of matches are found and none of them can be determined with certainty to

be the driver in question, FMCSA changes the search criteria to reduce the number of matches (e.g., reduce the

number of years either side of the driverřs computed year of birth to be considered) or specifies a different range

of matches to be returned.

FMCSA determines if any of the drivers on whom data was returned is the driver in question and, if so, initiates

a State-to-State History Request transaction to the SOR of the driverRef2

References

Reference

#


Ref1 CDLIS System

Specifications


Ref2 CDLIS System

Specifications








IF Minimal Driver Data Inquiry

RK Number of MPR Responses from Inquiry 1

RZ MPR Data for Match on Inquiry 0 - 99

CD18.1 Request Driver Information (FMCSA)


The Minimal Data Driver Search Inquiry transaction is a request for Master Pointer Record information about an





individual when known driver data is minimal.

CD18.1.2 Transmission of Minimal Data Driver Search Inquiry (IF) Message

The Minimal Data Driver Search Inquiry (IF) message must include:



The IF message may optionally include:

Driver Age (DDVAGE) set to the driver's age

Message Year Search Range (GMSSYR) set to the number of years either side of the driverřs computed year of

birth to be considered; defaults to 3 if value not present and Driver Age (DDVAGE) is present

State of Record (BJUCD1) set to the issuing jurisdiction code(s) on which the search is to be performed, up to 10

occurrences

Message First Match Sequence ID (GMSFMS) set to the number of the first match to be returned; if value not

present, defaults to 01*

Message Match Count (GMSCNT) set to the total number of matches to be returned; if value not present,

defaults to 15; maximum of 99

Return as Received Text/Block (GRRECV) set to any value desired by FMCSA

*This allows continuation of a previous search when the maximum to be returned is exceeded. If set to Ř25ř, for

example, the first 24 matches found will not be returned

See "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE" for remaining elements in the NCB and MEC

blocks.

CD18.2 Research Driver (CDLIS Central Site)

CD18.2.1 Reception of Minimal Driver Data Inquiry (IF) Message

Upon receipt of a Minimal Driver Data Inquiry (IF) message from FMCSA, the CDLIS Central Site initiates validation

processing.


The CDLIS Central Site performs the following validations on the Minimal Driver Data Inquiry (IF) message. If errors

are detected, the Central Site stops processing and returns the original message to FMCSA with error fields set.

FMCSA must correct the errors and resend the Minimal Driver Data Inquiry (IF) message. Up to five validation failures

may be reported on a single error message. The Central Site must report as many problems as it can to minimize the

number of resends.

Validate the password and determine the implementation status of FMCSA by performing ŘCDJ1.2 Verification of

Message Originatorř using the following input;

Jurisdiction Code (BJUCDE) set to the Message Originator (GMSORG) from the Minimal Driver Data Inquiry

(IF) message

Message Sender Password (GMSPSW) set to the Message Sender Password (GMSPSW) from the Minimal

Driver Data Inquiry (IF) message

Authorization Function (BJUAFN) set to ŖIFŗ












The Message Originator (GMSORG) must be ŘFHř.

Error Text: 'INVALID ORIGIN'

The Person Name Group (BPENGP) must conform to the requirements listed in "APPENDIX E.3 - AAMVA PERSON

NAME STANDARD (2008) VALIDATIONS"



The Driver Age (DDVAGE), if present, must conform to the requirements listed in "APPENDIX D.1 - DATA

ELEMENTS"

Error Text: 'INVALID AGE'

The Message Year Search Range (GMSSYR), if present, must conform to the requirements listed in "APPENDIX D.1 -

DATA ELEMENTS"

Error Text: 'INVALID YOB RANGE'

All the elements in the State of Record (BJUCD1), if present, must conform to the "United States" list in "APPENDIX



The Message First Match Sequence ID (GMSFMS), if present, must conform to the requirements listed "APPENDIX


Error Text: 'INVALID FIRST MATCH COUNT'

The Message Match Count (GMSCNT), if present, must conform to the requirements listed in "APPENDIX D.1 -

DATA ELEMENTSŗ

Error Text: 'INVALID MAX NUMBER RESPONSES'

CD18.2.3 Retrieval

Before searching for matching drivers, the CDLIS Central Site performs the following:

If the Driver Age (DDVAGE) is present, computes the driverřs year of birth (YOB) by subtracting Driver Age

(DDVAGE) from the current calendar year

If any of the following elements are not present or have a value of zero, sets them to the listed default value

Data Element Value

Message Year Search Range (GMSSYR) If DDVAGE present, set to Ř3ř

State of Record (BJUCD1) Jurisdiction codes based on the number of pointers in each jurisdiction

Message First Match Sequence ID (GMSFMS) Ř01ř

Message Match Count (GMSCNT) Ř15ř

The CDLIS Central Site searches the Master Pointer (CD20) data store. A pointer record is returned as a match with the





inquiry data if the following criteria are satisfied:

Input Match Criteria

Licensing Jurisdiction(s) Exact Match1

Name Matches, exactly or approximately, based on the search algorithm

Age (if present) Year portion of the Person Date of Birth (BPEDOB) within the Message Year Search Range

(GMSSYR) of the computed YOB

1 Jurisdictions are searched in the order they appear in the list (i.e., consider all drivers in first jurisdiction before

considering drivers in second jurisdiction, etc.)

During the search, the CDLIS Central site tracks the number of MPRs determined to be a match (and the order in which

each was identified as a match) based on the input criteria. The search ends if the number of MPRs exceeds the sum of

Message Match Count (GMSCNT) plus the Message First Match Sequence ID (GMSFMS).

Once the search is complete, the Central Site returns up to the Message Match Count (GMSCNT) beginning with the

MPR with the sequence number equal to the Message First Match Sequence ID (GMSFMS).

Example:

Input

Message Match Count (GMSCNT) = 50

Message First Match Sequence ID (GMSFMS) = 25

Records returned

If the count of matching MPRs = 76 (one more than 50 + 25)

o Matches 25-75 are returned with an indication that more matches were found than could be

returned

If the count of matching MPRs never gets to 76

o All matches beginning with the 25th

are returned with no indication that more matches were found

than could be returned

Notes:

The search is done first only on primary names on the MPR. If the Message Match Count (GMSCNT) has not

been reached, the search starts over with the first jurisdiction listed and searches only on AKA names and YOBs

(if Driver Age (DDVAGE) present)

Age

o If the Driver Age (DDVAGE) is not present, all drivers in the State of Record (BJUCD1) whose name

matches are returned

o If the Driver Age (DDVAGE) is present, the same criteria is used and the YOB must be within the range

specified

If the Central Site identifies a driver based on primary and AKA data, the Central Site returns the data for that

driver only once.


When all searches have been completed, CDLIS Central Site creates and sends the following messages to FMCSA:

Message Number sent

Number of MPR Responses from

Inquiry (RK)

1

MPR Data for Match on Inquiry

Transaction (RZ)

0 to Message Match Count (GMSCNT) as specified by the inquirer on the

associated inquiry message





CD18.2.4.1 Transmission of Number of MPR Responses from Inquiry (RK) Message

The Central Site returns a single Number of MPR Responses from Inquiry (RK) message indicating how many matches

were found. This match count equals the number of MPR Data for Match on Inquiry Transaction (RZ) messages that

will be sent. If there are zero matches, the Number of MPR Responses from Inquiry (RK) message will be the only

response to FMCSA and the transaction is considered complete.

The Number of MPR Responses from Inquiry (RK) message must include:

Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Minimal Driver Data Inquiry

(IF) message.

Message Locator/Header (GMSLOC) set to the value on the original Minimal Driver Data Inquiry (IF) message.

Message Match Count (GMSCNT) set to the number of matching MPRs being sent Message Match Indicator

(GMSIND) set to 'Y' if at least one matching MPR was found; 'N' otherwise

Message Match Limit Exceeded Indicator (GMSLEI) set to 'Y' if more than input Message Match Count

(GMSCNT) matches were found; 'N' otherwise

The Number of MPR Responses from Inquiry (RK) message may optionally include:

State Of Record (BJUCD1)3 that were searched (max of 10 Ŕ see note below)

Return as Received Text/Block (GRRECV) set to the value on the original message (if any)

CD18.2.4.2 Transmission of MPR Data for Match on Inquiry Transaction (RZ) Message(s)

One MPR Data for Match on Inquiry Transaction (RZ) message is returned for each match found on the Master Pointer

(CD20) data store.

The MPR Data for Match on Inquiry Transaction (RZ) message must include:

Message Destination (GMSDST) set to the Message Origin (GMSORG) on the Minimal Driver Data Inquiry

(IF) message




Message AKA DLN Count (GMSCDL) set to the number of AKA ST-DLN (CD24) records being sent on the

message, up to a maximum of 3

Message AKA Name Count (GMSCNM) set to the number of AKA Name (CD22) records being sent on the

message, up to a maximum of 3

The MPR Data for Match on Inquiry Transaction (RZ) message must include the following from the Master Pointer

(CD20) record:





Person Date of Birth (BPEDOB) set to the CD20 Driver Date of Birth (DDVDOB)

The last 5 positions of Driver SSN- CDLIS (DDVSS6) set to the CD20 Person SSN Last 5 Digits (BPESSD)

Message SOR Change in Progress Indicator (GMSSCH) set to the Message SOR Change in Progress Indicator

(GMSSCH) of the first matching CD20 record

3 The State of Record (BJUCD1) includes a state code corresponding to each jurisdiction searched (in the order

searched) if a list of SORs was present on input; if a list of SORs was not present on input, no state codes are returned

(FMCSA knows the order of jurisdictions searched)





The MPR Data for Match on Inquiry Transaction (RZ) message must also include:



o All associated CD23 records have Master Pointer Unique Indicator (DCDPUI) equal to ŘUř


o the CD20 record has at least one associated Duplicate Pointer (CD23) record with Master Pointer Unique

Indicator (DCDPUI) equal to ŘDř or ŘPř

The MPR Data for Match on Inquiry Transaction (RZ) message must include the following from the three most recent

AKA Name (CD22) records associated with the CD20 record, where present and used to determine the match:

The first occurrence of Person AKA Name Group (BPENG3) set to the Person AKA Name Group (BPENG3) of

the most recent CD22

The second occurrence of Person AKA Name Group (BPENG3) set to the Person AKA Name Group (BPENG3)

of the second most recent CD22

The third occurrence of Person AKA Name Group (BPENG3) set to the Person AKA Name Group (BPENG3)

of the third most recent CD22

The MPR Data for Match on Inquiry Transaction (RZ) message must include the following from the three most recent

AKA ST-DLN (CD24) records associated with the CD20 record where the AKA ST-DLN Status (DDLKST) = ŘAř,

where present and used to determine the match:

AKA Driver License Jurisdiction Number (DDLJD2) set to the AKA Jurisdiction Code - Licensing (DDLJU2)

concatenated to the AKA Driver License Number (DDLNUI) of the most recent CD24


(DDLJU2) concatenated to the AKA Driver License Number (DDLNUI) of the second most recent CD24


(DDLJU2) concatenated to the AKA Driver License Number (DDLNUI) of the third most recent CD24


values.

CD18.2.4.3 Transmission of Minimal Driver Data Inquiry (IF) Message with Errors

If the CDLIS Central Site encounters errors on the original Minimal Driver Data Inquiry (IF) message that preclude

further processing, the Central Site returns the message to FMCSA with Error Block appended (up to 5 occurrences).



(02/2) blocks.

CD18.3 Assess Responses (FMCSA)


Once an inquiry has been sent to the CDLIS Central Site, FMCSA receives the following messages:

Message Number received

Number of MPR Responses from Inquiry (RK) 1

MPR Data for Match on Inquiry Transaction (RZ) 0 to Message Match Count (GMSCNT)





CD18.3.2 Reception

CD18.3.2.1 Reception of the Number of MPR Responses from Inquiry (RK) Message

The Number of MPR Responses from Inquiry (RK) message includes:





Message Match Limit Exceeded (GMSLEI)*

* If more matches are found than requested by FMCSA, the CDLIS Central Site sets the Message Match Limit

Exceeded flag to 'Y' indicating more than the maximum matches exist. Only the Maximum Number of Responses

requested on input are sent.

The Number of MPR Responses from Inquiry (RK) message may optionally include:

State Of Record (BJUCD1)


Upon receipt of the Number of MPR Responses from Inquiry (RK) message, FMCSA checks the Message Match

Count:

If Message Match Count (GMSCNT) equal to 0, no matches were found in the CDLIS Master Pointer File over

and above the requested maximum to be returned. No other messages will follow.

If Message Match Count (GMSCNT) greater than 1 but less than the number of drivers requested by FMCSA,

FMCSA can expect the number of MPR Data for Match on Inquiry Transaction (RZ) messages indicated from


If Message Match Count equal to the number of drivers requested by FMCSA, FMCSA can expect exactly the

number of drivers requested by FMCSA MPR Data for Match on Inquiry Transaction (RZ) messages. The

Message Match Limit (GMSLEI) is set to 'Y' if more than the number of drivers requested by FMCSA matches

were found. This indicates more than the number of drivers requested by FMCSA matches were found but MPR

Data for Match on Inquiry (RZ) messages for only the input Message Match Count (GMSCNT) are being sent.

CD18.3.2.2 Reception of the MPR Data for Match on Inquiry Transaction (RZ)

The MPR Data for Match on Inquiry Transaction (RZ) message includes:








CSOR in Progress Indicator (GMSSCH)


AKA DLN Count (GMSCDL)

AKA Name Count (GMSCNM)

Driver's Primary Name (DDVNAM)

Person Date of Birth (BPEDOB)

The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) set to the CD20 Person SSN Last 5 Digits (BPESSD)







The MPR Data for Match on Inquiry Transaction (RZ) message may optionally include:







Notes:

Based on the Number of MPR Responses from Inquiry (RK) message, FMCSA will know the number of MPR Data for

Match on Inquiry Transaction (RZ) messages to expect. FMCSA procedures will dictate whether processing begins

with receipt of the first MPR Data for Match on Inquiry Transaction (RZ) message or after all MPR Data for Match on

Inquiry Transaction (RZ) messages have been received.

If the number of records found exceeds the maximum number requested, FMCSA can evaluate the MPR Data for Match

on Inquiry Transaction (RZ) messages returned to determine if any of the drivers on whom information was returned is

the correct driver. If not, FMCSA can submit a new query, if desired, where the first record to be returned is after the

previous maximum number of responses.

Because messages may not be received in the order sent, it is recommended that the Last Match Indicator (GMSLMI)

not be used to determine when all MPR Data for Match on Inquiry Transaction (RZ) messages have been received.

Comparing the number of MPR Data for Match on Inquiry Transaction (RZ) messages received to the Message Match

Count (GMSCNT) is a more reliable method of ensuring all messages have been received (for UNI users, this task may

be performed with the message grouping option).







Description

One of the functions of the CDLIS Central Site is to prevent more than one record from being established for the same

driver. To achieve this, the CDLIS Central Site checks for possible duplicates when a State performs any of the

following triggering transactions:

Add New Driver Ref1

Change Data Ref2

if key driver identification data or AKA data is submitted with the transaction

Update AKA Data Ref3

if key driver identification data or AKA data is submitted with the transaction

Change State of Record (CSOR) Ref4

, if key driver identification data is being changed during the transaction

If any of the above actions lead to the creation of possibly duplicating records, the CDLIS Central Site marks the

records as such, and notifies both State of Records accordingly. The States of Record then cooperatively determine how

to resolve the situation.

To determine when and if the "possible duplicate" designation on a Master Pointer Record can be removed, the CDLIS

Central Site reviews these records (i.e. records marked as possible duplicates) when a State performs any of the

following transactions:

Delete Master Pointer Record Ref6

Change Data Ref2

Mark Driver Unique Ref7

The following are examples of how possible duplicate records are created.

An Add New Driver transaction Ref1

is submitted when a Change State of Record (CSOR) transaction Ref4

should

have been submitted. In this case, the driver is already on CDLIS and, for whatever reason, the jurisdiction that

issued the CDL neglected to perform the CSOR transaction. In this situation, deleting the MPR created by the

Add New Driver transaction will resolve the duplicate. The jurisdiction must also perform the CSOR transaction

to correctly process the issuance of the CDL and gather the driver's history.

The two drivers are separate individuals, but an input error was made when entering key data (e.g., SSN,

ST/DLN, or Name/DOB). The incorrect data is corrected through the Change Data transaction. Ref2

The two drivers are separate individuals but have the same SSN or their SSN, name, and date of birth

combination are similar enough to raise a question on their uniqueness. To resolve this, both jurisdictions must

mark their drivers as unique to the other driver using the Mark Driver Unique transaction. Ref7

The two drivers are in fact the same person and further research reveals that he/she is attempting to obtain a

second CDL. Both jurisdictions should disqualify the driver. Both pointer records will remain on CDLIS. No

attempt should be made to resolve the duplicate to prevent the driver from attempting another CSOR.

One driver is attempting to impersonate another driver. To protect the innocent driver, jurisdictions should use

the Mark Driver Unique transaction to resolve the possible duplicate situation while they conduct further

investigation.

Participants

Initiating SOR (the entity whose actions lead to the creation of new/updated record for a driver (the 'initiating

driver') that possibly duplicates an existing Master Pointer Record)

o U.S. jurisdiction

CDLIS Central Site

Established SOR (the entity that is the owner of a record for a driver (the "established driver") that (possibly)

corresponds with the initiating driver's record))

o U.S. jurisdiction





Pre-Requisites

None.

Standard Processing

Upon receipt of one of the triggering transactions above, the CDLIS Central Site:

o Performs a search of existing MPRs for possible duplicates

o Flags all possible duplicate records

o For each possible duplicate MPR found, transmits a Possible Duplicate Notification to the Initiating SOR

and to the Existing SOR of the possible duplicate driver

Upon receipt of the Possible Duplicate Notification, the Initiating SOR becomes responsible for initiating the

process to resolve the possible duplicate(s).

When a duplicate has been resolved, the CDLIS Central Site sends a Duplicate Resolved Notification to the

Initiating SOR and to the Established SOR. No additional action is required upon receipt of such notification.

Inputs

When the duplicate flagging or resolution process is triggered, the triggering message is provided as input to the

duplicate process.


CDLIS Central Site to the SOR:

o If possible duplicate records are found, Possible Duplicate Notifications, which include the MPR

information for both the initiating driver and the established driver.

o If possible duplicate records are resolved, Duplicate Resolution Notifications, which include the same

initiating driver and established driver information sent when the SORs were notified of the possible

duplicate.

CDLIS Central Site internally to the triggering transaction

o Information to add to the confirmation message the CDLIS Central Site sends back to the Initiating SOR


None.

Post-Requisites

A 96-hour countdown clock is automatically set at the CDLIS Central Site when the Possible Duplicate

Notification is sent to both SORs. If the possible duplicate is not cleared before the 96-hour period expires, the

duplications are identified in a report which is then sent by the AAMVA Operations Help Desk to the

jurisdictions for resolution.

The Initiating SOR or the Established SOR use one of the following transactions to resolve the possible duplicate

situation:

o Delete Master Pointer Record if the pointer record was established in error. See restrictions on the use of

this message in the Delete Master Pointer Record transaction section. Ref6

o Change Data if one of the key data elements was entered erroneously. Ref2

Experience has shown that a

keying error is the most likely cause for a possible duplicate. Normally, the Change Data transaction is

used to correct the identification data entered in error and will resolve most possible duplicate situations.

o Mark Driver Unique if the data is correct and examination reveals that the driver is not the same as the

possible duplicate from the other jurisdiction(s). Ref7

A SOR must positively determine that its driver was

not one of the close matches returned from the Search Inquiry before a new driver is added to CDLIS. If

this results in a duplicate, the Mark Driver Unique transaction must be initiated.

References





Reference

#


Ref1 CDLIS System

Specifications

CD07 ADD NEW DRIVER

Ref2 CDLIS System

Specifications

CD09 CHANGE DATA

Ref3 CDLIS System

Specifications


Ref4 CDLIS System

Specifications


Ref5 CDLIS System

Specifications


Ref6 CDLIS System

Specifications


Ref7 CDLIS System

Specifications








NA CDLIS Possible Duplicate 0 - 5






CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)

CDA1.1.1 Transmission / Reception

The Central Site executes the Identify Possible Duplicate Drivers (CDA1.1) process when it receives any of the

following messages:

Add Driver (UA)

Change Data (UC), if any of the following fields are present:

For all Initiating SORs regardless of the version implemented:





















Change State of Record (UD), if any of the following fields are present:

For all Initiating SORs, regardless of the version implemented:


Driver SSN Ŕ CDLIS (DDVSS6)





Update AKA Data (UK)

When executing the '





CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)' process, the Central Site submits the following

fields to the process:


Driver License Jurisdiction Number (DDLJDL) set to:

o In case of an Add Driver (UA) message: Driver License Jurisdiction Number (DDLJDL)

o In case of a Change Data (UC) message: If present, Driver License Jurisdiction Number

(DDLJDL), otherwise DL Old Jurisdiction Number (DDLJD1)

o In case of a Change State of Record (UD) message: Driver License Jurisdiction Number

(DDLJDL)

o In case of an Update AKA Data (UK) message: Driver License Old Jurisdiction Number

(DDLJD1)

Driver Date of Birth (DDVDOB) set to:

o In case of an Add Driver (UA) message: Driver Date of Birth (DDVDOB)

o In case of a Change Data (UC) message: If present, Driver Date of Birth (DDVDOB), otherwise


o In case of a Change State of Record (UD) message: If present, Driver Date of Birth (DDVDOB),

otherwise Driver Old Date of Birth (DDVDO1)

o In case of an Update AKA Data (UK) message: Driver Old Date of Birth (DDVDO1)

Driver SSN - CDLIS (DDVSS6) set to:

o In case of an Add Driver (UA) message: Driver SSN - CDLIS (DDVSS6)

o In case of a Change Data (UC) message: If present, Driver SSN - CDLIS (DDVSS6), otherwise


o In case of a Change State of Record (UD) message: If present, Driver SSN - CDLIS (DDVSS6),

otherwise Driver Old Social Security Number (DDVSS1)

o In case of an Update AKA Data (UK) message: Driver Old Social Security Number (DDVSS1)



Person Name Group (BPENGP) set to:

o In case of an Add Driver (UA) message: Person Name Group (BPENGP)

o In case of a Change Data (UC) message: If present, Person Old Name Group (BPENG1),

otherwise Person Name Group (BPENGP)

o In case of a Change State of Record (UD) message: If present, Person Old Name Group

(BPENG1), otherwise Person Name Group (BPENGP)

o In case of an Update AKA Data (UK) message: Person Old Name Group (BPENG1)


Person Name Group (BPENGP), set to the following, as converted into the format specified in "link to

Appendix D.3":

o In case of an Add Driver (UA) message: Driver Name (DDVNAM)

o In case of a Change Data (UC) message: If present, Driver Name (DDVNAM), otherwise Driver

Old Name (DDVNM1)

o In case of a Change State of Record (UD) message: If present, Driver Name (DDVNAM),

otherwise Driver Old Name (DDVNM1)

o In case of an Update AKA Data (UK) message: Driver Old Name (DDVNM1)


o In case of an Add Driver (UA) message: Driver Current Sex (DDVSX3)

o In case of a Change Data (UC) message: If present, Driver Current Sex (DDVSX3), otherwise the






o In case of a Change State of Record (UD) message: If present, Driver Current Sex (DDVSX3),

otherwise the CD20 Driver Sex (DDVSEX)

o In case of an Update AKA Data (UK) message: CD20 Driver Sex (DDVSEX)

CDA1.1.2 Retrieval

Using the following data passed to the





CDA1.1 Identify Possible Duplicate Drivers (CDLIS Central Site)' process:




The Central Site performs the following search routines on the Master Pointer (CD20) data store.

CDA1.1.2.1 SSN Search

If the Driver SSN - CDLIS (DDVSS6) passed to this process is not all 9s, perform the following searches:

CDA1.1.2.1.1 Exact SSN Search


Access the Master Pointer (CD20) data store by Driver Social Security Number (DDVSSN) using Driver SSN Ŕ

CDLIS (DDVSS6)

For each CD20 record found (a 'found record'), retrieve any associated Duplicate Pointer (CD23) records. A found

record is not considered a possible duplicate record if it has already been marked as an acceptable duplicate for the

initiating record, i.e. if all of the following are true:

One of the associated CD23 records represents the initiating record

The associated CD23 record (representing the initiating record) has a Master Pointer Unique Indicator

(DCDPUI) equal to 'U' (marked unique)

The initiating record has an associated CD23 record that represents the found record, which CD23 record has a

Master Pointer Unique Indicator (DCDPUI) equal to 'U' (marked unique)

The remaining found records are considered possible duplicate records ('established records').

Note: An exact SSN search is not performed for those Initiating SORs at version 5.1 or greater.

CDA1.1.2.1.2 'Similar SSN' Search

This search has as goal to identify SSNs that are similar enough (created for example by mistyping, misreading or

switching digits) that they could represent the same SSN.


Access the Master Pointer (CD20) data store by Person SSN Last 5 Digits (BPESSD) using:

o the last 5 positions of numbers similar to Driver SSN Ŕ CDLIS (DDVSS6), and

o the last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6)


Access the Master Pointer (CD20) data store by Driver Social Security Number (DDVSSN) using 9-digit

numbers similar to Driver SSN Ŕ CDLIS (DDVSS6)

Detailed information on how 'similar' numbers are created is not provided due to its proprietary nature, but may be

obtained by authorized parties on a Řneed to knowř basis by contacting AAMVA.

Once the 'Similar SSN' search is complete, compare the Person Name Group (BPENGP) and Driver Date of Birth

(DDVDOB) passed to this process with those on each retrieved record. Retain the record as a match only if both fields

match exactly or pass the ŘSimilar Primary Name-DOBř algorithm used in ŖCDA1.1.2.2.2 ŘSimilar Primary

Name/DOBř Searchŗ.

Transitional note:

"Exact matches" on name fields take into account that a name converted from the format described in Appendix

D.2 to the format described in Appendix D.3 may be slightly different from the same name captured (from

source documents) in accordance with the format described in Appendix D.3.














CDA1.1.2.2 Primary Name/DOB Search

If the Driver SSN - CDLIS (DDVSS6) passed to this process is all 9s, perform the following searches:

CDA1.1.2.2.1 Exact Primary Name/DOB Search

Access the Master Pointer (CD20) data store by the following fields passed to this process:


Person Date of Birth (BPEDOB) using the Driver Date of Birth (DDVDOB)

Transitional note:

"Exact matches" on name fields take into account that a name converted from the format described in Appendix

D.2 to the format described in Appendix D.3 may be slightly different from the same name captured (from

source documents) in accordance with the format described in Appendix D.3.










CDA1.1.2.2.2 ‘Similar Primary Name/DOB’ Search

This search has as goal to identify Name/DOB combinations that are likely to be for the same person even though the

combinations are not exactly the same.

Access the Master Pointer (CD20) data store by the following fields:

Person Name Group (BPENGP) using name information that is similar to the Person Name Group (BPENGP)

passed to this process

Person Date of Birth (BPEDOB) using DOBs that are similar to the Driver Date of Birth (DDVDOB) passed to

this process

Detailed information on how 'similar' name information and DOBs are created is not provided due to its proprietary

nature, but may be obtained by authorized parties on a Řneed to knowř basis by contacting AAMVA.














CDA1.1.3 Updates

For each established record, add a new record to the Duplicate Pointer (CD23) data store, if the CD23 is not already

there:

Set the CD23 Duplicate Licensing Jurisdiction Code (DDLJU6) using the retrieved CD20 Jurisdiction Code -

Licensing (DDLJUR) of the initiating record

Set the CD23 Duplicate Driver License Number (DDLNU5) using the retrieved CD20 Driver License Number

(DDLNUM) of the initiating record

For the initiating record, add a new record to the Duplicate Pointer (CD23) data store for each established record, if the

CD23 is not already there:

Set the CD23 Duplicate Licensing Jurisdiction Code (DDLJU6) using the retrieved CD20 Jurisdiction Code -

Licensing (DDLJUR) of the established record

Set the CD23 Duplicate Driver License Number (DDLNU5) using the retrieved CD20 Driver License Number

(DDLNUM) of the established record

Set other fields on the new Duplicate Pointer (CD23) records as follows:

Master Pointer Unique Indicator (DCDPUI) set to ŘDř (possible duplicate)





CDA1.1.4 Transmission

CDA1.1.4.1 Transmission of CDLIS Possible Duplicate (NA) Message

The CDLIS Central Site creates and sends CDLIS Possible Duplicate (NA) messages to the following jurisdictions:

The Initiating SOR, identified by positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) passed to

this process

The Established SORs, identified by the Duplicate Licensing Jurisdiction Code (DDLJU6) on each established

record

Two CDLIS Possible Duplicate (NA) messages are sent for each pair of possibly matching records Ŕ one to the

Initiating SOR, and one to the Established SOR.

For example, if Driver A is added in AL and A is a possible duplicate of Driver B in NE, Driver C in CA and Driver D

in CA, the following NA messages are sent:

to AL, with Driver A and duplicate Driver B

to AL, with Driver A and duplicate Driver C

to AL, with Driver A and duplicate Driver D

to NE, with Driver B and duplicate Driver A

to CA, with Driver C and duplicate Driver A

to CA, with Driver D and duplicate Driver A

The CDLIS Central Site does not send more than 5 CDLIS Possible Duplicate (NA) messages to any jurisdiction. If

more than 5 CDLIS Possible Duplicate (NA) messages are identified for the Initiating SOR, CDLIS Possible Duplicate

(NA) messages are only sent only for the first 5 identified.





The CDLIS Possible Duplicate (NA) message includes:

Message Match Count (GMSCNT) set to the number of CDLIS Possible Duplicate (NA) messages being sent to

the jurisdiction (up to 5)


Message Match Sequence ID (GMSMSI) set to the number representing the order in which the matching drivers

were found ('00' Ŕ '05')


Last Match Indicator (GMSLMI) set to 'Y' if this is the last CDLIS Possible Duplicate (NA) message being sent

(i.e. for the CDLIS Possible Duplicate (NA) message with the highest Message Match Sequence ID (GMSMSI));

'N' otherwise

Jurisdiction Code - State of Record (GMSSOR) set to the CD20 Jurisdiction Code - Licensing (DDLJUR) of the

Established SOR of the possible pair of duplicate drivers to which the CDLIS Possible Duplicate (NA) message

pertains

Message Match Limit Exceeded Indicator (GMSLEI) set to 'N' if all possible duplicates are being sent; 'Y'

otherwise

Message SOR Change In Progress Indicator (GMSSCH) set to 'N'

Message Driver Duplicate Indicator (GMSDUP) set to ŘYř

The CDLIS Possible Duplicate (NA) message sent to the Initiating SOR also includes:


Message Destination (GMSDST) set to the first two positions of the Driver License Jurisdiction Number

(DDLJDL) passed to this process (i.e. of the initiating driver)

Message Locator/Header (GMSLOC), set to the set to the Message Locator (GMSLOC) passed to this

process; this allows the Initiating SOR to match the associated transaction with the CDLIS Possible

Duplicate (NA) message received

Driver License Duplicate Jurisdiction Number (DDLJD5) set to the CD20 Driver License Jurisdiction

Number (DDLJDL) of the established driver

Driver License Jurisdiction Number (DDLJDL) set to the Driver License Jurisdiction Number (DDLJDL)

passed to this process (i.e. of the initiating driver)

Driver Duplicate Date of Birth (DDVDO2) set to the CD20 Driver Date of Birth (DDVDOB) of the

established driver

Driver Date of Birth (DDVDOB) set to the Driver Date of Birth (DDVDOB) passed to this process (i.e. of

the initiating driver)


Person Duplicate Name Group (BPENG2) set to the CD20 Person Name Group (BPENGP) of the

established driver

Person Name Group (BPENGP) set to the Person Name Group (BPENGP) passed to this process (i.e. of


The last 5 positions of Duplicating Driver SSN (DDVSS2) set to the CD20 Person SSN Last 5 Digits

(BPESSD)The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) set to the last 5 digits of the Driver

SSN Ŕ CDLIS (DDVSS6) passed to this process (i.e. of the initiating driver)


Driver Duplicate Name (DDVNM3) set to the CD20 Person Name Group (BPENGP) of the established

driver as converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON NAME

FORMATTING RULES"

Driver Name (DDVNAM) set to the Person Name Group (BPENGP) passed to this process (i.e. of the

initiating driver) converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON NAME

FORMATTING RULES"





Driver Duplicate Sex (DDVSX2) set to the CD20 Driver Sex (DDVSEX) of the established driver

Driver Current Sex (DDVSX3) set to the Driver Sex (DDVSX3) passed to this process (i.e. of the

initiating driver)

Duplicating Driver SSN (DDVSS2) set to the CD20 Driver Social Security Number (DDVSSN) of the

established driver

Driver SSN - CDLIS (DDVSS6) set to the Driver SSN - CDLIS (DDVSS6) passed to this process (i.e. of


The CDLIS Possible Duplicate (NA) message sent to an Established SOR also includes:


Message Destination (GMSDST) set to the first two positions of the CD20 Driver License Jurisdiction


Message Locator/Header (GMSLOC), set to the set to ŘCDLIS ř in the first and last 6 positions, with the

intervening positions blank (i.e. ŘCDLIS CDLISř with 16 spaces in between)

Driver License Duplicate Jurisdiction Number (DDLJD5) set to the Driver License Jurisdiction Number


Driver License Jurisdiction Number (DDLJDL) set to the CD20 Driver License Jurisdiction Number

(DDLJDL) of the established driver

Driver Duplicate Date of Birth (DDVDO2) set to the Driver Date of Birth (DDVDOB) passed to this

process (i.e. of the initiating driver)

Driver Date of Birth (DDVDOB) set to the CD20 Driver Date of Birth (DDVDOB) of the established

driver


Person Name Group (BPENGP) set to the CD20 Person Name Group (BPENGP) of the established driver

Person Duplicate Name Group (BPENG2) set to the Person Name Group (BPENGP) passed to this


The last 5 positions of Duplicating Driver SSN (DDVSS2) set to the last 5 digits of the Driver SSN Ŕ

CDLIS (DDVSS6) passed to this process (i.e. of the initiating driver)

The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) set to the CD20 Person SSN last 5 Digits

(BPESSD) of the established driver


Driver Duplicate Name (DDVNM3) set to the Person Name Group (BPENGP) passed to this process (i.e.

of the initiating driver) converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON

NAME FORMATTING RULES"

Driver Name (DDVNAM) set to the CD20 Person Name Group (BPENGP) of the established driver as

converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING

RULES"

Driver Duplicate Sex (DDVSX2) set to the Driver Sex (DDVSX3) passed to this process (i.e. of the

initiating driver)

Driver Current Sex (DDVSX3) set to the CD20 Driver Sex (DDVSEX) of the established driver

Duplicating Driver SSN (DDVSS2) set to the Driver SSN - CDLIS (DDVSS6) passed to this process (i.e.

of the initiating driver)

Driver SSN - CDLIS (DDVSS6) set to the CD20 Driver Social Security Number (DDVSSN) of the

established driver)






values.

Notes:

When CDLIS Possible Duplicate (NA) messages are sent, the Initiating SOR (in consultation with the Established SOR)

is responsible for ensuring resolution (see "CDA1.3 Process Resolved Duplicates (CDLIS Central Site)").

CDA1.1.4.2 Transmission of Information to Initiating Process

The Central Site passes the following information back to the initiating process for inclusion in the confirmation

message:

Number of Duplicate Drivers Identified set to the number of established records possibly duplicating the

initiating record (up to a maximum of 5)

First Dup CSOR Indicator set to the Message SOR Change in Progress Indicator (GMSSCH) of the Master

Pointer (CD20) record for the first established driver being reported

First Dup SOR set to the Jurisdiction Code - Licensing (DDLJUR) of the Master Pointer (CD20) record for the

first established driver being reported

CDA1.2 Process Duplicate Notification (Initiating and Established State(s) of Record (SOR))

CDA1.2.1 Introduction

The CDLIS Central Site notifies all SOR(s) when duplicates have been created.

Upon receipt of notification that a possible duplicate driver exists, one or both of the SORs must submit transactions to

resolve the situation.

CDLIS transactions that may be used to resolve possible duplicates are:

Delete Master Pointer Record (see "CD10 DELETE MASTER POINTER RECORD") if the pointer record was

established in error. See restrictions on the use of this message in "CD10 DELETE MASTER POINTER

RECORD".

Change Data (see "CD09 CHANGE DATA") if one of the key data elements was entered erroneously. A keying

error is the most likely cause for a possible duplicate. Normally, the Change Data transaction is used to correct

the identification data entered in error and will resolve most possible duplicate situations.

Mark Driver Unique (see "CD14 MARK DRIVER UNIQUE") if the data is correct and examination reveals that

the driver is not the same as the possible duplicate from the other jurisdiction(s)

Details of these messages can be found in the sections that describe the specific transactions.

CDA1.2.2 Reception of CDLIS Possible Duplicate (NA) Message

The CDLIS Central Site sends CDLIS Possible Duplicate (NA) messages to the Initiating SOR and to the Established

SOR.

The CDLIS Possible Duplicate (NA) message includes:

Message Destination (GMSDST)















Driver License Duplicate Jurisdiction Number (DDLJD5)


Person Duplicate Name Group (BPENG2)


The last 5 positions of Duplicating Driver SSN (DDVSS2)



blocks.

Notes:

For each CDLIS Possible Duplicate (NA) message received by a SOR, a similar CDLIS Possible Duplicate (NA)

message pertaining to the same set of possibly duplicating driver records is received by another SOR. Data

elements marked as "Duplicate" reflect information pertaining to the other SOR's record.

If the SOR that receives the CDLIS Possible Duplicate (NA) message is the Initiating SOR, the Message Locator

(GMSLOC) is set to the locator on the original message that resulted in the CDLIS Possible Duplicate (NA)

message. If the SOR that receives the CDLIS Possible Duplicate (NA) message is an Established SOR, the

Message Locator (GMSLOC) is set to ŘCDLIS ř in the first and last 6 positions, with the intervening positions

blank (i.e. ŘCDLIS CDLISř with 16 spaces in between)

The Message Match Sequence ID (GMSMSI) and related fields (Last Match Indicator (GMSLMI) and Message

Match Limit Exceeded Indicator (GMSLEI)) pertain to the total number of possible duplicates identified.

Because Established SORs only receive CDLIS Possible Duplicate (NA) messages pertaining to them, these

fields are intended for use by the Initiating SOR.

CDA1.2.3 Transmission of CDLIS Possible Duplicate (NA) Message with Errors

In rare circumstances, a SOR will have an MPR for a driver for whom it no longer maintains a driver history (a 'broken

pointer'). In this case, the SOR will not be able to locate the driver on its database and will reject the CDLIS Possible

Duplicate (NA) message. If the CDLIS Possible Duplicate (NA) message is rejected by a SOR, it should be returned to

the CDLIS Central Site exactly as received with the following exceptions:







The SOR must determine why the broken pointer condition exists and resolve the situation within 96 hours of returning

the associated error. The AAMVA Operations Help Desk will provide all assistance possible and should be kept

informed of the progress.

CDA1.3 Process Resolved Duplicates (CDLIS Central Site)

CDA1.3.1 Reception

The Central Site executes the "CDA1.3 Process Resolved Duplicates (CDLIS Central Site)" process when it receives

any of the following messages:





Change Data (UC), if any of the following fields are present:

For all Initiating SORs regardless of the version implemented:











Delete Master Pointer Record (UE)

Mark Unique (UG)

When executing the "CDA1.3 Process Resolved Duplicates (CDLIS Central Site)" process, the Central Site submits the

following fields to the process:


Driver License Jurisdiction Number (DDLJDL) set to:

o In case of a Change Data (UC) message: If present, Driver License Jurisdiction Number

(DDLJDL), otherwise DL Old Jurisdiction Number (DDLJD1)

o In case of a Delete Master Pointer Record (UE) message: Driver License Jurisdiction Number

(DDLJDL)

o In case of a Mark Unique (UG) message: Driver License Jurisdiction Number (DDLJDL)

Driver Date of Birth (DDVDOB) set to:

o In case of a Change Data (UC) message: If present, Driver Date of Birth (DDVDOB), otherwise


o In case of a Delete Master Pointer Record (UE) message: Driver Date of Birth (DDVDOB)

o In case of a Mark Unique (UG) message: Driver Date of Birth (DDVDOB)

Driver SSN - CDLIS (DDVSS6) set to:

o In case of a Change Data (UC) message: If present, Driver SSN - CDLIS (DDVSS6), otherwise


o In case of a Delete Master Pointer Record (UE) message: Driver SSN - CDLIS (DDVSS6)

o In case of a Mark Unique (UG) message: Driver SSN - CDLIS (DDVSS6)



Person Name Group (BPENGP) set to:

o In case of a Change Data (UC) message: If present, Person Old Name Group (BPENG1),

otherwise Person Name Group (BPENGP)

o In case of a Delete Master Pointer Record (UE) message: Person Name Group (BPENGP)

o In case of a Mark Unique (UG) message: Person Name Group (BPENGP)


Person Name Group (BPENGP), set to the following, as converted into the format specified in "link to

Appendix D.3":

o In case of a Change Data (UC) message: If present, Driver Name (DDVNAM), otherwise Driver





Old Name (DDVNM1)

o In case of a Delete Master Pointer Record (UE) message: Driver Name (DDVNAM)

o In case of a Mark Unique (UG) message: Driver Name (DDVNAM)

Driver Sex (DDVSX3)

o In case of a Change Data (UC) message: If present, Driver Current Sex (DDVSX3), otherwise the


o In case of a Delete Master Pointer Record (UE) message: If present, Driver Current Sex

(DDVSX3), otherwise the CD20 Driver Sex (DDVSEX)

o In case of a Mark Unique (UG) message: CD20 Driver Sex (DDVSEX)

In case of a Change Data (UC) message, perform "CDA1.3.2 Retrieval", "CDA1.3.3 Duplicate Verification Process",

"CDA1.3.4 Updates" and "CDA1.3.5 Transmission".

In case of a Delete Master Pointer Record (UE) message, perform "CDA1.3.4 Updates", and "CDA1.3.5

Transmission" if called by "CDA1.3.4 Updates".

In case of a Mark Unique (UG) message, perform "CDA1.3.4 Updates", and "CDA1.3.5 Transmission" if called by

"CDA1.3.4 Updates".

CDA1.3.2 Retrieval

Access the Master Pointer (CD20) data store by Driver License Jurisdiction Number (DDLJDL) using the Driver

License Jurisdiction Number (DDLJDL) passed to this process (i.e. of the initiating driver). Retrieve any associated

Duplicate Pointer (CD23) records where the Master Pointer Unique Indicator (DCDPUI) equals 'D' (Possible

Duplicate). For each Duplicate Pointer (CD23) record, retrieve the corresponding record (the 'established record') from

the Master Pointer (CD20) data store by Driver License Jurisdiction Number (DDLJDL) using the concatenation of the

CD23 Duplicate Licensing Jurisdiction Code (DDLJU6) and CD23 Duplicate Driver License Number (DDLNU5).

For each established record, submit the following information to the "CDA1.3.3 Duplicate Verification Process"

process:

For the initiating record:


CD20 Person Name Group (BPENGP)

CD20 Person Date of Birth (BPEDOB)

Driver SSN - CDLIS (DDVSS6) passed to this process (i.e. of the initiating driver)

For those Initiating SORs at version older than 5.1:

CD20 Driver Social Security Number (DDVSSN)


CD20 Person SSN Last 5 Digits (BPESSD)

For the established record:


CD20 Person Name Group (BPENGP)

CD20 Person Date of Birth (BPEDOB)

For those Initiating SORs at version older than 5.1:

CD20 Driver Social Security Number (DDVSSN)


CD20 Person SSN Last 5 Digits (BPESSD)





CDA1.3.3 Duplicate Verification Process

CDA1.3.3.1 SSN Verification

If the Driver SSN - CDLIS (DDVSS6) for the initiating record is not all 9s, perform the following verifications:

CDA1.3.3.1.1 Exact SSN verification


If the Driver Social Security Number (DDVSSN) for the initiating record does not equal the Driver Social

Security Number (DDVSSN) for the established record, the record pair submitted to this process passes the

verification.

CDA1.3.3.1.2 Similar SSN verification


If the Person SSN Last 5 Digits (BPESSD) for the initiating record is not similar to the Person SSN Last 5 Digits

(BPESSD) for the established record, and if the Person SSN Last 5 Digits (BPESSD) for the initiating record

does not equal the Person SSN Last 5 Digits (BPESSD) for the established record, the record pair submitted to

this process passes the verification.


If the Driver Social Security Number (DDVSSN) for the initiating record is not similar to the Driver Social

Security Number (DDVSSN) for the established record, the record pair submitted to this process passes the

verification.

Detailed information on when numbers are considered to be 'similar' is not provided due to its proprietary nature, but

may be obtained by authorized parties on a Řneed to knowř basis by contacting AAMVA.

If the above comparison does not indicate that the initiating record is dissimilar from the established record, compare

the Person Name Group (BPENGP) and Driver Date of Birth (DDVDOB) for each record passed to this process. If any

of these fields do not match, the record pair submitted to this process passes the verification.

Transitional note:

Comparisons on name fields take into account that a name converted from the format described in Appendix D.2

to the format described in Appendix D.3 may be slightly different from the same name captured (from source

documents) in accordance with the format described in Appendix D.3.

If the above comparison does not indicate that the initiating record is dissimilar from the established record, compare

the Person Name Group (BPENGP) and Driver Date of Birth (DDVDOB) for each record passed to this process using

the 'Similar Primary Name-DOB' algorithm described in "CDA1.3.3.2.2 'Similar Primary Name/DOB' Verification". If

the two records are not considered a match, the record pair submitted to this process passes the verification.

CDA1.3.3.2 Primary Name/DOB Verification

If the Driver SSN - CDLIS (DDVSS6) for the initiating record is not all 9s, perform the following verifications:

CDA1.3.3.2.1 Exact Primary Name/DOB Verification

If the Person Name Group (BPENGP) for the initiating record does not equal the Person Name Group (BPENGP) for

the established record, or if the Person Date of Birth (BPEDOB) for the initiating record does not equal the Person Date

of Birth (BPEDOB) for the established record, the record pair submitted to this process passes the verification.

CDA1.3.3.2.2 'Similar Primary Name/DOB' Verification

If the Person Name Group (BPENGP) for the initiating record is not similar to the Person Name Group (BPENGP) for

the established record, or if the Person Date of Birth (BPEDOB) for the initiating record is not similar to the Person

Date of Birth (BPEDOB) for the established record, the record pair submitted to this process passes the verification.

Detailed information on when fields are considered to be 'similar' is not provided due to its proprietary nature, but may





be obtained by authorized parties on a Řneed to knowř basis by contacting AAMVA.

CDA1.3.4 Updates

CDA1.3.4.1 Updates in case of a Change Data (UC) Message

For each pair of records identified in "CDA1.3.2 Retrieval" that passes all the verifications in "CDA1.3.3 Duplicate

Verification Process":


License Jurisdiction Number (DDLJDL) of the initiating record. Delete the associated Duplicate Pointer (CD23)

record for which the concatenation of the CD23 Duplicate Licensing Jurisdiction Code (DDLJU6) and CD23

Duplicate Driver License Number (DDLNU5) equals the Driver License Jurisdiction Number (DDLJDL) of the

established record.


License Jurisdiction Number (DDLJDL) of the established record. Delete the associated Duplicate Pointer

(CD23) record for which the concatenation of the CD23 Duplicate Licensing Jurisdiction Code (DDLJU6) and

CD23 Duplicate Driver License Number (DDLNU5) equals the Driver License Jurisdiction Number (DDLJDL)

of the initiating record.

CDA1.3.4.2 Updates in case of a Delete Master Pointer Record (UE) Message


License Jurisdiction Number (DDLJDL) passed to this process (i.e. of the initiating driver). Retrieve all associated

Duplicate Pointer (CD23) records.

For each Duplicate Pointer (CD23) record, retrieve the corresponding record (the 'established record') from the Master

Pointer (CD20) data store by Driver License Jurisdiction Number (DDLJDL) using the concatenation of the CD23

Duplicate Licensing Jurisdiction Code (DDLJU6) and CD23 Duplicate Driver License Number (DDLNU5).

For each established record, delete the Duplicate Pointer (CD23) where the concatenation of the CD23 Duplicate

Licensing Jurisdiction Code (DDLJU6) and CD23 Duplicate Driver License Number (DDLNU5) is equal to the Driver

License Jurisdiction Number (DDLJDL) passed to this process (i.e. of the initiating driver).

Delete all Duplicate Pointer (CD23) records associated with the initiating driver.

Perform "CDA1.3.5 Transmission" for each Duplicate Pointer (CD23) record deleted where the Master Pointer Unique

Indicator (DCDPUI) was not set to 'U' (Mark Unique Completed).

CDA1.3.4.3 Updates in case of a Mark Driver Unique (UG) Message


License Jurisdiction Number (DDLJDL) of the initiating driver. Retrieve the Duplicate Pointer (CD23) record for the

established driver using Driver License Jurisdiction Number (DDLJDL).


License Jurisdiction Number (DDLJDL) of the established driver. Retrieve the Duplicate Pointer (CD23) record for the

initiating driver using Driver License Jurisdiction Number (DDLJDL).

For both Duplicate Pointer (CD23) records:

If the Master Pointer Unique Indicator (DCDPUI) equals 'D' (Possible Duplicate), set the Master Pointer Unique

Indicator (DCDPUI) to 'P' (Mark Unique Pending).

If the Master Pointer Unique Indicator (DCDPUI) equals 'P' (Mark Unique Pending):

o Set the Master Pointer Unique Indicator (DCDPUI) to 'U' (Mark Unique Completed).

o Perform "CDA1.3.5 Transmission".





CDA1.3.5 Transmission

CDA1.3.5.1 Transmission of Duplicate Resolved (NE) Message

For each pair of drivers for whom the duplicate status has been resolved, the CDLIS Central Site will send a Duplicate

Resolved (NE) message to the SOR for each driver involved. Although this does not have to occur in real time, it does

occur at least before the start of the next working day.

The Duplicate Resolved (NE) message includes:







Message SOR Change In Progress Indicator (GMSSCH) set to 'N'

Message Driver Duplicate Indicator (GMSDUP) set to 'N' if no duplicates exist after the update; otherwise 'Y'

The Duplicate Resolved (NE) message sent to the Initiating SOR also includes:


Message Destination (GMSDST) set to the first two positions of the Driver License Jurisdiction Number


Message Locator/Header (GMSLOC), set to the Message Locator (GMSLOC) on the Initiating SOR's

message that contributed to the resolution of the duplicate

Driver License Duplicate Jurisdiction Number (DDLJD5) set to the CD20 Driver License Jurisdiction


Driver License Jurisdiction Number (DDLJDL) set to the Driver License Jurisdiction Number (DDLJDL)

passed to this process (i.e. of the initiating driver)

Driver Duplicate Date of Birth (DDVDO2) set to the CD20 Driver Date of Birth (DDVDOB) of the

established driver

Driver Date of Birth (DDVDOB) set to the Driver Date of Birth (DDVDOB) passed to this process (i.e. of



Person Duplicate Name Group (BPENG2) set to the CD20 Person Name Group (BPENGP) of the

established driver

Person Name Group (BPENGP) set to the Person Name Group (BPENGP) passed to this process (i.e. of


The last 5 positions of Duplicating Driver SSN (DDVSS2) set to the CD20 Person SSN Last 5 Digits

(BPESSD) of the established driver

The last 5 positions of Driver SSN Ŕ CDLIS (DDVSS6) set to the last 5 digits of the Driver SSN - CDLIS

(DDVSS6) passed to this process (i.e. of the initiating driver)


Driver Duplicate Name (DDVNM3) set to the CD20 Person Name Group (BPENGP) of the established

driver as converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON NAME

FORMATTING RULES"

Driver Name (DDVNAM) set to the Person Name Group (BPENGP) passed to this process (i.e. of the

initiating driver) converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON NAME

FORMATTING RULES".





Driver Duplicate Sex (DDVSX2) set to the CD20 Driver Sex (DDVSEX) of the established driver

Driver Current Sex (DDVSX3) set to the Driver Sex (DDVSX3) passed to this process (i.e. of the

initiating driver)

Duplicating Driver SSN (DDVSS2) set to the CD20 Driver Social Security Number (DDVSSN) of the

established driver

Driver SSN - CDLIS (DDVSS6) set to the Driver SSN - CDLIS (DDVSS6) passed to this process (i.e. of


The Duplicate Resolved (NE) message sent to an Established SOR also includes:


Message Destination (GMSDST) set to the first two positions of the CD20 Driver License Jurisdiction


Message Locator/Header (GMSLOC), set to the set to ŘCDLIS ř in the first and last 6 positions, with the

intervening positions blank (i.e. ŘCDLIS CDLISř with 16 spaces in between)

Driver License Duplicate Jurisdiction Number (DDLJD5) set to the Driver License Jurisdiction Number



(DDLJDL) of the established driver

Driver Duplicate Date of Birth (DDVDO2) set to the Driver Date of Birth (DDVDOB) passed to this


Driver Date of Birth (DDVDOB) set to the CD20 Driver Date of Birth (DDVDOB) of the established

driver


Person Duplicate Name Group (BPENG2) set to the Person Name Group (BPENGP) passed to this


Person Name Group (BPENGP) set to the CD20 Person Name Group (BPENGP) of the established driver

The last 5 positions of Duplicating Driver SSN (DDVSS2) set to the last 5 digits of the Driver SSN -

CDLIS (DDVSS6) passed to this process (i.e. of the initiating driver)


(BPESSD) of the established driver)


Driver Duplicate Name (DDVNM3) set to the Person Name Group (BPENGP) passed to this process (i.e.

of the initiating driver) converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON

NAME FORMATTING RULES".

Driver Name (DDVNAM) set to the CD20 Person Name Group (BPENGP) of the established driver as

converted into the format specified in "APPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING

RULES"

Driver Duplicate Sex (DDVSX2) set to the Driver Sex (DDVSX3) passed to this process (i.e. of the

initiating driver)

Driver Current Sex (DDVSX3) set to the CD20 Driver Sex (DDVSEX) of the established driver

Duplicating Driver SSN (DDVSS2) set to the Driver SSN - CDLIS (DDVSS6) passed to this process (i.e.

of the initiating driver)

Driver SSN - CDLIS (DDVSS6) set to the CD20 Driver Social Security Number (DDVSSN) of the

established driver)






values.

Transitional note

Height, weight and eye color is not stored at the CDLIS Central Site any more, and consequently is not included on any

message, including messages being sent to jurisdictions at a version older than 5.1.

CDA1.3.5.2 Transmission of Information to Initiating Process

The Central Site passes the following information back to the initiating process for inclusion in the confirmation

message:

Number of Duplicate Drivers Identified set to '01'

First Dup CSOR Indicator set to the Message SOR Change in Progress Indicator (GMSSCH) of the Master

Pointer (CD20) record for the first established driver being reported

First Dup SOR set to the Jurisdiction Code - Licensing (DDLJUR) of the Master Pointer (CD20) record for the

initiating driver





CDA1.4 Process Resolution Notification (Initiating and Established State(s) of Record (SOR))

CDA1.4.1 Introduction

The CDLIS Central Site notifies all SORs when duplicates have been resolved.

No action is required upon receipt of a Duplicate Resolved (NE) message.

CDA1.4.2 Reception of Duplicate Resolved (NE) Message

The CDLIS Central Site sends Duplicate Resolved (NE) messages to the Initiating SOR and to the Established SOR.

The Duplicate Resolved (NE) message includes:

Message Destination (GMSDST)










Driver License Duplicate Jurisdiction Number (DDLJD5)




The last 5 positions of Duplicating Driver SSN (DDVSS2)



blocks.

Notes:

For each Duplicate Resolved (NE) message received by a SOR, a similar Duplicate Resolved (NE) message

pertaining to the same set of resolved driver records is received by another SOR. Data elements marked as

"Duplicate" reflect information pertaining to the other SOR's record.

If the SOR that receives the Duplicate Resolved (NE) message is the Initiating SOR, the Message Locator

(GMSLOC) is set to the Message Locator (GMSLOC) on the Initiating SOR's message that contributed to the

resolution of the duplicate. If the SOR that receives the Duplicate Resolved (NE) message is an Established

SOR, the Message Locator (GMSLOC) is set to ŘCDLIS ř in the first and last 6 positions, with the intervening

positions blank (i.e. ŘCDLIS CDLISř with 16 spaces in between)

CDA1.4.3 Transmission of Duplicate Resolved (NE) Message with Errors

In rare circumstances, a SOR will have an MPR for a driver for whom it no longer maintains a driver history (a 'broken

pointer'). In this case, the SOR will not be able to locate the driver on its database and will reject the Duplicate

Resolved (NE) message. If the Duplicate Resolved (NE) message is rejected by a SOR, it should be returned to the

CDLIS Central Site exactly as received with the following exceptions:











The SOR must determine why the broken pointer condition exists and resolve the situation within 96 hours of returning

the associated error. The AAMVA Operations Help Desk will provide all assistance possible and should be kept

informed of the progress.



CDB1 PROCESS STATUS RECEIVED (STATE OF INQUIRY (SOI))



CDB1.1 Introduction

Once a "CD01 SEARCH INQUIRY", "CD02 VERIFICATION INQUIRY", or "CD05 AKA DATA INQUIRY" is

processed by the CDLIS Central Site and the State(s) of Record (SOR(s)), the State of Inquiry (SOI) receives response.

After a "CD01 SEARCH INQUIRY" or "CD05 AKA DATA INQUIRY", the SOI receives:

A Number of Status Responses from Inquiry (RC) message from the CDLIS Central Site

0-15 MPR Data for Match in Inquiry Transaction (RD) messages from the CDLIS Central Site

If one, and only one, match was found by the CDLIS Central Site, the SOI (if not the SOR) will receive from the

SOR;

o A Status Response (HC) message

o A Permit Restrictions (H6) message if the driver has at least one permit restriction, as indicated on the

Status Response (HC)

Note: If the SOI is the SOR for the only matching driver, the Status Request (SC) message will not be sent by the

Central Site (see "CD01.2 Research Driver (CDLIS Central Site)" and "CD05.2 Research Driver for AKA Data

(CDLIS Central Site)") and no Status Response (HC) or Permit Restrictions (H6) message will be received.

After a "CD02 VERIFICATION INQUIRY", the SOI receives:

A Number of Status Responses from Inquiry (RC) message from the CDLIS Central Site

0-5 MPR Data for Match in Inquiry Transaction (RD) messages from the CDLIS Central Site

The SOI (if not the SOR) will receive from the SOR

o 0-5 Status Response (HC) message(s)

o A Permit Restrictions (H6) message for each Status Response (HC) if the driver has at least one permit

restriction, as indicated on the Status Response (HC)




Social Security Number) matches. The SOI may also consider secondary driver identifying data, such as Sex, Height,


Note: If the SOI is the SOR for any of the matching drivers, the Status Request (SC) message will not be sent by the

Central Site (see "CD02.2 Verify Driver (CDLIS Central Site)") and no Status Response (HC) or Permit Restrictions

(H6) message will be received for that driver.

CDB1.2 Reception

CDB1.2.1 Reception of the Number of Status Responses from Inquiry (RC) Message

The Number of Status Responses from Inquiry (RC) message includes:







Message Match Limit Exceeded (GMSLEI)*






* If more than the maximum number of matches are found, CDLIS Central Site sets the Message Match Limit

Exceeded flag to 'Y' indicating more than the maximum matches exist. Only the first 15 matches for a Search Inquiry or

5 for a Verification Inquiry are sent.




State of Record (BJUCD1)*


* The State of Record (BJUCD1) includes a state code corresponding to each of the drivers being returned as a match,

without regard to duplications (i.e., if two records with New Hampshire as the SOR are being returned, 'NH' will appear

twice).

Upon receipt of the Number of Status Responses from Inquiry (RC) message, the SOI should check the Message Match

Count (GMSCNT):

For a Search Inquiry (CD01) or AKA Inquiry (CD05):

If Message Match Count (GMSCNT) equal to 0, no matches were found in the Master Pointer (CD20)

data store. No other messages will follow.

If Message Match Count (GMSCNT) equal to 1, the SOI can expect to receive:

o One MPR Data for Match in Inquiry Transaction (RD) message from the CDLIS Central Site

o If the SOI is not the SOR, the SOI will receive the following two messages (see Note below)

One Status Response (HC) message from the SOR

One Permit Restrictions (H6) if the driver has at least one permit restriction, as indicated on

the Status Response (HC) from the SOR

If Message Match Count (GMSCNT) greater than 1 but less than 15, the SOI can expect the number of

MPR Data for Match in Inquiry Transaction (RD) messages indicated by Message Match Count

(GMSCNT) from the CDLIS central site.

If Message Match Count (GMSCNT) equal to 15, the SOI can expect exactly 15 MPR Data for Match in

Inquiry Transaction (RD) messages. The Message Match Limit (GLSLEI) flag will be set to 'Y' if more

than 15 matches were found. This indicates more than 15 matches were found but MPR Data for Match in

Inquiry Transaction (RD) messages for only the first 15 are being sent.

Note: If the SOI is the SOR for the matching driver, the Status Request (SC) message will not be sent by the

Central Site (see "CD01.2 Research Driver (CDLIS Central Site)" and "CD05.2 Research Driver for AKA Data

(CDLIS Central Site)") and no Status Response (HC) or Permit Restrictions (H6) message will be received for

that driver.

For a Verification Inquiry (CD02):

If Message Match Count (GMSCNT) equal to 0, no matches were found in the Master Pointer(CD20)

data store. No other messages will follow.

If Message Match Count (GMSCNT) greater than 1 but less than 5, the SOI can expect to receive:

o The number of MPR Data for Match in Inquiry Transaction (RD) messages indicated by Message

Match Count (GMSCNT) from the CDLIS Central Site

o Up to the number indicated by Message Match Count (GMSCNT) of

Status Response (HC) message from the SOR (see Notes below)

Permit Restrictions (H6) message if the driver has at least one permit restriction, as

indicated on the Status Response (HC) from the SOR (see Note below)

If equal to 5, the SOI can expect to receive:

o Exactly 5 MPR Data for Match in Inquiry Transaction (RD) messages from the CDLIS Central

Site. The Message Match Limit (GMSLEI) flag will be set to 'Y' if more than 5 matches were

found. This indicates more than 5 matches were found but MPR Data for Match in Inquiry





Transaction (RD) messages for only the first 5 are being sent.

o Up to the number indicated by Message Match Count (GMSCNT) of

Status Response (HC) message from the SOR (see Note below)

Permit Restrictions (H6) message if the driver has at least one permit restriction, as

indicated on the Status Response (HC) from the SOR (see Note below)

Note: If the SOI is the SOR for any of the matching drivers, the Status Request (SC) message will not be sent by

the Central Site (see "CD02.2 Verify Driver (CDLIS Central Site)") and no Status Response (HC) or Permit

Restrictions (H6) message will be received for that driver.

CDB1.2.2 Reception of the MPR Data for Match in Inquiry Transaction (RD) Message(s)

The MPR Data for Match in Inquiry Transaction (RD) message includes:








Message Match Limit Exceeded (GMSLEI)

Message SOR Change in Progress Indicator (GMSSCH)








Note: The AKA Count fields on the MPR Data for Match in Inquiry Transaction (RD) will reflect the number of AKAs

on the MPR whether or not any AKA values have been included on the MPR Data for Match in Inquiry Transaction

(RD).

The MPR Data for Match in Inquiry Transaction (RD) message may optionally include:







Note: If any MPR AKA field(s) matched on a Primary or AKA entry on the Search Inquiry or AKA Inquiry, the MPR

Data for Match in Inquiry Transaction (RD) will contain values for any AKA fields on the MPR.

Based on the Number of Status Responses from Inquiry (RC) message, the SOI will know the number of MPR Data for

Match in Inquiry Transaction (RD) messages to expect. State procedures will dictate whether processing begins with

receipt of the first MPR Data for Match in Inquiry Transaction (RD) or after all MPR Data for Match in Inquiry

Transaction (RD)s have been received.

Note: Because messages may not be received in the order sent, it is recommended that the Last Match Indicator





(GMSLMI) not be used to determine when all MPR Data for Match in Inquiry Transaction (RD) messages have been

received. Comparing the number of MPR Data for Match in Inquiry Transaction (RD) messages received to the

Message Match Count (GMSCNT) is a more reliable method of ensuring all messages have been received (for UNI

users, this task may be performed with the message grouping option).

CDB1.2.3 Reception of the Status Response (HC) Message

The Status Response (HC) message is used to report information on a driver located by the SOR as well as to indicate

that the driver could not be found (a 'broken pointer' situation).

Note: If the CDLIS Central Site finds more than one match on a Search Inquiry or an AKA Inquiry, the SOI will not

receive a Status Response (HC) message. The SOI will have to determine which of the drivers returned on the MPR

Data for Match in Inquiry Transaction (RD)s is the correct driver and submit a State-to-State Status Request (CD03)

message to determine the driverřs eligibility for a CDL.

The Status Response (HC) message must include the following:














If the driver was located by the SOR, the Status Response (HC) must also include the following:


Commercial Driver License Class Code (DDLCL2)

Non-Commercial Driver License Class Code (DDLCL3)





Driver License Privilege Type W/D Action Pending (DDLWDP)




Total ACD Convictions On Record (DDTTCR)


Total Accidents On Record (DDTTAR)


Total Withdrawals On Record (DDTTWR)






Note: The Total Convictions Sent (DDTTCS), Total Accidents Sent (DDTTAS), and Total Withdrawals Sent

(DDTTWS) will always be zero since no conviction, accident, or withdrawal information is sent in status responses.

If the driver was located by the SOR, the Status Response (HC) message must also include all available data on the

SORřs database for the following:

Driver AKA Date Of Birth (DDVKDB)

Driver AKA 2nd Date Of Birth (DDVKD2)

Driver AKA 3rd Date Of Birth (DDVKD3)










Driver License Permit Endorsement Code (DDLEP1)




Driver License Number or Permit Restrictions (DDLRPN)


Driver License Endorsement Code (DDLEND)

Driver License Restriction Code (DDLRSC)

Driver License Restriction End Date (DDLRSD)

Driver License Restriction Explanation (DDLRSE)




When the SOI receives a Status Response (HC) message, the SOI should

Check the NCB Error Code (GNCBER), Message Match Count (GMSCNT), Message Match Indicator

(GMSIND) , Message Match Sequence Identifier (GMSMSI) and Processing Status (GPROST) to determine if

an error has occurred. If the SOR could not locate the record (a broken pointer situation)*, the following will be

set:

o NCB Error Code (GNCBER) = 'Y'

o Message Match Count (GMSCNT) = '00'

o Message Match Indicator (GMSIND) = 'N'

o Message Match Sequence Identifier (GMSMSI) = '00'

o Processing Status Code (GPROST) = '01' (logic error)

If no error is indicated on the Status Response (HC), check the Number of Permit Restrictions (DDLRPN) to

determine if a Permit Restrictions (H6) message will follow.

If a Permit Restrictions (H6) message is expected, verify that it has been received.

*Note: The SOR must determine why the broken pointer condition exists and resolve the situation within 96 hours of

returning the associated error. The AAMVA Operations Help Desk will provide all assistance possible and should be





kept informed of the progress.

The Status Response (HC) message must contain all available data for the following Medical Certificate information:















CDB1.2.4 Reception of the Permit Restrictions (H6) Message










The Permit Restrictions (H6) message must also include all available data on the SORřs database for the following:










Note: A Permit Restrictions (H6) message will follow the Status Response (HC) if and only if the Number of

Restrictions (DDLRPN), which may occur 0 to 3 times is also greater than zero.

If no errors have occurred on the Status Response (HC) or Permit Restrictions (H6) messages, the SOI may use the

status information and permit restriction information (if applicable).





CDB1.2.5 Reception of Inquiry Messages with Errors

If errors are encountered in the original inquiry message (Search Inquiry (IM), Verification Inquiry (IN), or Inquiry for

AKA Data (IK)), the message will be returned in its original state with changes to the following elements:




When an error is encountered, processing stops. Therefore, the error conditions must be corrected and another inquiry

message transmitted.



CDC1 Assist in Error Resolution (CDLIS Central Site)


CDC1 ASSIST IN ERROR RESOLUTION (CDLIS CENTRAL SITE)

CDC1.1 Introduction

The Assist in Error Resolution (CDC1) process is performed upon receipt of a Status Request (SC) message in error.

CDC1.2 Reception

If the State of Record (SOR) is unable to locate the requested driver on its database (a Řbroken pointerř situation), it

returns the Status Request (SC) message to the Central Site in error. The AAMVA Operations Help Desk may be called

upon to assist in helping the SOR resolve the Řbroken pointerř.

CDC1.3 Updates

The CDLIS Central Site treats received Status Request (SC) message with error(s) as explained in '4.4 Confirmation

Errors'. . The CDLIS Central Site stops processing the transaction associated with the Status Request (SC) message.



CDD1 RESOLVE STATUS ERRORS (STATE OF RECORD (SOR))


CDD1 RESOLVE STATUS ERRORS (STATE OF RECORD (SOR))

CDD1.1 Introduction

This section describes how to process a status message that has been rejected due to errors. It applies to:

Status Response (HC) message used by:

o Search Inquiry (CD01)

o Verification Inquiry (CD02)

o Inquiry on AKA Data (CD05)

Status Response (HG) message used by:

o State-to-State Status Request (CD03)

Permit Restrictions (H6) message used by:

o Search Inquiry (CD01)

o Verification Inquiry (CD02)

o State-to-State Status Request (CD03)

o Inquiry on AKA Data (CD05)

If errors are encountered on the Status Response (HC) or Status Response (HG) message, the message is returned to the

originator of the message (i.e., the SOR) with the NCB Error Code (GNCBER) set to 'Y' and the error(s) identified.

If errors are encountered on the Permit Restrictions (H6) message, the jurisdiction detecting the error may:

Return the original Status Response (HC) or Status Response (HG) message with errors identified on the

message

Return the Permit Restrictions (H6) message identifying the errors (the Permit Restrictions (H6) message will

not contain the text of any errors detected)

Contact the SOR by telephone, fax, or email informing the SOR that errors were discovered on the driver status

response

Jurisdictions must have procedures in place to alert them that errors have been returned electronically.

CDD1.2 Reception

CDD1.2.1 Reception of Driver Status Response (HC/HG) Message with Errors

If errors are encountered on the Status Response (HC) or Status Response (HG) message, it is returned exactly as

transmitted with the addition of up to five error explanations in the error block.

CDD1.2.2 Reception of Permit Restrictions (H6) Message with Errors

If errors are encountered on this message and are not reflected on the Status Response (HC) or Status Response (HG)

message, the Permit Restrictions (H6) message is returned exactly as transmitted. Up to five error blocks are included.

CDD1.3 Resolution of Errors

Jurisdictions should correct any errors identified and notify the State of Inquiry that another status request can be

submitted. Status Request (SC) and State Request for Status (SG) messages cannot be resent by the AAMVA

Operations Help Desk.



CDE1 RESOLVE HISTORY ERRORS (STATE OF RECORD (SOR)/OLD SOR)



This section describes how to process a history message that has been rejected due to errors. The specifications apply to

the Driver History Response (HB) during a State-to-State History Request transaction (see "CD04 STATE-TO-STATE

HISTORY REQUEST") and the CSOR Driver History Response (HD) message during a Change State of Record

(CSOR) transaction (see "CD08 CHANGE STATE OF RECORD").

If errors are encountered on the Driver History Response (HB) or CSOR Driver History Response (HD) message, the

message is returned to the originator of the Driver History Response (HB) or CSOR Driver History Response (HD)

message (i.e., the SOR) with the errors identified.

If errors are encountered on the Driver History Permit Info (H2), Driver History Convictions (H3), Driver History

Accidents (H4), Driver History Withdrawals (H5), and/or Driver History Withdrawal-Conviction Links (H7) messages,

the jurisdiction detecting the error:

Returns the original Driver History Response (HB) or CSOR Driver History Response (HD) message with errors

identified on any of the messages

Returns the Driver History Permit Info (H2), Driver History Convictions (H3), Driver History Accidents (H4),

Driver History Withdrawals (H5) and/or Driver History Withdrawal-Conviction Links (H7) messages identifying

the errors

Contacts the SOR by telephone, fax, or email informing the SOR that errors were discovered on the Driver

History Response(s)

Jurisdictions must have procedures in place to alert them that errors have been returned electronically.

CDE1.1 Reception

CDE1.1.1 Reception of Driver History Response (HB/HD) Message with Errors

If errors are encountered on the Driver History Response (HB) or CSOR Driver History Response (HD) message, it is

returned exactly as transmitted with the addition of up to five error explanations in the error block.

CDE1.1.2 Reception of Other Driver History Response Messages in Error

If errors are encountered on any of the following messages, the message is returned exactly as transmitted with the

addition of up to five error explanations in the error block.

Driver History Permit Info (H2) Message with Error(s)

Driver History Convictions (H3) Message with Error(s)

Driver History Accidents (Driver History Accidents (H4) Message with Error(s)

Driver History Withdrawals (H5) Message with Error(s)

Driver History Withdrawal-Conviction Links (H7) Message with Error(s)

CDE1.2 Resolution of Errors

Jurisdictions must correct any errors identified as quickly as possible to ensure correct data is sent the next time the

driver history is transmitted. Correction of all the errors will also ensure a New SOR can take any necessary driver

control action.

During CSOR:

The Old SOR must be able to successfully resend the correct message electronically. If the Old SOR does not currently

have the capability of resending the Driver History (HD) and associated messages, the Old SOR must implement the

Ŗon demandŗ or automated CSOR History Request (SD) redrive or contact the AAMVA Operations Help Desk to have

the CSOR History Request (SD) message resent to the Old SOR. Both the Old and New SOR have the responsibility of

ensuring the complete driver history is successfully transferred to the New SOR within 96 hours initiation of the CSOR

transaction.





If the error condition originated from a State of Conviction (SOC) other than the Old SOR, the Old SOR is still

responsible for obtaining the corrected information from the SOC and passing it on to the New SOR electronically. If

both jurisdictions agree, they can use a different correction method.

The Old SOR must make every effort to correct the error within 96 hours of returning the associated error. If the Old

SOR does not correct the data within 96 hours, the driver will show up on the 96-hour pending report for outstanding

CSORs which is submitted to FMCSA. The AAMVA Operations Help Desk monitors this report and periodically calls

the New SORs to see if assistance is needed in resolving the outstanding CSOR. The New SOR should inform the

AAMVA Operations Help Desk caller if the record is pending correction by the Old SOR.

The jurisdiction receiving the errors does NOT confirm receipt of the history by sending a Confirm DHR

Received/Processed (CC) message until all errors are resolved.



CDF1 CREATE AKA FROM UPDATE MESSAGE (CDLIS Central Site)


CDF1 CREATE AKA FROM UPDATE MESSAGE (CDLIS CENTRAL SITE)

CDF1.1 Introduction

The CDLIS Central Site adds record(s) to the appropriate AKA Name (CD22) and/or AKA ST-DLN (CD24) data

store(s) when new AKA data is present on an update message and:

No primary name value will ever be the same as any AKA values

No primary ST-DLN value will ever be the same as the first AKA ST-DLN

No two name AKA values will be the same

No two consecutive ST-DLN AKA values will be the same

CDF1.2 Updates

CDF1.2.1 Update AKA Name (CD22)


Driver AKA 3rd Name

If the third occurrence of Person AKA Name Group (BPENG3) is present on the update message and the

value does not match any CD22 Person AKA Name Group (BPENG3) (if present) or the Person Name

Group (BPENGP) on the Master Pointer (CD20), add a new associated record to the AKA Name (CD22)

data store:

o Move the third occurrence of Person AKA Name Group (BPENG3) from the update message to

CD22 Person AKA Name Group (BPENG3)

Driver AKA 2nd Name

If the second occurrence of Person AKA Name Group (BPENG3) is present on the update message and

the value does not match any CD22 Person AKA Name Group (BPENG3) (if present) or the Person

Name Group (BPENGP) on the Master Pointer (CD20), add a new associated record to the AKA Name

(CD22) data store:

o Move the second occurrence of Person AKA Name Group (BPENG3) from the update message to


Driver AKA Name

If the first occurrence of Person AKA Name Group (BPENG3) is present on the update message and the

value does not match any CD22 Person AKA Name Group (BPENG3) (if present) or the Person Name

Group (BPENGP) on the Master Pointer (CD20), add a new associated record to the AKA Name (CD22)

data store:

o Move the first occurrence of Person AKA Name Group (BPENG3) from the update message to



Driver AKA 3rd Name

If Driver AKA 3rd Name (DDVKN3) is present on the update message and the value does not match any

CD22 Person AKA Name Group (BPENG3) (if present) as converted into the format specified in

ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ, or the Person Name Group

(BPENGP) on the Master Pointer (CD20) as converted into the format specified in ŖAPPENDIX E.1 Ŕ

AAMVA PERSON NAME FORMATTING RULESŗ, add a new associated record to the AKA Name

(CD22) data store:

o Convert the Driver AKA 3rd Name (DDVKN3) from the update message into the format specified

in "APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)" (with the transliteration

and truncation codes set to "U"), and move to CD22 Person AKA Name Group (BPENG3)





Driver AKA 2nd Name

If Driver AKA 2nd Name (DDVKN2) is present on the update message and the value does not match any





(CD22) data store:

o Convert the Driver AKA 2nd Name (DDVKN2) from the update message into the format

specified in "APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)" (with the

transliteration and truncation codes set to "U"), and move to CD22 Person AKA Name Group

(BPENG3)

Driver AKA Name

If Driver AKA Name (DDVKNM) is present on the update message and the value does not match any





(CD22) data store:

o Convert the Driver AKA Name (DDVKNM) from the update message into the format specified in

"APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)" (with the transliteration and

truncation codes set to "U"), and move to CD22 Person AKA Name Group (BPENG3)

Set other fields on each new associated AKA Name (CD22) records as follows:





Note: Each Name Pointer (CD22) record must have a unique Record Creation Date (GRCCDT) and Record Creation

Time (GRCCTM) combination, as well as a unique Date of Last Update (GRCUDT) and Time of Last Update

(GRCUTM) combination. When setting the Record Creation Time (GRCCTM) or Time of Last Update (GRCUTM), if

a duplicate date/time will be created, increment the time by one second until a unique combination is found.

CDF1.2.2 Update AKA ST-DLN (CD24)

Driver AKA 3rd ST-DLN

If AKA 3rd Driver License Jurisdiction Number (DDLJD4) is present on the update message and the value does

not match the most recent CD24 concatenated AKA Jurisdiction Code Ŕ Licensing (DDLJU2) plus AKA Driver

License Number (DDLNU1) values (if present), add a new record to the AKA ST-DLN (CD24) data store:

Move positions 1 - 2 of the AKA 3rd Driver License Jurisdiction Number (DDLJD4) from the update

message to the CD24 AKA Jurisdiction Code - Licensing (DDLJU2)

Move positions 3 - 27 of the AKA 3rd Driver License Jurisdiction Number (DDLJD4) from the update

message to the CD24 AKA Driver License Number (DDLNU1)

Driver AKA 2nd ST-DLN

If AKA 2nd Driver License Jurisdiction Number (DDLJD3) is present on the update message and the value does

not match the most recent CD24 concatenated AKA Jurisdiction Code Ŕ Licensing (DDLJU2) plus AKA Driver

License Number (DDLNU1) values, add a new record to the AKA ST-DLN (CD24) data store:

Move positions 1 - 2 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3) from the update


Move positions 3 - 27 of the AKA 2nd Driver License Jurisdiction Number (DDLJD3) from the update






Driver AKA ST-DLN

If AKA Driver License Jurisdiction Number (DDLJD2) is present on the update message and:

The value does not match the most recent CD24 concatenated AKA Jurisdiction Code Ŕ Licensing

(DDLJU2) plus AKA Driver License Number (DDLNU1) values; and also

Does not match the concatenated Jurisdiction Code Ŕ Licensing (DDLJUR) plus Driver License Number

(DDLNUM) on the Master Pointer (CD20),

Add a new record to the AKA ST-DLN (CD24) data store:

Move positions 1 - 2 of the AKA Driver License Jurisdiction Number (DDLJD2) from the update


Move positions 3 - 27 of the AKA Driver License Jurisdiction Number (DDLJD2) from the update


Set other fields on each new associated AKA ST-DLN (CD24) record as follows:

AKA ST-DLN Status (DDLKST) set to ŘAř





Note: Each ST-DLN Pointer (CD24) record must have a unique Record Creation Date (GRCCDT) and Record Creation

Time (GRCCTM) combination, as well as a unique Date of Last Update (GRCUDT) and Time of Last Update

(GRCUTM) combination. When setting the Record Creation Time (GRCCTM) or Time of Last Update (GRCUTM), if

a duplicate date/time will be created, increment the time by one second until a unique combination is found.



CDG1 CREATE AKA FROM MASTER POINTER DATA (CDLIS Central Site)


CDG1 CREATE AKA FROM MASTER POINTER DATA (CDLIS CENTRAL SITE)

CDG1.1 Introduction

When an existing Master Pointer (CD20) record is updated, the CDLIS Central Site adds record(s) to the appropriate

AKA Name (CD22), and/or AKA ST-DLN (CD24) data store(s) using the CD20 data prior to update

CDG1.2 Updates

CDG1.2.1 Update AKA Name (CD22)

The following rules apply to updates of AKA Name on the Update AKA Name (CD22) record:

No two AKA Name values will ever be the same, and

No primary name value will ever be the same as any AKA values


If Person Name Group (BPENGP) is present on the update message and does not match the Person Name Group

(BPENGP) on the existing CD20 record prior to update:

Delete any existing CD22 Person AKA Name Group (BPENG3) records that match the Person Name

Group (BPENGP) on the update message (so no AKA names duplicate the primary name)

Add a new associated record to the AKA Name (CD22) data store:

o Person AKA Name Group (BPENG3) set to Person Name Group (BPENGP) on the existing CD20

record prior to update

Set other fields on the new AKA Name (CD22) record as follows:

o Record Creation Date (GRCCDT) set to current system date

o Record Creation Time (GRCCTM) set to current system time

o Date of Last Update (GRCUDT) set to current system date

o Time of Last Update (GRCUTM) set to current system time


If Driver Name (DDVNAM) is present on the update message and, when converted into the format specified in

ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ, does not match the Person Name

Group (BPENGP) on the existing CD20 record prior to update:

Delete any existing CD22 Person AKA Name Group (BPENG3) records that, when converted into the

format specified in ŖAPPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULESŗ, match the

Driver Name (DDVNAM) on the update message (so no AKA names duplicate the primary name)

Add a new associated record to the AKA Name (CD22) data store:

o Person AKA Name Group (BPENG3) set to Person Name Group (BPENGP) on the existing CD20

record prior to update

Set other fields on the new AKA Name (CD22) record as follows:

o Record Creation Date (GRCCDT) set to current system date

o Record Creation Time (GRCCTM) set to current system time

o Date of Last Update (GRCUDT) set to current system date

o Time of Last Update (GRCUTM) set to current system time

Transitional Note:

When matching names, the CDLIS Central Site shall take into account that the same name may have slight

differences depending on whether it was originally captured in the format described in ŖAPPENDIX E.1 Ŕ

AAMVA PERSON NAME FORMATTING RULESŗ or in the format described in 'APPENDIX E.2 - AAMVA

PERSON NAME STANDARD (2008)'.



CDG1 CREATE AKA FROM MASTER POINTER DATA (CDLIS Central Site)


CDG1.2.2 Update AKA ST-DLN (CD24)

The following rules apply to updates of AKA ST-DLN on the Master Pointer (CD20) record:

No two consecutive AKA ST-DLN values will ever be the same, and

No primary ST-DLN value will ever be the same as the one most recent AKA ST-DLN value

If Driver License Jurisdiction Number (DDLJDL) is present on the update message and does not match the

concatenated Jurisdiction Code Ŕ Licensing (DDLJUR) plus Driver License Number (DDLNUM) on the existing CD20

record prior to update,

Add a new associated record to the AKA ST-DLN (CD24) data store:

AKA Jurisdiction Code - Licensing (DDLJU2) set to the Driver License Jurisdiction Number (DDLJDL)

from the existing CD20 record prior to update

AKA Driver License Number (DDLNU1) set to the Driver License Jurisdiction Number (DDLJDL) from

the existing CD20 record prior to update

Set other fields on the new AKA ST-DLN (CD24) record as follows:

AKA ST-DLN Status (DDLKST) set to ŘAř







CDH1 SEARCH INQUIRY RETRIEVAL (CDLIS CENTRAL SITE)



CDH1.1 Introduction

The Search Inquiry Retrieval (CDH1) process is performed upon receipt of a valid Search Inquiry (IM) or Inquiry for

AKA Data (IK) message.

CDH1.2 Retrieval

For each valid search inquiry message, the Central Site retrieves up to a maximum of 15 records from the Master

Pointer (CD20) data store based on possible matches of information sent in the search inquiry message.

The Central Site will execute up to four different search routines depending on the information sent in the search inquiry

message. The search routines are executed in the following order:

State/Driver License Number (ST/DLN) - Exact

Social Security Number (SSN) Ŕ Exact, Similar and Transposed

Primary Name/Date of Birth (DOB) Ŕ Exact and Similar

Date of Birth (DOB)/AKA Name Ŕ Exact and Similar

The Central Site returns the first 15 unique records retrieved from Master Pointer (CD20).

CDH1.2.1 Exact ST/DLN Search

If Driver License Jurisdiction Number (DDLJDL) is present on the search inquiry message, the Central Site searches

both the primary and AKA data stores for exact matches:



(DDLJDL) from the search inquiry message; and


(DDLJDL) from the search inquiry message

Access AKA ST-DLN (CD24) by:


Number (DDLJDL)


Number (DDLJDL)

Retrieve the three most recent CD24 records based on Date of Last Update (GRCUDT) and Time of Last Update

(GRCUTM) where the AKA ST-DLN Status (DDLKST) is set to ŘAř.

Access the CD20 records associated with the selected CD24 records.

CDH1.2.2 SSN Search

If Driver SSN - CDLIS (DDVSS6) is present on the search inquiry and is not all 9s, perform the following searches in

the order presented below:

CDH1.2.2.1 Exact SSN Search



Person SSN Last 5 Digits (BPESSD) using the last 5 positions of the Driver SSN - CDLIS (DDVSS6)

from the search inquiry message. Retrieve only those records where the Driver SSN Type (DDVSSI) is

not = ŘSř to avoid matches on substitute SSNs (all 9řs).







Driver Social Security Number (DDVSSN) using Driver SSN - CDLIS (DDVSS6) from the search

inquiry message

CDH1.2.2.2 ‘Similar SSN’ Search

The Řsimilar SSNř search uses a set of probabilistic algorithms based on commonly occurring typographical errors to

determine whether two SSNs are similar enough that they could represent the same SSN.

Detailed information on how to perform a Řsimilar SSNř search is not provided in this document, but may be obtained

by authorized parties on a Řneed to knowř basis by contacting AAMVA.

CDH1.2.2.3 ‘Transposed SSN’ Search

The Řtransposed SSNř search uses a set of probabilistic algorithms based on common numeric transpositions to

determine whether two SSNs are similar enough that they could represent the same SSN.

Detailed information on how to perform a Řtransposed SSNř search is not provided in this document, but may be


CDH1.2.3 Primary Name/DOB Search

Perform the following searches in the order presented below:

CDH1.2.3.1 Exact Primary Name/DOB Search



Person Name Group (BPENGP) using Person Name Group (BPENGP) from the search inquiry message

Person Date of Birth (BPEDOB) using the Driver Date of Birth (DDVDOB) from the search inquiry

message



Person Name Group (BPENGP) as converted into the format specified in ŖAPPENDIX E.1 Ŕ AAMVA

PERSON NAME FORMATTING RULESŗ, using Driver Name (DDVNAM) from the search inquiry

message

Person Date of Birth (BPEDOB) using the Driver Date of Birth (DDVDOB) from the search inquiry

message

CDH1.2.3.2 ‘Similar Primary Name/DOB’ Search

The Řsimilar primary name/DOBř search uses a set of probabilistic algorithms to determine when any two name/DOB

combinations being compared are similar enough that they both may refer to the same individual.

Detailed information on how to perform a Řsimilar name/DOBř search is not provided in this document, but may be


CDH1.2.4 AKA Name(/DOB) Search


If the first occurrence of Person AKA Name Group (BPENG3) is present on the search inquiry message

Perform the searches represented in ŖCDH1.2.4.1 Exact AKA Name(/DOB) Searchŗ and ŖCDH1.2.4.2

ŘSimilar AKA Name(/DOB)ř Searchŗ in the order presented.






If Driver AKA Name (DDVKNM) is present on the search inquiry message

Perform the searches represented in ŖCDH1.2.4.1 Exact AKA Name(/DOB) Searchŗ and ŖCDH1.2.4.2

ŘSimilar AKA Name(/DOB)ř Searchŗ in the order presented.

CDH1.2.4.1 Exact AKA Name(/DOB) Search



Person Name Group (BPENGP) using the first occurrence of Person AKA Name Group (BPENG3) from

the search inquiry message and

Person Date of Birth (BPEDOB) using the Driver AKA Date of Birth (DDVKDB) from the search

inquiry message

If Driver AKA 2nd Name (DDVKN2) is present on the search inquiry message, access the Master Pointer


Person Name Group (BPENGP) using the second occurrence of Person AKA Name Group (BPENG3)

from the search inquiry message and

Person Date of Birth (BPEDOB) using the Driver AKA 2nd Date of Birth (DDVKD2) from the search

inquiry message

If Driver AKA 3rd Name (DDVKN3) is present on the search inquiry message, access the Master Pointer


Person Name Group (BPENGP) using the third occurrence of Person AKA Name Group (BPENG3) from

the search inquiry message and

Person Date of Birth (BPEDOB) using the Driver AKA 3rd Date of Birth (DDVKD3) from the search

inquiry message

Access AKA Name (CD22) by:

Person AKA Name Group (BPENG3) using the first occurrence of Person AKA Name Group (BPENG3)

from the search inquiry message


If Driver AKA 2nd Name (DDVKN2) is present on the search inquiry message, access the AKA Name (CD22)

data store by:

Person AKA Name Group (BPENG3) using the second occurrence of Person AKA Name Group

(BPENG3) from the search inquiry message


If Driver AKA 3rd Name (DDVKN3) is present on the search inquiry message, access the AKA Name (CD22)

data store by:

Person AKA Name Group (BPENG3) using the third occurrence of Person AKA Name Group (BPENG3)

from the search inquiry message









PERSON NAME FORMATTING RULESŗ, using Driver AKA Name (DDVKNM) from the search

inquiry message and

Person Date of Birth (BPEDOB) using the Driver AKA Date of Birth (DDVKDB) from the search

inquiry message

If Driver AKA 2nd Name (DDVKN2) is present on the search inquiry message, access the Master Pointer



PERSON NAME FORMATTING RULESŗ, using Driver AKA 2nd Name (DDVKN2) from the search

inquiry message and

Person Date of Birth (BPEDOB) using the Driver AKA 2nd Date of Birth (DDVKD2) from the search

inquiry message

If Driver AKA 3rd Name (DDVKN3) is present on the search inquiry message, access the Master Pointer



PERSON NAME FORMATTING RULESŗ, using Driver AKA 3rd Name (DDVKN3) from the search

inquiry message and

Person Date of Birth (BPEDOB) using the Driver AKA 3rd Date of Birth (DDVKD3) from the search

inquiry message

Access AKA Name (CD22) by:

Person AKA Name Group (BPENG3) as converted into the format specified in ŖAPPENDIX E.1 Ŕ

AAMVA PERSON NAME FORMATTING RULESŗ, using Driver AKA Name (DDVKNM) from the

search inquiry message


If Driver AKA 2nd Name (DDVKN2) is present on the search inquiry message, access the AKA Name (CD22)

data store by:


AAMVA PERSON NAME FORMATTING RULESŗ, using Driver AKA 2nd Name (DDVKN2) from

the search inquiry message


If Driver AKA 3rd Name (DDVKN3) is present on the search inquiry message, access the AKA Name (CD22)

data store by:


AAMVA PERSON NAME FORMATTING RULESŗ using Driver AKA 3rd Name (DDVKN3) from the

search inquiry message


CDH1.2.4.2 ‘Similar AKA Name(/DOB)’ Search

The Řsimilar AKA name(/DOB)ř search uses a set of probabilistic algorithms to determine when any name and/or DOB

combinations being compared are similar enough that they may refer to the same individual.

Detailed information on how to perform a Řsimilar name(/DOB)ř search is not provided in this document, but may be




CDI1 PROVIDE DETAIL ON REQUESTED DRIVER (STATE OF RECORD (SOR))



CDI1.1 Introduction

Upon receipt of the Status Request (SC) message, the SOR attempts to retrieve the requested record from the State's

database using the information contained on the Status Request (SC).

If the driver record is found, the SOR sends the Status Response (HC) message and, if applicable, Permit Restrictions

(H6) to the SOI.

If the State does not find the requested Driver information on the State system (a 'broken pointer' situation), the SOR

notifies the CDLIS Central Site (by returning the Status Request (SC) message) and the SOI (via the Status Response

(HC) message).

Note: The SOR must determine why the broken pointer condition exists and resolve the situation within 96 hours of

returning the associated error. The AAMVA Operations Help Desk will provide all assistance possible and should be

kept informed of the progress.

CDI1.2 Reception

The SOR processes the Status Request (SC) message sent from the CDLIS Central Site.








The Status Request (SC) message may optionally include:



Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the Status Request (SC) message may include either the

Driver Name (DDVNAM) or the Person Name Group (BPENGP). The absence of Person Name Group (BPENGP)

indicates that the initiator of the Status Request (SC) message has not yet implemented version 5.1 or greater.

CDI1.3 Validation

The validation checks described below are performed on the message. If any errors are detected, the error fields are set

(see Ŗ4 CDLIS ERROR PROCESSINGŗ for details), the original message is returned to its sender, and the

jurisdiction's processing stopped.

The error messages are examples of the messages the CDLIS Central Site may receive from the SOR.

CDI1.3.1 System Errors


CDI1.3.2 Required Data Errors

One or the other of the following must be present:








Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the Status Request (SC) message may include either the

Driver Name (DDVNAM) or the Person Name Group (BPENGP). The absence of Person Name Group (BPENGP)

indicates that the initiator of the Status Request (SC) message has not yet implemented version 5.1 or greater.

CDI1.3.3 Invalid Data Errors

Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL), if present, must contain one of the valid values in



Person Name Group (BPENGP), if present, must conform to the requirements listed in "APPENDIX E.3 - AAMVA




Driver Name (DDVNAM), if present, must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ AAMVA



CDI1.3.4 Data Look-up Errors





Error Text: ‘RECORD NOT FOUND’







New SOR, it cannot respond with driver information until the Change State of Record (CSOR) has successfully


(GPROST) = Ř05ř.


CDI1.4 Transmission

If the SOR successfully retrieves the corresponding jurisdiction driver record, the SOR sends

A Status Response (HC) message

A Permit Restrictions (H6) message (if the driver has any permit restriction information)

If the SOR cannot retrieve the corresponding jurisdiction driver record (a 'broken pointer' situation), the SOR

Either sends a Status Response (HC) message to the SOI or





Returns the original Status Request (SC) message to the Central Site

CDI1.4.1 Transmission of the Status Response (HC) Message When Driver Located



Application Status (GAPPST) set to '0'






If the driver record is involved in a Change State of Record transaction at the time the inquiry is

processed, and if the associated driver history has not yet been posted to the driver's record:


o NCB Error Code set to 'Y'

o Error text: "DRIVER HISTORY NOT COMPLETE"

Otherwise,


o NCB Error Code (GNSBER) set to 'N'

Note: Even though the NCB Error Code is set to 'Y', the other fields in the Status Response (HC) message

are still populated as if no error has occurred.


Message AKA DLN Count (GMSCDL) set to the number of AKA DLNs being sent

Message AKA SSN Count (GMSCSS) set to the number of AKA SSNs being sent

Message AKA Name Count (GMSCNM) set to the number of AKA Names being sent

Driver Date of Birth (DDVDOB) set to the driver's date of birth on the SOR's database

Driver License Jurisdiction Number (DDLJDL) set to the driver's license number on the SOR's database

Driver SSN - CDLIS (DDVSS6) set to the driver's Social Security Number on the SOR's database

Driver License Number of Permits (DDLNMP) set to the number of permits for the driver's on the SOR's

database

Commercial Driver License Class Code (DDLCL2) set to the driver's commercial class on the SOR's

database

Non-Commercial Driver License Class Code (DDLCL3) set to the driver's non-commercial class on the

SOR's database

Driver License Issue Date (DDLISS) set to the issue date of the driver's license on the SOR's database

Driver License Expiration Date (DDLEXP) set to the expiration date of the driver's license on the SOR's

database

Driver License Non-Commercial Status (DDLNTS) set to the status of a driver's non-commercial license

on the SOR's database

Driver License Commercial Status (DDLCTS) set to the status of a driver's commercial license on the

SOR's database

Driver License Privilege Type W/D Action Pending (DDLWDP) set to '1' if the SOR has an action

pending; '2' otherwise

Number of Driver License Restrictions (DDLNMR) set to the number of restrictions on the driver's

license on the SOR's database





Driver Medical History Indicator (DDVMED) set to '1' if the SOR has a medical history file on the driver;

'2' otherwise. The Driver Medical History Indicator (DDVMED) has no relationship to Medical

Certificate requirements.

Total Convictions Sent (DDTTCS) set to '00'

Total ACD Convictions On Record (DDTTCR) set to the number of convictions with a current ACD code

on the SOR's database for the driver

Total Accidents Sent (DDTTAS) set to '00'

Total Accidents On Record (DDTTAR) set to the number of accidents on the SOR's database for the

driver

Total Withdrawals Sent (DDTTWS) set to '00'

Total Withdrawals On Record (DDTTWR) set to the number of withdrawals with a current ACD code on

the SOR's database for the driver

Driver Mailing Address (DDVADD) set to the driver's mailing address on the SOR's database

Note: The Total Convictions Sent (DDTTCS), Total Accidents Sent (DDTTAS) and Total Withdrawals Sent

(DDTTWS) will always be '00' since no conviction, accident, or withdrawal information is sent in status

responses.

The Status Response (HC) message must include all available data on the SOR's database for the following:

Driver AKA Date Of Birth (DDVKDB) set to the first date of birth previously associated with the driver

Driver AKA 2nd Date Of Birth (DDVKD2) set to the second date of birth previously associated with the

driver

Driver AKA 3rd Date Of Birth (DDVKD3) set to the third date of birth previously associated with the

driver

Driver Current Sex (DDVSX3) set to the driver's sex

Driver Current Height (DDVHT3) set to the driver's height

Driver Current Weight (DDVWT3) set to the driver's weight

Driver Current Eye Color (DDVEY3) set to the driver's eye color

AKA Driver License Jurisdiction Number (DDLJD2) set to the first driver license number previously

associated with the driver

AKA 2nd Driver License Jurisdiction Number (DDLJD3) set to the second driver license number

previously associated with the driver

AKA 3rd Driver License Jurisdiction Number (DDLJD4) set to the third driver license number previously

associated with the driver

Driver AKA Social Security Number (DDVKSS) set to a Social Security Number previously associated

with the driver

Driver License Permit Classification Code (DDLPC2) set to the class(es) of vehicle the driver is

authorized to operate (up to 3)

Driver License Permit Endorsement Group Code (DDLEP1) set to the endorsement(s) held by the driver

(up to 3)

Driver License Permit Issue Date (DDLPID) set to the issue date of any permit(s) issued to the driver (up

to 3)

Driver License Permit Expiration Date (DDLPED) set to the expiration date of any permit(s) issued to the

driver (up to 3)

Driver License Permit Status (DDLPST) set to the status of any permit(s) issued to the driver (up to 3)

Driver License Number of Permit Restrictions (DDLRPN) set to the number of restrictions on any

permit(s) issued to the driver (up to 3)

Driver Residence Address (DDVRAD) set to the driver's residence address





Driver License Endorsement Code (DDLEND) set to the endorsement(s) on the driver's license (up to 5)

Driver License Restriction Code (DDLRSC) set to the restriction(s) on the driver's license (up to 12)

Driver License Restriction End Date (DDLRSD) set to the date on which the restriction(s) will end (up to

12); if the period of the restriction is indefinite, the date is left blank

Driver License Restriction Explanation (DDLRSE) set to the explanation of the restriction(s) (up to 12);

only entered if the Driver License Restriction Code (DDLRSC) is set to either ŘIř (ŖRestricted Ŕ Otherŗ)

or 'J' ("Other")





The first occurrence of Person AKA Name Group (BPENG3) set to the first name by which the driver

may be known other than the current name


driver may be known other than the current name





Driver Name (DDVNAM) set to the value on the SOR's database


Driver AKA Name (DDVKNM) set to the first name by which the driver may be known other than the

current name

Driver AKA 2nd Name (DDVKN2) set to the second name by which the driver may be known other than

the current name

Driver AKA 3rd Name (DDVKN3) set to the third name by which the driver may be known other than

the current name

If Medical Certificate information is available, the Status Response (HC) message must include the following required

Medical Certificate fields:


certification


certification

If Medical Certificate information is available, the Status Response (HC) message must also include all available data

on the SORřs database for the following optional Medical Certificate fields:



examinerřs license




specialty








ten occurrences)

If FMCSA-approved variance information is available, the Status Response (HC) message must also include all

available data on the SORřs database for the following optional FMCSA variance fields:












values.

CDI1.4.2 Transmission of the Permit Restrictions (H6) Message


Message Destination (GMSDST) set to the value of the Transaction Originator (GTRORG) on the original

message







Driver License Jurisdiction Number (DDLJDL) set to the driver license number in the SOR's database

Driver SSN - CDLIS (DDVSS6) set to the driver's Social Security Number in the SOR's database


values.

The Permit Restrictions (H6) message may optionally include up to 12 occurrences of the following elements populated

with data from the SOR's database:










CDI1.4.3 Transmission of Status Request (SC) Message When a 'Broken Pointer' Exists

If the jurisdiction does not find a matching driver on its system (a 'broken pointer' situation) or if a CSOR is in progress

and the Transaction Originator (GTRORG) is not the New SOR, the SOR returns the Status Request (SC) message in its




original form to the CDLIS Central Site with the following data elements changed:









values.



CDJ1 AUTHORIZATION, IMPLEMENTATION VERIFICATION (CDLIS Central Site)


CDJ1 AUTHORIZATION, IMPLEMENTATION VERIFICATION (CDLIS CENTRAL SITE)

CDJ1.1 Introduction

All messages received by the CDLIS Central Site must include a password that corresponds to a previously assigned

value for the message sender. The CDLIS Central Site must verify that the password provided on any received message

matches the password assigned to the participant at the CDLIS Central Site.

In addition, until all participants have fully implemented version 5.1 or greater, processing requirements for some

messages may vary depending on the version that a given participant has implemented. After receiving a given

message, the CDLIS Central Site determines the authorization and implementation status of each involved participant

for the given execution of the process. It does this by performing ŘCDJ1.2 Verification of Message Originatorř and

ŘCDJ1.3 Verification of Additional Transaction Participantř.

CDJ1.2 Verification of Message Originator

The following information is passed to ŘCDJ1.2 Verification of Message Originatorř:

Jurisdiction Code (BJUCDE)


Authorized Function (BJUAFN)

Implementation Release Code (GMSIRL)

To validate the password provided by the message originator:

Access the Participant (CD2C) data store by Jurisdiction Code (BJUCDE) using the value provided by the

calling process. An occurrence must exist and the CD2C Message Sender Password (GMSPSW) must match the

Message Sender Password (GMSPSW) provided by the calling process.

Error Text: ‘USER ID/PASSWORD MISMATCH’

To determine the current version of implementation for the message originator:

Access the associated Authorized Function (CD2D) data store by Authorized Function (BJUAFN) using the

value provided by the calling process.

If a record exists and the associated Implementation Release Code (GMSIRL) is equal to or greater than the

Implementation Release Code (GMSIRL) provided by the calling process, then the participant is authorized for

the function at the release specified or greater.

If a record exists but the associated Implementation Release Code (GMSIRL) is less than the Implementation

Release Code (GMSIRL) provided by the calling process, then the participant is authorized for the function, but

only at a release less than the release specified.

If a record does not exist, then the participant is not authorized for the function.

Error Text: 'ORIGINATING SITE NOT APPROVED TO SEND MESSAGE TYPE'

If either password or authorization validation fails, no further validations are performed. The message is returned to the

message originator with the appropriate error text appended.

CDJ1.3 Verification of Additional Transaction Participant

The following information is passed to ŘCDJ1.3 Verification of Additional Transaction Participantř:

Jurisdiction Code (BJUCDE)

Authorized Function (BJUAFN)

Implementation Release Code (GMSIRL)

To determine the current version of implementation for the additional participant of the transaction:



CDJ1 AUTHORIZATION, IMPLEMENTATION VERIFICATION (CDLIS Central Site)


Access the Participant (CD2C) data store by Jurisdiction Code (BJUCDE) using the value passed by the calling

process. An occurrence must exist.

Error Text: ‘DESTINATION SITE NOT APPROVED TO RECEIVE MESSAGE

TYPE’

Access the associated Authorized Function (CD2D) data store by Authorized Function (BJUAFN) using the

value provided by the calling process.

If a record exists and the associated Implementation Release Code (GMSIRL) is equal to or greater than the

Implementation Release Code (GMSIRL) provided by the calling process, then the participant is authorized for

the function at the release specified or greater.

If a record exists but the associated Implementation Release Code (GMSIRL) is less than the Implementation

Release Code (GMSIRL) provided by the calling process, then the participant is authorized for the function, but

only at a release less than the release specified.

If a record does not exist, then the participant is not authorized for the function.

Error Text: ‘DESTINATION SITE NOT APPROVED TO RECEIVE MESSAGE

TYPE’

If either of the above validations fail, no further validations are performed. The message is returned to the message

originator with the appropriate error text appended.



CDL1 PROCESS HISTORY REQUEST (STATE OF RECORD (SOR)/Old State of Record (OSOR))


CDL1 PROCESS HISTORY REQUEST (STATE OF RECORD (SOR)/OLD STATE OF RECORD (OSOR))

CDL1.1 Reception

CDL1.1.1 Reception of the Driver History Request (SB) Message

The SOR processes the Driver History Request (SB) message sent from the SOI.

For all Jurisdictions, regardless of the version implemented, the Driver History Request (SB) message must include:



For all Jurisdictions, regardless of the version implemented, the Driver History Request (SB) message may optionally

include:



Return as Received Text Block (GRRECV)

If the SOI is at version 5.1 or greater, the Driver History Request (SB) message may optionally include:


If the SOI is at version older than 5.1, the Driver History Request (SB) message may optionally include:


Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the SOR should consider the absence of Person Name

Group (BPENGP) as the indicator that the SOI has not yet implemented version 5.1 or greater.

CDL1.1.2 Reception of the CSOR History Request (SD) Message

The Old SOR processes the CSOR History Request (SD) message sent from the CDLIS Central Site.

For all Jurisdictions, regardless of the version implemented, the CSOR History Request (SD) message must include:




If the New SOR is at version 5.1 or greater, the CSOR History Request (SD) message must include:



If the New SOR is at a version older than 5.1, the CSOR History Request (SD) message must include:

Old Name (DDVNM1)

Name (DDVNAM)

For all Jurisdictions, regardless of the version implemented, the CSOR History Request (SD) message may optionally

include:






CDL1.2 Validation

CDL1.2.1 Common Validations

The validations in "CDL1.2.1 Common Validations" are common to both the Driver History Request (SB) and CSOR

History Request (SD) messages.

CDL1.2.1.1 System Errors


CDL1.2.1.2 Required Data Errors


(DDLJDL).




CDL1.2.1.3 Invalid Data Errors

System Release Code (GMSSRL), if present, must contain one of the valid values listed in ŖAPPENDIX D - DATA

DICTIONARYŗ.


CDL1.2.2 Driver History Request (SB) Message Validations

The validations in "CDL1.2.2 Driver History Request (SB) Message Validations" are applicable to the Driver History

Request (SB) message only.

CDL1.2.2.1 Invalid Data Errors

Positions 1 - 2 of the Driver License Jurisdiction Number (DDLJDL) must contain ŘMXř or one of the valid values in



Driver Date of Birth (DDVDOB), if present, must be a valid date and formatted as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ.



Must be numeric





Person Name Group (BPENGP), if present, must conform to the requirements listed in the "APPENDIX E.3 - AAMVA








Driver Name (DDVNAM), if present, must conform to the requirements listed in the ŖAPPENDIX E.1 Ŕ AAMVA



Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the Driver History Request (SB) message may

optionally include the Driver Name (DDVNAM), the Person Name Group (BPENGP), or both. The SOR should

consider the absence of Person Name Group (BPENGP) as the indicator that the SOI has not yet implemented version

5.1 or greater.

CDL1.2.2.2 Data Look-up Errors





Error Text: ‘'REQUESTED RECORD NOT FOUND’











New SOR, it cannot respond with status information until the Change State of Record (CSOR) has successfully


(GPROST) = Ř05ř.





The CDLIS 5.1 design requires ST/DLN to be unique on both the Central Site and the state database. If duplicate

ST/DLNs exist in an SOR's environment, they must be resolved prior to the state implementing 5.1.

CDL1.2.3 CSOR Driver History Request (SD) Message Validations

The validations in "CDL1.2.3 CSOR Driver History Request (SD) Message Validationsŗ are applicable to the CSOR

Driver History Request (SD) message only.

The validation checks described below are performed on the message. If any errors are detected, the error fields are set

(see Ŗ4 CDLIS ERROR PROCESSINGŗ for details), the original message is returned to its sender, and the

jurisdiction's processing stopped.





CDL1.2.3.1 Data Look-up Errors





Error Text: ‘'REQUESTED RECORD NOT FOUND’













A record must exist for the Driver License Jurisdiction Number (DDLJDL) on the SOR database and the state must

consider itself the current SOR. Additional verifications on the Person Name Group (BPENGP)/Driver Name

(DDVNAM), Driver Date of Birth (DDVDOB) and Driver SSN - CDLIS (DDVSS6) are not permitted.

Error Text: 'THE RQSTD REC NOT ON FILE'

If the record is not found, a broken pointer exists on the CDLIS Central Site. Additional instructions for a broken

pointer are given in the CDLIS State Procedures Manual.

The CDLIS 5.1 design requires ST/DLN to be unique on both the Central Site and the state database. If duplicate

ST/DLNs exist in an SOR's environment, they must be resolved prior to the state implementing 5.1.If the SOR has

multiple matches on the ST/DLN, it requires special attention. If identical ST/DLNs can exist in an SOR's environment

for multiple drivers, this condition needs to be examined closely to assess its impact on the CDLIS application.

Typically, duplicates occur when an SOR recycles old DLNs. In this situation, the match with the most recent issue

date should be returned.

CDL1.2.4 Updates

Upon receipt of the CSOR History Request (SD) message, the Old SOR must add the New SOR's jurisdiction code and

driver license number to its on-line record. This record update allows the Old SOR to respond to status and history

requests from the New SOR until such time as the CSOR is complete. The Old SOR must not respond to status and

history requests from other sources during the Change State of Record. After the CSOR is successfully completed, the

Old SOR must not respond to any CDLIS status or history requests.

CDL1.3 Transmission

Upon receipt and validation of the Driver History Request (SB) message, the SOR generates the following messages for

transmission to the inquirer:

Driver History Response (HB)

Driver History Permit Info (H2) (as applicable)

Driver History Convictions (H3) (as applicable)





Driver History Accidents (H4) (as applicable)

Driver History Withdrawals (H5) (as applicable)

Driver History Withdrawal-Conviction Links (H7) (as applicable)

Upon receipt and validation of the CSOR History Request (SD) message, the Old SOR generates the following

messages for transmission to the inquirer:

CSOR Driver History Response (HD)

Driver History Permit Info (H2) (as applicable)

Driver History Convictions (H3) (as applicable)

Driver History Accidents (H4) (as applicable)

Driver History Withdrawals (H5) (as applicable)

Driver History Withdrawal-Conviction Links (H7) (as applicable)

The Jurisdiction that transmits a Driver History Convictions (H3) message, a Driver History Withdrawals (H5) message,

or a Driver History Withdrawal-Conviction Links (H7) message must edit and validate the conviction and withdrawal

information, especially the conviction offense ACD codes, withdrawal reason ACD codes, conviction ID codes, and

withdrawal IDs before they are sent. The overall purpose of validating codes is to identify errors that, if not corrected,

would interfere with the inquirer's ability to interpret the data, and would, therefore, negatively affect its ability to

determine whether or not to take any driver control actions where the inquirer is a state.

The SOR/Old SOR must respond electronically via CDLIS to a history request. Responding via CDLIS will ensure the

convictions and withdrawals are received in a timely manner and will minimize transcription errors.

The SOR/Old SOR must send only the blocks and messages in the driver history that the inquirer can process. This

determination is based on the value of the System Release Code (GMSSRL) in the associated Driver History Request

(SB) or CSOR History Request (SD) message. If the System Release Code (GMSSRL) is a space, the SOR/Old SOR

must not transmit information in the 14/2 block of the Driver History Response (HB) or CSOR Driver History Response

(HD) message and must not transmit the Driver History Withdrawal-Conviction Links (H7) message.

If, for any reason, the SOR/Old SOR cannot transmit the complete driver history, it must transmit whatever driver

history information it can via CDLIS and must contact the inquirer and arrange to send the complete driver history,

including convictions, withdrawals, and linkages by mail. Jurisdictions must indicate which mailed information

duplicates data already transmitted via CDLIS electronically.

See the CDLIS State Procedures Manual for rules when transmitting the driver history.

CDL1.3.1 Transmission of Driver History Response (HB) Message

The following information must be provided on the Driver History Response (HB) message and/or the CSOR Driver

History Response (HD) message, whichever is applicable to the inquiry message received:

Message Destination (GMSDST) set to the value of the Transaction Originator (GTRORG) in the original

message

Message Locator/Header (GMSLOC) set to the value in the original message





NCB Error Code (GNSBER) set to 'N'


Message AKA DLN Count (GMSCDL) set to the number of AKA DLNs returned

Message AKA SSN Count (GMSCSS) set to the number of AKA SSNs returned

Message AKA Name Count (GMSCNM) set to the number of AKA Names returned





System Release Code (GMSSRL) set to the valid code in ŖAPPENDIX D - DATA DICTIONARYŗ (ŘFř, or ŘHř)

indicating the transaction version currently implemented by the SOR/Old SOR

Driver Date of Birth (DDVDOB) set to the value on the SOR/Old SOR's database


o Driver License Current Jurisdiction Code (DDLJU1) set to jurisdiction code of the driver's license on the

SOR/Old SOR's database

o Driver License Number (DDLNUM) set to the driver's license number on the SOR/Old SOR's database

Driver SSN - CDLIS (DDVSS6) set to the value on the SOR/Old SOR's database

Driver License Number of Permits (DDLNMP) set to the number of permits being sent

If Person Name Group (BPENGP) is present on the associated inquiry message,

Person Name Group (BPENGP) set to the value on the SOR/Old SOR's database

If Driver Name (DDVNAM) is present and Person Name Group (BPENGP) is not present on the associated

inquiry message,

Driver Name (DDVNAM) set to the value on the SOR/Old SOR's database

If neither Driver Name (DDVNAM) nor Person Name Group (BPENGP) are present on the associated inquiry

message,

Person Name Group (BPENGP) and Driver Name (DDVNAM), both set to the value on the SOR/Old

SOR's database

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the Driver History Request (SB) and/or CSOR Driver

History Response (HD) message may optionally include the Driver Name (DDVNAM), the Person Name Group

(BPENGP), or both. The SOR/Old SOR should consider the absence of Person Name Group (BPENGP) as the

indicator that the SOI/New SOR has not yet implemented version 5.1 or greater.

If present on the original message, the response message must also contain:

Return as Received Text Block (GRRECV) from the original message

The response message must also include all available data on the SOR/Old SOR's database for the following:










Total Convictions Sent (DDTTCS) set to the number of convictions sent in the Driver History Convictions (H3)

message (≤ 50)

Total ACD Convictions on Record (DDTTCR) Ŕ the total includes only convictions with current ACD codes

Total Accidents Sent (DDTTAS) set to the number of accidents sent in the Driver History Accidents (H4)

message (≤ 50)


Total Withdrawals Sent (DDTTWS) set to the number of withdrawals sent in the Driver History Withdrawals

(H5) message (≤ 50)

Total Withdrawals on Record (DDTTWR) Ŕ the total includes only retained withdrawals with current ACD





codes

Total Withdrawal-Conviction Links Sent (DDTTLS) set to zero if the System Release Code (GMSSRL) in the

associated inquiry message was set to a space; otherwise set to the number of linkages sent in the Driver History

Withdrawal-Conviction Links (H7) message (≤ 50)

Total Withdrawal-Conviction Links on Record (DDTTLR)









Driver SSN - CDLIS (DDVSS6) set to the value on the SOR/Old SOR's database.

Driver License Endorsement Code (DDLEND) filled with zero to five occurrences




Driver AKA Social Security Number (DDVKSS) Ŕ sent when the response is being returned to a jurisdiction.

For other recipients, jurisdiction privacy rules will dictate whether the SSN will be included.


Driver License History Check Inquiring Jurisdiction (DDLHCI) set to the code identifying the jurisdiction that

requested the most recent 10-year history check, if a 10-year history check has been initiated; otherwise left

blank

Driver License History Check Date (DDLHCD) set to the date that the jurisdiction requested the most recent 10-

year history check, if a 10-year history check has been initiated; otherwise left blank

Driver License History Check Response Total (DDLHCT) set to the number (up to a limit of 99) of former

licensing jurisdictions that responded to the most recent 10-year history check request, if a 10-year history check

has been initiated; otherwise left blank

Driver License History Check Response List (DDLHCL) containing 0 to 15 occurrences of the following data

element, if a 10-year history check has been initiated; otherwise left blank

o Driver License History Check Responding State (DDLHCJ) set to the code of a jurisdiction that

responded to the most recent 10-year history check request.

Driver License History Check Request Total (DDLHCR) set to the number (up to a limit of 99) of former

licensing jurisdictions that were queried in the most recent 10-year history check request, if a 10-year history

check has been initiated; otherwise left blank

Driver TSA HME Threat Determination (DTHTSD) set to the appropriate code, if a TSA Threat Determination

has been completed. This data element is required if available

Driver License Hazmat Endorsement Exp Date (DDLHED) set to the appropriate date, if a TSA Threat

Determination has been completed. This data element is required if available

Driver License Restriction Code (DDLRSC) set to the restriction(s) on the driver's license (0 to 12 occurrences)

Driver License Restriction End Date (DDLRSD) set to the date on which the restriction(s) will end (0 to 12

occurrences)--if the period of the restriction is indefinite, the date is left blank

Driver License Restriction Explanation (DDLRSE) set to the explanation of the restriction(s) (0 to 12

occurrences)--only entered if the Driver License Restriction Code (DDLRSC) is set to either ŘIř (ŖRestricted Ŕ

Otherŗ) or 'J' ("Other")





If Person Name Group (BPENGP) is present on the associated inquiry message,







If Driver Name (DDVNAM) is present and Person Name Group (BPENGP) is not present on the associated inquiry

message,

Driver AKA Name (DDVKNM) set to the first name by which the driver may be known other than the current

name

Driver AKA 2nd Name (DDVKN2) set to the second name by which the driver may be known other than the

current name

Driver AKA 3rd Name (DDVKN3) set to the third name by which the driver may be known other than the

current name

If neither Driver Name (DDVNAM) nor Person Name Group (BPENGP) are present on the associated inquiry message,

The first occurrence of Person AKA Name Group (BPENG3) and Driver AKA Name (DDVKNM), both set to

the first name by which the driver may be known other than the current name

The second occurrence of Person AKA Name Group (BPENG3) and Driver AKA 2nd Name (DDVKN2), both

set to the second name by which the driver may be known other than the current name

The third occurrence of Person AKA Name Group (BPENG3) and Driver AKA 3rd Name (DDVKN3), both set

to the third name by which the driver may be known other than the current name

If Medical Certificate information is available, the response message must include the following required Medical

Certificate fields:


certification


certification

If Medical Certificate information is available, the response message must also include all available data on the SORřs

database for the following optional Medical Certificate fields:



examinerřs license




specialty




ten occurrences)

If FMCSA-approved variance information is available, the response message must also include all available data on the

SORřs database for the following optional FMCSA variance fields:
















values.

Notes about backward compatibility for Release 4.0.1:

If the SOR/Old SOR has not implemented Release 4.0.1 and a 10-year history check has been initiated, the SOR/Old

SOR must send the information it can in the response message; notify the inquirer of its situation; and, if requested by

the inquirer, mail the 10-year history check information.

Notes about the total number of convictions, withdrawals, and linkages on record and sent:

The counts for convictions, withdrawals, and linkages sent on the response message must only include those

convictions/withdrawals/linkages that can be sent via CDLIS. The intent of the ŘTotal Sentř and ŘTotal on Recordř (for

convictions itřs now ŘTotal ACD Convictions on Recordř; for withdrawals it includes the ŘW00ř code) is to notify the

recipient that more convictions, withdrawals and/or linkages exist on the driverřs record than could be transmitted. The

SOR/Old SOR then mails all of the convictions, withdrawals and/or linkages to the recipient. As of October 1, 2005, if

the SOR/Old SOR has not yet implemented Release 4.0.1, these counts may be different because some of the

conviction/withdrawals contain or reference convictions/withdrawals with new ACD codes which the SOR/Old SOR

cannot yet transmit via CDLIS.

Notes about Driver License Non-Commercial Status (DDLNTS) and Driver License Commercial Status (DDLCTS):

According to 49 CFR 384.210 ŖLimitation on licensing statesŗ a jurisdiction may not issue a CDL to a person during a

period in which ŖAny type of driver's license held by such person is suspended, revoked, or canceled by the State where

the driver is licensed for any State or local law related to motor vehicle traffic control (other than parking violations).ŗ

Therefore, when deciding whether to issue a CDL, a commercial or non-commercial status of ŘNOTř precludes

issuance, regardless of the reason for the status.

The current SOR is responsible for determining the commercial status using the driverřs complete history. Even when a

driver moves and downgrades his/her license, the SOR must be able to maintain the driverřs CDL status based on the

driverřs history. If a commercial driver has received a lifetime disqualification, their commercial status has to stay

ŘNOTř for 55 years. Additional convictions and withdrawals may be sent to the SOR after the person no longer holds a

CDL and these also affect a personřs commercial status.

A commercial status of ŘNOTř requires at least one open withdrawal (one without a reinstatement date).

Notes about the HME and the TSA Threat Determination:

A jurisdiction must not issue a hazardous materials endorsement on a permit (see 49 CFR 383.23(c)(3)). Because the

ŖXŗ endorsement is for a combined Tank/HAZMAT endorsement, that is not allowed either, although a Tank

endorsement by itself would be valid

The two USA PATRIOT Act data elements (Driver TSA HME Threat Determination (DTHTSD) and Driver License

Hazmat Endorsement Exp Date (DDLHED)) are required. The jurisdiction must send and receive these data elements if

the driver has had a TSA background records check.

The Driver License Hazmat Endorsement Exp Date (DDLHED), as referenced in the State-to-State History Request

(CD04) and Change State of Record (CD08) transactions, is not required to equal the TSA expiration date. It cannot be

later than 5 years after the TSA approval date (with a Řreasonable periodř to synch up with the licensing cycle) but it

could be earlier.





Notes about the school bus endorsement:

By federal regulation, ŖSŗ is the national standard for the bus endorsement (ŖSŗ) and passenger endorsement (ŖPŗ). If a

driver has an ŖSŗ endorsement, he/she also has a ŖPŗ endorsement. A jurisdiction should send an ŖSŗ and ŖPŗ in the

history message, but if a driver has more endorsements than can be sent in the message, only the ŖSŗ is sent (this must

be interpreted as sending both the ŖSŗ and ŖPŗ).

A jurisdiction cannot have a special school bus endorsement; however, they may add a restriction that restricts the

driver to drive only empty school buses, as in the case of a mechanic driving an empty school bus to a repair shop.

CDL1.3.3 Transmission of Driver History Permit Info (H2) Message

If the driver's record contains permit information, the SOR sends a Driver History Permit Info (H2) message. The

Driver History Permit Info (H2) message must contain the following:


message







System Release Code (GMSSRL) set to the valid code in ŖAPPENDIX D - DATA DICTIONARYŗ (Řblankř,

ŘFř, or ŘHř) indicating the CDLIS release version currently implemented by the SOR/Old SOR







values.

If sent, the Driver History Permit Info (H2) message must contain one to three permits. For each permit the Driver

History Permit Info (H2) must include all available data on the SOR/Old SOR's database for the following:

Driver License Permit Classification Code (DDLPC2) set to the appropriate value

Driver License Permit Issue Date (DDLPID) set to the appropriate date

Driver License Permit Expiration Date (DDLPED) set to the appropriate date

Driver License Permit Status (DDLPST) set to the appropriate value

Driver License Number of Permit Restrictions (DDLRPN) set to the number of permit restrictions that are

included on the driver's record

For each permit that has any endorsements, the Driver History Permit Info (H2) must include all available information

on the SOR/Old SORřs database for the following:

Driver License Permit Endorsement Group Code (DDLEP1) set to the appropriate values

Each permit in the Driver History Permit Info (H2) message may contain up to 12 permit restrictions. For each permit

restriction sent on the first permit, the Driver History Permit Info (H2) must include all available data on the SOR/Old

SOR's database for the following:

Driver License 1st Permit Restriction Code (DDLRP1)

Driver License 1st Permit Restriction End Date (DDLPD1)

Driver License 1st Permit Restriction Explanation (DDLPE1)





For each restriction sent on the second permit, the Driver History Permit Info (H2) message must contain all available

data for the following:

Driver License 2nd Permit Restriction Code (DDLRP2)

Driver License 2nd Permit Restriction End Date (DDLPD2)

Driver License 2nd Permit Restriction Explanation (DDLPE2)

For each restriction sent on the third permit, the Driver History Permit Info (H2) message must contain all available data

for the following:

Driver License 3rd Permit Restriction Code (DDLRP3)

Driver License 3rd Permit Restriction End Date (DDLPD3)

Driver License 3rd Permit Restriction Explanation (DDLPE3)

CDL1.3.4 Transmission of Driver History Convictions (H3) Message

If the driver's record contains convictions that have corresponding, currently valid AAMVA Code Dictionary (ACD)

codes, the SOR sends the Driver History Convictions (H3) message. Convictions that have retired ACD codes are not

sent. Convictions which are not described by an ACD code are not sent. Up to 50 ACD convictions may be sent on the

Driver History Convictions (H3) message. If the driver has more than 50 ACD convictions on record, the SOR/Old

SOR sends the most recent 50 ACD convictions in the Driver History Convictions (H3) message and mails all of the

ACD convictions, withdrawals and linkages.

Note: Jurisdictions must make sure that duplicate convictions are not sent out as history. See "CD11.3 Process

Conviction (State of Record (SOR))" for the criteria for duplicate convictions.

The Driver History Convictions (H3) must contain the following:


message







System Release Code (GMSSRL) set to the valid code in the ŖAPPENDIX D - DATA DICTIONARYŗ (Řblankř,

ŘFř, or ŘHř) indicating the CDLIS release version currently implemented by the SOR/Old SOR






Citation Date (DCIDCI) set to the date of the original citation, court ruling of an FTC, or administrative ruling of

an Admin per se was issued

If sent, the H3 message must contain 1 to 50 convictions. For each conviction sent, the H3 message must include the

following based on the dates indicated:

For convictions with Citation Date (DCIDCI) on or after April 1, 1992, the H3 message must include the

following:

Jurisdiction Code - Convicting (DCVJUR) set to the jurisdiction code of the State of Conviction

Conviction Date (DCVDCV) set to the date on which the conviction, such as an FTC or Admin per se,

was adjudicated

Conviction Court Type (DCVCRT) set to the appropriate code for the type of court, such as "traffic court"





or "administrative adjudication", that finalized the conviction

Conviction Offense ACD Code (DCVCCA) set to the appropriate code from the current ACD manual

Depending on the Conviction Offense ACD Code (DCVCCA), the following field is blank, optional, or

requiredŕsee the note below on FTA/FTP and the AAMVA Code Dictionary Manual for details:

Conviction Offense Detail - ACD (DCVCDA) set to the appropriate value

For convictions with Citation Date (DCIDCI) on or after October 1, 2005, the H3 message must include the

following:





unknown,








set to '2' if the driver was not carrying hazardous materials when the violation occurred, or

if unknown





Citation CDL Holder Indicator (DCICHI) set to the appropriate code Ŕ for a conviction with a citation

date on or after January 1, 2008, the code must be set to Ř1ř or Ř2ř

If the conviction resulted in a withdrawal reported in the H7 message, the following must be included:

Conviction ID Code (DCVCID) set to the identifier for the conviction within this transaction; the

conviction identifier must also appear in the H7 message to tie the conviction to the withdrawal.

Jurisdictions may use any identifier they wish of the 1,296 unique values possible, but, as a best practice,

the identifier should be a sequential code, such as '00' to '99', 'A0' to 'Z9', '0A' to '9Z', and 'AA' to 'ZZ'.

For convictions with Citation Date (DCIDCI) on or after January 1, 2008, the H3 message must include the

following:

Conviction Jurisdiction Court Report ID (DCVCLO) set to the reference number assigned by the SOC

that identifies the individual court report

Conviction Jurisdiction Offense Code (DCVCOR) set by the SOC to the SOC's native state code

indicating the type of offense

For convictions with Citation Date (DCIDCI) on or after January 1, 2008 and for all ŘMajorř, ŘFalsifyř, and

ŘPATRIOT Actř (see Appendix C in the ACD Manual) convictions with a citation date on or after April 1, 1992,

the H3 message must include the following:

Conviction Court Type (DCVCRT) set to the appropriate code for the type of court, such as "traffic court"

or "administrative adjudication", that finalized the conviction

If sent, the Driver History Convictions (H3) message must contain 1 to 50 convictions. For each conviction sent, the

Driver History Convictions (H3) message must include the following:

Jurisdiction Code - Convicting (DCVJUR) set to the jurisdiction code of the State of Conviction





Citation Date (DCIDCI) set to the date of the original citation, court ruling of an FTC, or administrative ruling of

an Admin per se was issued

Conviction Date (DCVDCV) set to the date on which the conviction, such as an FTC or Admin per se, was

adjudicated

Conviction Commercial Vehicle Indicator (DCVCOM) set to the appropriate code

Conviction HAZMAT Indicator (DCVHAZ) set to the appropriate code

Conviction Offense ACD Code (DCVCCA) set to the appropriate code from the current AAMVA Code

Dictionary (ACD) Manual

Citation CDL Holder Indicator (DCICHI) set to the appropriate code

For convictions with Citation Date (DCIDCI) on or after January 1, 2008, the H3 message must include the following:

Conviction Jurisdiction Court Report ID (DCVCLO) set to the reference number assigned by the SOC that

identifies the individual court report

Conviction Jurisdiction Offense Code (DCVCOR) set by the SOC to the SOC's native state code indicating the

type of offense

For convictions with Citation Date (DCIDCI) on or after January 1, 2008 and for all ŘMajorř, ŘFalsifyř, and ŘPATRIOT

Actř (see Appendix C in the AAMVA Code Dictionary (ACD) Manual ) convictions with a citation date on or after

April 1, 1992, the H3 message must include the following:

Conviction Court Type (DCVCRT) set to the appropriate code for the type of court, such as "traffic court" or

"administrative adjudication", that finalized the conviction

For each conviction sent, up to a limit of 50 convictions, the Driver History Convictions (H3) message must include all

available data for the following:

Conviction Offense Detail - ACD (DCVCDA) set to the appropriate code Ŕ depending on the Conviction

Offense ACD Code (DCVCCA) value, this field is blank, optional, or requiredŕsee the note below on FTA/FTP

and the AAMVA Code Dictionary (ACD) Manual for details

Conviction ID Code (DCVCID) set to the identifier for the conviction within this transaction Ŕ if the conviction

resulted in a withdrawal reported in the Driver History Withdrawal-Conviction Links (H7) message, the

conviction identifier must also appear in the Driver History Withdrawal-Conviction Links (H7) message to tie

the conviction to the withdrawal. Jurisdictions may use any identifier they wish of the 1,296 unique values

possible, but, as a best practice, the identifier should be a sequential code, such as '00' to '99', 'A0' to 'Z9', '0A' to

'9Z', and 'AA' to 'ZZ'.

Notes:

In accordance with FMCSA policy, if a jurisdiction issues a Failure to Appear (FTA) or Failure to Pay (FTP) or Failure

to Comply (FTC) for an out-of-state CDL driver, the jurisdiction issuing the FTA/FTP/FTC must report the

FTA/FTP/FTC to the SOR. The SOR must retain the FTA/FTP/FTC in the driver history record according to the data

retention requirements of the underlying citation. When responding to a State-to-State History Request, the SOR must

send all the FTA/FTP/FTCs retained in the driver history record, either in the Driver History Convictions (H3) message

or by some other means if more than 50 convictions exist on the record. When an FTA/FTP/FTC conviction is

transmitted in the history, the Conviction Offense ACD Code (DCVCCA) must contain the code for the FTA/FTP/FTC

(e.g., 'D56' "Failure to answer a citation, pay fines, penalties and/or costs related to the original violation") and the

Conviction Offense Detail - ACD (DCVCDA) must contain the code for the citation associated with the FTA/FTP/FTC,

if available (e.g., 'A04' "Driving under the influence of alcohol with BAC at or over 0.04").

For convictions entered in the history prior to 10/1/2005, the ACD code for the underlying violation is not required in

the Conviction Offense Detail - ACD (DCVCDA). All D45, D53, and D56 convictions with a conviction date before

October 1, 2005 must be allowed on the Driver History Convictions (H3) without detail.

A jurisdiction must not send convictions with retired ACD codes as part of the history response in a Driver History

Convictions (H3) message. Each jurisdiction can choose whether or not to keep these convictions with retired ACD

codes on their own internal record, but these Ŗnon-ACDŗ convictions are not part of the total convictions on the driver

history record. Because the retired ACD codes are not safety related or federally mandated, the SOR is not altering the





salient driver history for commercial drivers if it purges convictions with retired codes from the driver history.

The table below indicates the valid values for the following data elements based on the citation date:



Citation CDL Holder Indicator (DCICHI)

Citation Date Valid Values

≥ April 1, 1992 and ≤ September 30, 2005 <blank>, Ř1ř, Ř2ř, or Ř9ř

≥ October 1, 2005 and ≤ December 31, 2007 Ř1ř, Ř2ř, or Ř9ř*

≥ January 1, 2008 to present Ř1ř or Ř2ř†

* 'blank' values must be changed to a '9', and the SOR must document its research to determine the correct value.

† Unknown values must be changed to Ř2ř and the SOR must document its research to determine the correct value

Although convictions for ACD violations in a non-CMV prior to obtaining a CDL are not used to disqualify a CDL

holder, if a driver is issued a CDL, these convictions are treated as ŖCDLIS convictionsŗ. They are subject to data

validation rules for required and optional data, to data retention requirements, and to data transmission rules, and must

pass those rules before being added to the driver history record.


values.

CDL1.3.5 Transmission of Driver History Accidents (H4) Message

If the driver record contains accident information, the SOR/Old SOR sends the Driver History Accidents (H4) message.

Up to 50 accidents may be sent on the Driver History Accidents (H4) message. If the driver has more than 50 accidents

on record, the SOR/Old SOR sends the most recent 50 accidents in the Driver History Accidents (H4) message and

mails all of the accidents to the inquirer.

The Driver History Accidents (H4) message must contain the following:


message


Message Match Count (GMSCNT) set to the '01'





System Release Code (GMSSRL) set to the valid code (ŘFř, or ŘHř) in the ŖAPPENDIX D - DATA

DICTIONARYŗ indicating the CDLIS release version currently implemented by the SOR/Old SOR






If sent, the Driver History Accidents (H4) message must include 1 to 50 accidents. For each accident sent, the

following data elements must be sent:

Accident Jurisdiction Code (DACJUR) set to the appropriate jurisdiction code in which the accident occurred





Accident Date (DACDAT) set to the appropriate date

Accident Severity Code (DACSEV) set to the appropriate code

Driver Accident Commercial Vehicle Indicator (DDACOM) set to the appropriate code

Driver Accident HAZMAT Indicator (DDAHAZ) set to the appropriate code

Accident Locator Reference (DACLOC) set to the appropriate reference number


values.

CDL1.3.6 Transmission of Driver History Withdrawals (H5) Message

If the driver's record contains withdrawals having a corresponding ACD code, the SOR sends the Driver History

Withdrawals (H5) message (exception: out-of-state withdrawals with an ACD code of ŘW00ř are not required to be

sent). One to 50 withdrawals may be sent on the Driver History Withdrawals (H5) message. If the driver has more than

50 withdrawals on record, the SOR/Old SOR must transmit the most recent 50 withdrawals in the Driver History

Withdrawals (H5) message and must mail all of the ACD convictions, withdrawals, and linkages.

Note: To document that each withdrawal is posted within 10 days of its reception, the SOR/Old SOR must maintain

internally the "Date Withdrawal Received" and "Date Withdrawal Posted to the CDLIS driver history" for each ACD

withdrawal the SOR/Old SOR receives or takes on one of its drivers. Typically, for withdrawals sent electronically,

these dates will differ by one day or less. For withdrawals sent by mail, the "posted" date might be significantly later

than the "received" date. The SOR retains these dates only as long as it is the current SOR for the given driver. The

SOR/Old SOR does not transmit these dates in the driver history.

Note: Jurisdictions must make sure that duplicate withdrawals are not sent out as history. See "CD16.3 Process

Withdrawal (State of Record (SOR))" for the criteria for duplicate withdrawals.

The Driver History Withdrawals (H5) message must include the following:


message







System Release Code (GMSSRL) set to the valid code (Řblankř, ŘFř, or ŘHř) in ŖAPPENDIX D - DATA

DICTIONARYŗ indicating the CDLIS release version currently implemented by the SOR/Old SOR






If sent, the Driver History Withdrawals (H5) message must include 1 to 50 withdrawals. For each withdrawal sent, the

following data elements must be sent:


withdrawal

Driver License Withdrawal Effective Date (DWDDWD) set to the date the withdrawal period starts

Driver License ACD Withdrawal Reason Code (DWDWRS) set to the appropriate code

Driver License Withdrawal Eligibility Date (DWDWDE) set to the date the driver can apply for reinstatement

For withdrawals with Driver License Withdrawal Effective Date (DWDDWD) on or after January 1, 2008 and for all





ŘMajorř, ŘFalsifyř, and ŘPATRIOT Actř (see Appendix C in the AAMVA Code Dictionary (ACD) Manual )

withdrawals with an effective date on or after April 1, 1992, the H5 message must include the following:





For withdrawals with Driver License Withdrawal Effective Date (DWDDWD) on or after January 1, 2008, the H5

message must include the following:

Driver License Withdrawal Jurisdiction Report ID (DWDWLO) set to the appropriate reference number

Driver License ACD Withdrawal Reason Reference (DWDWRR) set to the native state code identifying the

reason for the withdrawal


ŘMajorř, ŘFalsifyř, and ŘPATRIOT Actř (see Appendix C in the ACD Manual) withdrawals with an effective date on or

after April 1, 1992, the H5 message must include the following:





For each withdrawal sent, up to a maximum of 50 withdrawals, the Driver History Withdrawals (H5) must include all

available data for the following:

Driver License Withdrawal Reinstatement Date (DWDWDR) set to the date the withdrawal period ended

Driver License Withdrawal ID Code (DWDWID) set to the identifier for the withdrawal within the transaction--

If the withdrawal has underlying convictions identified in the Driver History Withdrawal-Conviction Links (H7)

message, the withdrawal identifier must also appear in the Driver History Withdrawal-Conviction Links (H7)

message to tie the withdrawal to its underlying ACD conviction(s). Jurisdictions may use any identifier they

wish of the 1,296 unique values possible, but, as a best practice, the identifier should be a sequential code, such

as '00' to '99', 'A0' to 'Z9', '0A' to '9Z', and 'AA' to 'ZZ'.

Notes:

A jurisdiction must not send withdrawals with retired ACD codes as part of the history response in a Driver History

Withdrawals (H5) message. Each jurisdiction can choose whether or not to keep withdrawals with retired ACD codes

on its own internal record, but these Ŗnon-ACDŗ withdrawals are not part of the total withdrawals on the driver history

record. Because the retired ACD codes are not safety related or federally mandated, the SOR is not altering the salient

driver history for commercial drivers if it purges withdrawals with retired codes from the driver history.

Although withdrawals for ACD violations in a non-CMV prior to obtaining a CDL are not used to disqualify a CDL

holder, if a driver is issued a CDL, these withdrawals are treated as ŖCDLIS withdrawalsŗ. They are subject to data

validation rules for required and optional data, to data retention requirements, and to data transmission rules, and must

pass those rules before being added to the driver history record.

Since the "W00" was created specifically for situations where an SOR has a current withdrawal that does not map to an

ACD code, the "W00" should only be sent in a message if the withdrawal is currently in effect, however at the SORřs

option, the SOR may transmit other W00 code withdrawals, including inactive W00 code withdrawals and out-of-state

W00 code withdrawals. Since an SOR is not required to transmit inactive W00 withdrawals in the history response

messages, the SOR is not required to retain a W00 withdrawal in the history past its reinstatement date.

If a given driver has only a "W00" code withdrawal issued by the SOR, and the driver has no ACD convictions on

record, then the SOR only sends the Driver History Withdrawals (H5) message, which lists the W00 code withdrawalŕ

the SOR sends neither the Driver History Convictions (H3) message nor the Driver History Withdrawal-Conviction

Links (H7) message in the history response.






values.

CDL1.3.7 Transmission of Driver History Withdrawal-Conviction Links (H7) Message

Each withdrawal of a driver with a pointer on CDLIS that is the result of ACD conviction(s) and with a withdrawal

effective date of November 1, 2005 or later must be linked to all of its underlying ACD conviction(s) in the driver

history. If the driver's record contains at least one linkage (i.e., one withdrawal linked to all of its underlying ACD

convictions), the SOR/Old SOR sends the Driver History Withdrawal-Conviction Links (H7) message.

If sent, the Driver History Withdrawal-Conviction Links (H7) message must contain 1 to 50 withdrawal-conviction

linkages. If the driver has more than 50 withdrawal-conviction linkages on record, the most recent 50 withdrawal-

conviction linkages are sent in the Driver History Withdrawals (H5) message, with the following possible exceptions:

If a withdrawal is not sent in the Driver History Withdrawals (H5) message, the SOR must not send its linkage in

the Driver History Withdrawal-Conviction Links (H7) message.

If a withdrawal is sent in the Driver History Withdrawals (H5) message but none of the underlying convictions

are sent in the Driver History Convictions (H3) message, the SOR must not send its linkage in the Driver History

Withdrawal-Conviction Links (H7) message.

If a withdrawal is sent in the Driver History Withdrawals (H5) message and at least one underlying conviction

but not all underlying convictions are sent in the Driver History Convictions (H3) message, the SOR either (1)

must not send the linkage or (2) must send an incomplete linkage that includes the Withdrawal ID and the

Conviction IDs for the convictions sent in the Driver History Convictions (H3) message.

If the SOR/Old SOR does not transmit all the linkages via CDLIS, the SOR must mail all the driver history convictions,

withdrawals, and withdrawal-conviction linkages.

The Driver History Withdrawal-Conviction Links (H7) must include the following:


message







System Release Code (GMSSRL) set to the valid code (ŘFř, or ŘHř) in ŖAPPENDIX D - DATA DICTIONARYŗ

indicating the CDLIS transaction version currently implemented by the SOR/Old SOR







values.

If sent, the Driver History Withdrawal-Conviction Links (H7) message includes 1 to 50 withdrawal-conviction(s)

linkages. For each withdrawal-conviction(s) linkage sent, the following must be sent:

Driver License Withdrawal ID Conviction Link (DWDWI2) set to the identifier in the Driver History

Withdrawals (H5) message

Driver License Withdrawal-Conviction Links Group (DWDCLG) composed of 1-14 occurrences of the

following data element:

o Conviction ID Code, Linked to Withdrawal (DCVCI2) set to the identifier of an ACD conviction

underlying the withdrawal--The conviction identifier must also appear in the Driver History Convictions




(H3) message.

CDL1.3.8 Transmission of the Driver History Request (SB) Message with Errors

The information in "CDL1.3.8 Transmission of the Driver History Request (SB) Message with Errors" applies only

when processing a Driver History Request (SB).

If the SOR encounters errors which preclude processing or the SOR cannot locate a record based on the information

submitted by the SOI (a 'no hit'), the SOR returns the original Driver History Request (SB) to the SOI. The Driver

History Request (SB) is returned exactly as received with the following exceptions:


Processing Status Code (GPROST) set to

o '01' (logic error) if the driver could not be located

o '03' (syntax error) if processing could not be performed

System Release Code (GMSSRL) set to the valid code in ŖAPPENDIX D - DATA DICTIONARYŗ indicating

the release version used by the SOR




values.

CDL1.3.9 Transmission of the CSOR History Request (SD) Message with Errors

The information in "CDL1.3.9 Transmission of the CSOR History Request (SD) Message with Errors" applies only

when processing a CSOR History Request (SD) message.

If the Old SOR encounters errors that preclude processing or if the Old SOR cannot locate a record based on the

information submitted by the New SOR, the Old SOR returns the original CSOR History Request (SD) to the CDLIS

Central Site. The CSOR History Request (SD) message is returned exactly as submitted with the following exceptions:








See 'Error Block Format' under Edit/Error Description Block (25/1).


values.

The CDLIS Central Site logs the returned CSOR History Request (SD) and makes an entry in the System Error file as a

broken pointer. The Old SOR must then determine why the broken pointer condition exists and resolve the situation.

The AAMVA Operations Help Desk will provide all assistance possible.



CDM1 PROCESS HISTORY RESPONSE (INQUIRER)



CDM1.1 Reception




Social Security Number) matches. The SOI may also consider secondary driver identifying data, such as Sex, Height,


The following information applies when processing either a Driver History Request (SB) or a CSOR History Request

(SD) message:

Using the value of the System Release Code (GMSSRL) transmitted by the SOR, the SOI determines what

information it can expect in the SOR's transmission of the driver history. If the SOR or the SOI is not on the

current CDLIS Release 4.0.1 or later and driver history information valid as of that release cannot be transmitted

or received via CDLIS, the SOR and the SOI must arrange to send and receive the driver history information by

mail.

If, for any other reason, the SOI cannot receive the complete driver history, the SOI must receive whatever driver

history information it can via CDLIS. If it canřt receive the 10-year history check information and intends to use

the information, it must contact the SOR and arrange to receive it by mail. If it cannot receive all the driver

history convictions, withdrawals, and linkages on record, it must contact the SOR and arrange to receive the

complete driver history convictions, withdrawals, and linkages by mail.

CDM1.1.1 Reception of the Driver History Response (HB) Message

The Driver History Response (HB) message is received in response to the Driver History Request (SB) message.

The Driver History Response (HB) message will contain the following:






Processing Status (GPROST) If the CSOR is not complete, the Processing Status (GPROST) must be set

to '05' indicating the SOR is in the middle of a Change State of Record transaction but may have not yet

posted all driver history information. For example, if the driver has only one conviction and it is not yet

posted, the inquirer would not receive a Driver History Convictions (H3) message. The inquirer should

determine if the history received is sufficient or if a new request should be submitted at a later date.





System Release Code (GMSSRL), if in response to a Driver History Request (SB) message
























Total Withdrawal-Conviction Links Sent (DDTTLS)







Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the Driver History Response (HB) message will

include either the Driver Name (DDVNAM), or the Driver Name (DDVNAM) and the Person Name Group

(BPENGP). Once all Jurisdictions have implemented version 5.1 or greater, Driver Name (DDVNAM) will not

be supported on the Driver History Response (HB) message any more.

The Driver History Response (HB) message must contain all available data for the following:









Driver License Endorsement Code (DDLEND), zero to five occurrences






Driver License History Check Inquiring Jurisdiction (DDLHCI)

Driver License History Check Date (DDLHCD)





Driver License History Check Response Total (DDLHCT)

Driver License History Check Response List (DDLHCL) containing 0 to 15 occurrences of the following

data element, if a 10-year history check has been initiated; otherwise left blank



Driver License History Check Request Total (DDLHCR)



Driver License Restriction Code (DDLRSC), 0 to 12 occurrences

Driver License Restriction End Date (DDLRSD), 0 to 12 occurrences

Driver License Restriction Explanation (DDLRSE), 0 to 12 occurrences

Return as Received (GRRECV)








Driver AKA 3rd

Name (DDVKN3)

Transitional Note:

Until all Jurisdictions have implemented version 5.1 or greater, the Driver History Response (HB) message will

include AKA name information either in the old name format (Driver AKA Name (DDVKNM) etc), or in both

the old name format and in the new name format (Person AKA Name Group (BPENG3)). Once all Jurisdictions

have implemented version 5.1 or greater, the old name format will not be supported on the Driver History

Response (HB) message any more.

The Driver History Response (HB) message must contain all available data for the following Medical Certificate

information:















The Driver History Response (HB) message is used by the SOR to transmit information on a driver located in its





database. It can also be used to notify the inquirer that the driver was not located (a 'broken pointer' situation). Where

the Driver History Response (HB) is notifying the inquirer that the driver was not located, the inquirer should check the

following data elements to determine whether or not a match was found:

NCB Error Code (GNCBER) set to 'N' is the driver was located; 'Y' if not

Message Match Indicator (GMSIND) set to 'Y' is the driver was located; 'N' if not

Processing Status (GPROST) set to '00' is the driver was located; '01' (logic error) if not

If the Driver History Response (HB) is in response to a Driver History Request (SB) message and the SOI determines

that the SOR found a match, the SOI then checks the System Release Code (GMSSRL) to determine what information it

can expect in the SOR's transmission of the driver history. If the SOR and SOI are not both on CDLIS Release 4.0.1 or

later, the SOR must transmit via CDLIS the information they can, including any convictions and withdrawals with new

ACD codes and must arrange to send and receive all driver history convictions, withdrawals, and linkages by mail.

When the inquirer receives the Driver History Response (HB) message, the inquirer determines the number of Permit,

Conviction, Accident, Withdrawal, and Withdrawal-Conviction Links messages that will be received by evaluating the

following fields:

Driver License Number of Permits (DDLNMP); a value of zero indicates no Driver History Permit Info (H2)

message is expected; other values indicate one Driver History Permit Info (H2) will be received from the SOR.

Total Convictions Sent (DDTTCS); a value of zero indicates no Driver History Convictions (H3) message is

expected; other values indicate one Driver History Convictions (H3) will be received from the SOR

Total ACD Convictions on Record (DDTTCR), a value that is more than the Total Convictions Sent (DDTTCS)

indicates the SOR must mail all convictions to the inquirer

Total Accidents Sent (DDTTAS); a value of zero indicates no Driver History Accidents (H4) message is

expected; other values indicate one Driver History Accidents (H4) will be received from the SOR

Total Accidents on Record (DDTTAR), a value that is more than the Total Accidents Sent (DDTTAS) indicates

the SOR must mail additional accidents to the inquirer

Total Withdrawals Sent (DDTTWS); a value of zero indicates no Driver History Withdrawals (H5) message is

expected; other values indicate one Driver History Withdrawals (H5) will be received from the SOR

Total Withdrawals on Record (DDTTWR), a value that is more than the Total Withdrawals Sent (DDTTWS)

indicates the SOR must mail additional withdrawals to the inquirer

Total Withdrawal-Conviction Links Sent (DDTTLS); a value of zero indicates no Driver History Withdrawal-

Conviction Links (H7) message is expected; other values indicate one Driver History Withdrawal-Conviction

Links (H7) will be received from the SOR

Total Withdrawal-Conviction Links on Record (DDTTLR), a value that is more than the Total Withdrawal-

Conviction Links Sent (DDTTLS) indicates the SOR must mail additional withdrawal-conviction(s) linkages to

the inquirer

CDM1.1.2 Reception of the CSOR Driver History Response (HD) Message

The CSOR Driver History Response (HD) message is received in response to the CSOR Driver History Request (SD)

message.

The CSOR Driver History Response (HD) message will contain the following:


































Total Withdrawal-Conviction Links Sent (DDTTLS)




The CSOR Driver History Response (HD) message must contain all available data for the following:












Driver License Endorsement Code (DDLEND), zero to five occurrences


Driver License History Check Inquiring Jurisdiction (DDLHCI)

Driver License History Check Date (DDLHCD)

Driver License History Check Response Total (DDLHCT)





Driver License History Check Responding States List (DDLHCL) containing 0 to 15 occurrences of the

following data element, if a 10-year history check has been initiated; otherwise left blank



Driver License History Check Response Total (DDLHCR)



Driver License Restriction Code (DDLRSC), 0 to 12 occurrences

Driver License Restriction End Date (DDLRSD), 0 to 12 occurrences

Driver License Restriction Explanation (DDLRSE), 0 to 12 occurrences




The CSOR Driver History Response (HD) message must contain all available data for the following Medical Certificate

information:















The CSOR Driver History Response (HD) message is used by the Old SOR to either transmit information on a driver

located in its database or to notify the New SOR that the driver was not located (a 'broken pointer' situation). The New

SOR should check the following data elements to determine whether or not a match was found:

NCB Error Code (GNCBER): set to 'N' is the driver was located; 'Y' if not

Message Match Indicator (GMSIND): set to 'Y' is the driver was located; 'N' if not

Processing Status (GPROST): set to '00' is the driver was located; '01' (logic error) if not

If a match is found, the New SOR checks the System Release Code (GMSSRL). Using the value of the System Release

Code (GMSSRL), the New SOR determines what information it can expect in the Old SOR's transmission of the driver

history. If the Old SOR and New SOR are not both on CDLIS Release 4.0.1 or later, they must transmit via CDLIS the

information they can and must arrange to send and receive the remaining driver history information required as of

Release 4.0.1, if available, by mail.

When the CSOR Driver History Response (HD) message is received, the New SOR determines the number of Permit,

Conviction, Accident, Withdrawal, and Withdrawal-Conviction Links messages that will be received by evaluating the

following fields:

Driver License Number of Permits (DDLNMP): a value of zero indicates no Driver History Permit Info (H2)

message is expected; other values indicate one Driver History Permit Info (H2) will be received from the Old





SOR

Total Convictions Sent (DDTTCS): a value of zero indicates no Driver History Convictions (H3) message is

expected; other values indicate one Driver History Convictions (H3) will be received from the Old SOR

Total ACD Convictions on Record (DDTTCR), a value that is more than the Total Convictions Sent (DDTTCS)

indicates the Old SOR will mail additional convictions to the New SOR

Total Accidents Sent (DDTTAS): a value of zero indicates no Driver History Accidents (H4) message is

expected; other values indicate one Driver History Accidents (H4) will be received from the Old SOR

Total Accidents on Record (DDTTAR), a value that is more than the Total Accidents Sent (DDTTAS) indicates

the Old SOR will mail additional accidents to the New SOR

Total Withdrawals Sent (DDTTWS): a value of zero indicates no Driver History Withdrawals (H5) message is

expected; other values indicate one Driver History Withdrawals (H5) will be received from the Old SOR

Total Withdrawals on Record (DDTTWR), a value that is more than the Total Withdrawals Sent (DDTTWS)

indicates the Old SOR will mail additional withdrawals to the New SOR

Total Withdrawal-Conviction Links Sent (DDTTLS): a value of zero indicates no Driver History Withdrawal-

Conviction Links (H7) message is expected; other values indicate one Driver History Withdrawal-Conviction

Links (H7) will be received from the Old SOR

Total Withdrawal-Conviction Links on Record (DDTTLR), a value that is more than the Total Withdrawal-

Conviction Links Sent (DDTTLS) indicates the Old SOR will mail additional withdrawal-conviction(s) linkages

to the New SOR

CDM1.1.3 Reception of the Driver History Permit Info (H2) Message

The Driver History Permit Info (H2) message is received in response to either the Driver History Request (SB) message

or the CSOR Driver History Request (SD) message.

The Driver History Permit Info (H2) message must contain the following:









The Driver History Permit Info (H2) message must contain all available data for the following:


The Driver History Permit Info (H2) message may contain up to three permits. For each permit sent, the Driver History

Permit Info (H2) message must contain all available information for the following:





Driver License Number of Permit Restrictions (DDLRPN)

For each permit that has any endorsements, the Driver History Permit Info (H2) must include all available information

for the following:

Driver License Permit Endorsement Group Code (DDLEP1)

The Driver History Permit Info (H2) message may optionally contain up to 12 permit restrictions for each permit sent.





For each restriction sent on the first permit, the Driver History Permit Info (H2) message must contain all available data

for the following:


Driver License1st Permit Restrict End Date (DDLPD1)


For each restriction sent on the second permit, the Driver History Permit Info (H2) message must contain all available

data for the following:




For each restriction sent on the third permit, the Driver History Permit Info (H2) message must contain all available data

for the following:




CDM1.1.4 Reception of the Driver History Convictions (H3) Message

The Driver History Convictions (H3) message is received in response to either the Driver History Request (SB) message


The Driver History Convictions (H3) message contains 1 to 50 convictions. If the driver has more than 50 convictions

on record, the SOI should expect the SOR to transmit the most recent 50 convictions in the Driver History Convictions

(H3) message and all of the convictions, withdrawals, and linkages via mail.

The Driver History Convictions (H3) message must contain the following:









The Driver History Convictions (H3) message may optionally contain the following:


For each conviction in the Driver History Convictions (H3) message, the Driver History Convictions (H3) message

must contain the following:







Conviction Offense ACD Code (DCVCCA), to help ensure data integrity, the inquirer should edit and validate

conviction offense codes received from other jurisdictions to identify errors that, if not corrected, would interfere

with the inquirer's ability to interpret the data.






For convictions with Citation Date (DCIDCI) on or after January 1, 2008, the H3 message must include the following



For each conviction in the Driver History Convictions (H3) message, the Driver History Convictions (H3) message

must contain the following, depending on certain conditions:

Conviction Offense Detail - ACD (DCVCDA) Ŕ depending on the value of the ACD code, the detail field is

required, optional, or Řnullř. Notes: To help ensure data integrity, the inquirer should edit and validate

conviction offense detail codes received from other jurisdictions. Prior to 10/1/2005, the ACD code for the

underlying violation is not required in the Conviction Offense Detail - ACD (DCVCDA) for an FTA/FTP/FTC

conviction.

Conviction ID Code (DCVCID) -- required if the conviction is listed in a linkage in the Driver History

Withdrawal-Conviction Links (H7) message, otherwise optional

Notes: Jurisdictions must have procedures in place to identify duplicate convictions received in a history response. See

"CD11.3 Process Conviction (State of Record (SOR))" for the criteria for duplicate convictions.

CDM1.1.5 Reception of the Driver History Accidents (H4) Message

The Driver History Accidents (H4) message is received in response to either the Driver History Request (SB) message


The Driver History Accidents (H4) message may contain up to 50 accidents. If the driver has more than 50 accidents on

record, the inquirer should expect the SOR to transmit the most recent 50 accidents in the Driver History Accidents

(H4) message and all of the accidents via mail.

The Driver History Accidents (H4) message must contain the following:









The Driver History Accidents (H4) message may optionally contain:


For each accident in the Driver History Accidents (H4) message, the Driver History Accidents (H4) message must

contain the following:

Accident Jurisdiction Code (DACJUR)

Accident Date (DACDAT)

Accident Severity Code (DACSEV)

Driver Accident Commercial Vehicle Indicator (DDACOM)

Driver Accident HAZMAT Indicator (DDAHAZ)

Accident Locator Reference (DACLOC)

CDM1.1.6 Reception of the Driver History Withdrawals (H5) Message

The Driver History Withdrawals (H5) message is received in response to either the Driver History Request (SB)

message or the CSOR Driver History Request (SD) message.





The Driver History Withdrawals (H5) message may contain up to 50 withdrawals. If the driver has more than 50

withdrawals on record, the inquirer should expect the SOR to transmit the most recent 50 withdrawals in the Driver

History Withdrawals (H5) message and all of the convictions, withdrawals, and linkages via mail.

The Driver History Withdrawals (H5) must include the following:









The Driver History Withdrawals (H5) message may optionally contain:


For each withdrawal in the Driver History Withdrawals (H5) message, the Driver History Withdrawals (H5) message

must contain the following:



Driver License ACD Withdrawal Reason Code (DWDWRS) Ŕ to help ensure data integrity, the inquirer must

edit and validate withdrawal codes received from other jurisdictions--The overall purpose of validating

withdrawal codes is to identify errors that, if not corrected, would interfere with the inquirer's ability to interpret

the data.


For withdrawals with Driver License Withdrawal Effective Date (DWDDWD) on or after January 1, 2008, the H5

message must include the following:


Driver License ACD Withdrawal Reason Reference (DWDWRR)


ŘMajorř, ŘFalsifyř, and ŘPATRIOT Actř (see Appendix C in the AAMVA Code Dictionary (ACD) Manual )

withdrawals with an effective date on or after April 1, 1992, the H5 message must include the following

Driver License Withdrawal Type Detail (DWDWTP)




For each withdrawal, the Driver History Withdrawals (H5) message must contain the following under certain

conditions:

Driver License Withdrawal Reinstatement Date (DWDWDR) Ŕ required if the withdrawal has been reinstated

Driver License Withdrawal ID Code (DWDWID) Ŕ required if the withdrawalřs linkage is sent in the Driver

History Withdrawal-Conviction Links (H7) message, otherwise optional

Notes: Jurisdictions must have procedures in place to identify duplicate withdrawals received in a history response. See

"CD16.3 Process Withdrawal (State of Record (SOR))" for the criteria for duplicate withdrawals.

CDM1.1.7 Reception of the Driver History Withdrawal-Conviction Links (H7) Message

The Driver History Withdrawal-Conviction Links (H7) message is received in response to either the Driver History

Request (SB) message or the CSOR Driver History Request (SD) message.





The Driver History Withdrawal-Conviction Links (H7) message contains 1-50 withdrawal-conviction linkages (a

linkage identifies all of the underlying convictions that resulted in the given withdrawal). If the driver has more than 50

withdrawal-conviction linkages on record, the inquirer should expect the SOR to transmit the most recent 50

withdrawal-conviction linkages in the Driver History Withdrawal-Conviction Links (H7) message and all of the

convictions, withdrawals, and linkages via mail.

The Driver History Withdrawal-Conviction Links (H7) must include the following:









The Driver History Withdrawal-Conviction Links (H7) may optionally contain:


For each withdrawal-conviction link sent, the message must include the following:

Driver License Withdrawal ID Conviction Link (DWDWI2)

Driver License Withdrawal-Conviction Links Group (DWDCLG) composed of following data element,

repeating up to 14 times:

o Conviction ID Code, Linked to Withdrawal (DCVCI2)

The inquirer must use this information with the conviction information in the Driver History Convictions (H3) message

and the withdrawal information in the Driver History Withdrawals (H5) message to identify the underlying convictions

for withdrawals identified in the Driver History Withdrawal-Conviction Links (H7) message. If a disqualifying

conviction occurred after the implementation deadline and no withdrawal has been assessed, the inquirer must check

whether the driver must be disqualified based on the disqualifying conviction in the driver history.

CDM1.1.8 Reception of Driver History Request (SB) or Driver History Response (HB) Message with Errors

The information in "CDM1.1.8 Reception of Driver History Request (SB) or Driver History Response (HB) Message

with Errors" applies only when receiving an error in response to a Driver History Request (SB) message.

If the SOR was unable to locate the driver, the SOR returns the Driver History Request (SB), or sends the Driver

History Response (HB), to the SOI. See "4 CDLIS ERROR PROCESSING" for information on returning errors.

Note: The standard for reporting errors is to return the original messages (the Driver History Request (SB) message)

with the description of the error. In this transaction, the Driver History Response (HB) message may be used to return

the description of the error.

CDM1.1.9 Reception of CSOR Driver History Request (SD) or CSOR Driver History Response (HD) Message with Errors

The information in "CDM1.1.9 Reception of CSOR Driver History Request (SD) or CSOR Driver History Response

(HD) Message with Errors" applies only when receiving an error in response to a CSOR Driver History Request (SD)

message.

If the SOR was unable to locate the driver, the SOR returns the CSOR Driver History Request (SD), or sends the CSOR

Driver History Response (HD), to the SOI. See "4 CDLIS ERROR PROCESSING" for information on returning

errors.

Note: The standard for reporting errors is to return the original messages (the Driver History Request (SB) message)





with the description of the error. In this transaction, the CSOR Driver History Response (HD) message may be used to

return the description of the error.

CDM1.2 Validation of the Driver History Response

While the CDLIS Common Validation Process performs the majority of the necessary validations on the history

responses from the SOR, additional validations must be performed by the New SOR as specified in the following

sections. Validations are especially important for the driver's license details, any conviction details, and any withdrawal

details, because these can contribute to a driver's disqualification.

Jurisdictions must not implement any other data validation checks other than those listed in this section. If an

implementation date is specified, jurisdictions must not implement data validation checks prior to the implement date

nor after the implementation date. If the New SOR detects any errors, it sets the error fields, (see "4 CDLIS ERROR

PROCESSING" for more details), returns the original message to its sender, and stops processing the transaction.

Note: If a jurisdiction is including convictions for retired ACD codes, the inquirer may contact the sending jurisdiction

to confirm all the convictions not received are for retired ACD codes. If the problem is unresolved or continues, the

inquirer should contact the AAMVA Operations Helpdesk and AAMVA will fill out a CDLIS problem report.

AAMVA will try working with the jurisdiction to correct the problem and then notify FMCSA if the jurisdiction does

not correct the problem.


CDM1.2.1 Validation of the Driver History Response (HB) Message

All validations of the Driver History Response (HB) message are performed by the ŖCDN1 APPLY COMMON

VALIDATIONS (CDLIS COMMON VALIDATION PROCESSOR)ŗ in CD08.12.

CDM1.2.2 Validation of the CSOR Driver History Response (HD) Message

All validations of the CSOR Driver History Response (HD) message are performed by the ŖCDN1 APPLY COMMON


CDM1.2.3 Validation of the Driver History Permit Info (H2) Message

All validations of the Driver History Permit Info (H2) message are performed by the ŖCDN1 APPLY COMMON


CDM1.2.4 Validation of the Driver History Convictions (H3) Message

All validations of the Driver History Convictions (H3) message are performed by the ŖCDN1 APPLY COMMON


CDM1.2.5 Validation of the Driver History Accidents (H4) Message

All validations of the Driver History Accidents (H4) message are performed by the ŖCDN1 APPLY COMMON


CDM1.2.6 Validation of the Driver History Withdrawals (H5) Message

All validations of the Driver History Withdrawals (H5) message are performed by the ŖCDN1 APPLY COMMON


CDM1.2.7 Validation of the Driver History Withdrawal-Conviction Links (H7) Message

While most validations on the Driver History Withdrawal-Conviction Links (H7) message are performed by the ŖCDN1

APPLY COMMON VALIDATIONS (CDLIS COMMON VALIDATION PROCESSOR)ŗ process, the following

additional data checks must be performed by the SOI/NSOR.





CDM1.2.7.1 Data Cross-Check Errors

Each Driver License Withdrawal ID Conviction Link (DWDWI2) received on the Driver History Withdrawal-

Conviction Links (H7) message must match one and only one Driver License Withdrawal ID Code (DWDWID) in the

Driver History Withdrawals (H5) message.

Error Text: 'NO MATCHING WITHDRAWAL ID CODE IN H5 MESSAGE'

Each 2-character conviction identifier in the Driver License Withdrawal Convictions Links Group (DWDCLG) received

on the Driver History Withdrawal-Conviction Links (H7) message must match one and only one Conviction ID Code

(DCVCID) in the Driver History Convictions (H3) message.

Error Text: 'NO MATCHING CONVICTION ID CODE IN H3 MESSAGE'

A conviction ID code in the Driver License Withdrawal Convictions Links Group (DWDCLG) for a given linkage in

the Driver History Withdrawal-Conviction Links (H7) message must not be repeated within a given Driver License

Withdrawal Convictions Links Group (DWDCLG).

Error Text: 'REPEATED CONVICTION IDS IN CONVICTIONS LINKS GRP'

CDM1.3 Transmission

If the inquirer encounters errors in the Driver History Response (HB) message, the inquirer either

Returns the Driver History Response (HB) message in error or

Manually notifies the SOR of the error.

If the inquirer encounters errors in the CSOR Driver History Response (HD) message, the inquirer either

Returns the CSOR Driver History Response (HD) message in error or

Manually notifies the SOR of the error.

If the inquirer finds an error on a Driver History Permit Info (H2) through Driver History Withdrawal-Conviction Links

(H7) messages, the inquirer must do one of the following:

Return the corresponding Driver History Response (HB) message with error block(s) explaining the error(s) on

the Driver History Permit Info (H2) through Driver History Withdrawal-Conviction Links (H7) messages;

Return the erroneous Driver History Permit Info (H2) through Driver History Withdrawal-Conviction Links (H7)

messages with error block(s) explaining the error(s) or

Manually notify the SOR/Old SOR of the error.

CDM1.3.1 Transmission of Driver History Response (HB) Messages with Errors

As of January 1, 2008, if errors are encountered on the Driver History Response (HB) message, the inquirer must return

it exactly as transmitted with the following exceptions:




CDM1.3.2 Transmission of CSOR Driver History Response (HD) Message with Errors

As of January 1, 2008, if errors are encountered on the CSOR Driver History Response (HD) message, the inquirer must

return it exactly as transmitted with the following exceptions:








-or-

Accept the CSOR Driver History Response (HD)

Contact the Old SOR by telephone, fax, or email informing the Old SOR that errors were discovered on the

Driver History Response(s); if requested by the New SOR, the Old SOR should send a fax of the CSOR Driver

History Response (HD) message along with all associated messages (Driver History Permit Info (H2), Driver

History Convictions (H3), Driver History Accidents (H4), Driver History Withdrawals (H5), and Driver History

Withdrawal-Conviction Links (H7)) received.

CDM1.3.3 Transmission of Other Driver History Messages with Errors

As of January 1, 2008, if errors are encountered on the Driver History Permit Info (H2), Driver History Convictions

(H3), Driver History Accidents (H4), Driver History Withdrawals (H5), and/or Driver History Withdrawal-Conviction

Links (H7) messages, the inquirer must do one of the following but not both:

either return the original Driver History Response (HB) message exactly as received with the following

exceptions:


o Processing Status (GPROST) set to '03' (Syntax Error)



or return the message for which the error was encountered exactly as received (Driver History Permit Info (H2),

Driver History Convictions (H3), Driver History Accidents (H4), Driver History Withdrawals (H5), and/or

Driver History Withdrawal-Conviction Links (H7)) with the following exceptions:


o Processing Status (GPROST) set to '03' (Syntax Error)



After returning the Driver History Response electronically, the inquirer should contact the SOR by telephone or email

informing the SOR that they returned one or more history messages. If requested by the inquirer, the SOR should send

a fax of the Driver History Response (HB) message along with all associated messages (Driver History Permit Info

(H2), Driver History Convictions (H3), Driver History Accidents (H4), Driver History Withdrawals (H5), and Driver

History Withdrawal-Conviction Links (H7)) received. The SOR has the responsibility to identify the error message

received electronically and make the necessary corrections, whether or not the inquirer has contacted the SOR.



CDN1 APPLY COMMON VALIDATIONS (CDLIS COMMON VALIDATION PROCESSOR)



CDN1.1 Introduction

The CDLIS Common Validation Processor intercepts response messages sent from the SOR to the transaction

originator and performs a common set of validations on those messages. If errors are found, the messages are returned

to the SOR and to the transaction originator with error descriptions attached. If no errors are found, the CDLIS Common

Validation Processor forwards the history messages to the transaction originator.

CDN1.2 Reception

Upon receipt of a given message, the CDLIS Common Validation Processor initiates validation processing specific to

the Application Id and Message Type received.

The following message types are received and processed by the CDLIS Common Validation Processor. Reference to

applicable transactions is included with each message type.

Driver History Response (HB) Message, as part of transaction CD04

CSOR Driver History Response (HD) Message, as part of transaction CD08

Driver History Permit Information (H2) Message, as part of transactions CD04 and CD08

Driver History Convictions (H3) Message, as part of transactions CD04 and CD08

Driver History Accidents (H4) Message, as part of transactions CD04 and CD08

Driver History Withdrawals (H5) Message, as part of transactions CD04 and CD08

Driver History Withdrawal-Conviction Links (H7) Message, as part of transactions CD04 and CD08

CDN1.3 Validation

CDN1.3.1 Validation of the Driver History Response (HB) and CSOR Driver History Response (HD) Message

CDN1.3.1.1 System Errors


CDN1.3.1.2 Required Data Errors

Either at least one component field of Person Name Group (BPENGP) must be present or Driver Name (DDVNAM)

must be present.


Transitional note

Until such time as all Jurisdictions have implemented version 5.1 or later, messages processed by the CDLIS Common

Validation Processor may contain name information in the old and/or the new name format. When all Jurisdictions

have implemented version 5.1 or later, name information on all messages will be rendered in the new name format.




(DDLJDL).








CDN1.3.1.3 Invalid Data Errors




Person Name Group (BPENGP), if present, must conform to the requirements listed in "APPENDIX E.3 - AAMVA




Driver Name (DDVNAM), if present, must conform to the requirements listed in ŖAPPENDIX E.1 Ŕ AAMVA




DICTIONARYŗ.


System Release Code (GMSSRL) must be set to spaces, 'F', or ŘHř.


CDL Medical Self Certification Code (DDLSCT), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID SELF CERTIFICATION CODE'

Medical Certificate Status Code (DMCCTC), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID MED CERT STATUS CODE'

If at least one component of Medical Examiner Name Group (BMPNGP) is present, then Medical Examiner Name

Group (BMPNGP) must conform to the requirements listed in "APPENDIX E.3 - AAMVA PERSON NAME

STANDARD (2008) VALIDATIONS"



Medical Licensing Jurisdiction Code (BMPJO1), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID MED EXAMINER JURISDICTION'

Medical Examiner Telephone Number (BMPTP1), if present, must contain 10 characters.

Error Text: 'INVALID MED EXAMINER PHONE NUMBER'

Medical Examiner Specialty Code (BMPSP1), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.





Error Text: 'INVALID MED EXAMINER SPECIALTY CODE'

Medical Certificate Issue Date (DMCPED), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID MED CERT ISSUE DATE'

Medical Certificate Expiration Date (DMCEDT), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID MED CERT EXPIRATION DATE'

Each occurrence of Medical Certificate Restriction Code (DMCRES), if present, must be valid as listed in "APPENDIX

D - DATA DICTIONARYŗ.

Error Text: 'INVALID MED CERT RESTRICTION CODE'

Driver Skill Performance Evaluation Effective Date (DDLSSD), if present, must be valid as listed in "APPENDIX D -

DATA DICTIONARYŗ.

Error Text: 'INVALID DRIVER SPE EFFECTIVE DATE'

Driver Skill Performance Evaluation Expiration Date (DDLSED), if present, must be valid as listed in "APPENDIX D -

DATA DICTIONARYŗ.

Error Text: 'INVALID DRIVER SPE EXPIRATION DATE'

Driver Waiver/Exempt Effective Date (DDLWSD), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID DRIVER WAIVER/EXEMPT EFFECTIVE DATE'

Driver Waiver/Exempt Expiration Date (DDLWED), if present, must be valid as listed in "APPENDIX D - DATA

DICTIONARYŗ.

Error Text: 'INVALID DRIVER WAIVER/EXEMPT EXPIRATION DATE'

CDN1.3.1.4 Data Cross-Check Errors

No two occurrences of Medical Certificate Restriction Code (DMCRES) can be the same.

Error Text: 'DUPLICATE MED CERT RESTRICTION CODES'

If Medical Certificate Status Code (DMCCTC) is ŘCř (the driver is certified),

At least one component field of Medical Examiner Name Group (BMPNGP) must be present.

Error Text: 'MED EXAMINER NAME REQUIRED FOR CERT DRIVER'

Medical Licensing Jurisdiction Code (BMPJO1) must be present.

Error Text: 'MED EXAMINER LICENSE JURIS REQUIRED FOR CERT

DRIVER'

Medical Examiner License Number (BMPLI1) must be present.

Error Text: 'MED EXAMINER LICENSE NUMBER REQUIRED FOR CERT

DRIVER'

Medical Examiner Telephone Number (BMPTP1) must be present.





Error Text: 'MED EXAMINER PHONE NUMBER REQUIRED FOR CERT DRIVER'

Medical Certificate Issue Date (DMCPED) must be present.

Error Text: 'MED CERT ISSUE DATE REQUIRED FOR CERT DRIVER'

Medical Certificate Expiration Date (DMCEDT) must be present.

Error Text: 'MED CERT EXPIRATION DATE REQUIRED FOR CERT DRIVER'

Medical Certificate Expiration Date (DMCEDT) must be equal to or later than the Message Date (GMSDAT).

Error Text: 'MEDICAL CERTIFICATE HAS EXPIRED – DRIVER NOT

CERTIFIED'

Medical Certificate Expiration Date (DMCEDT) must be equal to or later than Medical Certificate Issue Date

(DMCPED).

Error Text: 'MED CERT EXP DATE < MED CERT ISSUE DATE'

Medical Certificate Expiration Date (DMCEDT) must be equal to or less than 2 years after Medical Certificate

Issue Date (DMCPED).

Error Text: 'MED CERT EXP DATE > MED CERT ISSUE DATE + 2 YEARS'

Medical Examiner Specialty Code (BMPSP1) must be present.

Error Text: 'MED EXAM SPEC CODE REQUIRED FOR MED CERT'

Driver Skill Performance Evaluation Expiration Date (DDLSED), if present, must be equal to or later than the

Message Date (GMSDAT)

Error Text: 'DRIVER SPE HAS EXPIRED'

Driver Waiver/Exempt Expiration Date (DDLWED), if present, must be equal to or later than the Message Date

(GMSDAT)

Error Text: 'DRIVER WAIVER/EXEMPTION HAS EXPIRED'

If any one occurrence of Medical Certificate Restriction Code (DMCRES) is Ř4ř (intra city zone) or Ř6ř (by

operation of 49 CFR 391.64),

Medical Certificate Expiration Date (DMCEDT), if present, must be equal to or less than 1 year after

Medical Certificate Issue Date (DMCPED).

Error Text: 'MED CERT EXP DTE > ISS DTE + 1 YR AND RESTR CDE 4

OR 6'

If one occurrence of Driver License Restriction Code (DDLRSC) is ŘVř,

Either Driver Skill Performance Evaluation Effective Date (DDLSSD) or Driver Waiver/Exempt Effective Date

(DDLWSD), or both, must be present

Error Text: 'V DL RESTR REQUIRES DRIVER SPE OR WAIVER/EXEMPT

DATES'

If any one occurrence of Medical Certificate Restriction Code (DMCRES) is Ř3ř (SPE),

Driver Skill Performance Evaluation Effective Date (DDLSSD) must be present.





Error Text: 'DRIVER SPE EFFECTIVE DATE REQUIRED FOR SPE

RESTRICTION'

Driver Skill Performance Evaluation Expiration Date (DDLSED) must be present.

Error Text: 'DRIVER SPE EXPIRATION DATE REQUIRED FOR SPE RESTR'

Driver Skill Performance Evaluation Expiration Date (DDLSED), if present, must be equal to or less than 2 years after

Driver Skill Performance Evaluation Effective Date (DDLSSD).

Error Text: 'DRIVER SPE EXP DATE > DRIVER SPE EFF DATE + 2

YEARS'

Driver Skill Performance Evaluation Expiration Date (DDLSED), if present, must be equal to or later than Driver Skill

Performance Evaluation Effective Date (DDLSSD).

Error Text: 'DRIVER SPE EXP DATE > DRIVER SPE EFF DATE'

If any one occurrence of Medical Certificate Restriction Code (DMCRES) is Ř5ř (Waiver/Exemption),

Driver Waiver/Exempt Effective Date (DDLWSD) must be present.

Error Text: 'DRIVER WAIVER/EXEMPT EFF DATE REQD FOR

WAIVER/EXEMPT'

Driver Waiver/Exempt Expiration Date (DDLWED) must be present.

Error Text: 'DRIVER WAIVER/EXEMPT EXP DATE REQD FOR

WAIVER/EXEMPT'

Driver Waiver/Exempt Expiration Date (DDLWED), if present, must be equal to or less than 2 years after Driver

Waiver/Exempt Effective Date (DDLWSD).

Error Text: 'DRIVER WAIVER/EXEMPT EXP DATE > EFF DATE + 2 YEARS'

Driver Waiver/Exempt Expiration Date (DDLWED), if present, must be equal to or later than Driver Waiver/Exempt

Effective Date (DDLWSD).

Error Text: 'DRIVER WAIVER/EXEMPT EXP DATE < WAIVER/EXEMPT EFF

DATE'

CDN1.3.2 Validation of the Driver History Permit Info (H2) Message

CDN1.3.2.1 System Errors.




(DDLJDL).









The System Release Code (GMSSRL) must be set to space, 'F', or ŘHř.





CDN1.3.3 Validation of the Driver History Convictions (H3) Message

CDN1.3.3.1 Validation Overview

This section provides an overview of the process for editing the Driver History convictions (H3) message.

1. Ensure minimal data is available to determine if a conviction is Řpre-CDLISř

a. ST/DLN is required.

b. Citation Date is required and must be a valid date for all convictions.

2. If Citation Date is < April 1, 1992, no additional validations are performed on the conviction.

3. Ensure all convictions have minimal, correct data to determine if it is a ŘCDLIS convictionř.

a. The CMV and HAZMAT indicators must be valid, if present, regardless of the citation date.

b. The three indicators (CMV, HAZMAT, and CDL holder) must be present and valid for citation dates on or

after October 1, 2005.

c. Certain ACD codes (B19, B27, B56, E03, E04, E06, E33, E36, E53, E56, U09, and U10) require the CMV

indicator = Ř1ř

d. Certain ACD codes (E06, E36, and E56) require the HAZMAT indicator = Ř2ř or Ř9ř

4. Determine whether the conviction is considered a CDLIS conviction.

a. If one or more of the indicators are Ř1ř, the conviction is a CDLIS conviction.

5. If determined to be a Řnon-editedř CDLIS conviction, no additional validations are performed on the conviction.

6. Ensure all convictions have minimal, correct data to determine if it meets the milestone criteria.

a. if the ACD code is A11, the detail field must be present and valid

7. Determine what milestone category the conviction falls into.

a. Milestone #1 Ŕ convictions with a citation date on or after January 1, 2008

b. Milestone #2 (Major, Falsify, and USA PATRIOT Act)

1) combination of various ACD codes, indicators, and citation date (in table)

c. Milestone #3 (violations of Out-of-Service Orders)

1) ACD code of B19 or B27 with a citation date on or after January 1, 1995

8. Perform validations that should be applied to the milestone categories


See the Error Processing section for more information on returning system errors.


The DL Current Jurisdiction Code (DDLJU1) embedded in the Driver License Juris Number (DDLJDL) must be

present.

Message: 'STATE CODE REQUIRED'

The Driver License Number (DDLNUM) embedded in the Driver License Juris Number (DDLJDL) must be present.

Message: 'DRIVER LICENSE NUMBER REQUIRED'





The Driver History Convictions (H3) message contains information related to one or more convictions.

Each conviction is described by a given occurrence of the following attributes:

Convicting Jurisdiction (DCVJUR)


Conviction Id Code (DCVCID) when applicable




Conviction Hazmat Indicator (DCVHAZ)

Conviction Jurisdiction Court Report (DCVCLO)



Conviction Offense Detail - ACD (DCVCDA), when applicable


For each conviction sent,

The Citation Date (DCIDCI) must be present.

Message: 'CITATION DATE REQUIRED'


The DL Current Jurisdiction Code (DDLJU1) embedded in the Driver License Juris Number (DDLJDL) must be equal

to one of the "United States" codes or the Mexican code of 'MX' listed in the Data Dictionary appendix.

Message: 'INVALID STATE CODE'

The System Release Code (GMSSRL), if provided, must be 'blank', 'F', or ŘHř.

Message: 'INVALID SYSTEM RELEASE CODE'

For each conviction sent,

The Citation Date (DCIDCI) must conform to the requirements listed in the Data Dictionary appendix.

Message: 'INVALID CITATION DATE'


Note: If the citation date is before April 1, 1992, the conviction is considered Řpre-CDLISř. None of the edits in this

section are performed on Řpre-CDLISř convictions.

If the Conviction Offense ACD Code (DCVCCA) value is ‘B78’, the

Citation CDL Holder Indicator (DCICHI) must be "2".Message: 'INVALID

CDL HOLDER INDICATOR'

If provided, the Commercial Vehicle Indicator (DCVCOM) must be valid as specified in the Data Dictionary Appendix.

Message: 'INVALID COMMERCIAL VEHICLE INDICATOR'

If provided, the Conviction HAZMAT Indicator (DCVHAZ) must be valid as specified in the Data Dictionary

Appendix.

Message: 'INVALID HAZMAT INDICATOR'





If provided, the Citation CDL Holder Indicator (DCICHI) must be valid as specified in the Data Dictionary Appendix

Message: 'INVALID CDL HOLDER INDICATOR'

If the Conviction Offense ACD Code (DCVCCA) value is one of the following, the Conviction Commercial Vehicle

Indicator (DCVCOM) must be '1':

B19 Driving while out of service order is in effect and transporting 16 or more passengers, including the driver

and/or transporting hazardous materials that require a placard.

B27 Driving while an out of service order is in effect (for violations not covered by B19)

B56 Driving a CMV without obtaining a CDL

E03 Operating without HAZMAT safety equipment as required by law

E04 Operating without HAZMAT placards/markings as required by law

E06 Operating without school bus equipment as required by law

E33 Defective HAZMAT safety devices

E36 Defective school bus equipment

E53 Failure to use HAZMAT safety devices as required

E56 Failure to use school bus safety equipment as required

U09 Negligent homicide while operating a CMV

U10 Causing a fatality through the negligent operation of a CMV

Message: 'CONV CMV INDICATOR MUST = 1 FOR ACD CONV CODE'

If the Citation Date (DCIDCI) is before January 1, 2008,

If the Conviction Offense ACD Code (DCVCCA) value is one of the following, the Conviction HAZMAT

Indicator (DCVHAZ) must be "2" or Ŗ9ŗ:




Message: 'CONV HAZMAT IND MUST = 2 OR 9 FOR ACD CONV CODE'

If the Citation Date (DCIDCI) is on or after October 1, 2005

The Commercial Vehicle Indicator (DCVCOM) must be present.

Message: 'COMMERCIAL VEHICLE INDICATOR REQUIRED'

The Conviction HAZMAT Indicator (DCVHAZ) must be present.

Message: 'CONVICTION HAZMAT INDICATOR REQUIRED'

The Citation CDL Holder Indicator (DCICHI) must be present.

Message: 'CDL HOLDER INDICATOR REQUIRED'

If the Citation Date (DCIDCI) is on or after January 1, 2008,

The Conviction Commercial Vehicle Indicator (DCVCOM) must be '1' or Ř2ř.

Message: ‘CONV CMV IND MUST = 1 OR 2, FOR CITATN DATE >

200701231’

The Conviction HAZMAT Indicator (DCVHAZ) must be '1' or Ř2ř.





Message: ‘CONV HAZ IND MUST = 1 OR 2, FOR CITATN DATE >

200701231’

The Citation CDL Holder Indicator (DCICHI) must be '1' or Ř2ř.

Message: ‘CDL HLDR IND MUST = 1 OR 2, FOR CITATN DATE >

200701231’

If the Conviction Offense ACD Code (DCVCCA) value is one of the following, the Conviction HAZMAT

Indicator (DCVHAZ) must be "2":




Message: 'CONV HAZMAT IND MUST = 2 FOR ACD CONV CODE'

Determination of ‘Non-Edited’ CDLIS convictions: ŘNon-Editedř CDLIS convictions are those that have no impact

on the federal disqualification requirements. Determination of ŘNon-Editedř CDLIS convictions is based on the content

of the associated data as provided in the following table. All conditions in a given row of the table must be true for the

conviction to be considered a ŘNon-Editedř CDLIS conviction.

Row Citation Date (DCIDCI) Conviction Commercial Vehicle Indicator (DCVCOM)

Conviction HAZMAT Indicator

(DCVHAZ)

Citation CDL Holder Indicator

(DCICHI)

1 ≥ April 1, 1992 and

≤ September 30, 2005

<blank>, 2, or 9 <blank>, 2, or 9

2 ≥ October 1, 2005 and ≤ December 31, 2007

2 or 9 2 or 9 2 or 9

3 ≥ January 1, 2008 2 2 2

As an example, a conviction with a Citation Date (DCIDCI) of November 1, 2006, Conviction Commercial Vehicle

Indicator (DCVCOM) of Ř2ř, Conviction HAZMAT Indicator of Ř2ř, Citation CDL Holder Indicator (DCICHI) of Ř2ř

and Conviction Offense ACD Code (DCVCCA) of M84 (Reckless Driving) would satisfy all considerations in row two

of the table and would therefore be considered a ŘNon-Editedř CDLIS conviction.

Note: None of the remaining edits in this section are performed on ŘNon-Editedř CDLIS convictions.

The Conviction Offense ACD Code (DCVCCA) must be present.

Message: 'ACD CONVICTION CODE REQUIRED'

If the value of the Conviction HAZMAT Indicator (DCVHAZ) is '1', then the Conviction Commercial Vehicle Indicator

(DCVCOM) must be '1'.

Message: 'CONV CMV IND MUST = 1, IF CONV HAZMAT IND = 1

If the Conviction Offense ACD Code (DCVCCA) is 'A11', the Conviction Offense Detail - ACD (DCVCDA) must

have numeric values in the range '01'-'99' in the first 2 positions and all blanks or all zeroes in the remaining three

positions.

Message: 'INVALID CONV OFF DETAIL FOR ACD CONV CODE = A11'





CDN1.3.3.6 Data Checks to be Phased in by Milestone Dates

CDN1.3.3.6.1 Milestone Determination

Note: If the citation date is before April 1, 1992, the conviction is considered Řpre-CDLISř. None of the edits in this

section are performed on Řpre-CDLISř convictions.

Note: None of the edits in this section are performed on ŘNon-CDLIS convictionsř.

Complete and accurate data is essential to maintaining highway safety. Rather than requiring all conviction data to be

complete and accurate on one date, FMCSA has implemented a Řphased-inř approach for validating conviction data

based on the convictionřs FMCSR category as defined in the ACD Manual. The start date with which enforcement of

each phase of validations begins is referred to as a milestone effective date.

The following table reflects each milestone, the associated effective date, and the FMCSR category of conviction for

which the milestone validations are applied. Details pertaining to each milestone validation are reflected later in this

section.

Milestone

Number

Effective Date Convictions to be checked

#1 January 1, 2008 All convictions with a citation date on or after January 1,

2008

#2 March 15, 2009 All convictions in the ŖMajorŗ category with a citation

date ≥ April 1, 1992 and < January 1, 2008, with

further qualification below

All convictions in the ŖFalsifyŗ category with a citation

date ≥ October 1, 2005 and < January 1, 2008, with

further qualification below

All convictions in the ŖPATRIOT Actŗ category with a

citation date ≥ April 1, 2005 and < January 1, 2008,

with further qualification below

#3 March 14, 2010 All convictions in the ŖOut of Service Order (OOSO)ŗ

category with a citation date ≥ January 1, 1995 and <

January 1, 2008, with further qualification below

Determination of ‘Major’ conviction category for Milestone #2: Each conviction on the H3 message is evaluated to

determine whether or not it falls within the ŘMajorř conviction category. The determination is based on the content of

the associated data as described in the following table. All conditions in a given row of the table must be true for the

conviction to be considered a ŘMajorř conviction for Milestone #2.

Row Conviction Offense ACD Code (DCVCCA)


Conviction Commercial

Vehicle Indicator

(DCVCOM)

Citation CDL Holder

Indicator (DCICHI)

Conviction Offense

Detail ACD (DCVCDA)

1 A04, A94 ≥ April 1, 1992 = ‘1’







Conviction Commercial

Vehicle Indicator

(DCVCOM)

Citation CDL Holder

Indicator (DCICHI)

Conviction Offense

Detail ACD (DCVCDA)

and < January 1, 2008

2 A08, A10, A12, A21, A23, A50, A90, A98, B01, B02, B03, B04, B05, B06, B07, B08, U03, U07, U08

≥ April 1, 1992 and < January 1,

2008

= ‘1’

3 A08, A10, A12, A21, A23, A50, A90, A98, B01, B02, B03, B04, B05, B06, B07, B08, U03, U07, U08

≥ October 1, 2005 and <

January 1, 2008

= ‘1’

4 A11 ≥ April 1, 1992 and < January 1,

2008

= ‘1’ 1st two

characters ≥ ’04‘

5 A11 ≥ October 1, 2005 and <

January 1, 2008

= ‘1’ 1st two

characters ≥ ’08‘

6 B20, B21, B22, B23, B24, B25, B26

≥ October 1, 2005 and <

January 1, 2008

= ‘1’

7 U09, U10 ≥ October 1, 2005 and <

January 1, 2008

= ‘1’

Determination of ‘Falsify’ conviction category for Milestone #2: Each conviction on the H3 message is evaluated to

determine whether or not it falls within the ŘFalsifyř conviction category. The determination is based on the content of

the associated data as described in the following table. All conditions in the row of the table must be true for the

conviction to be considered a ŘFalsifyř conviction for Milestone #2.


Citation Date (DCIDCI) Citation CDL Holder Indicator (DCICHI)

1 = D02 ≥ October 1, 2005 and ≤ December 31, 2007

= 1

Determination of ‘PATRIOT Act’ conviction category for Milestone #2: Each conviction on the H3 message is

evaluated to determine whether or not it falls within the ŘPATRIOT Actř conviction category. The determination is

based on the content of the associated data as described in the following table. All conditions in the row of the table

must be true for the conviction to be considered a ŘPATRIOT Actř conviction for Milestone #2.





Row Conviction Offense ACD Code (DCVCCA) Citation Date (DCIDCI)

1 = W09 ≥ April 1, 2005 and ≤ December 31, 2007

Determination of an ‘Out Of Service Order (OOSO)’ conviction for Milestone #3: Each conviction on the H3

message is evaluated to determine whether or not it is an ŘOut of Service Order (OOSO)ř conviction. The determination

is based on the content of the associated data as provided in the following table. All conditions in the row of the table

must be true for the conviction to be considered an ŘOut of Service Order (OOSO)ř conviction for Milestone #3.

Row Conviction Offense ACD Code (DCVCCA) Citation Date (DCIDCI)

1 = B19 or B27 ≥ January 1, 1995 and < January 1, 2008

Note: In previous versions of the specifications, there were five Milestones. FMCSA has agreed to only edit

convictions that must be maintained (i.e., no edits are applied to convictions that have met retention requirements).

Therefore, all ŘOtherř (previously in Milestone #4; March 2011) and ŘSeriousř/ŘRRGCř convictions (previously in

Milestone #5; March 2012) are edited based on Milestone #1 criteria only (only if citation date is on or after January 1,

2008).

For each conviction that meets the milestone criteria described above, all the checks in the following sections

are performed as of the milestone effective date described above.

CDN1.3.3.6.2 Required Data Checks to be Phased in by Milestone Dates

The Jurisdiction Code - Convicting (DCVJUR) must be present.

Message: 'STATE-OF-CONVICTION CODE REQUIRED'

The Conviction Date (DCVDCV) must be present.

Message: 'CONVICTION DATE REQUIRED'

The Conviction Juris Court Report ID (DCVCLO) must be present.

Message: 'SOC COURT REPORT ID REQUIRED'

The State of Conviction Offense Code (DCVCOR) must be present.

Message: 'SOC OFFENSE CODE REQUIRED'

The Conviction Court Type (DCVCRT) must be present.

Message: 'CONVICTION COURT TYPE REQUIRED'

CDN1.3.3.6.3 Invalid Data Checks to be Phased in by Milestone Dates

The Conviction Offense ACD Code (DCVCCA) must be a valid ACD code as specified in the AAMVA Code

Dictionary (ACD) Manual.

Message: 'INVALID ACD CONVICTION CODE'

The Conviction Offense ACD Code (DCVCCA) must not be one of the codes reserved for withdrawals: W00, W01,

W30, W31, W40, W41, W45, W50, W51, W52, W60, W61, W72, W80, and W81.

Message: 'INVALID ACD CONVICTION CODE'

The Jurisdiction Code - Convicting (DCVJUR) must conform to the ŖUnited Statesŗ, ŖCanadaŗ, ŖUS Territoriesŗ or





ŖMexicoŗ (ŘMXř only) list in the Data Dictionary appendix.

Message: 'INVALID STATE-OF-CONVICTION CODE'

The Conviction Date (DCVDCV) must conform to the requirements listed in the Data Dictionary appendix.

Message: 'INVALID CONVICTION DATE'

The Conviction Court Type (DCVCRT) must be valid as specified in the Data Dictionary Appendix.

Message: 'INVALID CONVICTION COURT TYPE'

CDN1.3.3.6.4 Data Cross-Checks to be Phased in by Milestone Dates

The Citation Date (DCIDCI) must be equal to or earlier than the Conviction Date (DCVDCV).

Message: 'CITATION DATE MUST NOT BE LATER THAN CONV DATE'

The Conviction Date (DCVDCV) must be equal to or earlier than the Message Date (GMSDAT).

Message: 'CONV DATE MUST NOT BE LATER THAN MESSAGE DATE'

If the Conviction Offense ACD Code (DCVCCA) value is one of the following, the Conviction HAZMAT Indicator

(DCVHAZ) must be "1":

E03 Operating without HAZMAT safety equipment as required by law

E04 Operating without HAZMAT placards/markings as required by law

E33 Defective HAZMAT safety devices

E53 Failure to use HAZMAT safety devices as required

Message: 'CONV HAZMAT IND MUST = 1 FOR ACD CONV CODE'

If the Conviction Offense ACD Code (DCVCCA) is NOT in the group ('A11', 'D45', 'D53' or 'D56') and is NOT in the

range 'S01'-'S92', the Conviction Offense Detail - ACD (DCVCDA) must have all blanks.

Message: 'ACD CONV CODE VALUE REQUIRES BLANK CONV OFF DET'

If the Conviction Offense ACD Code (DCVCCA) is in the range 'S01'-'S91', the Conviction Offense Detail - ACD

(DCVCDA) must have one of the following two formats (Note: The format of "zeroes for null values" does not conform

to the AAMVA standard of "blanks for null values" and will be rejected in error):

(1) All blanks (for null values) or

(2) Numeric values in the range '05'-'90' in the first 2 positions and all blanks or all zeroes in the last three

positions.

Message: 'INVALID CONV OFF DET FOR ACD CONV CODES S01-S91'

If the Conviction Offense ACD Code (DCVCCA) is 'S92', the Conviction Offense Detail - ACD (DCVCDA) must have

a numeric value in the range '05'-'90' in the first two positions and a numeric value in the last three positions that is less

than '300' and greater than the numeric value in the first two positions.

Message: 'INVALID CONV OFF DETAIL FOR ACD CONV CODE = S92'

If the Conviction Offense ACD Code (DCVCCA) is 'D45' or 'D53' or 'D56', the first three positions of the Conviction

Offense Detail - ACD (DCVCDA) must have a valid ACD Conviction Code that must NOT be 'D45', 'D53' or 'D56ř;

and the remaining two positions must have blanks.

Message: 'INVALID CONV OFF DETAIL FOR GIVEN ACD CONV CODE'





If the Conviction Offense ACD Code (DCVCCA) value is ŘB78ř, ŘS14ř, ŘU27ř, or ŘU28ř, the Citation Date (DCIDCI)

must be on or after November 9, 2009.

Message: 'INVALID CITATION DATE FOR CONV ACD'

CDN1.3.4 Validation of the Driver History Accidents (H4) Message




The following checks must be implemented as of January 1, 2008 for accidents with an accident date on or after January

1, 2008.


(DDLJDL).





The following check must be implemented as of January 1, 2008 for accidents with an accident date on or after January

1, 2008.

The System Release Code (GMSSRL) must be set to space, ŘFř, or ŘHř.





CDN1.3.5 Validation of the Driver History Withdrawals (H5) Message


This section provides an overview of the process for editing the Driver History Withdrawals (H5) message.

1. Ensure minimal data is available to determine if a withdrawal is Řpre-CDLISř


b. Withdrawal Effective Date is required and must be a valid date for all withdrawals.

2. If Withdrawal Effective Date is < April 1, 1992, no additional validations are performed on the withdrawal.

3. Ensure all withdrawals have minimal, correct data to determine if it is a ŘCDLIS withdrawalř.

a. Certain ACD codes (B19, B27, M10, M20, M21, M22, M23, M24, W30, W31, W40, W41, W45, W50, W51,

W52, W60, W61, and W72) require the Withdrawal Extent = Ř1ř or Ř3ř

4. Determine whether the withdrawal is considered a CDLIS withdrawal.

a. If the Withdrawal Extent is Ř1ř or ř3ř, the withdrawal is a CDLIS withdrawal.

5. If determined to be a Řnon-editedř CDLIS withdrawal, no additional validations are performed on the withdrawal.

6. Ensure all withdrawals have minimal, correct data to determine if it meets the milestone criteria.

a. No additional edits (kept for parallelism)





7. Determine what milestone category the withdrawal falls into.

a. Milestone #1 Ŕ withdrawals with an effective date on or after January 1, 2008

b. Milestone #2 (Major, Falsify, and USA PATRIOT Act)

1) combination of various ACD codes, Withdrawal Extent, and withdrawal effective date (in table)

c. Milestone #3 (violations of Out-of-Service Orders)

1) ACD code of B19, B27, W50, W51 or W52 with an effective date on or after January 1, 1995

8. Perform validations that should be applied to the milestone categories




The DL Current Jurisdiction Code (DDLJU1), embedded in the Driver License Juris Number (DDLJDL), must be

present. If not, issue an error.


The Driver License Number (DDLNUM), embedded in the Driver License Juris Number (DDLJDL), must be present.

If not, issue an error.


The Driver History Withdrawals (H5) message contains information related to one or more withdrawals. Each

withdrawal is described by a given occurrence of the following attributes:








Driver License Withdrawal Reinstatement Date (DWDWDR) when applicable




Driver License Withdrawal ID Code (DWDWID) when applicable

For each withdrawal sent,

The Drv Lic Withdrawal Effective Date (DWDDWD) must be present.

Message: ‘WITHDRAWAL EFFECTIVE DATE REQUIRED'


The DL Current Jurisdiction Code (DDLJU1) embedded in the Driver License Juris Number (DDLJDL) must conform

to the "United States" list in the Data Dictionary appendix or the Mexican value of 'MX'.


For each withdrawal sent,





The Drv Lic Withdrawal Effective Date (DWDDWD) must conform to the requirements listed in the Data

Dictionary appendix.

Message: 'INVALID WITHDRAWAL EFFECTIVE DATE'


Note: If the Drv Lic Withdrawal Effective Date (DWDWDW) is before April 1, 1992, the withdrawal is considered

Řpre-CDLISř. None of the edits in this section are performed on Řpre-CDLISř withdrawals.

If Drv Lic ACD Withdrawal Reason Code (DWDWRS) is ŘW40ř or ŘW41ř, the Drv Lic Withdrawal Extent ID Ŕ DLC

(DWDWEX) must be Ř1ř or Ř3ř.

Message: 'INVALID WITHDRAWAL EXTENT FOR ACD'

If Drv Lic ACD Withdrawal Reason Code (DWDWRS) is one of the following (A08, A10, A12, A21, A23, A50, A90,

A98, B01, B02, B03, B04, B05, B06, B07, B08, D02, U03, U07 or U08), the Drv Lic Withdrawal Extent ID Ŕ DLC

(DWDWEX) must be present.

Message: 'WITHDRAWAL EXTENT REQUIRED FOR WITHDRAWAL ACD'

If Drv Lic ACD Withdrawal Reason Code (DWDWRS) is one of the following (A08, A10, A12, A21, A23, A50, A90,

A98, B01, B02, B03, B04, B05, B06, B07, B08, D02, U03, U07 or U08), the Drv Lic Withdrawal Extent ID Ŕ DLC

(DWDWEX) must be valid as specified in the Data Dictionary appendix.

Message: 'INVALID WITHDRAWAL EXTENT'

If Drv Lic ACD Withdrawal Reason Code (DWDWRS) is ŘW45ř, the Drv Lic Withdrawal Extent ID Ŕ DLC

(DWDWEX) must = Ř1ř or Ř3ř.


If the Drv Lic Withdrawal Effective Date (DWDDWD) is on or after October 1, 2005,

If Drv Lic ACD Withdrawal Reason Code (DWDWRS) is ŘU09ř, ŘU10ř or ŘW09ř, the Drv Lic Withdrawal

Extent ID Ŕ DLC (DWDWEX) must = Ř1ř or Ř3ř.






CDN1.3.5.6 Data Checks to be Phased in by Milestone Dates

CDN1.3.5.6.1 Milestone Determination

Note: If the Drv Lic Withdrawal Effective Date (DWDWDW) is before April 1, 1992, the withdrawal is considered

Řpre-CDLISř. None of the edits in section cd04.3.3.5.5 are performed on Řpre-CDLISř withdrawals.

Complete and accurate data is essential to maintaining highway safety. Rather than requiring all withdrawal data to be

complete and accurate on one date, FMCSA has implemented a Řphased-inř approach for validating withdrawal data

based on the withdrawalřs FMCSR category as defined in the ACD Manual. The start date with which enforcement of

each phase of validations begins is referred to as a milestone effective date.

The following table reflects each milestone, the associated effective date, and the FMCSR category of withdrawal for

which the milestone validations are applied. Details pertaining to each milestone validation are reflected later in this

section.

Milestone

Number

Effective Date Withdrawals to be checked

#1 January 1, 2008 All withdrawals with a withdrawal effective date on or after

January 1, 2008

#2 March 15, 2009 All withdrawals in the ŖMajorŗ category with a

withdrawal effective date ≥ April 1, 1992 and <


All withdrawals in the ŖFalsifyŗ category with a

withdrawal effective date ≥ October 1, 2005 and <


All withdrawals in the ŖPATRIOT Actŗ category with a

withdrawal effective date ≥ April 1, 2005 and <


#3 March 14, 2010 All withdrawals in the ŖOut of Service Order (OOSO)ŗ

category with a withdrawal effective date ≥ January 1,

1995 and < January 1, 2008, with further qualification

below

Determination of ‘Major’ withdrawal category for Milestone #2: Each withdrawal on the H5 message is evaluated

to determine whether or not it falls within the ŘMajorř withdrawal category. The determination is based on the content

of the associated data as described in the following table. All conditions in a given row of the table must be true for the

withdrawal to be considered a ŘMajorř withdrawal for Milestone #2.

Row ACD Withdrawal Reason Code (DWDWRS)

Withdrawal Effective Date (DWDDWD)


1 A08, A10, A12, A21, A23, A50, A90, A98, B01, B02, B03, B04, B05, B06, B07, B08, U03, U07, U08,

≥ April 1, 1992 and < January 1, 2008

= 1 or 3

2 W40, W41 ≥ April 1, 1992 and < January 1, 2008





3 U09, U10 ≥ October 1, 2005 and < January 1, 2008

Determination of ‘Falsify’ withdrawal category for Milestone #2: Each withdrawal on the H5 message is evaluated

to determine whether or not it falls within the ŘFalsifyř withdrawal category. The determination is based on the content

of the associated data as described in the following table. All conditions in the row of the table must be true for the

withdrawal to be considered a ŘFalsifyř withdrawal for Milestone #2.




1 = D02 ≥ April 1, 1992 and < January 1, 2008

= 1 or 3

Determination of ‘PATRIOT Act’ withdrawal for Milestone #2: Each withdrawal on the H5 message is evaluated

to determine whether or not it falls within the ŘPATRIOT Actř withdrawal category. The determination is based on the

content of the associated data as described in the following table. All conditions in the row of the table must be true for

the withdrawal to be considered a ŘPATRIOT Actř withdrawal for Milestone #2.



1 W09 ≥ October 1, 2005 and < January 1, 2008

Determination of an ‘Out Of Service Order (OOSO)’ withdrawal for Milestone #3: Each withdrawal on the H5

message is evaluated to determine whether or not it is an ŘOut of Service Order (OOSO)ř withdrawal. The

determination is based on the content of the associated data as provided in the following table. All conditions in the row

of the table must be true for the withdrawal to be considered an ŘOut of Service Order (OOSO)ř withdrawal for

Milestone #3.



1 = B19, B27, W50, W51, W52 ≥ January 1, 1995 and < January 1, 2008

Note: In previous versions of the specifications, there were five Milestones. FMCSA has agreed to only edit

withdrawals that must be maintained (i.e., no edits are applied to withdrawals that have met retention requirements).

Therefore, all ŘOtherř (previously in Milestone #4; March 2011) and ŘSeriousř/ŘRRGCř withdrawals (previously in

Milestone #5; March 2012) are edited based on Milestone #1 criteria only (only if withdrawal effective date is on or

after January 1, 2008).

For each withdrawal that meets the milestone criteria described above, all the checks in the following sections are

performed as of the milestone effective date described above.

CDN1.3.5.6.2 Required Data Checks to be Phased in by Milestone Dates

The Drv Lic ACD Withdrawal Reason Code (DWDWRS) must be present.

Message: 'ACD WITHDRAWAL REASON CODE REQUIRED'

The Jurisdiction Code - Withdrawing (DWDJUR) must be present.

Message: 'STATE-OF-WITHDRAWAL CODE REQUIRED'

The Drv Lic Withdrawal Eligibility Date (DWDWDE) must be present.





Message: 'WITHDRAWAL ELIGIBILITY DATE REQUIRED'

The Drv Lic Withdrawal Extent ID - DLC (DWDWEX) must be present.

Message: 'WITHDRAWAL EXTENT ID REQUIRED'

The Driver License Withdrawal Type (DWDWTP) must be present.

Message: 'WITHDRAWAL TYPE DETAIL REQUIRED'

The Driver License Withdrawal Basis (DWDWBS) must be present.

Message: 'WITHDRAWAL BASIS REQUIRED'

The DL Withdrawal Due Process Status (DWDWPS) must be present.

Message: 'WITHDRAWAL DUE PROCESS STATUS REQUIRED'

The DL Withdrawal Jurisdiction Report ID (DWDWLO) must be present.

Message: 'WITHDRAWAL JURISDICTION REPORT ID REQUIRED'

The Drv Lic Withdrawal Reason Reference (DWDWRR) must be present.

Message: 'WITHDRAWAL REASON REFERENCE REQUIRED'

CDN1.3.5.6.3 Invalid Data Checks to be Phased in by Milestone Dates

The Drv Lic ACD Withdrawal Reason Code (DWDWRS) must conform to the requirements listed in the Data


Message: 'INVALID WITHDRAWAL ACD REASON CODE'

The Jurisdiction Code - Withdrawing (DWDJUR) must conform to the "United States", ŖCanadaŗ, ŖUS Territoriesŗ or

ŖMexicoŗ (ŘMXř only) list in the Data Dictionary appendix.

Message: 'INVALID STATE-OF-WITHDRAWAL CODE'

The Drv Lic Withdrawal Eligibility Date (DWDWDE) must be valid as specified in the Data Dictionary appendix,

and if the value is a date the date must conform to the requirements listed in the Data Dictionary appendix.

Message: 'INVALID ELIGIBILITY DATE'

If provided, the DL Withdrawal Reinstatement Date (DWDWDR) must conform to the requirements listed in the Data


Message: 'INVALID REINSTATEMENT DATE'

The Drv Lic Withdrawal Extent ID - DLC (DWDWEX) must be valid as specified in the Data Dictionary appendix.

Message: 'INVALID WITHDRAWAL EXTENT ID'

The Driver License Withdrawal Type (DWDWTP) must be valid as specified in the Data Dictionary appendix.

Message: 'INVALID WITHDRAWAL TYPE'

The Driver License Withdrawal Basis (DWDWBS) must be valid as specified in the Data Dictionary appendix.

Message: 'INVALID WITHDRAWAL BASIS'





The DL Withdrawal Due Process Status (DWDWPS) must be valid as specified in the Data Dictionary appendix.

Message: 'INVALID WITHDRAWAL PROCESS STATUS'

CDN1.3.5.6.5 Data Cross-Checks to be Phased in by Milestone Dates

If the Drv Lic Withdrawal Eligibility Date (DWDWDE) is a date it must be equal to or later than the Drv Lic

Withdrawal Effective Date (DWDDWD).

Message: 'ELIG DATE MUST BE EQUAL TO OR LATER THAN EFFEC DATE'

If provided, the DL Withdrawal Reinstatement Date (DWDWDR) must be equal to or earlier than the Message Date

(GMSDAT).

Message: 'REINSTATE DATE MUST NOT BE LATER THAN MESSAGE DATE'

If the Drv Lic Withdrawal Eligibility Date (DWDWDE) is a date, it must be equal to or earlier than the DL Withdrawal

Reinstatement Date (DWDWDR).

Message: 'ELIG DATE MUST BE EQUAL TO OR EARLIER THAN REINST

DATE'

If Drv Lic ACD Withdrawal Reason Code (DWDWRS) is ŘB78, ŘS14ř, ŘU27ř, ŘU28ř, ŘW80ř or ŘW81ř, the Drv Lic

Withdrawal Effective Date (DWDDWD) must be on or after November 9, 2009.

Message: 'INVALID EFFECTIVE DATE FOR WDRAW ACD'

If the Drv Lic Withdrawal Effective Date (DWDDWD) is on or before November 9, 2008,

The Drv Lic ACD Withdrawal Reason Code (DWDWRS) cannot equal ŘW45ř or ŘW72ř

Message: 'INVALID WITHDRAWAL ACD REASON CODE'

CDN1.3.6 Validation of the Driver History Withdrawal-Conviction Links (H7) Message


This section provides an overview of the process for editing the Driver History Withdrawal-Conviction Links (H7)

message.

1. Ensure minimal data is available to determine if an H7 can be processed.


CDN1.3.6.2 System Errors.



The DL Current Jurisdiction Code (DDLJU1), embedded in the Driver License Juris Number (DDLJDL), must be

present.


The Driver License Number (DDLNUM), embedded in the Driver License Juris Number (DDLJDL), must be present.






The Driver History Withdrawal Conviction Linkage (H7) message contains information related to one or more

withdrawal conviction linkages.

Each withdrawal conviction linkage is described by a given occurrence of the following attributes:

Driver License Withdrawal ID Conviction Link (DWDWI2)

Driver License Withdrawal Conviction Links Group (DWDCLG)


The System Release Code (GMSSRL) must be set to Řblankř, 'F', or ŘHř.

Message: 'INVALID SYSTEM RELEASE CODE'

The DL Current Jurisdiction Code (DDLJU1) embedded in the Driver License Juris Number (DDLJDL) must conform

to the "United States" list in the Data Dictionary appendix or the Mexican value of 'MX'.



A conviction ID code in the DL WITHDRAWAL CONVICTIONS LINKS GRP (DWDCLG) for a given linkage in the

H7 message must not be repeated within a given DL WITHDRAWAL CONVICTIONS LINKS GRP (DWDCLG). If

not, issue an error.

Message: 'REPEATED CONVICTION IDS IN CONVICTIONS LINKS GRP'

Each DL WITHDRAWAL ID - CONVICTION LINK (DWDWI2) received on the H7 message must match one and

only one DRIVER LICENSE WITHDRAWAL ID CODE (DWDWID) in the H5 message. If not, issue an error.

Message: 'NO MATCHING WITHDRAWAL ID CODE IN H5 MESSAGE'

Each 2-character conviction identifier in the DL WITHDRAWAL CONVICTIONS LINKS GRP (DWDCLG) received

on the H7 message must match one and only one CONVICTION ID CODE (DCVCID) in the H3 message. If not, issue

an error.

Message: 'NO MATCHING CONVICTION ID CODE IN H3 MESSAGE'

CDN1.4 Transmission

CDN1.4.1 Transmission of Validated Message without Errors

If the CDLIS Common Validation Processor does not encounter any validation exceptions when processing a given

message, it forwards the message to the Message Destination (GMSDST) exactly as received.

CDN1.4.2 Transmission of Validated Message with Errors

If the CDLIS Common Validation Process encounters one or more validation exceptions when processing a given

message, it returns the message to the Message Originator (GMSORG) exactly as received, with the following

exceptions:



Additionally, the CDLIS Common Validation Process forwards the message to the Message Destination (GMSDST),

exactly as received, with the following exceptions:


If the Message Destination (GMSDST) is configured to handle receipt with the NCB Error Code (GNCBER) set to ŘYř,






Otherwise,




8 BATCH PROCESS DESCRIPTIONS 417



8 BATCH PROCESS DESCRIPTIONS

This section describes the batch processes that are performed within CDLIS. For each process, the following

information is provided:

A high level business description of the process

A Process Implementation Chart (PIC) Ŕ graphical, logical representation of the process

A detailed logical description of each sub-process that, taken together, comprise the overall process.



CD30 BATCH INQUIRY


CD30 BATCH INQUIRY


Description

The Motor Carrier Safety Improvements Act (MCSIA) required jurisdictions to check the Problem Driver Pointer

System (PDPS) and CDLIS up to 90 days prior to the issuance, transfer, upgrade or renewal of any driver's license. The

additional inquiries resulted in a significant increase in traffic over AAMVAřs network. The CDLIS Batch Search

Inquiry was developed as an alternative to the CDLIS online Search Inquiry*.Ref1

It allows jurisdictions to perform

search inquiries in a batch mode, meaning that inquiries on multiple drivers are collected by the inquirer and sent

together as a group (batch) as opposed to being sent one at a time. The collected batch inquiry messages are sent

together in a file as opposed to separately online.

Each CDLIS Batch Search Inquiry is a request for a driverřs Master Pointer Record (MPR). The batch inquiry enables

the inquirer to determine if a driver already exists on the CDLIS Central Site. The CDLIS Batch Search Inquiry

retrieves driver records that match, exactly or approximately, on any of the search fields. It is used when it is not known

whether a given individual is on the CDLIS Central Site.

A State of Inquiry (SOI) may submit a weekly or monthly batch. Each jurisdiction gains approval from the Federal

Motor Carrier Safety Administration (FMCSA) prior to using the CDLIS Batch Search Inquiry process.

* The CDLIS Batch Search Inquiry messages have the same structure as those used in the online Search Inquiry.

Participants

Inquirer

o U.S. jurisdiction (SOI)

CDLIS Central Site


o U.S. jurisdiction

Pre-Requisites

None

Standard Processing

An inquirer makes a request by sending a CDLIS Batch Search Inquiry file to the CDLIS Central Site.

Upon receipt of the CDLIS Batch Search Inquiry file, the CDLIS Central Site:

o Validates the control information

o For each driver being inquired upon:

Validates the driver identification information in the message

Retrieves MPRs that match, exactly or approximately, on any of the search fields

o Returns a CDLIS Batch Search Inquiry response file from the Central Site to the inquirer

Inputs

The CDLIS Batch Search Inquiry file includes control information, as well as search information for each driver being

inquired upon. The control information includes the date the batch inquiry file was sent to the CDLIS Central Site, as

well as the number of inquiries included in the file. Each search inquiry includes the driverřs name and date of birth. It

may optionally include the licensing jurisdiction code and driver's license number combination, the driver's Social

Security Number, and up to three AKA names.



o The Central Site returns a batch response file for each batch inquiry file submitted. The batch response



CD30 BATCH INQUIRY


file contains control information and, for each driver being inquired upon, information on the number of

matches found, along with the MPR data for each match, up to 15 drivers


Central Site

o If the control information does not pass the edit validations performed by the CDLIS Central Site, the

Central Site stops processing (no inquiries are processed) and returns a response file to the inquirer with

information regarding the error.

o If a specific inquiry in the file does not pass the edit validations performed by the CDLIS Central Site, the

Central Site includes an error for that particular inquiry in the response file. Processing on that particular

driver is stopped, but other inquiries on other drivers included in the file are processed.

Post-Requisites

If more than 15 matches are found for a particular driver and none of the first 15 matches returned can be determined

with certainty to be the driver in question, the inquirer changes the search criteria to reduce the number of matches (e.g.,

eliminate AKA data).

The CDLIS Batch Search Inquiry process does not provide status information from the SOR like the online Search

Inquiry. To complete the inquiry process, the inquirer initiates an online inquiry (like the State-to-State Status

Request)Ref3

to get status information from the SOR.

References

Reference

#


Ref1 CDLIS System

Specifications

CD01 SEARCH INQUIRY

Ref2 CDLIS System

Specifications


Ref3 CDLIS System

Specifications




CD30 BATCH INQUIRY




CD30 BATCH INQUIRY


CD30.1 Request Batch Search for Driver (State of Inquiry (SOI))

CD30.1.1 Create Batch Inquiry File

Jurisdictions will create and transmit to CDLIS Central Site a Batch Inquiry file, based on the jurisdictionřs batch cycle

(weekly or monthly). The Batch Inquiry file contains a single Batch Inquiry Control (EQ) message and Batch Search

Inquiry (EM) message(s).

When a jurisdiction has implemented UNI, the jurisdiction application may use UNI to build EM inquiry messages in

AMIE format. The jurisdiction application can write each EM inquiry message individually to the Batch Inquiry file

and increment a counter. Then the jurisdiction application can use UNI to format one EQ control message in AMIE

format and add the EQ control message to the Batch Inquiry file. The EQ control message must contain the count of the

total number of EM inquiry messages (DDBST1) in the file and the date the Batch Inquiry file is sent (DDBISD) to

Central Site. When calling UNI to format each message, the Network Service code located on the UNI Parameter List

must be set to the value of ŘFLř. This will enable the UNI translation process to store in the NCB Transmit Mode

(GXMODC) a value of Ř3ř to indicate to the Central Site that response messages will not be sent interactively. For each

EM message, UNI populates the SOI password (GMSPSW) with the value the SOI uses in interactive IM transactions.

UNI populates a unique locator (GMSLOC) in each EM inquiry message to provide a link with its expected responses.

Note: UNI populates elements of the NCB and MEC blocks with the required values.

If a jurisdiction does not use UNI to create the Batch Inquiry file, the jurisdiction must adhere to the AMIE

specifications (section 4.2.1). The jurisdiction application must perform the process described above to build messages

(all EM inquiry messages and one EQ control message) in AMIE format and create the Batch Inquiry file.

If a jurisdiction does not use UNI to create the Batch Inquiry file, the jurisdiction application must:

When formatting each EM inquiry message, store in the NCB Transmit Mode (GXMODC) a value of Ř3ř (batch

mode).

Include a unique locator (GMSLOC) in each EM inquiry message in order to provide a link with its expected

responses. If the locator is not populated, the EM inquiry message will not be matched with its corresponding

responses.

Populate the SOI password (GMSPSW) in the MEC block of each EM message with the value the SOI uses in

interactive IM transactions.

Note: If the SOI does not use UNI, care must be taken to set the appropriate values when populating elements of the

NCB and MEC blocks.

BATCH INQUIRY FILE FORMAT

This file contains two types of records:

Control (message type ŘEQř)

Inquiry (message type ŘEMř)

Record Type Position Length (chars) Occurrence

Control EQ Anywhere in file 330 to 990 1

Inquiry EM Before/After EQ 264 to 1188 >= 1

CD30.1.2 Transmission of Batch Inquiry Control (EQ) Message

For all jurisdictions, regardless of the version implemented,



CD30 BATCH INQUIRY


Only one EQ control message must be included and may be positioned anywhere in the Batch Inquiry file.

The EQ message must contain required values for the following batch control elements:

o Batch Inquiry File Sent Date (DDBISD) set to the date the Batch Inquiry file is transmitted by the SOI to

the CDLIS Central Site. In order to resubmit a Batch Inquiry file, the SOI must update the batch

submission date.

o Batch inquiry message count (DDBST1) set to the number of EM inquiry messages in the Batch Inquiry

file.

o All remaining batch control elements (blocks 23/3 and 23/4) set to spaces.

The EQ control message must contain the following elements set to required values:

o Message Length (GMSLEN) set to the value representing the total number of bytes in the message.

o Message Destination (GMSDST) set to the value of ŘXXř.

o Message Originator (GMSORG) set with a SOI s jurisdiction code.

o Message Sender Password (GMSPSW) set with the current CDLIS password for the SOI.

o Message Date (GMSDAT) set to the date the message is created.

o Message Time (GMSTIM) set to the time the message is created.

o Message Sequence Identifier (GMSSEQ) set to the value of Ř0001ř.

o Application ID (GAPPID) set to the value of Ř02ř.

o Message Type (GMSTYP) set to the value of ŘEQř.

o Segment Sequence Number (GSGSEQ) set to the value of Ř01ř.

o Last Segment Indicator (GLSEGI) set to the value of ŘYř.

o Number of Text Blocks Count (GNBTXT) set to the value representing the number of text blocks in the

message.

o Network Session Indicator (GNETSI) set to the value of ŘNř.

o Test/Production Indicator (GTPIND) set to the correct value of ŘTř for test or ŘPř for production.

o Note: The Production Indicator must be the same in the EQ control message and all EM inquiry

messages.

o NCB Transmit Mode (GXMODC) set to the value of Ř3ř.

o NCB Error Code (GNCBER) set to the value of ŘNř.

o Transaction Originator (GTRORG) set to the value of the Message Originator (GMSORG).

o Network Status (GNETST) set to the value of Ř00ř.

o Application Status (GAPPST) set to the value of Ř0ř.

o Message Locator (GMSLOC) set to a value that allows linking the message to its associated response

messages.

The EQ message may optionally include:

o Return as Received Text/Block (GRRECV) (up to five occurrences)

Note: If the SOI uses UNI, elements of the NCB, Verification, and MEC blocks will be populated by UNI with

the required values.

See ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for remaining elements in the NCB,

Verification, and MEC blocks.

CD30.1.3 Transmission of Batch Search Inquiry (EM) Message

Jurisdictions must transmit EM inquiry messages in a Batch Inquiry file. The EM inquiry message contains the same

data elements as the online IM inquiry message.

Each EM inquiry message must contain the following elements set to required values:

For all Jurisdictions, regardless of the version implemented:



CD30 BATCH INQUIRY



Message Length (GMSLEN) set to the correct value representing the total number of bytes in the

message.

Message Destination (GMSDST) set to the value of ŘXXř.

Message Originator (GMSORG) set with a SOI s jurisdiction code.

Message Sender Password (GMSPSW) set with the current CDLIS password for the SOI.

Message Date (GMSDAT) set to the date the message is created.

Message Time (GMSTIM) set to the time the message is created.

Message Sequence Identifier (GMSSEQ) set to the value of Ř0001ř.

Application ID (GAPPID) set to the value of Ř02ř.

Message Type (GMSTYP) set to the value of ŘEMř.

Segment Sequence Number (GSGSEQ) set to the value of Ř01ř.

Last Segment Indicator (GLSEGI) set to the value of ŘYř.

Number of Text Blocks Count (GNBTXT) set to the value representing the number of text blocks in the

message.

Network Session Indicator (GNETSI) set to the value of ŘNř.

Test/Production Indicator (GTPIND) set to the correct value of ŘTř for test or ŘPř for production.

Note: The Production Indicator must be the same in each EM inquiry message and the EQ control

message.

NCB Transmit Mode (GXMODC) set to the value of Ř3ř.

NCB Error Code (GNCBER) set to the value of ŘNř.

Transaction Originator (GTRORG) set to the value of the Message Originator (GMSORG).

Network Status (GNETST) set to the value of Ř00ř.

Application Status (GAPPST) set to the value of Ř0ř.

Message Locator (GMSLOC) set to a value that allows linking the message to its associated response

messages.

For those Jurisdictions at version 5.1 or greater:



Driver Name (DDVNAM) set to the driver's name

Optionally, the EM inquiry message may include:


Driver AKA Name count (GMSCNM) set to the total number of AKA names populated in the message.




Driver License Jurisdiction Number (DDLJDL) set to the driver's license number of the driver


Return as Received Text/Block (GRRECV) (up to five occurrences)







CD30 BATCH INQUIRY


driver may be known other than the current name




Driver AKA Name (DDVKNM) set to the first name by which the driver may be known other than the

current name

Driver AKA 2nd Name (DDVKN2) set to the second name by which the driver may be known other than

the current name

Driver AKA 3rd Name (DDVKN3) set to the third name by which the driver may be known other than

the current name

Note: If AKA Name and AKA DOB is transmitted, each AKA Name must be paired with an AKA Date of Birth. The

first occurrence must be populated before the second occurrence, which must be populated before the third occurrence.

Note: If the SOI uses UNI, elements of the NCB and MEC blocks will be populated by UNI with the required values.

See ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for remaining elements in the NCB, Verification,

and MEC blocks.

CD30.1.4 Transmission of Batch Inquiry File

Jurisdictions must transmit the Batch Inquiry file to the CDLIS Central Site using TCP/IP transfer protocols via file

transfer protocol (FTP) over AAMVAnet. Batch Inquiry files must use data formats ASCII or EBCDIC.

When sending Batch Inquiry files, jurisdictions must use the file naming format provided by AAMVA at the time the

jurisdiction signs for batch processing.

The SOI may submit Batch Inquiry files before 5:00PM ET. If a Batch Inquiry file is received after 5:00PM ET, or

outside the window of CDLIS operations, it will be processed starting from the following business day. If a Batch

Inquiry file is resubmitted with the same name, this will overwrite the file previously sent. Overwriting a file should

only be done when a file is corrected for resubmission.

Note: The SOI should not attempt to resubmit a Batch Inquiry file, on the day of submission, after 5:00PM ET. If the

file was submitted in error, the SOI should contact the AAMVA Help Desk for assistance.

Note: In order to process an exceptionally large Batch Inquiry file, the SOI should contact the AAMVA Help Desk for

special arrangements. Jurisdictions should avoid sending large number of messages in a single file because the

corresponding response file can potentially return 16 times more messages.

CD30.2 Batch Research Driver (CDLIS Central Site)

CD30.2.1 Batch Inquiry File Reception

This process begins with the receipt of a Batch Inquiry file from a State of Inquiry (SOI).

CD30.2.2 Validation of Batch Inquiry File

Note: If the batch file sender is not an authorized jurisdiction, the batch file is not processed.

CD30.2.2.1 Validation of Batch Inquiry Control (EQ) Message

This process will verify that only one Batch Inquiry Control (EQ) message is in the Batch Inquiry file.

If the Batch Inquiry file contains no message, terminate the batch file processing and contact the batch file sender to

correct and resubmit the Batch Inquiry file.

If an error is found in the EQ control message, the EQ message is returned with an error indication and an error block,

and the batch file processing terminates.



CD30 BATCH INQUIRY


CD30.2.2.1.1 System Errors


CD30.2.2.1.2 Required Data Errors

This process counts the number of EQ control messages:

If no EQ control message is found, select the first message in the Batch Inquiry file, set the message destination

(GMSDST) of that message with the batch file sender jurisdiction code, return the message with an error block,

and terminate the batch file processing.

Error Text: CONTROL MESSAGE NOT FOUND

If more than one EQ control messages are found, return the first EQ message in the Batch Response file with an

error block attached.

Error Text: MULTIPLE CONTROL MESSAGES

Note: If an SOI sends multiple EQ control messages in the Batch Inquiry file, this process will stop with the second EQ

message found and one EQ message will be returned with an error block attached.

CD30.2.2.1.3 Invalid Data Errors

If any of the following checks fail, the EQ control message will be returned in the Batch Response file with an error

block attached:

If the first two characters of the Message Originator (GMSORG) do not match the batch file sender jurisdiction

code, issue an error.

Error Text: BATCH FILE SENDER IS NOT MSG ORIGINATOR.

If the Message Sender Password (GMSPSW) is does not match the CDLIS password for the SOI, issue an error.

Error Text: PASSWORD RCVD IS NOT VALID PASSWORD.

The Batch Inquiry File Sent Date (DDBISD) must be valid as specified in the ŖAPPENDIX D - DATA

DICTIONARYŗ.

Error Text: INVALID BATCH SENT DATE

If the number of EM inquiry messages sent (DDBST1) is equal to zero, issue an error.

Error Text: EM MESSAGE COUNT IS ZERO

If the number of EM inquiry messages sent (DDBST1) has non-numeric value, issue an error.

Error Text: EM MESSAGE COUNT IS NOT NUMERIC

If the Message Destination (GMSDST) value is not equal to ŘXXř, set the message destination to ŘXXř and issue

an error..

Error Text: INVALID DESTINATION

Test/Production Indicator (GTPIND) value must be equal to ŘTř or ŘPř.

Error Text: INVALID TEST/PROD INDICATOR

If the NCB Transmit Mode (GXMODC) value is not equal to Ř3ř, issue an error.

Error Text: INVALID XMIT CODE



CD30 BATCH INQUIRY


If the NCB Error Code (GNCBER) value is not equal to ŘNř, issue an error.

Error Text: ERROR INDICATOR IS ON

If the Transaction Originator (GTRORG) value is not equal to the Message Originator (GMSORG), issue an

error.

Error Text: INVALID BILLING ID

If the EQ control message does not contain the required blocks, issue an error.

Error Text: INVALID CONTROL MESSAGE

Count the number of EM messages. If the total number of EM messages is not equal to the number of inquiry

messages sent (DDBST1), set the number of EM messages in error (DDBNE1) to zero, and return the EQ

message with an error indication and an error block.

Message EM COUNT IN CTRL MSG NOT EQUAL TO NUM OF EM MSGS

If the EQ control message is returned in error, counts are set to zero for messages processed (DDBNP1), QC response

messages (DDBNR1), and QD response messages (DDBNR2) and the batch file processing terminates.

Note: If an error is found in the original EQ control message, the SOI must investigate and correct the error if the SOI

intends to resubmit the Batch Inquiry file. The SOI should check the error message attached to the EQ control message

returned in the Batch Response file.

CD30.2.2.1.4 Data Cross-Check Errors

None.

CD30.2.2.2 Validation of Other Messages

If no error is found in the EQ control message, the other messages in the batch inquiry file will be edited.




See "CD30.2.3.1.2 Required Data Errors" for required data errors.

CD30.2.2.2.3 Invalid Data Errors

This process will verify that the Batch Inquiry file contains valid Batch Inquiry (EM) messages.

If the Message Type (GMSTYP) value is not equal to ŘEMř, issue an error.

Error Text: MSG CODE NOT VALID OR NOT ALLOWED

For each EM message, if any of the following checks fail, the EM inquiry message will be returned in the Batch

Response file with an error block attached:

If the Message Destination (GMSDST) value is not equal to ŘXXř, set the message destination to ŘXXř

and issue an error.

Error Text: INVALID DESTINATION

If the Message Originator (GMSORG) is not equal to the value in the EQ control message, issue an error.

Error Text: INVALID ORIGIN



CD30 BATCH INQUIRY


If the Message Sender Password (GMSPSW) is does not match the CDLIS password for the SOI, issue an

error.

Error Text: PASSWORD RCVD IS NOT VALID PASSWORD.

If the Test/Production Indicator (GTPIND) is not equal to the value in the EQ control message, issue an

error.

Error Text: INVALID TEST/PROD INDICATOR

If the NCB Transmit Mode (GXMODC) value is not equal to Ř3ř, issue an error.

Error Text: INVALID XMIT CODE

If the NCB Error Code (GNCBER) value is not equal to ŘNř, issue an error.

Error Text: ERROR INDICATOR IS ON

If the Transaction Originator (GTRORG) value is not equal to the Message Originator (GMSORG), issue

an error.

Error Text: INVALID BILLING ID

If the EM inquiry message does not contain the required data blocks, issue an error.

Error Text: INVALID INQUIRY MESSAGE

Count each invalid EM message and record the total in the number of error messages returned (DDBNE1) in the

RQ control message.

If all EM inquiry messages are returned in error during the batch inquiry file validation (DDBNE1 equals to

DDBST1), set to zero the number of EM messages processed (DDBNP1), QC response messages (DDBNR1),

and QD response messages (DDBNR2) in the RQ control message.


See "CD30.2.4.1.4 Data Cross-Check Errors" for data cross-check errors.

If no error is found in the EQ control message and at least one valid EM inquiry message was found, the Central Site

proceeds with the search process, based on schedule.

CD30.2.3 Batch Inquiry Searches

Each EM inquiry message will be processed like an online IM transaction (CD01) with the following differences:

For each EM message processed with no error, a corresponding QC message will be generated. If no match is

found, the EM processing ends with the QC message.

When one or more matches are found, up to fifteen QD messages will be generated.

When all EM messages are processed, a Batch Response Control (RQ) message is created and added to the Batch

Response file. The RQ control message will provide a count of EM messages that passed all validation edits and

were submitted to the search process (DDBNP1).

No status request (SC) message will be sent to the SOR.

When an error occurs, an error block containing the appropriate error message is attached to the EM message and

the EM message is returned in the Batch Response file.

Note: No interactive messages will be sent to the SOI or SOR.



CD30 BATCH INQUIRY


CD30.2.3.1 Validation of Batch Inquiry (EM) Message

When processing the EM inquiry message, validate the NCB and MEC blocks with the same checks performed for the

online IM transaction. If an error is found with the NCB or MEC block, the EM inquiry message must be returned as an

error.

The validation checks described below are performed on the EM inquiry message. These validations apply the same

checks that are performed for the online IM transaction.













CD30.2.3.1.3 Invalid Data Error


Driver Date of Birth (DDVDOB) must be valid as specified in the ŖAPPENDIX D - DATA DICTIONARYŗ.


The Jurisdiction Code embedded in the Driver License Jurisdiction Number (DDLJDL), if present, must conform

to the United States list in the ŖAPPENDIX D - DATA DICTIONARYŗ. If an invalid code is used, issue an

error.



Must be numeric





Driver AKA Date of Birth (DDVKDB), if present, must be valid as specified in the ŖAPPENDIX D - DATA

DICTIONARYŗ.


Driver AKA 2nd Date of Birth (DDVKD2), if present, must be valid as specified in the ŖAPPENDIX D - DATA



CD30 BATCH INQUIRY


DICTIONARYŗ.


Driver AKA 3rd Date of Birth (DDVKD3), if present, must be valid as specified in the ŖAPPENDIX D - DATA

DICTIONARYŗ.


Driver AKA Name count (GMSCNM) must be equal to the total number of AKA names populated in the EM

message.

Error Text: ‘NAME COUNT DOESNT MATCH NUM NAMES’

























Driver AKA Name (DDVKNM), if present, must conform to the requirements listed in ŖAPPENDIX E.1



Driver AKA 2nd Name (DDVKN2), if present, must conform to the requirements listed in ŖAPPENDIX





CD30 BATCH INQUIRY


Driver AKA 3rd Name (DDVKN3), if present, must conform to the requirements listed in ŖAPPENDIX





The Driver License Jurisdiction Number (DDLJDL), if present, must conform to the requirements listed in

"APPENDIX D.1 - DATA ELEMENTS":


If AKA Name and AKA DOB is transmitted, each AKA Name must be paired with an AKA Date of Birth:

If at least one component field of the first occurrence of Person AKA Name Group (BPENG3) is present,

Driver AKA Date of Birth (DDVKDB) must also be present.


If Driver AKA Date of Birth (DDVKDB) is present, at least one component field of the first occurrence

of Person AKA Name Group (BPENG3) must also be present.


If at least one component field of the second occurrence of Person AKA Name Group (BPENG3) is

present, Driver AKA 2nd Date of Birth (DDVKD2) must also be present.


If Driver AKA 2nd Date of Birth (DDVKD2) is present, at least one component field of the second

occurrence of Person AKA Name Group (BPENG3) must also be present.


If at least one component field of the third occurrence of Person AKA Name Group (BPENG3) is present,

Driver AKA 3rd Date of Birth (DDVKD3) must also be present.


If Driver AKA 3rd Date of Birth (DDVKD3) is present, at least one component field of the third

occurrence of Person AKA Name Group (BPENG3) must also be present.


If AKA Name/DOBs are transmitted, the 3rd pair may not be used without the 1st and 2nd pairs and the 2nd pair

may not be used without the 1st pair:

If at least one component field of the second occurrence of Person AKA Name Group (BPENG3) is

present, at least one component field of the first occurrence of Person AKA Name Group (BPENG3) must

also be present.


If at least one component field of the third occurrence of Person AKA Name Group (BPENG3) is present,

at least one component field of the second occurrence of Person AKA Name Group (BPENG3) must also

be present.




CD30 BATCH INQUIRY



If AKA Name and AKA DOB is transmitted, each AKA Name must be paired with an AKA Date of Birth:

If Driver AKA Name (DDVKNM) is present, Driver AKA Date of Birth (DDVKDB) must also be

present.


If the Person Name Group (BPENGP) was not present on the Validation of Batch Inquiry (EM) message

(meaning the state is on a version older than 5.1), and if Driver AKA Date of Birth (DDVKDB) is

present, Driver AKA Name (DDVKNM) must also be present.


If Driver AKA 2nd Name (DDVKN2) is present, Driver AKA 2nd Date of Birth (DDVKD2) must also be

present.



(meaning the state is on a version older than 5.1), and if Driver AKA 2nd Date of Birth (DDVKD2) is

present, Driver AKA 2nd Name (DDVKN2) must also be present.


If Driver AKA 3rd Name (DDVKN3) is present, Driver AKA 3rd Date of Birth (DDVKD3) must also be

present.



(meaning the state is on a version older than 5.1), and if Driver AKA 3rd Date of Birth (DDVKD3) is

present, Driver AKA 3rd Name (DDVKN3) must also be present.


If AKA Name/DOBs are transmitted, the 3rd pair may not be used without the 1st and 2nd pairs and the 2nd pair

may not be used without the 1st pair:

If Driver AKA 2nd Name (DDVKN2) is present, Driver AKA Name (DDVKNM) must also be present.


If Driver AKA 3rd Name (DDVKN3) is present, Driver AKA 2nd Name (DDVKN2) must also be

present.


CD30.2.5 Retrieval

For each valid EM inquiry message, the Central Site will retrieve data from zero to 15 existing MPRs, based on possible

matches of information sent in the EM inquiry message.

Depending on the information sent in the EM inquiry message, the Central Site will execute up to four types of search

routines, in the following order:

ST/DLN Search

SSN search

Primary Name/DOB Search



CD30 BATCH INQUIRY


AKA Name(/DOB) Search

The Central Site includes an MPR reference only once in the list of matches to be returned, even if a given MPR is

identified through more than one type of search routine. If more than 15 possible MPR matches exist, the Central Site

will return only the first 15 MPRs found in the order they were found by the search routines.

The search on MPRs will use the same matching comparisons performed for an online IM transaction.


For each Batch Inquiry file received, this process sends back to the SOI a corresponding Batch Response file.

CD30.2.6.1 Transmission of Number of Batch Status Responses from Inquiry Transaction (QC) Message

For each EM inquiry message processed with no error, this process will send back a corresponding Number of Batch

Status Responses (QC) message.

If there were zero matches, the QC message will be the only response to the SOI and the EM inquiry will end with the

QC message.

The QC message includes:

Message Locator/Header (GMSLOC) set to the value on the original EM inquiry message.

Message Match Count (GMSCNT) set to the number of matching MPRs being sent ('00' - '15').

Message Match Indicator (GMSIND) set to 'Y' if at least one matching MPR was found; 'N' otherwise.

Message Match Sequence ID (GMSMSI) set to the value indicating the order in which the MPR was determined

to be a match ('00' - '15')

Last Match Indicator (GMSLMI) set to 'Y' if this is the last record being sent considered a match; 'N' otherwise

Message Match Limit Exceeded Indicator (GMSLEI) set to 'Y' if more than 15 matches were found; 'N'

otherwise.

Processing Status (GPROST) set to '00'.

Jurisdiction Code - State of Record (GMSSOR) set to the SOR of the first Batch MPR Data for Match (QD)

message sent (CD30.2.6.2).

Message SOR Change in Progress Indicator (GMSSCH) set to 'N' or to the value for this field on the first

matching MPR.

Message Driver Duplicate Indicator (GMSDUP) set to 'N' or to the value for this field on the first matching

MPR.

State Of Record (BJUCD1) set to the SORs of the QD messages sent (up to 15 occurrences).

The QC message may optionally include:

Return as Received Text/Block (GRRECV) set to the value on the original EM inquiry message (if any) (up to 5

occurrences).


and MEC blocks.

CD30.2.6.2 Transmission of Batch MPR Data for Match (QD) Message(s).

For each EM inquiry message processed with no error, if one or more matching MPRs were found, the SOI will receive

up to fifteen Batch MPR Data for Match (QD) messages.

Note: QD messages are generated in the order the matching MPRs were found by search routines. The Message Match

Count (GMSCNT) in the QC message indicates the number of corresponding QD messages sent.

Each QD message includes:



CD30 BATCH INQUIRY



Message Locator/Header (GMSLOC) set to the value on the original EM inquiry message.

Message Match Count (GMSCNT) set to the number of matches found ('01' - '15').

Message Match Indicator (GMSIND) set to 'Y'.


identified as a match ('01' - '15').


Last Match Indicator (GMSLMI) set to 'Y' if the record is the final one returned; 'N' otherwise.

Jurisdiction Code - State of Record (GMSSOR) set to the SOR of the retrieved driver.

Message Match Limit Exceeded (GMSLEI) set to 'Y' if more than 15 matches found; 'N' otherwise.

Message SOR Change in Progress Indicator (GMSSCH) set to the CD20 Message SOR Change in

Progress Indicator (GMSSCH).

Message Driver Duplicate Indicator (GMSDUP) set to 'Y' if the record is currently marked as a potential

duplicate of another driver; 'N' otherwise.

Message AKA DLN Count (GMSCDL) set to the number of AKA DLNs being sent on the message.

Message AKA Name Count (GMSCNM) set to the number of AKA Names being sent on the message.


Message AKA SSN Count (GMSCSS) set to spaces.

The following fields will be populated with the corresponding fields from the matching MPR:



(DDLJDL)

Driver DOB (DDVDOB) set to the CD20 Driver DOB (DDVDOB)



(BPESSD)






Driver SSN Ŕ CDLIS (DDVSS6) set to the CD20 Driver Social Security Number (DDVSSN)

If any MPR AKA field(s) matched on a Primary or AKA entry on the Search Inquiry, the QD message will contain only

those AKA fields from the MPR that were essential in determining the match, i.e. any of the following 3 fields:









Each QD message optionally includes the following fields populated with the corresponding fields from the matching



CD30 BATCH INQUIRY


MPR, if populated in the MPR:




See ŖAPPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPEŗ for remaining elements in the NCB, verification,

and MEC blocks.

CD30.2.6.3 Transmission of Batch Search Inquiry (EM) Message with Errors

If an error is found, this process will append error codes and block(s) to the input EM inquiry message and write the

modified EM message to the Batch Response file. If errors are encountered on the original EM inquiry message that

preclude processing by the Central Site, the following changes will be made in the EM message:


NCB Error Code (GNCBER) set to ŘYř


CD30.2.6.4 Transmission of Batch Response Control (RQ) Message

For each Batch Inquiry file received, this process will generate an RQ control message in the Batch Response file, if a

unique and valid EQ control messages was found.

Note: Only one RQ control message must be in the Batch Response file. The RQ control message may be positioned

anywhere in the Batch Response file.

The RQ message must contain required values for the following batch control elements (blocks 23/3 and 23/4):

Batch Inquiry File Sent Date (DDBISD) set to the value in the original EQ control message.

Batch inquiry message count (DDBST1) set to the value in the original EQ control message.

Batch File Reception Date (DDBIRD) set to the date the Batch Inquiry file was received at the Central Site.

Note: In CDLIS version 4.1.0, this date is set to the date the batch inquiry file processing started at the Central

Site.

Batch File Processing Date (DDBFPD) set to the date the Batch Inquiry file processing started at the Central

Site.

Batch Response File Sent Date (DDBRSD) set to the date the Batch Response file is sent by the Central Site to

the SOI. Note: In CDLIS version 4.1.0, this date is set to the date the batch inquiry file processing is completed

at the Central Site.

Number of EM inquiry messages processed (DDBNP1) set to the count of EM messages successfully validated

in the pre-processing.

Number of EM inquiry messages found to be in error (DDBNE1) set to the number of EM messages sent back to

the SOI in the Batch Response file.

Number of batch response QC messages (DDBNR1) set to the count of QC messages sent in the Batch Response

file.

Number of MPR data match QD messages (DDBNR2) set to the count of QD messages sent in the Batch

Response file.

The RQ control message must contain the following elements set to required values:

NCB Transmit Mode (GXMODC) set to the value of Ř3ř.

Message Locator (GMSLOC) set to the value of the original EQ control message, if an EQ message was found.


and MEC blocks.



CD30 BATCH INQUIRY


CD30.2.6.5 Transmission of Batch Inquiry Control (EQ) Message with Errors

If an error is found in the original EQ control message (CD30.2.3), this process will append error codes and block(s) to

the EQ control message and return the modified EQ control message in the Batch Response file.

The original EQ control message is returned to the SOI with the following changes:


NCB Error Code (GNCBER) set to ŘYř.


The following batch control elements (blocks 23/3 and 23/4) will be set:



Site.

Batch File Processing Date (DDBFPD) set to the date the Batch Inquiry file processing started at the Central

Site.




Number of EM inquiry messages processed (DDBNP1) set to zero.

Number of EM inquiry messages found to be in error (DDBNE1) set to zero.

Number of batch QC response messages (DDBNR1) set to zero.

Number of batch QD response messages (DDBNR2) set to zero.

CD30.2.6.6 Transmission of Batch Response File

When a Batch Inquiry file is processed, this process will transmit a corresponding Batch Response file to the SOI

through FTP. Batch Response files use data formats ASCII or EBCDIC.

The Batch Response file must be sent to the SOI within 2 business days of the Batch File Reception Date (DDBIRD).

When sending a Batch Response file, the filename should be derived from the corresponding Batch Inquiry filename

and must use the file naming format provided by AAMVA at the time the jurisdiction signed for batch processing.

For each Batch Inquiry file processed, one corresponding Batch Response file is sent back to the SOI.

Before sending the Batch Response file to the SOI, the RQ control message must be checked.

If the transmission date (DDBRSD) is less than the processing date (DDBFPD), issue an error.

Error Text: ‘INVALID XMIT DATE’

If the processing date (DDBFPD) is less than the reception date (DDBIRD), issue an error.

Error Text: ‘INVALID PROCESSING DATE’

If the number of messages processed (DDBNP1) is greater than the number of messages submitted (DDBST1) in

the original EQ control message, issue an error.

Error Text: ‘INVALID COUNT OF MESSAGES PROCESSED’

If the number of EM messages in error (DDBNE1) is greater than the number of messages submitted (DDBST1)

in the original EQ control message, issue an error.

Error Text: ‘INVALID MESSAGE COUNT – EM’

If the number of QC messages (DDBNR1) is greater than the number of messages processed (DDBNP1), issue

an error.



CD30 BATCH INQUIRY


Error Text: ‘INVALID MESSAGE COUNT – QC’

If an error is found in the Batch Response file, the error will be investigated before placing the file for retrieval by the

SOI via FTP:

If the error is corrected, the corrected Batch Response file is placed for retrieval by the SOI via FTP.

If the error cannot be corrected, the SOI is notified and may request re-processing of the batch inquiry file.

CD30.3 Receive Batch Inquiry Response (State of Inquiry (SOI))

CD30.3.1 Validation of the Batch Response File

The SOI will receive one Batch Response file corresponding to each Batch Inquiry file sent to the Central Site.

The SOI can expect in the Batch Response file:

If no EQ control message was found: one message corresponding to the first message found in the Batch Inquiry

file with an error block attached.

If no error was found in the original EQ control message: all QC and QD responses returned by the inquiries, all

EM inquiry messages that had an error, one RQ control message, and all messages rejected due an invalid

message type error.

If an error was found in the original EQ control message or no EM message was found: the EQ control message

with an error block attached.

If all EM messages encountered an error: one RQ control message, all EM inquiry messages returned in error,

and all messages rejected due an invalid message type error.

Note: The Batch Response file contains only one control message that is either an RQ or an EQ message. The control

message may be positioned anywhere in the Batch Response file. If no control message is found, the Batch response

file will contain an error message corresponding to the first message in the Batch Inquiry file.

Note: If the SOI does not receive a Batch Response file more than 2 business days after submitting a Batch Inquiry file,

the SOI should contact the AMMVA Help Desk for investigation.

BATCH RESPONSE FILE FORMAT

This file may contain four or more types of records:

Control (message type 'EQ' or 'RQ')

Inquiry Error (message type 'EM')

Match Count (message type 'QC')

MPR Data (message type 'QD')

Messages rejected because of an invalid message type.

Record Type Position Length (chars) Occurrence

Control EQ/RQ Anywhere in file 330 to 990 1

Inquiry Error EM Before/After EQ/RQ 264 to 1188 0 to 1 per EM processed

Match Count QC Before/After EQ/RQ 198 to 924 1 per EM processed without error

MPR Data QD Before/After EQ/RQ 330 to 1056 0 to 15 per QC

Invalid Message Before/After EQ/RQ



CD30 BATCH INQUIRY


CD30.3.1.1 Reception of the Batch Inquiry Control (EQ) Message With Error

For each Batch Response file received from the Central Site, the SOI should check if an EQ control message was

returned:

If an EQ control message is found, none of the EM inquiry messages was processed. The error message in the

error block(s) attached to the EQ control message will indicate the reason. The SOI should investigate and

possibly correct and resubmit the entire Batch Inquiry file.

If no EQ or RQ control message is found, the SOI can expect one error message, corresponding to the first

message found in the batch inquiry file.

If an EQ control message is found, the following elements will be set:


Batch Inquiry Message Count (DDBST1) set to the value in the original EQ control message.



Site.

Batch File Processing Date (DDBFPD) set to the date the Batch Inquiry file was processed at the Central Site.




Number of EM inquiry messages processed (DDBNP1) set to zero.

Number of EM inquiry messages found to be in error (DDBNE1) set to zero.

Number of batch response QC messages sent (DDBNR1) set to zero.

Number of batch response QD messages sent (DDBNR2) set to zero.

CD30.3.1.2 Reception of the Batch Response Control (RQ) Message

When a Batch Response file is received from the Central Site, the SOI should verify if an RQ control message is

returned.

If no RQ control message is found, none of the EM inquiry messages was processed. The SOI can expect one errored

EQ control message returned in the Batch Response file or one error message corresponding to the first message in the

Batch Inquiry file. The SOI should investigate and possibly correct and resubmit the entire Batch Inquiry file.

The RQ message will contain the following batch control elements (blocks 23/3 and 23/4):


Batch inquiry message count (DDBST1) set to the value in the original EQ control message.



Site.

Batch File Processing Date (DDBFPD) set to the date the Batch Inquiry file was processed at the Central Site.




Number of EM inquiry messages processed (DDBNP1) set to the count of EM messages that were submitted to

the search process.

Number of EM inquiry messages found to be in error (DDBNE1) set to the number of errored EM messages sent

back to the SOI in the Batch Response file.

Number of QC messages sent (DDBNR1) set to the count of QC messages sent in the Batch Response file.

Number of QD messages sent (DDBNR2) set to the count of QD messages sent in the Batch Response file.

If an RQ control message is found in the Batch Response file, the SOI should check the counts of number of EM



CD30 BATCH INQUIRY


inquiry messages processed (DDBNP1), Number of QC messages sent (DDBNR1), and number of QD messages sent

(DDBNR2). If those counts are zero, the SOI should investigate and possibly correct and resubmit the entire Batch

Inquiry file.

If the number of EM inquiry messages submitted (DDBST1) is equal to the number of messages returned in error

(DDBNE1), none of the EM inquiry messages was successfully processed. The SOI should investigate and possibly

correct and resubmit the entire Batch Inquiry file.

If the number of messages processed (DDBNP1) is:

Equal to zero, none of the EM inquiry messages passed the initial validation edits and the SOI can expect all EM

messages returned in error.

Not equal to zero, the SOI can expect in the Batch Response file all QC and QD responses from the inquiries, all

EM inquiry messages that encountered an error, and any messages submitted with an invalid message type.

CD30.3.1.3 Reception of the Number of Batch Status Responses (QC) Message

For each EM inquiry message processed with no error, the SOI will receive a corresponding Number of Batch Status

Responses (QC) message from the CDLIS Central Site.

The QC message includes:



Note: The match count indicates how many corresponding QD messages are sent in the Batch Response file.








State Of Record (BJUCD1)

The QC message may optionally include:

Return as Received Text/Block(s) (GRRECV)

Upon receipt of the QC message, the SOI should check the Message Match Count (GMSCNT):

If equal to zero, no matches were found in the CDLIS Master Pointer File. No QD messages will follow.

If greater than 0 but less than 15, the SOI can expect exactly the number of QD messages indicated.

If equal to 15, the SOI can expect exactly fifteen QD messages. The Message Match Limit flag will be set to 'Y'

if more than 15 matches were found. This indicates more than 15 matches were found but QD messages for only

the first 15 are being sent.

Note: If more than fifteen matches are found, the SOI may follow with a direct state-to-state inquiry to obtain additional

information or change the search criteria to reduce the number of matches.

CD30.3.1.4 Reception of the Batch MPR Data for Match (QD) Message(s)

For each EM inquiry message processed with no error, if one or more matches were found, the SOI will receive up to

fifteen Batch MPR Data for Match (QD) messages from the CDLIS Central Site.

Note: For each EM inquiry, a counter in the corresponding QC message (GMSCNT) indicates how many QD messages

are sent.

Each QD message includes:



CD30 BATCH INQUIRY
















Driver DOB (DDVDOB)



The last 5 positions of Driver SSN (DDVSS6)


AKA SSN Count (GMSCSS)


Driver SSN (DDVSS6)

Note: The AKA Count fields (GMSCDL and GMSCNM) on each QD message will reflect the number of AKAs on the

corresponding MPR.

If any MPR AKA field(s) matched on a Primary or AKA entry on the Search Inquiry, the QD message will contain only

those AKA fields from the MPR that were essential in determining the match, i.e. any of the following three fields:





Each QD message may optionally include:




CD30.3.1.5 Reception of the Batch Search Inquiry (EM) Messages with Errors

If errors are encountered in an original EM inquiry message, the EM message will be returned with changes to the

following elements:

NCB Number of Text Blocks (GNBTST)

NCB Message Length(GMSLEN)




CD30 BATCH INQUIRY






CD31 MPR DATA QUALITY VALIDATION AND VERIFICATION




The Master Pointer Record (MPR) Data Quality Validation and Verification process identifies missing or incorrect data

on the CDLIS Master Pointer Records (MPRs) at the Central Site based on driver record information resident at the

corresponding State of Record (SOR). The goal of the process is to help jurisdictions ensure that the MPRs are

complete and accurate as required by federal regulations (see Title 49 Code of Federal Regulations Parts 383 and 384

[49CFR383-4]).

In support of this process, the CDLIS Central Site checks for the following:

a missing MPR at the Central Site for an existing driver record at the SOR,

a missing driver history record at the SOR for an existing MPR at the Central Site,

data content inconsistencies between the MPR at the Central Site and the corresponding driver record at the

SOR, and

missing and/or invalid data content on the MPR at the Central Site and on the driver record at the SOR.

FMCSA, in coordination with each SOR and the CDLIS Central Site, schedules the execution of this process to occur at

least once per year. Either the SOR or FMCSA may request additional executions, but only through coordination and

approval by all involved stakeholders.

The following diagram illustrates the steps involved in the process, as follows:The SOR and/or FMCSA requests the

process to be scheduled.

The SOR, FMCSA, and the CDLIS Central Site coordinate a mutually acceptable Ŗas ofŗ date and time for the

SOR to extract its driver record information and for the CDLIS Central Site to extract the corresponding MPR

data from the Central Site.

The SOR extracts its driver record information transmits it to the CDLIS Central Site, via secure means.

The CDLIS Central Site extracts the corresponding MPR data.

The CDLIS Central Site verifies that the data received from the SOR is in the correct overall format and can be

processed. If errors are found that preclude further processing, the CDLIS Central Site notifies the SOR and

requests correction

In coordination with the CDLIS Central Site, the SOR corrects the errors, if needed, retransmits the extracted

driver record information to the CDLIS Central Site.

The CDLIS Central Site validates and verifies the SORřs extracted data and the corresponding MPR data.

The CDLIS Central Site generates both detail and summary reports based on the results of the performed

validations. Detail information is provided to the SOR. Summary information is provided to the SOR, FMCSA

and the AAMVA Operations Help Desk.

The summary information is retained at the CDLIS Central Site.

The driver record information provided by the SOR as input to this process is not retained at the CDLIS Central

Site. Upon successful completion of the process, this information is destroyed.

The SOR analyzes the detailed report and formulates a plan, in coordination with FMCSA, to correct errors

according to a schedule. Resolution of broken and missing pointers is critical to the effectiveness of the CDLIS

application. As such, the SOR is expected to correct these kinds of errors before any others, and with a sense of

urgency.

The SOR corrects the errors in its own driver record data and corrects erroneous MPR data at the CDLIS Central

Site through use of update transactions via CDLIS.





Figure 1: Processing Steps of the CD31 MPR Data Validation and Verification Process

Time Jurisdiction Central Site FMCSA

2A

Coordinate the Extract

Schedule and Parameters

3

Extract DHR Data

5

Extract MPR Data

6

Preprocess SOR’s DHR

Extract

9

Generate Results and

Distribute

11A

Resolve Data

Quality Issues

11B

Process Transactions to

Correct MPR data

10A

Devise Plan for Resolving

Data Quality Issues

10B


Data Quality Issues

Data

Detailed

Reports

parms parms

7

Resolve Formatting Issues

and Re-drive process

Summary

Reports

Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame

4

Send Extract File to

Central Site

Data Data

Data

8

Validate and Verify

MPR – DHR Data

Data

1A

Decide to Request MPR –

DHR Validation and

Verification

1B


DHR Validation and

Verification

2B

Coordinate the Scope and

Schedule of the Process

2C



Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame





CD31.1 Request Validation and Verification (State of Record (SOR), FMCSA)

In the first step of the MPR Validation and Verification Process, the SOR or FMCSA decides to request the scheduling

of the process.

CD31.2 Coordinate Scope and Schedule (State of Record (SOR), FMCSA, AAMVA)

The SOR or FMCSA notifies the other processors, and coordinates with the other processors to determine the

schedule for data extraction, validation and verification, and the reporting of the results.

CD31.3 Extract Driver Data (State of Record (SOR))

According to the schedule, the SOR creates an extract file composed of the appropriate driver records and associated

control record. The SOR must use the file naming format provided by the CDLIS Central Site at the time the Data

Validation and Verification process was scheduled.

The extract file includes one and only one MPR DHR Validation Control (DQ) message, plus multiple records

reflective of driver data.

The MPR DHR Validation Control (DQ) message can be located anywhere within the extract file. The extract file will

be sorted at the Central Site before validation processing to ensure that the MPR DHR Validation Control (DQ)

message is processed first.

The MPR DHR Validation Control (DQ) message contains control information about the extract file and process to be

executed.

The MPR DHR Validation Control (DQ) message must contain the following information:

Message Locator (GMSLOC) initialized to spaces

Data Validation and Verification Type (GRCDDT) set to Ř1ř for MPR only

Jurisdiction Code-Licensing (DDLJUR) set to the Jurisdiction Code of the state extracting the data (the SOR)

Record ŘAs ofř Date (GRCAOD) set to the Ŗas ofŗ date of the extract

Record ŘAs ofř Time (GRCAOT) set to the Ŗas ofŗ time of the extract

Driver Count (DDVCNT) set to the total number of drivers extracted to the file

Extract Record Count (GRCCNT) set to the total number of records contained in the extract file, including the

control record

SSN Start Range (DDVSS0) set to blank indicating that all drivers are being extracted

SSN End Range (DDVSS9) set to blank indicating that all drivers are being extracted

DLN Start Range (DDLNU0) set blank indicating that all drivers are being extracted

DLN End Range (DDLNU9) set to blank indicating that all drivers are being extracted

The driver data is provided in AMIE format, where a given driverřs detail information is represented by one Driver

History (HD) message.

The Message Locator (GMSLOC) on the Driver History (HD) message must be populated with the appropriate driverřs

Driver License Number. This will be used by the CDLIS Central Site to sort the extract file prior to processing.

To illustrate the rules for building the extract file, the following example lists the records of the extract file for the

following control message:





Table 3: Example Control Message Values

Element Name Value

Data Validation and Verification Type 1

Jurisdiction Code-Licensing VA

ŘAs ofř Date/Time 20080731130000

Driver Count 0000003

Extract Record Count 00000004

SSN Start Range

SSN End Range

DLN Start Range

DLN End Range

The SOR extract, as of July 31, 2008 at 1 p.m., includes three drivers, with state license numbers VA1000045301,

VA1000045302, and VA1000045303. The records in the extract file in this example are as follows:

HD record (for driver VA1000045301)



DQ control record

The SOR may want to consider using the UNI Outbound Batch to Batch process to simplify the creation of the extract

file. The AAMVA Operations Help Desk should be contacted for additional information.

CD31.4 Transmit Extract File to Central Site (State of Record (SOR))

The SOR transmits the extract file per predefined schedule to the CDLIS Central Site using one of the following

mechanisms:

TCP/IP transfer protocols and Secure Shell File Transfer Protocol (sftp).

ftp with Secure Sockets Layer / Transport Layer Security (ftps) via AAMVAnet, or

viaencrypted physical media by secure means

If the SORřs the extract file is too large to send via ftp, the SOR divides the extract file into multiple smaller files and

transmits each via sftp or ftps or sends it on encrypted physical media by secure means.

CD31.5 Extract MPR Data (CDLIS Central Site)

Upon receipt of the extract file, the CDLIS Central Site sorts the file on Message Locator (GMSLOC) to ensure that the

MPR DHR Validation Control (DQ) message is processed first, followed by driver information in ST-DLN order.

The CDLIS Central Site extracts the MPR data corresponding to the control information provided.

CD31.6 Preprocess SOR Extract File (CDLIS Central Site)

CD31.6.1 Check SOR Extract File Control Data

The CDLIS Central Site receives and preprocesses the SOR Extract File to ensure that there are no obvious errors

inherent in the extracted file. Specific preprocessor validations include the following:

One and only one control message exists.

All required information is provided on the control message.

All provided control information is in valid format and valid values.





Driver Count is consistent with the number of drivers provided in the extract file.

Extract Record Count is consistent with the number of records provided in the extract file, inclusive of the

control record.

Jurisdiction Code provided on the control record is consistent with the contents of the extract file.

CD31.6.2 Notify SOR of Control Data Check Results

If errors are detected in the preprocessor step that preclude further processing of the extract file, the CDLIS Central Site

notifies the SOR of the errors and works with the SOR to determine what specific steps to take to resolve the errors.

CD31.7 Resolve Issues and Re-drive process (State of Record (SOR))

The SOR determines the source of the error(s) and either corrects the problem(s) at the SOR before resubmitting the

SOR Extract File for processing, or works with the CDLIS Central Site to correct the problem(s) to the file already at


CD31.8 Validate and Verify SOR Extract Data and MPR data (CDLIS Central Site)

CD31.8.1 Check for mismatches between the SOR Extract Data and associated MPR data

The CDLIS Central Site compares the corresponding driver demographic data in the SOR Extract file with the

corresponding MPR data from the Central Site extract file for mismatches. The specific checks are as follows.

MPRs that exist on the CDLIS Central Site but do not have associated driver records at the SOR (i.e., Ŗbroken

pointersŗ)

Driver records extracted at the SOR with no corresponding MPRs on the Central Site (i.e., Ŗmissing pointersŗ)

Mismatches between Central Site MPR and SOR data (e.g., MPR Driver Date of Birth = Ř19500201ř and DHR

Driver Date of Birth = Ř19500102ř)

Invalid data content in either the MPR or the SOR data

CD31.8.2 Verify SOR Extract Data and associated MPR data

The CDLIS Central Site validates and verifies the driver data in the SOR extract file and in the MPR extract file.

In general, the checks are as follows:

Missing required data (e.g., missing DHR Driver Date of Birth)

Invalid data (e.g., a DHR driver weight of ŖAAAŗ)

Anomalous Data (data with valid entries but highly unlikely values, e.g., an MPR driver weight of 999 pounds)

See "CD31.SUPPLEMENT.A MPR DATA VALIDATION AND VERIFICATION CHECKS" for a complete list of

validation and verification checks that the CDLIS Central Site performs.

Note that it is anticipated that the requirements for specific validation and verification checks will change over time.

Currently identified checks may at some point no longer be necessary to perform and additional checks that are not

currently defined will need to be added. Providing for this kind of flexibility is crucial to the successful implementation

of this process.

CD31.9 Generate and Distribute Results (CDLIS Central Site)

After compiling the results of the validations, the CDLIS Central Site makes available the following process results:





Table 4: CD31 MPR Data Validation and Verification Reports

Report Recipient

1 Detailed Results: A detailed results file that contains all the mismatches, errors and

anomalies found for each driverřs license number from the MPR and from the SOR

Extract File.

SOR

2 SOR Summary Results: A summary results file that contains the failure rate for the

given SOR, by edit number within the first three categories as specified in section

CD31.8.1.

FMCSA and SOR

3 Summary Comparison Results: A summary results file that contains the comparative

failure rate of all jurisdictions that have executed this process. No personally identifiable

information is conveyed in this report.

FMCSA

4 FMCSA Overview Compliance Report: A summary results file that contains a summary

of the number of licenses not compliant with existing FMCSRs, inclusive of a grand

total. No personally identifiable information is conveyed in this report.

FMCSA

These reports are formatted as variable length records that can be loaded into a spreadsheet, like Excel. The recipient

can then sort and summarize the data on any column or group of columns, as desired. These reports are explained

further in the following sections.

CD31.9.1 Create Detailed Results File

As the CDLIS Central Site checks the data, it creates a detailed results file containing all the mismatches, errors and

anomalies that are identified for each driver record and each MPR during the process. The detailed results file is

provided to the SOR.

The file consists of variable length, delimited records, with one record for each error. Each record on the file contains

the following information:

ST/DLN, to identify the driver and enable the SOR to correct the DHR

Error/Exception Number

Descriptive Error Message

Error Category

Applicable FMCSR number, if known

Edit Number (unique identifier) within the FMCSR

Input file containing the error (MPR, SOR Extract File, both)

Data Element name corresponding with the element in error (6 character unique identifier as defined in the Data

Dictionary),

Data Element Descriptive name corresponding with the element in error

Specific value of the offending data element.

CD31.9.2 Create SOR Summary Results File

The SOR Summary Results File - Summary report - Failure Rate by Edit Number within FMCSR - contains a summary

of all the errors found in the SORřs data extract and the corresponding MPR data, shown by edit number within

FMCSR.

For each edit number within FMCSR, in addition to the number of related errors found, the report also shows the

number of times the Central Site was able to execute the check (i.e., the number of times an error was found plus the

number of times no error was found).





The file also includes the percent failure rate for each edit, calculated as the ratio of the number of errors divided by the

total number of checks executed.

CD31.9.3 Create Summary Comparison Results File

The Summary Comparison Results File - Summary Report - Failure Rate by FMCSR - is an executive level report

showing a summary of all jurisdictions that have submitted an extract file to this process. This report is similar to the

ŖSummary Report - Failure Rate by Edit Number within FMCSRŗ, except that failure rates for each jurisdiction are

shown by FMCSR rather than by edit number.

The report shows the following:

Jurisdiction Name

Number of errors found

Total number of times that any edits related to that FMCSR were executed

Failure rate for that FMCSR to be the total number of errors found as a percentage of the total number of times

the related edits were executed

CD31.9.4 Distribute Reports

The CDLIS Central Site makes the results of the process available to the SOR and FMCSA, as appropriate. The CDLIS

Central Site must format the detailed error report to enable the SOR either to print out the results as a text file or to

import the information easily into an EXCEL spreadsheet or other database at the SOR.

The CDLIS Central Site archives the summary reports for 18 months.

CD31.10 Determine Plan for Resolving Data Validation and Verification Issues (State of Record (SOR), FMCSA)

CD31.10.1 Determine priority of corrections

When the SOR receives the detailed and summary reports from CDLIS Central Site, it must analyze the mismatches,

errors, and anomalies reported in the file. It then coordinates with FMCSA to establish a priority for correcting the

various types of mismatches, errors, and anomalies.

CD31.10.2 Generate Plan

The SOR must develop a detailed action plan to ensure that mismatches, errors and anomalies are corrected according to

the priority set by FMCSA. The plan must include a specific time-line for correcting the errors. FMCSA must approve

the plan.

CD31.11 Resolve Data Validation and Verification Issues (State of Record (SOR), CDLIS Central Site)

The SOR corrects the DHR mismatches, errors, and anomalies according to the plan approved by FMCSA. The SOR

and the CDLIS Central Site coordinate the scheduling of any Add driver, Delete Driver, Update Data, and Update AKA

Data Transactions to correct MPR mismatches, errors, and anomalies.





CD31.SUPPLEMENT.A MPR DATA VALIDATION AND VERIFICATION CHECKS

CD31.A.1 Introduction

This supplement contains the checks that the CDLIS Central Site performs in the CD31 MPR Data Validation and

Verification Process.

LEGEND

384 Ŕ The value in this column is the subsection of the FMCSR, Title 49 Part 384, which relates to the data validation.

For example, the value in the first row of Table 1 (Ŗ207ŗ) relates the data validation to Title 49 Code of Federal

Regulations Part 384.207.

Code Ŕ The Data Check ID Code in the format N-N.NN that uniquely identifies the data check. The code is a

concatenation of three fields: the first field, to the left of the dash, indicates the category of data (for example, Ŗlicense

dataŗ), the second field between the dash and the decimal indicates the kind of exception (for example, Ŗmissing

required dataŗ), and the third field, to the right of the decimal, is an arbitrary number that makes the code unique .

Thus, the ID Code 1-1.01 in the first row of Table 1 identifies the check for a broken pointer.

The first field has a value of 1 indicating that the data is MPR data (data from either the MPR or the corresponding data

from the driver record).

The second field has values ranging from 1-7, with the following meanings.

1. Broken pointerŕa CDLIS CS DLN on the MPR has no matching DLN on the SOR extract file.

2. Missing pointerŕa DLN on the SOR extract file has no matching DLN on the CDLIS CS MPR.

3. Unmatched MPR Ŕ DHR dataŕa specific data value in the SORřs driver record is different from its

corresponding data value on the MPR at the Central Site.

4. Missing required dataŕa specific required data element value is blank.

5. Invalid dataŕa specific data element value is not correct according to the domain or formatting rules in

ŖAPPENDIX D - DATA DICTIONARYŗ and the CDLIS specifications (e.g., a driver weight of ŖAAAŗ)

6. Anomalous dataŕa specific data element value is valid but is probably incorrect (e.g., a driver weight of 900

pounds)

7. Inconsistent dataŕOne piece of SOR data contains a value that is inconsistent with another related piece of

SOR data.

Data Check Ŕ Brief explanation of the data validation and verification rule.

Exception Message Ŕ Text string explaining error or warning that appears in the detailed exception report.

CD31.A.2 MPR / Driver Record Matching and Validation

CD31.A.2.1 Table A.1: Driver Demographic Data

Table A.1: Validations that pertain to Driver Demographic Data

384. Code Data Check Exception

Message

Exception Category Code 1. Broken-Pointer Check

207 1-1.01 Each Driver License Jurisdiction Number (DDLJDL) on the CS extract file must

exactly match a Driver License Jurisdiction Number (DDLJDL) of the SOR

extract file

MPR ST/DLN

NOT FOUND

ON SOR

EXTRACT FILE

Exception Category Code 2. Missing-Pointer Check







Message

207 1-2.01

Each DHR Driver License Jurisdiction Number (DDLJDL) on the HD record of

the SOR extract file must exactly match a Driver License Jurisdiction Number

(DDLJDL) on the Central Site extract file, unless the SOR Extract Date is more

than 10 days later than the corresponding, valid Driver License Issue Date

(DDLISS)

DHR ST/DLN

NOT FOUND

ON CS

EXTRACT FILE

Exception Category Code 3. Mismatched MPR-DHR Data ChecksŕFor each matching MPR Ŕ DHR Driver

License Jurisdiction Number (DDLJDL) pair

207 1-3.04 The MPR Person Name Group (BPENGP) must exactly match the corresponding

DHR Person Name Group (BPENGP)

DHR DATA

INCONSISTENT

WITH MPR

DATA Ŕ

DRIVER NAME

207 1-3.08 The MPR Person Date of Birth (BPEDOB) must exactly match the corresponding

DHR Driver Date of Birth (DDVDOB)

DHR DATA

INCONSISTENT

WITH MPR

DATA Ŕ DOB

207 1-3.12 The MPR Person SSN Last 5 Digits (BPESSD) must exactly match the last five

digits of the corresponding DHR Driver SSN Ŕ CDLIS (DDVSS6)

DHR DATA

INCONSISTENT

WITH MPR

DATA Ŕ SSN

Exception Category Code 4. Missing Required-Data ChecksŕFor each matching MPR Ŕ DHR Driver License

Jurisdiction Number (DDLJDL) pairR

207 1-4.01 The Jurisdiction Code (DDLJU1) in the Driver License Jurisdiction Number

(DDLJDL) must be present

STATE CODE

REQUIRED

207 1-4.02 The Driver License Number (DDLNUM), in the Jurisdiction Driver License

Number (DDLJDL), must be present

DLN

REQUIRED

207 1-4.04 The Driver Sex (DDVSEX) must be present on the DHR SEX CODE

REQUIRED

207 1-4.08 At least one component field of Person Name Group (BPENGP) must be present NAME

REQUIRED

207 1-4.12 The Driver SSN - CDLIS (DDVSS6) must be present on the DHR

The Person SSN Last 5 Digits (BPESSD) must be present on the MPR

SSN REQUIRED

207 1-4.16 The Driver Date of Birth (DDVDOB) must be present on the DHR

The Person Date of Birth (BPEDOB) must be present on the MPR

DOB

REQUIRED

Exception Category Code 5. Invalid-Data ChecksŕFor each matching MPR Ŕ DHR Driver License Jurisdiction

Number (DDLJDL) pair, when the fields exist

207 1-5.01 The Jurisdiction Code (DDLJU1), in the Driver License Jurisdiction Number

(DDLJDL), must be in list of U.S. jurisdiction codes in the BJUCDE domain as

specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID

STATE CODE

207 1-5.04 The Driver Sex (DDVSEX) must be one of the codes listed in "APPENDIX D.1 -

DATA ELEMENTS".

INVALID SEX

CODE







Message

207 1-5.08 The Person Name Group (BPENGP) must conform to the requirements listed in

"APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008)

VALIDATIONS"

See "APPENDIX

E.3 - AAMVA

PERSON NAME

STANDARD

(2008)

VALIDATIONS"

for specific error

text associated

with this error.

207 1-5.12 The Driver Date of Birth (DDVDOB) must be valid as specified in "APPENDIX

D.1 - DATA ELEMENTS" and in "2.2.2 Dates"

INVALID DOB

207 1-5.16 The Driver SSN - CDLIS (DDVSS6) must be numeric, positions 1 Ŕ 3 must be

between Ř000ř and Ř999ř inclusive, positions 4 Ŕ 5 must be between Ř01ř and Ř99ř

inclusive, and positions 6 Ŕ 9 must be between Ř0001ř and Ř9999ř inclusive.

INVALID SSN

Exception Category Code 7. Inconsistent-Data Cross-ChecksŕFor each matching MPR Ŕ DHR Driver License

Jurisdiction Number (DDLJDL) pair

207 1-7.01 Driver Sex (DDVSEX) Code = Ř0ř or Ř9ř and Driver SSN Ŕ CDLIS (DDVSS6)

not Ř999999999ř on the DHR

SEX NOT

DETERMINED

AND SSN NOT

999999999

207 1-7.02 Driver Date of Birth (DDVDOB) must be present if SSN is not Ř999999999ř on

the DHR

DOB BLANK

AND SSN NOT

999999999



CD32 (PILOT) DHR DATA QUALITY VALIDATION AND VERIFICATION




The Driver History Record (DHR) Data Quality Validation and Verification process identifies missing or incorrect data

on the Driver History Records (DHR)s of a given State of Record (SOR). The goal of the process is to help

jurisdictions ensure that the DHRs are complete and accurate, as required by federal regulations (see Title 49 Code of

Federal Regulations Parts 383 and 384 [49CFR383-4]).

The Driver History Record (DHR) Data Quality Validation and Verification process is a pilot project, which will

initially be implemented by only four or five jurisdictions. Fulfillment of CD32 (Pilot) DHR Data Quality

Validation and Verification is not a requirement for a Jurisdiction to go live with CDLIS Release 5.1.

Results from the pilot effort will be used to determine the extent of DHR validations to be performed and the minimum

frequency with which the process must be executed.

Consequently, requirements as specified in this in ŖCD32 (PILOT) DHR DATA QUALITY VALIDATION AND

VERIFICATIONŗ should be considered preliminary.

In support of this process, the CDLIS Central Site checks for the following:

missing and/or invalid data content on the DHR at the SOR.

anomalous data for the following types of data;

o Driver demographic data on the DHR

o Driverřs license data on the DHR (including the data about license endorsements and restrictions, the

HAZMAT endorsement background records check, and the 10-year history check)

o Driverřs permit data on the DHR (including data about permit restrictions)

o Driverřs conviction data on the DHR

o Driverřs accident data on the DHR

o Driverřs withdrawal data on the DHR (including linkage data indentifying the convictions that resulted in

the withdrawal)

FMCSA, in coordination with each SOR and the CDLIS Central Site, schedules the execution of this process to occur

on a predefined schedule. Either the SOR or FMCSA may request additional executions, but only through coordination

and approval by all involved stakeholders.

The following diagram illustrates the steps involved in the process, as follows:

The SOR and/or FMCSA requests the process to be scheduled.

The SOR, FMCSA, and the CDLIS Central Site coordinate a mutually acceptable Ŗas ofŗ date and time for the

SOR to extract its DHR data.

The SOR extracts its DHR data and transmits it to the CDLIS Central Site via secure means.

The CDLIS Central Site verifies that the data received from the SOR is in the correct overall format and can be

processed. If errors are found that preclude further processing, the CDLIS Central Site notifies the SOR and

requests correction.

In coordination with the CDLIS Central Site, the SOR corrects the errors and, if needed, retransmits the extracted

DHR data to the CDLIS Central Site.

The CDLIS Central Site validates and verifies the DHR data, including detailed license, permit, conviction,

accident, and withdrawal information.

The CDLIS Central Site generates both detail and summary reports based on the results of the performed

validations. Detail information is provided to the SOR. Summary information is provided to the SOR, FMCSA

and the AAMVA Operations Help Desk.

The summary information is retained at the CDLIS Central Site.

The driver record information provided by the SOR as input to this process is not retained at the CDLIS Central

Site. Upon successful completion of the process, this information is destroyed.





The SOR analyzes the detailed report and formulates a plan, in coordination with FMCSA, to correct errors

according to a schedule.

The SOR corrects the errors in its own DHR data.





Figure 2: Processing Steps of the CD32 DHR Data Validation and Verification Process

Time Jurisdiction Central Site FMCSA

2A

Coordinate the Extract

Schedule and Parameters

3

Extract DHR Data

5

Extract MPR Data

6

Preprocess SOR’s DHR

Extract

9

Generate Results and

Distribute

11A

Resolve Data

Quality Issues

11B

Process Transactions to

Correct MPR data

10A


Data Quality Issues

10B


Data Quality Issues

Data

Detailed

Reports

parms parms

7

Resolve Formatting Issues

and Re-drive process

Summary

Reports

Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame

4

Send Extract File to

Central Site

Data Data

Data

8

Validate and Verify

MPR – DHR Data

Data

1A


DHR Validation and

Verification

1B


DHR Validation and

Verification

2B



2C



Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame

Within ?

Time-frame





CD32.1 Request Validation and Verification (State of Record (SOR), FMCSA)

In the first step of the DHR Validation and Verification Process, the SOR or FMCSA decides to request the scheduling

of the process.

CD32.2 Coordinate Scope and Schedule (State of Record (SOR), FMCSA, AAMVA)

The SOR or FMCSA notifies the other processors, and coordinates with the other processors to determine the schedule

for data extraction, validation and verification, and the reporting of the results.

Coordination also includes determining what range of SSNs or DLNs is to be extracted, if a subset of data is to be

processed. Normally all of the DHR records are extracted, but the stakeholders have the option to limit the extract to a

subset of data, if appropriate for the purpose at hand. If, for example, FMCSA wants to check the SORřs progress in

correcting errors found in a previous validation and verification review, it may only request a subset of data to be

extracted to compare results against earlier performance.

CD32.3 Extract DHR Data (State of Record (SOR))

According to the schedule, the SOR creates an extract file composed of the appropriate DHR records and associated

control record. The SOR must use the file naming format provided by the CDLIS Central Site at the time the Data

Validation and Verification process was scheduled.

The extract file includes one and only one MPR DHR Validation Control (DQ) message, plus multiple records

reflective of driver data.

The MPR DHR Validation Control (DQ) message can be located anywhere within the extract file. The extract file will

be sorted at the Central Site before validation processing to ensure that the MPR DHR Validation Control (DQ)

message is processed first.

The MPR DHR Validation Control (DQ) message contains control information about the extract file and process to be

executed.

The MPR DHR Validation Control (DQ) message must contain the following information:

Message Locator (GMSLOC) initialized to spaces

Data Validation and Verification Type (GRCDDT) set to Ř2ř for DHR only

Jurisdiction Code-Licensing (DDLJUR) set to the Jurisdiction Code of the state extracting the data (the SOR)

Record ŘAs ofř Date (GRCAOD) set to the Ŗas ofŗ date of the extract

Record ŘAs ofř Time (GRCAOT) set to the Ŗas ofŗ time of the extract

Driver Count (DDVCNT) set to the total number of drivers extracted to the file

Extract Record Count (GRCCNT) set to the total number of records contained in the extract file, including the

control record

The MPR DHR Validation Control (DQ) message may additionally contain the following information:

SSN Start Range (DDVSS0) set to the lower bound of the agreed upon SSN range of the extracted driver

information, or left blank if all drivers are being extracted

SSN End Range (DDVSS9) set to the upper bound of the agreed upon SSN range of the extracted driver

information, or left blank if all drivers are being extracted

DLN Start Range (DDLNU0) set to the lower bound of the agreed upon Driver License Number range of the

extracted driver information, or left blank if all drivers are being extracted

DLN End Range (DDLNU9) set to the upper bound of the agreed upon Driver License Number range of the

extracted driver information, or left blank if all drivers are being extracted

If the SSN Range is used to qualify the data to be extracted, then the DLN Range cannot also be specified. Likewise, if

the DLN Range is used to qualify the data to be extracted, then the SSN Range cannot also be specified.

The driver data is provided in AMIE format, where a given driverřs information is represented by one record per

message type as follows:





Table 2: Driver Data Records in the SOR Extract File

Message Type Description Occurrences

HD Driver History 1/DLN

H2 Permit Information 0-1/DLN

H3 Convictions 0-1/DLN

H4 Accidents 0-1/DLN

H5 Withdrawals 0-1/DLN

H7 Withdrawal Conviction Linkages 0-1/DLN

The format of each of the above record types is shown in "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE

TYPE".

Note: The UNI Source Code in "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE" classifies many data

elements as ŘOř for ŖApplication optionalŗ, which may be misleading regarding a specific application like CDLIS.

When a message is used in multiple processes or applications, a data element may be required (if present on the DHR)

in one process or application (e.g., CDLIS) but not required in another. Since each message type is only listed once in

the appendix (regardless of the number of processes in which it is used), data elements that are required in one process

but not in another are assigned a source code of 'Oř (optional). Additionally, data elements that are required when

available are also assigned a UNI source code of ŘOř (optional). For example: In "APPENDIX A Ŕ DATA

ELEMENTS BY MESSAGE TYPE", AAMVA lists AKA data; 10-year history check results; the TSA threat

determination and associated HME expiration date, and accidents in the history as "optional" The CDLIS specifications

indicate that jurisdictions must send all available information for these data elements. Therefore, jurisdictions are

required to maintain the information and transmit them on the extract. In other words, all the information on a DHR

must be sent in the extract file.

For all message types listed above, the Message Locator (GMSLOC) must be populated with the appropriate driverřs

Driver License Number. This will be used by the CDLIS Central Site to sort the extract file prior to processing.

To illustrate the rules for building the extract file, the following example lists the records of the extract file for the

following control message:

Table 3: Example Control Message Values

Element Name Value

Data Validation and Verification Type 2

Jurisdiction Code-Licensing VA

ŘAs ofř Date/Time 20080731130000

Driver Count 0000003

Extract Record Count 00000009

SSN Start Range

SSN End Range

DLN Start Range 0000000000000001000045301

DLN End Range 0000000000000001000045303

The SOR extract, as of July 31, 2008 at 1 p.m., includes three drivers, with state license numbers VA1000045301,

VA1000045302, and VA1000045303. If Driver VA1000045301 has one permit; Driver VA1000045302 has 3

convictions, one withdrawal and one linkage; and Driver VA1000045303 has two accidents, the records in the extract





file in this example are as follows:


H2 record (for driver VA1000045301)







DQ control record

The SOR may want to consider using the UNI Outbound Batch to Batch process to simplify the creation of the extract

file. The AAMVA Operations Help Desk should be contacted for additional information.

CD32.4 Transmit Extract File to Central Site (State of Record (SOR))

The SOR transmits the extract file, per predefined schedule, to the CDLIS Central Site using one of the following

mechanisms:

TCP/IP transfer protocols and Secure Shell File Transfer Protocol (sftp),

ftp with Secure Sockets Layer / Transport Layer Security (ftps) via AAMVAnet, or

via encrypted physical media by secure means

If the SORřs extract file is too large to send via ftp, the SOR divides the extract file into multiple smaller files and

transmits each via sftp or ftps or sends it on encrypted physical media by secure means.

CD32.5 Extract MPR Data (CDLIS Central Site)

Not applicable.

CD32.6 Preprocess SOR Extract File (CDLIS Central Site)

CD32.6.1 Check SOR Extract File Control Data

The CDLIS Central Site receives and preprocesses the SOR Extract File to ensure that there are no obvious errors

inherent in the extracted file. Specific preprocessor validations include the following:

One and only one control message exists.

All required information is provided on the control message.

All provided control information is in valid format and valid values.

Driver Count is consistent with the number of drivers provided in the extract file.

Extract Record Count is consistent with the number of records provided in the extract file, inclusive of the

control record.

SSN Start and End Range, if provided, is consistent with the contents of the extract file.

DLN Start and End Range, if provided, is consistent with the contents of the extract file.

Jurisdiction Code provided on the control record is consistent with the contents of the extract file.

CD32.6.2 Notify SOR of Control Data Check Results

If errors are detected in the preprocessor step that preclude further processing of the extract file, the CDLIS Central Site

notifies the SOR of the errors and works with the SOR to determine what specific steps to take to resolve the errors.





CD32.7 Resolve Issues and Re-drive process (State of Record (SOR))

The SOR determines the source of the error(s) and either corrects the problem(s) at the SOR before resubmitting the

SOR Extract File for processing, or works with the CDLIS Central Site to correct the problem(s) to the file already at


CD32.8 Validate and Verify SOR Extract Data and MPR data (CDLIS Central Site)

CD32.8.1 Check for mismatches between the SOR Extract Data and associated MPR data

Not applicable.

CD32.8.2 Verify SOR Extract Data

The CDLIS Central Site validates and verifies the DHR data.

In general, the checks are as follows:

Missing required data (e.g., missing Conviction ACD Code for a DHR conviction)

Invalid data (e.g., invalid Conviction ACD Code for a DHR conviction)

Anomalous data (a driverřs license issue date of 19200101)

See "<<insert link to cd32.supplement.a here>>

for a complete list of validation and verification checks that the CDLIS Central Site performs.

Note that it is anticipated that the requirements for specific validation and verification checks will change over time.

Currently identified checks may at some point no longer be necessary to perform and additional checks that are not

currently defined will need to be added. Providing for this kind of flexibility is crucial to the successful implementation

of this process.

CD32.9 Generate and Distribute Results (CDLIS Central Site)

After compiling the results of the validations, the CDLIS Central Site makes available the following process results:

Table 4: CD32 DHR Data Validation and Verification Reports

Report Recipient

1 Detailed Results: A detailed results file that contains all the errors and anomalies found

for each driverřs license number from the SOR Extract File.

SOR

2 SOR Summary Results: A summary results file that contains the failure rate for the

given SOR, by edit number within Federal Motor Carrier Safety Regulation (FMCSR).

No personally identifiable information is conveyed in this report.

FMCSA and SOR

3 Summary Comparison Results: A summary results file that contains the comparative

failure rate within Federal Motor Carrier Safety Regulation (FMCSR) of all jurisdictions

that have executed this process. No personally identifiable information is conveyed in

this report.

FMCSA

4 FMCSA Overview Compliance Report: A summary results file that contains a summary

of the number of licenses not compliant with existing FMCSRs. No personally

identifiable information is conveyed in this report.

FMCSA

These reports are formatted as variable length records that can be loaded into a spreadsheet, like Excel. The recipient

can then sort and summarize the data on any column or group of columns, as desired. These reports are explained

further in the following sections.





CD32.9.1 Create Detailed Results File

As the CDLIS Central Site checks the data, it creates a detailed results file containing all the errors and anomalies that

are identified for each driver record during the process. The detailed results file is provided to the SOR.

The file consists of variable length, delimited records, with one record for each error. Each record on the file contains

the following information:

ST/DLN, to identify the driver and enable the SOR to correct the DHR

Error/Exception Number

Descriptive Error Message

Error Category

Applicable FMCSR number, if known

Edit Number (unique identifier) within the FMCSR

Input file containing the error (DHR)

Data Element name corresponding with the element in error (6 character unique identifier as defined in the Data

Dictionary),

Data Element Descriptive name corresponding with the element in error

Additional information, as needed, to enable the SOR to identify which occurrence within the same driver record

contains the error (for example, the error occurs in the second conviction of three convictions of the identified

driver).

Specific value of the offending data element.

CD32.9.2 Create SOR Summary Results File

The SOR Summary Results File - Summary report - Failure Rate by Edit Number within FMCSR - contains a summary

of all the errors found in the SORřs data extract, shown by edit number within FMCSR.

For each edit number within FMCSR, in addition to the number of related errors found, the report also shows the

number of times the Central Site was able to execute the check (i.e., the number of times an error was found plus the

number of times no error was found).

The file also includes the percent failure rate for each edit, calculated as the ratio of the number of errors divided by the

total number of checks executed.

CD32.9.3 Create Summary Report of All SORs

The Summary Comparison Results File - Summary Report - Failure Rate by FMCSR - is an executive level report

showing a summary of all jurisdictions that have submitted an extract file to this process. This report is similar to the

ŖSummary Report - Failure Rate by Edit Number within FMCSR”, except that failure rates for each jurisdiction are

shown by FMCSR rather than by edit number.

The report shows the following:

Jurisdiction Name

Number of errors found

Total number of times that any edits related to that FMCSR were executed

Failure rate for that FMCSR (calculated as the total number of errors found as a percentage of the total number

of times the related edits were executed)

CD32.9.4 Create FMCSA Overview Compliance Report

The FMCSA Overview Compliance Report - FMCSA Overview Compliance Report – Number of Licenses not

Compliant with FMCSRs - includes the following information for each jurisdiction that has submitted an extract to this

process:

Jurisdiction Name





Extract Date

Number of Drivers extracted from the SOR

Number of Drivers with FMCSR findings

Percentage of Drivers with FMCSR findings

CD32.9.5 Distribute Reports

The CDLIS Central Site makes the results of the process available to the SOR and FMCSA, as appropriate. The CDLIS

Central Site must format the detailed error report to enable the SOR either to print out the results as a text file or to

import the information easily into an EXCEL spreadsheet or other database at the SOR.

The CDLIS Central Site archives the summary report for 18 months.

CD32.10 Determine Plan for Resolving Data Validation and Verification Issues (State of Record (SOR), FMCSA)

CD32.10.1 Determine priority of corrections

When the SOR receives the detailed and summary reports from CDLIS Central Site, it must analyze the mismatches,

errors, and anomalies reported in the file. It then coordinates with FMCSA to establish a priority for correcting the

various types of mismatches, errors, and anomalies.

CD32.10.2 Generate Plan

The SOR must develop a detailed action plan to ensure that mismatches, errors and anomalies are corrected according to

the priority set by FMCSA. The plan must include a specific time-line for correcting the errors. FMCSA must approve

the plan.

CD32.11 Resolve Data Validation and Verification Issues (State of Record (SOR), CDLIS Central Site)

The SOR corrects the DHR mismatches, errors, and anomalies according to the plan approved by FMCSA. The SOR

and the CDLIS Central Site coordinate the scheduling of any Add driver, Delete Driver, Update Data, and Update AKA

Data Transactions to correct errors, and anomalies.




CD32.SUPPLEMENT.A DHR DATA VALIDATION AND VERIFICATION CHECKS

CD32.A.1 Introduction

This supplement contains the checks that the CDLIS Central Site performs in the CD32 DHR Data Validation and

Verification Process.

The checks are listed in different tables in order by type of data checked (e.g., license data). Each table is subdivided by

the exception category of the check (e.g., missing required data).

LEGEND

384 Ŕ The value in this column is the subsection of the FMCSR, Title 49 Part 384, which relates to the data validation.

Thus, the value in the first row of Table 1 (Ŗ207ŗ) relates the data validation to Title 49 Code of Federal Regulations

Part 384.207.

Code Ŕ The Data Check ID Code in the format N-N.NN that uniquely identifies the data check. The code is a

concatenation of three fields: the first field, to the left of the dash, indicates the category of data (for example, Ŗlicense

dataŗ), the second field between the dash and the decimal indicates the kind of exception (for example, Ŗmissing

required dataŗ), and the third field, to the right of the decimal, is an arbitrary number that makes the code unique .

Thus, the ID Code 1-1.01 in the first row of Table 1 identifies the check for a broken pointer.

The first field has values ranging from 1-7, with the following meanings.

1. MPR dataŕdata on the MPR and on the DHR (i.e. driver demographic data on the HD record)

2. License dataŕdriverřs license detail data, such as ŖCDL statusŗ (on the HD record)

3. Permit dataŕdriverřs permit data, if any, such as ŖPermit Statusŗ (mostly on the H2 record)

4. Conviction dataŕdata describing a driverřs convictions, if any, such as the citation date (mostly on the H3

record)

5. Accident dataŕdata describing a driverřs accidents, such as the accident date (mostly on the H4 record)

6. Withdrawal dataŕdata describing a driverřs withdrawals, if any, such as the withdrawal effective date (mostly

on the H5 record)

7. Linkage dataŕdata linking a withdrawal to the convictions that resulted in the withdrawal, if any (mostly on

the H7 record)

The second field has values ranging from 1-7, with the following meanings.

8. Broken pointerŕa CDLIS CS DLN on the MPR has no matching DLN on the SOR extract file.

9. Missing pointerŕa DLN on the SOR extract file has no matching DLN on the CDLIS CS MPR.

10. Unmatched MPR Ŕ DHR dataŕa specific data value in the SORřs DHR is different from its corresponding

data value on the MPR at the Central Site.

11. Missing required dataŕa specific required data element value is blank (e.g., a commercial driverřs license

status is blank).

12. Invalid dataŕa specific data element value is not correct according to the domain or formatting rules in

ŖAPPENDIX D - DATA DICTIONARYŗ and the CDLIS specifications (e.g., a driver weight of ŖAAAŗ)

13. Anomalous dataŕa specific data element value is valid but is probably incorrect (e.g., a driver weight of 900

pounds)

14. Inconsistent dataŕOne piece of SOR data contains a value that is inconsistent with another related piece of

SOR data (e.g., ŖAKA name countŗ does not match actual number of AKA names)

Data Check Ŕ Brief explanation of the data validation and verification rule.

Exception Message Ŕ Text string explaining error or warning that appears in the detailed exception report.

CD32.A.2 MPR DHR Matching and Validation

If the Data Validation and Verification Type is Ř1ř Ŕ MPR only or Ř3ř Ŕ both MPR and DHR data, then the CDLIS

Central Site performs the checks contained in CD31.A.2.




CD31.A.2.1 Table A.1: Driver Demographic Data


384. Code Data Check Exception Message

Exception Category Code 1. Broken-Pointer Check

207 1-1.01 Each Driver License Jurisdiction Number (DDLJDL) on the CS

extract file must exactly match a Driver License Jurisdiction Number

(DDLJDL) of the SOR extract file

MPR ST/DLN NOT FOUND

ON SOR EXTRACT FILE

Exception Category Code 2. Missing-Pointer Check

207 1-2.01

Each DHR Driver License Jurisdiction Number (DDLJDL) on the HD

record of the SOR extract file must exactly match a Driver License

Jurisdiction Number (DDLJDL) on the Central Site extract file, unless

the SOR Extract Date is more than 10 days later than the

corresponding, valid Driver License Issue Date (DDLISS)

DHR ST/DLN NOT FOUND

ON CS EXTRACT FILE

Exception Category Code 3. Mismatched MPR-DHR Data ChecksŕFor each matching MPR Ŕ DHR Driver

License Jurisdiction Number (DDLJDL) pair

207 1-3.04 The MPR Person Name Group (BPENGP) must exactly match the

corresponding DHR Person Name Group (BPENGP)

DHR DATA

INCONSISTENT WITH

MPR DATA Ŕ DRIVER

NAME

207 1-3.08 The MPR Person Date of Birth (BPEDOB) must exactly match the

corresponding DHR Driver Date of Birth (DDVDOB)

DHR DATA

INCONSISTENT WITH

MPR DATA Ŕ DOB

207 1-3.12 The MPR Person SSN Last 5 Digits (BPESSD) must exactly match the

last five digits of the corresponding DHR Driver SSN Ŕ CDLIS

(DDVSS6)

DHR DATA

INCONSISTENT WITH

MPR DATA Ŕ SSN

Exception Category Code 4. Missing Required-Data ChecksŕFor each driver on the MPR and each driver on

the DHR

204 1-4.01 The Jurisdiction Code (DDLJU1) in the Driver License Jurisdiction

Number (DDLJDL) must be present

STATE CODE REQUIRED

204 1-4.02 The Driver License Number (DDLNUM), in the Jurisdiction Driver

License Number (DDLJDL), must be present

DLN REQUIRED

204 1-4.04 The Driver Sex (DDVSEX) must be present on the DHR SEX CODE REQUIRED

204 1-4.08 At least one component field of Person Name Group (BPENGP) must

be present

NAME REQUIRED

204 1-4.12 The Driver SSN - CDLIS (DDVSS6) must be present on the DHR

The Person SSN Last 5 Digits (BPESSD) must be present on the MPR

SSN REQUIRED

204 1-4.16 The Driver Date of Birth (DDVDOB) must be present on the DHR

The Person Date of Birth (BPEDOB) must be present on the MPR

DOB REQUIRED

Exception Category Code 5. Invalid-Data ChecksŕFor each driver on the MPR and each driver on the DHR,

when the fields exist

204 1-5.01 The Jurisdiction Code (DDLJU1), in the Driver License Jurisdiction

Number (DDLJDL), must be in list of U.S. jurisdiction codes in the

BJUCDE domain as specified in "APPENDIX D.1 - DATA

ELEMENTS"

INVALID STATE CODE






204 1-5.04 The Driver Sex (DDVSEX) must be one of the codes listed in

"APPENDIX D.1 - DATA ELEMENTS".

INVALID SEX CODE

204 1-5.08 The Person Name Group (BPENGP) must conform to the

requirements listed in "APPENDIX E.3 - AAMVA PERSON NAME

STANDARD (2008) VALIDATIONS"

See "APPENDIX E.3 -

AAMVA PERSON NAME

STANDARD (2008)

VALIDATIONS" for

specific error text associated

with this error.

204 1-5.12 The Driver Date of Birth (DDVDOB) must be valid as specified in

"APPENDIX D.1 - DATA ELEMENTS" and in "2.2.2 Dates"

INVALID DOB

204 1-5.16 The Driver SSN - CDLIS (DDVSS6) must be numeric, positions 1 Ŕ 3

must be between Ř000ř and Ř999ř inclusive, positions 4 Ŕ 5 must be

between Ř01ř and Ř99ř inclusive, and positions 6 Ŕ 9 must be between

Ř0001ř and Ř9999ř inclusive.

INVALID SSN

204 1-5.20 The Driver Height (DDVHGT) must be numeric characters and the

inches portion must be in range Ř00ř through Ř11ř

INVALID HEIGHT

1-5.24 The Driver Weight (DDVWGT) must be numeric characters INVALID WEIGHT

1-5.28 Driver Eye Color (DDVEYE) must be one of the codes listed in

"APPENDIX D.1 - DATA ELEMENTS"

INVALID EYE COLOR

Exception Category Code 7. Inconsistent-Data Cross-ChecksŕFor each driver on the MPR and each driver on

the DHR

204 1-7.01 Driver Sex (DDVSEX) Code = Ř0ř or Ř9ř and Driver SSN Ŕ CDLIS

(DDVSS6) not Ř999999999ř on the DHR

SEX NOT DETERMINED

AND SSN NOT 999999999

204 1-7.02 Driver Date of Birth (DDVDOB) must be present if SSN is not

Ř999999999ř on the DHR

DOB BLANK AND SSN

NOT 999999999

204 1-7.04 Driver Height (DDVHGT) must be present if SSN is not Ř999999999ř

on the DHR

HEIGHT BLANK AND SSN

NOT 999999999

Note: Any data value Ŗon the SOR extractŗ referenced in this table A.1 (where the Data Check ID code begins with Ř1ř)

is sent on the HD record of the SOR extract, unless otherwise noted.

CD32.A.3 Additional DHR Data Quality Validation

CD32.A.3.1 Table A.2: Driver License Details

Table A.2: Validations that pertain to Driver License Details


Exception Category Code 4. Missing Required-Data Checks

2-4.01 The Driver License Number of Permits (DDLNMP) must be present. NUMBER OF PERMITS

REQUIRED

204 2-4.02 The Driver License Commercial Class Code (DDLCL2) must be

present.

COMMERCIAL CLASS

REQUIRED

2-4.04 The Driver License Non-Commercial Class Code (DDLCL3) must be

present.

NON-COMMERCIAL

CLASS REQUIRED






204 2-4.08 The Driver License Issue Date (DDLISS) must be present. ISSUE DATE REQUIRED

204 2-4.12 The Driver License Expiration Date (DDLEXP) must be present. EXPIRATION DATE

REQUIRED

2-4.16 The Driver License Non-Commercial Status (DDLNTS) must be

present.

NON-COMMERCIAL

STATUS REQUIRED

204 2-4.20 The Driver License Commercial Status (DDLCTS) must be present. COMMERCIAL STATUS

REQUIRED

204 2-4.24 The Driver License Privilege Type W/D Action Pending (DDLWDP)

must be present.

WITHDRAWAL

PENDING FLAG

REQUIRED

2-4.28 The Number of Driver License Restrictions (DDLNMR) must be

present.

NUMBER OF

RESTRICTIONS

REQUIRED

2-4.32 The Driver Medical History Indicator (DDVMED) must be present. MEDICAL INDICATOR

REQUIRED

225 2-4.36 Total Convictions Sent (DDTTCS) must be present. NUMBER OF

CONVICTIONS SENT

REQUIRED

225 2-4.40 The Total Convictions on Record (DDTTCR) must be present. NUMBER OF

CONVICTIONS ON

RECORD REQUIRED

2-4.44 The Total Accidents Sent (DDTTAS) must be present. NUMBER OF

ACCIDENTS SENT

REQUIRED

2-4.48

The Total Accidents on Record (DDTTAR) must be present. NUMBER OF

ACCIDENTS ON

RECORD REQUIRED

225 2-4.52 The Total Withdrawals Sent (DDTTWS) must be present. NUMBER OF

WITHDRAWALS SENT

REQUIRED

225 2-4.56 The Total Withdrawals on Record (DDTTWR) must be present. NUMBER OF

WITHDRAWALS ON

RECORD REQUIRED

225 2-4.60 The Total Withdrawal-Conviction Links Sent (DDTTLS) must be

present.

NUMBER OF LINKAGES

SENT REQUIRED

225 2-4.64 Total Withdrawal-Conviction Links on Record (DDTTLR) must be

present

NUMBER OF LINKAGES

ON RECORD REQUIRED

204 2-4.68 Driver Mailing Address (DDVADD) must be present MAILING ADDRESS

REQUIRED

Exception Category Code 5. Invalid-Data Checks

2-5.01 The Driver License Number of Permits (DDLNMP) must be numeric,

and as specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID NUMBER OF

PERMITS






204 2-5.02 The Driver License Commercial Class Code (DDLCL2) must be in the

domain specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID COMMERCIAL

CLASS

2-5.04 The Driver License Non-Commercial Class Code (DDLCL3) must be

in the domain specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID NON-

COMMERCIAL CLASS

204 2-5.08 The Driver License Issue Date (DDLISS) must be a valid date, as

specified in "APPENDIX D.1 - DATA ELEMENTS" and in "2.2.2

Datesŗ

INVALID ISSUE DATE

204 2-5.12 The Driver License Expiration Date (DDLEXP) must be a valid date,

as specified in "APPENDIX D.1 - DATA ELEMENTS" and in "2.2.2

Datesŗ

INVALID EXPIRATION

DATE

2-5.16 The Driver License Non-Commercial Status (DDLNTS) must be in the


INVALID NON-

COMMERCIAL STATUS

204 2-5.20 The Driver License Commercial Status (DDLCTS) must be in the


INVALID COMMERCIAL

STATUS

204 2-5.24 The Driver License Privilege Type W/D Action Pending (DDLWDP)

must be in the domain specified in "APPENDIX D.1 - DATA

ELEMENTS"

INVALID

WITHDRAWAL

PENDING FLAG

204 2-5.28 The Number of Driver License Restrictions (DDLNMR) must be

numeric, and as specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID NUMBER OF

RESTRICTIONS

225 2-5.32 The Driver Medical History Indicator (DDVMED) must be in the


INVALID MEDICAL

INDICATOR

225 2-5.36 The Total Convictions Sent (DDTTCS) must be numeric. INVALID NUMBER OF

CONVICTIONS SENT

225 2-5.40 The Total Convictions on Record (DDTTCR) must be numeric. INVALID NUMBER OF

CONVICTIONS ON

RECORD

225 2-5.42 The Total Accidents Sent (DDTTAS) must be numeric. INVALID NUMBER OF

ACCIDENTS SENT

225 2-5.44 The Total Accidents on Record (DDTTAR) must be numeric. INVALID NUMBER OF

ACCIDENTS ON

RECORD

225 2-5.46 The Total Withdrawals Sent (DDTTWS) must be numeric. INVALID NUMBER OF

WITHDRAWALS SENT

225 2-5.48 The Total Withdrawals on Record (DDTTWR) must be numeric. INVALID NUMBER OF

WITHDRAWALS ON

RECORD

225 2-5.50 The Total Withdrawal-Conviction Links Sent (DDTTLS) must be

numeric.

INVALID NUMBER OF

LINKAGES SENT

225 2-5.52 The Total Withdrawal-Conviction Links on Record (DDTTLR) must

be numeric.

INVALID NUMBER OF

LINKAGES ON RECORD

204 2-5.56 The Driver Mailing Address (DDVADD) must be valid as specified in


INVALID MAILING

ADDRESS






204 2-5.60 The Driver License Endorsement Code (DDLEND), if present, must be

valid as specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID

ENDORSEMENT

2-5.64 The Driver Residence Address (DDVRAD), if present, must be valid as

specified in "APPENDIX D.1 - DATA ELEMENTS".

INVALID RESIDENCE

ADDRESS

206 2-5.68 The Driver License History Check Inquiring Jurisdiction (DDLHCI), if

present, must conform to the "United States" list in "APPENDIX D.1 -

DATA ELEMENTS"

INVALID HISTORY

CHECK JURISDICTION

206 2-5.72 The Driver License History Check Date (DDLHCD), if present, must

be a valid date, as specified in "APPENDIX D.1 - DATA

ELEMENTS" and in "2.2.2 Datesŗ

INVALID HISTORY

CHECK DATE

206 2-5.76 The Driver License History Check Response Total (DDLHCT), if

present, must be a numeric value

INVALID HISTORY

CHECK RESPONSES

TOTAL

206 2-5.80 Each occurrence of the Driver License History Check Responding State

embedded in the Driver License History Check Responding States List

(DDLHCL) must conform to the "United States" list in "APPENDIX


INVALID HISTORY

CHECK RESPONDENT

206 2-5.84 The Driver License History Check Requested States Total (DDLHCR),

if present, must be a numeric value

INVALID HISTORY

CHECK REQUESTS

TOTAL

233 2-5.88 The Driver TSA HME Threat Determination (DTHTSD), if present,

must be as specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID TSA HME

THREAT

DETERMINATION

233 2-5.92 The Driver License HAZMAT Endorsement Exp Date (DDLHED), if

present, must be a valid date, as specified in "APPENDIX D.1 -

DATA ELEMENTS" and in "2.2.2 Datesŗ

INVALID HAZMAT

EXPIRATION DATE

204 2-5.96 Each occurrence of the Driver License Restriction Code (DDLRSC), if

present, must be in the domain specified in "APPENDIX D.1 - DATA

ELEMENTS"

INVALID RESTRICTION

204 2-5.98 Each occurrence of the Driver License Restriction End Date

(DDLRSD), if present, must be a valid date, as specified in

"APPENDIX D.1 - DATA ELEMENTS" and in "2.2.2 Datesŗ

INVALID RESTRICTION

END DATE

Exception Category Code 6. Anomalous-Data Checks

2-6.01 The Number of Driver License Restrictions (DDLNMP) should be less

than 21

# OF Driver License

RESTRICTIONS > 20

2-6.02 The Driver License Issue Date (DDLISS) should not be before 1-1-

1960

ANOMALOUS ISSUE

DATE

2-6.04 The Driver License Expiration Date (DDLEXP) should not be before 1-

1-1970

ANOMALOUS

EXPIRATION DATE

2-6.08 The Total Convictions Sent (DDTTCS) must be less than Ř51ř # OF CONVICTIONS

SENT > 50

2-6.12 The Total Accidents Sent (DDTTAS) must be less than Ř51ř # OF ACCIDENTS SENT

> 50






2-6.16 The Total Withdrawals Sent (DDTTWS) must be less than Ř51ř # OF WITHDRAWALS

SENT > 50

2-6.20 The Total Withdrawal-Conviction Links Sent (DDTTLS) must be less

than Ř51ř

# OF LINKAGES SENT >

50

2-6.24 Driver License History Check Response Total (DDLHCT) must be in

the range 01-51

ANOMALOUS HISTORY

CHECK RESPONSES

TOTAL

2-6.28 The Driver License History Check Request Total (DDLHCR) must be

in the range 01-51

ANOMALOUS HISTORY

CHECK REQUESTS

TOTAL

Exception Category Code 7. Inconsistent-Data Cross-Checks

2-7.01 The number of permits transmitted in the SOR extract file for the driver

must match the Driver License Number of Permits (DDLNMP)

INCORRECT NUMBER

OF PERMITS

2-7.02 The Driver License Issue Date (DDLISS) must be on or before the


INCONSISTENT ISSUE,

EXPIRATION DATES

2-7.04 If the Driver License Withdrawal Effective Date (DWDDWD) is later

than the SOR extract date, the Driver License Privilege Type W/D

Action Pending (DDLWDP) must be Ř1ř

FUTURE WITHDRWL

BUT NO WITHDRWL

PENDING FLAG

2-7.08 The number of Driver License Restriction Codes (DDLRSC) of the

SOR extract must match the Number of Driver License Restrictions

(DDLNMR)

INCORRECT NUMBER

OF RESTRICTIONS

225 2-7.10 The number of convictions transmitted in the H3 message of the SOR

extract file on the driver must match the Total Convictions Sent

(DDTTCS) of the SOR extract

INCORRECT NUMBER

OF CONVICTIONS

225 2-7.12 The number of accidents transmitted in the H4 message of the SOR

extract file on the driver must match the Total Accidents Sent

(DDTTAS)

INCORRECT NUMBER

OF ACCIDENTS

225 2-7.14 The number of withdrawals transmitted in the H5 message of the SOR

extract file on the driver must match the Total Withdrawals Sent

(DDTTWS)

INCORRECT NUMBER

OF WITHDRAWALS

225 2-7.16 The number of conviction-withdrawal linkages transmitted in the H7

message of the SOR extract file on the driver must match the Total

Withdrawal-Conviction Links Sent (DDTTLS)

INCORRECT NUMBER

OF LINKAGES

233 2-7.20 If the Driver TSA HME Threat Determination () is Ř1ř or Ř2ř, no Driver

License Endorsement Code () can be ŘHř or ŘXř

THREAT

DETERMINATION

INCONSISTENT WITH

ENDORSEMENT

233 2-7.24 If the Driver TSA HME Threat Determination (DTHTSD) is Ř1ř or Ř2ř,

Driver License Hazmat Endorsement Exp Date (DDLHED) must be

earlier than the SOR extraction date or must be blank

THREAT

DETERMINATION

INCONSISTENT WITH

HAZMAT EXPIR DT

207 2-7.26 If the Message SOR Change In Progress Indicator (GMSSCH) is Ŗin

progressŗ on the MPR extract, the Driver License Issue Date (DDLISS)

must not be more than 10 days earlier than the extraction date

CSOR MORE THAN 10

DAYS AFTER

ISSUANCE






233 2-7.28 If the Driver License Commercial Status (DDLCTS) is ŖLICŗ, the

Driver License Hazmat Endorsement Exp Date (DDLHED) must not

be later than the License Expiration Date (DDLEXP).

INCONSISTENT

HAZMAT, CDL

EXPIRATION DATES

204 2-7.32 Each Driver License Restriction Code (DDLRSC) must have a

corresponding Driver License Restriction End Date (DDLRSD)

INCOMPLETE

RESTRICTION

INFORMATION

2-7.36 Each Driver License Restriction Code (DDLRSC) with a value of

either ŘIř (ŖRestricted Ŕ Otherŗ) or ŘJř (ŖOther) must have a

corresponding Driver License Restriction Explanation (DDLRSE)

NO EXPLANATION FOR

ŖOTHERŗ RESTRICTION

204 2-7.40 No Driver License Restriction Code (DDLRSC) with a value other than

ŘJř can have a corresponding Driver License Restriction Explanation

(DDLRSE)

EXPLANATION FOR

NON-ŖOTHERŗ

RESTRICTION

204 2-7.44 If the Driver License Non-Commercial Status (DDLNTS) is ŘRPDř, the

Driver License Commercial Status (DDLCTS) must be ŘRPDř

CDL STATUS

INCONSISTENT WITH

NON-CDL STATUS

204 2-7.48 If the Driver License Non-Commercial Status (DDLNTS) is ŘNOTř, the

Driver License Commercial Status (DDLCTS) must be ŘNOTř

CDL STATUS

INCONSISTENT WITH

NON-CDL STATUS

206 2-7.50 If all of the following are blank, the 10-year history check has not been

done: Driver License History Check Inquiring Jurisdiction (DDLHCI);

Driver License History Check Date (DDLHCD); Driver License

History Check Requested States Total (DDLHCR);Driver License

History Check Responding State (DDLHCJ); and Driver License

History Check Responding States Total (DDLHCT)

WARNING: 10-YEAR

HISTORY CHECK NOT

YET DONE

206 2-7.51 If one of the following is present then all must be present : Driver

License History Check Inquiring Jurisdiction (DDLHCI); Driver

License History Check Date (DDLHCD); Driver License History

Check Requested States Total (DDLHCR);Driver License History

Check Responding State (DDLHCJ); and Driver License History

Check Responding States Total (DDLHCT)

MISSING HISTORY

CHECK DATA

206 2-7.52 The Driver License History Check Requested States Total (DDLHCR)

must be equal to or greater than the Responding States Total

(DDLHCT)

HISTORY CHCK

REQUEST TOTAL NOT

EQAUL RESPONSE

TOTAL

233 2-7.54 If the Driver License Endorsement Code (DDLEND) is ŘHř or ŘXř and

if the Driver License Issue Date (DDLISS) is less than 1 year before

the SOR Extract Date, the Driver License HAZMAT Endorsement Exp

Date (DDLHED) must not be blank.

LIC ENDORSE, ISSUE

DT INCONSISTENT

WITH HAZMAT EXP DT

204 2-7.56 If the Driver License Commercial Status (DDLCTS) is

ŘLICř, the Driver SSN - CDLIS (DDVSS6) must not be

Ř999999999ř

INCONSISTENT CDL

STATUS, SSN

Note: Any data value Ŗon the SOR extractŗ referenced in (where the Data Check ID code begins with Ř2ř) is sent on

the HD record, unless otherwise noted.




CD32.A.3.2 Permits

Table A.3: Validations that pertain to Permits


Exception Category Code 4. Required-Data Checks

3-4.01 The Driver License Permit Classification Code (DDLPC2) must be

present

PERMIT CLASSIFICATION

CODE REQUIRED

3-4.04 The Driver License Permit Issue Date (DDLPID) must be present PERMIT ISSUE DATE

REQUIRED

3-4.08 The Driver License Permit Expiration Date (DDLPED) must be

present

PERMIT EXPIRATION

DATE REQUIRED

3-4.12 The Driver License Permit Status (DDLPST) must be present PERMIT STATUS CODE

REQUIRED

3-4.16 The Driver License Number of Permit Restrictions (DDLRPN) must

be present

NUMBER OF PERMIT

RESTRICTIONS REQUIRED


3-5.01 The Driver License Permit Classification Code (DDLPC2) must be in

the domain specified in Data Dictionary appendix

INVALID COMMERCIAL

DRIVER PERMIT CODE

INVALID

3-5.02 The Driver License Permit Issue Date (DDLPID) must be a valid

date, as specified in "APPENDIX D.1 - DATA ELEMENTS" and in

"2.2.2 Datesŗ

INVALID PERMIT ISSUE

DATE

3-5.04

The Driver License Permit Expiration Date (DDLPED) must be a

valid date, as specified in "APPENDIX D.1 - DATA ELEMENTS"

and in "2.2.2 Datesŗ

INVALID PERMIT

EXPIRATION DATE

3-5.08 The Driver License Permit Status (DDLPST) must be in the domain

specified in Data Dictionary appendix

INVALID PERMIT STATUS

3-5.08 The Driver License Number of Permit Restrictions (DDLRPN) must

be numeric

INVALID NUMBER OF

PERMIT RESTRICTIONS

3-5.12 The Driver License Permit Endorsement Group Code (DDLEP1)

must be in the domain specified in "APPENDIX D.1 - DATA

ELEMENTS"

INVALID PERMIT

ENDORSEMENT GROUP

CODE

3-5.16 The Driver License 1st Permit Restrict Code (DDLRP1) must be in

the domain specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID FIRST PERMIT

RESTRICTION CODE

3-5.20 Driver License 1st Permit Restrict End Date must be a valid date, as


Datesŗ

INVALID FIRST PERMIT

RESTRICT END DATE

3-5.24 Driver License 2nd Permit Restrict Code must be in the domain


INVALID SECOND PERMIT

RESTRICTION CODE

3-5.28 Driver License 2nd Permit Restrict End Date must be a valid date, as


Datesŗ

INVALID SECOND PERMIT

RESTRICT END DATE

3-5.32 Driver License 3rd Permit Restrict Code must be in the domain


INVALID THIRD PERMIT

RESTRICTION CODE




Table A.3: Validations that pertain to Permits


3-5.36 Driver License 3rd Permit Restrict End Date must be a valid date, as


Datesŗ

INVALID THIRD PERMIT

RESTRICT END DATE

Note: Any data value referenced in this table A.3 (where the Data Check ID code begins with Ř3ř) is sent on the H2

record of the SOR extract, unless otherwise noted.

CD32.A.3.3 Convictions

Table A.4: Validations that pertain to Convictions


Message


225 4-

4.01

Jurisdiction Code - Convicting (DCVJUR) must be present. CONVICTION

JURISDICTION

CODE

REQUIRED

225 4-

4.02

Citation Date (DCIDCI) must be present. CITATION

DATE

REQUIRED

225 4-

4.04

Conviction Date (DCVDCV) must be present. CONVICTION

DATE

REQUIRED

225 4-

4.08

Conviction Court Type (DCVCRT) must be present. CONVICTION

COUNT TYPE

REQUIRED

225 4-

4.12

If the Citation Date (DCIDCI) is on or after October 1, 2005, the Conviction

Commercial Vehicle Indicator (DCVCOM) must be present.

CONVICTION

COMMERCIAL

VEH INDIC

REQUIRED

225 4-

4.16


HAZMAT Indicator (DCVHAZ) must be present.

CONVICTION

HAZMAT

INDIC

REQUIRED

225 4-

4.20


Jurisdiction Court Report ID (DCVCLO) must be present.

CONVICTION

JURIS COURT

REPORT ID

REQUIRED

225 4-

4.24

State of Conviction Offense Code (DCVCOR) must be present. CONVICTION

JURIS

OFFENSE

CODE

REQUIRED

225 4-

4.28

Conviction Offense ACD Code (DCVCCA) must be present. CONVICTION

OFFENSE ACD

CODE

REQUIRED






Message

225 4-

4.32

If the Citation Date (DCIDCI) is on or after October 1, 2005, the Citation CDL

Holder Indicator (DCICHI) must be present.

CITATION CDL

HOLDER INDIC

REQUIRED


225 4-

5.01

Jurisdiction Code - Convicting (DCVJUR) must conform to the "United States",

ŖCanadaŗ, ŖMexicoŗ ('MX' only) or ŖUS Government Agenciesŗ (ŘFHř only) list in

the Data Dictionary or must be ŖFHŗ

INVALID

CONVICTING

JURISDICTION

CODE

225 4-

5.02

Citation Date (DCIDCI) must be a valid date as specified in "APPENDIX D.1 -

DATA ELEMENTS" and in "2.2.2 Datesŗ INVALID

CITATION

DATE

225 4-

5.04

Conviction Date (DCVDCV) must be a valid date as specified in "APPENDIX

D.1 - DATA ELEMENTS" and in "2.2.2 Datesŗ INVALID

CONVICTION

DATE

225 4-

5.08

The Conviction Court Type (DCVCRT) must be valid as specified in "APPENDIX


INVALID

CONVICTION

COURT TYPE

225 4-

5.12

The Conviction Commercial Vehicle Indicator (DCVCOM) must be valid as


INVALID

CONVICTION

COM VEHICLE

INDICATOR

225 4-

5.16

The Conviction HAZMAT Indicator (DCVHAZ) must be valid as specified in


INVALID

CONVICTION

HAZMAT

INDICATOR

225 4-

5.28

The Conviction Offense ACD Code (DCVCCA) must be valid as specified in the

current AAMVA Code Dictionary (ACD) Manual and must not be one of the

codes reserved for withdrawals: W00, W01, W30, W31, W40, W41, W45, W50,

W51, W52, W60, W61, W72, W80 and W81.

INVALID

CONVICTION

ACD CODE

225 4-

5.32

The Citation CDL Holder Indicator (DCICHI) must be valid as specified in


INVALID CDL

HOLDER

INDICATOR

Exception Category Code 7. Inconsistent-Data

225 4-

7.01

The Citation Date (DCIDCI) must be equal to or earlier than the Conviction Date

(DCVDCV).

CITATION

DATE MUST

NOT BE LATER

THAN CONV

DATE

225 4-

7.02

The Conviction Date (DCVDCV) must be equal to or earlier than the Message Date

(GMSDAT).

CONV DATE

MUST NOT BE

LATER THAN

SYSTEM DATE






Message

225 4-

7.03


Commercial Vehicle Indicator (DCVCOM) must be '1', Ř2ř, or Ř9ř.

CONV CMV

IND MUST = 1,

2, 9 FOR

CITATN DATE

> 20050930

225 4-

7.04

If the Citation Date (DCIDCI) is on or after January 1, 2008, the Conviction

Commercial Vehicle Indicator (DCVCOM) must be '1' or Ř2ř.

CONV CMV

IND MUST = 1

OR 2 FOR

CITATN DATE

> 20071231

225 4-

7.05


HAZMAT Indicator (DCVHAZ) must be '1', Ř2ř, or Ř9ř.

CONV HAZ

IND MUST = 1,

2, 9 FOR

CITATN DATE

> 20050930

225 4-

7.08

If the Citation Date (DCIDCI) is on or after January 1, 2008, the Conviction

HAZMAT Indicator (DCVHAZ) must be '1' or Ř2ř.

CONV HAZ IND

MUST = 1 OR 2

FOR CITATN

DATE >

20071231

225 4-

7.12

If the Citation Date (DCIDCI) is on or after January 1, 2008, the Citation CDL

Holder Indicator (DCICHI) must be '1' or Ř2ř.

CDL HLDR IND

MUST = 1 OR 2

FOR CITATN

DATE >

20071231

225 4-

7.16

If the value of the Conviction HAZMAT Indicator (DCVHAZ) is '1', the

Conviction Commercial Vehicle Indicator (DCVCOM) must be '1'.

CONV CMV

IND MUST = 1,

IF CONV

HAZMAT IND =

1

225 4-

7.20

If the Conviction Offense ACD Code (DCVCCA) value is one of the following

(ŘB19ř, ŘB27ř, ŘB56ř, ŘE03ř, ŘE04ř, ŘE06ř, ŘE33ř, ŘE36ř, ŘE53ř, ŘE56ř, ŘM22ř,

ŘU09ř, ŘU10ř), the Conviction Commercial Vehicle Indicator (DCVCOM) must be

'1'

CONV CMV

INDICATOR

MUST = 1 FOR

ACD CONV

CODE

225 4-

7.22


(ŘD45ř, ŘD53ř, ŘD56ř), the Conviction Commercial Vehicle Indicator (DCVCOM)

must be '2'

CONV CMV

INDICATOR

MUST = 2 FOR

ACD CONV

CODE

225 4-

7.24


(ŘE03ř, ŘE04ř, ŘE33ř, ŘE53ř), the Conviction HAZMAT Indicator (DCVHAZ) must

be "1"

CONV

HAZMAT IND

MUST = 1 FOR

ACD CONV

CODE






Message

225 4-

7.28

If the Citation Date (DCIDCI) is on or before December 31, 2007 and the

Conviction Offense ACD Code (DCVCCA) value is one of the following (ŘE06ř,

ŘE36ř, ŘE56ř), the Conviction HAZMAT Indicator (DCVHAZ) must be "2" or "9"

CONV

HAZMAT IND

MUST = 2 OR 9

FOR ACD

CONV CODE

225 4-

7.32

If the Citation Date (DCIDCI) is on or after January 1, 2008 and the Conviction

Offense ACD Code (DCVCCA) value is one of the following (ŘE06ř, ŘE36ř,

ŘE56ř), the Conviction HAZMAT Indicator (DCVHAZ) must be "2"

CONV

HAZMAT IND

MUST = 2 FOR

ACD CONV

CODE

225 4-

7.36


Offense ACD Code (DCVCCA) value is ŘD27ř, the CDL Holder Indicator

(DCICHI) must be Ř2ř.

CIT CDL

HOLDER IND

MUST = 2 FOR

ACD CONV

CODE

225 4-

7.40

If the Citation Date (DCIDCI) is after September 30, 2005 and the Conviction

Offense ACD Code (DCVCCA) is not in the group ('A11', 'D45', 'D53' or 'D56')

and is not in the range 'S01'-'S92', the Conviction Offense Detail - ACD

(DCVCDA) must have all blanks.

ACD CONV

CODE VALUE

REQUIRES

BLANK CONV

OFF DET

225 4-

7.44


Offense ACD Code (DCVCCA) is 'A11', the Conviction Offense Detail - ACD

(DCVCDA) must have numeric values in the range '01'-'99' in the first 2 positions

and all blanks or all zeroes in the remaining three positions.

INVALID

CONV OFF

DETAIL FOR

ACD CONV

CODE = A11

225 4-

7.48


Offense ACD Code (DCVCCA) is 'D45' or 'D53' or 'D56', the first three positions

of the Conviction Offense Detail - ACD (DCVCDA) must have a valid ACD

Conviction Code that must not be 'D45', 'D53', or 'D56'; and the remaining two

positions must have blanks.

INVALID

CONV OFF

DETAIL FOR

GIVEN ACD

CONV CODE

225 4-

7.52


Offense ACD Code (DCVCCA) is in the range 'S01'-'S91', the Conviction Offense

Detail - ACD (DCVCDA) must have one of the following two formatsř all blanks

or numeric values in the range '05'-'90' in the first 2 positions and all blanks or all

zeroes in the last 3 positions.

INVALID

CONV OFF DET

FOR ACD

CONV CODES

S01-S91

225 4-

7.54


Offense ACD Code (DCVCCA) is 'S92', the Conviction Offense Detail - ACD

(DCVCDA) must have a numeric value in the range '05'-'90' in the first two

positions and a numeric value in the last three positions that is less than '300' and

greater than the numeric value in the first two positions.

INVALID

CONV OFF

DETAIL FOR

ACD CONV

CODE = S92






Message

225 4-

7.56

No two convictions are allowed to match exactly on the six elements listed below.

DCVJUR - JURISDICTION CODE - CONVICTING

DCIDCI - CITATION DATE

DCVDCV - CONVICTION DATE

DCVCLO - CONVICTION JURIS COURT REPORT ID

DCVCOR - CONVICTION JURISDICTION OFFENSE CODE

DCVCCA - CONVICTION OFFENSE ACD CODE

DUPLICATE

CONVICTIONS

225 4-

7.58

A Conviction ID Code (DCVCID) must be unique for a given driverřs convictions;

a Conviction ID Code must not be repeated for any other conviction.

DUPLICATE

CONVICTION

IDS

225 4-

7.60

If the Conviction ACD Code (DCVCCA) is ŘM22ř, the CMV Indicator

(DCVCOM) must be Ř1ř (Yes)

CONV ACD

CODE

INCONSISTENT

WITH CMV IND

217 4-

7.62

If the Conviction Offense ACD Code (DCVCCA) is ŘA50ř, the Driver License

Commercial Status (DDLCTS) cannot be ŘLICř or ŘELGř.

INCONSISTENT

CONVICTION

ACD CODE,

CDL STATUS

209 4-

7.64

If the Driver License Commercial Class Code (DDLCL2) is blank, at least one

conviction must have the Conviction Commercial Vehicle Indicator (DCVCOM)

must = Ř1ř .

NO CMV

CONVICTIONS

FOR NON-CDL

HOLDER

215

222

224

4-

7.66

If the Citation Date (DCIDCI) is on or after November 1, 2005 and if the

Conviction Offense ACD Code (DCVCCA) is A08, A10, A12, A20, A21, A22,

A23, A50, A90, A98 B01, B02, B03, B04, B05, B06, B07, B08, U03, B19, B27,

D02, or W70 (a major violation), the Conviction ID Code (DCVCID) must equal at

least one Conviction ID Code in a Driver License Withdrawal Convictions Links

Group (DWDCLG) of the linkages for the driver

WITHDRAWAL

REQUIRED

FOR

CONVICTION

215

224

4-

7.68

66


Conviction Offense ACD Code (DCVCCA) is A11 and if the Conviction Offense

Detail - ACD (DCVCDA) is greater than Ř08ř, the Conviction ID Code (DCVCID)

must equal at least one Conviction ID Code in a Driver License Withdrawal

Convictions Links Group (DWDCLG) of the linkages for the driver

WITHDRAWAL

REQUIRED

FOR

CONVICTION

303

215

4-

7.70


Conviction Offense ACD Code (DCVCCA) is ŘA11ř and if the Conviction Offense

Detail - ACD (DCVCDA) is greater than Ř04ř and if the Conviction Commercial

Vehicle Indicator (DCVCOM) is Ř1ř, the Conviction ID Code (DCVCID) of the

conviction must equal at least one Conviction ID Code in a Driver License

Withdrawal Convictions Links Group (DWDCLG) of the linkages for the driver

WITHDRAWAL

REQUIRED

FOR

CONVICTION

203

215

223

4-

7.72


Conviction Offense ACD Code (DCVCCA) is A04, A94, M10, M20-M24, U07,

U08, U09, or U10 and if the Conviction Commercial Vehicle Indicator

(DCVCOM) is Ř1ř, the Conviction ID Code (DCVCID) of the conviction must

equal at least one Conviction ID Code in a Driver License Withdrawal Convictions

Links Group (DWDCLG) of the linkages for the driver

WITHDRAWAL

REQUIRED

FOR

CONVICTION






CD32.A.3.4 Accidents

Table A.5: Validations that pertain to Accidents



5-4.01 The Accident Jurisdiction Code (DACJUR) must be present ACCIDENT JURISDICTION CODE

REQUIRED

5-4.02 The Accident Date (DACDAT) must be present ACCIDENT DATE REQUIRED

5-4.04 The Accident Severity Code (DACSEV) must be present ACCIDENT SEVERTIY CODE

REQUIRED

5-4.08

The Driver Accident Commercial Vehicle Indicator

(DDACOM) must be present

DRIVER ACCIDENT

COMMERCIAL VEH IND

REQUIRED

5-4.12 The Driver Accident HAZMAT Indicator (DDAHAZ) must

be present

DRIVER ACCIDENT HAZMAT

IND REQUIRED

5-4.16 The Accident Locator Reference (DACLOC) must be

present

ACCIDENT LOCATOR

REFERENCE REQUIRED


5-5.01 The Accident Jurisdiction Code (DACJUR) must be valid as


ACCIDENT JURISDICTION CODE

INVALID

5-5.02 The Accident Date (DACDAT) must be valid as specified in

Data Dictionary appendix

DATE NOT IN FORMAT

CCYYMMDD

5-5.04 The Accident Severity Code (DACSEV) must be valid as


ACCIDENT SEVERITY CODE

INVALID

5-5.08 The Driver Accident Commercial Vehicle Indicator

(DDACOM) must be valid as specified in Data Dictionary

appendix

DRIVER ACCIDENT

COMMERICAL VEH IND INVALID

5-5.12 The Driver Accident HAZMAT Indicator (DDAHAZ) must

be valid as specified in Data Dictionary appendix

DRIVER ACCIDENT HAZMAT

IND INVALID

Exception Category Code 7 Data Cross-Checks

5-7.01 The Accident Date (DACDAT) must be equal to or earlier

than the Extraction Date.

ACCIDENT MUST NOT BE LATER

THAN MESSAGE DATE



CD32.A.3.5 Withdrawals

Table A.6: Validations that pertain to Withdrawals








225 6-4.01 The Jurisdiction Code - Withdrawing (DWDJUR) must be present JURISDICTION CODE -

WITHDRAWING

REQUIRED

225 6-4.02

The Driver License Withdrawal Effective Date (DWDDWD) must be

present

DRIVER LICENSE

WITHDRAWAL

EFFECTIVE DATE

REQUIRED

225 6-4.04 The Driver License Withdrawal Type (DWDWTP) must be present DRIVER LICENSE

WITHDRAWAL TYPE

REQUIRED

225 6-4.08 The Driver License Withdrawal Basis (DWDWBS) must be present DRIVER LICENSE

WITHDRAWAL BASIS

REQUIRED

225 6-4.12 The Driver License Withdrawal Due Process Status (DWDWPS) must

be present

DRIVER LICENSE

WITHDRAWAL DUE

PROCESS STATUS

REQUIRED

225 6-4.16 The Driver License ACD Withdrawal Reason Code (DWDWRS) must

be present

DRIVER LICENSE ACD

WITHDRAWAL

REASON CODE

REQUIRED

225 6-4.20 The Driver License Withdrawal Eligibility Date (DWDWDE) must be

present

DRIVER LICENSE

WITHDRAWAL

ELIGIBILITY DATE

REQUIRED

225 6-4.24 The Driver License Withdrawal Extent ID - DLC (DWDWEX) must be

present

DRIVER LICENSE

WITHDRAWAL EXTENT

ID - DLC REQUIRED

225 6-4.28 The Driver License Withdrawal Jurisdiction Report ID (DWDWLO)

must be present

DRIVER LICENSE

WITHDRAWAL JURIS

REPORT ID REQUIRED

225 6-4.32 The Driver License Withdrawal Reason Reference (DWDWRR) must

be present

DRIVER LICENSE ACD

WITHDRAWAL

REASON REF

REQUIRED


225 6-5.01 The Jurisdiction Code - Withdrawing (DWDJUR) must conform to the

"United States", ŖCanadaŗ, or ŖMexicoŗ ('MX' only), or ŖUS

Government Agenciesŗ (ŘFHř only) list in the data element BJUCDE

domain in "APPENDIX D.1 - DATA ELEMENTS".

INVALID STATE-OF-

WITHDRAWAL CODE

225 6-5.02 The Driver License Withdrawal Effective Date (DWDDWD) must be a

valid date as specified in "APPENDIX D.1 - DATA ELEMENTS"

and in "2.2.2 Datesŗ

INVALID

WITHDRAWAL

EFFECTIVE DATE

225 6-5.04 The Driver License Withdrawal Type (DWDWTP) must be valid as


INVALID

WITHDRAWAL TYPE






225 6-5.08 The Driver License Withdrawal Basis (DWDWBS) must be valid as


INVALID

WITHDRAWAL BASIS

225 6-5.12 The Driver License Withdrawal Due Process Status (DWDWPS) must

be valid as specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID

WITHDRAWAL

PROCESS STATUS

225 6-5.16 The Driver License ACD Withdrawal Reason Code (DWDWRS) must

be valid as specified in the current AAMVA Code Dictionary (ACD)

Manual

INVALID

WITHDRAWAL ACD

REASON CODE

225 6-5.20 The Driver License Withdrawal Eligibility Date (DWDWDE) must be

valid as specified in the Data Dictionary appendix, and, if the value is a

date, the date must be a valid date as specified in "APPENDIX D.1 -

DATA ELEMENTS" and in "2.2.2 Datesŗ

INVALID ELIGIBILITY

DATE

225 6-5.24 The Driver License Withdrawal Extent ID - DLC (DWDWEX) must be

valid as specified in "APPENDIX D.1 - DATA ELEMENTS"

INVALID

WITHDRAWAL EXTENT

ID

225 6-5.36 The Driver License Withdrawal Reinstatement Date (DWDWDR), if

present, must be a valid date as specified in "APPENDIX D.1 - DATA

ELEMENTS" and in "2.2.2 Datesŗ

INVALID

REINSTATEMENT

DATE


225 6-7.01 If the Driver License Withdrawal Eligibility Date (DWDWDE) is a

date, it must be equal to or later than the Driver License Withdrawal

Effective Date (DWDDWD).

ELIG DATE MUST BE

EQUAL TO OR LATER

THAN EFFEC DATE

225 6-7.02 The Driver License Withdrawal Reinstatement Date (DWDWDR), if

present, must be equal to or earlier than the Extract Date.

REINSTATE DATE

MUST NOT BE LATER

THAN EXTRACT DATE

225 6-7.04 No two withdrawals are allowed to match exactly on the six elements

listed below

DWDJUR - JURISDICTION CODE - WITHDRAWING

DWDWLO - Driver License WITHDRAWAL JURISDICTION

REPORT ID

DWDDWD - DRV LIC WITHDRAWAL EFFECTIVE DATE

DWDWTP - DRIVER LICENSE WITHDRAWAL TYPE

DWDWRS - DRV LIC ACD WITHDRAWAL REASON CODE

DWDWRR - DRV LIC WITHDRAWAL REASON REFERENCE

DUPLICATE

WITHDRAWALS

225 6-7.08 Driver License Withdrawal ID Code (DWDWID) must be unique; it

must not be repeated for any other withdrawal for the given driver

DUPLICATE

WITHDRAWAL IDS

210 6-7.10 If the Jurisdiction Code - Withdrawing (DWDJUR) equals the Driver

License Current Jurisdiction Code (DDLJU1) embedded in the Driver

License Jurisdiction Number (DDLJDL), Driver License Issue Date

(DDLISS) on the HD record must not fall within the period between

the Driver License Withdrawal Effective Date (DWDDWD) and the

Driver License Withdrawal Reinstatement Date (DWDWDR), if

present

WARNING: LICENSE

ISSUED WHILE DRIVER

WITHDRAWN






215 6-7.12 If the Driver License Withdrawal Effective Date (DWDDWD) is on or

after October 1, 1992 and if the Driver License ACD Withdrawal

Reason Code (DWDWRS) is one of the following: A08, A10, A12,

A20, A21, A22, A23, A90, or A98 (a major state-law alcohol or

controlled substance violation or refusal to test), the Driver License

Withdrawal Eligibility Date (DWDWDE) must be at least 1 year after

the Driver License Withdrawal Effective Date (DWDDWD)

WRONG PENALTY FOR

MAJOR-VIOLATION

WITHDRAWAL



Reason Code (DWDWRS) is A11 and if the Withdrawal ID Code

(DWDWID) is equal to a Driver License Withdrawal ID Conviction

Link (DWDWI2) on the H7 record and if a Conviction ID Code,

Linked to Withdrawal (DCVCI2) in the Driver License Withdrawal

Convictions Links Group (DWDCLG) linked to the Driver License

Withdrawal ID Conviction Link (DWDWI2) on the H7 record is equal

to Conviction ID Code (DCVCID) of a driver conviction on the H3

record where the associated Conviction Offense ACD Code

(DCVCCA) on the H3 record is ŘA11ř and the Conviction Offense

Detail - ACD (DCVCDA) on the H3 record is greater than Ř08ř (a

major state-law blood alcohol concentration violation (where

BAC>0.08)), then the Driver License Withdrawal Eligibility Date

(DWDWDE) must be at least 1 year after the Driver License


WRONG PENALTY FOR

MAJOR-VIOLATION

WITHDRAWAL



Reason Code (DWDWRS) is A11 and if the Withdrawal ID Code

(DWDWID) is equal to a Driver License Withdrawal ID Conviction

Link (DWDWI2) on the H7 record and if a Conviction ID Code,

Linked to Withdrawal (DCVCI2) in the Driver License Withdrawal

Convictions Links Group (DWDCLG) linked to the Driver License

Withdrawal ID Conviction Link (DWDWI2) on the H7 record is equal

to Conviction ID Code (DCVCID) of a driver conviction on the H3

record where the associated Conviction Offense ACD Code

(DCVCCA) on the H3 record is ŘA11ř and the Conviction Offense

Detail - ACD (DCVCDA) on the H3 record is greater than Ř04ř and less

than or equal to Ř08ř and the Conviction Commercial Vehicle Indicator

(DCVCOM) on the H3 record is Ř1ř (a major blood alcohol

concentration violation (where BAC>0.04-0.08)), then the Driver

License Withdrawal Eligibility Date (DWDWDE) must be at least 1

year after the Driver License Withdrawal Effective Date (DWDDWD)

WRONG PENALTY FOR

MAJOR-VIOLATION

WITHDRAWAL






203

215

6-7.24 If the Driver License Withdrawal Effective Date (DWDDWD) is on or


Reason Code (DWDWRS) is ŘA04ř or ŘA94ř and if the Withdrawal ID

Code (DWDWID) is equal to a Driver License Withdrawal ID

Conviction Link (DWDWI2) on the H7 record and if a Conviction ID

Code, Linked to Withdrawal (DCVCI2) in the Driver License

Withdrawal Convictions Links Group (DWDCLG) linked to the Driver

License Withdrawal ID Conviction Link (DWDWI2) on the H7 record

is equal to Conviction ID Code (DCVCID) of a driver conviction on

the H3 record where the associated Conviction Offense ACD Code

(DCVCCA) on the H3 record is equal to the Driver License ACD

Withdrawal Reason Code (DWDWRS) on the H7 record and the

Conviction Commercial Vehicle Indicator (DCVCOM) on the H3

record is Ř1ř (a major blood alcohol concentration violation in a CMV),

the Driver License Withdrawal Eligibility Date (DWDWDE) must be at

least 1 year after the Driver License Withdrawal Effective Date

(DWDDWD)

WRONG PENALTY FOR

MAJOR-VIOLATION

WITHDRAWAL



Reason Code (DWDWRS) is one of the following: B01, B02, B03,

B04, B05, B06, B07, B08, or U03 (a major violation of leaving the

scene of an accident or using a motor vehicle in the commission of a

felony, other than a felony involving manufacturing, distributing, or

dispensing a controlled substance), the Driver License Withdrawal

Eligibility Date (DWDWDE) must be at least 1 year after the Driver

License Withdrawal Effective Date (DWDDWD)

WRONG PENALTY FOR

MAJOR-VIOLATION

WITHDRAWAL


after November 1, 2005 and the Driver License ACD Withdrawal

Reason Code (DWDWRS) is one of the following: B20, B21, B22,

B23, B24, B25, B26, U07, U08, U09, or U10 and if the Withdrawal ID

Code (DWDWID) is equal to a Driver License Withdrawal ID

Conviction Link (DWDWI2) on the H7 record and if a Conviction ID

Code, Linked to Withdrawal (DCVCI2) in the Driver License

Withdrawal Convictions Links Group (DWDCLG) linked to the Driver

License Withdrawal ID Conviction Link (DWDWI2) on the H7 record

is equal to Conviction ID Code (DCVCID) of a driver conviction on

the H3 record where the associated Conviction Offense ACD Code

(DCVCCA) on the H3 record is equal to the Driver License ACD

Withdrawal Reason Code (DWDWRS) on the H5 record and the

Conviction Commercial Vehicle Indicator (DCVCOM) on the H3

record is Ř1ř (a major violation of (1) driving a commercial motor

vehicle when as a result of prior violations committed operating a

CMV, the driverřs CDL is revoked, suspended, or canceled, or the

driver is disqualified from operating a CMV or (2) causing a fatality

through the negligent operation of a commercial motor vehicle and the

vehicle was a commercial vehicle), then the Driver License Withdrawal


License Withdrawal Effective Date (DWDDWD)

WRONG PENALTY FOR

MAJOR-VIOLATION

WITHDRAWAL






215

217



Reason Code (DWDWRS) associated with a withdrawal ID is A50,

W40, or W41, the Driver License Withdrawal Eligibility Date

(DWDWDE) must be ŘINDEFř, ŘPERMř, or at least 55 years after the


WRONG PENALTY FOR

W40 WITHDRAWAL



Reason Code (DWDWRS) is W30, the Driver License Withdrawal

Eligibility Date (DWDWDE) must be at least 60 days after the Driver

License Withdrawal Effective Date (DWDDWD).

WRONG PENALTY FOR

W30 WITHDRAWAL






WRONG PENALTY FOR

W31 WITHDRAWAL



Reason Code (DWDWRS) is in the RRGC violations group (M10,

M20-M24), the Driver License Withdrawal Eligibility Date

(DWDWDE) must be at least 60 days after the Driver License

Withdrawal Effective Date (DWDDWD).

WRONG PENALTY FOR

RRGC-VIOLATION

WITHDRAWAL






WRONG PENALTY FOR

W60 WITHDRAWAL






WRONG PENALTY FOR

W61 WITHDRAWAL


after June 17, 1997 and if the Driver License ACD Withdrawal Reason

Code (DWDWRS) is B19, the Driver License Withdrawal Eligibility

Date (DWDWDE) must be between 180 days and 2 years after the


WRONG PENALTY FOR

B19 WITHDRAWAL

222 6-7.50 If the Driver License Withdrawal Effective Date (DWDDWD) is within

the period June 17, 1997 through September 3, 2010 and if the Driver

License ACD Withdrawal Reason Code (DWDWRS) is B27, the

Driver License Withdrawal Eligibility Date (DWDWDE) must be

between 90 days and 1 year after the Driver License Withdrawal


WRONG PENALTY FOR

B27 WITHDRAWAL


after September 4, 2010 and if the Driver License ACD Withdrawal

Reason Code (DWDWRS) is B27, the Driver License Withdrawal

Eligibility Date (DWDWDE) must be between 180 days and 1 year

after the Driver License Withdrawal Effective Date (DWDDWD).

WRONG PENALTY FOR

B27 WITHDRAWAL






222 6-7.52 If the Driver License Withdrawal Effective Date (DWDDWD) is within

the period June 17, 1997 through September 3, 2010 and if the Driver

License ACD Withdrawal Reason Code (DWDWRS) is W50, the

Driver License Withdrawal Eligibility Date (DWDWDE) must be

between 1 year and 5 years after the Driver License Withdrawal


WRONG PENALTY FOR

W50 WITHDRAWAL


after September 4, 2010 and if the Driver License ACD Withdrawal


Eligibility Date (DWDWDE) must be between 2 years and 5 years after

the Driver License Withdrawal Effective Date (DWDDWD).

WRONG PENALTY FOR

W50 WITHDRAWAL



Code (DWDWRS) is W51, the Driver License Withdrawal Eligibility

Date (DWDWDE) must be between 3 years and 5 years after the Driver


WRONG PENALTY FOR

W51 WITHDRAWAL



Code (DWDWRS) is W52, the Driver License Withdrawal Eligibility

Date (DWDWDE) must be between 3 years and 5 years after the Driver


WRONG PENALTY FOR

W52 WITHDRAWAL



Reason Code (DWDWRS) is D02, the Driver License Withdrawal



WRONG PENALTY FOR

D02 WITHDRAWAL




Eligibility Date (DWDWDE) must be no more than 1 year after the


WRONG PENALTY FOR

W70 WITHDRAWAL



CD32.A.3.6 Linkages

Table A.7: Validations that pertain to Linkages.



225 7-4.01 The Driver License Current Jurisdiction Code (DDLJU1)

embedded in the Driver License Jurisdiction Number (DDLJDL)

must be present

WITHDR-CONV LINKS -

DRIVER LICENSE JURIS

CODE REQUIRED

225 7-4.02 The Driver License Withdrawal ID Conviction Link (DWDWI2)

must be present

DRIVER LICENSE

WITHDRAWAL ID

REQUIRED




Table A.7: Validations that pertain to Linkages.


225 7-4.04 The Driver License Withdrawal Convictions Links Group

(DWDCLG) must be present (The first two characters of the field

must be present)

CONVICTION ID REQUIRED


225 7-5.01 The Driver License Current Jurisdiction Code (DDLJU1)

embedded in the Driver License Jurisdiction Number (DDLJDL)

must conform to the "United States" list in the Data Dictionary

appendix.

INVALID WITHDR-CONV

LINKS - DRIVER LICENSE

JURIS CODE

225 7-5.02 The Driver License Withdrawal ID Conviction Link must be

alphanumeric

INVALID WITHDRAWAL ID

IN LINKAGE

225 7-5.04 The Driver License Withdrawal Convictions Links Group

(DWDCLG) must be valid as specified in ŖAPPENDIX D - DATA

DICTIONARYŗ

INVALID CONVICTION ID

GROUP

225 7-5.06

Each Conviction ID Code embedded in the Driver License

Withdrawal Convictions Links Group (DWDCLG) must be valid

as specified in ŖAPPENDIX D - DATA DICTIONARYŗ

INVALID CONVICTION ID

IN LINKAGE

225 7-5.07

If the Driver License ACD Withdrawal Reason Code (DWDWRS)

is W30,

W30 must have 2 and only 2 underlying convictions

INVALID NUMBER OF

CONVICTION IDS IN

LINKAGE


225 7-7.01 The Driver License Withdrawal ID Conviction Link (DWDWI2) in

one linkage must not be repeated in any other linkage for a given

driver

REPEATED WITHDRAWAL

IDS IN LINKAGES

225 7-7.02 A Conviction ID Code embedded in the Driver License

Withdrawal Convictions Links Group (DWDCLG) for a given

linkage must not be repeated.

REPEATED CONVICTION

IDS IN CONVICTIONS

LINKS GRP

225 7-7.04 Each 2-character Driver License Withdrawal ID Conviction Link

(DWDWI2) for a given driver must match a Driver License

Withdrawal ID Code (DWDWID) in the H5 record

NO CORRESPONDING

WITHDRAWAL FOR

LINKAGE

225 7-7.08 Each 2-character Conviction ID Code in the Driver License

Withdrawal Convictions Links Group (DWDCLG) for a given

driver must match a Conviction ID Code (DCVCID) in the H3

record

NO CORRESPONDING

CONVICTION FOR

LINKAGE




APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE 482


APPENDIX A – DATA ELEMENTS BY MESSAGE TYPE

The Data Elements by AMIE Message Type matrices show the data elements (by AMIE block) that are included in eacn

message type. If an element is not sent in an AMIE message, it is not shown in the report.

Someelements may not be sent in a CDLIS messageŕsee the process description for details. Column headings in the

report include:

Call List Data Element Name Ŕ designation in the COBOL Call List references for the data element field.

Block Ŕ the AMIE block in which the data is transmitted. (An asterisk before the block code is included to aid in the

building of the call list. It indicates the call list name is used in other blocks).

Source Ŕ UNI code showing how a field is set when a message is initiated. The list below describes the codes used in

this column. (See the UNI Application Developer's manual for additional information).

Element Code Ŕ coded designation of the data element, which is listed in "APPENDIX D.1 - DATA ELEMENTS".

Nbr Of Occurs Ŕ maximum number of occurrences of an element within the message. If an element occurs 2 times in a

block and the block is used 3 times in the message, this column would have a value of 6.

When a field occurs multiple times in a message, the filling rules described by the source code can be ambiguous. In

some instances, the number of occurrences of a data element must be from zero to the specified maximum. In other

instances, the number must be from one to the specified maximum. Some fields occur independently of other fields,

while others occur as part of a repeated group of elements. Therefore, when a field occurs multiple times, see the filling

rules in the Process Description sections for specific details.

Source Definition of UNI Code

O Application optional. When a message is used in multiple processes or applications, an

element may be required in one process or application but not required in another. Since

each message type is only listed once in this appendix (regardless of the number of

processes in which it is used), data elements that are required in one process but not in

another are assigned a source code of 'Oř (optional). Additionally, data elements that are

required when available are also assigned a UNI source code of ŘOř (optional). In general,

the application will fill this field if the information is available, else leave the field blank.

Because of the ambiguity of the code ŘOř, see the Process Description sections in this

CDLIS Systems Specifications for complete instructions on how to fill these elements. For

example: In "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE", AAMVA lists

AKA data; 10-year history check results; the TSA threat determination and associated

HME expiration date, and accidents in the history as "optional" The specifications indicate

that jurisdictions must send all available information for these data elements. Therefore,

jurisdictions are required to maintain the information and transmit them on state-to-state

history requests and CSORs.

P Pass-through fields are required. The application must pass-through the entire length of

this field from the unsolicited inbound message to the same field in the outbound

message(s). Outbound messages are response messages or messages that are sent to a

third-party. If the inbound pass-through field is a space, the space must be passed-through

to the outbound message(s). The rule applies to application fields, the transaction

originator, and the message locator.

R Application required. This field is required for this message type. See the filling rules in

the Process Description sections for specific details.

T Transaction originator is required on unsolicited messages. If the 4-byte suffix is not used

in the Gap Code, the application can fill the field or the 7 bytes may be left blank then UNI

will fill the field with the 7-byte value from the site default field in the UNI's configuration

tables. When a bridge is not used in UNI, the recommendation is to leave the field blank

and allow UNI to fill it. If the site uses the 4-byte suffix field, the application must fill all

seven bytes of the Transaction Originator field (using the 4-byte suffix is not recommended




in UNI).

U The field is required for network processing. UNI will calculate the field when the field is

left blank in the call list. UNI calculates the field based on the supplied message, the host

system, or a configuration table. This applies to:

GSGSEQ: Segment Sequence Number, derived from the message.

GLSEGI: Last Segment Indicator, derived from the message.

GTPIND: Test/Production Indicator, from the system or a configuration table.

GNCBER: NCB Error Code, defaults to 'N'.

GNETST: Network Status, defaults to '00' when a message is sent.

V The field is required for network processing. UNI will calculate the field. UNI calculates

the field based on the supplied message, the host system, or a configuration table. This

applies to:

GMSLEN: Message Length, derived from the message.

GMSDAT: Message Date, obtained from the system.

GMSTIM: Message Time, obtained from the system.

GMSSEQ: Message Sequence ID, obtained from the system.

GNBTXT: Number of Text Blocks Count, derived from the message.

GNETSI: Network Session Indicator, derived from the network source code in the

parameter list.

GMSLOC: Message Locator, is set by UNI when sending the message. Normally it

is calculated on unsolicited messages. The exception to this rule is for

situations where the application requires a response to be sent as an

unsolicited message. However in these situations, the source for the

locator will be a pass-thru. The determination on when it is calculated is

controlled by UNI's Message Move tables.

W The field is required for network processing. UNI will use a like-named field on the

parameter list. This applies to:

GMSDST: Message Destination

GAPPID: Application ID

GMSTYP: Message Type

GXMODC: Transmit Mode, is set based on the parameter lists network service code.

X The field is required for network processing. UNI will calculate the field from the

configuration tables when a bridge is not used. When a bridge is used the value must be

supplied in the call list. This applies to the:

GMSORG: Message Origin.

The information contained in "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE" was extracted from

AAMVAřs Central Repository on January 22, 2010.

- CA - CONFIRM OUT OF STATE ACTION - (028C)

________________________________________




Element Nbr Of

Call List Data Element Name Block Source Code Occurs

CLMF-NUMB-NCB-MSG-LEN NCB V GMSLEN

CLMF-CODE-MSG-DEST NCB W GMSDST

CLMF-CODE-ORIGIN NCB X GMSORG

CLMF-DATE-NCB-MSG NCB V GMSDAT

CLMF-TIME-NCB-MSG NCB V GMSTIM

CLMF-DESC-NCB-MSG-SEQ-ID NCB V GMSSEQ

CLMF-CODE-NET-APPL-ID NCB W GAPPID

CLMF-CODE-MSG-TYPE NCB W GMSTYP

CLMF-NUMB-NCB-SEG NCB U GSGSEQ

CLMF-INDC-NCB-LAST-SEG NCB U GLSEGI

CLMF-CNT-NCB-NUM-TXT-BLKS NCB V GNBTXT

CLMF-INDC-NET-SESSION NCB V GNETSI

CLMF-INDC-TST-PROD NCB U GTPIND

CLMF-CODE-NCB-XMIT-MODE NCB W GXMODC

CLMF-CODE-NCB-ERROR NCB U GNCBER

CLMF-CODE-NCB-TRANS-ORIGINATOR NCB P GTRORG

CLMF-CODE-NET-STATUS NCB U GNETST

CLMF-CODE-APPL-STATUS NCB R GAPPST

AMIE-BLOCK01-COUNT 01/1 V GBKN01



CLMF-DESC-MEC-MSG-LOCATOR * 02/2 P GMSLOC

CLMF-CODE-MEC-PASSWORD 02/2 V GMSPSW

CLMF-CODE-MEC-PROCESS-STATUS * 02/2 R GPROST

CLMF-DESC-ERROR-BLOCK-OUT * 25/1 O GEROUT 5

- CB - CONFIRMATION OF DRIVER ADDED - (0252)

________________________________________

Element Nbr Of




























CLMF-CNT-MEC-MATCH * 02/2 R GMSCNT

CLMF-INDC-MEC-MATCH * 02/2 R GMSIND

CLMF-NUMB-MEC-MATCH-SEQ-ID * 02/2 R GMSMSI


CLMF-INDC-MEC-LAST-MATCH * 02/2 R GMSLMI

CLMF-CODE-MEC-SOR * 02/2 O GMSSOR

CLMF-INDC-MEC-MATCH-LIMIT-EX * 02/2 R GMSLEI

CLMF-INDC-MEC-CHANGE-SOR 02/2 R GMSSCH

CLMF-INDC-MEC-DUPE-FLAG 02/2 R GMSDUP

CLMF-MEC-CNT-DLN 02/2 O GMSCDL

CLMF-MEC-CNT-SSN 02/2 O GMSCSS

CLMF-MEC-CNT-NAME 02/2 O GMSCNM

CLMF-DESC-RETURN-AS-RECEIVED * 24/3 P GRRECV 5


- CC - CONFIRM DHR RECEIVED/PROCESSED - (0253)

________________________________________

Element Nbr Of





























CLMF-CODE-MEC-PASSWORD 02/2 R GMSPSW

CLMF-SYSTEM-REL-CODE 02/2 O GMSSRL

CLMF-CODE-STDLN-OLD-PRIMARY 04/1 R DDLJD1

CLMF-NUMB-SSN-OLD-PRIMARY 04/1 R DDVSS1

CLMF-NAME-OLD-PRIMARY 04/2 O DDVNM1

CLMF-DOB-OLD-PRIMARY 04/2 R DDVDO1

CLMF-CODE-STDLN-CURRENT * 09/2 R DDLJDL

CLMF-CODE-SSN-CURRENT * 09/2 R DDVSS6




CLMF-NAME-CURRENT * 10/2 O DDVNAM

CLMF-DOB-CURRENT * 10/2 R DDVDOB

CLMF-CUR-CODE-SEX * 10/2 O DDVSX3

CLMF-CUR-DESC-HEIGHT * 10/2 O DDVHT3

CLMF-CUR-DESC-WEIGHT * 10/2 O DDVWT3

CLMF-CUR-DESC-EYE-COLOR * 10/2 O DDVEY3

CLMF-PERSON-LAST-NAME 10/J O BPENLT

CLMF-PERSON-FIRST-NAME 10/J O BPENFT

CLMF-PERSON-MIDDLE-NAME 10/J O BPENMD

CLMF-PERSON-NAME-SUFFIX 10/J O BPENSX

CLMF-PERSON-TRUNC-1ST 10/N O BPENTF

CLMF-PERSON-TRUNC-MID 10/N O BPENTM

CLMF-PERSON-TRUNC-LAST 10/N O BPENTL

CLMF-PERSON-TRLIT-1ST 10/N O BPENRF

CLMF-PERSON-TRLIT-MID 10/N O BPENRM

CLMF-PERSON-TRLIT-LAST 10/N O BPENRL

CLMF-PERSON-OLD-LAST-NAME 10/K O BPENL1

CLMF-PERSON-OLD-FIRST-NAME 10/K O BPENF1

CLMF-PERSON-OLD-MID-NAME 10/K O BPENM1

CLMF-PERSON-OLD-NAME-SUFFIX 10/K O BPENS1

CLMF-PERSON-OLD-TRUNC-LAST 10/N O BPETL1

CLMF-PERSON-OLD-TRUNC-1ST 10/N O BPETF1

CLMF-PERSON-OLD-TRUNC-MID 10/N O BPETM1

CLMF-PERSON-OLD-TRLIT-LAST 10/N O BPERL1

CLMF-PERSON-OLD-TRLIT-1ST 10/N O BPERF1

CLMF-PERSON-OLD-TRLIT-MID 10/N O BPERM1



- CD - CONFIRM CHANGE DATA COMPLETE - (0254)

________________________________________

Element Nbr Of










































- CE - CONFIRM CSOR IS COMPLETE - (0255)

________________________________________

Element Nbr Of




























- CF - CONFIRM DELETE MPR IS COMPLETE - (0256)

________________________________________

Element Nbr Of































- CG - CONFIRM CSOR IN PROGRESS - (0257)

________________________________________

Element Nbr Of







































- CO - CONFIRM RECEIPT OF CX - (028J)

________________________________________

Element Nbr Of



























- CS - CONFIRM RECEIPT OF CA - (028D)

________________________________________

Element Nbr Of





























- CT - CONFIRM RECEIPT OF CW - (026J)

________________________________________

Element Nbr Of



























- CV - CONFIRM NEGATE WITHDRAWAL - (026H)

________________________________________

Element Nbr Of






























- CW - CONFIRM OUT-OF-STATE WITHDRAWAL - (026F)

________________________________________

Element Nbr Of






























- CX - ACKNOWLEDGE NEGATE CONVICTION - (028I)

________________________________________

Element Nbr Of



























- CY - CONFIRM RECEIPT OF CV - (026K)

________________________________________

Element Nbr Of






























- DQ - MPR DHR VALIDATION CONTROL - (029I)

________________________________________

Element Nbr Of

















CLMF-CODE-NCB-TRANS-ORIGINATOR NCB T GTRORG



CLMF-DRIVER-DATA-TYPE 02/2 R GRCDDT

CLMF-DRIVER-LICENCE-JURIS * 09/2 R DDLJUR

CLMF-REC-AS-OF-DATE 23/3 R GRCAOD

CLMF-REC-AS-OF-TIME 23/3 R GRCAOT

CLMF-CNT-DRIVERS 23/4 R DDVCNT

CLMF-REC-COUNT 23/4 R GRCCNT

CLMF-SSN-START 09/2 O DDVSS0

CLMF-SSN-END 09/7 O DDVSS9

CLMF-DLN-START 09/2 O DDLNU0

CLMF-DLN-END 09/7 O DDLNU9

CLMF-DESC-MEC-MSG-LOCATOR * 02/2 V GMSLOC

- EM - CDLIS BATCH SEARCH INQUIRY - (027E)

________________________________________

Element Nbr Of






























CLMF-CODE-MEC-PROCESS-STATUS * 02/2 O GPROST



CLMF-CODE-STDLN-CURRENT * 09/1 O DDLJDL

CLMF-CODE-SSN-CURRENT * 09/1 O DDVSS6



CLMF-NAME-AKA1 * 10/8 O DDVKNM

CLMF-NAME-AKA2 * 10/8 O DDVKN2


CLMF-DOB-AKA1 * 10/8 O DDVKDB

CLMF-DOB-AKA2 * 10/8 O DDVKD2












CLMF-PERSON-AKA-LAST-NAME 10/M O BPENL3 3

CLMF-PERSON-AKA-FIRST-NAME 10/M O BPENF3 3

CLMF-PERSON-AKA-MID-NAME 10/M O BPENM3 3

CLMF-PERSON-AKA-NAME-SUFFIX 10/M O BPENS3 3

CLMF-PERSON-AKA-TRUNC-LAST 10/N O BPETL3 3

CLMF-PERSON-AKA-TRUNC-1ST 10/N O BPETF3 3

CLMF-PERSON-AKA-TRUNC-MID 10/N O BPETM3 3

CLMF-PERSON-AKA-TRLIT-LAST 10/N O BPERL3 3

CLMF-PERSON-AKA-TRLIT-1ST 10/N O BPERF3 3

CLMF-PERSON-AKA-TRLIT-MID 10/N O BPERM3 3

CLMF-DESC-RETURN-AS-RECEIVED * 24/3 O GRRECV 5


- EQ - CDLIS BATCH INQUIRY CONTROL - (027F)




________________________________________

Element Nbr Of




























CLMF-BAT-STA-REQUESTS 23/4 R DDBST1

CLMF-BAT-CNT-RESP 23/4 O DDBNR1

CLMF-NUM-BAT-INQ-PROCESSED 23/4 O DDBNP1

CLMF-NUM-BAT-INQ-IN-ERROR 23/4 O DDBNE1

CLMF-BAT-CNT-RESP2 23/4 O DDBNR2

CLMF-BAT-INQ-DATE-SENT 23/3 R DDBISD

CLMF-BAT-DATE-RCV 23/3 O DDBIRD

CLMF-BAT-DATE-PROC 23/3 O DDBFPD

CLMF-BAT-DATE-RESP 23/3 O DDBRSD



- HA - REPORT OUT OF STATE CONVICTION - (028A)

________________________________________

Element Nbr Of






























CLMF-CNT-MEC-MATCH * 02/2 O GMSCNT

CLMF-INDC-MEC-MATCH * 02/2 O GMSIND

CLMF-NUMB-MEC-MATCH-SEQ-ID * 02/2 O GMSMSI


CLMF-INDC-MEC-LAST-MATCH * 02/2 O GMSLMI

CLMF-CODE-MEC-PASSWORD 02/2 O GMSPSW






CLMF-CODE-CONV-JUR * 17/1 R DCVJUR

CLMF-DATE-CITATION * 17/1 R DCIDCI

CLMF-DATE-CONV * 17/1 R DCVDCV

CLMF-CODE-COURT-TYPE * 17/1 R DCVCRT

CLMF-INDC-COMM-VEHICLE-OFF * 17/1 R DCVCOM

CLMF-INDC-HAZ-MATERIAL-OFF * 17/1 R DCVHAZ

CLMF-DESC-CONV-OFF-LOC * 17/1 R DCVCLO

CLMF-DESC-CONV-OFF-REF * 17/1 R DCVCOR

CLMF-ACD-CONV-OFF * 17/1 R DCVCCA

CLMF-ACD-CONV-OFF-DETAIL * 17/1 O DCVCDA












- HB - DRIVER HISTORY RESP(SOR - SOI) - (0259)

________________________________________

Element Nbr Of






































CLMF-MEC-CNT-DLN 02/2 R GMSCDL

CLMF-MEC-CNT-SSN 02/2 R GMSCSS

CLMF-MEC-CNT-NAME 02/2 R GMSCNM




CLMF-CODE-STDLN-AKA1 * 09/5 O DDLJD2



CLMF-CODE-SSN-AKA1 * 09/5 O DDVKSS













CLMF-DRVHIST-MAILING-ADDR * 11/1 R DDVADD

CLMF-DRVHIST-RESIDE-ADDR 11/5 O DDVRAD

CLMF-NUMB-PERMITS 14/1 R DDLNMP

CLMF-DESC-CDL-CLASS 14/1 R DDLCL2




CLMF-DESC-NON-CDL-CLASS 14/1 R DDLCL3

CLMF-DESC-DL-ENDORSE-OCCURS 14/1 O DDLEND 5

CLMF-DATE-DL-ISSUE 14/1 R DDLISS

CLMF-DATE-DL-EXPIRE 14/1 R DDLEXP

CLMF-DESC-NON-CDL-STATUS 14/1 R DDLNTS

CLMF-DESC-CDL-STATUS 14/1 R DDLCTS

CLMF-INDC-DL-WDRAW-PEND 14/1 R DDLWDP

CLMF-NUMB-DL-RESTR 14/1 R DDLNMR

CLMF-INDC-MED-HX 14/1 R DDVMED

CLMF-NUMB-CONV-SENT 14/1 R DDTTCS

CLMF-NUMB-CONV-RECORD 14/1 R DDTTCR

CLMF-NUMB-ACC-SENT 14/1 R DDTTAS

CLMF-NUMB-ACC-RECORD 14/1 R DDTTAR

CLMF-NUMB-WDRAW-SENT 14/1 R DDTTWS

CLMF-NUMB-WDRAW-RECORD 14/1 R DDTTWR

CLMF-NUMB-LINKS-SENT 14/1 O DDTTLS

CLMF-NUMB-LINKS-RECORD 14/1 O DDTTLR

CLMF-DL-HIST-INQUIRING-JURIS 14/2 O DDLHCI

CLMF-DL-HIST-CHECK-DATE 14/2 O DDLHCD

CLMF-DL-HIST-STATE-TOTAL 14/2 O DDLHCT

CLMF-DL-HIST-JURIS 14/2 O DDLHCJ 15

CLMF-DL-HIST-REQUEST-TOTAL 14/2 O DDLHCR

CLMF-HME-EXP-DATE 14/3 O DDLHED

CLMF-TSA-HME-DETERMINATION 14/3 O DTHTSD

CLMF-MED-SELF-CERTIFICATION 14/5 O DDLSCT

CLMF-CODE-LIC-RESTR 16/1 O DDLRSC 12

CLMF-DATE-LIC-RESTR-END 16/1 O DDLRSD 12

CLMF-DESC-LIC-EXPL 16/1 O DDLRSE 12

CLMF-MED-CERT-ISS-DATE 14/5 O DMCPED

CLMF-MED-CERT-EXP-DATE 14/5 O DMCEDT

CLMF-MED-CERT-STATUS-CODE 14/5 O DMCCTC

CLMF-MED-CERT-RESTRICTION 14/5 O DMCRES 6

CLMF-MEDIC-JUR-CODE-1 62/2 O BMPJO1

CLMF-MEDIC-NUM-1 62/2 O BMPLI1

CLMF-MEDIC-PHONE-NUM-1 62/2 O BMPTP1

CLMF-MEDIC-REG-NUM 62/2 O BMPNRN

CLMF-MEDIC-SPECIALTY-1 62/2 O BMPSP1

CLMF-WE-START-DATE 14/5 O DDLWSD

CLMF-WE-EXP-DATE 14/5 O DDLWED

CLMF-SPE-START-DATE 14/5 O DDLSSD

CLMF-SPE-EXP-DATE 14/5 O DDLSED
























CLMF-MEDIC-NAME-LAST-1 62/3 O BMPNL1

CLMF-MEDIC-NAME-1ST-1 62/3 O BMPNF1

CLMF-MEDIC-NAME-MIDDLE-1 62/3 O BMPNM1

CLMF-MEDIC-NAME-SFX-1 62/3 O BMPNS1

CLMF-MEDIC-TRUNC-LAST-1 62/2 O BMPTL1

CLMF-MEDIC-TRUNC-1ST-1 62/2 O BMPTF1

CLMF-MEDIC-TRUNC-MID-1 62/2 O BMPTM1

CLMF-MEDIC-TRANS-LAST-1 62/2 O BMPLL1

CLMF-MEDIC-TRANS-1ST-1 62/2 O BMPLF1

CLMF-MEDIC-TRANS-MID-1 62/2 O BMPLM1



- HC - STATUS RESPONSE (SOR - SOI) - (0260)

________________________________________

Element Nbr Of















































































CLMF-DESC-PERM-CLASS 15/1 O DDLPC2 3

CLMF-DESC-PERM-ENDORSE 15/1 O DDLEP1 3

CLMF-DATE-PERM-ISSUE 15/1 O DDLPID 3

CLMF-DATE-PERM-EXPIRE 15/1 O DDLPED 3

CLMF-DESC-PERM-STATUS 15/1 O DDLPST 3

CLMF-NUMB-PERM-RESTR 15/1 O DDLRPN 3



















































- HD - DRIVER HISTORY RESP(SOR - SOR) - (0261)

________________________________________

Element Nbr Of
























CLMF-NUMB-LINKS-SENT 14/1 O DDTTLS

CLMF-NUMB-LINKS-RECORD 14/1 O DDTTLR

CLMF-DL-HIST-INQUIRING-JURIS 14/2 O DDLHCI

CLMF-DL-HIST-CHECK-DATE 14/2 O DDLHCD

CLMF-DL-HIST-STATE-TOTAL 14/2 O DDLHCT

CLMF-DL-HIST-JURIS 14/2 O DDLHCJ 15

CLMF-DL-HIST-REQUEST-TOTAL 14/2 O DDLHCR






















































- HF - FWD RPT OUT OF ST CONVICTION - (028B)

________________________________________

Element Nbr Of






































CLMF-CUR-CODE-SEX * 10/4 R DDVSX3










CLMF-CODE-COURT-TYPE * 17/1 R DCVCRT

CLMF-INDC-COMM-VEHICLE-OFF * 17/1 R DCVCOM

CLMF-INDC-HAZ-MATERIAL-OFF * 17/1 R DCVHAZ
















- HG - STATUS RESPONSE (SOR - SOI) - (0263)

________________________________________

Element Nbr Of










































CLMF-SYSTEM-REL-CODE 02/2 R GMSSRL









































CLMF-DESC-PERM-CLASS 15/1 O DDLPC2 3


CLMF-DATE-PERM-ISSUE 15/1 O DDLPID 3

CLMF-DATE-PERM-EXPIRE 15/1 O DDLPED 3

CLMF-DESC-PERM-STATUS 15/1 O DDLPST 3

CLMF-NUMB-PERM-RESTR 15/1 O DDLRPN 3




















































- HH - NEGATE CONVICTION - (028G)

________________________________________

Element Nbr Of












































CLMF-CODE-COURT-TYPE * 17/1 O DCVCRT

CLMF-INDC-COMM-VEHICLE-OFF * 17/1 O DCVCOM

CLMF-INDC-HAZ-MATERIAL-OFF * 17/1 O DCVHAZ
















- HT - FORWARD OUT-OF-STATE WITHDRAWAL - (026B)

________________________________________

Element Nbr Of

















CLMF-INDC-TST-PROD NCB V GTPIND





























CLMF-CODE-CONV-JUR-OOSW 17/4 R DCVJU3 14

CLMF-DATE-CITATION-OOSW 17/4 R DCIDC3 14

CLMF-DATE-CONV-OOSW 17/4 R DCVDC3 14

CLMF-CODE-COURT-TYPE-OOSW 17/4 R DCVCR3 14

CLMF-INDC-COMM-VEH-OFF-OOSW 17/4 R DCVCO4 14

CLMF-INDC-HAZMAT-OFF-OOSW 17/4 R DCVHA3 14

CLMF-DESC-CONV-OFF-LOC-OOSW 17/4 R DCVCL3 14

CLMF-DESC-CONV-OFF-REF-OOSW 17/4 R DCVCO5 14

CLMF-ACD-CONV-OFF-OOSW 17/4 R DCVCC3 14

CLMF-ACD-CONV-OFF-DET-OOSW 17/4 O DCVCD4 14

CLMF-CODE-WDRAW-JUR 19/1 R DWDJUR

CLMF-DATE-WDRAW 19/1 R DWDDWD

CLMF-CODE-WDRAW-ACTION-TYPE * 19/1 R DWDWTP

CLMF-CODE-WDRAW-BASIS * 19/1 R DWDWBS

CLMF-CODE-WDRAW-DUE-PROC-STAT * 19/1 R DWDWPS

CLMF-CODE-WDRAW-REASON 19/1 R DWDWRS

CLMF-DATE-WDRAW-ELIG 19/1 R DWDWDE

CLMF-DATE-WDRAW-REINST 19/1 O DWDWDR




CLMF-CODE-WDRAW-EXTENT 19/1 R DWDWEX

CLMF-CODE-WDRAW-LOC 19/1 R DWDWLO

CLMF-CODE-WDRAW-REF 19/1 R DWDWRR












- HV - FORWARD NEGATE WITHDRAWAL - (026C)

________________________________________

Element Nbr Of


































CLMF-SYSTEM-REL-CODE 02/2 P GMSSRL













CLMF-DATE-WDRAW 19/1 O DWDDWD

CLMF-CODE-WDRAW-ACTION-TYPE * 19/1 O DWDWTP

CLMF-CODE-WDRAW-BASIS * 19/1 O DWDWBS

CLMF-CODE-WDRAW-DUE-PROC-STAT * 19/1 O DWDWPS

CLMF-CODE-WDRAW-REASON 19/1 O DWDWRS

CLMF-DATE-WDRAW-ELIG 19/1 O DWDWDE


CLMF-CODE-WDRAW-EXTENT 19/1 O DWDWEX














- HW - REPORT OUT-OF-STATE WITHDRAWAL - (026E)

________________________________________

Element Nbr Of










































CLMF-CODE-CONV-JUR-OOSW 17/4 R DCVJU3 14

CLMF-DATE-CITATION-OOSW 17/4 R DCIDC3 14

CLMF-DATE-CONV-OOSW 17/4 R DCVDC3 14

CLMF-CODE-COURT-TYPE-OOSW 17/4 R DCVCR3 14

CLMF-INDC-COMM-VEH-OFF-OOSW 17/4 R DCVCO4 14

CLMF-INDC-HAZMAT-OFF-OOSW 17/4 R DCVHA3 14

CLMF-DESC-CONV-OFF-LOC-OOSW 17/4 R DCVCL3 14

CLMF-DESC-CONV-OFF-REF-OOSW 17/4 R DCVCO5 14

CLMF-ACD-CONV-OFF-OOSW 17/4 R DCVCC3 14

CLMF-ACD-CONV-OFF-DET-OOSW 17/4 O DCVCD4 14


CLMF-DATE-WDRAW 19/1 R DWDDWD

CLMF-CODE-WDRAW-ACTION-TYPE * 19/1 R DWDWTP

CLMF-CODE-WDRAW-BASIS * 19/1 R DWDWBS

CLMF-CODE-WDRAW-DUE-PROC-STAT * 19/1 R DWDWPS

CLMF-CODE-WDRAW-REASON 19/1 R DWDWRS

CLMF-DATE-WDRAW-ELIG 19/1 R DWDWDE


CLMF-CODE-WDRAW-EXTENT 19/1 R DWDWEX














- HX - FWD NEGATE CONVICTION - (028H)

________________________________________

Element Nbr Of


CLMF-DESC-NCB-TXN-PROG NCB U GTXNPR

CLMF-NUMB-NCB-MSG-LEN NCB U GMSLEN

CLMF-CODE-MSG-DEST NCB U GMSDST

CLMF-CODE-ORIGIN NCB U GMSORG




CLMF-DATE-NCB-MSG NCB U GMSDAT

CLMF-TIME-NCB-MSG NCB U GMSTIM

CLMF-DESC-NCB-MSG-SEQ-ID NCB U GMSSEQ

CLMF-CODE-NET-APPL-ID NCB U GAPPID

CLMF-CODE-MSG-TYPE NCB U GMSTYP

CLMF-NUMB-NCB-SEG NCB I GSGSEQ

CLMF-INDC-NCB-LAST-SEG NCB I GLSEGI

CLMF-CNT-NCB-NUM-TXT-BLKS NCB U GNBTXT

CLMF-INDC-NET-SESSION NCB U GNETSI

CLMF-INDC-TST-PROD NCB I GTPIND

CLMF-CODE-NCB-XMIT-MODE NCB U GXMODC

CLMF-CODE-NCB-ERROR NCB I GNCBER





























CLMF-CODE-COURT-TYPE * 17/1 O DCVCRT

CLMF-INDC-COMM-VEHICLE-OFF * 17/1 O DCVCOM

CLMF-INDC-HAZ-MATERIAL-OFF * 17/1 O DCVHAZ



















- HY - NEGATE OUT-OF-STATE WITHDRAWAL - (026G)

________________________________________

Element Nbr Of








































CLMF-DATE-WDRAW 19/1 O DWDDWD

CLMF-CODE-WDRAW-ACTION-TYPE * 19/1 O DWDWTP

CLMF-CODE-WDRAW-BASIS * 19/1 O DWDWBS

CLMF-CODE-WDRAW-DUE-PROC-STAT * 19/1 O DWDWPS

CLMF-CODE-WDRAW-REASON 19/1 O DWDWRS

CLMF-DATE-WDRAW-ELIG 19/1 O DWDWDE


CLMF-CODE-WDRAW-EXTENT 19/1 O DWDWEX

















- H2 - DRIVER HISTORY PERMIT INFO - (0264)

________________________________________

Element Nbr Of



































CLMF-DESC-PERM-CLASS 15/1 R DDLPC2 3


CLMF-DATE-PERM-ISSUE 15/1 R DDLPID 3

CLMF-DATE-PERM-EXPIRE 15/1 R DDLPED 3

CLMF-DESC-PERM-STATUS 15/1 R DDLPST 3

CLMF-NUMB-PERM-RESTR 15/1 R DDLRPN 3

CLMF-CODE-P1-RESTR 16/2 O DDLRP1 12

CLMF-DATE-P1-RESTR-END 16/2 O DDLPD1 12




CLMF-DESC-P1-EXPL 16/2 O DDLPE1 12








- H3 - DRIVER HISTORY CONVICTIONS - (0265)

________________________________________

Element Nbr Of


































CLMF-CODE-CONV-JUR * 17/1 R DCVJUR 50

CLMF-DATE-CITATION * 17/1 R DCIDCI 50

CLMF-CONV-ID-CODE 17/1 O DCVCID 50

CLMF-DATE-CONV * 17/1 R DCVDCV 50

CLMF-CODE-COURT-TYPE * 17/1 R DCVCRT 50

CLMF-INDC-COMM-VEHICLE-OFF * 17/1 R DCVCOM 50

CLMF-INDC-HAZ-MATERIAL-OFF * 17/1 R DCVHAZ 50

CLMF-DESC-CONV-OFF-LOC * 17/1 R DCVCLO 50

CLMF-DESC-CONV-OFF-REF * 17/1 R DCVCOR 50

CLMF-ACD-CONV-OFF * 17/1 R DCVCCA 50




CLMF-ACD-CONV-OFF-DETAIL * 17/1 O DCVCDA 50

CLMF-CITATION-CDL-IND 17/1 R DCICHI 50


- H4 - DRIVER HISTORY ACCIDENTS - (0266)

________________________________________

Element Nbr Of


































CLMF-CODE-ACC-JUR * 18/1 R DACJUR 50

CLMF-DATE-ACC * 18/1 R DACDAT 50

CLMF-INDC-ACC-SEVERITY * 18/1 R DACSEV 50

CLMF-INDC-ACC-COMM * 18/1 R DDACOM 50

CLMF-INDC-ACC-HAZ-MAT * 18/1 R DDAHAZ 50

CLMF-INDC-ACC-LOC * 18/1 R DACLOC 50


- H5 - DRIVER HISTORY WITHDRAWALS - (0267)

________________________________________

Element Nbr Of





































CLMF-CODE-WDRAW-JUR 19/1 R DWDJUR 50

CLMF-DATE-WDRAW 19/1 R DWDDWD 50

CLMF-CODE-WDRAW-ACTION-TYPE * 19/1 R DWDWTP 50

CLMF-CODE-WDRAW-BASIS * 19/1 R DWDWBS 50

CLMF-CODE-WDRAW-DUE-PROC-STAT * 19/1 R DWDWPS 50

CLMF-CODE-WDRAW-REASON 19/1 R DWDWRS 50

CLMF-DATE-WDRAW-ELIG 19/1 R DWDWDE 50

CLMF-DATE-WDRAW-REINST 19/1 O DWDWDR 50

CLMF-CODE-WDRAW-EXTENT 19/1 R DWDWEX 50

CLMF-CODE-WDRAW-LOC 19/1 R DWDWLO 50

CLMF-CODE-WDRAW-REF 19/1 R DWDWRR 50

CLMF-WD-ID-CODE 19/1 O DWDWID 50


- H6 - PERMIT RESTRICTIONS - (0268)

________________________________________

Element Nbr Of















































- H7 - DRIVER HISTORY WITHD-CONV LINKS - (026A)

________________________________________

Element Nbr Of


































CLMF-SYSTEM-REL-CODE 02/2 R GMSSRL



CLMF-WD-ID-CODE-LINK 19/3 R DWDWI2 50

CLMF-WD-CONV-LINK-GRP 19/3 R DWDCLG 50


- IA - INQ REQ CHG DATA/MARK UNIQUE - (0269)

________________________________________

Element Nbr Of
















































- IB - INQ REQUEST PRECEDING DEL MPR - (0270)

________________________________________

Element Nbr Of
















































- IC - INQ REQUEST PRECEDING CSOR - (0271)

________________________________________

Element Nbr Of
















































- ID - INQ REQ PRECEDE RPT OOS CONVCT - (0272)

________________________________________

Element Nbr Of
















































- IE - INQUIRY REQUEST PRECEDING DHR - (0273)

________________________________________

Element Nbr Of













































- IF - MINIMAL DRIVER DATA INQUIRY - (029A)

________________________________________

Element Nbr Of

































CLMF-SEARCH-YEAR-RANGE 02/2 O GMSSYR

CLMF-1ST-MATCH-SEQ-ID 02/2 O GMSFMS

CLMF-CODE-SOR 20/1 O BJUCD1 10

CLMF-DRIVER-AGE 10/A O DDVAGE

CLMF-PERSON-LAST-NAME 10/J R BPENLT




CLMF-PERSON-TRUNC-1ST 10/N R BPENTF

CLMF-PERSON-TRUNC-MID 10/N R BPENTM

CLMF-PERSON-TRUNC-LAST 10/N R BPENTL

CLMF-PERSON-TRLIT-1ST 10/N R BPENRF

CLMF-PERSON-TRLIT-MID 10/N R BPENRM

CLMF-PERSON-TRLIT-LAST 10/N R BPENRL



- IK - INQUIRY FOR AKA DATA - (0274)

________________________________________

Element Nbr Of
































































- IM - CDLIS SEARCH INQUIRY - (0275)

________________________________________

Element Nbr Of







- IN - VERIFICATION INQUIRY - (0276)

________________________________________

Element Nbr Of













































- IO - INQ PRECEDING CREATE NEW DRIVER - (0277)

________________________________________




Element Nbr Of































































- IW - EMPLOYER INQUIRY - (027A)

________________________________________

Element Nbr Of











































- IX - APPLICATION STATUS INQUIRY - (0279)

________________________________________




Element Nbr Of



















- NA - CDLIS POSSIBLE DUPLICATE - (0280)

________________________________________

Element Nbr Of































CLMF-CODE-MEC-SOR * 02/2 R GMSSOR












CLMF-CODE-STDLN-DUPE 09/7 R DDLJD5

CLMF-CODE-SSN-DUPE 09/7 R DDVSS2







CLMF-NAME-DUPE 10/7 O DDVNM3

CLMF-DOB-DUPE 10/7 R DDVDO2

CLMF-DUP-CODE-SEX 10/7 R DDVSX2

CLMF-DUP-DESC-HEIGHT 10/7 O DDVHT2

CLMF-DUP-DESC-WEIGHT 10/7 O DDVWT4

CLMF-DUP-DESC-EYE-COLOR 10/7 O DDVEY2











CLMF-PERSON-DUP-LAST-NAME 10/L O BPENL2

CLMF-PERSON-DUP-FIRST-NAME 10/L O BPENF2

CLMF-PERSON-DUP-MID-NAME 10/L O BPENM2

CLMF-PERSON-DUP-NAME-SUFFIX 10/L O BPENS2

CLMF-PERSON-DUP-TRUNC-LAST 10/N O BPETL2

CLMF-PERSON-DUP-TRUNC-1ST 10/N O BPETF2

CLMF-PERSON-DUP-TRUNC-MID 10/N O BPETM2

CLMF-PERSON-DUP-TRLIT-LAST 10/N O BPERL2

CLMF-PERSON-DUP-TRLIT-1ST 10/N O BPERF2

CLMF-PERSON-DUP-TRLIT-MID 10/N O BPERM2


- NE - CDLIS DUPLICATE RESOLVED - (0281)

________________________________________

Element Nbr Of




















































CLMF-DUP-CODE-SEX 10/7 R DDVSX2

CLMF-DUP-DESC-HEIGHT 10/7 O DDVHT2

CLMF-DUP-DESC-WEIGHT 10/7 O DDVWT4

CLMF-DUP-DESC-EYE-COLOR 10/7 O DDVEY2












- NF - CONFIRM CSOR IS COMPLETE - (0282)




________________________________________

Element Nbr Of









































- QC - # OF BATCH STATUS RESPONSES - (027C)

________________________________________

Element Nbr Of









































- QD - BATCH MPR DATA MATCH(ES) - (027D)

________________________________________

Element Nbr Of
















































































- RC - # OF STATUS RESP FROM INQ TRANS - (0283)




________________________________________

Element Nbr Of






































- RD - MPR DATA MATCH(S) ON INQ TRANS - (0284)

________________________________________

Element Nbr Of






















- RK - NUMBER OF MPR RESP FROM INQUIRY - (029C)

________________________________________

Element Nbr Of
































- RQ - CDLIS BATCH RESPONSE CONTROL - (027G)

________________________________________

Element Nbr Of































CLMF-BAT-STA-REQUESTS 23/4 R DDBST1

CLMF-BAT-CNT-RESP 23/4 R DDBNR1

CLMF-NUM-BAT-INQ-PROCESSED 23/4 R DDBNP1

CLMF-NUM-BAT-INQ-IN-ERROR 23/4 R DDBNE1

CLMF-BAT-CNT-RESP2 23/4 R DDBNR2

CLMF-BAT-INQ-DATE-SENT 23/3 R DDBISD

CLMF-BAT-DATE-RCV 23/3 R DDBIRD

CLMF-BAT-DATE-PROC 23/3 R DDBFPD

CLMF-BAT-DATE-RESP 23/3 R DDBRSD



- RW - EMPLOYER INQUIRY RESPONSE (3RD) - (027B)

________________________________________

Element Nbr Of




































CLMF-INDC-MEC-MATCH-LIMIT-EX * 02/2 B GMSLEI

CLMF-INDC-MEC-CHANGE-SOR 02/2 B GMSSCH

CLMF-INDC-MEC-DUPE-FLAG 02/2 B GMSDUP















































- RZ - MPR DATA FOR MATCH ON INQUIRY - (029E)

________________________________________

Element Nbr Of









































CLMF-PERSON-DOB 62/1 R BPEDOB

CLMF-PERSON-LAST-NAME 10/J R BPENLT




CLMF-PERSON-TRUNC-1ST 10/N R BPENTF

CLMF-PERSON-TRUNC-MID 10/N R BPENTM

CLMF-PERSON-TRUNC-LAST 10/N R BPENTL

CLMF-PERSON-TRLIT-1ST 10/N R BPENRF




CLMF-PERSON-TRLIT-MID 10/N R BPENRM

CLMF-PERSON-TRLIT-LAST 10/N R BPENRL












- SB - DRIVER HISTORY REQUEST - (0287)

________________________________________

Element Nbr Of
































CLMF-DOB-CURRENT * 10/1 O DDVDOB
















- SC - STATUS REQUEST - (0288)

________________________________________

Element Nbr Of


























CLMF-CNT-MEC-MATCH * 02/2 B GMSCNT

CLMF-INDC-MEC-MATCH * 02/2 B GMSIND



CLMF-INDC-MEC-LAST-MATCH * 02/2 B GMSLMI

CLMF-INDC-MEC-MATCH-LIMIT-EX * 02/2 B GMSLEI























- SD - CSOR HISTORY REQUEST - (0289)

________________________________________

Element Nbr Of





























CLMF-SYSTEM-REL-CODE 02/2 P GMSSRL





































- SG - STATE REQUEST FOR STATUS - (0290)

________________________________________

Element Nbr Of















































- SR - HISTORY REDRIVE - (029H)

________________________________________

Element Nbr Of


























CLMF-PERSON-OLD-LAST-NAME 10/K R BPENL1




CLMF-PERSON-OLD-TRUNC-LAST 10/N R BPETL1

CLMF-PERSON-OLD-TRUNC-1ST 10/N R BPETF1

CLMF-PERSON-OLD-TRUNC-MID 10/N R BPETM1

CLMF-PERSON-OLD-TRLIT-LAST 10/N R BPERL1

CLMF-PERSON-OLD-TRLIT-1ST 10/N R BPERF1

CLMF-PERSON-OLD-TRLIT-MID 10/N R BPERM1


- UA - ADD NEW DRIVER (SOR - CDLIS) - (0291)

________________________________________




Element Nbr Of











































































- UC - CHANGE DATA (SOR - CDLIS) - (0292)

________________________________________

Element Nbr Of


























































































- UD - CHANGE STATE-of-RECORD - (0293)

________________________________________

Element Nbr Of










- UE - DELETE MASTER POINTER RECORD - (0294)

________________________________________

Element Nbr Of




















































- UG - MARK DRIVER UNIQUE - (0295)

________________________________________

Element Nbr Of






























































- UK - UPDATE AKA (SOR - CDLIS) - (0296)

________________________________________

Element Nbr Of












































APPENDIX B - BLOCKS BY MESSAGE TYPE 556


APPENDIX B - BLOCKS BY MESSAGE TYPE

The following information describes which blocks are used in which AMIE message. The description contains:

Block Number.

Block Name.

Required / Optional indicator. A value of ŖRequiredŗ means the block must be present in a message. Empty

blocks (containing no data) are not transmitted. If a given block may not be present because the data were not

present, the Required / Optional indicator is ŘOptionalř. Blocks that contain only elements that may or may not

be transmitted at the option of the sender are also marked as ŘOptionalř. See the specifications for the given

transaction to see if an Ŗoptionalŗ block is Ŗrequiredŗ when the information is available.

Occurrence. When a message can contain a block multiple times, this column indicates the maximum number of

times the block may appear. The occurrence is a count of the physical blocks used (a logical block that is 122

bytes long and is used 3 times would have an occurrence count of 6).

A summary of the size of each AMIE message, is included after the list of blocks. AMIE messages can hold up to 55

blocks. However, the number of blocks shown on some messages with optional blocks may exceed the 55 block limit.

In these instances, the documentation is showing the blocks in a message and the maximum number of occurrences of

those blocks. In practice the maximum number of the occurrences are hardly ever used, so the 55 limit will not be

reached. If an application finds it has more than 55 blocks of data for a message, it must omit some of the blocks to

maintain the 55 limit.

Four message types (H3, H4, H5, and H7) have more than 55 blocks listed, including up to 55 data blocks on the

original message and up to an additional 5 error blocks on messages returned in error. When necessary on a message

returned in error, enough data blocks (convictions, accidents, withdrawals, or linkages, respectively) are removed to

make the limit of 55 blocks per message.

The information contained in Appendix B was extracted from AAMVAřs Central Repository on January 22, 2010.

- CA - CONFIRM OUT OF STATE ACTION - (023C)

________________________________________

Block Type/Sub-Type - Name Comment Occurs

00/0 NETWORK CONTROL BLOCK Required

01/1 VERIFICATION BLOCK Required

02/2 CDLIS/DLR/PDPS MSG EXCHANGE CONTROL Required

25/1 EDIT/ERROR DESCRIPTION BLOCK Optional 5

Variable Length: 198 to 528, in 8 Blocks of 66 characters.

- CB - CONFIRMATION OF DRIVER ADDED - (0202)

________________________________________





24/3 RETURN AS RECEIVED Optional 5






- CC - CONFIRM DHR RECEIVED/PROCESSED - (0203)

________________________________________





04/1 OLD PRIMARY ST DLN/SSN BLOCK Required

04/2 OLD PRIMARY NAME/DESCRIPTION BLOCK Required

09/2 PRIMARY STATE/DLN/SSN SOR Required

10/2 DRIVER NAME/DESCRIPTIVE DATA - SOR Required



10/J PERSON NAME Optional 2

10/K PERSON OLD NAME Optional 2

10/N PERSON NAME INDICATORS Optional


- CD - CONFIRM CHANGE DATA COMPLETE - (0204)

________________________________________








- CE - CONFIRM CSOR IS COMPLETE - (0205)

________________________________________








- CF - CONFIRM DELETE MPR IS COMPLETE - (0206)

________________________________________











- CG - CONFIRM CSOR IN PROGRESS - (0207)

________________________________________








- CO - CONFIRM RECEIPT OF CX - (023J)

________________________________________







- CS - CONFIRM RECEIPT OF CA - (023D)

________________________________________







- CT - CONFIRM RECEIPT OF CW - (021J)

________________________________________










- CV- CONFIRM NEGATE WITHDRAWAL - (021H)

________________________________________







- CW - CONFIRM OUT-OF-STATE WITHDRAWAL - (021F)

________________________________________







- CX - ACKNOWLEDGE NEGATE CONVICTION - (023I)

________________________________________







- CY - CONFIRM RECEIPT OF CV - (021K)

________________________________________










- DQ - MPR DHR VALIDATION CONTROL - (024I)

________________________________________






09/7 DUPLICATE STATE/DLN/SSN from CDLIS Optional

23/3 BATCH FILE CONTROL DATES Required

23/4 BATCH FILE CONTROL COUNTS Required


- EM - CDLIS BATCH SEARCH INQUIRY - (022E)

________________________________________





09/1 PRIMARY STATE/DLN/SSN SOI Optional

10/1 DRIVER NAME/DESCRIPTIVE DATA - SOI Required

10/8 AKA DRIVER NAME - SOI Optional 3




10/M PERSON AKA NAME Optional 6



- EQ - CDLIS BATCH INQUIRY CONTROL - (022F)

________________________________________













- HA - REPORT OUT OF STATE CONVICTION - (023A)

________________________________________





09/1 PRIMARY STATE/DLN/SSN SOI Required


17/1 DRIVER CONVICTION BLOCK Required





- HB - DRIVER HISTORY RESP(SOR - SOI) - (0209)

________________________________________






09/5 AKA STATE/DLN/SSN from SOR Optional 3


10/5 AKA DRIVER NAME - SOR Optional 3

11/1 INDIVIDUAL/EMPLOYEE MAILING ADDRESS Required 2

11/5 INDIVIDUAL/EMPLOYEE HOME ADDRESS Optional 2

14/1 DRIVER HISTORY BLOCK Required

14/2 DRIVER HISTORY CHECKS BLOCK Optional

14/3 DRIVER HME BLOCK Optional

14/5 DRIVER MEDICAL CERTIFICATE Optional

16/1 DRIVER RESTRICTION/LICENSE Optional 12



62/2 MEDICAL EXAMINER Optional

62/3 MEDICAL EXAMINER NAME Optional





- HC - STATUS RESPONSE (SOR - SOI) - (0210)

________________________________________
















15/1 DRIVER PERMIT INFORMATION BLOCK Optional 3









- HD - DRIVER HISTORY RESP(SOR - SOR) - (0211)

________________________________________












14/2 DRIVER HISTORY CHECKS BLOCK Optional











- HF - FWD RPT OUT OF ST CONVICTION - (023B)

________________________________________








09/4 PRIMARY STATE/DLN/SSN from CDLIS Required

10/4 DRIVER NAME/DESCRIPTIVE DATA - CDLIS Required






- HG - STATUS RESPONSE (SOR - SOI) - (0213)

________________________________________














15/1 DRIVER PERMIT INFORMATION BLOCK Optional 3










- HH - NEGATE CONVICTION - (023G)

________________________________________















- HT - FORWARD OUT-OF-STATE WITHDRAWAL - (021B)

________________________________________







17/4 DRIVER CONVICTION (REPORT OOSW) Optional 14

19/1 DRIVER WITHDRAWAL BLOCK Required





- HV - FORWARD NEGATE WITHDRAWAL - (021C)

________________________________________












- HW - REPORT OUT-OF-STATE WITHDRAWAL - (021E)

________________________________________







17/4 DRIVER CONVICTION (REPORT OOSW) Optional 14









- HX - FWD NEGATE CONVICTION - (023H)

________________________________________












- HY - NEGATE OUT-OF-STATE WITHDRAWAL - (021G)

________________________________________












- H2 - DRIVER HISTORY PERMIT INFO - (0214)

________________________________________






15/1 DRIVER PERMIT INFORMATION BLOCK Required 3

16/2 DRIVER RESTRICTION/PERMIT #1 Optional 12








- H3 - DRIVER HISTORY CONVICTIONS - (0215)

________________________________________






17/1 DRIVER CONVICTION BLOCK Required 50



- H4 - DRIVER HISTORY ACCIDENTS - (0216)

________________________________________






18/1 DRIVER ACCIDENT BLOCK Required 50



- H5 - DRIVER HISTORY WITHDRAWALS - (0217)

________________________________________






19/1 DRIVER WITHDRAWAL BLOCK Required 50



- H6 - PERMIT RESTRICTIONS - (0218)

________________________________________














- H7 - DRIVER HISTORY WITHD-CONV LINKS - (021A)

________________________________________






19/3 DRIVER WITHDRAWAL CONVICTION BLOCK Required 50



- IA - INQ REQ CHG DATA/MARK UNIQUE - (0219)

________________________________________












- IB - INQ REQUEST PRECEDING DEL MPR - (0220)

________________________________________















- IC - INQ REQUEST PRECEDING CSOR - (0221)

________________________________________












- ID - INQ REQ PRECEDE RPT OOS CONVCT - (0222)

________________________________________












- IE - INQUIRY REQUEST PRECEDING DHR - (0223)

________________________________________















- IF - MINIMAL DRIVER DATA INQUIRY - (024A)

________________________________________





20/1 STATE OF RECORD LIST BLOCK Optional



10/A DRIVER NAME / DESCRIPTIVE BLOCK Optional

10/J PERSON NAME Required 2

10/N PERSON NAME INDICATORS Required


- IK - INQUIRY FOR AKA DATA - (0224)

________________________________________














- IM - CDLIS SEARCH INQUIRY - (0225)

________________________________________

















- IN - VERIFICATION INQUIRY - (0226)

________________________________________












- IO - INQ PRECEDING CREATE NEW DRIVER - (0227)

________________________________________














- IW - EMPLOYER INQUIRY - (022A)

________________________________________















- NA - CDLIS POSSIBLE DUPLICATE - (0230)

________________________________________






09/7 DUPLICATE STATE/DLN/SSN from CDLIS Required


10/7 DUPLICATE DRIVER NAME/DESC - CDLIS Required



10/L PERSON DUPLICATE NAME Optional 2



- NE - CDLIS DUPLICATE RESOLVED - (0231)

________________________________________













- NF - CONFIRM CSOR IS COMPLETE - (0232)

________________________________________














- QC - # OF BATCH STATUS RESPONSES - (022C)

________________________________________









- QD - BATCH MPR DATA MATCH(ES) - (022D)

________________________________________






09/6 AKA STATE/DLN/SSN from CDLIS Optional 3


10/6 AKA DRIVER NAME - CDLIS Optional 3






- RC - # OF STATUS RESP FROM INQ TRANS - (0233)

________________________________________












- RD - MPR DATA MATCH(S) ON INQ TRANS - (0234)

________________________________________














- RK - NUMBER OF MPR RESP FROM INQUIRY - (024C)

________________________________________









- RQ - CDLIS BATCH RESPONSE CONTROL - (022G)

________________________________________













- RW - EMPLOYER INQUIRY RESPONSE (3RD) - (022B)

________________________________________















- RZ - MPR DATA FOR MATCH ON INQUIRY - (024E)

________________________________________







62/1 PERSON BLOCK Required


10/J PERSON NAME Required 2




- SB - DRIVER HISTORY REQUEST - (0237)

________________________________________















- SC - STATUS REQUEST - (0238)

________________________________________











- SD - CSOR HISTORY REQUEST - (0239)

________________________________________














- SG - STATE REQUEST FOR STATUS - (0240)

________________________________________






10/1 DRIVER NAME/DESCRIPTIVE DATA - SOI Optional









- SR - HISTORY REDRIVE - (024H)

________________________________________








10/K PERSON OLD NAME Required 2



- UA - ADD NEW DRIVER (SOR - CDLIS) - (0241)

________________________________________















- UC - CHANGE DATA (SOR - CDLIS) - (0242)

________________________________________










09/2 PRIMARY STATE/DLN/SSN SOR Optional


10/2 DRIVER NAME/DESCRIPTIVE DATA - SOR Optional









- UD - CHANGE STATE-of-RECORD - (0243)

________________________________________








10/2 DRIVER NAME/DESCRIPTIVE DATA - SOR Optional







- UE - DELETE MASTER POINTER RECORD - (0244)

________________________________________












- UG - MARK DRIVER UNIQUE - (0245)




________________________________________















- UK - UPDATE AKA (SOR - CDLIS) - (0246)

________________________________________
















APPENDIX C - DATA ELEMENTS BY BLOCK 579


APPENDIX C - DATA ELEMENTS BY BLOCK

Each AMIE block used in the system is described in detail below. A block description includes the block name, block

code and a list of all the application data elements. These physical block layouts sometimes include data elements that

are not used by this application. All data elements within a block are shown because this appendix describes the offset

of a data element within a block. A physical block is transmitted as 66 bytes. In all blocks (except for the NCB), the

first 5 bytes are reserved for addressing the block. This appendix shows the business data elements in bytes 6 through

66 (except for the NCB where all data elements are shown).

The description of a data element consists of:

Data Element Code Ŕ Six-character meaningful designation for the data element, used as a reference to the data

element in ŖAPPENDIX D - DATA DICTIONARYŗ

Data Element Name Ŕ Short descriptive term for the data element

Data Element Typ Ŕ alphanumeric type of the data element: AN=alpha-numeric, N=numeric

Data Element Leng Ŕ length of data element in bytes, i.e., ASCII characters

Data Element Occ Ŕ the code for the maximum number of times the data element occurs in the block. The first

(or only) occurrence of a data element has an OCC value of <blank>, the second occurrence has an OCC value

of 1, the third occurrence has an OCC value of 2, etc.)

Data Element Pos Ŕ the starting address of the data element within the logical block)

A data element may be a group or an elementary element. A group element will be made up of a group of elementary

elements. An elementary element may or may not be part of a group element. The code of elementary elements that

make up a group are offset to the right by 2 characters.

It is possible for a data element to occupy the same position in a block as another element. In other words, they redefine

the area used. In this appendix the second (and subsequent) element(s) is indicated with an '*R'.

The information contained in "APPENDIX A Ŕ DATA ELEMENTS BY MESSAGE TYPE" was extracted from

AAMVAřs Central Repository on January 22, 2010.

- NETWORK CONTROL BLOCK - (00/0)

________________________________________

DATA ELEMENT TYP LENG OCC POS

GTXNPR - TRANSACTION CODE AN 4 1

GMSLEN - MESSAGE LENGTH AN 4 5

GMSDST - MESSAGE DESTINATION AN 7 9

GMSGPI - GAP CODE USER NETWORK ID AN 3 9

- RESERVED AN 4 12

GMSORG - MESSAGE ORIGIN AN 7 16

GMSDAT - MESSAGE DATE AN 6 23

GMSTIM - MESSAGE TIME AN 6 29

GMSSEQ - MESSAGE SEQUENCE ID AN 4 35

GAPPID - APPLICATION ID AN 2 39

GMSTYP - MESSAGE TYPE AN 2 41

GSGSEQ - SEGMENT SEQUENCE NUMBER AN 2 43

GLSEGI - LAST SEGMENT INDICATOR AN 1 45

GNBTXT - NUMBER OF TEXT BLOCKS COUNT AN 2 46

R* GNBT9T - NUMBER OF TEXT BLOCKS COUNT N 2 46

GNETSI - NETWORK SESSION INDICATOR AN 1 48

GTPIND - TEST/PRODUCTION INDICATOR AN 1 49

GXMODC - TRANSMIT MODE CODE AN 1 50

GNCBER - NCB ERROR CODE AN 1 51

GTRORG - TRANSACTION ORIGINATOR AN 7 52

GNETST - NETWORK STATUS AN 2 59

GAPPST - APPLICATION STATUS AN 1 61




GMSRTA - NUMBER OF ROUTING ATTEMPTS AN 1 62

- RESERVED AN 4 63

- VERIFICATION BLOCK - (01/1)

________________________________________


GBKN01 - BLOCK NUMBER OF 1ST 01 BLOCK N 2 1


























- RESERVED AN 9 53

- CDLIS/DLR/PDPS MSG EXCHANGE CONTROL - (02/2)

________________________________________


GMSLOC - MESSAGE LOCATOR/HEADER AN 26 1

GMSCNT - MESSAGE MATCH COUNT AN 2 27

GMSIND - MESSAGE MATCH INDICATOR AN 1 29

GMSMSI - MESSAGE MATCH SEQUENCE ID AN 2 30

R* GMSFMS - MESSAGE FIRST MATCH SEQUENCE ID AN 2 30

R* DTNSSC - SELECTIVE SERVICE INTERNAL CODE AN 2 30

GPROST - PROCESSING STATUS AN 2 32

GMSLMI - LAST MATCH INDICATOR AN 1 34

R* GTRRST - TRANSACTION RESUBMISSION TYPE AN 1 34

GMSSOR - JURISDICTION CODE - STATE OF RECORD AN 2 35

GMSDRV - MESSAGE DRIVER DATA AN 23 37

GMSLEI - MESSAGE MATCH LIMIT EXCEEDED IND AN 1 37

GMSPSW - MESSAGE SENDER PASSWORD AN 7 38

GMSSCH - MESSAGE SOR CHANGE IN PROGRESS IND AN 1 45

GMSDUP - MESSAGE DRIVER DUPLICATE INDICATOR AN 1 46

GMSSYR - MESSAGE SEARCH YEAR RANGE AN 2 47

- RESERVED AN 3 49

GMSCDL - MESSAGE AKA DLN COUNT AN 1 52

R* GMSHBC - HME CHECK CURRENT SOR UP AN 1 52




GMSCSS - MESSAGE AKA SSN COUNT AN 1 53

R* GMSHBO - HME CHECK OLD SOR DOWN AN 1 53

GMSCNM - MESSAGE AKA NAME COUNT AN 1 54

- RESERVED AN 1 55

GMSDEL - MESSAGE DELAYED SEARCH IND AN 1 56

GMSNMI - MESSAGE NUMBER OF SEARCH NAMES AN 1 57

GMSNMN - MESSAGE NUMBER OF UPDATE NAMES AN 1 58

GMSVRC - SSA VERIFICATION RESPONSE CODE AN 1 59

R* GRCDDT - DRIVER DATA RECORD TYPE AN 1 59

R* IMGGRP - Image Group AN 23 37

- RESERVED AN 6 37

GDIRQT - IMAGE REQUEST TYPE AN 1 43

GMSMSZ - MESSAGE MAXIMUM SIZE AN 1 44

GDIDST - IMAGE DESTINATION AN 7 45

- RESERVED AN 3 52

GDIERS - EXPECTED IMAGE RESPONSE INDICATOR AN 1 55

GDIRQN - NUMBER OF IMAGES REQUESTED AN 2 56

R* GDINST - NUMBER OF IMAGES SENT AN 2 56

GDIPST - IMAGE PROCESSING STATUS AN 2 58

R* BATGRP - Batch Group AN 23 37

GMSCN4 - MESSAGE MATCH COUNT AN 4 37

GMSMS4 - MESSAGE MATCH SEQUENCE ID AN 4 41

GMSBID - BATCH IDENTIFIER AN 15 45

GMSSRL - SYSTEM RELEASE CODE AN 1 60

DEDELG - ELIGIBILITY INDICATOR AN 1 61

- OLD PRIMARY ST DLN/SSN BLOCK - (04/1)

________________________________________


DDLJD1 - DL OLD JURISDICTION NUMBER AN 27 1

DDLJU5 - OLD JURISDICTION CODE - LICENSING AN 2 1

DDLNU4 - OLD DRIVER LICENSE NUMBER AN 25 3

DDVSS1 - DRIVERS OLD SOCIAL SECURITY NUMBER AN 9 28

- RESERVED AN 25 37

- OLD PRIMARY NAME/DESCRIPTION BLOCK - (04/2)

________________________________________


DDVNM1 - DRIVER OLD NAME AN 35 1

DDVDO1 - DRIVER OLD DATE OF BIRTH AN 8 36

- RESERVED AN 18 44

- PRIMARY STATE/DLN/SSN SOI - (09/1)

________________________________________


DDLJDL - DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU1 - DL CURRENT JURISDICTION CODE AN 2 1

R* DDLJUR - JURISDICTION CODE - LICENSING AN 2 1

DDLNUM - DRIVER LICENSE NUMBER AN 25 3

R* DDLNU7 - DRIVER LICENSE NUMBER AN 25 3

R* DDLJD6 - DL CURRENT JURISDICTION NUMBER AN 27 1





DDLNU6 - DRIVER LICENSE CURRENT NUMBER AN 25 3

DDVSS6 - DRIVER SSN - CDLIS AN 9 28

R* DDVSS3 - DRIVERS CURRENT SSN AN 9 28

R* DDVSSN - DRIVER SOCIAL SECURITY NUMBER AN 9 28

R* SSNGRP - SSN Group AN 9 28

DDVSFT - DRIVER SSN - FIRST THREE DIGITS AN 3 28

DDVSMT - DRIVER SSN - MIDDLE TWO DIGITS AN 2 31

DDVSLF - DRIVER SSN - LAST FOUR DIGITS AN 4 33

BJDTYP - STATE DOCUMENT TYPE AN 1 37

- RESERVED AN 24 38

- PRIMARY STATE/DLN/SSN SOR - (09/2)

________________________________________




R* DDLJUR - JURISDICTION CODE - LICENSING AN 2 1


R* DDLNU7 - DRIVER LICENSE NUMBER AN 25 3

R* DDLNU0 - DRIVER LICENSE NUMBER START RANGE AN 25 3


R* DDVSS4 - DRIVER SOCIAL SECURITY NUMBER AN 9 28

R* DDVSS5 - DRIVER SOCIAL SECURITY NUMBER AN 9 28

R* DDVSSN - DRIVER SOCIAL SECURITY NUMBER AN 9 28

R* DDVSS0 - DRIVER SSN START RANGE AN 9 28

BJDTYP - STATE DOCUMENT TYPE AN 1 37

- RESERVED AN 24 38

- PRIMARY STATE/DLN/SSN from CDLIS - (09/4)

________________________________________






- RESERVED AN 25 37

- AKA STATE/DLN/SSN from SOR - (09/5)

________________________________________


DDLJD2 - AKA DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU2 - AKA JURISDICTION CODE - LICENSING AN 2 1

DDLNU1 - AKA DRIVER LICENSE NUMBER AN 25 3

R* DDLJD3 - AKA 2ND DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU3 - AKA 2ND JURISDICTION CODE-LICENSING AN 2 1

DDLNU2 - AKA 2ND DRIVER LICENSE NUMBER AN 25 3

R* DDLJD4 - AKA 3RD DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU4 - AKA 3RD JURISDICTION CODE-LICENSING AN 2 1

DDLNU3 - AKA 3RD DRIVER LICENSE NUMBER AN 25 3

DDVKSS - DRIVER AKA SOCIAL SECURITY NUMBER AN 9 28

- RESERVED AN 25 37




- AKA STATE/DLN/SSN from CDLIS - (09/6)

________________________________________


DDLJD2 - AKA DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU2 - AKA JURISDICTION CODE - LICENSING AN 2 1

DDLNU1 - AKA DRIVER LICENSE NUMBER AN 25 3

R* DDLJD3 - AKA 2ND DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU3 - AKA 2ND JURISDICTION CODE-LICENSING AN 2 1

DDLNU2 - AKA 2ND DRIVER LICENSE NUMBER AN 25 3

R* DDLJD4 - AKA 3RD DRIVER LICENSE JURIS NUMBER AN 27 1

DDLJU4 - AKA 3RD JURISDICTION CODE-LICENSING AN 2 1

DDLNU3 - AKA 3RD DRIVER LICENSE NUMBER AN 25 3

DDVKSS - DRIVER AKA SOCIAL SECURITY NUMBER AN 9 28

- RESERVED AN 25 37

- DUPLICATE STATE/DLN/SSN from CDLIS - (09/7)

________________________________________


DDLJD5 - DL DUPLICATE JURISDICTION NUMBER AN 27 1

DDLJU6 - DUPLICATE LICENSING JURIS CODE AN 2 1

DDLNU5 - DUPLICATE DRIVER LICENSE NUMBER AN 25 3

R* DDLNU9 - DRIVER LICENSE NUMBER END RANGE AN 25 3

DDVSS2 - DRIVERS DUPLICATE SSN AN 9 28

R* DDVSS9 - DRIVER SSN END RANGE AN 9 28

- RESERVED AN 25 37

- DRIVER NAME/DESCRIPTIVE DATA - SOI - (10/1)

________________________________________


DDVNAM - DRIVER NAME AN 35 1

R* DDVKNM - DRIVER AKA NAME AN 35 1

R* DDVKN2 - DRIVER AKA 2ND NAME AN 35 1

R* DDVKN3 - DRIVER AKA 3RD NAME AN 35 1

R* DDVNM2 - DRIVER CURRENT NAME AN 35 1

R* DDVNM4 - SSA DRIVER NAME AN 35 1

R* DDVKN4 - DRIVER AKA NAME - PDPS AN 35 1

R* DDVKN5 - DRIVER AKA 2ND NAME - PDPS AN 35 1

R* DDVKN6 - DRIVER AKA 3RD NAME - PDPS AN 35 1

DDVDOB - DRIVER DATE OF BIRTH AN 8 36

R* DDVKDB - DRIVER AKA DATE OF BIRTH AN 8 36

R* DDVKD2 - DRIVER AKA 2ND DATE OF BIRTH AN 8 36

R* DDVKD3 - DRIVER AKA 3RD DATE OF BIRTH AN 8 36

R* DDVDO3 - DRIVER CURRENT DATE OF BIRTH AN 8 36

R* DDVKD4 - DRIVER AKA DATE OF BIRTH - PDPS AN 8 36

R* DDVKD5 - DRIVER AKA 2ND DATE OF BIRTH - PDPS AN 8 36

R* DDVKD6 - DRIVER AKA 3RD DATE OF BIRTH - PDPS AN 8 36

DDVDSC - DRIVER DESCRIPTIVE INFORMATION AN 18 44

- RESERVED AN 8 44

DDVSEX - DRIVER SEX AN 1 52

R* DDVSX1 - DRIVER SEX - PDPS AN 1 52

R* DDVSX3 - DRIVER CURRENT SEX AN 1 52

DDVHGT - DRIVER HEIGHT AN 3 53




DDVHG1 - DRIVER HEIGHT - FEET AN 1 53

DDVHG2 - DRIVER HEIGHT - PLUS INCHES AN 2 54

R* DDVHT1 - DRIVER HEIGHT - PDPS AN 2 53

R* DDVHT3 - DRIVER CURRENT HEIGHT AN 2 53

DDVWGT - DRIVER WEIGHT AN 3 55

R* DDVWT1 - DRIVER WEIGHT - PDPS AN 3 55

R* DDVWT3 - DRIVER CURRENT WEIGHT AN 3 55

DDVEYE - DRIVER EYE COLOR AN 3 58

R* DDVEY1 - DRIVER EYE COLOR - PDPS AN 3 58

R* DDVEY3 - DRIVER CURRENT EYE COLOR AN 3 58

- DRIVER NAME/DESCRIPTIVE DATA - SOR - (10/2)

________________________________________





- RESERVED AN 8 44


DDVSX3 - DRIVER CURRENT SEX AN 1 52


DDVHT3 - DRIVER CURRENT HEIGHT AN 3 53




DDVWT3 - DRIVER CURRENT WEIGHT AN 3 56


DDVEY3 - DRIVER CURRENT EYE COLOR AN 3 59

- DRIVER NAME/DESCRIPTIVE DATA - CDLIS - (10/4)

________________________________________





- RESERVED AN 8 44











- AKA DRIVER NAME - SOR - (10/5)

________________________________________


DDVKNM - DRIVER AKA NAME AN 35 1






DDVKDB - DRIVER AKA DATE OF BIRTH AN 8 36



- RESERVED AN 18 44

- AKA DRIVER NAME - CDLIS - (10/6)

________________________________________








- RESERVED AN 18 44

- DUPLICATE DRIVER NAME/DESC - CDLIS - (10/7)

________________________________________


DDVNM3 - DRIVER DUPLICATE NAME AN 35 1

DDVDO2 - DRIVER DUPLICATE DATE OF BIRTH AN 8 36

DDVDS2 - DRIVER DESCRIPTIVE INFO - DUPLICATE AN 18 44

- RESERVED AN 8 44

DDVSX2 - DRIVER DUPLICATE SEX AN 1 52


DDVHT2 - DRIVER DUPLICATE HEIGHT AN 3 53




DDVWT4 - DRIVER DUPLICATE WEIGHT AN 3 56


DDVEY2 - DRIVER DUPLICATE EYE COLOR AN 3 59


- AKA DRIVER NAME - SOI - (10/8)

________________________________________








- RESERVED AN 18 44

- INDIVIDUAL/EMPLOYEE MAILING ADDRESS - (11/1)

________________________________________





ADDRG1 - ADDRESS GROUP 1 AN 122 1

VPOADD - INDIVIDUAL ADDRESS AN 108 1

R* ADDRG2 - ADDRESS GROUP 2 AN 108 1

DDVAD2 - DRIVER MAILING ADDRESS AN 71 1

DDVADD - DRIVER MAILING ADDRESS AN 71 1

- RESERVED AN 37 72

- RESERVED AN 11 109

DDVMCY - DRIVER MAILING ADDRESS COUNTY AN 3 120

R* DDVAD1 - DRIVER MAILING ADDRESS - PDPS AN 122 1

DDVAD3 - DRIVER MAILING ADDRESS BLK - PDPS AN 61 1

DDVAD3 - DRIVER MAILING ADDRESS BLK - PDPS AN 61 1 62

- INDIVIDUAL/EMPLOYEE HOME ADDRESS - (11/5)

________________________________________


DDVRAD - DRIVER RESIDENCE ADDRESS AN 71 1

- DRIVER HISTORY BLOCK - (14/1)

________________________________________


DDLNMP - DRV LIC NUMBER OF PERMITS AN 1 1

DDLCL2 - DL COMMERCIAL CLASS CODE AN 3 2

R* DDLCL1 - DRIVER LICENSE CLASSIFICATION CODE AN 3 2

DDLCL3 - DL NON-COMMERCIAL CLASS CODE AN 3 5

DDLEND - DRIVER LICENSE ENDORSEMENT CODE AN 1 8

DDLEND - DRIVER LICENSE ENDORSEMENT CODE AN 1 1 9




DDLISS - DRIVER LICENSE ISSUE DATE AN 8 13

DDLEXP - DRIVER LICENSE EXPIRATION DATE AN 8 21

DDLNTS - DRV LIC NON-COMMERCIAL STATUS AN 3 29

DDLCTS - DRIVER LICENSE COMMERCIAL STATUS AN 3 32

DDLWDP - DL PRIVILEGE TYPE W/D ACTION PENDING AN 1 35

DDLNMR - NUMBER OF DRV LIC RESTRICTIONS AN 2 36

DDVMED - DRIVER MEDICAL HISTORY INDICATOR AN 1 38

DDTTCS - TOTAL CONVICTIONS SENT AN 2 39

DDTTCR - TOTAL ACD CONVICTIONS ON RECORD AN 2 41

DDTTAS - TOTAL ACCIDENTS SENT AN 2 43

DDTTAR - TOTAL ACCIDENTS ON RECORD AN 2 45

DDTTWS - TOTAL WITHDRAWALS SENT AN 2 47

DDTTWR - TOTAL WITHDRAWALS ON RECORD AN 2 49

DDVCPI - DRIVER HISTORY POINTER INDICATOR AN 1 51

DDTTLS - TOTAL WITHDRAWAL-CONV LINKS SENT AN 2 52

DDTTLR - TOTAL WITHDR-CONV LINKS ON RECORD AN 2 54

DDTTMS - TOTAL COMMENTS SENT AN 1 56

DDLLEI - DL EXTENSION INDICATOR AN 1 57

- RESERVED AN 4 58

- DRIVER HISTORY CHECKS BLOCK - (14/2)

________________________________________





DDLHCI - DL HISTORY CHECK INQUIRING JURIS AN 2 1

DDLHCD - DL HISTORY CHECK DATE AN 8 3

DDLHCT - DL HISTORY CHECK RESPONSE TOTAL AN 2 11

DDLHCL - DL HISTORY CHECK RESPONSE LIST AN 30 13

DDLHCJ - DL HISTORY CHECK RESPONDING STATE AN 2 13

DDLHCJ - DL HISTORY CHECK RESPONDING STATE AN 2 1 15














DDLHCR - DL HISTORY CHECK REQUEST TOTAL AN 2 43

- RESERVED AN 17 45

- DRIVER HME BLOCK - (14/3)

________________________________________


DDLHED - DL HAZMAT ENDORSEMENT EXP DATE AN 8 1

DTHTSD - DRIVER TSA HME THREAT DETERMINATION AN 1 9

DTHTDD - DRIVER TSA HME THREAT DETERM DATE AN 8 10

DTHADT - DRIVER TSA HAZMAT APPLICATION DATE AN 8 18

DTHIDC - DRIVER CONVICTION IN PAST 7 YEARS AN 1 26

DTHRDC - DRIVER INCARCERATED IN PAST 5 YEARS AN 1 27

DTHWDC - DRIVER HAZMAT UNDER INDICTMENT AN 1 28

DTHPDC - DRIVER PERMANENT DISQUALIFYING CRIME AN 1 29

DTHMDC - DRIVER MENTAL STANDING AN 1 30

DTHIES - DRIVER IMMIGRATION ELIGIBILITY AN 1 31

- RESERVED AN 30 32

- DRIVER MEDICAL CERTIFICATE - (14/5)

________________________________________


DDLSCT - CDL MEDICAL SELF CERTIFICATION CODE AN 2 1

DDLCEC - DL CLAIM MEDICAL CERT EXCEPTED CODE AN 1 1

DDLCIC - DL CLAIM OF AREA FOR MED CERT CODE AN 1 2

DMCPED - MEDICAL CERTIFICATE ISSUE DATE AN 8 3

DMCEDT - MEDICAL CERTIFICATE EXPIRATION DATE AN 8 11

DMCCTC - MEDICAL CERTIFICATION STATUS CODE AN 1 19

DDLSED - DRIVER SPE EXPIRATION DATE AN 8 20

DDLWED - DRIVER WAIVER/EXEMPT EXPIRATION DATE AN 8 28

DDLSSD - DRIVER SPE EFFECTIVE DATE AN 8 36

DDLWSD - DRIVER WAIVER/EXEMPT EFFECTIVE DATE AN 8 44

DMCRES - MEDICAL CERTIFICATE RESTRICTION CODE AN 1 52

DMCRES - MEDICAL CERTIFICATE RESTRICTION CODE AN 1 1 53












- DRIVER PERMIT INFORMATION BLOCK - (15/1)

________________________________________


DDLPC2 - DRVER PERMIT COMMERCIAL CLASS CODE AN 6 1

DDLPCL - DRVER PERMIT COMMERCIAL CLASS CODE AN 1 1

- RESERVED AN 5 2

DDLEP1 - DL PERMIT ENDORSEMENT GROUP CODE AN 5 7

DDLPID - DRV LIC PERMIT ISSUE DATE AN 8 12

DDLPED - DRV LIC PERMIT EXPIRATION DATE AN 8 20

DDLPST - DRV LIC PERMIT STATUS AN 3 28

DDLRPN - DL NUMBER OF PERMIT RESTRICTIONS AN 2 31

DDLPMT - DRV LIC PERMIT IDENTIFIER AN 4 33

- RESERVED AN 25 37

- DRIVER RESTRICTION/LICENSE - (16/1)

________________________________________


DDLRSC - DRIVER LICENSE RESTRICTION CODE AN 1 1

DDLRSD - DRIVER LICENSE RESTRICTION END DATE AN 8 2

DDLRSE - DL RESTRICTION EXPLANATION AN 40 10

- RESERVED AN 12 50

- DRIVER RESTRICTION/PERMIT #1 - (16/2)

________________________________________


DDLRP1 - DRV LIC 1ST PERMIT RESTRICT CODE AN 1 1

DDLPD1 - DRV LIC 1ST PERMIT RESTRICT END DATE N 8 2

DDLPE1 - DL 1ST PERMIT RESTRICT EXPLANATION AN 40 10

- RESERVED AN 12 50


________________________________________


DDLRP2 - DRV LIC 2ND PERMIT RESTRICT CODE AN 1 1

DDLPD2 - DRV LIC 2ND PERMIT RESTRICT END DATE N 8 2

DDLPE2 - DL 2ND PERMIT RESTRICT EXPLANATION AN 40 10

- RESERVED AN 12 50


________________________________________





DDLRP3 - DRV LIC 3RD PERMIT RESTRICT CODE AN 1 1

DDLPD3 - DRV LIC 3RD PERMIT RESTRICT END DATE N 8 2

DDLPE3 - DL 3RD PERMIT RESTRICT EXPLANATION AN 40 10

- RESERVED AN 12 50

- DRIVER CONVICTION BLOCK - (17/1)

________________________________________


DCVJUR - JURISDICTION CODE - CONVICTING AN 2 1

DCIDCI - CITATION DATE AN 8 3

DCVCID - CONVICTION ID CODE AN 2 11

DCVPTS - CONVICTION POINTS CODE AN 1 13

DCVDCV - CONVICTION DATE AN 8 14

DCVCRT - CONVICTION COURT TYPE AN 3 22

DCVCOM - CONVICTION COMMERCIAL VEH IND AN 1 25

DCVHAZ - CONVICTION HAZMAT IND AN 1 26

DCVCLO - CONVICTION JURIS COURT REPORT ID AN 18 27

DCVCOR - CONVICTION JURISDICTION OFFENSE CODE AN 8 45

DCVCCA - CONVICTION OFFENSE ACD CODE AN 3 53

DCVCDA - CONVICTION OFFENSE DETAIL - ACD AN 5 56

DCVCD1 - CONVICTION OFFENSE DETAIL - ACD N 5 56

DCICHI - CITATION CDL HOLDER INDICATOR AN 1 61

- DRIVER CONVICTION (REPORT OOSW) - (17/4)

________________________________________


DCVJU3 - JURISDICTION CODE - CONVICTING, OOSW AN 2 1

DCIDC3 - CITATION DATE (OOSW) AN 8 3

- RESERVED AN 3 11

DCVDC3 - CONVICTION DATE (OOSW) AN 8 14

DCVCR3 - CONVICTION COURT TYPE (OOSW) AN 3 22

DCVCO4 - CONVICTION COMMERCIAL VEH IND (OOSW) AN 1 25

DCVHA3 - CONVICTION HAZMAT IND (OOSW) AN 1 26

DCVCL3 - CONVICTION JURIS CRT REPORT ID, OOSW AN 18 27

DCVCO5 - CONVICTION JURIS OFFENSE CD (OOSW) AN 8 45

DCVCC3 - CONVICTION OFFENSE ACD CODE (OOSW) AN 3 53

DCVCD4 - CONVICTION OFFENSE DET - ACD (OOSW) AN 5 56

- RESERVED AN 1 61

- DRIVER ACCIDENT BLOCK - (18/1)

________________________________________


DACJUR - ACCIDENT JURISDICTION CODE AN 2 1

DACDAT - ACCIDENT DATE AN 8 3

DACSEV - ACCIDENT SEVERITY CODE AN 1 11

DDACOM - DRIVER ACCIDENT COMMERCIAL VEH IND AN 1 12

DDAHAZ - DRIVER ACCIDENT HAZMAT IND AN 1 13

DACLOC - ACCIDENT LOCATOR REFERENCE AN 18 14

- RESERVED AN 30 32




- DRIVER WITHDRAWAL BLOCK - (19/1)

________________________________________


DWDJUR - JURISDICTION CODE - WITHDRAWING AN 2 1

DWDDWD - DRV LIC WITHDRAWAL EFFECTIVE DATE AN 8 3

DWDWDT - DRIVER LIC W/D TYPE-OBSOLETE FOR ACD AN 3 11

R* DWDWTD - DRIVER LIC WITHDRAWAL TYPE DETAIL N 3 11

R* DWDWT2 - DRIVER LIC WITHDRAWAL TYPE DETAIL AN 3 11

DWDWTP - DRIVER LICENSE WITHDRAWAL TYPE AN 1 11

R* DWDATP - DRIVER LICENSE ACTION TYPE AN 1 11

DWDWBS - DRIVER LICENSE WITHDRAWAL BASIS AN 1 12

DWDWPS - DL WITHDRAWAL DUE PROCESS STATUS AN 1 13

DWDWRS - DRV LIC ACD WITHDRAWAL REASON CODE AN 3 14

DWDWDE - DRV LIC WITHDRAWAL ELIGIBILITY DATE AN 8 17

DWDWDR - DL WITHDRAWAL REINSTATEMENT DATE N 8 25

DWDWEX - DRV LIC WITHDRAWAL EXTENT ID - DLC AN 1 33

R* DWDWE1 - DRV LIC WITHDRAWAL EXTENT ID AN 1 33

DWDWLO - DL WITHDRAWAL JURISDICTION REPORT ID AN 18 34

DWDWRR - DRV LIC WITHDRAWAL REASON REFERENCE AN 8 52

DWDWID - DRIVER LICENSE WITHDRAWAL ID CODE AN 2 60

- DRIVER WITHDRAWAL CONVICTION BLOCK - (19/3)

________________________________________


DWDWI2 - DL WITHDRAWAL ID - CONVICTION LINK AN 2 1

DWDCLG - DL WITHDRAWAL CONVICTIONS LINKS GRP AN 28 3

DCVCI2 - CONVICTION ID CODE, LINKED TO WITHDR AN 2 3

DCVCI2 - CONVICTION ID CODE, LINKED TO WITHDR AN 2 1 5













- RESERVED AN 31 31

- STATE OF RECORD LIST BLOCK - (20/1)

________________________________________


BJUCD2 - STATES OF RECORD AN 30 1

BJUCD1 - STATE OF RECORD AN 2 1

BJUCD1 - STATE OF RECORD AN 2 1 3

















- RESERVED AN 31 31

- BATCH FILE CONTROL DATES - (23/3)

________________________________________


DDBISD - BATCH INQUIRY FILE SENT DATE AN 8 1

DDBIRD - BATCH FILE RECEPTION DATE AN 8 9

DDBFPD - BATCH FILE PROCESSING DATE AN 8 17

DDBRSD - BATCH RESPONSE FILE SENT DATE AN 8 25

GRCAOD - RECORD AS OF DATE AN 8 33

GRCAOT - RECORD AS OF TIME AN 6 41

- RESERVED AN 15 47

- BATCH FILE CONTROL COUNTS - (23/4)

________________________________________


DDBST1 - BATCH INQUIRY MESSAGES SENT AN 6 1

DDBNR1 - COUNT OF MESSAGES PROCESSED AN 6 7

DDBNP1 - BATCH INQUIRIES PROCESSED AN 6 13

DDBNE1 - BATCH INQUIRIES RETURNED IN ERROR AN 6 19

DDBNR2 - COUNT OF SUCCESSFUL MATCHES AN 6 25

DDVCNT - DRIVER COUNT AN 9 31

GRCCNT - RECORD COUNT AN 10 40

- RESERVED AN 12 50

- RETURN AS RECEIVED - (24/3)

________________________________________


GRRECV - RETURN AS RECEIVED TEXT/BLOCK AN 61 1

- EDIT/ERROR DESCRIPTION BLOCK - (25/1)

________________________________________


GEROUT - ERROR BLOCK OUT AN 61 1

GERELN - ERROR ELEMENT NUMBER - CDLIS AN 4 1

R* GEREL9 - ERROR ELEMENT NUMBER N 4 1

- RESERVED AN 1 5

GERCDO - ERROR CODE OUT AN 2 6




R* GERCD9 - ERROR CODE OUT N 2 6

GERMSO - ERROR MESSAGE OUT AN 54 8

R* GERPDP - ERROR BLOCK PDPS AN 61 1

GERBTY - ERROR BLOCK TYPE AN 2 1

GERBST - ERROR BLOCK SUBTYPE AN 1 3

GERLIN - ERROR BLOCK LINE NUMBER AN 2 4

GERCOD - ERROR CODE AN 2 6

GERMSG - ERROR MESSAGE AN 54 8

R* GERUEB - UNI ERROR BLOCK AN 61 1

GERUEC - UNI ERROR CODE AN 4 1

GERUCD - UNI ERROR INDICATOR AN 1 5

GERU2C - UNI ERROR CODE LAST 2 CHARACTERS AN 2 6

GERUET - UNI ERROR MESSAGE TEXT AN 54 8

- PERSON BLOCK - (62/1)

________________________________________


BPEDOB - PERSON DATE OF BIRTH AN 8 1

BPEBIY - PERSON BIRTH YEAR AN 4 1

- RESERVED AN 4 5

BPESTA - STATUS OF PERSON AN 1 9

- RESERVED AN 52 10

- MEDICAL EXAMINER - (62/2)

________________________________________


BMPJOL - MEDICAL LICENSING JURISDICTION CODE AN 2 1

R* BMPJO1 - MEDICAL LICENSING JURISDICTION CODE AN 2 1

BMPLIN - MEDICAL PRACTITIONER LICENSE NUMBER AN 14 3

R* BMPLI1 - MEDICAL EXAMINER LICENSE NUMBER AN 14 3

BMPTPN - MEDICAL PRACTITIONER TELEPHONE NUM AN 10 17

R* BMPTP1 - MEDICAL EXAMINER TELEPHONE NUMBER AN 10 17

BMPNRN - MEDICAL EXAMINER REGISTRY NUMBER AN 15 27

BMPSPC - MEDICAL PRACTITIONER SPECIALTY CODE AN 2 42

R* BMPSP1 - MEDICAL EXAMINER SPECIALTY CODE AN 2 42

- RESERVED AN 12 44

BMPTFI - MP FIRST NAME TRUNCATION IND AN 1 56

R* BMPTF1 - ME FIRST NAME TRUNCATION IND AN 1 56

BMPTMI - MP MIDDLE NAME TRUNCATION IND AN 1 57

R* BMPTM1 - ME MIDDLE NAME TRUNCATION IND AN 1 57

BMPTLI - MP LAST NAME TRUNCATION IND AN 1 58

R* BMPTL1 - ME LAST NAME TRUNCATION IND AN 1 58

BMPLFI - MP FIRST NAME TRANSLITERATION IND AN 1 59

R* BMPLF1 - ME FIRST NAME TRANSLITERATION IND AN 1 59

BMPLMI - MP MIDDLE NAME TRANSLITERATION IND AN 1 60

R* BMPLM1 - ME MIDDLE NAME TRANSLITERATION IND AN 1 60

BMPLLI - MP LAST NAME TRANSLITERATION IND AN 1 61

R* BMPLL1 - ME LAST NAME TRANSLITERATION IND AN 1 61

- MEDICAL EXAMINER NAME - (62/3)

________________________________________





BMPNLN - MEDICAL PRACTITIONER LAST NAME AN 40 1

R* BMPNL1 - MEDICAL EXAMINER LAST NAME AN 40 1

BMPNFN - MEDICAL PRACTITIONER FIRST NAME AN 40 41

R* BMPNF1 - MEDICAL EXAMINER FIRST NAME AN 40 41

BMPNMN - MEDICAL PRACTITIONER MIDDLE NAME AN 35 81

R* BMPNM1 - MEDICAL EXAMINER MIDDLE NAME AN 35 81

BMPNSN - MEDICAL PRACTITIONER NAME SUFFIX AN 5 116

R* BMPNS1 - MEDICAL EXAMINER NAME SUFFIX AN 5 116

- RESERVED AN 2 121

- DRIVER NAME / DESCRIPTIVE BLOCK - (10/A)

________________________________________


DDVNM2 - DRIVER CURRENT NAME AN 35 1


DDVDO3 - DRIVER CURRENT DATE OF BIRTH AN 8 36


R* GRPAGE - Age Group AN 8 36

DDVAGE - DRIVER AGE AN 3 36

- RESERVED AN 5 39











DDVRAC - DRIVER RACE/ETHNICITY AN 3 54

DDVHCL - DRIVER HAIR COLOR AN 3 57

BPESXO - SEX OFFENDER REGISTRATION FLAG AN 1 60

- RESERVED AN 1 61

- PERSON NAME - (10/J)

________________________________________


BPENLT - PERSON LAST NAME AN 40 1

BPENFT - PERSON FIRST NAME AN 40 41

BPENMD - PERSON MIDDLE NAME AN 35 81

BPENSX - PERSON NAME SUFFIX AN 5 116

- RESERVED AN 2 121

- PERSON OLD NAME - (10/K)

________________________________________


BPENL1 - PERSON OLD LAST NAME AN 40 1

BPENF1 - PERSON OLD FIRST NAME AN 40 41

BPENM1 - PERSON OLD MIDDLE NAME AN 35 81

BPENS1 - DRIVER OLD NAME SUFFIX AN 5 116

- RESERVED AN 2 121




- PERSON DUPLICATE NAME - (10/L)

________________________________________


BPENL2 - PERSON DUPLICATE LAST NAME AN 40 1

BPENF2 - PERSON DUPLICATE FIRST NAME AN 40 41

BPENM2 - PERSON DUPLICATE MIDDLE NAME AN 35 81

BPENS2 - DRIVER DUPLICATE NAME SUFFIX AN 5 116

- RESERVED AN 2 121

- PERSON AKA NAME - (10/M)

________________________________________


GRPNAM - Name Group AN 120 1

GRPNAM - Name Group AN 120 1 121

GRPNAM - Name Group AN 120 2 241

BPENL3 - PERSON AKA LAST NAME AN 40 1

BPENL3 - PERSON AKA LAST NAME AN 40 1 121

BPENL3 - PERSON AKA LAST NAME AN 40 2 241

BPENF3 - PERSON AKA FIRST NAME AN 40 41

BPENF3 - PERSON AKA FIRST NAME AN 40 1 161

BPENF3 - PERSON AKA FIRST NAME AN 40 2 281

BPENM3 - PERSON AKA MIDDLE NAME AN 35 81

BPENM3 - PERSON AKA MIDDLE NAME AN 35 1 201

BPENM3 - PERSON AKA MIDDLE NAME AN 35 2 321

BPENS3 - DRIVER AKA NAME SUFFIX AN 5 116

BPENS3 - DRIVER AKA NAME SUFFIX AN 5 1 236

BPENS3 - DRIVER AKA NAME SUFFIX AN 5 2 356

- RESERVED AN 6 361

- PERSON NAME INDICATORS - (10/N)

________________________________________


BPENTF - PERSON FIRST NAME TRUNCATION CODE AN 1 1

BPENTM - PERSON MIDDLE NAME TRUNCATION CODE AN 1 2

BPENTL - PERSON LAST NAME TRUNCATION CODE AN 1 3

BPENRF - PERSON FIRST NAME TRANSLITERATION AN 1 4

BPENRM - PERSON MIDDLE NAME TRANSLITERATION AN 1 5

BPENRL - PERSON LAST NAME TRANSLITERATION AN 1 6

BPETF1 - PERSON OLD FIRST NAME TRUNCATION AN 1 7

BPETM1 - PERSON OLD MIDDLE NAME TRUNCATION AN 1 8

BPETL1 - PERSON OLD LAST NAME TRUNCATION CODE AN 1 9

BPERF1 - PERSON OLD FIRST NAME TRANSLIT CODE AN 1 10

BPERM1 - PERSON OLD MIDDLE NAME TRANSLIT CODE AN 1 11

BPERL1 - PERSON OLD LAST NAME TRANSLIT AN 1 12

BPETF2 - PERSON DUP FIRST NAME TRUNCATION AN 1 13

BPETM2 - PERSON DUP MIDDLE NAME TRUNCATION AN 1 14

BPETL2 - PERSON DUP LAST NAME TRUNCATION CODE AN 1 15

BPERF2 - PERSON DUP FIRST NAME TRANSLIT CODE AN 1 16

BPERM2 - PERSON DUP MIDDLE NAME TRANSLIT CODE AN 1 17

BPERL2 - PERSON DUP LAST NAME TRANSLIT AN 1 18

AKAGRP - AKA Indicator Group AN 6 19




AKAGRP - AKA Indicator Group AN 6 1 25

AKAGRP - AKA Indicator Group AN 6 2 31

BPETF3 - PERSON AKA FIRST NAME TRUNCATION AN 1 19

BPETF3 - PERSON AKA FIRST NAME TRUNCATION AN 1 1 25

BPETF3 - PERSON AKA FIRST NAME TRUNCATION AN 1 2 31

BPETM3 - PERSON AKA MIDDLE NAME TRUNCATION AN 1 20

BPETM3 - PERSON AKA MIDDLE NAME TRUNCATION AN 1 1 26

BPETM3 - PERSON AKA MIDDLE NAME TRUNCATION AN 1 2 32

BPETL3 - PERSON AKA LAST NAME TRUNCATION CODE AN 1 21

BPETL3 - PERSON AKA LAST NAME TRUNCATION CODE AN 1 1 27

BPETL3 - PERSON AKA LAST NAME TRUNCATION CODE AN 1 2 33

BPERF3 - PERSON AKA FIRST NAME TRANSLIT CODE AN 1 22

BPERF3 - PERSON AKA FIRST NAME TRANSLIT CODE AN 1 1 28

BPERF3 - PERSON AKA FIRST NAME TRANSLIT CODE AN 1 2 34

BPERM3 - PERSON AKA MIDDLE NAME TRANSLIT CODE AN 1 23

BPERM3 - PERSON AKA MIDDLE NAME TRANSLIT CODE AN 1 1 29

BPERM3 - PERSON AKA MIDDLE NAME TRANSLIT CODE AN 1 2 35

BPERL3 - PERSON AKA LAST NAME TRANSLIT AN 1 24

BPERL3 - PERSON AKA LAST NAME TRANSLIT AN 1 1 30

BPERL3 - PERSON AKA LAST NAME TRANSLIT AN 1 2 36

- RESERVED AN 25 37


APPENDIX D - DATA DICTIONARY 596


APPENDIX D - DATA DICTIONARY

This appendix has three parts: the data element dictionary; the naming rules for the data element for DRIVER NAME

and associated data elements; and scenarios for assigning Conviction IDs and Withdrawal IDs in a driver history

response.

APPENDIX D.1 - DATA ELEMENTS

The following table describes all the data elements used in CDLIS. The table includes the following information:

Element Code Ŕ the 6-character alphanumeric meaningful identifier for the data element.

Business Name Ŕ the descriptive, identifying term for the data element.

Call List Name Ŕ the identifier used in the UNI call list for the data element.

Type Ŕ the data format for the element, either alphanumeric or numeric.

Length Ŕ the number of bytes (characters) used in the message for the value of the data element.

Description Ŕ a short explanation or definition of the data element.

Values Ŕ the allowable values or data filling rules for the data element.

When the specification references elements, the data element code is listed. This table is listed in element code order to

allow for easy reference.

The information contained in Appendix D was extracted from AAMVAřs Central Repository on January 22, 2010.

Element

Code

Business & Call List Names Type

/Len

Description & Values

BJUAFN AUTHORIZED FUNCTION CODE

NONE

AN

2 The Authorized Function Code identifies a

given function within the system.

VALUE MEANING/DESCRIPTION

--- Send functionality ---------

'CA' Authorized to send a CA message

'CC' Authorized to send a CC message

'CV' Authorized to send a CV message

'CW' Authorized to send a CW message

'CX' Authorized to send a CX message

HA' Authorized to send a HA message

'HH' Authorized to send an HH message

'HW' Authorized to send an HW message

'HY' Authorized to send an HY message

'IF' Authorized to send an IF message

'IK' Authorized to send an IK message

'IM' Authorized to send an IM message

'IN' Authorized to send an IN message

'IW' Authorized to send an IW message

'SR' Authorized to send an SR message

'UA' Authorized to send a UA message

UC' Authorized to send a UC message

'UD' Authorized to send a UD message




Element

Code


/Len


UE' Authorized to send a UE message

'UG' Authorized to send a UG message

'UK' Authorized to send a UK message

--- Receive functionality ------

'HF' Authorized to receive an HF message

'HT' Authorized to receive an HT message

'HV' Authorized to receive an HV message

'HX' Authorized to receive an HX message

'NF' Authorized to receive an NF message

'SC' Authorized to receive an SC message

'SD' Authorized to receive an SD message

BJUCD1 STATE OF RECORD

CLMF-CODE-SOR

AN

2 A jurisdiction code identifying the state

that holds a given record.


See Jurisdiction Code BJUCDE for values.

BJUCDE JURISDICTION CODE

CLMF-JURISDICTION-CODE

AN

2 A jurisdiction is an organization with power,

right or authority to interpret and apply the law,

or the limit or territory within which authority

may be exercised. The codes listed describe the

values used within the scope of AAMVA

systems.


------------------ United States ---------------------

'AK' Alaska

'AL' Alabama

'AR' Arkansas

'AZ' Arizona

'CA' California

'CO' Colorado

'CT' Connecticut

'DC' District of Columbia

'DE' Delaware

'FL' Florida

'GA' Georgia

'HI' Hawaii

'IA' Iowa

'ID' Idaho




Element

Code


/Len


'IL' Illinois

'IN' Indiana

'KS' Kansas

'KY' Kentucky

'LA' Louisiana

'MA' Massachusetts

'MD' Maryland

'ME' Maine

'MI' Michigan

'MN' Minnesota

'MO' Missouri

'MS' Mississippi

'MT' Montana

'NC' North Carolina

'ND' North Dakota

'NE' Nebraska

'NH' New Hampshire

'NJ' New Jersey

'NM' New Mexico

'NV' Nevada

'NY' New York

'OH' Ohio

'OK' Oklahoma

'OR' Oregon

'PA' Pennsylvania

'RI' Rhode Island

'SC' South Carolina

'SD' South Dakota

'TN' Tennessee

'TX' Texas

'UT' Utah

'VA' Virginia

'VT' Vermont

'WA' Washington

'WI' Wisconsin

'WV' West Virginia

'WY' Wyoming

-------------- US Government Agencies -----------

'D2' U.S. Department of Justice

'DS' U.S. Department of State

'DT' U.S. Department of Transportation

'FH' Federal Motor Carrier Safety




Element

Code


/Len


Administration (FMCSA used to be the OMC

in the FHWA)

'GS' General Services Administration (GSA)

'IR' Internal Revenue Service (IRS)

'TS' Transportation Security Administration

(TSA)

------------ US Territorial Possessions ------------

'AS' American Samoa

'FM' Federal States of Micronesia

'GM' Guam

'MH' Marshal Islands

'MP' Northern Mariana Islands

'PW' Palau (till 1994)

'PZ' Panamanian Canal Zone (till December

2000)

'PR' Puerto Rico

'VI' Virgin Islands

'WK' Wake Island

--------------------- Canada -------------------------

'AB' Alberta

'BC' British Columbia

'MB' Manitoba

'NB' New Brunswick

'NF' Newfoundland and Labrador

'NT' Northwest Territory

'NS' Nova Scotia

'NU' Nunavut

'ON' Ontario

'PE' Prince Edward Island

'QC' Quebec

'SK' Saskatchewan

'YT' Yukon Territory

--------------------- Mexico -------------------------

'MX' Mexico (United Mexican States)

'AG' Aguascalientes

'BA' Baja California

'BJ' Baja California Sur

'CE' Campeche

'CH' Chihuahua




Element

Code


/Len


'CI' Chiapas

'CL' Colima

'CU' Coahuila de Zaragoza

'DF' Distrito Federal Mexico

'DO' Durango

'EM' Estado de Mexico (the state within the

country)

'GR' Guerrero

'GU' Guanajuato

'HL' Hidalgo

'JL' Jalisco

'MC' Michoacan de Ocampo

'MR' Morelos

'NA' Nayarit

'NL' Nuevo Leon

'OA' Oaxaca

'PB' Puebla

'QR' Quintana Roo

'QU' Queretaro de Arteaga

'SI' Sinaloa

'SL' San Luis Potosi

'SO' Sonora

'TA' Tamaulipas

'TB' Tabasco

'TL' Tlaxcala

'VC' Veracruz-Llave

'YU' Yucatan

'ZA' Zacatecas

BMPJO1 MEDICAL LICENSING JURISDICTION

CODE

CLMF-MEDIC-JUR-CODE-1

AN

2 A medical licensing jurisdiction is an

organization with the authority to license

medical practitioners, who act as medical

examiners.


See BJUCDE for a list of the U.S. Jurisdiction

codes.

BMPLF1 ME FIRST NAME TRANSLITERATION

IND

CLMF-MEDIC-TRANS-1ST-1

AN

1 An indication if a medical examiner's first

name has been transliterated. Transliteration

refers to the practice of replacing non-English

letters with comparable letters from the English

alphabet.




Element

Code


/Len


See the AAMVA Person Name Standard-2008

for the complete set of rules governing the

format of a person's name.


N First name not transliterated

T First name transliterated

U Unknown if first name is transliterated

BMPLI1 MEDICAL EXAMINER LICENSE

NUMBER

CLMF-MEDIC-NUM-1

AN

14 A jurisdiction assigned number used to identify

the license of medical practitioner who acts as a

medical examiner.

BMPLL1 ME LAST NAME TRANSLITERATION

IND

CLMF-MEDIC-TRANS-LAST-1

AN

1 An indication if a medical examiner's last




alphabet.





N Last name not transliterated

T Last name transliterated

U Unknown if last name is transliterated

BMPLM1 ME MIDDLE NAME

TRANSLITERATION IND

CLMF-MEDIC-TRANS-MID-1

AN

1 An indication if a medical examiner's middle




alphabet.





N Middle name not transliterated

T Middle name transliterated

U Unknown if middle name is




Element

Code


/Len


transliterated

BMPNF1 MEDICAL EXAMINER FIRST NAME

CLMF-MEDIC-NAME-1ST-1

AN

40 A first name of a medical examiner.




BMPNGP MEDICAL EXAMINER NAME GROUP

NONE

AN

146 A group of components that make up a name of

a medical examiner.

The group contains:

- Medical Examiner First Name (BMPNF1)

- Medical Examiner Middle Name (BMPNM1)

- Medical Examiner Last Name (BMPNL1)

- Medical Examiner Name Suffix (BMPNS1)

- ME First Name Truncation Code (BMPTF1)

- ME Middle Name Truncation Code

(BMPTM1)

- ME Last Name Truncation Code (BMPTL1)

- ME First Name Transliteration Code

(BMPLF1)

- ME Middle Name Transliteration Code

(BMPLM1)

- ME Last Name Transliteration Code

(BMPLL1)




BMPNL1 MEDICAL EXAMINER LAST NAME

CLMF-MEDIC-NAME-LAST-1

AN

40 A last name of a medical examiner.




BMPNM1 MEDICAL EXAMINER MIDDLE

NAME

CLMF-MEDIC-NAME-MIDDLE-1

AN

35 A middle name of a medical examiner.


for the

complete set of rules governing the format of a

person's name.

BMPNRN MEDICAL EXAMINER REGISTRY

AN

15 A number used as the identifier in a National




Element

Code


/Len


NUMBER

CLMF-MEDIC-REG-NUM

Registry of Medical Examiners who issue

Medical

Certificates.

BMPNS1 MEDICAL EXAMINER NAME SUFFIX

CLMF-MEDIC-NAME-SFX-1

AN

5 A name suffix of a medical examiner.





JR Junior

SR Senior

I 1st

II 2nd

III 3rd

IV 4th

V 5th

VI 6th

VII 7th

VIII 8th

IX 9th

1ST 1st

2ND 2nd

3RD 3rd

4TH 4th

5TH 5th

6TH 6th

7TH 7th

8TH 8th

9TH 9th

BMPSP1 MEDICAL EXAMINER SPECIALTY

CODE

CLMF-MEDIC-SPECIALTY-1

AN

2 A code indicating the specialty of the medical

practitioner.


AN Advanced Practice Nurse

CH Chiropractor

DO Osteopathic Doctor

MD Medical Doctor

PA Physician Assistant




Element

Code


/Len


BMPTF1 ME FIRST NAME TRUNCATION IND

CLMF-MEDIC-TRUNC-1ST-1

AN

1 An indication if a medical examiner's first

name has been truncated.





N First name not truncated

T First name truncated

U Unknown if the first name is truncated

BMPTL1 ME LAST NAME TRUNCATION IND

CLMF-MEDIC-TRUNC-LAST-1

AN

1 An indication if a medical examiner's last






N Last name not truncated

T Last name truncated

U Unknown if the last name is truncated

BMPTM1 ME MIDDLE NAME TRUNCATION

IND

CLMF-MEDIC-TRUNC-MID-1

AN

1 An indication if a medical examiner's middle






N Middle name not truncated

T Middle name truncated

U Unknown if the middle name is

truncated

BMPTP1 MEDICAL EXAMINER TELEPHONE

NUMBER

CLMF-MEDIC-PHONE-NUM-1

AN

10 A telephone number at which a medical

examiner can be reached.

BPEDOB PERSON DATE OF BIRTH

AN

8 Date of birth of an individual. The format

is CCYYMMDD.




Element

Code


/Len


CLMF-PERSON-DOB

BPENF1 PERSON OLD FIRST NAME

CLMF-PERSON-OLD-FIRST-NAME

AN

40 An old first name of a person.




BPENF2 PERSON DUPLICATE FIRST NAME

CLMF-PERSON-DUP-FIRST-NAME

AN

40 A duplicate first name of a person.




BPENF3 PERSON AKA FIRST NAME

CLMF-PERSON-AKA-FIRST-NAME

AN

40 An AKA first name of a person.




BPENFT PERSON FIRST NAME

CLMF-PERSON-FIRST-NAME

AN

40 A first name of a person.




BPENG1 PERSON OLD NAME GROUP

NONE

AN

146 A group of components that make up an old

name of a person. The group contains:

- Person Old First Name (BPENF1)

- Person Old Middle Name (BPENM1)

- Person Old Last Name (BPENL1)

- Person Old Name Suffix (BPENS1)

- Person Old First Name Truncation Code

(BPETF1)

- Person Old Middle Name Truncation Code

(BPETM1)

- Person Old Last Name Truncation Code

(BPETL1)

- Person Old First Name Transliteration Code

(BPERF1)

- Person Old Middle Name Transliteration Code

(BPERM1)

- Person Old Last Name Transliteration Code

(BPERL1)




Element

Code


/Len





BPENG2 PERSON DUPLICATE NAME GROUP

NONE

AN

146 A group of components that make up a

duplicate name of a person. The group contains:

- Person Duplicate First Name (BPENF2)

- Person Duplicate Middle Name (BPENM2)

- Person Duplicate Last Name (BPENL2)

- Person Duplicate Name Suffix (BPENS2)

- Person Duplicate First Name Truncation Code

(BPETF2)

- Person Duplicate Middle Name Truncation

(BPETM2)

- Person Duplicate Last Name Truncation Code

(BPETL2)

- Person Dup First Name Transliteration Code

(BPERF2)

- Person Dup Middle Name Transliteration

Code (BPERM2)

- Person Dup Last Name Transliteration Code

(BPERL2)




BPENG3 PERSON AKA NAME GROUP

NONE

AN

146 A group of components that make up an AKA

name of a person. The group contains:

- Person AKA First Name (BPENF3)

- Person AKA Middle Name (BPENM3)

- Person AKA Last Name (BPENL3)

- Person AKA Name Suffix (BPENS3)

- Person AKA First Name Truncation Code

(BPETF3)

- Person AKA Middle Name Truncation Code

(BPETM3)

- Person AKA Last Name Truncation Code

(BPETL3)

- Person AKA First Name Transliteration Code

(BPERF3)

- Person AKA Middle Name Transliteration

Code (BPERM3)

- Person AKA Last Name Transliteration Code

(BPERL3)




Element

Code


/Len





BPENGP PERSON NAME GROUP

NONE

AN

146 A group of components that make up a name of

a person.

The group contains:

- Person First Name (BPENFT)

- Person Middle Name (BPENMD)

- Person Last Name (BPENLT)

- Person Name Suffix (BPENSX)

- Person First Name Truncation Code

(BPENTF)

- Person Middle Name Truncation Code

(BPENTM)

- Person Last Name Truncation Code

(BPENTL)

- Person First Name Transliteration Code

(BPENRF)

- Person Middle Name Transliteration Code

(BPENRM)

- Person Last Name Transliteration Code

(BPENRL)




BPENL1 PERSON OLD LAST NAME

CLMF-PERSON-OLD-LAST-NAME

AN

40 An old last name of a person.




BPENL2 PERSON DUPLICATE LAST NAME

CLMF-PERSON-DUP-LAST-NAME

AN

40 A duplicate last name of a person.




BPENL3 PERSON AKA LAST NAME

CLMF-PERSON-AKA-LAST-NAME

AN

40 An AKA last name of a person.






Element

Code


/Len



BPENLT PERSON LAST NAME

CLMF-PERSON-LAST-NAME

AN

40 The last name of a person. Also referred to as

surname of a person.




BPENM1 PERSON OLD MIDDLE NAME

CLMF-PERSON-OLD-MID-NAME

AN

35 The old middle name(s) of a person.




BPENM2 PERSON DUPLICATE MIDDLE NAME

CLMF-PERSON-DUP-MID-NAME

AN

35 A duplicate middle name of a person.




BPENM3 PERSON AKA MIDDLE NAME

CLMF-PERSON-AKA-MID-NAME

AN

35 The AKA middle name(s) of a person.




BPENMD PERSON MIDDLE NAME

CLMF-PERSON-MIDDLE-NAME

AN

35 The middle name(s) of a person.




BPENRF PERSON FIRST NAME

TRANSLITERATION

CLMF-PERSON-TRLIT-1ST

AN

1 An indication if a person's first name has been

transliterated.

Transliteration refers to the practice of

replacing non-English letters with comparable

letters from the English alphabet.







Element

Code


/Len



N Not transliterated

T Transliterated

U Unknown if it is transliterated

BPENRL PERSON LAST NAME

TRANSLITERATION

CLMF-PERSON-TRLIT-LAST

AN

1 An indication if a person's last name has been

transliterated.









T Transliterated


BPENRM PERSON MIDDLE NAME

TRANSLITERATION

CLMF-PERSON-TRLIT-MID

AN

1 An indication if a person's middle name has

been transliterated.









T Transliterated


BPENS1 DRIVER OLD NAME SUFFIX

CLMF-PERSON-OLD-NAME-SUFFIX

AN

5 The suffix for a person's old name.


JR Junior

SR Senior

I 1st

II 2nd




Element

Code


/Len


III 3rd

IV 4th

V 5th

VI 6th

VII 7th

VIII 8th

IX 9th

1ST 1st

2ND 2nd

3RD 3rd

4TH 4th

5TH 5th

6TH 6th

7TH 7th

8TH 8th

9TH 9th

BPENS2 DRIVER DUPLICATE NAME SUFFIX

CLMF-PERSON-DUP-NAME-SUFFIX

AN

5 A duplicate suffix for a person's name.


JR Junior

SR Senior

I 1st

II 2nd

III 3rd

IV 4th

V 5th

VI 6th

VII 7th

VIII 8th

IX 9th

1ST 1st

2ND 2nd

3RD 3rd

4TH 4th

5TH 5th

6TH 6th

7TH 7th

8TH 8th

9TH 9th

BPENS3 DRIVER AKA NAME SUFFIX

AN

5 The suffix for a person's AKA name.




Element

Code


/Len


CLMF-PERSON-AKA-NAME-SUFFIX


JR Junior

SR Senior

I 1st

II 2nd

III 3rd

IV 4th

V 5th

VI 6th

VII 7th

VIII 8th

IX 9th

1ST 1st

2ND 2nd

3RD 3rd

4TH 4th

5TH 5th

6TH 6th

7TH 7th

8TH 8th

9TH 9th

BPENSX PERSON NAME SUFFIX

CLMF-PERSON-NAME-SUFFIX

AN

5 The suffix for a person's name.


JR Junior

SR Senior

I 1st

II 2nd

III 3rd

IV 4th

V 5th

VI 6th

VII 7th

VIII 8th

IX 9th

1ST 1st

2ND 2nd

3RD 3rd

4TH 4th

5TH 5th

6TH 6th




Element

Code


/Len


7TH 7th

8TH 8th

9TH 9th

BPENTF PERSON FIRST NAME TRUNCATION

CODE

CLMF-PERSON-TRUNC-1ST

AN

1 An indication if a person's first name has been

truncated.





N Not truncated

T Truncated

U Unknown if it is truncated

BPENTL PERSON LAST NAME TRUNCATION

CODE

CLMF-PERSON-TRUNC-LAST

AN

1 An indication if a person's last name has been

truncated.





N Not truncated

T Truncated


BPENTM PERSON MIDDLE NAME

TRUNCATION CODE

CLMF-PERSON-TRUNC-MID

AN

1 An indication if a person's middle name has

been truncated.





N Not truncated

T Truncated


BPERF1 PERSON OLD FIRST NAME

TRANSLIT CODE

AN

1 An indication if a person's old first name has





Element

Code


/Len


CLMF-PERSON-OLD-TRLIT-1ST Transliteration refers to the practice of

replacingnon-English letters with comparable







T Transliterated


BPERF2 PERSON DUP FIRST NAME

TRANSLIT CODE

CLMF-PERSON-DUP-TRLIT-1ST

AN

1 An indication if a person's duplicate first name

has been transliterated.









T Transliterated


BPERF3 PERSON AKA FIRST NAME

TRANSLIT CODE

CLMF-PERSON-AKA-TRLIT-1ST

AN

1 An indication if a person's AKA first name has










T Transliterated





Element

Code


/Len


BPERL1 PERSON OLD LAST NAME TRANSLIT

CLMF-PERSON-OLD-TRLIT-LAST

AN

1 An indication if a person's old last name has










T Transliterated


BPERL2 PERSON DUP LAST NAME TRANSLIT

CLMF-PERSON-DUP-TRLIT-LAST

AN

1 An indication if a person's duplicate last name










T Transliterated


BPERL3 PERSON AKA LAST NAME TRANSLIT

CLMF-PERSON-AKA-TRLIT-LAST

AN

1 An indication if a person's AKA last name has













Element

Code


/Len


T Transliterated


BPERM1 PERSON OLD MIDDLE NAME

TRANSLIT CODE

CLMF-PERSON-OLD-TRLIT-MID

AN

1 An indication if a person's old middle name has










T Transliterated


BPERM2 PERSON DUP MIDDLE NAME

TRANSLIT CODE

CLMF-PERSON-DUP-TRLIT-MID

AN

1 An indication if a person's duplicate middle

name has been transliterated.









T Transliterated


BPERM3 PERSON AKA MIDDLE NAME

TRANSLIT CODE

CLMF-PERSON-AKA-TRLIT-MID

AN

1 An indication if a person's AKA middle name











Element

Code


/Len




T Transliterated


BPESSD PERSON SSN LAST 5 DIGITS

NONE

AN

5 The last 5 digits of a person's social security

number.

BPETF1 PERSON OLD FIRST NAME

TRUNCATION

CLMF-PERSON-OLD-TRUNC-1ST

AN

1 An indication if a person's old first name has

been truncated.





N Not truncated

T Truncated


BPETF2 PERSON DUP FIRST NAME

TRUNCATION

CLMF-PERSON-DUP-TRUNC-1ST

AN

1 An indication if a person's duplicate first name

has been truncated.





N Not truncated

T Truncated


BPETF3 PERSON AKA FIRST NAME

TRUNCATION

CLMF-PERSON-AKA-TRUNC-1ST

AN

1 An indication if a person's AKA first name has

been truncated.





N Not truncated




Element

Code


/Len


T Truncated


BPETL1 PERSON OLD LAST NAME

TRUNCATION CODE

CLMF-PERSON-OLD-TRUNC-LAST

AN

1 An indication if a person's old last name has

been truncated.





N Not truncated

T Truncated


BPETL2 PERSON DUP LAST NAME

TRUNCATION CODE

CLMF-PERSON-DUP-TRUNC-LAST

AN

1 An indication if a person's duplicate last name

has been truncated.





N Not truncated

T Truncated


BPETL3 PERSON AKA LAST NAME

TRUNCATION CODE

CLMF-PERSON-AKA-TRUNC-LAST

AN

1 An indication if a person's AKA last name has

been truncated.





N Not truncated

T Truncated


BPETM1 PERSON OLD MIDDLE NAME

TRUNCATION

CLMF-PERSON-OLD-TRUNC-MID

AN

1 An indication if a person's old middle name has

been truncated.





Element

Code


/Len





N Not truncated

T Truncated


BPETM2 PERSON DUP MIDDLE NAME

TRUNCATION

CLMF-PERSON-DUP-TRUNC-MID

AN

1 An indication if a person's duplicate middle






N Not truncated

T Truncated


BPETM3 PERSON AKA MIDDLE NAME

TRUNCATION

CLMF-PERSON-AKA-TRUNC-MID

AN

1 An indication if a person's AKA middle name

has been truncated.





N Not truncated

T Truncated


DACDAT ACCIDENT DATE

CLMF-DATE-ACC

AN

8 The date on which an accident occurred.

The date format is CCYYMMDD.

DACJUR ACCIDENT JURISDICTION CODE

CLMF-CODE-ACC-JUR

AN

2 The jurisdiction in which an accident occurred.


See Jurisdiction Code BJUCDE for the list of

values.

DACLOC ACCIDENT LOCATOR REFERENCE

AN

18 A reference number for the organization that

keeps accident records.




Element

Code


/Len


CLMF-INDC-ACC-LOC

DACSEV ACCIDENT SEVERITY CODE

CLMF-INDC-ACC-SEVERITY

AN

1 The severity of an accident, based on the most

intense injury to any person or, if none were

injured, so designated.


1 Fatal Accident

2 Incapacitating Injury Accident

3 Non-incapacitating Injury Accident

4 Possible Injury Accident

5 Non-injury Accident (i.e. property

damage only)

9 Unknown

DCDPUI MASTER POINTER UNIQUE

INDICATOR

NONE

AN

1 The Master Pointer Unique Indicator is used to

convey whether or not a given MPR is currently

identified as a likely duplicate of another MPR,

is in the process of being marked as unique, or

has been successfully marked as unique.


D Possible Duplicate

P Mark Unique Pending

U Mark Unique Complete

DCICHI CITATION CDL HOLDER INDICATOR

CLMF-CITATION-CDL-IND

AN

1 A code indicating at the time of the citation,

whether the individual holds a Commercial

Driver License (CDL) or, in the case of an

unlicensed driver, whether the individual's last

held license was a CDL.

The code categorizes a driver at the time of the

citation into one of two groups.

One category is for drivers who hold a CDL,

have let their CDL expire, or have had their

CDL suspended or revoked.

The other category is for drivers who have

never had a license, have a base license, have

let their base license expire, or have had their

base license suspended or revoked.




Element

Code


/Len



1 Yes - The cited driver has a current

CDL, or if no valid license, his previous license

was a CDL.

2 No - The cited driver has a current base

license, has never held a license, or holds no

current license and the previous license was a

base license.

9 Unknown (This value is not always

allowed, see the specification for any

restrictions).

DCIDC3 CITATION DATE (OOSW)

CLMF-DATE-CITATION-OOSW

AN

8 The date on which the citation, which led to an

out-of-state withdrawal, was issued.


DCIDCI CITATION DATE

CLMF-DATE-CITATION

AN

8 The date on which a citation was issued.


DCVCC3 CONVICTION OFFENSE ACD CODE

(OOSW)

CLMF-ACD-CONV-OFF-OOSW

AN

3 A code describing an offense for which an

individual was convicted and given an out-of-

state withdrawal by the convicting jurisdiction.


See the AAMVA Code Dictionary (ACD)

DCVCCA CONVICTION OFFENSE ACD CODE

CLMF-ACD-CONV-OFF

AN

3 A code describing an offense for which an

individual was convicted.



DCVCD4 CONVICTION OFFENSE DET - ACD

(OOSW)

CLMF-ACD-CONV-OFF-DET-OOSW

AN

5 For certain conviction offenses, the reference

that further defines the conviction offense and

provides additional detailed information

concerning the offense that led to an out-of-

state withdrawal.

The contents of the field may have the

following format:

XXX.. - 3 character ACD code

99... - 2 digit BAC reading

99... - 2 speed limit violated

99888 - 2 speed limit violated followed by




Element

Code


/Len


the 3 digit actual speed

The unused portion of the field may contain

zeros or spaces. See the AAMVA Code

Dictionary (ACD) for details of when each

format is used.

DCVCDA CONVICTION OFFENSE DETAIL -

ACD

CLMF-ACD-CONV-OFF-DETAIL

AN

5 This field is used with certain conviction

offenses to further define the conviction

offense and provide additional detailed

information concerning the offense.

The contents of the field may have the

following format:

XXX.. - 3 character ACD code

99... - 2 digit BAC reading

99... - 2 speed limit violated

99888 - 2 speed limit violated followed by

the 3 digit actual speed

The unused portion of the field may contain

zeros or spaces. See the AAMVA Code

Dictionary (ACD) for details of when each

format is used.

DCVCID CONVICTION ID CODE

CLMF-CONV-ID-CODE

AN

2 The unique identifier of the conviction,

assigned by the Jurisdiction of Record to

identify a conviction underlying a withdrawal.

DCVCL3 CONVICTION JURIS CRT REPORT ID,

OOSW

CLMF-DESC-CONV-OFF-LOC-OOSW

AN

18 The Jurisdiction of Conviction's identifier for

an individual conviction of a driver that led to

an out-of-state withdrawal of the driver. This

identifier may be a summons number, a

reference to a record in a file, a database, a

microfilm, or any other reference assigned by

the jurisdiction of conviction. The identifier is

unique within the jurisdiction and enables the

jurisdiction to look up the original record of the

conviction.

The element is sometimes referred to as the

"Conviction Offense Locator Reference".

DCVCLO CONVICTION JURIS COURT REPORT

ID

AN

18 The Jurisdiction of Conviction's unique

identifier for an individual conviction of a




Element

Code


/Len


CLMF-DESC-CONV-OFF-LOC

driver. The identifier may be a summons

number, a reference to a record in a file, a

database, a microfilm, or any other reference

assigned by the jurisdiction of conviction. The

identifier is unique within the jurisdiction and

enables the jurisdiction to look up the original

record of the conviction.

The element is sometimes referred to as the

"Conviction Offense Locator Reference".

DCVCO4 CONVICTION COMMERCIAL VEH

IND (OOSW)

CLMF-INDC-COMM-VEH-OFF-OOSW

AN

1 An indicator of whether a commercial vehicle

was being used when the offense, which led to

an out-of-state withdrawal, was committed.


1 Yes (commercial)

2 No (non-commercial)



restrictions).

DCVCO5 CONVICTION JURIS OFFENSE CD

(OOSW)

CLMF-DESC-CONV-OFF-REF-OOSW

AN

8 The Jurisdiction of Conviction's native code for

the type of offense committed by the driver

(typically, a reference to a statute within a

jurisdiction) that led to an out-of-state

withdrawal of the driver.

DCVCOM CONVICTION COMMERCIAL VEH

IND

CLMF-INDC-COMM-VEHICLE-OFF

AN

1 An indicator of whether a commercial vehicle

was being used when the offense was

committed.


1 Yes (commercial)




restrictions).

DCVCOR CONVICTION JURISDICTION

OFFENSE CODE

CLMF-DESC-CONV-OFF-REF

AN

8 The Jurisdiction of Conviction's native code for

the type of offense committed by the driver :

typically, a reference to a statute within a

jurisdiction.

DCVCR3 CONVICTION COURT TYPE (OOSW)

AN

3 The type of court which finalized the conviction

that led to an out-of-state withdrawal.




Element

Code


/Len


CLMF-CODE-COURT-TYPE-OOSW


ADM Administrative Adjudication

CHA Chancery Court

CIR Circuit Court

CIT City Court

CIV Civil Court

COC County Court

COR Corporation Court

CRI Criminal Court

DIS District Court

DOT Secretary USDOT

FED U.S. District Court

GEN General Court Martial

HUS Hustings Court

JPC Justice of Peace Court

JUS Justice Court

JUV Juvenile Court

LEC Law and Equity Court

MAG Magistrate Court

MAY Mayor's Court

MUN Municipal Court

POL Police Court

SJC Special Justice Court

SPL Special Court Martial

SSP State Supreme Court

SUM Summary Court Martial

SUP Superior Court

TJC Trial Justice Court

TRA Traffic Court

TRI Tribal Court

TWN Town Court

UNK Unknown

USC U.S. Commissioner

USM U.S. Magistrate Court

USS U.S. Supreme Court

DCVCRT CONVICTION COURT TYPE

CLMF-CODE-COURT-TYPE

AN

3 The type of court which finalized the

conviction.


ADM Administrative Adjudication

CHA Chancery Court




Element

Code


/Len


CIR Circuit Court

CIT City Court

CIV Civil Court

COC County Court

COR Corporation Court

CRI Criminal Court

DIS District Court

DOT Secretary USDOT

FED U.S. District Court

GEN General Court Martial

HUS Hustings Court

JPC Justice of Peace Court

JUS Justice Court

JUV Juvenile Court

LEC Law & Equity Court

MAG Magistrate Court

MAY Mayor's Court

MUN Municipal Court

POL Police Court

SJC Special Justice Court

SPL Special Court Martial

SSP State Supreme Court

SUM Summary Court Martial

SUP Superior Court

TJC Trial Justice Court

TRA Traffic Court

TRI Tribal Court

TWN Town Court

UNK Unknown

USC U.S. Commissioner

USM U.S. Magistrate Court

USS U.S. Supreme Court

DCVDC3 CONVICTION DATE (OOSW)

CLMF-DATE-CONV-OOSW

AN

8 The date that an individual was convicted of an

offense that led to an out-of-state withdrawal.


DCVDCV CONVICTION DATE

CLMF-DATE-CONV

AN

8 The date that an individual was convicted. The

date format is CCYYMMDD

DCVHA3 CONVICTION HAZMAT IND (OOSW)

AN

1 For a specific conviction of a driver, which led

to an out-of-state withdrawal of the driver,




Element

Code


/Len


CLMF-INDC-HAZMAT-OFF-OOSW

a determination of whether the violation

occurred while the driver was carrying

hazardous materials (that required a placard)

in a commercial vehicle.


1 Yes (hazardous materials)

2 No (no hazardous materials)


allowed, see the

specification for any restrictions).

DCVHAZ CONVICTION HAZMAT IND

CLMF-INDC-HAZ-MATERIAL-OFF

AN

1 For a specific conviction of a driver,

a determination of whether the violation

occurred while the driver was carrying

hazardous materials (that required a placard)

in a commercial vehicle.


1 Yes (hazardous materials)

2 No (no hazardous materials)



restrictions).

DCVJU3 JURISDICTION CODE - CONVICTING,

OOSW

CLMF-CODE-CONV-JUR-OOSW

AN

2 The code identifying the Jurisdiction (at the

state level) in which the conviction was

rendered.

The Jurisdiction that took an out-of-state

withdrawal.



values.

DCVJUR JURISDICTION CODE - CONVICTING

CLMF-CODE-CONV-JUR

AN

2 The code identifying the Jurisdiction (at the

state level) in which the conviction was

rendered.



values.




Element

Code


/Len


DDACOM DRIVER ACCIDENT COMMERCIAL

VEH IND

CLMF-INDC-ACC-COMM

AN

1 A determination of whether the accident

occurred while the driver was operating a

commercial vehicle.


1 Yes (commercial)


9 Unknown

DDAHAZ DRIVER ACCIDENT HAZMAT IND

CLMF-INDC-ACC-HAZ-MAT

AN

1 A determination of whether the accident

occurred while the driver was operating a

commercial vehicle that was carrying hazardous

materials (that required a placard).


1 Yes (hazardous material)

2 No (no hazardous material)

9 Unknown

DDBFPD BATCH FILE PROCESSING DATE

CLMF-BAT-DATE-PROC

AN

8 The date processing of a batch file started

The format is CCYYMMDD.

DDBIRD BATCH FILE RECEPTION DATE

CLMF-BAT-DATE-RCV

AN

8 The date a batch file is received .


DDBISD BATCH INQUIRY FILE SENT DATE

CLMF-BAT-INQ-DATE-SENT

AN

8 The date a batch inquiry file is sent.


DDBNE1 BATCH INQUIRIES RETURNED IN

ERROR

CLMF-NUM-BAT-INQ-IN-ERROR

AN

6 The number of batch inquiries returned in error.


NUMERIC VALUES WHEN

PRESENT

DDBNP1 BATCH INQUIRIES PROCESSED

CLMF-NUM-BAT-INQ-PROCESSED

AN

6 The number of inquiries processed in batch

mode.


NUMERIC VALUES WHEN

PRESENT




Element

Code


/Len


DDBNR1 COUNT OF MESSAGES PROCESSED

CLMF-BAT-CNT-RESP

AN

6 The number of batch response messages sent.


NUMERIC VALUES WHEN

PRESENT

DDBNR2 COUNT OF SUCCESSFUL MATCHES

CLMF-BAT-CNT-RESP2

AN

6 The number of batch response messages sent.


NUMERIC VALUES WHEN

PRESENT

DDBRSD BATCH RESPONSE FILE SENT DATE

CLMF-BAT-DATE-RESP

AN

8 The date a batch response file is sent.


DDBST1 BATCH INQUIRY MESSAGES SENT

CLMF-BAT-STA-REQUESTS

AN

6 The number of inquiry requests sent.


NUMERIC VALUES WHEN

PRESENT

DDLCL2 DL COMMERCIAL CLASS CODE

CLMF-DESC-CDL-CLASS

AN

3 The type of commercial vehicle

that a licensed driver has been examined on and

approved to operate. This field represents the

highest-level classification for a particular

Driver Privilege Type.

This is a group field that can hold up to three

occurrences of class code. In practice it will be

used for two codes at most ('AM', 'BM' or

'CM').


'A' Class "A" vehicles - any combination of

vehicles with a GCWR of 26,001 or more

pounds, provided the GVWR of the vehicle(s)

being towed is in excess of 10,000 pounds.

(Holders of a Class A license may with the

appropriate endorsement operate all Class

B & C vehicles). [49 CFR 383.91(a)(1)].

'B' Class "B" vehicles - any single vehicle

with a GVWR of 26,001 or more pounds, or




Element

Code


/Len


any such vehicle towing a vehicle not in excess

of 10,000 pounds GVWR. (Holders of a Class

B license may with the appropriate

endorsement, operate all Class C vehicles). [49

CFR 383.91(a)(2)].

'C' Class "C" vehicles - any single

commercial vehicle, or combination of vehicles,

that meets neither the definition of group A nor

that of group B, but that either is designed to

transport 16 or more passengers including the

driver, or is used in the transportation of

materials found to be hazardous for the

purposes of the Hazardous Materials

Transportation Act and which require the motor

vehicle to be placarded under the Hazardous

Materials Regulations (49 CRF part 172,

subpart F) [49 CFR 383.91(a)(3)].

'M' Class "M" vehicles - Motorcycles,

Mopeds, Motor-driven Cycles.

' ' Blank - Never held a license or the

information is longer available.

DDLCL3 DL NON-COMMERCIAL CLASS CODE

CLMF-DESC-NON-CDL-CLASS

AN

3 The type of non-commercial vehicle that a

licensed driver has been examined on and

approved to operate. This field represents the

highest-level classification for a particular

driver privilege. The non-commercial classes

are state defined.

DDLCTS DRIVER LICENSE COMMERCIAL

STATUS

CLMF-DESC-CDL-STATUS

AN

3 The current status of an individual's commercial

privilege type. The statuses are:

Licensed

The individual has a current valid license with

all their driving privileges intact. This

status is only used within the jurisdiction

that issued the current license.

Eligible

The individual does not have a current valid

license and has nothing on record that would

prevent issuance. This includes an individual

who:

- has moved out of a state and the jurisdiction




Element

Code


/Len


cancels the license

- has met the requirements to allow restoration

of driving privileges following a suspension or

revocation

- has never held a license

- possesses a learner's permit

- has had a parent approve reinstatement of

privileges revocation

- has reached 18 after a parent withdrew

privileges

- has had a court lift the suspensions

- voluntarily surrendered their license

- is within the renewal grace period after a

license expired

- needs to take a test before obtaining a license

(for a new driver and for an expired

license)

Not Eligible


license and has an adverse action on record that

prevents issuance of a commercial license and

may prevent the issuance of a base license.

These conditions include:

- suspended for minor offenses with outstanding

restoration requirements

- revoked indefinitely

- habitual offender

- medical condition

- unsatisfied judgment

- revoked for major offenses with outstanding


- parent revokes privileges of driver under 18

- seizure of license by law enforcement

- default in payment

- insurance cancellation

- misrepresentation (clearance letter needed)

- driving privileges lost due to conviction even

though the individual has never held a

license

- administrative per se action

- within disqualification period

- inability to pass test (i.e. for the period after

a failed test when the test can not be




Element

Code


/Len


retaken).

Not Eligible due to non-ACD

(In use from 10/1/2005 to 12/31/2007).

The individual has been withdrawn in a specific

jurisdiction for an offense that is not federally

mandated or related to traffic safety and

therefore does not have an ACD conviction

code. Because it is a withdrawal for an offense

specific to a jurisdiction, other jurisdictions

may issue a new license to the individual if

their rules permit.

Reported Deceased

The individual has been reported deceased.


LIC Licensed

ELG Eligible

NOT Not Eligible

NEN Not Eligible due to non-ACD (In use

from 10/1/2005 to 12/31/2007)

RPD Reported Deceased

DDLEND DRIVER LICENSE ENDORSEMENT

CODE

CLMF-DESC-DL-ENDORSE-OCCURS

AN

1 Any endorsements on a driver license (not a

permit) which authorize the operation of

specified types of vehicles or the operation of

vehicles carrying specified loads.

Endorsements are specific to classifications of a

driver license.


T Doubles/Triples - This endorsement is

required for the operation of any vehicle that

would be referred to as a double or triple.

P Passenger - This endorsement is required

for the operation of any vehicle used for

transportation of sixteen or more occupants,

including the driver.

N Tank - This endorsement is required for

the operation of any vehicle transporting, as its

primary cargo, any liquid or gaseous material

within a tank attached to the vehicle.

H Hazardous Material - This endorsement




Element

Code


/Len


is required for the operation of any vehicle

transporting hazardous materials requiring

placarding, as defined by U.S. Department of

Transportation regulations.

X Combined Tank/HAZ-MAT - This

endorsement may be issued to any driver who

qualifies for both the N and H endorsements.

S School Bus - This endorsement is

required for the operation of a school bus.

School bus means a CMV used to transport pre-

primary, primary, or secondary school students

from home to school, from school to home, or

to and from school sponsored events. School

bus does not include a bus used as common

carrier (49 CFR 383.5).

L Motorcycles - Including

Mopeds/Motorized Bicycles.

O Other Jurisdiction Specific

Endorsement(s) – This code indicates one or

more additional jurisdiction assigned

endorsements.

DDLEP1 DL PERMIT ENDORSEMENT GROUP

CODE

CLMF-DESC-PERM-ENDORSE

AN

5 An endorsement on a driver license permit that

grants the operation of specified types

of vehicles or the operation of vehicles

carrying specified loads, subject to the

supervision of a person licensed for such

endorsement (i.e., the endorsement is under

permit.) Endorsements will be specific to

classifications of a driver license.

Up to five codes can be sent in this group

element.


The following values apply the individual codes

in this group.

T Doubles/Triples - This endorsement is

required for the operation of any vehicle that

would be referred to as a double or triple.




Element

Code


/Len


P Passenger - This endorsement is required

for the operation of any vehicle used for

transportation of sixteen or more occupants,

including the driver.

N Tank - This endorsement is required for

the operation of any vehicle transporting, as its

primary cargo, any liquid or gaseous material

within a tank attached to the vehicle.

S School Bus - This endorsement is

required for the operation of a school bus.

School bus means a CMV used to transport pre-

primary, primary, or secondary school students

from home to school, from school to home, or

to and from school sponsored events. School

bus does not include a bus used as common

carrier (49 CFR 383.5).

L Motorcycles - Including

Mopeds/Motorized Bicycles.

O Other Jurisdiction Specific

Endorsement(s) – This code indicates one or

more additional jurisdiction assigned

endorsements.

DDLEXP DRIVER LICENSE EXPIRATION DATE

CLMF-DATE-DL-EXPIRE

AN

8 The date after which a driver license is no

longer valid. The date format is CCYYMMDD.

DDLHCD DL HISTORY CHECK DATE

CLMF-DL-HIST-CHECK-DATE

AN

8 The date that the jurisdiction requested the 10

year history check (a request for the driver

history from all other jurisdictions that had

issued a license to a CDL applicant in the 10

year period prior to the application). The

format is CCYYMMDD.

DDLHCI DL HISTORY CHECK INQUIRING

JURIS

CLMF-DL-HIST-INQUIRING-JURIS

AN

2 A code identifying the jurisdiction that asked

for the driver history from all other jurisdictions

that had issued a license to a CDL applicant in

the 10 year period prior to the application.



values.




Element

Code


/Len


DDLHCJ DL HISTORY CHECK RESPONDING

STATE

CLMF-DL-HIST-JURIS

AN

2 The code of a former licensing jurisdiction that

responded to a request for the driver history as

part of the 10 year history check of a CDL

applicant.



values.

DDLHCL DL HISTORY CHECK RESPONSE LIST

CLMF-DL-HIST-STATES-LIST

AN

30 A list of the former licensing jurisdictions that

that responded to a request for the driver history

as part of the 10 year history check of a CDL

applicant. Up to 15 jurisdiction codes may be

identified.



values.

DDLHCR DL HISTORY CHECK REQUEST

TOTAL

CLMF-DL-HIST-REQUEST-TOTAL

AN

2 The number (up to a limit of 99) of former

licensing jurisdictions queried for the driver

history as part of the 10-year history check of a

CDL applicant.


NUMERIC VALUES WHEN

PRESENT

DDLHCT DL HISTORY CHECK RESPONSE

TOTAL

CLMF-DL-HIST-STATE-TOTAL

AN

2 The number (up to a limit of 99) of former

licensing jurisdictions that responded to a

request for the driver history as part of

the 10 year history check of a CDL applicant.

DDLHED DL HAZMAT ENDORSEMENT EXP

DATE

CLMF-HME-EXP-DATE

AN

8 The date the Hazardous Material

endorsement(s) on a drivers license expire.

Format is CCYYMMDD.

DDLISS DRIVER LICENSE ISSUE DATE

CLMF-DATE-DL-ISSUE

AN

8 The date when a driver license was

issued/renewed.


DDLJD1 DL OLD JURISDICTION NUMBER

AN

27 The old primary driver license jurisdiction

number. A composite element consisting of




Element

Code


/Len


CLMF-CODE-STDLN-OLD-PRIMARY

Driver Licensing Jurisdiction and Driver

License Number. The combination of

jurisdiction and driver license number creates a

single unique key useful to most jurisdictions to

locate a driver within their files. The first two

characters are an alphabetic code identifying the

jurisdiction. The third and subsequent

characters are assigned by the licensing

jurisdiction to an individual's driver license.

DDLJD2 AKA DRIVER LICENSE JURIS

NUMBER

CLMF-CODE-STDLN-AKA1

AN

27 The also known as Driver Licensing

Jurisdiction Number. The AKA number holds

historical information such as a prior driver

license.

A composite element consisting of Driver

Licensing Jurisdiction and Driver License

Number. The combination of jurisdiction and

driver license number creates a single unique

key useful to most jurisdictions to locate a

driver within their files. The first two characters

are an alphabetic code identifying the




DDLJD3 AKA 2ND DRIVER LICENSE JURIS

NUMBER


AN

27 The second also known as Driver Licensing



license.











DDLJD4 AKA 3RD DRIVER LICENSE JURIS

NUMBER


AN

27 The third also known as Driver Licensing



license.







Element

Code


/Len









DDLJD5 DL DUPLICATE JURISDICTION

NUMBER

CLMF-CODE-STDLN-DUPE

AN

27 The duplicate Driver Licensing Jurisdiction

Number.









characters are assigned by the license


DDLJDL DRIVER LICENSE JURIS NUMBER

CLMF-CODE-STDLN-CURRENT

AN

27 The composite element consisting of Driver










DDLJU2 AKA JURISDICTION CODE -

LICENSING

CLMF-CODE-ST-AKA1

AN

2 The code of the jurisdiction that issued the

license. The AKA code holds historical

information such as a prior driver license

jurisdiction code.



values.

DDLJU6 DUPLICATE LICENSING JURIS CODE

CLMF-CODE-ST-DUPE

AN

2 The code of the jurisdiction that issued a

duplicate license.



values.




Element

Code


/Len


DDLJUR JURISDICTION CODE - LICENSING

CLMF-DRIVER-LICENCE-JURIS

AN

2 The code of the jurisdiction that issued

the license.



values.

DDLKST AKA ST-DLN STATUS

NONE

AN

1 The AKA ST-DLN Status is used to convey

whether or not a given occurrence of AKA ST-

DLN is active or inactive.


A Active

I Inactive

DDLNMP DRV LIC NUMBER OF PERMITS

CLMF-NUMB-PERMITS

AN

1 The number of driver license permits that are

included on the driver's record.


NUMERIC VALUES WHEN

PRESENT

DDLNMR NUMBER OF DRV LIC

RESTRICTIONS

CLMF-NUMB-DL-RESTR

AN

2 The number of license restrictions on the

driver's record.


NUMERIC VALUES WHEN

PRESENT

DDLNTS DRV LIC NON-COMMERCIAL

STATUS

CLMF-DESC-NON-CDL-STATUS

AN

3 The current status of an individual's

non-Commercial (Base) privilege type. The

statuses are:

Licensed





Eligible







Element

Code


/Len


who:


cancels the license


of driving privileges following a suspension or

revocation






privileges




license expired



license)

Not Eligible









- habitual offender

- medical condition











license






Element

Code


/Len




retaken).


(In use from 10/1/2005 to 12/31/2007).








their rules permit.

Reported Deceased



LIC Licensed

ELG Eligible

NOT Not Eligible


from 10/1/2005

to 12/31/2007)


DDLNU0 DRIVER LICENSE NUMBER START

RANGE

CLMF-DLN-START

AN

25 A driver license number provides a single

unique index or key useful within a jurisdiction

to locate a driver. The Start Range indicates the

driver license number with the lowest value,

when describing a number of driver licenses.

DDLNU1 AKA DRIVER LICENSE NUMBER

CLMF-CODE-DLN-AKA1

AN

25 The driver license number provides a single


to locate a driver. The AKA number holds


license number.

DDLNU5 DUPLICATE DRIVER LICENSE

NUMBER

CLMF-CODE-DLN-DUPE

AN

25 The duplicate driver license number used within

a jurisdiction to locate a driver.




Element

Code


/Len


DDLNU9 DRIVER LICENSE NUMBER END

RANGE

CLMF-DLN-END

AN

25 A driver license number provides a single


to locate a driver. The End Range indicates the

driver license number with the highest value,

when describing a number of driver licenses.

DDLNUM DRIVER LICENSE NUMBER

CLMF-CODE-DLN-CURR

AN

25 The driver license number provides a single


to locate a driver.

DDLPC2 DRVER PERMIT COMMERCIAL

CLASS CODE

CLMF-DESC-PERM-CLASS

AN

6 The type of commercial or non-commercial

vehicle that a licensed driver has been

examined on and approved to operate subject to

a permit. This field represents the highest level

classification for a particular driver privilege

type (i.e., commercial vs. non-commercial). Up

to six classes can be stored in this element.


FOR NON-COMMERCIAL DRIVER

LICENSES, EACH STATE

ASSIGNS ITS OWN VALUE.

FOR COMMERCIAL DRIVER LICENSES,

THE FOLLOWING

CODES ARE USED:

'A' Class "A" vehicles - any combination of

vehicles with a GCWR of 26,001 or more

pounds, provided the GVWR of the vehicle(s)

being towed is in excess of 10,000 pounds.

(Holders of a Class A license may with the

appropriate endorsement operate all Class

B & C vehicles). [49 CFR 383.91(a)(1)].

'B' Class "B" vehicles - any single vehicle

with a GVWR of 26,001 or more pounds, or

any such vehicle towing a vehicle not in excess

of 10,000 pounds GVWR. (Holders of a Class

B license may with the appropriate

endorsement, operate all Class C vehicles). [49

CFR 383.91(a)(2)].

'C' Class "C" vehicles - any single

commercial vehicle, or combination of vehicles,

that meets neither the definition of group A nor

that of group B, but that either is designed to




Element

Code


/Len


transport 16 or more passengers including the

driver, or is used in the transportation of

materials found to be hazardous for the

purposes of the Hazardous Materials

Transportation Act and which require the motor

vehicle to be placarded under the Hazardous

Materials Regulations (49 CFR part 172,

subpart F) [49 CFR 383.91(a)(3)].

'M' Class "M" vehicles - Motorcycles,

Mopeds, Motor-driven Cycles.

DDLPD1 DRV LIC 1ST PERMIT RESTRICT END

DATE

CLMF-DATE-P1-RESTR-END

AN

8

The date when a special restriction applicable

to the first permit will end.


DDLPD2 DRV LIC 2ND PERMIT RESTRICT

END DATE


AN

8


to the second permit will end.


DDLPD3 DRV LIC 3RD PERMIT RESTRICT

END DATE


AN

8


to the third permit will end.


DDLPE1 DL 1ST PERMIT RESTRICT

EXPLANATION

CLMF-DESC-P1-EXPL

AN

40 Freeform text to describe the nature of

a restriction applicable to the first

permit.

DDLPE2 DL 2ND PERMIT RESTRICT

EXPLANATION

CLMF-DESC-P2-EXPL

AN


a restriction applicable to the second

permit.

DDLPE3 DL 3RD PERMIT RESTRICT

EXPLANATION

CLMF-DESC-P3-EXPL

AN


a restriction applicable to the third

permit.

DDLPED DRV LIC PERMIT EXPIRATION DATE

CLMF-DATE-PERM-EXPIRE

AN

8 The date after which a driver permit is no

longer valid.





Element

Code


/Len


DDLPID DRV LIC PERMIT ISSUE DATE

CLMF-DATE-PERM-ISSUE

AN

8 The date when a driver permit was issued /

renewed.


DDLPST DRV LIC PERMIT STATUS

CLMF-DESC-PERM-STATUS

AN

3 The current status of an individual's driver

permit.

The statuses are:

Licensed





Eligible




who:


cancels the license


of driving privileges following a

suspension or revocation






privileges




license expired



license)

Not Eligible









Element

Code


/Len





- habitual offender

- medical condition











license





retaken).


(In use from 10/1/2005 to 12/31/2007).








their rules permit.

Reported Deceased



LIC Licensed

ELG Eligible

NOT Not Eligible


from 10/1/2005

to 12/31/2007)





Element

Code


/Len


DDLRP1 DRV LIC 1ST PERMIT RESTRICT

CODE

CLMF-CODE-P1-RESTR

AN

1 A restriction applicable to the first permit.


B Corrective lenses must be worn

C Mechanical Aid (Special Brakes, hand

controls,

or other adaptive devices)

D Prosthetic Aid

E Automatic Transmission

F Outside Mirror

G Limit to Daylight Only

H Limited to Employment

I Limited - other

J Other

K CDL Intrastate Only

L Vehicles without Air Brakes

M Except Class A bus

N Except Class A and Class B bus

O Except Tractor-Trailer

V Medical Variance Documentation

Required

W Farm Waiver

DDLRP2 DRV LIC 2ND PERMIT RESTRICT

CODE

CLMF-CODE-P2-RESTR

AN

1 A restriction applicable to the second permit.




controls,


D Prosthetic Aid


F Outside Mirror



I Limited - other

J Other









Element

Code


/Len



Required

W Farm Waiver

DDLRP3 DRV LIC 3RD PERMIT RESTRICT

CODE

CLMF-CODE-P3-RESTR

AN

1 A restriction applicable to the third permit.




controls,


D Prosthetic Aid


F Outside Mirror



I Limited - other

J Other







Required

W Farm Waiver

DDLRPN DL NUMBER OF PERMIT

RESTRICTIONS

CLMF-NUMB-PERM-RESTR

AN

2 The number of permit restrictions that are

included on

the driver's record.


NUMERIC VALUES WHEN

PRESENT

DDLRSC DRIVER LICENSE RESTRICTION

CODE

CLMF-CODE-LIC-RESTR

AN

1 A restriction applicable to a driver license.

When the code is set to 'other' the restriction

explanation is used to describe the restriction.




controls,




Element

Code


/Len



D Prosthetic Aid


F Outside Mirror



I Limited - other

J Other







Required

W Farm Waiver

DDLRSD DRIVER LICENSE RESTRICTION END

DATE

CLMF-DATE-LIC-RESTR-END

AN

8 The date when a special restriction applicable

to a driver license will end.


DDLRSE DL RESTRICTION EXPLANATION

CLMF-DESC-LIC-EXPL

AN


a restriction applicable to a complete driver

license.

DDLSCT CDL MEDICAL SELF CERTIFICATION

CODE

CLMF-MED-SELF-CERTIFICATION

AN

2 A driver's self certification of the driver's

status regarding 49 CFR 390.3 and the type of

driving.


EA Excepted Intrastate

EI Excepted Interstate

NA Non-excepted Intrastate

NI Non-excepted Interstate

DDLSED DRIVER SPE EXPIRATION DATE

CLMF-SPE-EXP-DATE

AN

8 The expiration date of the most recent variance

of a medical certificate, due to a Skills

Performance Evaluation.

The data format is CCYYMMDD.

DDLSSD DRIVER SPE EFFECTIVE DATE

AN

8 The start date of the most recent variance of

a medical certificate, due to a Skills




Element

Code


/Len


CLMF-SPE-START-DATE

Performance Evaluation.


DDLWDP DL PRIVILEGE TYPE W/D ACTION

PENDING

CLMF-INDC-DL-WDRAW-PEND

AN

1 If set to ‘1’, this flag indicates that the

current licensing jurisdiction has an action

pending, that if carried to completion will

cause a withdrawal of a specified driver

privilege type (i.e., Base or Commercial)


1 Yes (action pending)

2 No (no action pending)

DDLWED DRIVER WAIVER/EXEMPT

EXPIRATION DATE

CLMF-WE-EXP-DATE

AN

8 The expiration date of the most recent variance

of a medical certificate, due to a waiver or

exemption.


DDLWSD DRIVER WAIVER/EXEMPT

EFFECTIVE DATE

CLMF-WE-START-DATE

AN

8 The start date of the most recent variance of

a medical certificate, due to a waiver or

exemption.


DDTTAR TOTAL ACCIDENTS ON RECORD

CLMF-NUMB-ACC-RECORD

AN

2 This is the number of accidents on a driver's

record.


NUMERIC VALUES WHEN

PRESENT

DDTTAS TOTAL ACCIDENTS SENT

CLMF-NUMB-ACC-SENT

AN

2 This is the number of accidents sent in a driver

history request. It may be less than what is

actually on the driving record. The maximum

that can be in a driver history request is 50.


NUMERIC VALUES WHEN

PRESENT

DDTTCR TOTAL ACD CONVICTIONS ON

RECORD

AN

2 The number of AAMVA Code Dictionary

(ACD) convictions on a driver's record. ACD

convictions are for violations that are federally

mandated and/or related to traffic-safety.




Element

Code


/Len


CLMF-NUMB-CONV-RECORD

When the total number of ACD convictions on

a driver's record is 99 or more, this element is

set to 99.


NUMERIC VALUES WHEN

PRESENT

DDTTCS TOTAL CONVICTIONS SENT

CLMF-NUMB-CONV-SENT

AN

2 This is the number of convictions sent in a

Driver History Request. It may be less than

what is actually on the driving record. The

maximum that can be in a driver history request

is 50.


NUMERIC VALUES WHEN

PRESENT

DDTTLR TOTAL WITHDR-CONV LINKS ON

RECORD

CLMF-NUMB-LINKS-RECORD

AN

2 The number of withdrawal-convictions linkages

on record.

When the total number of withdrawal-

conviction links on a driver's record is 99 or

more, this element is set to 99.


NUMERIC VALUES WHEN

PRESENT

DDTTLS TOTAL WITHDRAWAL-CONV LINKS

SENT

CLMF-NUMB-LINKS-SENT

AN

2 The number of withdrawal-convictions linkages

sent in a driver history request (a linkage is the

association of a withdrawal and its underlying

convictions). The number sent may be less than

the actual number of linkages on the driving

record.


NUMERIC VALUES WHEN

PRESENT

DDTTWR TOTAL WITHDRAWALS ON RECORD

CLMF-NUMB-WDRAW-RECORD

AN

2 This is the number of withdrawals on a driver's

record.

When the total number of withdrawals on a




Element

Code


/Len


driver's record is 99 or more, this element is

set to 99.


NUMERIC VALUES WHEN

PRESENT

DDTTWS TOTAL WITHDRAWALS SENT

CLMF-NUMB-WDRAW-SENT

AN

2 This is the number of withdrawals sent in a

driver history request. It may be less than what

is actually on the driving record. The

maximum that can be in a driver history request

is 50.


NUMERIC VALUES WHEN

PRESENT

DDVADD DRIVER MAILING ADDRESS

CLMF-DRVHIST-MAILING-ADDR

AN

71 The mailing address of a driver (or a MVA

customer).

The address is delimited as follows:

Address Element # Maximum Length

Characters

Street Address A 20 + 1 for separator

A/N

Street Address B 20 + 1 for separator

A/N

City or Town 15 + 1 for separator

A/N

State Code 2 + 1 for separator

A/N

Zip Code 9 + 1 for delimiter

A/N

Allow @ as separator and ; as ending delimiter.

Unused character positions can not be used to

extend the maximum length of any address

element.

DDVAGE DRIVER AGE

CLMF-DRIVER-AGE

AN

3 The age in years of an individual driver.




Element

Code


/Len


DDVCNT DRIVER COUNT

CLMF-CNT-DRIVERS

AN

9 A count of the number of drivers.


NUMERIC VALUES WHEN

PRESENT

DDVDO1 DRIVER OLD DATE OF BIRTH

CLMF-DOB-OLD-PRIMARY

AN

8 The birth date of a driver on an old record. The

date format is CCYYMMDD.

DDVDO2 DRIVER DUPLICATE DATE OF BIRTH

CLMF-DOB-DUPE

AN

8 The birth date of a driver on a duplicate record.


DDVDOB DRIVER DATE OF BIRTH

CLMF-DOB-CURRENT

AN

8 The birth date of a driver. The date

format is CCYYMMDD.

DDVEY2 DRIVER DUPLICATE EYE COLOR

CLMF-DUP-DESC-EYE-COLOR

AN

3 The duplicate eye color of a driver as reported

by a Jurisdiction.


BLK Black

BLU Blue

BRO Brown

DIC Dichromatic

GRY Gray

GRN Green

HAZ Hazel

MAR Maroon

PNK Pink

UNK Unknown

DDVEY3 DRIVER CURRENT EYE COLOR

CLMF-CUR-DESC-EYE-COLOR

AN

3 The current eye color of a driver, as reported

by a Jurisdiction.


BLK Black

BLU Blue

BRO Brown

DIC Dichromatic

GRY Gray

GRN Green




Element

Code


/Len


HAZ Hazel

MAR Maroon

PNK Pink

UNK Unknown

DDVHT2 DRIVER DUPLICATE HEIGHT

CLMF-DUP-DESC-HEIGHT

AN

3 This element is a duplicate measurement of a

driver's height. The first digit contains the

number of feet and the last two digits contain

the number of inches.


NUMERIC VALUES WHEN

PRESENT

DDVHT3 DRIVER CURRENT HEIGHT

CLMF-CUR-DESC-HEIGHT

AN

3 The measurement of a driver's current height.

The first digit contains the number of feet and

the last two digits contain the number of inches.


NUMERIC VALUES WHEN

PRESENT

DDVKD2 DRIVER AKA 2ND DATE OF BIRTH

CLMF-DOB-AKA2

AN

8 An AKA recorded birth date for a driver. The

second AKA date holds historical information

such as a previously recorded date of birth. The


DDVKD3 DRIVER AKA 3RD DATE OF BIRTH

CLMF-DOB-AKA3

AN


third AKA date holds historical information

such as a previously recorded date of birth. The


DDVKDB DRIVER AKA DATE OF BIRTH

CLMF-DOB-AKA1

AN


AKA data holds historical information such as a

previously recorded date of birth. The date

format is CCYYMMDD.

DDVKN2 DRIVER AKA 2ND NAME

CLMF-NAME-AKA2

AN

35 The second name by which a driver may be

known other than the currently used name.

See the AAMVA Person Name Formatting

Rules for the complete set of rules governing

the format of a person's name.




Element

Code


/Len


DDVKN3 DRIVER AKA 3RD NAME

CLMF-NAME-AKA3

AN

35 The third name by which a driver may be

known other than the currently used name.




DDVKNM DRIVER AKA NAME

CLMF-NAME-AKA1

AN

35 A name by which a driver may be known other

than the currently used name.




DDVKSS DRIVER AKA SOCIAL SECURITY

NUMBER

CLMF-CODE-SSN-AKA1

AN

9 An AKA recorded Social Security Number for

a driver.

A standard SSN is assigned to an individual by

the Social Security Administration.

In addition to standard SSNs, CDLIS uses

pseudo and substitute SSNs.

A CDLIS pseudo SSN is an invented SSN

assigned to a driver by a state when the state

was not, for some reason, able to obtain a SSN.

Pseudo SSNs begin with "000". Every state has

an assigned range of pseudo SSNs available to

it. This range can be found in the CDLIS State

Procedures Guide.

A CDLIS substitute SSN ("999-99-9999") is

used only when a non-CDL driver has been

convicted of a CMV violation, and no SSN was

provided or available for that driver.


NUMERIC VALUES WHEN

PRESENT

DDVMED DRIVER MEDICAL HISTORY

INDICATOR

CLMF-INDC-MED-HX

AN

1 This field indicates whether a state or

province medical history file exists. The

presence of a file, does not necessarily

indicate there is a medical issue.





Element

Code


/Len


1 Yes (Medical file exists)

2 No (No medical file)

DDVNAM DRIVER NAME

CLMF-NAME-CURRENT

AN

35 The full name of the driver.




DDVNM1 DRIVER OLD NAME

CLMF-NAME-OLD-PRIMARY

AN

35 The old name of the driver.




DDVNM3 DRIVER DUPLICATE NAME

CLMF-NAME-DUPE

AN

35 A duplicate name of a driver.




DDVRAD DRIVER RESIDENCE ADDRESS

CLMF-DRVHIST-RESIDE-ADDR

AN

71 The place where the driver resides.

The address is delimited as follows:

Address Element # Maximum Length

Characters

Street Address A 20 + 1 for separator

A/N

Street Address B 20 + 1 for separator

A/N

City or Town 15 + 1 for separator

A/N

State Code 2 + 1 for separator

A/N

Zip Code 9 + 1 for delimiter

A/N

Allow @ as separator and ; as ending delimiter.

Unused character positions can not be used to

extend the maximum length of any address

element.




Element

Code


/Len


DDVSEX DRIVER SEX

CLMF-CODE-SEX

AN

1 The sex of a driver.


0 Unknown

1 Male

2 Female

9 Not specified

DDVSS0 DRIVER SSN START RANGE

CLMF-SSN-START

AN

9 A unique number assigned by the Social

Security Administration to an individual, who is

a driver. The Start Range indicates the SSN

with the lowest value, when describing a

number of drivers.


NUMERIC VALUES WHEN

PRESENT

DDVSS1 DRIVERS OLD SOCIAL SECURITY

NUMBER

CLMF-NUMB-SSN-OLD-PRIMARY

AN

9 The drivers old SSN, which is the unique

number assigned by the Social Security

Administration to an individual.






Every state has an assigned range of pseudo

SSNs available to it. This range can be found

in the CDLIS State Procedures Guide. Pseudo

SSNs begin with "000".






NUMERIC VALUES WHEN

PRESENT

DDVSS2 DRIVERS DUPLICATE SSN

CLMF-CODE-SSN-DUPE

AN

9 The duplicate number describes an additional

number.

The number assigned to an individual, who is




Element

Code


/Len


the driver of a vehicle, by the Social Security

Administration.















NUMERIC VALUES WHEN

PRESENT

DDVSS6 DRIVER SSN - CDLIS

CLMF-CODE-SSN-CURRENT

AN

9 The unique number assigned to an individual,

who is the driver of a vehicle, by the Social

Security Administration.















NUMERIC VALUES WHEN

PRESENT




Element

Code


/Len


DDVSS9 DRIVER SSN END RANGE

CLMF-SSN-END

AN

9 A unique number assigned by the Social


a driver. The End Range indicates the SSN

with the highest value, when describing a

number of drivers.


NUMERIC VALUES WHEN

PRESENT

DDVSSI DRIVER SSN TYPE

CLMF-SSN-TYPE

AN

1 The type of SSN associated with the driver.


A SSA-Assigned SSN - Assigned by the

Social Security Administration

S Substitute SSN - Has a value of "999-99-

9999" and is used only when a non-CDL driver

has been convicted of a CMV violation, but no

SSN was provided or available for that driver.

P Pseudo SSN - Has a value of "000-nn-

nnnn" and is used only when the driver isn't

required by SSA to have an SSN. (ie SSA has

issued a waiver for religious reasons or a non-

resident is issued a CDL) AAMVA assigns a

unique range of pseudo SSN values to each

state for their use.

DDVSSN DRIVER SOCIAL SECURITY NUMBER

CLMF-CODE-SSN-CURRENT

AN

9 The unique number assigned by the Social


a driver.


NUMERIC VALUES WHEN

PRESENT

DDVSX2 DRIVER DUPLICATE SEX

CLMF-DUP-CODE-SEX

AN

1 This element describes a duplicate code for the

sex of a driver.


0 Unknown

1 Male

2 Female

9 Not specified

DDVSX3 DRIVER CURRENT SEX

AN

1 The current sex of a driver.




Element

Code


/Len


CLMF-CUR-CODE-SEX


0 Unknown

1 Male

2 Female

9 Not specified

DDVWT3 DRIVER CURRENT WEIGHT

CLMF-CUR-DESC-WEIGHT

AN

3 The weight of an individual driver in pounds.


NUMERIC VALUES WHEN

PRESENT

DDVWT4 DRIVER DUPLICATE WEIGHT

CLMF-DUP-DESC-WEIGHT

AN

3 The duplicate measurement of the weight of an

individual driver in pounds.


NUMERIC VALUES WHEN

PRESENT

DMCCTC MEDICAL CERTIFICATION STATUS

CODE

CLMF-MED-CERT-STATUS-CODE

AN

1 An indication of the status of a driver's medical

certification.


C The driver is certified.

N The driver is not certified.

DMCEDT MEDICAL CERTIFICATE

EXPIRATION DATE

CLMF-MED-CERT-EXP-DATE

AN

8 A date on which a medical certificate expires.


DMCPED MEDICAL CERTIFICATE ISSUE DATE

CLMF-MED-CERT-ISS-DATE

AN

8 A date on which a medical practitioner

performed an examination and on which a

medical certificate was subsequently issued.


DMCRES MEDICAL CERTIFICATE

RESTRICTION CODE

CLMF-MED-CERT-RESTRICTION

AN

1 A restriction imposed on a driver by a medical

examiner.


1 Wearing corrective lenses

2 Wearing hearing aid




Element

Code


/Len


3 Accompanied by a waiver/exemption

4 Driving within an exempt intra city zone

5 Accompanied by a Skill Performance

Evaluation certificate (SPE)

6 Qualified by operation of 49 CFR

391.64

DTHTSD DRIVER TSA HME THREAT

DETERMINATION

CLMF-TSA-HME-DETERMINATION

AN

1 A code indicating if a driver should be issued a

HAZMAT Endorsement, as determined by the

TSA adjudication process.


0 No security threat, issue/renew/transfer

HME

1 Final determination of security threat, do

not issue/renew/transfer HME

2 IMMEDIATE REVOCATION,

IMMEDIATELY REVOKE HME

DWDCLG DL WITHDRAWAL CONVICTIONS

LINKS GRP

CLMF-WD-CONV-LINK-GRP

AN

28 A group of conviction identifiers that

contributed to the withdrawal. This composite

element may hold up to 14 occurrences of the

2-character conviction identifiers.

DWDDWD DRV LIC WITHDRAWAL EFFECTIVE

DATE

CLMF-DATE-WDRAW

AN

8 The date on which a driver license withdrawal

becomes effective. The date format is

CCYYMMDD.

DWDJUR JURISDICTION CODE -

WITHDRAWING

CLMF-CODE-WDRAW-JUR

AN

2 The jurisdiction that withdrew driving

privileges for a driver.



values.

DWDWBS DRIVER LICENSE WITHDRAWAL

BASIS

CLMF-CODE-WDRAW-BASIS

AN

1 The basis for the withdrawal action for a

driver.


0 Unknown

1 Conviction

2 Administrative Adjudication

3 Administrative Action




Element

Code


/Len


4 Repeated Violations

5 Withdrawal resulting from point system

6 Court ordered or requested

7 Court recommended

8 NRVC Action or Reciprocity

9 Administrative Per Se

DWDWDE DRV LIC WITHDRAWAL

ELIGIBILITY DATE

CLMF-DATE-WDRAW-ELIG

AN

8 The date on or after which a driver is eligible to

apply for reinstatement of those driving

privileges withdrawn.

If the privilege is never to be restored, the

permanent code is used.

For jurisdictions that withdraw a license

privilege but do not start the clock until the

license is physically surrendered, or if the

length of the withdrawal is predicated on the

individual completing one or more actions, they

will not be able to provide an actual eligibility

date. In such cases the indefinite code is used.


ccyymmdd A date indicating the

actual date

'INDEF' Indefinite

'PERM' Permanent

DWDWDR DL WITHDRAWAL REINSTATEMENT

DATE

CLMF-DATE-WDRAW-REINST

AN

8

The date that the licensing privilege of a

driver (which has been previously

withdrawn) is reinstated. The date format

is CCYYMMDD.

DWDWEX DRV LIC WITHDRAWAL EXTENT ID -

DLC

CLMF-CODE-WDRAW-EXTENT

AN

1 This field identifies a particular withdrawal

extent. A withdrawal extent identifies the

portion of driving privileges being withdrawn,

such as the Commercial Privilege Type, or

non-Commercial (Base) Privilege Type, or

a specific Permit. It is only applicable for a

DLC Withdrawal.





Element

Code


/Len


1 Commercial

2 Permit

3 All

4 Non-CDL

DWDWI2 DL WITHDRAWAL ID - CONVICTION

LINK

CLMF-WD-ID-CODE-LINK

AN

2 The identifier of the withdrawal, arbitrarily

assigned by the Jurisdiction of Record. This

identifier is used to link the convictions to the

underlying withdrawal.

DWDWID DRIVER LICENSE WITHDRAWAL ID

CODE

CLMF-WD-ID-CODE

AN

2 The identifier of the withdrawal, arbitrarily

assigned by the Jurisdiction of Record.

DWDWLO DL WITHDRAWAL JURISDICTION

REPORT ID

CLMF-CODE-WDRAW-LOC

AN

18 The Jurisdiction of Withdrawal's unique

identifier for the withdrawal of the driver that

the Jurisdiction of Withdrawal uses to access its

report of the withdrawal. The identifier may be

a reference to a record in a file, a database or a

microfilm. It is sometimes referred to as the

"Driver License Withdrawal Locator

Reference".

DWDWPS DL WITHDRAWAL DUE PROCESS

STATUS

CLMF-CODE-WDRAW-DUE-PROC-

STAT

AN

1 The due process status for a withdrawal

action.


0 Not defined

1 Hearing held; action confirmed

2 Hearing offered but not requested

3 Hearing requested; not yet held

4 Department action appealed to court

5 Hearing not applicable

DWDWRR DRV LIC WITHDRAWAL REASON

REFERENCE

CLMF-CODE-WDRAW-REF

AN

8 A native state code that specifies a withdrawal

reason for future reference by the original State

of record.

DWDWRS DRV LIC ACD WITHDRAWAL

REASON CODE

CLMF-CODE-WDRAW-REASON

AN

3 The reason for the withdrawal of a driver

license and/or driving privilege.






Element

Code


/Len


DWDWTP DRIVER LICENSE WITHDRAWAL

TYPE

CLMF-CODE-WDRAW-ACTION-TYPE

AN

1 The type of driver license withdrawal action

that was taken.


1 Revoked

2 Barred

3 Suspended

4 Canceled

5 Denied

6 Disqualified

7 Other Withdrawal

GAPPID APPLICATION ID

CLMF-CODE-NET-APPL-ID

AN

2 The Application ID uniquely identifies an

application used by a site to exchange

information with another site through

AAMVAnet.


'01' (Old NDR)

'02' CDLIS

'03' DLR

'04' AAMVAnet

'05' SR22/26

'06' RRT

'07' E/MCO

'08' RLA

'09' (Old NRVC)

'10' ELT

'11' NMVTIS release 1

'12' PDPS

'13' BPEVR

'14' PRISM AMIE

'15' DVD

'16' VI

'17' SSOLV

'18' PRISM X12

'19' EDL

'20' SSR

'21' NLETS Driver Queries

'22' NMVTIS release 2

'23' PPI for NMVTIS

'24' EVVER




Element

Code


/Len


'25' AID

'26' ENS

'27' VIN Ping

'28' VLS

'29' Consumer Access

'99' IBM KIOSK

GAPPST APPLICATION STATUS

CLMF-CODE-APPL-STATUS

AN

1 The Application Status defines the status of an

application. It must be filled in when

responding to a message.


' ' Outbound message default

'0' Status OK

'1' Application inactive

'2' Application invalid

'3' Application security error

'9' Application window closed

GBKN01 BLOCK NUMBER OF 1ST 01 BLOCK

AMIE-BLOCK01-COUNT

N

2 Block number of first 01 block.


AMIE-BLOCK02-COUNT

N



AMIE-BLOCK04-COUNT

N



AMIE-BLOCK09-COUNT

N



AMIE-BLOCK10-COUNT

N



AMIE-BLOCK11-COUNT

N





Element

Code


/Len



AMIE-BLOCK14-COUNT

N



AMIE-BLOCK15-COUNT

N



AMIE-BLOCK16-COUNT

N



AMIE-BLOCK17-COUNT

N



AMIE-BLOCK18-COUNT

N



AMIE-BLOCK19-COUNT

N



AMIE-BLOCK20-COUNT

N



AMIE-BLOCK23-COUNT

N



AMIE-BLOCK24-COUNT

N



AMIE-BLOCK25-COUNT

N


GEROUT ERROR BLOCK OUT

CLMF-DESC-ERROR-BLOCK-OUT

AN

61 The AMIE block that contains the error

information.




Element

Code


/Len


GLSEGI LAST SEGMENT INDICATOR

CLMF-INDC-NCB-LAST-SEG

AN

1 When there is too much data to fit into a single

message, the message is split into multiple

segments. The Last Segment Indicator

specifies whether or not this is the last segment

for the message.


'Y' Yes this is the last segment

'N' No this is not the last segment

GMSCDL MESSAGE AKA DLN COUNT

CLMF-MEC-CNT-DLN

AN

1 For messages that can contain AKA DLNs, this

indicates how many AKA DLNs are being sent.


The values range from 0 to 3.

GMSCNM MESSAGE AKA NAME COUNT

CLMF-MEC-CNT-NAME

AN

1 For messages that can contain AKA names, this

indicates how many AKA names are being sent.


Values range from 0 to 3.

GMSCNT MESSAGE MATCH COUNT

CLMF-CNT-MEC-MATCH

AN

2 The Message Match Count represents the

number of matches that were found/requested in

a given transaction.


NUMERIC VALUES WHEN

PRESENT

GMSCSS MESSAGE AKA SSN COUNT

CLMF-MEC-CNT-SSN

AN

1 For messages that can contain AKA SSNs, this

indicates how many AKA SSNs are being sent.


0 No AKA SSNs

1 One AKA SSN

GMSDAT MESSAGE DATE

CLMF-DATE-NCB-MSG

AN

6

The Message Date represents the date that the

message was sent. The format is YYMMDD.

GMSDST MESSAGE DESTINATION

AN

7 The Message Destination contains the network

ID of the destination of the message.




Element

Code


/Len


CLMF-CODE-MSG-DEST

GMSDUP MESSAGE DRIVER DUPLICATE

INDICATOR

CLMF-INDC-MEC-DUPE-FLAG

AN

1 This field is used to indicate whether or not the

driver identified in the message has been

flagged as a possible duplicate.


Y The driver is flagged as a possible

duplicate

N The driver is not flagged

GMSFMS MESSAGE FIRST MATCH SEQUENCE

ID

CLMF-1ST-MATCH-SEQ-ID

AN

2 A match sequence ID is the sequence in which

matches are found at a central site or site of

record. The first match sequence ID is the ID

of the first of the matches to be returned in a

response.


NUMERIC VALUES WHEN

PRESENT

GMSIND MESSAGE MATCH INDICATOR

CLMF-INDC-MEC-MATCH

AN

1 The Message Match Indicator specifies whether

or not a match was found for a given message.


Y Yes, a match was found.

N No, a match was not found.

GMSIRL IMPLEMENTATION RELEASE CODE

NONE

AN

2 The identifier indicating at what release a

given participant is authorized to perform a

particular function.


41 CDLIS Release 4.1.0

51 CDLIS Release 5.1.0

GMSLEI MESSAGE MATCH LIMIT EXCEEDED

IND

CLMF-INDC-MEC-MATCH-LIMIT-EX

AN

1 The Message Match Limit Exceeded Indicator

specifies whether or not the number of matches

found for a given message exceeds the system

threshold.


'Y' The maximum threshold of matches was

exceeded.

'N' The maximum threshold of matches was




Element

Code


/Len


not exceeded.

GMSLEN MESSAGE LENGTH

CLMF-NUMB-NCB-MSG-LEN

AN

4 The Message Length specifies the length of the

Network Message in bytes.

The length is calculated as:

((Number of Text blocks + 1) * 66 )

GMSLMI LAST MATCH INDICATOR

CLMF-INDC-MEC-LAST-MATCH

AN

1 This element is used to indicate whether a

message contains the last match to be returned

for an inquiry. (i.e. is more data coming or is

this the final group of data).


N Not the last match

Y The last match

GMSLOC MESSAGE LOCATOR/HEADER

CLMF-DESC-MEC-MSG-LOCATOR

AN

26 The Message Locator/Header contains

information necessary to match up

confirmations and/or responses to their

respective originating messages.

The originator of the initial message in a

transaction sets a value in the locator.

Subsequent messages in the transaction pass

along the locator from the original message.

The locator generated by UNI is composed of:

- date - 6 bytes

- time - 6 bytes

- sequence - 4 bytes

- spaces - 4 bytes

- message splitting destination count - 1 byte

- "UNI" - 3 bytes

- initial message type in transaction - 2 bytes

GMSMSI MESSAGE MATCH SEQUENCE ID

CLMF-NUMB-MEC-MATCH-SEQ-ID

AN

2 The Message Match Sequence Id represents the

match identifier of a record found at a central

site or site of record. It is used for multiple

responses to an inquiry. The first response

contains "01", the second contains "02", etc.

The same identifier is applied to all pointer and

history messages for a particular match. So if

the data for a given match is returned on

multiple messages, all the messages returning

data for that match will have the same sequence




Element

Code


/Len


ID.


NUMERIC VALUES WHEN

PRESENT

GMSORG MESSAGE ORIGIN

CLMF-CODE-ORIGIN

AN

7 The Message Origin contains the network ID of

the site from which the message was originally

sent.

GMSPSW MESSAGE SENDER PASSWORD

CLMF-CODE-MEC-PASSWORD

AN

7 This field must contain a valid password for the

sender of the message as applicable to the

AAMVA system being used.

GMSSCH MESSAGE SOR CHANGE IN

PROGRESS IND

CLMF-INDC-MEC-CHANGE-SOR

AN

1 This field is used to indicate whether or not a

"Change State of Record" is in progress for a

Master Pointer Record (MPR).


Y Yes, a CSOR has been initiated but not

completed

E Yes, a CSOR has been initiated but an

error occurred preventing its completion

N No, a CSOR is not currently in progress

GMSSEQ MESSAGE SEQUENCE ID

CLMF-DESC-NCB-MSG-SEQ-ID

AN

4 The Message Sequence ID is used to uniquely

identify a given message from all others

generated by the same originator within the

same second.


NUMERIC VALUES WHEN

PRESENT

GMSSOR JURISDICTION CODE - STATE OF

RECORD

CLMF-CODE-MEC-SOR

AN

2 The U.S. Postal code or the code for Canada or

Mexico for the jurisdiction considered to be the

"state of record" for a particular message.



values.

GMSSRL SYSTEM RELEASE CODE

AN

1 The identifier indicating the release of a

system that the message is using.




Element

Code


/Len


CLMF-SYSTEM-REL-CODE


space CDLIS Release 2.0.0

F CDLIS Release 4.0.0 or later

H CDLIS Release 4.0.0 or later, with

support for TSA Threat Determination and

HME Expirations

GMSSYR MESSAGE SEARCH YEAR RANGE

CLMF-SEARCH-YEAR-RANGE

AN

2 A number of years before and after a date, on

which a search is performed. So if a range of 2

years is specified for the year 1966, the search

range will be 1964 to 1968.

GMSTIM MESSAGE TIME

CLMF-TIME-NCB-MSG

AN

6 The Message Time contains the time the

message was sent. The format is HHMMSS,

where HH can be 00 to 23.

GMSTYP MESSAGE TYPE

CLMF-CODE-MSG-TYPE

AN

2 The Message Type uniquely identifies the kind

of message within the given application.

GNBTXT NUMBER OF TEXT BLOCKS COUNT

CLMF-CNT-NCB-NUM-TXT-BLKS

AN

2 The Number of Text Blocks Count contains the

count of the number of text blocks within the

given text pool. It does NOT include the NCB

block, so the value will range from 0 to 54.

For example, if the message contains an NCB, a

Message Exchange Control Block, and a

Vehicle Identification Block, this field will

contain a value of '02'.


NUMERIC VALUES WHEN

PRESENT

GNCBER NCB ERROR CODE

CLMF-CODE-NCB-ERROR

AN

1 The NCB Error Code is a flag to indicate

whether an error has been detected on a given

message. The field is also used to indicate that

the message could not be delivered to its

destination.


'N' No error, this is the default value.

'Y' Error, detected by application or network

interface.

'U' Undeliverable (set by the network).




Element

Code


/Len


GNETSI NETWORK SESSION INDICATOR

CLMF-INDC-NET-SESSION

AN

1 The Network Session Indicator specifies

whether or not the message is sent through

NCS.


'Y' Yes

'N' No

GNETST NETWORK STATUS

CLMF-CODE-NET-STATUS

AN

2 The Network Status contains the status of the

network. This value is entered by NCS or by

UNI.


' ' Outbound message default

'00' Status Ok

'01' Destination inactive

'02' Destination not registered

'03' Destination not defined

'04' Origin error

'05' Message length error

'06' Billing ID error

'07' Received undeliverable

'08' Invalid message ID

'11' TRAC/NCS down

'98' Network window closed

'99' Local network down

GPROST PROCESSING STATUS

CLMF-CODE-MEC-PROCESS-STATUS

AN

2 This field indicates the status of the transaction.

A value of zero indicates that there is no error

in the message. A value other than zero will

indicate an invalid process (e.g. record not

found, syntax error or any other application

error). The non-zero values are defined within a

given application.


*** ALL APPLICATIONS ***

'00' Processing successful

*** MOST APPLICATIONS ***

* (all applications except 02, 05 & 12) *

'01' Processing unsuccessful




Element

Code


/Len


*** CDLIS (02) ***

'01' Logic error (such as record not found)

'02' System error (such as file off-line)

'03' Syntax error (edit errors)

'04' Security Exception

'05' Confirmation of new SOR, but DHR not

ready

'06' Message sent outside of CDLIS processing

window

*** SR22/SR26 (05) ***

'01' Syntax error detected

'02' Driver record not found by jurisdiction

'03' Driver found; SR22/26 not pertinent;

Record not updated

'04' Driver found; SR22/26 not pertinent;

Record updated

'05' Driver record found; SR22/26 is duplicate

'06' Security violation (not authorized to send)

'07' Insufficient identifiers; cannot search

driver record

*** PDPS (12) ***

'01' Logic error (such as record not found)

'02' System error (such as file off-line)

'03' Syntax error for DLN Survey only

*** ESI ***

'76' User is not a valid originator

'77' Destination is not a valid receiver

'78' Invalid message number

'79' Invalid block number

'80' Invalid error code

'81' Out of sequence text blocks

'82' Actual number of text blocks does not

match the count in the NCB block

'83' Network is down

GRCAOD RECORD AS OF DATE

CLMF-REC-AS-OF-DATE

AN

8 A date on which a record was current.


GRCAOT RECORD AS OF TIME

AN

6 A time at which a record was current.

The time format is HHMMSS.




Element

Code


/Len


CLMF-REC-AS-OF-TIME

GRCCDT RECORD CREATION DATE

NONE

AN

8 The Record Creation Date is the date that the

given record was first added.

GRCCNT RECORD COUNT

CLMF-REC-COUNT

AN

10 A count of the number of records in a file.


NUMERIC VALUES WHEN

PRESENT

GRCCTM RECORD CREATION TIME

NONE

AN

6 The Record Creation Time is the time that the

given record was created.

GRCDDT DRIVER DATA RECORD TYPE

CLMF-DRIVER-DATA-TYPE

AN

1 An indicator that specifies the type of a record.


1 MPR

2 DHR

GRCUDT DATE OF LAST UPDATE

NONE

AN

8 The Date of Last Update is the date that the

given record was last updated. When initially

created, the creation date is reflected in this

field.

GRCUTM TIME OF LAST UPDATE

NONE

AN

6 The Time of Last Update is the time that the

given record was last updated. When initially

created, the creation time is reflected in this

field.

GRRECV RETURN AS RECEIVED TEXT/BLOCK

CLMF-DESC-RETURN-AS-RECEIVED

AN

61 A free-form text block that is used to return

data in the same format as it was received.

GSGSEQ SEGMENT SEQUENCE NUMBER

CLMF-NUMB-NCB-SEG

AN

2 If a message is too large to be contained in one

segment, it is split into multiple segments. The

Segment Sequence Number is used to specify

which, in a possible series of segments, is

current.


NUMERIC VALUES WHEN




Element

Code


/Len


PRESENT

GTPIND TEST/PRODUCTION INDICATOR

CLMF-INDC-TST-PROD

AN

1 The Test / Production Indicator specifies

whether to route the message to Test or

Production at the site.


'T' Test

'P' Production

GTRORG TRANSACTION ORIGINATOR

CLMF-CODE-NCB-TRANS-

ORIGINATOR

AN

7 The Transaction Originator contains the

network ID of the site that originated the

transaction. On the initial message in a

transaction, it contains the origin of the

message. On subsequent messages in the

transaction the value from the original message

is passed along.

GTXNPR TRANSACTION CODE

CLMF-DESC-NCB-TXN-PROG

AN

4 The Transaction Code defines a specific

transaction for NCS. It is no used by UNI users.

Non-UNI users only use it on certain platforms.

GXMODC TRANSMIT MODE CODE

CLMF-CODE-NCB-XMIT-MODE

AN

1 The Transmit Mode Code indicates the type of

network service used during the transmission.


'1' NCS

'2' Information Exchange

'3' Batch


APPENDIX E Ŕ PERSON NAME FORMATTING 672


APPENDIX E – PERSON NAME FORMATTING

APPENDIX E.1 – AAMVA PERSON NAME FORMATTING RULES

The information contained in ŖAppendix E.1 - AAMVA Person Name Formatting Rulesŗ reflects the AAMVA person

name formatting rules as they pertain to the CDLIS System Specifications (Release 4.1). ŖAppendix E.1 - AAMVA

Person Name Formatting Rulesŗ is being retained only for backward compatibility purposes.

New standards become effective with the implementation of the CDLIS System Specifications (Release 5.1) and are

reflected in ŖAppendix E.2 Ŕ AAMVA Person Name Standard (2008)ŗ.

E.1.1 Rules for Delimiting Components within the Name Field

The Name field contains four components, separated with the "@" character:

Last Name (required)

@ (required)

First Name (required)

@ (required if other name components follow, otherwise optional)

Middle Name (optional)

@ (required if other name components follow, otherwise optional)

Suffix Code (optional)

@ (optional)

Title and Prefix components are not used.

Trailing delimiters are optional.

Valid Formats:

LAST@FIRST@@@

o An "@" delimiter embedded between the Last Name and First Name components is required. Trailing

delimiters are optional.

LAST@FIRST@MIDDLE@@

o If the Middle Name component is submitted, two embedded delimiters are required. Trailing delimiters

are optional.

LAST@FIRST@MIDDLE@JR@

o If Middle Name and Suffix Code components are submitted, three embedded delimiters are required.

Trailing delimiter is optional.

LAST@FIRST@@JR@

o If a Suffix Code component is submitted and a Middle Name component is not, three embedded

delimiters are required. The trailing delimiter is optional. (If the second or third embedded delimiter is

omitted, the Suffix Code component is treated as a middle name and is subject to Middle Name

component validation rules discussed later.)

Invalid Formats:

LAST@FIRST@MIDDLE@JR@@

o The delimiter occurs more than 4 times.

LAST@FIRST@MIDDLE@JR@X

o A non-blank value occurs after the fourth delimiter.

LAST@ FIRST@MIDDLE@JR

o The First Name component has a leading space.

LAST@FIRST@MIDDLE @JR




o The Middle Name component has a trailing space.

E.1.2 Field Length and Truncation Rules

The full Name field has a maximum length of 35 characters including the delimiters (e.g.,

SMYTHE@JOHN@WILLIAM JAMES ROBERT@JR => 35 characters). The name components, their lengths and an

example of the maximum length, are shown below:

Last Name: 1 to 33 characters

o LASTNAMEXXXXXXXXXXXXXXXXXXXXXXXXX@F

First Name: 1 to 33 characters

o L@FIRSTNAMEXXXXXXXXXXXXXXXXXXXXXXXX

Middle Name: 0 to 31 characters

o L@F@MIDDLE NAMES XXXXXXXXXXXXXXXXXX

Suffix Code: 0, 2, or 3 characters

o LASTNAME@FIRSTNAME@MIDDLENAME@3RD

If the length of the full Name field exceeds 35 characters, the Suffix Code component (if any) must be truncated first, in

its entirety.

If the length of the Name field still exceeds 35 characters, truncation must continue with the right-most character of the

Middle Name component (if any) and proceed to the left. The first character of the Middle Name component (i.e., the

initial of the first middle name) must never be truncated.


First Name component and proceed to the left. The first character of the First Name component (i.e., the initial of the

first name) must never be truncated.


Last Name component and proceed until 35 total characters remain (including delimiters, first initial and middle initial,

if any). The first 31 characters of the Last Name component must never be truncated.

The following table illustrates these rules:

Rule

a Truncate whole Suffix Code

component first From FirstNm Two MidNm LastNameAbcdefgh Jr

To LASTNAMEABCDEFGH@FIRSTNM@TWO MIDNM

b Continue truncation with Middle

Name component, starting from

right

From FirstNm Two MidNm LastNameAbcdefghij Jr

To LASTNAMEABCDEFGHIJ@FIRSTNM@TWO MIDN

c Leave first character of Middle

Name component and continue

truncation with First Name

component, from the right

From FirstNm Two MidNm LastNameAbcdefghijklmnopqr Jr

To LASTNAMEABCDEFGHIJKLMNOPQR@FIRSTN@T

d Leave first characters of First

Name and Middle Name

components and continue

truncation with Last Name

component, from the right

From FirstNm Two MidNm

LastNameAbcdefghijklmnopqrstuvwxyz Jr

To LASTNAMEABCDEFGHIJKLMNOPQRSTUVW@F@T




E.1.3 Validation Rules

E.1.3.1 All components of the Name

All characters are in upper case.

E.1.3.2 Last Name component

The Last Name component contains only alphabetic characters and up to one embedded hyphen (e.g., John Smith-Jones

=> SMITH-JONES@JOHN). Characters such as second hyphens, apostrophes, or spaces must be deleted when the Last

Name component is coded. If the person only has a first name, the first name is coded in the Last Name and First Name

components (e.g., Madonna => MADONNA@MADONNA).


Rule

a Only one embedded hyphen

allowed

From FirstName Last-Na-me

To LAST-NAME@FIRSTNAME

b No leading hyphen allowed From FirstName ŔLastName

To LASTNAME@FIRSTNAME

c No trailing hyphen allowed From FirstName LastName-


d No apostrophes allowed From FirstName La'Name

To LANAME@FIRSTNAME

e No spaces allowed From FirstName Last Name


f No numbers allowed From FirstName Last9Name


g Last Name component required From OnlyOneNameUsed

To ONLYONENAMEUSED@ONLYONENAMEUSED




E.1.3.3 First Name component

The First Name component contains only alphabetic characters. Any non-alphabetic characters, such as hyphens,

apostrophes, and spaces, must be deleted when the First Name component is coded. If the person only has a last name,

the last name is coded in the Last Name and First Name components, with all non-alphabetic characters deleted in the

First Name component (e.g., Johnson-Levy => JOHNSON-LEVY@JOHNSONLEVY).


Rule

a No hyphens allowed From Fir-st-Name LastName


b No apostrophes allowed From First'Name LastName


c No spaces allowed From First Name LastName


d No numbers allowed From First9Name LastName


e First Name component required From LastNameOnly

To LASTNAMEONLY@LASTNAMEONLY

f First Name component required,

no hyphens allowed

From Last-NameOnly

To LAST-NAMEONLY@LASTNAMEONLY

g First Name component required From OnlyOneNameUsed

To ONLYONENAMEUSED@ONLYONENAMEUSED

E.1.3.4 Middle Name component

The Middle Name component, if submitted, contains only alphabetic characters and spaces. Single or multiple middle

names may be coded. Use one space between multiple middle names (e.g., Regina Nicole Mary Alice Smith =>

SMITH@REGINA@NICOLE MARY ALICE). Other characters such as apostrophes or hyphens must be deleted when

the Middle Name component is coded.


Rule

a One space between middle names

required

From First MidNameOne MidNameTwo Last

To LAST@FIRST@MIDNAMEONE MIDNAMETWO

b Hyphen not allowed From First Mid-Name Last

To LAST@FIRST@MIDNAME

c Apostrophe not allowed From First Mid'Name Last


d Numbers not allowed From First Mid9Name Last


e First Name component required From MidName Last





E.1.3.5 Suffix Code component

The Suffix Code component, if submitted, can contain only the Suffix Codes shown in the following table (e.g., Andrew

Johnson, III => JOHNSON@ANDREW@@3RD):

Suffix Meaning or Synonym

JR Junior

SR Senior or Esquire

1ST First

2ND

Second

3RD

Third

4TH

Fourth

5TH

Fifth

6TH

Sixth

7TH

Seventh

8TH

Eighth

9TH

Ninth

E.1.4 Examples of Atypical Names

Name: Honorable Roy A Bean, Esquire (a full name that contains a title; this name component is not used)

Representation: BEAN@ROY@A@SR

Name: John Joseph Patrick Smith Jr. (two middle names and a suffix)

Representation: SMITH@JOHN@JOSEPH PATRICK@JR

Name: John Smith II (a suffix and no middle name)

Representation: SMITH@JOHN@@2ND

Name: Rainmaker-Jolly (a last name only-must be used as the Last Name and First Name components)

Representation: RAINMAKER-JOLLY@RAINMAKERJOLLY

Name: Madonna (a first name only- must be used as the Last Name and First Name components)

Representation: MADONNA@MADONNA

Name: John I (a single-letter last name)

Representation: I@JOHN

Name: JR Smith (a first name that consists of two letters resembling initials)

Representation: SMITH@JR

Name: Jonathan Jehosephat Jingleheimer Smith Jr. (a long full name that requires truncation of the coded Suffix Code

and Middle Name components)

Representation: SMITH@JONATHAN@JEHOSEPHAT JINGLEHEI

Name: Jonathan Benjamin Jehosephatty-Jingleheimer (a long full name that requires truncation of the coded First Name

and Middle Name components)

Representation: JEHOSEPHATTY-JINGLEHEIMER@JONATHA@B




APPENDIX E.2 - AAMVA PERSON NAME STANDARD (2008)

The information contained in ŖAppendix E.2 Ŕ AAMVA Person Name Standard (2008)ŗ reflects the new AAMVA

person name formatting rules as they pertain to the CDLIS System Specifications (Release 5.1) and greater. The new

rules replace those that are reflected in ŖAppendix E.1 - AAMVA Person Name Formatting Rulesŗ and become

effective with the implementation of the CDLIS System Specifications (Release 5.1).

E.2.1 Structure

Composite field names are used to represent various business name entities. Examples of composite field names

include the following:





Medical Examiner Name Group (BMPNGP)

Each composite field name is comprised of individual component fields as described below. Note that prefixes and

titles are not supported:

Group_Name: the composite field name

o First_Name: up to 40 characters

o Middle_Name(s): up to 35 characters

o Last_Name: up to 40 characters

o Suffix: up to 5 characters

o Truncation_Code for the First_Name field

o Truncation_Code for the Middle_Name(s) field

o Truncation_Code for the Last_Name field

o Transliteration_Code for the First_Name field

o Transliteration_Code for the Middle_Name(s) field

o Transliteration_Code for the Last_Name field

As an example, the Person Name Group (BPENGP) composite field is comprised of the following individual

component fields:


o Person First Name (BPENFT)

o Person Middle Name (BPENMD)

o Person Last Name (BPENLT)

o Person Suffix (BPENSX)

o Person First Name Truncation Code (PBENTF)

o Person Middle Name Truncation Code (BPENTM)

o Person Last Name Truncation Code (BPENTL)

o Person First Name Transliteration (BPENRF)

o Person Middle Name Transliteration (BPENRM)

o Person Last Name Transliteration (BPENRL)




E.2.2 Conventions

While composite field names are referenced in the process description sections of the specification, the associated

component fields are not. If a particular composite field is either required or optional on a given message, the

associated process description makes reference to the requirement in terms of the composite field only. Additional

reference to "APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008) VALIDATIONS" is made to ensure

that data content complies with the standards detailed in that section.

E.2.2.1 Example 1

As an example, Person Name Group (BPENGP) is required on the Search Inquiry (IM) message and is reflected in

ŖCD01.1.2 Transmission of Search Inquiry (IM) Messageŗ as follows:

The Search Inquiry (IM) message must include:


If Person Name Group (BPENGP) is not provided on the Search Inquiry (IM) message (determined because none of its

component fields is provided), the following error is returned as reflected in ŖCD01.2.2.2 Required Data Errorsŗ and no

additional validations specific to the Person Name Group (BPENGP) field are performed:



If, however, the Person Name Group (BPENGP) is provided on the Search Inquiry (IM) message (determined because

one or more of its component fields is provided), it will pass the Řrequired fieldř edit described above. Additional

validations are performed, however, based on the standards described in ŖAPPENDIX E.3 - AAMVA PERSON NAME

STANDARD (2008) VALIDATIONSŗ.

In this example, if the Person Name Group (BPENGP) component fields are populated as described below,


o Person First Name (BPENFT) set to Ř JANEř

o Person Middle Name (BPENMD) not provided

o Person Last Name (BPENLT) not provided

o Person Suffix (BPENSX) not provided

o Person First Name Truncation Code (PBENTF) set to ŘNř

o Person Middle Name Truncation Code (BPENTM) set to ŘNř

o Person Last Name Truncation Code (BPENTL) not provided

o Person First Name Transliteration (BPENRF) not provided

o Person Middle Name Transliteration (BPENRM) not provided

o Person Last Name Transliteration (BPENRL) not provided

the following error messages are returned:

'LAST NAME REQUIRED'

'INVALID SPACE AT LEFTMOST POSITION IN FIRST NAME'

'TRUNCATION IND NOT ALLOWED WITHOUT MIDDLE NAME'

'TRANSLITERATION IND REQUIRED FOR FIRST NAME'

E.2.2.2 Example 2

As a second example, Person AKA Name Group (BPENG3) is optional on the Search Inquiry (IM) message and is

reflected in ŖCD01.1.2 Transmission of Search Inquiry (IM) Messageŗ as follows:




The Search Inquiry (IM) message may optionally include:



If Person AKA Name Group (BPENG3) is not provided on the Search Inquiry (IM) message (determined because none

of its component fields is provided), there is no associated validation in ŖCD01.2.2.2 Required Data Errorsŗ and no

additional validations as described in ŖAPPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008)

VALIDATIONSŗ are performed.

If, however, Person AKA Name Group (BPENG3) is provided on the Search Inquiry (IM) message (determined

because one or more of its component fields is provided), the additional validations described in ŖAPPENDIX E.3 -

AAMVA PERSON NAME STANDARD (2008) VALIDATIONSŗ are performed to ensure that Person AKA Name

Group (BPENG3) meets the prescribed standards.

E.2.3 Field formatting

For the First_Name, Last_Name, Middle_Name(s) and Suffix fields the following characters are allowed:

A to Z

a to z

0 to 9

Special characters:

Name Character Name Character Name Character

Space Plus sign + Commercial at @

Exclamation mark ! Comma , Reverse solidus \

Quotation mark " Hyphen-minus - Low line _

Number sign # Full stop / Period . Grave accent `

Percent sign % Solidus / Left curly bracket {

Ampersand & Colon : Vertical line |

Apostrophe ' Semicolon ; Right curly bracket }

Left parenthesis ( Equals sign = Tilde ~

Right parenthesis ) Greater-than sign >

Asterisk * Question mark ?

In addition, the following formatting rules apply to the First_Name, Last_Name and Middle_Name(s) fields:

Uppercase, lowercase and mixed cases are allowed. For example, the First_Name fields "John", "JOHN" or

"john" are all valid and have the same meaning.

Trailing spaces are allowed but have no meaning. A trailing character is the character that appears at the

rightmost position in a field.

Leading spaces are not allowed. A leading character is the character that appears at the leftmost position in a

field.

Except for trailing spaces, a space character may not appear adjacent to another space character.

Name components that are longer than the allowed field lengths are truncated as described in the Truncation




section below.

Names in non-Latin characters are not supported.

Unsupported Latin characters are transliterated as specified in the Transliteration section below. If a character

does not have a transliterated equivalent, the character is dropped.

If an individual has only a single name, the name is stated in the Last_Name field. Other fields are omitted.

Any field not used is omitted.

Values for the Suffix field are limited to the following values:

JR (Junior)

SR (Senior)

1ST or I (First)

2ND or II (Second)

3RD or III (Third)

4TH or IV (Fourth)

5TH or V (Fifth)

6TH or VI (Sixth)

7TH or VII (Seventh)

8TH or VII (Eighth)

9TH or IX (Ninth)

Leading spaces are not allowed in the Suffix field, and except for trailing spaces, a space character may not appear

adjacent to another space character.

The Truncation_Code for the First_Name field is present if and only if the First_Name field is present.

The Truncation_Code for the Last_Name field is present if and only if the Last_Name field is present.

The Truncation_Code for the Middle_Name(s) field is present if and only if the Middle_Name(s) field is present.

The Transliteration_Code for the First_Name field is present if and only if the First_Name field is present.

The Transliteration_Code for the Last_Name field is present if and only if the Last_Name field is present.

The Transliteration_Code for the Middle_Name(s) field is present if and only if the Middle_Name(s) field is present.

If present, a Truncation_Code has to have one of the following values:

T: Field content truncated

N: Field content not truncated

U: It is unknown whether or not the field content is truncated. This value is used when transitioning from

the name format described in "APPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULES".

If present, a Transliteration_Code has to have one of the following values:

T: Field content transliterated

N: Field content not transliterated

U: It is unknown whether or not the field content is transliterated. This value is used when transitioning

from the name format described in "APPENDIX E.1 Ŕ AAMVA PERSON NAME FORMATTING RULES".

E.2.4 Truncation

For all name fields, characters are eliminated from a field in the following order until the name fits into the field:

Starting from the right and moving to the left, eliminate spaces adjacent to hyphens

Starting from the right and moving to the left, eliminate apostrophes

Starting from the right and moving to the left, eliminate any remaining characters, excluding:

o Hyphens




o Remaining spaces

o Characters immediately following a hyphen or a space.

For example, in the case where a person's middle names are "V'Erylongmiddlename01 V'Erylongmiddlename02 Marie

Ŕ Louise" (58 characters), the truncation sequence will progress as follows:

Remove spaces adjacent to hyphens, resulting in "V'Erylongmiddlename01 V'Erylongmiddlename02 MarieŔ

Louise" (56 characters)

Remove apostrophes, resulting in "VErylongmiddlename01 VErylongmiddlename02 MarieŔLouise" (54

characters)

Remove other characters as allowed, resulting in "VErylongmiddlename01 VErylongmi MŔL" (35 characters)

E.2.5 Transliteration

The table below lists the transliteration values used when converting names to the characters allowed.

# Character Description Transliteration

1 Á á A acute A

2 À à A grave A

3 Â â A circumflex A

4 Ä ä A diaeresis AE

5 Ã ã A tilde A

6 Ă ă A breve A

7 Å å A ring AA

8 Ā ā A macron A

9 Ą ą A ogonek A

10 ģ Ĥ C acute C

11 Ă ă C circumflex C

12 ĥ Ħ C caron C

13 Ą ą C dot accent C

14 Ç ç C cedilla C

15 Ð ħ Eth D

16 Ć ć D caron D

17 É é E acute E

18 È è E grave E

19 Ê ê E circumflex E

20 Ë ë E diaeresis E

21 Ě ě E caron E

22 Ċ ċ E dot accent E

23 Ć ć E macron E

24 Ę ę E ogonek E

25 Ĉ ĉ E breve E


26 Č č G circumflex G

27 Ğ ğ G breve G

28 Ď ď G dot accent G

29 Đ đ G cedilla G

30 Ĕ ĕ H bar H

31 Ē ē H circumflex H

32 I i I without dot

(Turkey)

I

33 Í í I acute I

34 Ì ì I grave I

35 Î î I circumflex I

36 Ï ï I diaeresis I

37 Ė ė I tilde I

8 Ġ i I dot accent I

39 Ę ę I macron I

40 Ĝ ĝ I ogonek I

41 Ě ě I breve I

42 Ğ ğ J circumflex J

43 Ġ ġ K cedilla K

44 Ł ł L slash L

45 Ĝ Ĝ L acute L

46 Ľ Ľ L caron L

47 Ļ Ļ L cedilla L

48 Ŀ Ŀ L dot L

49 Ń ń N acute N





50 Ñ ñ N tilde N

51 Ņ ņ N caron N

52 Ņ ņ N cedilla N

53 Ň ň Eng N

54 Ø ø O slash OE

55 Ó ó O acute O

56 Ò ò O grave O

57 Ô ô O circumflex O

58 Ö ö O diaeresis OE

59 Õ õ O tilde O

60 Ň ň O double acute O

61 ŉ Ŋ O macron O

62 ŋ Ō O breve O

63 ŉ Ŋ R acute R

64 ŋ Ō R caron R

65 ō Ŏ R cedilla R

66 ō Ŏ S acute S

67 ŏ Ő S circumflex S

68 Ń ń S caron S

69 ġ Ģ S cedilla S

70 ő Œ T bar T

71 ő Œ T caron T

72 ŏ Ő T cedilla T

73 Ú ú U acute U


74 Ù ù U grave U

75 Û û U circumflex U

76 Ü ü U diaeresis UE

77 œ Ŕ U tilde U

78 ŗ Ř U breve U

79 ŕ Ŗ U double acute U

80 œ Ŕ U ring U

81 ŕ Ŗ U macron U

82 ř Ś U ogonek U

83 ś Ŝ W circumflex W

84 Ý ý Y acute Y

85 ŝ Ş Y circumflex Y

86 Ÿ ÿ Y diaeresis Y

87 ŗ Ř Z acute Z

88 Ņ ņ Z caron Z

89 ř Ś Z dot Z

90 Þ þ Thorn (Iceland) TH

91 Æ æ ligature AE AE

92 Ĳ ĳ ligature IJ IJ

93 Œ œ ligature OE OE

94 ß ß double s

(Germany)

SS

A ʻ ʻ ʻokina (glottal

stop)

' (apostrophe)

Note 1: The table is based on the transliteration tables used by ICAO for passports, with the difference that each

character has only one transliterated value. The intent is to keep the table synchronized with the ICAO tables, but to do

so in an orderly and planned fashion

Note 2: When matching characters on source documentation to characters in the table, it is important to note that

different fonts may show the same character in different ways.




APPENDIX E.3 - AAMVA PERSON NAME STANDARD (2008) VALIDATIONS

A name is in conformance with this Appendix if all of the following are true:

It meets all the validations in the table below. If any of the validations are not met, the associated error text is

returned.

It complies with the structure, formatting, truncation and transliteration requirements rules in "APPENDIX E.2 -

AAMVA PERSON NAME STANDARD (2008)" (insofar as these rules are not already reflected in the table

below).

It is administered in compliance with "APPENDIX E.4 Ŕ NAMES STORED ON JURISDICTIONS'

SYSTEMS", if applicable.

# Validation Error text

1 If not empty, the First_Name, Middle_Name(s) and

Last_Name fields must contain only valid characters

'INVALID CHARACTER IN FIELD' where 'FIELD' is

'FIRST NAME', 'MIDDLE NAME' or 'LAST NAME' as

applicable

2 The Last_Name must be present 'LAST NAME REQUIRED'

3 The First_Name (if present), Middle_Name(s) (if

present) and Last_Name fields must not have a space

at the leftmost position

'INVALID SPACE AT LEFTMOST POSITION IN

FIELD' where 'FIELD' is 'FIRST NAME', 'MIDDLE

NAME' or 'LAST NAME' as applicable

4 The First_Name, Middle_Name(s) and Last_Name

fields must not contain adjacent space characters,

except for trailing spaces

'INVALID ADJACENT SPACES IN FIELD' where

'FIELD' is 'FIRST NAME', 'MIDDLE NAME' or 'LAST

NAME' as applicable

5 The Suffix field, if present, must contain one of the

defined values

'INVALID SUFFIX'

6 The Suffix field, if present, must not have a space at

the leftmost position

'INVALID SPACE AT LEFTMOST POSITION IN

SUFFIX'

7 The Suffix field, if present, must not contain adjacent

space characters, except for trailing spaces

'INVALID ADJACENT SPACES IN SUFFIX'

8 If present, a Truncation_Code must contain one of the

defined values

'INVALID TRUNCATION IND'

9 If present, a Transliteration_Code must contain one

of the defined values

'INVALID TRANSLITERATION IND'

10 The Truncation_Code for the Last_Name must be

present

'TRUNCATION IND REQUIRED FOR LAST NAME'

11 The Truncation_Code for the First_Name field must

be present if and only if the First_Name field is

present

'TRUNCATION IND REQUIRED FOR FIRST NAME'

or

'TRUNCATION IND NOT ALLOWED WITHOUT

FIRST NAME'

as applicable




# Validation Error text

12 The Truncation_Code for the Middle_Name(s) field is

present if and only if the Middle_Name(s)field is

present

'TRUNCATION IND REQUIRED FOR MIDDLE

NAME'

or

'TRUNCATION IND NOT ALLOWED WITHOUT

MIDDLE NAME'

as applicable

13 The Transliteration_Code for the Last_Name is

present

'TRANSLITERATION IND REQUIRED FOR LAST

NAME'

14 The Transliteration_Code for the First_Name field is

present if and only if the First_Name field is present 'TRANSLITERATION IND REQUIRED FOR FIRST

NAME'

or

'TRANSLITERATION IND NOT ALLOWED

WITHOUT FIRST NAME'

as applicable

15 The Transliteration_Code for the Middle_Name(s)

field is present if and only if the Middle_Name(s)field

is present

'TRANSLITERATION IND REQUIRED FOR MIDDLE

NAME'

or

'TRANSLITERATION IND NOT ALLOWED

WITHOUT MIDDLE NAME'

as applicable




APPENDIX E.4 – NAMES STORED ON JURISDICTIONS' SYSTEMS

Within technical limitations, names have to be retained in the same manner (including characters, spaces, apostrophes

etc.) as the name appears on the credential from which it was obtained.

The First_Name, Middle_Name(s), Last_Name, and Suffix fields must respectively accommodate at least 40, 35, 40 and

5 characters.

If name information has to be truncated to fit into the name fields stored by a Jurisdiction, the truncation rules specified

in "E.2.4 Truncation" have to be used. If name information has to be transliterated to remove non-supported Latin

characters, the transliteration rules specified in "E.2.5 Transliteration" have to be used.

Jurisdictions are encouraged to support extended character sets within their systems, especially those with significant

Spanish or French Canadian populations. However, when communicating with other jurisdictions, the transliteration

rule must be followed.


APPENDIX F ŔWITHDRAWAL IDS AND CONVICTION IDS 686


APPENDIX F –WITHDRAWAL IDS AND CONVICTION IDS

Introduction

A withdrawal must be linked in the DHR to any and all of its underlying ACD convictions, if the driver is required at

the time of the withdrawal effective date to have a pointer on CDLIS and the withdrawal effective date is on or after

November 1, 2005. The SOR is required to transmit or mail these linkages in history requests. When transmitting the

driver history in Change State-of-Record and State-to-State History Request transactions, the SOR must transmit a

linkage by transmitting: (1) the Withdrawal ID and underlying Convictions IDs in the H7 message; (2) the

corresponding Withdrawal ID in the H5 message; and (3) the corresponding Conviction IDs in the H3 message.

For example, assume the driver history has the following three withdrawal-convictions on record:

1-year withdrawal (W1) based on a DUI conviction (C1) 10 years ago.

60-day withdrawal (W2) based on an excessive speeding (C2) 3 years ago and a second excessive speeding (C3)

2 years ago.

120-day withdrawal (W3) based on the two excessive speeding convictions above plus a third excessive speeding

(C4) 1 year ago.

In this example, the SOR identifies the withdrawals and convictions in the history messages with sequential alpha-

numerical values. Then, the SOR identifies the three withdrawals in the H5 message (withdrawal ID values = "W1",

"W2", and "W3"); the four convictions in the H3 message (conviction ID values = "C1", "C2", "C3", and "C4); and the

three withdrawal-convictions in the 19/3 block H7 message with the data portion coded as shown below.

H3 message Conviction IDs

C1

C2

C3

C4

H5 message Withdrawal IDs:

W1

W2

W3

H7 message linkages:

W1C1

W2C2C3

W3C2C3C4

Design Rules for Reporting Linkages

To meet these driver history requirements for reporting linkages in a history response transaction, the SOR must choose

some method to identify each withdrawal, each underlying ACD conviction, and each withdrawal-conviction linkage on

its system. The two-character Withdrawal IDs and Conviction IDs are arbitrarily assigned by the SOR and are unique

for the given CSOR or STSHR transaction. The number of valid values for a Conviction ID or Withdrawal ID that are

unique for a given driver is 1,296 (i.e., 36*36). Thus an SOR may choose either (1) to maintain the two-character IDs

in its database or (2) to generate the two-character IDs on the fly at the time the message is generated. AAMVA

recommends the SOR should assign a unique internal ID to each withdrawal and each underlying ACD conviction when

the SOR enters them in the driver history. The jurisdiction can then translate its internal ID to a two-character ID when

the withdrawal and its underlying ACD convictions are transmitted in subsequent Change State-of-Record and State-to-

State History Request Transactions.

A New SOR is not required to maintain the IDs received in a CSORŕit is only required to maintain internally the

reported linkages between a withdrawal and the underlying convictions. See Sections cd04 and cd08 in this document

for details.




An SOR/Old SOR may populate Conviction IDs in the H3 and Withdrawal IDs in the H5 message, even if it doesnřt

send an H7 message. The Conviction ID and Withdrawal ID occupy Ŗreservedŗ positions according to the

specifications for Release 2.0.1 and thus will be ignored by a jurisdiction that has not implemented CDLIS Release

4.0.1 or later.

The field for the Conviction ID in the H3 message used to be defined as the ANSI conviction code. It was changed to

reserved (i.e. Řblankř) when the ACD codes replaced ANSI codes in CDLIS, but some jurisdictions may still be sending

ANSI codes in this field. Although the Old SOR should not send old ANSI codes in the field in the H3 message of a

CSOR, receiving jurisdictions must be able to handle old ANSI codes in the H3 message, if these values comply with

the business rules for ŖConviction IDŗ. For example, the Old SOR may send a "Conviction ID" in the H3 even if the

conviction is not linked to a withdrawal in the H7. Therefore, when a jurisdiction is the New SOR, it must look at each

conviction ID in the H7 message and find a matching ID in the H3 message to identify all the underlying convictions for

a given withdrawal. It must also look at each withdrawal ID in the H7 and find a matching ID in the H5 message. After

identifying the linkages, the jurisdiction must store the linkages using its own internal design scheme.

The specific CDLIS design rules for withdrawal-convictions linkages are:

If an ACD conviction resulted in a withdrawal with an effective date on or after November 1, 2005 and the driver

was required to have a pointer on CDLIS at the time of the effective date of the withdrawal, the linkage

information must be sent in the H7 message; the conviction information must be sent in the H3 message; and the

withdrawal information must be sent in the H5 message.

For a given underlying conviction, the conviction linkage information in the H7 message must be associated with

the corresponding conviction information in the H3 message using matching Conviction IDs.

For a given withdrawal, the withdrawal linkage information in the H7 message must be associated with the

corresponding withdrawal information in the H5 message using matching withdrawal IDs.

Corollaries are:

A conviction ID in the H7 message must be unique for a given withdrawal ID (For the following example,

where Ř01ř is withdrawal 1, Ř02ř is withdrawal 2, etc. and AA is conviction 1, BB is conviction 2, etc.)

o Ř01AABB...02AA...ř is valid

o Ř01AAAA...02AA...ř is not valid, because of the two repeating Conv. IDs in Ř01AAAAř

Each conviction ID in the H7 message must be equal to a unique conviction ID in the H3 message.

A conviction ID in the H3 message is not required to equal a conviction ID in the H7 message

Each withdrawal ID in the H7 message must be unique in the H7 message

Each withdrawal ID in the H7 message must be equal to a unique withdrawal ID in the H5 message

A withdrawal ID in the H5 message is not required to equal a withdrawal ID in the H7 message

Cases Illustrating Design Rules for Withdrawal-Convictions Linkages

Case 1: One withdrawal with one underlying conviction

Conviction 1 has conviction ID in H3 = '01'

Withdrawal 1 has withdrawal ID in H5 = '01'

The single withdrawal-conviction linkage in the H7 is:

'0101 '

According to existing business rules, the messages are valid--the receiving jurisdiction can correctly reconstruct

the linkages.

Case 2: Underlying conviction lacks ID in H3

Conviction 1 has conviction ID in H3 = ' ' (two spaces)



'01 '




According to existing business rules, the H7 message would be rejected because the linkage could not be

reconstructed.

Case 3: H7 message has incorrect conviction ID




'0123 '

According to existing business rules, the H7 message would be rejected because the linkage could not be

reconstructed.

Case 4: Correctly linked underlying conviction has ID = to old ANSI code

Conviction 1 has conviction ID in H3 = 'AC'



'01AC '

According to existing business rules, these messages are validŕthe receiving jurisdiction can correctly

reconstruct the linkage.

Case 5: Incorrectly linked underlying conviction has ID = to old ANSI code

Conviction 1 has conviction ID in H3 = 'AC'



'01AA '

According to existing business rules, the H7 message would be rejected, because the receiving jurisdiction

cannot correctly reconstruct the linkage.

Case 6: Conviction IDs in the H3 message are not required to be linked

Conviction 1 has conviction ID in H3 = 'AC' (which is an old ANSI code)

Conviction 2 has conviction ID in H3 = 'AA'

Conviction 3 has conviction ID in H3 = 'BB'


The single withdrawal-conviction linkage in the H7 message is:

'01AA '


reconstruct the linkages.

Case 7: Withdrawals with multiple underlying convictions

Conviction 1 has conviction ID in H3 = 'AC' (AC is an old ANSI code)

Conviction 2, a serious violation, has conviction ID in H3 = 'AA'

Conviction 3, a serious violation, has conviction ID in H3 = 'BB'

Conviction 4, a serious violation, has conviction ID in H3 = 'CC'


(Withdrawal 1 was taken before the MCSIA deadline




and does not have any linkages)


(Withdrawal 2 is based on two serious violations within 3 years)

Withdrawal 3 has withdrawal ID in H5 = Ř03ř

(Withdrawal 3 is based on three serious violations within 3 years)

The two linkages in the H7 message are:

'02AABB '

'03AABBCC '



Case 8: withdrawal with 14 underlying convictions















Conviction 15 has conviction ID in H3 = 'XA'


(Withdrawal 1 is a Ŗpointsŗ withdrawal based on 14 underlying convictions)

The single linkage in the H7 message is:

'010102030405060708091011121314'




APPENDIX G - GLOSSARY 690


APPENDIX G - GLOSSARY

This glossary defines acronyms and terms used in this document or related CDLIS and PDPS documentation that have a

special meaning in CDLIS or PDPS.

10-Year History Check

Before extending the expiration date of a CDL, the SOR must request the driver history from every jurisdiction

that has issued a license to operate any type of vehicle to the individual during the last 10 years, as certified by

the individual, unless the DHR indicates that jurisdiction has already responded to a previous 10-Year_History-

Check for the time in question..

23 CFR 1327.5

Federal Regulations issued by the National Highway Traffic Safety Administration, NHTSA.

49 CFR 383-384

Federal Regulations issued by the Federal Motor Carrier Safety Administration, FMCSA.

96 Hour Report

Weekly Suspense Report Ŕ Listing of drivers in: Duplicate status, CSOR (new and old) pending status that were

not completed within the required 96-hour timeframe, and changed to Unique status since last 96-hour report.

AAMVA

American Association of Motor Vehicle Administrators represents state and provincial officials in the United

States and Canada who administer and enforce motor vehicle laws. The Association encourages uniformity and

reciprocity among the states and provinces, and collaboration with other levels of government and the private

sector. Its program development and research activities provide guidelines for more effective public service.

AAMVA also serves as an information clearinghouse.

AAMVA Code Dictionary (ACD)

Codes that are used to transmit driver conviction data from state-to-state.

AAMVA Operations Help Desk

A technical resource for assisting jurisdictions in problem resolution and implementation of AAMVA production

applications.

AAMVANET

The telecommunication network that electronically links all Motor Vehicle Departments, the CDLIS Central

Site, the NDR, and other public and private sector authorized users.

ACD

The AAMVA Conviction/Withdrawal Code Dictionary which is the replacement for the ANSI D-20

Conviction/Withdrawal Codes.

ACD conviction

An AAMVA-Code-Dictionary conviction is an adjudication of guilt, as defined in FMCSA Policy Memorandum

CDL-04-001, for a violation that is traffic-safety related and/or federally mandated, which therefore is listed in

the version of the ACD that is current on the date the SOC reports the conviction.

ACD withdrawal

An AAMVA-Code-Dictionary withdrawal is a withdrawal for ACD convictions, which therefore is listed in the

version of the ACD that is current on the date that the withdrawal is assessed.




AGN

AT&T Global Network

AKA

AKA information is used to present historical identification information, such as prior name or prior Driver's

License Number.

AMIE

AAMVAnet Message Interchange Envelope Ŕ the protocol by which a CDLIS user defines the data elements in

an AAMVAnet Standard Message.

ANSI

American National Standards Institute

ANSI D-20

A common set of coding instructions for data elements related to traffic record systems.

Batch File

A file of messages sorted into logical groups (batches), usually transmitted using Network Job Entry (NJE),

magnetic tape or FTP, for handling through a scheduled batch process

Batch processing

Messages from a batch file are handled through a scheduled, usually nightly, job-oriented, batch process

Benchmarking

Benchmark hours represent the maximum number of hours the AAMVA tester can spend with a jurisdiction

tester on that driver stream per round of test (Initial and End-to-End). This includes test execution,

evaluating/documenting results, and retesting, but not the time the jurisdiction spends working on the driver

stream without the AAMVA tester. Each driver stream is assigned a certain number of benchmark hours.

Ensures that all jurisdictions have equitable access to AAMVAřs testers.

Billing ID

The Billing ID is the same as the Transaction Originator.

Blood Alcohol Content (BAC)

Content of alcohol within the blood

Broken Pointer

A situation in which an MPR doesnřt have a matching DHR.

Call List

A Call List record is the layout of the group of data elements through which a UNI siteřs application programs

supply information to and retrieve information from UNI. An applicationřs specifications document defines the

business function of this information. Depending on the UNI options selected, the call list data may be passed in

files or queues. Call list(s) may be requested from the UNI Help Desk (see also Offset Report(s)).

Canadian Council of Motor Transport Administrators (CCMTA)

Provides motor vehicle and driverřs license guidance for Canadian territories and providences.




Casual testing

Occurs before Structured testing; AAMVA verifies that messages are sent and received, but little data validation

is done; provides jurisdictions an opportunity to ask questions; optional but highly recommended.

CCMTA

The Canadian Council of Motor Transport Administrators is similar in program function to AAMVA, except the

CCMTA focuses on Canadian issues.

CDL

Commercial Driverřs License Ŕ see definition in 49 CFR 383.5

CDLIS

Commercial Driverřs License Information System Ŕ see definition in 49 CFR 383.5

CDLIS Central Site

The node on AAMVAnet that maintains the CDLIS Master Pointer Records, processes a number of transactions

between jurisdictions, and reports CDLIS activity to FMCSA.

CDLIS driver history

The CDLIS driver history is the record of an individual's identification information, driver's license information

(including information about any permits, endorsements, and restrictions), and history of convictions, accidents,

and withdrawals that is maintained by the SOR and transmitted in a Change State of Record Transaction.

CDLIS Readiness Assessment

Jurisdictions must submit one of each message type per CDLIS transaction to be tested. Messages will be

checked by AAMVA for formatting errors. All formatting errors must be corrected prior to implementation.

CFR

Code of Federal Regulations

Change State of Record (CSOR)

CSOR; when a driver moves from one jurisdiction to another, and CDL and the driver history is transferred from

the Old SOR to the New SOR.

CICS

Customer Information Control System; an IBM teleprocessing monitor.

CMV

Commercial Motor Vehicle

CMVSA

Commercial Motor Vehicle Safety Act (CMVSA) of 1986.

Commercial Driver’s License (CDL)

A license issued by a State or other jurisdiction, in accordance with the standards contained in 49 CFR parts 383

and 384, to an individual which authorizes the individual to operate a class of a commercial motor vehicle.

Commercial Driver’s License Information System (CDLIS)

Is an information system that satisfies the requirement of the CMVSA and MCSIA by providing identification,




status, and history information regarding commercial drivers.

Commercial Motor Vehicle (CMV)

As defined in 49 CFR 383.5, a motor vehicle or combination of motor vehicles used in commerce to transport

passengers or property if the motor vehicle:

has a gross combined weight of more than 26,001 lbs (11,794 kilograms) inclusive of a towed unit(s), or

has a gross vehicle weight rating of more than 26,001 lbs (11,794 kilograms), or

is designed to transport 16 or more passengers, including the driver, or

is of any size and is used in the transportation of hazardous materials.

Compliance

In accordance with federal requirements outlined in the Federal Motor Carrier Safety Regulations

Compliance Report

A report sent by AAMVA to FMCSA on a quarterly basis of all CDL activities and pending compliance tickets

for each jurisdiction.

Compliance Ticket

A notification sent by AAMVA to FMCSA when a jurisdiction is not in compliance with the FMCSR

Conviction

A conviction is an adjudication of guilt, as defined in FMCSA Policy Memorandum CDL-04-001. Note:

FMCSA considers the following to be types of convictions: admin per se, refusal to take an alcohol test, failure

to appear, and failure to pay.

Conviction Reports

790 CONVICTION/NEGATE CONVICTION RECORDS HAVE BEEN CORRECTED report. The purpose of

this report is to identify and notify the State of Conviction (SOC) of the Out of State Conviction and the Negate

Conviction messages which have been corrected and resent to the State of Record (SOR) via CDLIS Central

Site.Note* This report does not reflect corrected Out of State Convictions nor Negate Conviction messages

which were sent via other means to the SOR. This weekly report contains a listing of Out Of State Convictions

and Negate Conviction messages which have been corrected and successfully resent to the SOR through the

CDLIS Central Site. This report is refreshed on a weekly basis and there is no action required by the SOC to

remove data from the report.

730 CONVICTION/NEGATE CONVICTION ERROR REPORT. The purpose of this report is to identify

Convictions and Negate Convictions, which have erred off either at the CDLIS Central Site or at the State of

Record (SOR). The report can also be used to monitor the errors for a trend. This daily report contains a listing

of out of state convictions and negate conviction messages which have erred off at the CDLIS Central Site as a

Broken Pointer situation or erred off at the SOR because of edits on the 17 block or as a no-hit.

770 Conviction/Negate Conviction Duplicated Errors Report. The purpose of this report is to identify when

duplicate convictions are being sent by the State of Conviction, if the convictions are being posted by the SOR,

and if any administrative action is being taken as a result. This weekly report contains a listing of drivers which

have had duplicate Convictions or Negate Conviction messages sent by the State of Conviction. This report is

sorted by the State of Conviction. The duplicate conviction is identified by comparing the Location Reference

fields and the Offense Reference fields to previously sent convictions

780 CONVICTION/NEGATE CONVICTION ERROR TRACKING REPORT 10 DAYS PAST DUE Report.

The Out of State Convictions and Negate Conviction messages which have erred off either at the CDLIS Central

Site or at the State of Record (SOR), and have not been corrected, and re-sent. The report can be used to

evaluate the errors for any trends. The Conviction and Negate Conviction message are matched on the

information provided in the previously sent SOC Location Reference and the Offence Reference field in the 17

Conviction Block. It is thought that no two convictions will have the same Location Reference values and




Offence Reference values in the 17 block of the message. This report contains a listing by SOC of Out of State

Conviction and Negate Conviction messages which had erred off at the CDLIS Central Site as a Broken Pointer

situation or erred off at the SOR because of edits on the 17 block or as a no-hit. This report contains all driver

information contained in the original Report Out of State Conviction and (HA) or Negate Out-of-State

Conviction (HH) message including the 17 (Conviction) block and the 25 (Error) block.

CSL

Commercial Special License

CS

CDLIS Central Site

CSOR

Change State of Record Transaction is the transaction, used when a CDL holder moves from one jurisdiction to

another, and CDL and the driver history is transferred from the Old SOR to the New SOR.

Data (Element) Dictionary

The list of data elements and their definitions which are used in the application. Each data element is listed by

its business and call list name, element code, description, values, type and length.

Data Setup

Refers to test data setup prior to structured testing. AAMVA customizes each stateřs structured test messages

based on the stateřs Participant Setup Document and test plan. Jurisdiction must create MPRs and set up drivers

on their state database based on the stateřs Participation Setup Document and test plan. Both must be completed

prior to structured testing.

Department of Motor Vehicles

See MVA.

Department of Transportation (DOT)

The overseeing agency of the Federal Motor Carrier Safety Administration.

Development

All of the activities necessary to create the system specification and complete internal (not structured) testing.

These activities include analysis, design, programming, and documenting the business and technical

specifications.

DGAF

General Directorship of Federal Motor Carrier Transportation is Mexicořs equivalent of the U.S. FMCSA.

DHR

Driver's History Record Ŕ the record is maintained by the SOR and includes all the information required to be

transferred in a CSOR Transaction, including driver identification information, driverřs license information, and

the driverřs history of convictions, withdrawals, and (optionally) accidents.

Disqualification

As defined in 49 CFR 383.5, ŖDisqualification means any of the following three actions:

(a) The suspension, revocation, or cancellation of a CDL by the State of issuance.

(b) Any withdrawal of a person's privileges to drive a CMV by a State or other jurisdiction as the result of

a violation of State or local law relating to motor vehicle traffic control (other than parking, vehicle




weight or vehicle defect violations).

(c) A determination by the FMCSA that a person is not qualified to operate a commercial motor vehicle

under part 391 of this chapter.ŗ

DL

Driver's License Ŕ see definition in 49 CFR 383.5

DLA

Driver's License Agreement Ŕ an interstate compact that combines feature of the DLC and the NRVC.

DLC

Driver's License Compact Ŕ an interstate legal agreement that specifies how U.S. Jurisdictions give reciprocity

for drivers with out-of-state driverřs licenses.

DLN

Driver's License Number

DLN Survey

PDPS Driver's License Number Survey Transaction, used to obtain a DLN and status information from a

previous jurisdiction when a 10-Year History Check is needed and the DLN is not known.

DLR

Driver License Reciprocity

DMV

Department of Motor Vehicles Ŕ see MVA.

DOB

Date of Birth

Driver

Any individual who has ever held a driver license or who has been known by a state Department of Motor

Vehicles (DMV) to drive.

Driver History Record (DHR)

History of each driver maintained on the jurisdictionřs system.

Driver’s License

A license issued by a jurisdiction to an individual to operate a motor vehicle, including all licenses issued, not

just those that are current.

DSD

CDLIS Detail System Design Document

Duped Against

A term used in the duplicate processing function to indicate an existing CDLIS Master Pointer Record which has

the same SSN as a record being added to the CDLIS database.




EDI

Electronic Data Interchange a protocol for sending and receiving information via a computer networkŕAMIE is

an EDI.

Electronic Means

Electronic means include (but are not limited to): internet, interactive voice response (IVR) and telephone.

Electronic Verification of Vital Event Records (EVVER)

A system that will verify identify documents presented by driver license, permit, and ID card applicants and

improve and the driver license issuance processes

Electronic Verification of Vital Events (EVVE)

A system that will allow jurisdictions to verify information on birth certificates with the issuing jurisdictions

Endorsement

An authorization to an individual's CDL required to permit the individual to operate certain types of commercial

motor vehicles

End-to-End

Second run of the Structured test. Ensures any programming fixes made during First Pass did not adversely

affect code. If any errors are found, the test begins from the beginning.

Equivalency table

A jurisdiction equivalency table is a mapping of each jurisdiction statute for a traffic violation to the

Ŗsubstantially equivalentŗ Conviction ACD Code. The purpose of the ACD equivalency tables is to document

the ACD codes and their equivalent native jurisdiction codes. Since the ACD was introduced in 1996, AAMVA

has been collecting the mapping from each state and publishing the documentation containing all states mapping.

States use the tables to see how other states have an ACD code mapped and to identify their own statutes that

will be impacted by changes.

The ACD working group used the tables to see which codes are used by which states when assessing the impact

of a change.

ERD

Entity Relationship Diagram Ŕ ERDs graphically portray the information that the business area needs in order to

do its business and the relationships that the data have which are important to the business.

ESI

Enhanced State Interface is the interface used by the CDLIS Central Site to process AMIE messages.

FAA

Federal Aviation Administration

FAQ

Frequently Asked Question

FCWD

The Federal Convictions and Withdrawal Database (FCWD) is a repository of U.S. State convictions and

withdrawals on Mexican CDL drivers (holders of an LFC document with driver records in the LIFIS database),

and FMCSA withdrawals on LFC drivers. Future plans involve expansion to include similar information on




Canadian CDL drivers.

Federal Register

An official U.S. government publication in which FMCSA provides official notification of Federal Rulemaking

FHWA

Federal Highway Administration Ŕ the FMCSA was an office within the FHWA before MCSIA was enacted

First Pass Testing

Initial run of the Structured test. All programming errors are found and corrected. All test cases must pass before

End-to-End test.

FMCSA

U.S. Federal Motor Carrier Safety Administration (formerly The Office of Motor Carriers (OMC)

Develops, issues, and evaluates standards for testing and licensing CMV drivers

Standards (Federal regulations) require states to issue CDLs only after drivers pass knowledge and skills

tests that pertain to the type of CMV being operated

States are audited every 3 years to monitor compliance with Federal standards

Federal regulations provide for the FMCSA to conduct random inspections and audits of third-party

testers without notice

FMCSA provides Federal CDL grants to states.

FMCSR

Federal Motor Carrier Safety Regulation

FRA

Federal Railroad Administration

FTA

Failure to Appear

FTC

Failure to Comply

FTP

Failure to Pay

GAP Code

Government/Application Provider Code

HAZMAT

Hazardous Material

Government/Application Provider (GAP) Code

Each node on a network is assigned a code for message addressing

HAZMAT (Hazardous Materials)

Any material that has been designated as hazardous under 49 U.S.C. 5103 and is required to be placarded under




subpart F of 49 CFR part 172 or any quantity of a material listed as a select agent or toxin in 42 CFR part 73.

HME

Hazardous Material Endorsement

ICC

Interstate Commerce Commission

ICCTA

Interstate Commerce Commission Termination Act of 1995

ID

Identification

Implementation Period

The relatively short time necessary to move programs, utilities, etc., from the development region to the

production region. This phase also includes performance of structured testing with the pilot states.

Inquiry Functions

AKA Inquiry, Application Status Inquiry, Driver History Request, Employer Inquiry, Search Inquiry, Status

Request, and Verification Inquiry.

IPG

Implementation Planning Guide Ŕ a topic-specific transition document that has instructions for the

implementation period. Some IPG content may be incorporated into the specifications later.

IRE

The Canadian Interprovincial Record Exchange is the computerized system in Canada by which driver license

information is exchanged between Canadian provinces and territories. The AAMVAnet/IRE Bridge connects the

AAMVAnet U.S. network to the IRE.

SOHD (Insurance Services Organization Help Desk)

The Help Desk contact for NMVTIS Theft File

Issue/Issuance

Initial licensure, license transfers, license renewals, license upgrades, and nonresident commercial driverřs

licenses (CDLs).

Jurisdiction

A jurisdiction is any state, district, territory, possession, or province of the U.S., Mexico, or Canada. Usually the

term refers to one of the 50 U.S. states or the District of Columbia. The term "Mexican jurisdiction" means one

of the Mexican states, and the term "Canadian jurisdiction" means one of the Canadian provinces or territories.

LFC

Licencia Federal de Conductor Ŕ Mexicořs equivalent of a CDL.

Licensing Entity

The agency of state government authorized to issue driversř licenses.




LIFIS

The Licencia Federal Information Systema (LIFIS), the Mexican equivalent of CDLIS, includes the Mexican

Access gateway which: (1) provides communication between LIFIS and CDLIS and (2) maintains records of any

U.S. convictions of Mexican drivers. LIFIS also provides:

Direct electronic connection among Mexico's CDL field licensing offices and the headquarters office

Central issuance of a more secure and tamper-proof Licencia Federal (LFC) document

Real-time data entry

Information retrieval

Linenum

An AAMVAnet convention which is used in the documentation to indicate how many occurrences of a block

type are valid, and used in the transaction to indicate the occurrence number.

Maintenance

Any changes to the system after operation has begun.

Master Pointer Record

See MPR.

MCSAP

Motor Carrier Safety Assistance Program

MCSIA

Motor Carrier Safety Improvement Act (MCSIA) of 1999 (further defined by Title 49 §383-384)

MEC

Message Exchange Control

MEC Block

Message Exchange Control Block in a message sent over AAMVAnet

Message Originator

The Message originator is the entity that builds a message.

Mexico's General Directorship of Federal Motor Carrier Transportation (DGAF)

Established access to Mexican commercial driver records for CDLIS Driver's History Record

Mexican Conviction File

Contains information on US convictions of Mexican drivers. This information is forwarded to LIFIS (see

LIFIS), and may also be used by FMCSA to disqualify Mexican drivers from driving within the US. It does not

contain or forward information on Mexican convictions of US drivers.

Motor Vehicle Agency

See MVA.

MPR

Master Pointer Record Ŕ in CDLIS, the CDLIS Central Site keeps a Master Pointer Record for each driver. The

record is a pointer to the jurisdiction that issued the drivers latest drivers license. The record contains driver




identification information and a pointer to the current SOR, typically the jurisdiction that issued the driverřs

latest driverřs license. In PDPS, the current State of Licensure or SOL, and any jurisdiction that convicted or

withdrew the driver may be an SOR. The PDPS Central Site keeps a Master Pointer Record for each jurisdiction

that is an SOR.

MVA

Motor Vehicle Agency Ŕ the agency in charge of licensing drivers in a given stateŕAAMVA uses ŖMVAŗ as a

general term that applies whether the MVA is an independent agency or part of a law enforcement department or

a revenue department.

NADSF

North American Driver Safety Foundation

National Driver Register (NDR)

The NDR is a central repository of information about problem drivers in the United States. The NDR is in

NHTSA. The NDR (the repository) and PDPS (the Ŗpointerŗ system) are sometimes used interchangeably.

National Highway Traffic Safety Administration (NHTSA)

NHTSA includes the NDR and is the system operator of the Problem Driver Pointer System (PDPS).

National Motor Vehicle Titling Information System (NMVTIS)

NMVTIS is a system that maintains motor vehicle titling information.

NCB

Network Control Block

NCS (or NCS-II)

Network Control Software Ŕ an AAMVAnet-supported utility which routes messages. NCS allows each state

(and central site) to establish a session with NCS, rather than requiring a session with each other AAMVAnet

user.

NDR

National Driver Register

Negates

To reverse a conviction or withdrawal.

Network Control Software (NCS-II)

NCS-II is an AAMVAnet-supported utility that facilitates the routing of messages over the AAMVAnet network;

it allows each state (and central site) to establish a session with NCS, rather than requiring a session with each

other AAMVAnet user.

NHTSA

U.S. National Highway Traffic Safety Administration

NIS

Network Interface Software is a utility which translates messages from AMIE format into a format useful to the

specific nodeřs internal application.




Non-ACD conviction

A non-ACD conviction is an adjudication of guilt for a violation, such as gas-pump piracy, that is neither traffic-

related nor federally mandated.

Non-ACD withdrawal

A non-ACD withdrawal is a withdrawal based on at least one non-ACD conviction, such as gas-pump piracy.

Noncompliance

When a state fails to submit timely certifications and does not meet one or more of the standards based on a final

determination of FMCSA.

NOOSC

Negate out-of-state conviction (CD12) (see CDLIS System Specifications)

NOOSW

Negate out-of-state withdrawal (CD17) (see CDLIS System Specifications)

North American Driver Safety Foundation (NADSF)

FMCSAřs jurisdiction auditors and the jurisdictions to better maintain driver information.

NRVC

Non-Resident Violators Compact Ŕ an interstate legal agreement among 45 U.S. jurisdictions that specifies how

the Jurisdictions give reciprocity for out-of-state drivers cited for violations.

NTSB

The National Transportation Safety Board

Offset Report(s)

The offset reports provide the addresses of the elements within the call list. Call list(s) or Offset Report(s) may

be requested from the UNI Help Desk (see also Call List(s)).

OOSC

Out-of-state conviction, see also ROOSC, Report Out-of-state Conviction (CD11) in CDLIS documentation.

OOSO

Out-of-service order

OOSW

Out-of-state withdrawal, see also ROOSW, Report Out-of-state Withdrawal (CD16).

Open Compliance Tickets

The CDLIS documentation is included by reference in 49 CFR 383.107 and 384.231(d). It provides direction on

how the Federal regulations in 49 CFR 383 and 384 are to be implemented in CDLIS messages sent to and

from the CDLIS Central Site, other States and FMCSA. If a State sends CDLIS messages that include missing,

incorrect or improperly formatted information, thereby failing to follow the CDLIS documentation, and if the

State cannot fix the problem(s) within a reasonable period of time, a "compliance ticket" is put into AAMVA's

problem tracking system. Each compliance ticket references at least one regulation in 49 CFR 384. The tracking

system produces quarterly reports. The AAMVA Operations Help Desk monitors problem resolution at the

State. The compliance ticket is considered Řopenř until the problem(s) have been resolved.




Operation

The period after structured or acceptance testing is complete and CDLIS transactions are being sent and received

by the pilot participants.

Out-of-service order

An Out-of-Service Order is a declaration by an authorized enforcement officer of a Federal, State, Canadian,

Mexican, or local jurisdiction that a driver, a commercial motor vehicle, or a motor carrier operation, is out-of-

service pursuant to §§ 386.72 , 392.5 , 395.13 , 396.9 , or compatible laws, or the North American Uniform Out-

of-Service Criteria.

Participant Setup Document

Used to customize the Structured test plan; lists the test drivers a jurisdiction must create for the structured test;

must be completed prior to structured testing.

PDPS

The NDR's Problem Driver Pointer System

PIC

Process Implementation Chart is a graphical representation of the message routing and processing in a given

transaction.

Pointer

A pointer is a record on the CDLIS central site that identifies the state that issued the license and maintains the

record and the history of the driver.

Pointer on CDLIS

A pointer on CDLIS is a phrase that means the driver has a Master Pointer Record (MPR) on the CDLIS Central

Site. The pointer record identifies the current SOR. To identify the driver, the pointer holds the driver's personal

identification information and license information. The pointer also holds record maintenance information

POV

Personally owned vehicle

Project Participant

A stakeholder organization that maintains CDLIS, requires access to CDLIS, or supports PDPS (which is

integral to the CDL program). CDLIS project participants are FMCSA, AAMVA, the jurisdictions, employers,

and NHTSA.

Problem Driver

An individual whose privilege to drive has been revoked, suspended, canceled, or denied or who has been

convicted of serious traffic-related offenses. .

Problem Driver Pointer System (PDPS)

"Pointer" system for the NDRřs central repository of information about problem drivers in the United States.

Pseudobatch

Online messages are stored by the sender, then forwarded later for processing.

RAR

Return as Received is a term meaning the jurisdiction can enter an arbitrary phrase in a message and the return

http://www.fmcsa.dot.gov/rulesregs/fmcsr/regs/386.72.htm







message will return the phrase to the jurisdiction.

Re-drive

When a Change State of Record is suspended due to problems encountered, once the problems are identified, the

Operations Help Desk may assist the jurisdictions to re-drive or resend the CSOR.

RJE

Remote Job Entry Ŕ an IBM term for a method of initiating a batch job from a remote site

ROOSC

Report Out-of-state Conviction (CD11) (see the CDLIS Systems Specifications)

ROOSW

Report Out-of-state withdrawal (CD16) (see the CDLIS Systems Specifications)

RRGC

Railroad Grade Crossing Ŕ note: synonymous terms are ŖRailroad-Highway Grade Crossingŗ and ŖHighway-Rail

Grade Crossingŗ

S2SHR

State-to-state history request (CD04).

SAFETEA-LU

Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU) gives

FMCSA the discretion to withhold any amount of highway construction funds up to maximums of 5% the first

year or 10% in succeeding years.

SOC

The State of Conviction is the jurisdiction in which the driver is adjudicated guilty of a violation.

SOI

State of Inquiry Ŕ the State that sends an inquiry about another stateřs driver.

SOL

State of Licensure Ŕ the State where the driver is licensed.

Solicited Message

This message contains information in response to some request. Usually, this message is received by the

originator of a transaction in response to the initial message of the transaction, e.g., the transaction originator

sends the initial message of a transaction to request information. The response that is returned to the transaction

originator is the solicited message.

SOR

State of Record Ŕ in CDLIS, the SOR is the jurisdiction responsible for:

Maintaining the driverřs Master Pointer Record (MPR) at the CDLIS Central Site

Maintaining the DHR, including the driverřs complete ACD history and the driverřs commercial status, as

required by the CDLIS data retention requirements

This requirement applies to all drivers who are:

current CDL holders




drivers Řrequired to have a CDLř (non-CDL holders but have been convicted of offenses committed in a

CMV)

previous CDL holders, whether currently disqualified or voluntarily downgraded

The SOR is the jurisdiction of domicile, except when (1) the driver's address is unknown or (2) the jurisdiction of

domicile is decertified (see Federal Regulations for details about decertification).

For PDPS, there may be more than one SOR for the same driver. A jurisdiction becomes the State of Record

(SOR) for each problem driver it reports to the NDR. Any jurisdiction(s) with information about an incident,

either where the incident occurred or where the driver is licensed, may report the driver to the NDR. Within

PDPS, it is now the SORřs (not the NDRřs) responsibility to maintain the substantive information about specific

action(s) taken against an individual, to provide the identifying pointer record information to the PDPS Central

Site, to respond to on-line requests with status and history records for individuals who have pointers at the PDPS

Central Site, and to provide driver history information in response to requests from states for other authorized

users (see Section 2.5).

SOW

The State of Withdrawal Ŕ the jurisdiction in which a personřs driving privilege is withdrawn. If the SOR is the

SOW, the withdrawal is effective nation-wide.

SSAN

Social Security Account Number

SSN

Social Security Number

ST

State

ST/DLN

State/Driverřs License Number Ŕ the concatenation of the state of licensureřs two-character code and the

individualřs driverřs license number Ŕ a licensed driver must have only one ST/DLN.

Stakeholder

A stakeholder is an individual or group or organization that maintains CDLIS, requires access to CDLIS, or

supports PDPS (which is integral to the CDL program). CDLIS stakeholders are FMCSA, AAMVA, the

jurisdictions, employers, and NHTSA.

Structured testing

Consists of an Initial Run and an End to End Run; Performed to ensure jurisdictions follow the specs; test plan is

customized based on the questionnaire and Participant Setup Document; must be completed before a jurisdiction

implements any changes in the production environment.

STSHR

State-to-state history request (CD04).

STSSR

State-to-state status request (CD05).

TEA-21

Transportation Equity Act for the 21st Century




TPSP

Third Party Service Provider

Transaction (business)

A series of messages sent to accomplish a specific business function.

Transaction Originator

The Transaction Originator is the entity that started the transaction process.

TSA

Transportation Security Administration

UNI

Unified Network Interface

Unsolicited Message

An unsolicited message is a message that is not requested by the receiver. Usually it is the first message within a

transaction.

USA PATRIOT Act

Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct

Terrorism Act of 2001.

USCG

United States Coast Guard

Violation

Failure to follow predetermined regulations.

Weekly Suspense Report

96 Hour Report; Listing of drivers in: Duplicate status, CSOR (new and old) pending status, and Unique status.

Withdrawal

A withdrawal is the disqualification, revocation, suspension, denial or cancellation of a driver's license (see

disqualification defined in 49 CFR 383.5) resulting from one or more convictions. The Ŗwithdrawal extentŗ

identifies whether the driverřs CDL and/or base license privileges are withdrawn.

Withdrawal-conviction linkage

Under MCSIA, for any withdrawal with an effective after September 30, 2005, information to associate the

withdrawal with all convictions that resulted in the withdrawal (its underlying convictions) must be maintained

so that the withdrawal-conviction linkage(s) can be accurately reported on state-to-state history request or a

change state of record transaction.

commercial driverâ€™s license information system

Documents