2951_11.PDF

CJIS-RS-0010 (V7) January 29, 1999 ii

Department of Justice

Federal Bureau of Investigation

CRIMINAL JUSTICE INFORMATION SERVICES (CJIS)

ELECTRONIC FINGERPRINT TRANSMISSION

SPECIFICATION

JANUARY 1999

Prepared By:

Criminal Justice Information Services Division 935 Pennsylvania Avenue, N.W.

Washington, D.C. 20535 iii

CHANGE HISTORY

A. CJIS-RS-0010 (V4), August 24, 1995 - This version incorporates RFCs, 787, 842, 850, 877, 896, 898, and 906

B. CJIS-RS-0010 (V5), June 6, 1997 - This version release is a single-sided document and will be managed as such hereafter. This version incorporates the following RFCs:

870R2 Latent Search: need to develop a concept of operations, need to define/verify the requirement for the service provider to cancel searches and need to develop overall resource utilization concept, specification and flow requirements to segments: Sections 3.4.1.5, 3.4.1.6, 3.4.2, 3.11, 3.11.1, 3.11.1.1, 3.11.1.2, 3.11.1.3, 3.11.1.4, App.C: CFS, ETC, NCR, PEN, PRI, QDD, QUE, RIX, ROR, RSR, Table E-9, E-10, E-24, E-25, E-26, E-27, E-28, E-29

935 Modify IAFIS message A1003, A3026, and E1003 to include additional fields to support transmit of electronic rap sheet. Sections 3.1, 3.1.1.1, 3.1.1.11, App. C:

ERS, RAP, SCO, Table D-11.

938 Modify EFTS standard to include new Type-10 image record and 3 Type-2 records. Sections 1.2, 3.1.1.1, 3.1.1.2, 3.10, 3.10.1, 3.10.1.1, 3.10.1.2, 3.10.1.3, 3.10.2, 3.10.2.1, 3.10.2.2, Table I-1, I-2, I-3, I-4, J-1, App. K.

944 Change the EFTS to define three non-operational environments - training, test and development. Sections App. B: 1.04 (TOT), Table B-1.

946 Modify EFTS records Type 10 TOT=PHO, Type 2 TOT=PDR,PRR, CPD,CPR.

All records had field “IDC” added to them.

960 Extends the period of time from (7 to 14 days) for latent specialists and external users to confirm permanent addition to the unsolved latent fingerprint. Section 3.3.1.1,3.5, 3.5.1.2, 3.5.1.5

961 Provides latent service providers with the capability to solve latent cases. Section

Appendix F, 5.0

1021 Added Elements FGN and MSC. Changed the following EFTS Type-2 Records:

LSR-changed occurrence of CIN and CIX from 100 to 5, added elements DOB, HGT, WGT, CRI, ERS, NOTE, Deleted the following elements, AGR, HTR, WTR, EAD, OCP, RES; NAR - added element CRI; SRL - added elements FGN, MSC, NCR. Section Appendix C, Appendix E.

1023 Changes to PAT, Addition of AMP. Deleted the NCIC and the PAT from selected TOTs. Added AMP to selected TOTs. Section Appendices C, D, and E.

iv

1029 Redefined error messages based on usage, ERRA for administrative transaction errors, ERRT for ten-print transaction errors, ERRI for image transaction errors, and ERRL for latent transaction errors. Each group of transactions requires different data output when errors are encountered. The current EFTS lists 3 of these messages with the same name and a fourth error message for administrative messages was added. Customizing the messages this way will decrease response time when an error is encountered. Sections 3.1, 3.1.1.12, 3.2.1.4, 3.3, 3.3.1.8, 3.4, 3.4.1.4, 3.5, 3.5.1.7, 3.6, 3.6.1.1, 3.6.1.4, 3.7, 3.7.1.3, 3.8, 3.11, 3.11.1.5, Appendices D & E.

1025R2 Updated text to include SRE and CRN. Added Civil Record Number (CRN).

Section 3.1.1.11, Appendices C and D.

C. CJIS-RS-0010 (V6R2), March 1998 - This version has come about in three stages. A V6

Working Draft was produced in August, 1997 and was reviewed at a User Technical Review on August 26, 1997. Subsequent comments were incorporated as revision 1 of this working draft and distributed on September 30, 1997 as Version 6, Revision 1 (Working Draft).

Comments were received against revision 1 and were incorporated into an official V6R2 dated March 1998.

C.1 V6WD, August 1997 - This Version 6 Working Draft incorporates the following RFCs:

1024R2 Removed range AGR, WTR, HTR, DPR and DOS from ten-print transactions.

