NIST Special Publication 1152

Latent Interoperability Transmission 

Specification

Will Chapman

Austin Hicklin

George Kiebuzinski

Peter Komarinski

John Mayer-Splain

Melissa Taylor

Rachel Wallner

http://dx.doi.org/10.6028/NIST.SP.1152
NIST Special Publication 1152

Latent Interoperability Transmission 

Specification

Melissa Taylor

Law Enforcement Standards Office

Office of Special Programs

Will Chapman

Austin Hicklin

George Kiebuzinski

John Mayer-Splain

Rachel Wallner

Noblis

Falls Church, VA

Peter Komarinski

Komarinski & Associates, LLC

Rotterdam, NY

http://dx.doi.org/10.6028/NIST.SP.1152

January 2013

U.S. Department of Commerce 

Rebecca Blank, Acting Secretary

National Institute of Standards and Technology 

Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director 
Certain commercial entities, equipment, or materials may be identified in this

document in order to describe an experimental procedure or concept adequately.

Such identification is not intended to imply recommendation or endorsement by the

National Institute of Standards and Technology, nor is it intended to imply that the

entities, materials, or equipment are necessarily the best available for the purpose. 

National Institute of Standards and Technology Special Publication 1152

Natl. Inst. Stand. Technol. Spec. Publ. 1152, 46 pages (January 2013)

http://dx.doi.org/10.6028/NIST.SP.1152

CODEN: NSPUE2
iii

Latent Interoperability Transmission 

Specification

The Latent Interoperability Transmission Specification (LITS) is an application profile of the American 

National Standard for Information Systems: Data Format for the Interchange of Fingerprint, Facial & 

Other Biometric Information, American National Standards Institute/National Institute of Standards and 

Technology, Information Technology Laboratory (ANSI/NIST-ITL) 1-2011. LITS is a system-level 

specification, parallel to and compatible with the Federal Bureau of Investigation Criminal Justice 

Information Services Electronic Biometric Transmission Specification that focuses on the definition of 

vendor-neutral latent transactions to be exchanged among disparate cross-jurisdictional automated 

friction ridge identification systems (AFIS).

The purpose of LITS is to enable seamless, efficient hierarchical (from local to State to regional to 

Federal) and peer to peer (local to local, State to State, etc.) searches; to simplify acquisitions by defining 

a uniform latent AFIS data exchange format; and to enable the interchange of latent print annotation 

among examiners as part of non-AFIS casework.

LITS addresses latent AFIS interoperability between and among the States, local law enforcement 

agencies, regional organizations, and Federal organizations, such as the Department of Defense or the 

Department of Homeland Security.
January 2013 iv

1 Introduction........................................................................................................................................ 1

1.1 Purpose....................................................................................................................................... 2

1.2 Scope........................................................................................................................................... 3

1.3 Constraints and Assumptions...................................................................................................... 3

1.4 Name of Designated Repository Values...................................................................................... 4

2 Conformance ...................................................................................................................................... 5

2.1 Basic AFIS Implementation.......................................................................................................... 6

2.2 Optional AFIS Implementation.................................................................................................... 6

2.3 Casework Annotation and Exchange Implementation ................................................................ 7

3 Normative References ........................................................................................................................ 8

4 Concept of Operations........................................................................................................................ 9

4.1 Queries and Responses............................................................................................................... 9

4.1.1 Latent Friction Ridge Searches and Responses.................................................................... 9

4.1.2 Image Request and Response ........................................................................................... 10

4.2 Unsolved Latent File Transactions............................................................................................. 11

4.2.1 Unsolved Latent Match and Biometric Decision ............................................................... 11

4.2.2 Unsolicited Unsolved Latent Delete .................................................................................. 12

4.2.3 Unsolved Latent File Maintenance Transactions............................................................... 12

5 Transactions...................................................................................................................................... 13

5.1 Application Profile Specification ............................................................................................... 13

5.2 Implementation Domain ........................................................................................................... 13

5.3 Identification Numbers ............................................................................................................. 13

5.4 Queries...................................................................................................................................... 14

5.4.1 Record Set Requirements.................................................................................................. 14

5.4.2 Latent Friction Ridge Image Search (LFIS) ......................................................................... 15

5.4.3 Latent Friction Ridge Features Search (LFFS)..................................................................... 15

5.4.4 Image Request (IRQ) ......................................................................................................... 16

5.4.5 Biometric Decision (BDEC)................................................................................................. 16

5.5 Responses................................................................................................................................. 17

5.5.1 Record Set Requirements.................................................................................................. 17

5.5.2 Search Results – Latent (SRL) ............................................................................................ 17

5.5.3 Latent Transaction Error (ERRL) ........................................................................................ 18

5.5.4 Image Request Response (IRR).......................................................................................... 18

5.5.5 Image Error Response (ERRI)............................................................................................. 18

5.5.6 Image Summary Response (ISR)........................................................................................ 18

5.6 Unsolved Latent File Transactions............................................................................................. 18

5.6.1 Record Set Requirements.................................................................................................. 18

5.6.2 Unsolved Latent Match (ULM) .......................................................................................... 19
January 2013 v

5.6.3 Unsolicited Unsolved Latent Delete (UULD)...................................................................... 19

5.6.4 Unsolved Latent Record Delete Request (ULD)................................................................. 19

5.6.5 Unsolved Latent Delete Response (ULDR)......................................................................... 19

6 Type-2 Logical Record Requirements................................................................................................ 20

6.1 Data Dictionary ......................................................................................................................... 20

6.1.1 CSD 2.1401—Case Description.......................................................................................... 20

6.1.2 CSN 2.1402—Case Name................................................................................................... 20

6.1.3 IMN 2.1403—Image Number............................................................................................ 20

6.1.4 IML 2.1404—Impression Letter......................................................................................... 20

6.1.5 STR 2.1406—Source Transaction Reference ..................................................................... 20

6.2 Summary Field List.................................................................................................................... 24

7 Type-9 Logical Record Requirements................................................................................................ 27

Appendix A Casework Annotation and Exchange ................................................................................. 28

A.1 Record Set Requirements.......................................................................................................... 28

A.1.1 Comparison (COMP).......................................................................................................... 28

A.1.2 Analysis (ASYS) .................................................................................................................. 29

A.1.3 Casework Exchange (CWE)................................................................................................ 29

A.2 Summary Field List.................................................................................................................... 30

Appendix B Latent Case Processing Scenarios...................................................................................... 32

B.1 Neighboring City........................................................................................................................ 32

B.2 Better Impression...................................................................................................................... 32

B.3 International ............................................................................................................................. 32

B.4 Newer AFIS................................................................................................................................ 32

B.5 Military...................................................................................................................................... 32

B.6 Highly Publicized ....................................................................................................................... 33

B.7 Natural Disaster ........................................................................................................................ 33

Appendix C Transaction Error Messages.............................................................................................. 34

Appendix D Abbreviations.................................................................................................................... 38
January 2013 vi

Figure 1—Latent Friction Ridge Search and Response.............................................................................. 10

Figure 2—Image Request and Response................................................................................................... 11

Table 1—APS 1.016—Application Profile Specifications........................................................................... 13

Table 2—DOM 1.013—Domain Name ...................................................................................................... 13

Table 3—Record Set Requirements for Queries ....................................................................................... 14

Table 4—Record Set Requirements for Responses................................................................................... 17

Table 5—Record Set Requirements for Unsolved Latent File Transactions.............................................. 18

Table 6—Field Edit Specifications for Type-2 Fields.................................................................................. 21

Table 7—STR 2.1406—Source Transaction Reference Information Items................................................ 22

Table 8—Example of COMP Transaction Based on ANSI/NIST-ITL Transactions....................................... 23

Table 9—Example of COMP Transaction Based on Image Files. ............................................................... 23

Table 10—Summary Field List for Basic AFIS Implementation.................................................................. 24

Table 11—Summary Field List for Optional AFIS Implementation ............................................................ 25

Table 12—Record Set Requirements for Casework Annotation and Exchange ........................................ 28

Table 13—Summary Field List for Casework Annotation and Exchange ................................................... 30
1

1 Introduction

The Latent Interoperability Transmission Specification (LITS) is in recognition of and response to the 

following factors:

Recommendation 121in Strengthening Forensic Science in the United States: A Path Forward,

2

a 

report by The National Academies of Science that identifies the need “to launch a new broadbased effort to achieve nationwide fingerprint data interoperability.” 

The following limitations in the ability to search a latent print against another State or local 

database and the inability to communicate among disparate Automated Friction ridge 

Identification Systems (AFIS) need to be addressed

o There is no commonly accepted vendor-agnostic latent data exchange specification for 

use at the State/local level.

o There are differing rules for feature notation and extraction for each vendor.

There is growing recognition of the need for latent print interoperability, as evidenced by the 

testimonies and data collected by the Executive Office of the President of the United States AFIS 

Interoperability Task Force and the National Institute of Standards and Technology

(NIST)/National Institute for Justice AFIS Interoperability Working Group.

The development of the Extended Feature Set (EFS) for friction ridge images provides a vendorneutral feature set that may be used to search the Federal Bureau of Investigation’s (FBI’s) Next 

Generation Identification (NGI) and databases of State and local agencies with different AFIS 

vendors. Testing of the EFS has shown that major AFIS system vendors can interoperate 

effectively using a common method of latent encoding. The EFS has been incorporated in 

