SECTION 1

SECTION 1 INTRODUCTION

INTRODUCTION

1.1 Background

     For almost 100 years fingerprint cards ha ve been accepted as the standard means for recording and storing fingerprint identification data. Over that period the content, format, and quality of fingerprint cards have been revised and refined. Fingerprint cards are now accepted as a national standard for the exchange of fingerprint, identification, and arrest data between criminal justice agencies.

     However, because fingerprint cards must be physically transported and processed, substantial delays are introduced into the identification cycle. To improve the speed and accuracy of the fingerprint identification process and eliminate the need for contributing agencies to create and mail paper fingerprint cards to the Federal Bureau of Investigation (FBI) for processing, the FBI Criminal Justice Information Services (CJIS) Division is developing an Integrated Automated Fingerprint Identification System (IAFIS) that will support the paperless submission of fingerprint records.

     In support of the development of the IAFIS and in accordance with the recommendations of the National Crime Information Center (NCIC) Advisory Policy Board (APB) Identification Services Subcommittee, the FBI has developed in conjunction with the National Institute of Standards and Technology (NIST), and the fingerprint identification community, a standard for electronically encoding and transmitting fingerprint image, identification, and arrest data. This standard is comprised of an American National Standards Institute (ANSI) standard entitled “Data Format for the Interchange of Fingerprint Information” (ANSI NIST-CSL 1-1993), together with an Addendum, “Data Format for the Interchange of Fingerprint, Facial & SMT Information (ANSI/NIST-ITL 1a-1997).

     The ANSI standards define the content, format and units of measurement for the exchange of information that may be used in the fingerprint identification of a subject. Such information is intended for use in the interchange between criminal justice administrations or organizations that use an Automated Fingerprint Identification System (AFIS), and will provide a common interface for AFISs and related systems nationwide.

CJIS-RS-0010 (V7)

1

January 29, 1999

1.2 Contents of Specification

     While the ANSI standards referenced in Section 1.1 will allow all AFISs and related systems to communicate, the purpose of this document is to specify certain requirements to which agencies must adhere to communicate electronically with the FBI’s IAFIS. IAFIS has three segments: (1) Identification, Tasking and Networking (ITN/FBI), (2) Automated Fingerprint Identification System (AFIS/FBI), and (3) the Interstate Identification Index (III/FBI). III/FBI electronic communications do not include fingerprints, and the requirements are contained in appropriate NCIC manuals. This specification covers the remainder of the IAFIS electronic transmissions involving fingerprints. The basic requirements for Logical Records Type-1, Type-2, Type-4, Type-7, Type-9, and Type-10 set forth in the ANSI standards are also applicable to transmissions to the FBI. However, the FBI-specific requirements for the contents and format of Logical Records Type-2, Type-7, Type-9, and Type-10 as well as for any special requirements for the other record types, are contained in this specification.

1.3 Change Control

     The Electronic Fingerprint Transmission Specification (EFTS) defines the interface between IAFIS and the States’ systems. Any changes to the data fields or formats within the EFTS must honor previously published protocols to ensure that the States’ systems are not adversely affected. Since IAFIS and the States’ systems are being developed independently, a process has been established which provides for coordinated enhancements within the various systems while maintaining reliable interoperability. This process is based in the tagged field structure defined in the 1993 ANSI standard, and a few “business rules”. The rules simply state that field definitions cannot change over time or from system to system. If a change is needed, a new field is defined and assigned a new tag number. The new field cannot be made mandatory for established functionality, but merely enhances functionality for those systems wishing to incorporate the new definition. With this process in place, every system on the network has the opportunity to enhance its own system on its own schedule, yet no system is ever forced to make a change in order to maintain current functionality.

1.4 Tagged Fields

1.4.1 Interpretation of Tags

     In the construction and interpretation of the logical record, the tag number should not be taken as having a fixed number of digits. For example, in the version of the standard, Type-2 logical record, field tags are always shown as having three decimals between the decimal point and colon (2.NNN:data...). However, in future versions, Type-2 field tag numbers may be expanded to four or more digits (2.NNNN:data...). To accommodate such possibilities, the field numbers should be parsed as all digits between the period and colon.

     In the construction and interpretation of the logical record, there is no requirement that the tagged fields be present within the logical record in any given order, with the exception of the Length (LEN) and Image Designation Character (IDC), which must be in the first and second position in the record, respectively. Thus, for example, a State Ident Bureau could add the State

CJIS-RS-0010 (V7)

2

January 29, 1999

Identification Number (SID) to the end of a Type-2 record created at the booking station. (This is less restrictive than the ANSI Standard’s language.)

1.4.2 Use of Separator Characters

     Separator characters may best be understood by considering them necessary for what follows, not what precedes them. Thus, when a tagged field includes subfields¹ (e.g., the ASL field contains subfields DOO and AOL), and another subfield is still to follow, the following one must be separated from the one preceding it by the unit separator character. If what is to follow is a repetition of a field or group of subfields, a record separator must separate the preceding field or group of subfields from the repetition to follow. If what is to follow is a new field, then the group separator character is used. If the record is complete after the previous field, the file separator is used.

     Per NIST, successive separator characters now may be used with no intervening blank or other character when a subfield is missing. In Type-2 records, IAFIS recognizes the following sequences as meaning that a subfield is missing: <US><US>, <US><RS>, <US><GS>, and <US><FS>. These are needed to obviate the need for IAFIS’s validating each subfield in a grouped field to see whether it contains valid data or merely a blank. This will keep invalid data out of IAFIS databases.