Added TAA to criminal ten-print transactions and CRI to all transactions requiring a response. Added PRI and case-ID extensions CIX and LCX to latent transactions.

Deleted the MIR as a separate transaction (subsumed into IRQ). Added latent requirements. Added placeholder for Type-7 and Type-9 records.

1035R3 Modified latent, and remote ten-print search requirements. Added CRI, FGP, NCR, and ULF to latent search records. Added fields and field edit specifications to Type-7 record. Modified MRC set definition for Type-9 record.

1051R3 Modified SRE (response) requirements to cover incomplete responses when dealing with NFF states.

1069R1 Added Appendix K describing the new NIST Type-10 (photo) record. Removed old

Appendix J, which formerly contained the interim Type-10 definition. Added DOS to photo transactions, CPR, CPD PDR, and PRR. Added DOS to PRR and PDR.

1070R1 Modified unsolved latent transactions. Replaced ULNC transaction with UULD.

Defined and added ASCN field to unsolved latent file maintenance transactions.

1074R1 Corrected error response text to recognize four distinct error types. Modified ERRI definition.

v

1078R1 Modified requirements for latent penetration query, latent cognizant query, and latent search status and modification query. Modified corresponding responses. Added ASCN to these queries for reference to prior search submissions. Removed SCO, OCA, ROR, RIX and QUE fields.

1080R1 Modified T9TRANS definition to include AFV.

1087R1 Established maximum sizes for fingerprint images.

1099R1 Established T2ISR, (Image Summary Response) transaction.

In addition to the RFCs listed above, the Version 6 Working Draft (V6WD) incorporates the following noteworthy general changes:

CJIS-RS-0010 (V7) vi January 29, 1999

1. Data for the tables in Appendices B through K now are drawn from a database rather than being entered as text in the WordPerfect EFTS document. This database, which is built in Microsoft Access, contains application-specific functionality to generate those tables.

2. The EFTS has been reformatted to present the data in Appendices D and E in a more concise manner. Text has been judiciously added to Section 1 and Appendix D to explain and provide a guide to the new table formats.

3. Text has been added in Section 2 on the use of tagged fields and on error handling.

4. JPEG has been added as an approved compression algorithm for fingerprint images (this applies to UK’s Home Office only.)

5. The Addendum, ANSI/NIST-ITL 1a-1997 (American National Standard For Information

Systems - Data Format for the Exchange of Fingerprint, Facial & SMT Information) has been incorporated into the EFTS for Type-10 Record Definitions.

Further, there have been changes in V6WD to some data elements and/or logical records which are not due to a prior RFC. These changes were made only to correct obvious oversights/errors in an RFC or in V5 data. Detail of these numerous changes has been documented in the EFTS V6WD Comments and Dispositions document.

C.2 V6WDR1, September 30, 1997 - This revision of the working draft incorporates changes arising from the disposition of comments by attendees of the User Technical Review on August 26, 1997, together with changes due to comments from internal reviews of V6WD. The internal reviews have resulted in RFCs 1127R1, 1129R1, and 1130R1. While the intent of these was to change the IAFIS MDD, they have affected some EFTS data. All such changes have been captured in the EFTS V6 Comment Dispositions document.

C.3 V6R2, March 1998 - RFC 1168R1 incorporates changes arising from ISS comments against V6WDR1 and IAFIS/SEU activities to make engineering data consistent between the EFTS and IAFIS’ Message Data Dictionary (MDD). These internal reviews have also resulted in some of the content of RFC 1149R1. While the intent of this RFC has been to correct the MDD, some changes also have affected the EFTS, and have been incorporated into V6R2.

CJIS-RS-0010 (V7) vii January 29, 1999

The following changes are noteworthy:

1. Every set using CRI now allows up to three instances of it. This provides a means to handle intermediate routing from the State Ident Bureau to the Local Booking Station where necessary. Additional instance of the CRI can be used as the States wish to support Applicant Submissions and other such needs.

2. Text in the body of the EFTS (especially Sections 3 and Appendix C) now states more clearly the intent and use of transactions and elements.

3. An Appendix L has been added that collects EFTS-wide summary tables for reference by developers. Currently, two types of tables have been put into this Appendix. The first is a set of two tables listing first in Alphabetic order, then in Tag order every EFTS element.

The second is a set of two tables, the first listing recordset requirements for each submission, the second listing recordset requirements for each possible response to each submission.

4. EFTS specifications for elements and sets are now consistent with the IAFIS’s MDD, now providing the same interface information to IAFIS segment developers and to the EFTS development community. These changes to Version 6 Revision 2 EFTS data, which are the results of a maturing IAFIS design, provide the robustness in the communication interface needed to support the user community’s automation of ten-print submissions.