American National Standard for Information Systems; Data Format for the Interchange of 

Fingerprint, Facial & Other Biometric Information, American National Standards 

Institute/National Institute of Standards and Technology, Information Technology Laboratory 1-

2011 (ANSI/NIST-ITL, 2011).

3

The development of EFS definitions enables the interchange of latent print annotation among 

examiners as part of non-AFIS casework.

 

1

Recommendation 12 calls for the development of new standards. These include the following:

(a) standards for representing and communicating image and minutiae data among Automated 

Fingerprint Identification Systems. Common data standards would facilitate the sharing of fingerprint data 

among law enforcement agencies at the local, state, federal, and even international levels, which could 

result in more solved crimes, fewer wrongful identifications, and greater efficiency with respect to 

fingerprint searches; and

(b) baseline standards—to be used with computer algorithms—to map, record, and recognize features in 

fingerprint images, and a research agenda for the continued improvement, refinement, and 

characterization of the accuracy of these algorithms (including quantification of error rates).

2

National Academy of Sciences. 2009. Strengthening Forensic Science in the United States: A Path Forward. 

http://www.nap.edu/catalog.php?record_id=12589.

3

ANSI/NIST-ITL 1-2011 (NIST SP 500-290). Data Format for the Interchange of Fingerprint, Facial & Other Biometric 

Information. http://www.nist.gov/itl/iad/ig/ansi_standard.cfm.
2

This specification is one of three interrelated specifications that have been designed to enable vendorneutral latent AFIS interoperability. 

Extended Feature Set Profile Specification (EFS Profiles)

4—defines the sets of features to be used 

in latent friction ridge (fingerprint/palmprint or plantar5) AFIS searches. EFS Profiles is a 

supporting document to ANSI/NIST-ITL (2011).

(Note: EFS Profiles for fundamental latent AFIS transactions include the image.)

Markup Instructions for Extended Friction Ridge Features (Markup)

6—specifies a common set of 

instructions and data annotation guidelines for the markup of EFS features by latent print 

examiners.

Latent Interoperability Transmission Specification (LITS)—completes the progression by 

providing definitions of transactions between exchanging agencies, which are expected to 

include, but not necessarily be limited to, State and local law enforcement agencies. LITS is a 

system-level specification, parallel to and compatible with the FBI Criminal Justice Information 

Services (CJIS) Electronic Biometric Transmission Specification (EBTS), that focuses on the 

definition of vendor-neutral latent transactions to be exchanged among disparate crossjurisdictional AFIS.

In this specification, the term “to mark” refers to the recording of latent friction ridge features (generally 

by a latent print examiner), and “markup” refers to the features so marked. ANSI/NIST-ITL (2011) 

defines the term “mark” as “the point where a needle has pierced the skin, usually associated with drug 

use,” and in its introduction states, “The term ‘marks’ in some nations denotes what is called ‘latent 

prints.’”

1.1 Purpose

The purpose of LITS is to

enable seamless, efficient hierarchical (local to State to regional to Federal) and peer to peer 

(local to local, State to State, etc.) searches 

simplify acquisitions by defining a uniform latent AFIS data exchange format

enable the interchange of latent print annotation among examiners as part of non-AFIS 

casework

 

4

Extended Feature Set Profile Specification. 2012. http://www.nist.gov/itl/iad/ig/ansi_standard.cfm.

5

Although friction ridge features defined for fingers also may be applicable to toes, they are explicitly excluded 

from the scope of this document because many of these characteristics, such as pattern classification, are 

undefined for toes as of this writing.

6 Markup Instructions for Extended Friction Ridge Features. 2013.

http://www.nist.gov/itl/iad/ig/ansi_standard.cfm.
3

1.2 Scope

LITS includes the following:

a description of how to conform to this specification

normative references for the implementation of this specification

a description of the concept of operations for latent print interoperability

definitions of the transactions and Type-2 Logical Record Requirements

LITS addresses latent AFIS interoperability between and among the States, local law enforcement 

agencies, regional organizations, and Federal organizations, such as the Department of Defense or the 

Department of Homeland Security.

1.3 Constraints and Assumptions

This specification is designed to facilitate interoperability between LITS-conformant AFIS systems. New 

systems may have LITS conformance at the time they are released, whereas legacy systems will have to 

plan for upgrade or migration. 

LITS is specifically designed to be compatible with the FBI Integrated Automated Fingerprint 

Identification System (IAFIS) and NGI. By definition, a LITS-conformant system is compatible with FBI CJIS 

EBTS. With the exception of the Type-2 Logical Record Requirements (see section 6) and Casework 

Annotation and Exchange transaction (see appendix a), the fields and transactions in LITS are derived 

from the FBI CJIS EBTS.

Furthermore, it must be recognized that some interoperability may already exist and must be preserved 

when one of the exchanging parties adopts LITS.

LITS is predicated on the following:

LITS is an application profile specification, built upon ANSI/NIST-ITL (2011).

LITS is designed to be complementary to and compatible with the FBI CJIS EBTS.

Interoperability must also define policy and legal aspects, generally specified in negotiated 

Memoranda of Understanding (MOU), as well as specification of connectivity, messaging, search 

volumes, and technical aspects, generally specified in negotiated Interface Control Documents 

(ICDs) and/or additional Service Level Agreements (SLAs).

7

These negotiated MOUs/ICDs should specify certain options that are supported by LITS:

o whether palms, fingertips, or lower joints may be exchanged using LITS transactions

o which EFS Profiles are required

o whether optional LITS transactions, such as Unsolved Latent File Transactions, are 

permitted and whether an exchanging agency permits additions to its Unsolved Latent 

File

 

7

The content of MOUs, ICDs, and SLAs between exchanging agencies may vary and overlap.
4

o whether candidate lists will be anonymized, such as by disallowing names in the Search 

Results—Latent (SRL) transaction or if receiving software or systems will be configured 

to hide candidate names

LITS transactions are expected to be Law Enforcement Sensitive or contain Personally 

Identifiable Information and therefore must be secure in transmission. LITS assumes the 

negotiated ICD specifies security requirements and transport mechanisms.8

Requests for Proposals for latent AFIS acquisitions may cite conformance with the LITS as a 

requirement.

LITS assumes allocation of server-side computer resource time only and places no additional 

burden on server-side latent examiners’ resources or time.

LITS assumes the negotiated ICD may specify additional Type-2 fields to be exchanged, beyond 

those defined in LITS or FBI CJIS EBTS.

1.4 Name of Designated Repository Values

To conduct LITS transactions, AFIS owners must request a Name of Designated Repository (NDR) value

by contacting interop@noblis.org. Assigned values of NDR for State and local systems are posted at 

http://www.noblis.org/interop.

According to FBI CJIS EBTS appendix C, the values 200-399 are reserved for State and local systems. 

 

8

The FBI requires that security for all systems connecting to the NGI be implemented in accordance with CJIS 

Security Policy Version 5.0, CJISD-ITS-DOC-08140-5.0, February 9, 2011.
5

2 Conformance

The following terms are used in this specification to indicate mandatory requirements, recommended 

options, or permissible actions:

The terms “shall” and “shall not” indicate requirements strictly to be followed to conform to this 

specification and from which no deviation is permitted.

The terms “should” and “should not” indicate a recommended or particularly suitable choice 

when presented with several possibilities, without mentioning or excluding others, or when a 

certain course of action is preferred but not necessarily required, or when (in the negative form) 

a certain possibility or course of action is deprecated but not prohibited.

The terms “may” and “need not” indicate a course of action permissible within the limits of this 

specification.

Conformance to this specification falls into the following classes:

Basic AFIS Implementation

Optional AFIS Implementation

Casework Annotation and Exchange

To claim conformance to this specification, implementations shall provide the transactions for their 

conformance class, as defined below, in accordance with the transactions defined in Section 5—

Transactions; the requirements of Section 6–Type-2 Logical Record Requirements; and the requirements 

in Appendix A—Casework Annotation and Exchange.

A conformant AFIS shall accept Latent Friction Ridge Image Search (LFIS) and Latent Friction Ridge 

Features Search (LFFS) transactions as latent searches and Biometric Decision (BDEC) transactions as 

decision notifications. A conformant AFIS shall return Search Result—Latent (SRL) transactions as 

responses to LFFS or LFIS searches. All these transactions shall conform to the LITS, January 2013 (or 

later). LFIS transactions shall conform to EFS Profile 0: Image-Only Profile and LFFS transactions shall 

conform to, at a minimum, the EFS Profile 2: Quick Minutiae Search Profile as defined in EFS Profiles (or 

later); other profiles may be implemented optionally. These capabilities shall be demonstrated at 

delivery. These transactions shall be implemented for latent fingerprints; implementation for 

palmprints, extreme fingertips, or lower joints of the fingers is optional.

Conformant latent print workstation software shall be capable of the following:

importing LFFS transactions conformant with LITS without loss of defined features 

exporting LFFS transactions conformant with LITS without loss of defined features

Such import and export functions shall be incorporated into the software and not rely on use of the FBI’s 

Universal Latent Workstation software for translation. LITS is a peer of FBI CJIS EBTS, and therefore the 

exported LFFS transactions should be capable of being directly searched against the FBI’s NGI system.
6

2.1 Basic AFIS Implementation

A Basic AFIS Implementation shall provide the following transactions:

9