1.5 Error Handling

     Error processing takes on two primary forms within IAFIS. These are front-end error detection and internal process error detection and correction. The front-end process examines every incoming transaction from a security and mandatory data perspective. Potential security violations are rejected and transferred immediately to a system administrator. Transactions lacking mandatory data, or that are incomplete in referenced content, are rejected. All mandatory data and all optional data fields are edit checked for length and type of data included. Optional data failing this validation check are ignored. Mandatory data that fail this validation check are passed to a QC Service Provider for resolution. If the Service Provider can correct the data, the transaction will be forwarded for further processing. If the Service Provider cannot resolve the issue, the transaction can either be rejected or sent forward for attempted resolution later in the process.

     Secondary edit checks are performed any time an IAFIS segment attempts to utilize incoming data to perform a search or update a database. Any such action will check the field according to length and type as well as content. Some data values are content sensitive. That is, they can only be examined with respect to the databases against which they are to be applied. Errors in submissions detected at that time will generally be forwarded to a Logic Error Resolution Service Provider. At that point, appropriate actions can be taken to correct the discrepancy and an internal resubmission of the transaction can take place. Alternatively, if the Service Provider cannot resolve the issue, the transaction can be rejected.

¹ The EFTS’ use of the term subfield is synonymous with the term information item found in the ANSI Standard.

CJIS-RS-0010 (V7)

3

January 29, 1999

     In the interpretation of the logical record, tags that are not defined for the requested transaction are to be ignored; their inclusion is not to be considered an error. This rule makes it possible to use a single transmission format, for example, to control both intrastate and interstate transmissions.

     Fields should not be transmitted when there is no value present (e.g., ... 2.033:<GS> ...). However, receipt of such an empty field, if the field is not mandatory, should not result in rejection of the record or issuance of an error message. Rejection will occur, however, when missing or incorrect data would frustrate processing of the transaction. The following list illustrates these types of errors:

1• A mandatory field is missing in a submitted recordset (e.g., NAM is missing in T2CAR) and would result in immediate rejection;

2• The format of a mandatory field is incorrect (e.g., an alpha character is discovered in the SOC field) and would result in an attempt to correct the data;

3• The range of data of a mandatory field is incorrect (e.g., a DOB of 18871332 was submitted - century, month, and day are all out of range) and would result in an attempt to correct the data; Incorrect data is discovered that cannot be corrected by a service provider, and without which, the transaction processing cannot proceed will result in the transaction being rejected;

4• Appendix M lists the current set of Error Messages that are pertinent to the EFTS user (i.e., IAFIS internal errors are not listed).

1.6 Identifying Previous Transactions

     The user may wish to refer to previous transactions for the purpose of follow up or resubmission. The pertinent information is contained in two Type-1 fields, 1.09 Transaction Control Number (TCN) and 1.10 Transaction Control Reference (TCR) (See Appendix B).

     Upon submitting a transaction to the FBI, the submitter places his control number in the TCN field in the Type-1 record. For submissions not requiring reference to a prior transaction, the TCR field is omitted. When the FBI has completed processing the transaction and generates the response, it places the submitter’s control number (the received TCN) into the TCR field of the response as a reference number the submitter can use to mate the response with the original submission. The FBI also places its own internal identifier for that transaction (the ICN, or IAFIS Control Number, a 20-character alphanumeric field) in the TCN field of the response.

     The TCN in the response can be used by the submitter should he have to reopen the transaction for any purpose. For example, if the FBI rejected the first submission of a user-fee transaction (which the submitter is entitled to resubmit one time free of charge if the rejection was due to poor quality fingerprint images), the user would place this number in the TCR field of the resubmitted transaction to enable the FBI to verify the user’s authorization to resubmit at no-charge.

CJIS-RS-0010 (V7)

4

January 29, 1999

1.7 Data Storage in the IAFIS Database

     Data that is submitted in IAFIS transactions may or may not be stored in a table in the IAFIS database. Data which is not stored is considered to be user-defined. It is carried in transactions as an aid to the submitter in interpreting or routing the FBI’s response to the submission, and is returned verbatim to the user. Data which is stored in IAFIS is always converted to uppercase prior to storage. Therefore, if this data is returned as part of the response to a subsequent submission (or a III inquiry), it may differ (in case only) from the originally submitted data.

1.8 Guidance on ORI and CRI Usage

The following description offers some guidance for the use of the CRI field to provide appropriate authorization to perform file maintenance within IAFIS. We develop this scenario by examining how an electronic submission might be formed by a contributor and passed to IAFIS for evaluation. This is intended as an example since there are many other requirements that might influence the final design. Ultimately, the contributors manage the use of the CRI field.

Assume a print is obtained by a local agency, passed to a county agency for processing and subsequently to the CTA for transmission to the FBI. In such a case the transmission of ORIs and CRIs might appear as follows:

STATE_CTA

COUNTY_AGENCY | ORI |

LOCAL

| ORI |-----------------> | CRI2 |

| ORI |-----------------> | CRI1 |-----------------> | CRI1 |

When generated at the local level, no CRI need exist since this ORI is the originator. On receipt by the county agency and subsequent transmission to the state CTA, the original ORI is entered as the first instance of the CRI and the county ORI replaces the local ORI in the ORI field. On receipt by the state CTA and for subsequent retransmission to the FBI, the Local ORI is retained as CRI1, the county ORI is entered as CRI2, and the ORI of the state CTA is entered in the ORI field. The transaction is then forwarded to the FBI via the CJIS WAN. CRI1, the local ORI, is then used as the authority for action, and thus retains ‘ownership’ of the transaction. Then, only CRI1 can modify, cancel, confirm or delete a latent transaction. In the response, the transaction is sent to the ORI from which it was sent and it is the responsibility of the state CTA to route it properly to the county agency identified in CRI2. The county agency, in turn, would route the response to the local agency as appropriate.

CJIS-RS-0010 (V7)

5

January 29, 1999