D. CJIS-RS-0010 (V7), January 29, 1999 - This version incorporates several important revisions. New Type-9 records are defined for ten-print and latent features searches.

Latent transactions are revised. Several appendices are revised to provide references that were noted as lacking, and organization of some material has been changed to make it more accessible than in previous versions. The following provides more detail:

1195R2 Added these to Appendix C. Made PAT mandatory in ten-print features search.

Added RCD1, RCD2 to TPFS, TPIS, LFFS, LFIS, LPNQ. Added optional FGP to LPNQ. Remove IMA from LFFS

1200R2 Defined new Native Mode Searches for the EFTS. Replaced old T9TRANS

(Table J-1) recordset with T9TRANS_L (Table J-1) for latent searches and T9TRANS_T (Table J-2) for ten-print searches. Completely replaced Appendix J as a result. Added Reference Note Table (Table J-3) to Appendix J.

1213R1 Major Revision to EFTS. Incorporated IAFIS View Review Errata affecting

EFTS. Incorporated changes to Latent Transactions per November 15, 1998 EFTS Users Meeting. Incorporated various changes based upon user comments from NY, SC, CA, User Meeting Minutes, AFIS (Lockheed Martin, Orlando FL) EFIPS (Lockheed Martin, OakRidge TN), FBI Latent Fingerprint Section (Steve Meagher) and IAFIS System Engineering Unit. The following general revisions are of interest:

CJIS-RS-0010 (V7) viii January 29, 1999

1. Replaced entire Appendix J.

2. Revised Appendix L, replacing reference tables cross-referencing element IDs and tag numbers, and tables listing recordsets by transaction type.

3. Added detail to error codes in Appendix M.

4. Reorganized Reference Note Tables, distributing notes to appendices in which they are referenced.

5. Added discussion on ORI vice CRI use.

6. Added discussion of User Defined fields and edit restrictions to same.

7. Revised discussion of IAFIS error handling.

8. Revised descriptions of latent and native-mode search transactions.

CJIS-RS-0010 (V7) ix January 29, 1999

RECORD OF CURRENT CHANGES

RFC VERSION SECTION DESCRIPTION OF CHANGE

CJIS-RS-0010 (V7) x January 29, 1999

TABLE OF CONTENTS

CHANGE HISTORY .................................................................................................................................................. iii RECORD OF CURRENT CHANGES.........................................................................................................................ix TABLE OF CONTENTS ..............................................................................................................................................x LIST OF TABLES..................................................................................................................................................... xiii LIST OF FIGURES....................................................................................................................................................xiv

SECTION 1 INTRODUCTION

1.1 Background

1.2 Contents of Specification

1.3 Change Control

1.4 Tagged Fields

1.4.1 Interpretation of Tags

1.4.2 Use of Separator Characters

1.5 Error Handling

1.6 Identifying Previous Transactions

1.7 Data Storage in the IAFIS Database

1.8 Guidance on ORI and CRI Usage

SECTION 2 SCOPE

SECTION 3 DESCRIPTION OF OPERATIONAL CONCEPTS

3.1 Electronic Ten-print Submissions

3.1.1 Type of Transaction Definitions

3.1.1.1 Criminal Ten-Print Submission (Answer Required) (CAR)

3.1.1.2 Criminal Ten-Print Submission (No Answer Necessary) (CNA)

3.1.1.3 Federal Applicant (No Charge) (FANC)

3.1.1.4 Federal Applicant User Fee (FAUF)

3.1.1.5 Non-Federal Applicant User Fee (NFUF)

3.1.1.6 Miscellaneous Applicant Civil (MAP)

3.1.1.7 Known Deceased (DEK)

3.1.1.8 Unknown Deceased (DEU)

3.1.1.9 Missing Person (MPR)

3.1.1.10 Amnesia Victim (AMN)

3.1.1.11 Submission Results — Electronic (SRE)

3.1.1.12 Ten Print Transaction Error (ERRT)

3.1.2 Requirements for Logical Record Types

3.2 Remote Ten-Print Searches

3.2.1 Type of Transaction Definitions

3.2.1.1 Ten-Print Fingerprint Image Searches (TPIS)

3.2.1.2 Ten-Print Fingerprint Features Search (TPFS)

3.2.1.3 Search Results — Ten-Print (SRT)

3.2.1.4 Ten-Print Transaction Error (ERRT)

3.2.2 Requirements for Logical Record Types

3.3 Electronic Submission of Latent Prints