Latent Friction Ridge Image Search (LFIS)

o EFS Profile 0: Image-Only Profile

Latent Friction Ridge Features Search (LFFS)10

o EFS Profile 2: Quick Minutiae Search Profile 

Image Request (IRQ)

Biometric Decision (BDEC)

Search Results – Latent (SRL)

Latent Transaction Error (ERRL)

Image Request Response (IRR)

Image Error Response (ERRI)

2.2 Optional AFIS Implementation

An Optional AFIS Implementation may provide any or all of the following transactions in addition to the 

Basic AFIS Implementation:

Latent Friction Ridge Features Search (LFFS)10

o EFS Profile 1: Minimal Markup Profile

o EFS Profile 3: Detailed Markup Profile

o EFS Profile 10: Skeleton Profile

o EFS Profile 11: Minutiae Ridge Count Profile

o EFS Profile 20: Legacy IAFIS Latent Feature Search Profile

o EFS Profile 21: Quick Minutiae Search Profile without Image

o EFS Profile 30: Search Response Profile with All, and Corresponding, Minutiae

o EFS Profile 31: Search Response Profile without Corresponding Minutiae

o EFS Profile 90: Full Annotation Profile

Search Results – Latent (SRL)

o EFS Profile 30: Search Response Profile With All, and Corresponding, Minutiae

o EFS Profile 31: Search Response Profile Without Corresponding Minutiae

Image Summary Response (ISR)

Unsolved Latent Match (ULM) 

Unsolved Latent File Administrative Transactions

o Unsolicited Unsolved Latent Delete (UULD)

o Unsolved Latent Record Delete Request (ULD)

o Unsolved Latent Delete Response (ULDR)

 

9

EFS Profiles 1-3 include the friction ridge image with the features. Per ANSI/NIST-ITL 7.7.9.1 Use of compression 

algorithms for friction ridge images, “Latent images shall not be compressed with any lossy compression algorithm. 

It is required that images be stored uncompressed, or that PNG [Portable Network Graphics] or other totally 

lossless compression algorithm be used for latent images.”

10 See EFS Profile Specification for EFS Profiles for maximized accuracy and Special-purpose and legacy profiles.
7

2.3 Casework Annotation and Exchange Implementation

A Casework Annotation and Exchange Implementation may provide any or all of the following LITS

transactions:

Comparison (COMP)

Analysis (ASYS)

Casework Exchange (CWE)

These transactions are intended for exchange between human examiners or for archiving information 

associated with the Analysis, Comparison, Evaluation and Verification (ACE-V) process. These 

transactions are not intended for AFIS interaction.

The requirements for casework annotation and exchange are documented in appendix a.
8

3 Normative References

The following referenced documents are indispensable for the application of this specification. For 

dated references, only the edition cited applies. For undated references, the latest edition of the 

referenced document (including any amendments) applies. All standards are subject to revision, and 

parties using this specification are encouraged to investigate the possibility of applying the most recent 

versions of the standards and documents indicated below.

ANSI/NIST-ITL (American National Standards Institute/National Institute of Standards and 

Technology, Information Technology Laboratory). 2011. American National Standards 

Institute/National Institute of Standards and Technology, Information Technology Laboratory: 

Data Format for the Interchange of Fingerprint, Facial & Other Biometric Information, 1-2011, 

NIST Special Publication 500-290. http://biometrics.nist.gov/cs_links/standard/AN_ANSI_1-

2011_standard.pdf.

FBI CJIS (Federal Bureau of Investigation Criminal Justice Information Services Electronic). 2011. 

Electronic Biometric Transmission Specification, IAFIS-DOC-01078-9.3. 

https://www.fbibiospecs.org/docs/EBTS_v9_3_Final%2012_07_11_clean.pdf.

NIST-OLES (National Institute of Standards and Technology, Law Enforcement Standards Office). 

Forthcoming. Extended Feature Set Profile Specification. 

http://www.nist.gov/itl/iad/ig/ansi_standard.cfm. 

NIST-OLES (National Institute of Standards and Technology, Law Enforcement Standards Office). 

Forthcoming. Markup Instructions for Extended Friction Ridge Features. 

http://www.nist.gov/itl/iad/ig/ansi_standard.cfm.
9

4 Concept of Operations

LITS enables seamless, efficient hierarchical (local to State to regional to Federal) and peer to peer (local

to local, State to State, etc.) searches between a latent examiner’s own AFIS and any AFIS to which the 

latent examiner has access as permitted by an MOU. Currently, hierarchical searches are often based on 

nonstandard derivations of FBI CJIS EBTS, and the processes are often examiner-intensive and 

inefficient, especially for three-level hierarchies (AFIS systems at local, State, and IAFIS/NGI). Appendix B

documents specific scenarios and use cases.

Latent case processing would be as follows:

At the conclusion of normal latent print searches of the local/state AFIS, the examiner 

determines if the case is of sufficient importance to merit additional searches.

11 If so, the case 

would be sent for external search, with options as to which external AFIS to search, such as 

IAFIS/NGI, another city partnered through an MOU, or another State partnered through an 

MOU. 

With the image already acquired and the features marked for the search on the examiners’ own 

system, the features are exported and new features do not have to be marked (except to take 

advantage of optional EFS Profiles).

A candidate list is returned for each of the external AFIS systems searched, and the examiner

conducts comparisons with the candidates as usual. An image request may be conducted to 

obtain additional prints for specific subjects. If there is a match, the examiner notifies the 

requesting authorities who are handling the criminal case. The examiner would also remove the 

case from any Unsolved Latent File (ULF) on which it resides.

If no match is found, the examiner decides whether to enroll the case on the ULF of the other 

AFIS if permitted by MOU, save the case for a later periodic Latent Print to Tenprint (LT/TP)

search, remove the case entirely, etc.

4.1 Queries and Responses

4.1.1 Latent Friction Ridge Searches and Responses

Figure 1 depicts the transactions that provide interoperability between disparate, cross-jurisdictional 

AFIS systems. For the purposes of this workflow, Latent Friction Ridge Search is inclusive of both LFIS 

and LFFS. When latent examiners have exhausted all reasonable searches on their AFIS, they then have

the opportunity to send that same search without any additional encoding effort to an AFIS in another 

jurisdiction.

 

11 Policy may require serial searches or permit parallel searches.
10

Error response Normal response Latent Examiner Cross-jurisdictional AFIS Latent Friction Ridge Search Search Results – Latent Latent Transaction Error Biometric Decision Figure 1—Latent friction ridge search and response.

The Search Results—Latent (SRL) transaction returned by the target AFIS includes a candidate list 

composed of names and identification numbers of each candidate. In addition, if the MOU permits and 

the latent examiner requested the latent image to be stored in the target AFIS’s ULF, the SRL transaction 

shall return the identification number of the stored latent image.

The Latent Transaction Error (ERRL) transaction is returned by the target AFIS in response to a 

transaction that contained errors such as missing or inadequate quality fingerprints, missing mandatory 

information, or invalid contents. The ERRL transaction shall include additional information on the causes 

for the rejection. (See appendix c.)

The Biometric Decision (BDEC) transaction provides the examiner the ability to provide a definitive 

determination on the comparison between a latent print image and another image (i.e., identification, 

nonidentification, or inconclusive) to the target AFIS. The submission includes the identification number 

associated with the biometric for which the decision is made and the decision being made. If a positive 

decision by the owner of the fingerprint image is made against an image in the target AFIS’s ULF, that 

image is removed from the ULF.

4.1.2 Image Request and Response

Figure 2 depicts how a latent examiner may retrieve images from the target AFIS’s database(s) to assist 

in comparisons using the Image Request (IRQ) transaction. The latent examiner provides the 

identification number(s) of the subject(s) and indicators for which biometrics are being requested, such 

as fingerprints and palmprints.
11

Latent Examiner Cross-jurisdictional AFIS

Normal response Error response – request contained errors

Image Request Image Request Response Image Error Response Image Summary Response Error response – errors associated with individual identification numbers Figure 2—Image request and response.

Each identification number in the request and each set of biometrics being returned for the subject shall

be addressed in a separate Image Request Response (IRR) transaction. If the request contains any errors, 

an Image Error Response (ERRI) transaction shall be returned, including the reason for the return. Errors 

associated with individual identification numbers, such as an image set not being on file, shall be 

reported in the Image Summary Response (ISR) transaction. (See appendix c.) 

4.2 Unsolved Latent File Transactions

4.2.1 Unsolved Latent Match and Biometric Decision

The Unsolved Latent Match (ULM) transaction is an unsolicited message to the owner of the unsolved 

latent friction ridge image, not to the submitter of the newly submitted friction ridge search. The owner 

of the unsolved latent case is responsible for conducting the comparison. To the latent print examiner,

the process is identical to Tenprint to Unsolved Latent (TP/UL) search results on their AFIS system.
12

If a positive identification decision resulting from a Unsolved Latent Match (ULM) is made using a 

Biometric Decision (BDEC) transaction against a latent print in the target AFIS’s ULF, that print will be 

removed from the ULF.

(Note: This workflow is predicated on the assumption that the MOU permits cross-jurisdictional inserts 

into the target AFIS ULF.)

4.2.2 Unsolicited Unsolved Latent Delete

An Unsolicited Unsolved Latent Delete (UULD) transaction is sent by the AFIS when a record has been 