3.3.1 Type of Transaction Definitions

3.3.1.1 Latent Fingerprint Image(s) Submission (LFS)

3.3.1.2 Comparison Fingerprint Image(s) Submission (CFS) (For use by FBI only)

3.3.1.3 Major Case Image(s) Submission (MCS) (For use by FBI only)

3.3.1.4 Evaluation Latent Fingerprint Submission Request (ELR) (For use by FBI only)

3.3.1.5 Latent Submission Results (LSR)

3.3.1.6 Notification of Action Response (NAR)

3.3.1.7 Reserved

3.3.1.8 Latent Transaction Error (ERRL)

3.3.2 Requirements for Logical Record Types

CJIS-RS-0010 (V7) xi January 29, 1999

3.4 Remote Latent Fingerprint Searches

3.4.1 Type of Transaction Definitions

3.4.1.1 Latent Fingerprint Image(s) Search (LFIS)

3.4.1.2 Latent Fingerprint Features Search (LFFS)

3.4.1.3 Search Results - Latent (SRL)

3.4.1.4 Unsolved Latent Match Response (ULM)

3.4.1.5 Latent Penetration Query (LPNQ)

3.4.1.6 Latent Penetration Query Response (LPNR)

3.4.1.7 Transaction Error (ERRL)

3.4.2 Requirements for Logical Record Types

3.5 Latent File Maintenance Requests

3.5.1 Type of Transaction Definitions

3.5.1.1 Unsolved Latent Record Delete Request (ULD)

3.5.1.2 Unsolved Latent Add Confirm Request (ULAC)

3.5.1.3 Unsolved Latent Add Confirm Response (ULAR)

3.5.1.4 Unsolved Latent Delete Response (ULDR)

3.5.1.5 Unsolicited Unsolved Latent Delete (UULD)

3.5.1.6 Reserved

3.5.1.7 Latent Transaction Error (ERRL)

3.5.2 Requirements for Logical Record Types

3.6 Remote Requests For Fingerprint Images

3.6.1 Type of Transaction Definitions

3.6.1.1 Fingerprint Image Request (IRQ)

3.6.1.2 Reserved

3.6.1.3 Fingerprint Image Request Response (IRR)

3.6.1.4 Fingerprint Image Response Summary (ISR)

3.6.1.5 Image Transaction Error (ERRI)

3.6.2 Requirements for Logical Record Types

3.7 Electronic Requests To Upgrade Fingerprint Images

3.7.1 Type of Transaction Definitions

3.7.1.1 Fingerprint Image Submission (FIS)

3.7.1.2 Fingerprint Image Submission Response (FISR)

3.7.1.3 Image Transaction Error (ERRI)

3.7.2 Requirements for Logical Record Types

3.8 Error Message Format

3.9 Other Special Requirements For Communicating With IAFIS

3.9.1 Electronic Fingerprint Images

3.9.2 Fingerprint Image Compression/Decompression Algorithm

3.9.3 Fingerprint Image Quality Specifications

3.9.4 Fingerprint Image Size Requirements

3.10 Electronic Criminal Subject Photo Services

3.10.1 Type of Transaction Definitions

3.10.1.1 Criminal Subject Photo Request (CPR)

3.10.1.2 Criminal Subject Photo Delete Request (CPD)

3.10.1.3 Photo Responses

3.10.2 Requirements for Logical Record Types

3.10.2.1 Photo Request

3.10.2.2 Photo Delete Request

3.11 Latent Administrative Queries, Requests and Responses

3.11.1 Type of Transaction Definitions

3.11.1.1 Latent Repository Statistics Query (LRSQ)

3.11.1.2 Latent Search Status and Modification Query (LSMQ)

3.11.1.3 Latent Repository Statistics Response (LRSR)

3.11.1.4 Latent Search Status and Modification Response (LSMR)

3.11.1.5 Administrative Transaction Error (ERRA)

3.11.2 Requirements for Logical Record Types

CJIS-RS-0010 (V7) xii January 29, 1999

APPENDIX A TRANSACTION PRIORITIES

APPENDIX B DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-1 LOGICAL RECORDS

APPENDIX C DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-2 LOGICAL RECORDS

APPENDIX D LOGICAL RECORD LAYOUTS FOR TYPE-TWO (TEN-PRINT)

APPENDIX E SUMMARY FIELD LISTS FOR LATENT TRANSACTIONS

APPENDIX F IAFIS IMAGE QUALITY SPECIFICATIONS

APPENDIX G INTERIM IAFIS IMAGE QUALITY SPECIFICATIONS FOR SCANNERS

APPENDIX H DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-7 LOGICAL RECORDS...114

APPENDIX I LOGICAL RECORD LAYOUT FOR TYPE-2 (IMAGE) RECORDS

APPENDIX J DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-9 LOGICAL RECORDS

APPENDIX K DESCRIPTORS AND FIELD EDIT SPECIFICATIONS FOR TYPE-10 LOGICAL RECORDS

AND LOGICAL RECORD FIELD LISTS FOR TYPE-2 (PHOTO) RECORDS

APPENDIX L SUMMARY TABLES

APPENDIX M TRANSACTION ERROR MESSAGES

ACRONYMS

CJIS-RS-0010 (V7) xiii January 29, 1999

LIST OF TABLES

TABLE 3-1. VALUES of NAM, FBI and SID RETURNED in the SRE

TABLE A-1. PRIORITIES

TABLE B-1. FIELD LIST FOR TYPE-1 (TRANSACTION) LOGICAL RECORDS

TABLE C-1. FIELD EDIT SPECIFICATIONS FOR TYPE-2 ELEMENTS

TABLE D-1. FIELD LIST FOR TEN-PRINT, ANSWER-REQUIRED (CAR) TRANSACTION

TABLE D-2. FIELD LIST FOR TEN-PRINT RESPONSE, ELECTRONIC (SRE) TRANSACTION

TABLE D-3. SUMMARY FIELD LISTS FOR TEN-PRINT TRANSACTIONS

TABLE D-4. APPENDIX D REFERENCE NOTES

TABLE E-1. SUMMARY FIELD LISTS FOR LATENT TRANSACTIONS (Part 1 of 2)

TABLE E-2. SUMMARY FIELD LISTS FOR LATENT TRANSACTIONS

TABLE E-3. APPENDIX E REFERENCE NOTES

TABLE H-1. FIELD LIST FOR TYPE-7 (MISCELLANEOUS IMAGE) LOGICAL RECORDS

TABLE I-1. FIELD LIST FOR IMAGE REQUEST (IRQ) TRANSACTION

TABLE I-2. FIELD LIST FOR IMAGE REQUEST RESPONSE (IRR) TRANSACTION

TABLE I-3. FIELD LIST FOR IMAGE ERROR RESPONSE (ERRI) TRANSACTION

TABLE I-4. FIELD LIST FOR FINGERPRINT IMAGE SUBMISSION (FIS) TRANSACTION

TABLE I-5. FIELD LIST FOR FINGERPRINT IMAGE SUBMISSION RESPONSE (FISR)

TABLE I-6. FIELD LIST FOR IMAGE SUBMISSION RESPONSE (ISR) TRANSACTION

TABLE J-1. FIELD LIST FOR TYPE-9 (MINUTIAE) REMOTE, NATIVE-MODE TEN-PRINT LOGICAL

RECORD

TABLE J-2. FIELD LIST FOR TYPE-9 (MINUTIAE) REMOTE, NATIVE-MODE LATENT LOGICAL

RECORD

TABLE J-3. APPENDIX J REFERENCE NOTES

TABLE K-1. FIELD LIST FOR CRIMINAL PHOTO REQUEST (CPR) TRANSACTION

TABLE K-2. FIELD LIST FOR CRIMINAL PHOTO DELETE REQUEST (CPD) TRANSACTION

TABLE K-3. FIELD LIST FOR CRIMINAL PHOTO REQUEST RESPONSE (PRR) TRANSACTION

TABLE K-4 FIELD LIST FOR CRIMINAL PHOTO DELETE REQUEST RESPONSE (PDR)

TRANSACTION

TABLE K-5. FIELD LIST FOR TYPE-10 (CRIMINAL PHOTO) LOGICAL RECORDS

TABLE K-6. APPENDIX K REFERENCE NOTES

TABLE L-1. COMPLETE ELEMENT CROSS-REFERENCE LIST BY ID

TABLE L-2. COMPLETE ELEMENT CROSS-REFERENCE LIST BY TAG NUMBER

TABLE L-3. RECORDSET REQUIREMENTS SUMMARY BY TYPE OF TRANSACTION

TABLE L-4. RECORDSET REQUIREMENTS SUMMARY BY TYPE OF RESPONSE

TABLE M-1. TRANSACTION ERROR MESSAGES

CJIS-RS-0010 (V7) xiv January 29, 1999

LIST OF FIGURES

Figure 1. Electronic Ten-Print Submission Figure 2. Remote Ten-Print Search Figure 3. Electronic Latent Submission Figure 4. Remote Latent Search Figure 5. Electronic Request to Delete Unsolved Latent Fingerprint Records Figure 6. Remote Fingerprint Image Request Figure 7. Electronic Requests to Upgrade Fingerprint Images