deleted from the target AFIS’s ULF. If a set of unsolved latent images was added from a multifinger 

latent search, the UULD transaction is used to indicate that that applies to the entire set of images 

added.

(Note: This workflow is predicated on the assumption that the MOU permits cross-jurisdictional inserts 

into the target AFIS ULF.)

4.2.3 Unsolved Latent File Maintenance Transactions

The Unsolved Latent Record Delete Request (ULD) transaction requests that records be removed from 

the target AFIS’s ULF. If a set of unsolved latent images was added from a multifinger latent search, the 

ULD transaction applies to the entire set of images added. The Unsolved Latent Delete Response (ULDR) 

transaction is used to indicate to the latent examiner that a record has been deleted from the target 

AFIS’s ULF in response to a ULD transaction.

(Note: This workflow is predicated on the assumption that the MOU permits cross-jurisdictional inserts 

into the target AFIS ULF.)
13

5 Transactions

Transactions are subdivided into the following categories:

Queries and Responses

Unsolved Latent File Transactions

5.1 Application Profile Specification

An LITS transaction shall include a set of subfields for APS 1.016–Application Profile Specification as 

follows:

Table 1—APS 1.016—Application Profile Specifications

Field Number Mnemonic Content Description Value

1.016 APO Application Profile Organization “NIST/OLES”

APN Application Profile Name “LITS”

APV Application Profile Version Number “1.0”

The Application Profile reference to LITS may be in addition to other Application Profile references, such 

as FBI CJIS EBTS. The resulting transaction shall be conformant with all listed Application Profile 

references.

5.2 Implementation Domain

When a transaction corresponds to more than one Application Profile, it is recommended that DOM 

1.013—Domain Name be set to the primary Application Profile’s domain name and version number. For 

example, a LITS transaction that also conforms to FBI CJIS EBTS should set field 1.013 as follows: 

Table 2—DOM 1.013—Domain Name

Field Number Mnemonic Content Description Value

1.013 DNM Domain Name “NORAM”

DVN Domain Version Number “9.3”

5.3 Identification Numbers

To accommodate the variety of identification number types associated with different AFIS systems, LITS

pairs UCN 2.2033A—FBI Number/UCN12 and NDR 2.098—Named Data Repository in the SRL transaction

to allow the latent examiner to determine the type of identification number. As examples of such 

variations, UCN 2.2033A—FBI Number/UCN is 100 alphanumeric characters13 and State identification 

numbers are 3-10 characters that may end with a hyphen for certain States. The format and content of 

local identification numbers has not yet been explored fully.

 

12 UCN = Universal Control Number.

13 Field length change proposed for FBI CJIS EBTS v9.4.
14

5.4 Queries

Latent AFIS search queries are predicated on the following:

Search types

o Latent Print to Tenprint (LT/TP)

o Latent Print to Latent Print (LT/LT)

o Latent Palm to Reference Palm Palmprint 

Search categories

o Latent Fingerprint

o Latent Palmprint

o Supplementals14

5.4.1 Record Set Requirements

Table 3 contains the record set requirements for queries.

Table 3—Record Set Requirements for Queries

TOT T1 T2 Latent Images

(T4, T7, T13)15

T9 T10 T14 T15 T17

LFIS16 1 1-2 1-10 - - - - -

LFFS17 1 1-2 1-10 1-10 - - - -

IRQ 1 1 - - - - - -

BDEC 1 1 - - - - - -

(Note: Only one latent image record type, i.e., Type-4, Type-7, or Type-13, is permitted in a Latent 

Friction Ridge Search, i.e., LFIS or LFFS.)

The Basic AFIS Implementation shall implement a single friction ridge image in a single Latent Friction 

Ridge Search (i.e., LFIS or LFFS). The Optional AFIS Implementation may implement multiple friction 

ridge images in a single Latent Friction Ridge Search (i.e., LFIS or LFFS).

If the MOU permits cross-jurisdictional inserts into the target AFIS ULF, two Type-2 records may be 

present in an LFFS or LFIS Type of Transaction (TOT) only in the case that the search is to be added to the 

unsolved latent file and that there are suppositional Type-2 fields used to reduce file penetration. The 

Type-2 record for insertion into the ULF includes only known data, whereas the other Type-2 record 

includes data specified solely to reduce the search space.

 

14 Supplemental fingerprints include extreme tips of fingers and full finger views that include the lower 

segments/joints of the fingers.

15 Use of Type-13 records is preferred; use of Type-4 or Type-7 records is acceptable.

16 EFS Profile 0: Image-Only Profile.

17 An image shall be included in an LFFS transaction except in the case of optional EFS Profiles 20-21.
15

5.4.2 Latent Friction Ridge Image Search (LFIS)

The Latent Friction Ridge Image Search (LFIS) transaction corresponds to EFS Profile 0: Image-Only 

Profile. No ANSI/NIST-ITL Type-9 record shall be included in the transaction associated with the friction 

ridge image in the Type-x record (where x = 4, 7, or 13).

(Note: The code for EFS Profile 0 is never entered in field 9.303 because there is no corresponding Type9 record.)

Image and region of interest size requirements shall conform to EFS Profiles, Section 3 Image/region of 

interest size requirements.

LFIS transactions are transmitted along with the search criteria by the latent examiner. The friction ridge 

features are extracted automatically from the images by the target AFIS with no human intervention. 

There is no manual editing of friction ridge characteristics. 

(Note: The search image is mandatory in this transaction.)

The NDR 2.098–Named Data Repository field shall be set to the value of the target AFIS. The target AFIS 

conducts a search and transmits the results to the latent examiner. If images are of insufficient quality 

for the target AFIS to extract features and perform a search, the target AFIS responds with an ERRL 

transaction.

This transaction may include an indication that the latent image should be stored in the target AFIS’s 

ULF if permitted by the MOU. This transaction may include an optional field to search a target AFISspecific database, such as ULF, sex offenders, or other actions as permitted by the MOU. This 

transaction may include an indication whether features and matched minutiae for each candidate print 

image shall be returned in the Search Results—Latent (SRL) transaction. 

5.4.3 Latent Friction Ridge Features Search (LFFS)

The Latent Friction Ridge Features Search (LFFS) transaction corresponds to the following:

EFS Profile 1: Minimal Markup Profile

EFS Profile 2: Quick Minutiae Search Profile 

EFS Profile 3: Detailed Markup Profile

FSP 9.303—EFS feature set profile, the optional numeric field used to indicate an EFS Profile, shall be set 

to the EFS Profile number (i.e., 1, 2, or 3) to indicate the specific set of EFS fields that are included in the 

Latent Friction Ridge Features Search transaction. If a Latent Friction Ridge Features Search transaction 

is conformant with two or more EFS Profiles, the code for each profile shall be entered in a separate 

subfield of field 9.303. Use of these profiles requires inclusion of the image in the transaction. LITSconformant systems shall implement EFS Profile 2: Quick Minutiae Search Profile and may additionally 

implement other EFS Profiles.

Image and region of interest size requirements shall conform to EFS Profiles, Section 3 Image/region of 

interest size requirements.
16

The latent friction ridge features are extracted by the latent examiner and transmitted along with the 

search criteria. 

(Note: The search image is mandatory in this transaction.)

The NDR 2.098–Named Data Repository field shall be set to the value of the target AFIS. The target AFIS

conducts a search and transmits the results to the latent examiner. If images are of insufficient quality 

for the target AFIS to extract features and perform a search, the target AFIS responds with a Latent 

Transaction Error (ERRL) message. (See appendix c.)

The Latent Friction Ridge Features Search (LFFS) transaction may include an indication that the latent 

image should be stored in the target AFIS’s ULF if permitted by the MOU. This transaction may include 

an optional field to search a target AFIS-specific database, such as ULF, sex offenders, or other actions as 

permitted by the MOU. This transaction may include an indication of whether features and matched 

minutiae for each candidate print image shall be returned in the Search Results—Latent (SRL)

transaction.

5.4.4 Image Request (IRQ)

The Image Request (IRQ) transaction enables latent examiners to retrieve images from the target AFIS’s 

database(s) so a comparison may be made by the latent examiner or to populate the latent examiner’s

database. The latent examiner provides the identification number(s) of the subject(s) and indicators for 

which biometrics are being requested, such as fingerprints, palmprints, and/or face images. 

An IRQ transaction shall contain a list of identification numbers, such as FBI 2.014—FBI number (UCN), 

SID 2.015—State Identification Number, or MNU 2.017—Miscellaneous Identification Number. The ICD 

with the target AFIS shall specify which identification numbers it will accept, for example, a State AFIS 

may accept only SID 2.015—State Identification Number. 

Each identification number in the request and each set of biometrics being returned for the subject shall 

be addressed in a separate Image Request Response (IRR) transaction. If the request contains any errors, 

an ERRI transaction will be returned, including the reason for the return. Errors associated with 

individual identification numbers, such as an image set not being on file, shall be reported in the Image 

Summary Response (ISR) transaction. (See appendix c.) The remaining valid subject identifier numbers 

shall result in individual ISR transactions. 

5.4.5 Biometric Decision (BDEC)

The Biometric Decision (BDEC) transaction provides the examiner the ability to provide a definitive 

determination on the comparison between a latent print image and another image, such as

identification, nonidentification, or inconclusive. The transaction shall include the identification number 

associated with the biometric for which the decision is made and the decision being made. If a positive 