CJIS-RS-0010 (V7) xv January 29, 1999

How to use this document:

The Appendices of this document contain all the information that you will need in order to find all information regarding a particular type of electronic transaction. Definitions for transaction types can be found in Section 3. Appendix A briefly presents priorities for each transaction type.

Appendix B is the field list for Type-1 records. Appendix C contains the definitions of fields used for the Type-2 records. Type-2 field lists can be found in Appendix D for ten-print transactions, Appendix E for Latent searches and submissions. Appendix F gives Image Quality Specifications for fingerprint scanners and displays. Appendix H presents the Type-7 field list.

Appendix I presents Image retrieval and maintenance transactions. Appendix J gives the Type-9 field list. Appendix K details the Type-10 field list and the Type-2 (Photo) field lists. Appendix L provides a complete cross-references of elements and their tag numbers, and lists logical record requirements for each EFTS transaction type. Appendix M contains error message details. For example, to obtain information for sending a Criminal Ten-Print Submission, (Answer Required) (CAR), refer to Section 3 for CAR definition, Appendix B for Type-1 field list, Appendix D for the Type-2 CAR field list, and Appendix C for field definitions.

CJIS-RS-0010 (V7) 1 January 29, 1999

SECTION 1

SECTION 1 INTRODUCTION

INTRODUCTION

1.1 Background

For almost 100 years fingerprint cards have 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) 2 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) 3 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 subfields1 (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.

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

CJIS-RS-0010 (V7) 4 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;

4• 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;

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) 5 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) 6 January 29, 1999

SECTION 2

SECTION 2 SCOPE

SCOPE

This document specifies the file and record content, format, and data codes necessary for the exchange of fingerprint identification information between Federal, State and local users and the FBI. It provides a description of all requests and responses associated with electronic fingerprint identification services. These fingerprint identification services include the following:

1. Ten-Print Services

2. Latent Services

3. Fingerprint Image Services

Ten-print services can be accessed through electronic ten-print submissions and remote searches. Electronic submissions involve processing and evaluation judgments by FBI personnel. Remote searches are transactions that interface with automated equipment without human intervention by FBI personnel. Ten-print services also include requests to update current fingerprint images. Latent services are comprised of electronic latent submissions handled by FBI latent examiners and automatic remote searches of the FBI latent databases. Finally, image requests are used to solicit fingerprint images stored by the FBI. All transactions and messages are compliant with the ANSI standard for exchange of fingerprint information.

Section 3 gives a description of the seven types of fingerprint transactions in the electronic environment. It also establishes error messages, specific compression algorithms for the exchange of fingerprint image information, and image quality assurance methods. Appendix A establishes the priorities of incoming transactions. Appendix B includes Field Edit Specifications and a sample field list for the Type-1 record. Appendix C is the Descriptors and Field Edit Specifications for the Type-2 records. Appendix D summarizes Ten-Print transactions, listing in more detail the Criminal Ten-Print Answer Required (CAR) and Search Results, Electronic (SRE) transactions.

Appendix E summarizes Type-2 records for Latent transactions. Appendix F provides the image quality specifications for IAFIS equipment. Appendix G provides the interim image quality specifications. Appendix H is the Field Edit Specifications and a sample field list for Type-7 records. Appendix I includes Type-2 record samples of each Image Type of Transaction. Appendix J includes Field Edit Specifications and a sample field list for the Type- 9 record.

CJIS-RS-0010 (V7) 7 January 29, 1999

Appendix K includes Field Edit Specifications and sample field lists for the Type-2 (Photo) and the newly added Type-10 records, which are defined in the ANSI/NIST Addendum to the Electronic Fingerprint Transmission Standard. This addendum now defines a standard for transmitting mugshots. Appendix L provides cross-references, both by name and by ID, for all elements, Type-1 through Type-10, and also provides a summary of recordset requirements for submission and response TOTs. Appendix M is a listing of Error Messages that might be received in response to a submission.

CJIS-RS-0010 (V7) 8 January 29, 1999

SECTION 3

SECTION 3 DESCRIPTION OF OPERATIONAL CONCEPTS

DESCRIPTION OF OPERATIONAL CONCEPTS

The FBI CJIS Division will process the following seven types of fingerprint transactions from the three main service areas in its electronic environment:

Ten-Print Services Electronic Ten-Print Submissions Remote Ten-Print Searches

Latent Services Electronic Latent Submissions Remote Latent Searches Latent Image Maintenance Requests

Image Services Remote Requests for Fingerprint Images Electronic Requests to Upgrade Fingerprint Images

Photo Services Criminal Subject Photo Request Criminal Subject Photo Delete Request Criminal Subject Photo Response Criminal Subject Photo Delete Response

Details of the individual types of transaction are provided in the paragraphs below.

3.1 Electronic Ten-print Submissions

The processing flow for ten-print electronic submissions is illustrated in Figure 1, “Electronic Ten-Print Submission.” These submissions will originate from live-scan booking terminals or card scanners at either the federal, state or local level. Local submissions may be processed by a local AFIS and electronically transmitted to a state identification bureau for processing. If an identification is made at the state level, an Ident response will be transmitted back to the local agency, and if it is a criterion offense, it is to be forwarded to the FBI.

If no identification is made, the data will be forwarded via the CJIS WAN to the FBI for processing by IAFIS. Transmitted data will be automatically edited and a subject search will be conducted. If no identification is effected through comparison of candidates resulting from subject search, a fingerprint search will be executed through the FBI’s AFIS. The fingerprint images of any resulting file candidates will be compared to the search fingerprint images by FBI

CJIS-RS-0010 (V7) 10 January 29, 1999 fingerprint examiners. Electronic responses2 from IAFIS to the contributor will be electronically routed via the CJIS WAN through the State Identification Bureau (the ORI). Subsequent routing to the arresting agency is made by the State Ident Bureau using the CRI. Additional copies are routed by the State Ident Bureau using the SCO or other related information (see Appendices B and C for detailed ORI, SCO and CRI definitions).

Electronic criminal transactions will have a nominal 2-hour turnaround within IAFIS.

Civil transactions, and card-based transactions, once received, will have a 24-hour nominal

2 Established procedures for sending unsolicited messages to state identification bureaus in response to fingerprint cards from Interstate Identification Index (III) participating states will not be affected.

CJIS-RS-0010 (V7) 11 January 29, 1999 turnaround. The turnaround times are based on the type of transaction and are specified in Appendix A.

There are several types of ten-print electronic submissions that will be accepted by the FBI. The particular type of submission is identified in the Type of Transaction (TOT) Field in the Type-1 record that is used with each transaction. The following are the TOTs for ten-print submissions:

TOT TRANSACTION

CAR Criminal Ten-Print Submission (Answer Required) CNA Criminal Ten-Print Submission (No Answer Necessary) FANC Federal Applicant (No Charge) FAUF Federal Applicant User Fee NFUF Non-Federal Applicant User Fee MAP Miscellaneous Applicant Civil DEK Known Deceased DEU Unknown Deceased MPR Missing Person AMN Amnesia Victim

The FBI’s responses to electronic submissions will provide search results or indicate an error via the following TOTs:

TOT RESPONSE TRANSACTION

SRE Submission Results – Electronic ERRT Ten-Print Transaction Error

3.1.1 Type of Transaction Definitions

3.1.1.1 Criminal Ten-Print Submission (Answer Required) (CAR)

This transaction is a criminal arrest fingerprint submission for which the requester desires that a response be returned. It contains ten rolled and four plain impressions of all ten fingers, as well as information relative to an arrest or to custody or supervisory status and optionally may include up to 4 photos of the subject. The biographical data and fingerprint images are used to determine potential candidates with criminal records at the FBI. This TOT is also used for an inquiry on a criminal suspect or informant, in which case arrest, custody, or supervisory data may or may not be present (Retention Code set to "N"). Requirements for the use of the ASL and CSL fields in these cases is discussed in Appendix C. The fingerprint images of those candidates are then manually compared with those in the submission and an identification or non- identification decision is determined. The criminal records are updated (if the Retention Code is set to "Y") the photos are added to the file and a response is returned to the contributor.

The response will always contain the Ident/Non-Ident decision, and will contain the electronic rap sheet if requested. Table D-1 gives the logical record layout for the CAR TOT.

CJIS-RS-0010 (V7) 12 January 29, 1999

3.1.1.2 Criminal Ten-Print Submission (No Answer Necessary) (CNA)

This transaction is a criminal arrest fingerprint submission for which the requester desires that no response be transmitted back. Otherwise, it is identical to the CAR request described above, containing ten rolled and four plain impressions, arrest, custody or supervisory status data, and optionally up to 4 photos of the subject. Processing is also identical except that no response is returned. However, a communication protocol acknowledgment will be returned to the contributor to confirm receipt of the transaction. The Retention Code for this transaction must be set to "Y". The CNA TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

3.1.1.3 Federal Applicant (No Charge) (FANC)