decision by the owner of the fingerprint image is made against an image in the target AFIS’s ULF, that 

image is removed from the ULF.
17

5.5 Responses

5.5.1 Record Set Requirements

Table 4 contains the record set requirements for Responses.

Table 4—Record Set Requirements for Responses

TOT T1 T2 Fingerprint Exemplars

(T4, T14)

Latent Prints

(T7, T13)

T9 T10 Palmprint Exemplars

(T15)

T17

SRL 1 1 0-99 0-99 0-10918- 0-99 -

ERRL 1 1 - - - - - -

IRR 1 1 0-14 0-10 0-14 0-10 0-10 -

ERRI 1 1 - - - - - -

ISR 1 1 - - - - - -

(Note: A Search Results—Latent (SRL) transaction may contain different image record types.)

5.5.2 Search Results—Latent (SRL)

The Search Results—Latent (SRL) transaction is returned by the target AFIS in response to a latent 

friction ridge search request (LFFS or LFIS). It shall include a candidate list composed of names and 

identification numbers of each candidate (up to the Number of Candidates Returned (NCR) field value)

along with the corresponding friction ridge image(s) of the number of images specified in the NIR 

2.2010—Number of Images Requested field of the search message using the Type-4, 14, or 15 records. 

Up to 99 candidates, their match scores, and the finger/palm/supplemental positions of the images on 

file that matched may be included in the response. 

If the NIR 2.2010—Number of Images Requested is not specified, then the top 20 matching images shall 

be returned. If the NCR 2.079—Number of Candidates Returned is not specified, then the top 20 

candidates shall be included in the candidate list.

The latent examiner may optionally select in an LFIS or LFFS transaction whether features and matched 

minutiae for each candidate print image shall be returned in the SRL response. The features and 

matched minutiae shall reside in the EFS section of the Type-9 record for the candidate(s). When the 

RFR 2.095—Request Features Record field is set, the probe features shall be Information Designation 

Character (IDC) = 1, and the candidate list images/features shall be IDC = 2.

In addition, if the MOU permits and if the search included an indication that the latent image should be 

stored in the target AFIS’s ULF, the SRL shall return the identification number of the stored latent image.

The Search Results—Latent (SRL) transaction shall contain a candidate list of potential matches, CNL 

2.2033—Candidate Investigative List, from the target AFIS. The NDR 2.098—Named Data Repository 

field shall be set to the value of the target AFIS. The combination of UCN 2.2033A—FBI Number/UCN 

and NDR 2.098—Named Data Repository allows the latent examiner to determine the type of 

identification number returned in the SRL transaction.

 

18 The Search Results – Latent (SRL) transaction returns features if EFS Profiles 30 or 31 are implemented.
18

The legacy CAN 2.064—Candidate List is supported for backwards compatibility with older AFIS that are 

conformant to versions of FBI CJIS EBTS prior to v9.3.

5.5.3 Latent Transaction Error (ERRL)

The Latent Transaction Error (ERRL) transaction is returned by the target AFIS in response to an LFFS or 

LFIS transaction that contains errors, such as missing or inadequate quality fingerprints, missing 

mandatory information, or invalid contents. The ERRL transaction shall include additional information on 

the causes for the rejection. (See appendix c.)

5.5.4 Image Request Response (IRR)

The Image Request Response (IRR) transaction returns requested images on file with the target AFIS to 

the latent examiner. Each identification number in the request having images available triggers a 

separate response. The response shall include the identification number and the requested friction ridge 

images. If requested, the Type-9 records shall be included as well.

The Image Request Response (IRR) transaction shall contain the same identification number type as the 

Image Request (IRQ) that triggered it (for example, FBI 2.014—FBI number (UCN), SID 2.015—State 

Identification Number, or MNU 2.017—Miscellaneous Identification Number, which are mutually 

exclusive). The ICD with the target AFIS shall specify which identification numbers it will return, for 

example, a State AFIS may return only SID 2.015—State Identification Number. 

5.5.5 Image Error Response (ERRI)

The Image Error Response (ERRI) transaction is returned by the target AFIS to indicate a transaction 

error. It includes a message field indicating the type of error detected. (See appendix c.)

5.5.6 Image Summary Response (ISR)

The Image Summary Response (ISR) transaction is returned by the target AFIS to summarize the results 

of the image request processing. This transaction shall contain the listing of each identification number

returned. It is suggested that the submitting agency compare the original image request and this image 

summary response to determine which images were not returned because of invalid identification 

number or an image not being on file.

5.6 Unsolved Latent File Transactions

5.6.1 Record Set Requirements

Table 5 contains the record set requirements for Unsolved Latent File Transactions.

Table 5—Record Set Requirements for Unsolved Latent File Transactions

TOT T1 T2 T4 T7 T9 T10 T13 T14 T15 T17

ULM 1 1 1-14 0-10 0-1019- 0-10 0-14 -

20

-

UULD 1 1 - - - - - - - -

 

19 The Unsolved Latent Match (ULM) transaction returns features if EFS Profiles 30 or 31 are implemented.

20 From FBI CJIS EBTS, “Type-15 images apply for Palmprint Enrollment and Major Case Print Collections in 

conjunction with tenprint submissions.”
19

TOT T1 T2 T4 T7 T9 T10 T13 T14 T15 T17

ULD 1 1 - - - - - - - -

ULDR 1 1 - - - - - - - -

5.6.2 Unsolved Latent Match (ULM)

The Unsolved Latent Match (ULM) transaction is issued when a newly submitted friction ridge search in 

the target AFIS matches an unsolved latent case previously submitted by a latent examiner. This 

transaction is an unsolicited response to the “owner” of the unsolved latent friction ridge image, not to 

the submitter of the newly submitted friction ridge search. This transaction shall include the

identification number of the stored latent image and the images of the unsolved latent friction ridge. 

The Unsolved Latent Match (ULM) shall return the complete image set that was matched against the 

ULF. If the submission is not retained by the target AFIS, up to 14 images may be returned in this 

transaction when a tenprint record hits against multiple latents in the ULF. The “owner” of the unsolved 

latent case is responsible for conducting the comparison.

5.6.3 Unsolicited Unsolved Latent Delete (UULD)

The Unsolicited Unsolved Latent Delete (UULD) transaction is used to indicate that a record has been 

deleted from the target AFIS’s ULF. If a set of unsolved latent images were added from a multifinger 

latent search, the UULD transaction applies to the entire set of images added.

5.6.4 Unsolved Latent Record Delete Request (ULD)

The Unsolved Latent Record Delete Request (ULD) transaction requests that records be removed from 

the target AFIS’s ULF. If a set of unsolved latent images were added from a multifinger latent search, the 

ULD transaction applies to the entire set of images added.

5.6.5 Unsolved Latent Delete Response (ULDR)

The Unsolved Latent Delete Response (ULDR) transaction is used to indicate to the latent examiner that 

a record has been deleted from the target AFIS’s ULF in response to a ULDR transaction.
20

6 Type-2 Logical Record Requirements

6.1 Data Dictionary

Table 4 contains the descriptions and field specifications for the Type-2 record being included with a LITS

transaction.

6.1.1 CSD 2.1401—Case Description

The Case Description (CSD) field shall contain the free-text description of the case contained in the 

transaction, corresponding to CIN 2.010—Contributor Case Identifier Number.

6.1.2 CSN 2.1402—Case Name

The Case Name (CSN) field shall contain the free-text name of the case contained in the transaction, 

corresponding to CIN 2.010—Contributor Case Identifier Number.

6.1.3 IMN 2.1403—Image Number

The Image Number (IMN) field shall contain the image number within a case to differentiate between 

multiple latent impressions associated within a single case. This differs from CIX 2.011—Contributor 

Case Identifier Extension in that each search of an AFIS system requires a distinct CIX, even if multiple 

searches of a single latent print are conducted.

6.1.4 IML 2.1404—Impression Letter

The Impression Letter (IML) field shall contain the impression letter within an image to differentiate 

between multiple latent impressions within a single image. For example, if the image 5677 contains a 

simultaneous impression of four fingerprints, they would all share the same image number (e.g., IMN 

2.1403 = “5677”), and each fingerprint would have a distinct impression letter (e.g., IML 2.1404 = 

"A"<us>"B"<us>"C"<us>"D").

6.1.5 STR 2.1406—Source Transaction Reference

The Source Transaction Reference (STR) field is used in a Comparison (COMP), Analysis (ASYS), or 

Casework Exchange (CWE) transaction to identify the transaction(s) or file(s) that were the sources of 

images or features. STR 2.1406—Source Transaction Reference shall contain one occurrence for each 

image in the transaction and one occurrence for each Type-9 record that was imported from another 

ANSI/NIST-ITL transaction. 

(Note: STR 2.1406—Source Transaction Reference shall not have an occurrence for a Type-9 record 

created in the Comparison (COMP) transaction.)

For example, if a Comparison (COMP) transaction is created using a latent image and features from an 

LFFS transaction and one or more exemplar images and features from an SRL transaction, this field 

indicates the source of each image and feature record in the resulting Comparison (COMP) transaction. 

(Note: If for a given IDC, the image comes from one source and the feature set comes from another, 

there are two occurrences of STR, each of which points to a different source.)
21

Note that field STR 2.1406—Source Transaction Reference may be used with the source representation 

(Type-20), which may include a specific reference to the source file (EFR 20.994—External file 

reference), with a hash value (HAS 20.996—Hash).

Table 6—Field Edit Specifications for Type-2 Fields

Field Size Occurrence Count

Identifier Field 

Number

Field Name Condition Character Min Max Min Max

CSD 2.1401 Case Description ANS 1 300 0 1

CSN 2.1402 Case Name ANS 1 99 0 1

IMN 2.1403 Image Number N 1 99 0 99

IML 2.1404 Impression Letter A 1 1 0 99

2.1405 Reserved for 

future use21

STR 2.1406 Source 

Transaction 

Reference

1 # of image 

records

+ number of 

imported T9 

records

IDC 2.1406A Information 

Designation 

Character

M N 2 2 2 2

STT 2.1406B Source Type of 

Transaction

C

22 A 3 5 3 5

SID 2.1406C Source 

Information 

Designation 

Character

C

22 N 2 2 2 2

STN 2.1406D Source 

Transaction 

Control Number

C

22 ANS23 10 40 10 40

SFP 2.1406E Source 

Finger/Palm 

Position

C

22 N 2 2 2 2

RNU 2.1406F Source Record 

Number

C

22 NS23 1 1 1 5

SFN 2.1406G Source Filename M

24 ANS23 2 128

COM 2.1406H Comment M ANS23 2 200

 

21 NIST Law Enforcement Standards Office (OLES).

22 If the source is an ANSI/NIST-ITL transaction, then information items STT 2.1406B—Source Type of Transaction 

through RNU 2.1406F—Source Record Number, inclusive, are mandatory. If the source is not an ANSI/NIST-ITL

transaction (e.g., an image file), then information items STT 2.1406B—Source Type of Transaction through RNU 

2.1406F—Source Record Number, inclusive, are not used.

23 S = any printable 7-bit ASCII character.

24 SFN 2.1406G—Source Filename, COM 2.1406H—Comment, or both, are mandatory regardless of source.
22

Field Size Occurrence Count

Identifier Field 

Number

Field Name Condition Character Min Max Min Max

2.1407-

2.1499

Reserved for 

future use21