This transaction pertains to an individual who is fingerprinted in connection with applying for criminal justice employment with the Federal Government. When this TOT is used, there is no charge assessed to the contributor. Federal agencies which are considered "User Fee" contributors must not use this TOT, but use "FAUF" instead (see description below). The FANC TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

3.1.1.4 Federal Applicant User Fee (FAUF)

These submissions come from: (1) any of the branches of the U. S. military in connection with individuals enlisting or being considered for Officers’ Candidate School (OCS);

and (2) federal agencies in connection with employment, security updates, or contract personnel.

The FAUF TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1. See also Section 1.6 for a discussion of the use of TCN and TCR in no-charge resubmittal of user-fee submissions that the FBI has rejected. Such resubmittals are allowed only when the fingerprint image quality of the original submission was unacceptable.

3.1.1.5 Non-Federal Applicant User Fee (NFUF)

These submissions are for non-criminal justice and licensing purposes in which the contributor is charged a fee. Examples of the types of contributors of this type of transaction are:

federal and state banking institutions, regulatory agencies (such as stock exchanges, bankers’ associations, securities dealers, Nuclear Regulatory Commission, Securities and Exchange Commission, racing or gaming control board, etc.). Their purpose for submitting such requests is to ascertain whether individuals who have applied for licensing or employment with their organizations have any past criminal histories. The NFUF TOT is summarized in Table D-3.

Edit specifications for the fields it uses may be found in Table C-1. See also Section 1.6 for a discussion of the use of TCN and TCR in no-charge resubmittal of user-fee submissions that the FBI has rejected. Such resubmittals are allowed only when the fingerprint image quality of the original submission was unacceptable.

CJIS-RS-0010 (V7) 13 January 29, 1999

3.1.1.6 Miscellaneous Applicant Civil (MAP)

These no-charge submissions are for non-federal law enforcement and criminal justice employment. The MAP TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

3.1.1.7 Known Deceased (DEK)

These transactions are submitted for a deceased individual whose identity is known to the contributor. If the fingerprints are determined to be identical to those of a subject in the FBI’s criminal files, the subject’s FBI record will be marked as deceased. The ICO field in this submission must be filled with the text “DECEASED”. The DEK TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

3.1.1.8 Unknown Deceased (DEU)

This transaction is submitted with fingerprints taken from an individual who was deceased at that time but whose identity was not known to the contributor. If the fingerprints are determined to be identical to those of a subject in the FBI’s criminal files, the subject’s FBI record will be marked as deceased and the contributor will be notified of the results. Should no identification to a subject on file be effected, the subject will be added to the criminal file in order to be identified with missing persons reports. A search of the Civil File will be conducted following the Criminal File search if a "Y" is placed in the CSR field. The DEU TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

3.1.1.9 Missing Person (MPR)

These non-criminal submissions pertain to persons reported as missing. Their submission causes a search of the FBI files and may result in the placement of a “stop” in FBI automated files to create the possibility of a future fingerprint submission (of any type) hitting against the original set of fingerprints and establishing the person’s whereabouts. These subjects are added to the Criminal File. The Action to be Taken (ACN) field of the response will indicate if a “stop” has been established. The ICO field in this submission must be filled with the text “MISSING PERSON”. A search of the Civil File will be conducted following the Criminal File search if a "Y" is placed in the CAR field. The MPR TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

CJIS-RS-0010 (V7) 14 January 29, 1999

3.1.1.10 Amnesia Victim (AMN)

These non-criminal submissions pertain to persons known to have amnesia who are unaware of their own identity. The submission causes a search of the FBI files and may result in the placement of a "stop" in FBI automated files to create the possibility of a future fingerprint submission (of any type) hitting against the original set of fingerprints and establishing the person’s identity. These subjects are added to the Criminal File. The ACN field of the response will indicate if a "stop" has been established. The ICO field in this submission must be filled with the text “AMNESIA VICTIM”. A search of the Civil File will be conducted following the Criminal File search if a "Y" is placed in the CSR field. The AMN TOT is summarized in Table D-3. Edit specifications for the fields it uses may be found in Table C-1.

3.1.1.11 Submission Results — Electronic (SRE)

This transaction is returned by the FBI in response to ten-print submissions. The response will always contain the Ident/Non-Ident decision, and will contain the electronic rap sheet if requested. Table 3-1 describes which NAME, FBI number and State ID (SID) are returned in the SRE for Criminal, Civil and Humanitarian submissions, and for Non-Ident and Ident results. A non-matching NAME is returned in the electronic rap sheet (ERS), if one was requested.