(Note: The combination of CIN 2.010—Contributor Case Identifier Number, 2.1404 IMN—Image 

number, and IML 2.1404—Impression Letter provides a means for an agency to unambiguously refer to 

any impression.

Table 7 provides detailed descriptions of the information items that comprise the STR 2.1406—Source 

Transaction Reference. 

Table 7—STR 2.1406—Source Transaction Reference Information Items

Information Item Description

Information Designation Character IDC of the image and/or feature record within the 

current transaction

Source Type of Transaction Type of transaction for the source of this record

Source Information Designation Character IDC of this image and/or feature record in the 

source transaction

Source Transaction Control Number Transaction Control Number of the source 

transaction

Source Finger/Palm Position Finger/palm position25 of this image and/or 

feature record in the source transaction; 

generally, the finger/palm position is same in 

source and current transaction, but current 

transaction may correct an error or an unspecified 

position in the source

Source Record Number The image record number (4,7,13,14,15,19,20,21) 

and/or the feature record number (9); if image and 

feature record from the same file, image and 

feature record numbers both included, commadelimited in numeric order (e.g., “4,9” or “9,13” or 

“9,14”); generally, record number not changed 

between source transaction and the current 

transaction, but permissible to be changed from 

legacy record format (e.g., from Type-4 to Type14) or to correct errors (e.g., if palm image was in 

a Type-14 record in the source transaction)

 

25 ANSI/NIST-ITL (2011), Table 8 Friction ridge position code and recommended image dimensions. 
23

Information Item Description

Source Filename Filename (without path) used as source; when 

transactions do not have distinct filenames (as for 

some AFIS responses or if image acquired from a 

scanner), Source Filename may be omitted

Comment Optional text description of source; if filename not 

specified, this field shall state the source (e.g,. 

“IAFIS transaction” or “Image directly acquired 

from scanner”)

Table 8 contains an example of a COMP transaction that is the result of combining an LFFS and its SRL, 

where the latent image (Type-13) comes from the LFFS, but the latent features (Type-9) and 

images/features for 20 exemplars come from the SRL. In this example, some exemplar images in the SRL 

were in Type-4 records, and some were in Type-14 records. 

Table 8—Example of COMP Transaction Based on ANSI/NIST-ITL Transactions.

Field 

Number

Identifier Latent

Image

Latent 

Features

Exemplar 1 Exemplar 2 . . . Exemplar 20

2.1406A IDC 1 1 2 3 21

2.1406B STT LFFS SRL SRL SRL SRL

2.1406C SID 1 21 1 2 20

2.1406D STN 1234567890 a987654321 a987654321 a987654321 a987654321

2.1406E SFP 0 0 2 3 3

2.1406F RNU 13 9 4,9 9,14 9,14

2.1406G SFN

2.1406H COM IAFIS 

transaction

IAFIS 

transaction

IAFIS 

transaction

IAFIS 

transaction

IAFIS 

transaction

Table 9 contains an example of a COMP transaction that is the result of combining one or more image 

files (rather than an ANSI/NIST-ITL transaction) with features contained in one or more files (e.g., NIST 

Special Database SD-27). In this case, the STT 2.1406B—Source Type of Transaction through RNU 

2.1406F—Source Record Number information items are left blank, and SFN 2.1406G—Source Filename 

is set to the filename (without path) so there is some means to track from where the image came. 

Table 9—Example of COMP Transaction Based on Image Files.

Field 

Number

Identifier Latent Image Latent 

Features

Exemplar Image Exemplar 

Features

2.1406A IDC 1 1 2 2

2.1406B STT LFFS LFFS

2.1406C SID 1 1

2.1406D STN TestA001GM TestA001mm

2.1406E SFP 0 2
24

Field 

Number

Identifier Latent Image Latent 

Features

Exemplar Image Exemplar 

Features

2.1406F RNU 9 9

2.1406G SFN A001G.BMP A001GM.LFF A001M_2.BMP A001MM.LFF

2.1406H COM NIST SD-27 NIST SD-27 NIST SD-27 NIST SD-27

6.2 Summary Field List

Table 10 and Table 11 contain column headers for each transaction and row headers that specify the tag 

number and ID for each field.

26 The cell at the intersection of any given row and column summarizes

information about the use of that field (row) in that transaction (column). If the cell is blank, the field is 

not defined for use in that record. Otherwise, the number in the cell gives the maximum number of 

occurrences of that field for that record. If the cell is shaded, then the field shall be optional for that 

transaction. If the cell is unshaded, then the field shall be mandatory for that transaction. In all cases, 

the minimum number of occurrences for a mandatory field shall be one. In all cases, the minimum 

number of occurrences for an optional field shall be zero. Type-2 fields not documented below (e.g., 

those specified in the negotiated ICD that are not in LITS or FBI CJIS EBTS) may be used as appropriate.

Table 10—Summary Field List for Basic AFIS Implementation

Type-2 Field LFIS LFFS IRQ BDEC SRL ERRL IRR ERRI

2.001 LEN 1 1 1 1 1 1 1 1

2.002 IDC 1 1 1 1 1 1 1 1

2.003 FFN 1

2.006 ATN 1 1 1 1 1 1 1 1

2.007 SCO 9 9 9 9 9 9 9

2.009 OCA

2.010 CIN 1 1 1 1 5

2.011 CIX 1 1 1 1 5

2.012 LCN 1

2.014 FBI 1,000 1 1

2.015 SID 1,000 1 1

2.016 SOC

2.017 MNU 1,000 4 1

2.018 NAM 1

2.020 POB 1 1

2.023 AGR 1 1

2.024 SEX 1 1

2.025 RAC 1 1

2.026 SMT 10 10

2.028 HTR 1 1

2.030 WTR 1 1

2.031 EYE 1 1

2.032 HAI 1 1

 

26 Deviations from FBI CJIS EBTS are indicated with an asterisk.
25

Type-2 Field LFIS LFFS IRQ BDEC SRL ERRL IRR ERRI

2.034 PAT 1 1

2.035 PPA 1

2.036 PHT 1

2.044 GEO 5 5

2.057 FNR 13

2.059 SRF 1

2.060 MSG 11 11

2.061 CST 1

2.062 IMT 1

2.064 CAN 99

2.067 IMA 1

2.073 CRI 3 3 3 3 3 3 3 3

2.074 FGP 10 10 99

2.076 PRI 1 1

2.079 NCR 1 1 1

2.083 ULF 1 1 1

2.084 AMP 13

2.086 SCNA 1

2.089 MSC 99

2.091 RCD1 1 1

2.092 RCD2 1 1

2.095 RFR 1 1 1

2.098 NDR* 10 10

2.1401 CSD 1 1 1

2.1402 CSN 1 1 1

2.1403 IMN 99 99 99

2.1404 IML 99 99 99

2.2010 NIR 1 1 1

2.2033 CNL 99

2.2034 ULR 1

Table 11—Summary Field List for Optional AFIS Implementation

Type-2 Field LFFS27 SRL28 ULM UULD ULD ULDR ISR

2.001 LEN 1 1 1 1 1 1 1

2.002 IDC 1 1 1 1 1 1 1

2.006 ATN 1 1 1 1 1 1 1

2.007 SCO 9 9 9 9

2.010 CIN 1 1 1 1 1 1

2.011 CIX 1 1 1 1 1 1

2.012 LCN 1

 

27 EFS Profile 3: Detailed Markup Profile.

28 EFS Profile 30: Search Response Profile with All, and Corresponding, Minutiae.
26

Type-2 Field LFFS27 SRL28 ULM UULD ULD ULDR ISR

2.014 FBI 1 1 1,000

2.015 SID 1,000

2.018 NAM 1

2.019 AKA 10

2.020 POB 1 1

2.021 CTZ 1

2.022 DOB 5

2.023 AGR 1

2.024 SEX 1 1

2.025 RAC 1 1

2.026 SMT 10 10

2.027 HGT 1

2.028 HTR 1

2.029 WGT 1

2.030 WTR 1

2.031 EYE 1 1

2.032 HAI 1 1

2.034 PAT 1

2.035 PPA 1

2.036 PHT 1

2.038 DPR 1

2.044 GEO 5

2.060 MSG 1 11

2.062 IMT 1 1,000

2.064 CAN 99

2.073 CRI 3 3 3 3 3 3 3

2.074 FGP 10 99 10

2.076 PRI 1

2.079 NCR 1 1

2.083 ULF 1 1

2.084 AMP

2.086 SCNA 1 1 1 1 1

2.089 MSC 99

2.091 RCD1 1

2.092 RCD2 1

2.095 RFR 1

2.098 NDR* 10

2.1401 CSD 1 1 1

2.1402 CSN 1 1 1

2.1403 IMN 99 99 99

2.1404 IML 99 99 99

2.2010 NIR 1 1

2.2033 CNL 99
27

7 Type-9 Logical Record Requirements

The Type-9 record of a LITS transaction shall be populated per the field requirements as defined in the 

EFS Profile for the EFS Profile(s) in the transaction. 
28

Appendix A Casework Annotation and Exchange

These transactions are intended for exchange between human examiners or for archiving information 

associated with the ACE-V process. These transactions are not intended for AFIS interaction.

A.1 Record Set Requirements

Table 12 contains the record set requirements for Casework Annotation and Exchange. The Comparison 

(COMP) and Analysis (ASYS) transactions contain records known or believed to have originated from a 

single piece of friction ridge skin. The Casework Exchange (CWE) transaction is a collection of images 

within a single case, which may or may not be from a single individual.

Table 12—Record Set Requirements for Casework Annotation and Exchange

TOT T1 T2 T9 T10 T13 T14 T15 T17 T18 T19 T20 T21

COMP 1 1 2- - * * * - - * - *

ASYS 1 1 1 - 1 - - - - - * *

CWE 1 1 * * * * * * * * * *

A.1.1 Comparison (COMP)

The Comparison (COMP) transaction provides for the transmission of at least two friction ridge images 

and the Type-9 records containing their associated markup. The prints may be latent or exemplar and

finger, palm, or plantar. This is not an arbitrary association; the friction ridge images were selected or 

screened by some process and declared candidates for comparison, for example, friction ridge images 

returned by an AFIS or suspects resulting from casework.

All of the prints in a COMP transaction purport to be from a single area of friction ridge skin (i.e., all 

prints are known, or are alleged, to be from a single finger of a subject, not from all of the fingers of a 

subject.) A COMP transaction is not solely for individualization determinations and may be used to 

document the rationale for an exclusion or inconclusive determination. A COMP transaction may also 

be used to annotate decisions comparing a print with AFIS search results, such as providing markup 

justification for comparison decisions made based on a latent search (e.g., LFFS) and response (e.g., SRL) 

transactions.

The COMP transaction defines the information content and determination of a comparison of multiple 

friction ridge impressions as discerned by a latent examiner during comparison and evaluation for 

archiving, for interchanges with other examiners, for validation and quality assurance processing, and 

for quantitative analysis.

Feature markup is not required for the COMP transaction, but if it is present, the appropriate EFS Profile 

shall be set.
29

Of particular interest in a COMP transaction are the corresponding features:

AOC 9.360—EFS area of correspondence

CPF 9.361—EFS corresponding points or features

ECD 9.362—EFS examiner comparison determination

These fields are used to define the areas or points that correspond or do not correspond between two 

or more of the images in the current transaction. When images are compared as candidates for 

individualization (potential mates), the corresponding areas and points may be retained in these fields; 

similarly, the reasons for complex exclusions may be indicated. Corresponding features may be marked 

using any type of feature and are explicitly not limited to minutiae.

Comparison features are especially appropriate in transactions in which one latent image is bundled 

with one or more candidate/potential match images to show which areas and points in the latent image 

correspond to areas and points in the candidate images. Such transactions may be useful for exchanges 

between examiners or for communicating results from AFIS searches.

A.1.2 Analysis (ASYS)

The Analysis (ASYS) transaction provides the latent examiner the means to define the information 

content of a single friction ridge impression as discerned during analysis for archiving, for interchanges 

with other examiners, for validation and quality assurance processing, and for quantitative analysis. An 

ASYS transaction provides a means to provide detailed markup and annotation for a single impression 

that is not associated with other prints. For example, it provides a means to include detailed annotation 

that may not be appropriate for inclusion in an LFFS transaction.

Feature markup is not required for the ASYS transaction, but if it is present, the appropriate EFS Profile 

shall be set.

A.1.3 Casework Exchange (CWE)

The Casework Exchange (CWE) transaction provides a format for latent examiners to collect all 

information related to a case within a single transaction. This transaction permits the storage and 

exchange of fingerprint; palmprint; plantar; facial/mugshot; scar, mark and tattoo; iris; deoxyribonucleic 

acid (DNA); and other biometric sample and forensic information that may be used in the identification 

or verification process of a subject.

This transaction may contain the source representation (Type-20) from which other biometric Record 

Types were derived; for example, a high-resolution color image in a Type-20 record and two latent 

fingerprint images are segmented, rescaled, and gray-scaled for storage in separate Type-13 records. 

This transaction may contain associated contextual information (Type-21), such as an image of the area 

where latent fingerprints were captured. Type-2 fields may be used as appropriate.
30

This information may be cached for use by the latent examiner at a later date or may be exchanged with 

another latent examiner as part of non-AFIS casework.

A.2 Summary Field List

Table 13 contains column headers that show each transaction and row headers that specify the tag 

number and ID for each field.

29 The cell at the intersection of any given row and column summarizes

information about the use of that field (row) in that transaction (column). If the cell is blank, the field is 

not defined for use in that record. Otherwise, the number in the cell gives the maximum number of 

occurrences of that field for that record. If the cell is shaded, then the field shall be optional for that 

transaction. If the cell is unshaded, then the field shall be mandatory for that transaction. In all cases, 

the minimum number of occurrences for a mandatory field shall be one. In all cases, the minimum 

number of occurrences for an optional field shall be zero. Type-2 fields not documented below, such as

those specified in the negotiated ICD that are not in LITS or FBI CJIS EBTS, may be used as appropriate.

Table 13—Summary Field List for Casework Annotation and Exchange

Type-2 Field COMP ASYS

2.001 LEN 1 1

2.002 IDC 1 1

2.006 ATN 1 1

2.007 SCO 9 9

2.009 OCA

2.010 CIN 1 1

2.011 CIX 1 1

2.012 LCN 1

2.020 POB 1 1

2.023 AGR 1 1

2.024 SEX 1 1

2.025 RAC 1 1

2.026 SMT 10 10

2.028 HTR 1 1

2.030 WTR 1 1

2.031 EYE 1 1

2.032 HAI 1 1

2.034 PAT 1 1

2.044 GEO 5 5

2.064 CAN 99

2.067 IMA 1 1

2.073 CRI 3 3

2.074 FGP 10 10

2.076 PRI 1 1

2.079 NCR 1 1

2.083 ULF 1 1

 

29 Deviations from FBI CJIS EBTS are indicated with an asterisk.
31

Type-2 Field COMP ASYS

2.089 MSC 99

2.091 RCD1 1 1

2.092 RCD2 1 1

2.095 RFR 1 1

2.098 NDR 10 10

2.1401 CSD 1 1

2.1402 CSN 1 1

2.1403 IMN 99 99

2.1404 IML 99 99

2.1406 STR 99

2.2010 NIR 1 1

2.2030 PPD 10

2.2033 CNL 99
32

Appendix B Latent Case Processing Scenarios

B.1 Neighboring City

A latent print examiner of a large city near the state border has a print from a homicide that has been 

searched on the local and State AFIS systems as well as IAFIS/NGI with no match. Given the proximity of 

a large city in the adjacent state, the examiner believes a search of the neighboring city is warranted. 

The search produces a match of an individual whose prints were legal for the neighboring city to 

maintain, but not to forward to the FBI CJIS. A warrant is executed.

B.2 Better Impression

A series of shootings has occurred along the interstate. Ridge impressions were found on both shell 

casings and cigarette packages discovered at the site of the shootings. Although the shootings occurred 

within the same state, they occurred in different political boundaries. The investigation is handled by 

the Sheriff’s Department, which would like to search the AFIS databases of the two large cities located 

within the county since a search of the State and CJIS databases have produced no results. A search of 

the city AFIS produces a match. Upon closer inspection, an examiner determines that the city had an 

older, but more complete, friction ridge impression than the state or CJIS.

B.3 International

A city on an international border has an informal agreement with a non-U.S. city to search highly 

publicized latent print cases on each other’s AFIS. Each agency agrees that this is a valuable tool and 

would be willing to elevate the process with a formal MOU, but the technical issues of crossjurisdictional searching make this impossible on a regular basis. The uniform method of searching each 

other’s databases presented in LITS and Markup now allows those cross searches to become routine.

B.4 Newer AFIS

All cities and counties within a State share the same database through a statewide AFIS, which had its 

last update four years ago. Several large cities and counties maintain their own AFIS and latent print 

services. The latent print examiner in a large city has searched both the State database and IAFIS/NGI 

with no identification. The examiner searches the adjacent county and makes an identification. A later 

examination reveals that the individual has a record on both the State and IAFIS/NGI databases, but the 

newer coder and matchers on the adjacent system resulted in the identification.

B.5 Military

Authorities at a military installation have had several burglaries related to weapons. The latent prints 

have been searched against the Department of Defense (DoD) Automated Biometric Identification 

System (ABIS) and the CJIS IAFIS/NGI with no result. Given the proximity to a large city, the military 

latent print examiners search the city AFIS. The identification of several individuals is made based on 

their misdemeanor records at the city, which were not forwarded to DoD ABIS or CJIS IAFIS/NGI.

Warrants are issued.
33

B.6 Highly Publicized

Several carjackings within a few weeks have terrorized the city. Six latent fingerprints have been 

recovered from the abandoned vehicles. The latent print staff is overwhelmed and requests assistance 

from neighboring agencies. The latent print examiners at the neighboring agencies search several AFIS 

systems using Markup. An identification is made, and a warrant is executed.

B.7 Natural Disaster

A tidal surge has left many unidentified victims. Ridge impressions have been taken from the victims and 

delivered to the latent print examiners at several agencies. These agencies have different AFIS systems 

and varying database size. Collectively, the examiners are able to use this network of systems to make 

identifications not possible on each individual system. 
34

Appendix C Transaction Error Messages

Code Error Condition MDD Error 

Description

Count Insert #1 Insert #2 Insert 

#3

A0001 Unauthorized 

ULF delete

Requested deletion 

from ULF is not 

authorized.

0

A0004 Unauthorized 

LITS Transaction

Requestor is not 

authorized for 

transaction type %1.

1 TOT of 

incoming 

message

E0001 Required 

element missing

Mandatory element 

%1 was not supplied 

in message.

1 Element 

name

E0002 Element failed 

validation

Element %1, with 

value of [%2] contains 

invalid data.

2 Element 

name

Element value

E0003 Element failed 

validation

Element %1, with 

value of [%2] contains

invalid data. The data 

may not comply with 

the acceptable range 

of values.

2 Element 

name

Element value

E0004 LITS record 

parse error

LITS logical record 

type %1 containing 

IDC of [%2] in 

message does not 

comply with message.

Contents or Length 

field values or the 

record is not parsable.

2 Logical record 

type

IDC value or the 

value -1 if the 

named logical 

record is missing 

or is a Type-1 

record.

E0005 LITS field parse 

error

LITS field %1 could not 

be parsed. Check use 

of separator 

characters and 

presence of all 

required subfields.

1 Field tag

E0006 Field 

relationship 

error

The value of element 

%1 is inconsistent 

with the value of 

element %2.

2 Element 

name

Element name

E0012 Message Length 

Inconsistent

The length of the CJIS 

WAN message is 

inconsistent with the 

sum of the lengths of 

the logical records 

contained within it.

0
35

Code Error Condition MDD Error 

Description

Count Insert #1 Insert #2 Insert 

#3

L0002 Subject does 

not exist in 

Criminal or Civil 

File

Subject with identifier 

%1 does not exist in 

repository.

1 UCN

L0004 File image not 

available

The images for subject 

identifier %1 are not 

available from 

repository %2.

2 UCN NDR

L0005 High 

Penetration 

Search Rejected

Latent search 

penetration estimate 

of %1 percent exceeds 

the allowable limit of 

%2 percent.

2 Request 

percent

Authorization 

cap

L0006 Invalid image 

type

The supplied image(s) 

could not be used for 

characterization of 

subject.

0

L0007 Features not 

usable

The supplied features 

could not be used for 

requested search.

0

L000830 Characteristics 

quality low

The quality of the 

characteristics is too 

low to be used.

0

L0009 Image 

decompression 

error

An error occurred 

during decompression 

of the fingerprint 

images.

0

L0012 ULF Delete Error An error was 

encountered in 

processing the 

requested deletion 

from the Unsolved 

Latent File.

0

L0013 General Logic 

Error

A general logic error 

was detected that is 

not currently defined. 

Optional error 

message: %1 %2 %3.

0-3 Free text Free text Free 

Text

L0014 ULF Delete 

Subject Missing

Cannot perform the 

ULF delete request for 

%1 because the 

subject is not present 

1 SCNA

 

30 When a candidate was associated with the submission, this error message includes a formatted response 

reflecting “Candidate(s) were found. Please resubmit a new set of fingerprints for comparison to the candidate(s).” 
36

Code Error Condition MDD Error 

Description

Count Insert #1 Insert #2 Insert 

#3

in the ULF.

L0018 Latent search 

queue full

The requested search 

exceeds the allocation 

for the organization or 

State.

0

L0033 Element Entry 

Limit Exceeded

The requested update 

of this record would 

cause the maximum 

number of entries of 

the %1 field to be 

exceeded.

1 Field name

L0057 Improper Finger 

Specified

Latent searches 

cannot process %1 

possible finger 

positions for %2 

supplied search 

fingers.

2 FGN_CNT AFV_CNT

L0058 UCN and NDR 

format 

incompatible

The designated 

repository [%1] does 

not correlate to the 

provided record 

format number (%2).

2 NDR UCN

L0109 Poor Image 

Quality

The quality of the 

fingerprint images is 

too poor to permit 

processing.

0

L0115 Other QC Error A Quality Check error 

has occurred.

0

L011631 Fingerprint 

Pattern Quality 

Error

Fingerprint pattern(s) 

not discernible

0

L011731 Fingerprint 

Pattern Area 

Error

Insufficient pattern 

area(s) recorded for 

identification 

purposes

0

L0124 Unacceptable 

Criteria

The submission does 

not meet latent 

acceptance criteria.

L0125 Invalid ORI32 This ORI, %1, is not 

present in the CCA 

file.

1 ORI value 

from 

maintenance 

 

31 When a candidate was associated with the submission, this error message includes a formatted response 

reflecting “Candidate(s) were found. Please resubmit a new set of fingerprints for comparison to the candidate(s).” 

32 ORI = Originating Agency ID
37

Code Error Condition MDD Error 

Description

Count Insert #1 Insert #2 Insert 

#3

request

L0126 Invalid CRI33 This CRI, %1, is not 

present in the CCA 

file.

1 CRI value 

from 

maintenance 

request

L0131 Required 

element missing

Mandatory element 

%1 was omitted from 

message.

1 Element 

name

L0144 Field 

Relationship 

Error

The value of element 

%1 is inconsistent 

with the value of 

element %2.

2 Element 

name

Element name

L0147 Contributor has 

remote 

capability

The contributing state 

has remote capability.

0

L0148 Poor Latent 

Image Quality

The image quality is 

not adequate for 

conducting an AFIS 

search.

0

L0149 Bad Search 

Criteria

The descriptive search 

criteria are not 

adequate or are

incomplete.

0

L0151 Photo Not 

Available

Photo not available. 0

 

33 CRI = Controlling Agency ID
38

Appendix D Abbreviations

ABIS—Automated Biometric Identification System

AFIS—Automated Fingerprint Identification System

ANSI—American National Standards Institute

ASYS—Analysis Transaction

ACE-V—Analysis, Comparison, Evaluation and Verification

BDEC—Biometric Decision

CAN—Candidate List

CIN —Contributor Case Identifier Number

CIX—Contributor Case Identifier Extension

CJIS—Criminal Justice Information Services

COMP—Comparison Transaction

CNL—Candidate Investigative List 

CSD— Case Description

CSN—Case Name 

CWE—Casework Exchange Transaction

EBTS—Electronic Biometric Transmission Specification

EFS—Extended Friction Ridge Feature Set

ERRI—Image Error Response

ERRL—Latent Transaction Error

FBI—Federal Bureau of Investigation

IAFIS—Integrated Automated Fingerprint Identification System

ICD—Interface Control Document

IDC—Information Designation Character

IML—Impression Letter

IMN —Image Number

IRQ—Image Request

IRR—Image Request Response

ISR—Image Summary Response

LFIS—Latent Friction Ridge Image(s) Search

LFFS—Latent Friction Ridge Features Search

LITS—Latent Interoperability Transmission Specification

LT/TP —Latent Print to Tenprint 

MNU —Miscellaneous Identification Number

MOU—Memorandum of Understanding

NCR—Number of Candidates Returned 

NDR—Name of Designated Repository

NGI—Next Generation Identification

NIR—Number of Images Requested

NIST—National Institute of Standards and Technology

SID—State Identification Number 
39

SLA—Service Level Agreement

SRL—Search Results—Latent

STR —Source Transaction Reference

TOT—Type of Transaction

UCN—Universal Control Number

ULD—Unsolved Latent Record Delete Request

ULDR—Unsolved Latent Delete Response

ULF—Unsolved Latent File

ULM—Unsolved Latent Match

UULD—Unsolicited Unsolved Latent Delete