ANSI/NIST-ITL 1-2011 Requirements 

and Conformance Test Assertions

Christofer J. McGinnis

Dylan Yaga

Fernando L. Podio

NISTIR 7806
NISTIR 7806

ANSI/NIST-ITL 1-2011 Requirements 

and Conformance Test Assertions

Christofer J. McGinnis

Dylan Yaga

Fernando L. Podio

September 2011

.

Developed by NIST/ITL Computer Security Division.

This work is funded, in part by the Department of Homeland Security/US-VISIT

U.S. Department of Commerce

Rebecca M. Blank, Acting Secretary

National Institute of Standards and Technology

Patrick D. Gallagher, Under Secretary for Standards and Technology and Director
iii

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology 

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the 

Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, 

proof of concept implementations, and technical analysis to advance the development and productive 

use of information technology. ITL’s responsibilities include the development of technical, physical, 

administrative, and management standards and guidelines for the cost-effective security and privacy 

of sensitive unclassified information in Federal computer systems. This Interagency Report 

discusses ITL’s research, guidance, and outreach efforts in computer security, and its collaborative 

activities with industry, government, and academic organizations.

National Institute of Standards and Technology Interagency Report

175 pages (2011)

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.
iv

Sponsor

The work described in this document was sponsored, in part, by The Department of Homeland 

Security/US-VISIT Program.

Abstract

The current version of the ANSI/NIST-ITL standard "Data Format for the Interchange of Fingerprint, 

Facial & Other Biometric Information" is specified in two parts. Part 1, ANSI/NIST-ITL 1-2007, 

specifies the traditional format, and Part 2, ANSI/NIST-ITL 2-2008, specifies a NIEM-conformant 

XML format. Both parts have been combined into one document, which is being revised and 

augmented. The Computer Security Division (CSD) of NIST/ITL has developed a set of test 

assertions based on the requirements specified in the 4th draft of the new ANSI/NIST-ITL standard. 

Over twelve hundred test assertions have been identified and organized into a set of tables to assist in 

the development of a conformance test tool designed to test implementations of the new version of the 

ANSI/NIST-ITL standard for selected record types. These tables were contributed to the 

Conformance Testing Methodology (CTM) Working Group which was recently established by 

NIST/ITL to develop a CTM for the new version of the ANSI/NIST-ITL (AN-2011) standard. A 

ballot was conducted on a revised draft (5th draft) of the AN-2011 standard. A new draft will be 

developed based on the comments received as a result of this ballot. As the technical content of the 

AN-2011 draft standard evolves towards approval and publication, and comments on the assertion 

tables in this document are received, revised versions of these tables will be developed until they fully 

address the requirements of the approved AN-2011 standard. This publication documents the 

assertions developed and the terms, operands, and operators used in defining these assertions. Brief 

information on previous and ongoing conformance test tools development within NIST/ITL CSD is 

included. 

Disclaimer

Statements made in this paper should not be interpreted as standards, guidelines, best practices, or 

recommendations for specific changes to any other NIST publications.
v

Table of Contents

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

1.1 Background............................................................................................................... 1

1.2 Need for Conformance Testing to Biometric Standards ........................................... 1

1.3 NIST/ITL CSD Conformance Test Tools Developments .......................................... 1

1.4 BioAPI Conformance Test Suite (CTS) .................................................................... 1

1.5 Conformance Test Architecture for Biometric Information Records – Beta 1.1........ 2

1.6 Advanced Conformance Test Architecture (CTA) Beta 2.0...................................... 2

1.7 Support for the ANSI/NIST- ITL 1-2007 Standard .................................................... 2

1.8 Support for the ANSI/NIST-ITL 1-2011 (AN-2011) Standard ................................... 3

Annex A - References .......................................................................................................... 5

Annex B – Test Assertion Syntax and Testing Levels...................................................... 6

B.1 Operators...................................................................................................................... 6

B.2 Terms............................................................................................................................ 7

B.3 Operands ...................................................................................................................... 7

B.4 Hierarchy of Conformance Tests.................................................................................. 9

Annex C – Tables of Requirements and Assertions for AN-2011 4th Draft................... 10

C.1 Changes in the tables from the respective AN-2007 table......................................... 10

C.2 Table Headers ............................................................................................................ 10

C.3 Assertion Tables for AN-2011 4th Draft....................................................................... 13

C.4 Test Notes ................................................................................................................ 173

Annex D: Exceptions Table ............................................................................................. 178

List of Tables

Table B.1 - Operator Definitions.......................................................................................... 6

Table B.2 - Terms Used Throughout the Requirements and Assertion Tables ............. 7

Table B.3 - Operands Used Throughout the Requirements and Assertion Tables ....... 7

Table C.1 - Assertions for Data Conventions .................................................................. 13

Table C.2 - Assertions for Implementation Domain & Application Profiles ................. 20

Table C.3 - Assertions for Information Associated with Several Records ................... 21

Table C.4 - Assertions for Record Type 1- Transaction Information Record ............... 56
vi

Table C.5 - Assertions for Record Type 3 - Deprecated ................................................. 65

Table C.6 - Assertions for Record Type 4 - Grayscale Fingerprint Image .................... 66

Table C.7 - Assertions for Record Type 5 - Deprecated ................................................. 71

Table C.8 - Assertions for Record Type 6 - Deprecated ................................................. 71

Table C.9 - Assertions for Record Type 10 - Facial, Other Body Parts & SMT Image 

Record.......................................................................................................................... 72

Table C.10 - Assertions for Record Type 11 - Reserved for Voice ................................ 99

Table C.11 - Assertions for Record Type 12 - Reserved for Dental Records ............... 99

Table C.12 - Assertions for Record Type 13 - Friction-Ridge Latent Image Record.. 100

Table C.13 - Assertions for Record Type 14 - Fingerprint Image Record................... 114

Table C.14 - Assertions for Record Type 15 - Palm Print Image Record .................... 133

Table C.15 - Assertions for Record Type 17 - Iris Image Record................................. 147

Table C.16 - Assertions for Annex B - Traditional Encoding ....................................... 165

Table C-16 - IDC ID Location Comparison ..................................................................... 173

Table C-17 - IDC Comparison Results............................................................................ 173

Table C-18 - Image Metadata ........................................................................................... 175

Table D.1 - Exceptions Table........................................................................................... 178
1

1 Introduction

1.1 Background

The ANSI/NIST-ITL standard "Data Format for the Interchange of Fingerprint, Facial & Other 

Biometric Information" is used by law enforcement, intelligence, military, and homeland security 

organizations throughout the world. The current version of the ANSI/NIST-ITL standard is specified 

in two parts:

Part 1 – (ANSI/NIST-ITL 1-2007) in Traditional Format [1]

Part 2 – (ANSI/NIST-ITL 2-2008) in NIEM-conformant XML format [2]

In addition, an extension to the table of finger position codes in both parts of the standard to handle 

multiple-finger captures was published: ANSI/NIST-ITL 1a-2009 [3].

The standard is now in the process of being revised. Four drafts were developed as a result of two 

workshops that were held at NIST and comments received from subsequent drafts. A 

final voting version (5th draft) was developed [4]. A forty-five day ballot on the 5th draft closed 

August 31. A revised draft will be developed as a result of the ballot. Additional information on the 

standard and related activities can be found at the ANSI/NIST-ITL standard homepage [5].

1.2 Need for Conformance Testing to Biometric Standards

The existence of biometric standards alone is not enough to demonstrate that products meet the 

technical requirements specified in the standards. Conformance testing captures the technical 

description of a specification and measures whether an implementation faithfully implements the 

specification. Conformance testing provides developers, users, and purchasers with increased levels 

of confidence in product quality and increases the probability of successful interoperability.

The Computer Security Division (CSD) of NIST/ITL supports the development of biometric 

conformance testing methodology standards and other conformity assessment efforts through active 

technical participation in the development of biometric standards and the development of associated 

conformance test architectures and test suites. 

1.3 NIST/ITL CSD Conformance Test Tools Developments

NIST/ITL CSD develops these conformance test tools to support users that require conformance to 

selected biometric standards and product developers interested in conforming to biometric standards 

by using the same testing tools available to users. These efforts support the possible establishment of 

conformity assessment programs to validate conformance to biometric standards. The following 

sections briefly describe previous, recent, and ongoing conformance test tool developments in 

support of biometric standards.

1.4 BioAPI Conformance Test Suite (CTS)

In February 2006, NIST/ITL CSD released a BioAPI Conformance Test Suite (CTS) developed to 

test implementations of ANSI INCITS 358-2002, the BioAPI specification. This software tool was 

developed to help users verify the conformance of Biometric Service Providers to the BioAPI 

Specification 1.1. This tool can be downloaded from the BioAPI Conformance Test Suite web page 

[6]. The InterNational Committee for Information Technology Standards (INCITS) Technical 

Committee M1- Biometrics developed a conformance testing methodology standard for this BioAPI
2

specification. The standard was published in 2008 as ANSI INCITS 429-2008 [7]. NIST/ITL CSD 

co-sponsored the development of this standard. 

1.5 Conformance Test Architecture for Biometric Information Records – Beta 1.1

In August 2008, NIST/ITL CSD released a Conformance Test Architecture (CTA) for Biometric

Information Records and a Conformance Test Suite (CTS) for Patron Format A data structures 

specified in ANSI INCITS 398-2008, “Common Biometric Exchange Formats Framework” that runs 

under this CTA. The CTS for Patron Format A supported by this conformance testing architecture 

was developed to help users determine whether binary file implementations of Biometric Information 

Records (BIRs) based on this Patron Format conform to the standard. NIST/ITL CSD sponsored (in 

INCITS M1) development of a conformance testing methodology standard for CBEFF (Common 

Biometric Exchange Format Framework) data structures specified in ANSI INCITS 398-2008 and 

submitted to INCITS M1 the test assertions and related test cases developed for the Patron Format A

CTS as well as test assertions and test cases for other Patron Formats specified in the ANSI INCITS 

398-2008 standard. This standard was published as ANSI INCITS 473 in 2011 [8].

1.6 Advanced Conformance Test Architecture (CTA) Beta 2.0

In August 2010, NIST/ITL CSD released an advanced Conformance Test Architecture (CTA) Beta 

2.0 designed to test implementations of selected national and international biometric data interchange

standards. The CTA released was accompanied by the release of four Conformance Test Suites 

designed to test implementations of finger minutiae and finger image data formats conforming to 

American National Standards developed by Technical Committee M1- Biometrics [9]. These test 

tools, designed to test implementations of ANSI INCITS 378, “Finger Minutiae Format for Data 

Interchange” and ANSI INCITS 381, “Finger Image-Based Data Interchange Format” (both for the 

2004 and 2009 versions), are available from the NIST/ITL CSD conformance test tools download 

web page [10]. 

A subsequent release of a Conformance Test Suite in 2011 is a tool designed to test implementations 

of the second generation of the iris image data interchange format developed by Joint Technical 

Committee 1 of ISO and IEC Subcommittee 37 (JTC 1/SC 37) – Biometrics [11]. Two versions of 

this test tool are available at the NIST/ITL CSD conformance test tools download web page [10]; 

they are an Installer version that runs under NIST/ITL CSD CTA Beta 2.0 and the source code 

version. These tools were released as soon as the final draft of this international standard became 

technically stable. At the time of this writing the Final Draft International Standard (FDIS) ballot 

closed on July 27, 2011 and the FDIS was approved. The standard is not yet published.

CTSs designed to test implementations of other international data formats developed in JTC 1/SC 37 

are being tested before their release and others are under development. In addition, as addressed in 

the following sections, NIST/ITL CSD is also supporting the ANSI/NIST ITL standards by 

developing conformance test tools to test implementations of both the current version (2007) and the 

new version under development. 

1.7 Support for the ANSI/NIST- ITL 1-2007 Standard

Although a revised and augmented version of the standard is under development, the 2007 version is 

still widely used. NIST/ITL CSD developed a CTA/CTS (Beta version 0.4) designed to test 

implementations of selected Record Types of ANSI/NIST-ITL 1-2007, “Data Format for the 
3

Interchange of Fingerprint, Facial, & Other Biometric Information – Part 1”. These Record Types 

were considered the first-priority tier and are supported:

Record Type 1, Transaction Information Record

Record Type 4, High-resolution grayscale fingerprint image

Record Type 10, Facial and SMT image

Record Type 13, Variable-resolution latent image

Record Type 14, Variable-resolution fingerprint image

Record Type 17, Iris image.

Over five-hundred and thirty test assertions were implemented. The software code can be extended 

to support other record types as required. The conformance test tool developed to support this 

standard is designed to detail a transaction’s level of conformance to the standard. The CTA/CTS 

can also be used as an analysis tool for determining which parts of the transaction (e.g., nonconformant fields, records) do not conform to the standard and to analyze the reason for their 

nonconformance. For unsupported Record Types only the length of the record is reported during 

testing, and no determination of conformance is made for these records. In addition to stating 

whether a file passes or fails, the messages provided include warnings and notes. The code was

developed in C# under the Microsoft® .NET 4.0 Framework. Two versions of the tools are available 

to the public: (a) an Installer version (Beta 0.4) and (b) the source code. Both versions were released 

in May 2011 and are available at the same NIST/ITL CSD conformance test tools download web 

page [10]. NISTIR 7791, “Conformance Test Architecture and Test Suite for ANSI/NIST-ITL 1-

2007” [12], includes a high-level overview of the architecture and test suite as well as software 

details. The code structure description is provided. A quick start user guide and a comprehensive 

table of the standard’s requirements and the associated implemented conformance test assertions are 

included.

1.8 Support for the ANSI/NIST-ITL 1-2011 (AN-2011) Standard

Part of the process associated with the development of a CTA/CTS designed to test implementations 

of AN-2011 would include similar and extended capabilities as the test tool described in the previous 

section. NIST/ITL CSD revised and extended the tables of operands and operators developed for the 

AN-2007 CTA/CTS assertions to express the assertions derived from the requirements in the AN2011 standard and developed requirements and assertion tables for the AN-2011 standard. These 

tables include, at the present time, over twelve-hundred assertions. This initial set of tables was

developed based on the AN-2011 4th draft. NIST/ITL CSD contributed the requirements and 

assertions tables as well as the tables of terms, operands, and operators mentioned above to the

Conformance Testing Methodology (CTM) Working Group which was recently established by 

NIST/ITL to develop a CTM for selected records types of AN-2011. 

The CTM Working Group is led by NIST/ITL staff and has participation from NIST/ITL experts in 

conformance testing as well as experts from other US Government agencies and the private industry. 

The tables contained in the annexes include the terms, operands, and operators mentioned above, as 

well as the tables of requirements and assertions for the following sections and Record Types of the 

AN-2011 standard (4th draft):

Section 5: Data Conventions

Section 7: Information Associated with Several Record Types
4

Section 8.1 Record Type-1: Transaction information record

Section 8.4 Record Type-4: Grayscale fingerprint image

Section 8.10Record Type-10: Facial, other body part and SMT image record

Section 8.13 Record Type-13: Friction-ridge latent image record

Section 8.14 Record Type-14: Fingerprint image record

Section 8.15 Record Type-15: Palm print image record

Section 8.17 Record Type-17: Iris image record

Annex B: Traditional Encoding

Additionally, tables for the deprecated Record Types 3, 5, and 6 and reserved Record Types 11 and 

12 are included. Implementation exceptions are identified in Annex D. The headers of the tables of 

requirements and assertions are based on those specified in the draft Conformance testing 

methodology for AN-2011 presented at the second AN-2011 Workshop, with minor changes listed 

below. These changes have been made to accommodate requirements and assertions from the AN2011 standard.

As the technical content of the AN-2011 draft standard evolves towards approval and publication and 

comments on the assertion tables included in Annex C are received, NIST/ITL CSD staff involved in 

the development of the AN-2011 CTM standard plans to revise the assertion tables until they fully 

address the requirements in the approved and published AN-2011 standard. 
5

Annex A - References

[1] NIST Special Publication 500-271, ANSI/NIST-ITL 1-2007 (Revision of ANSI/NIST-ITL 1-

2000), American National Standard for Information Systems — Data Format for the 

Interchange of Fingerprint Facial, & Other Biometric Information – Part 1

[2] NIST Special Publication 500-275, ANSI/NIST-ITL 2-2008 (XML Version of ANSI/NISTITL 1-2007), American National Standard for Information Systems — Data Format for the 

Interchange of Fingerprint Facial, & Other Biometric Information – Part 2: XML Version

[3] Update to “Data Format for the Interchange of Fingerprint, Facial & Other Biometric 

Information” for multiple finger capture designations ANSI/NIST ITL 1a-2009

[4] Draft NIST Special Publication 500-290, ANSI/NIST-ITL 1-2011, Information Technology:

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

Fingerprint, Facial & Other Biometric Information

http://biometrics.nist.gov/cs_links/standard/AN_2011_Voting_Version_July_2011.pdf

[5] ANSI/NIST Standard Homepage - http://www.nist.gov/itl/iad/ig/ansi_standard.cfm

[6] NIST/ITL's Biometric Application Programming Interface (BioAPI) Conformance Test Suite 

(CTS), http://www.nist.gov/itl/csd/biometrics/bioapicts.cfm

[7] ANSI INCITS 429:2008 Information technology - Conformance Testing Methodology for 

ANSI INCITS 358-2002 BioAPI Specification. Can be obtained from the ANSI eStore: 

http://webstore.ansi.org/

[8] ANSI INCITS 473:2011 Information Technology - Conformance Testing Methodology 

Standard for Patron Formats Conforming to INCITS 398-2008, Information Technology -

Common Biometric Exchange Formats Framework (CBEFF)

[9] INCITS M1 – Biometrics Public Homepage - http://standards.incits.org/a/public/group/m1

[10] NIST/ITL CSD Biometric Conformance Test Architectures and Test Suites Downloads Web 

Page: http://www.nist.gov/itl/csd/biometrics/biocta_download.cfm

[11] ISO/IEC JTC1/SC 37 – Biometrics Public Homepage -

http://www.iso.org/iso/jtc1_sc37_home

[12] Conformance Test Architecture and Test Suite for ANSI/NIST-ITL 1-2007, NISTIR 7791, 

June 2011, Fernando L. Podio, Dylan Yaga, Christofer J. McGinnis 

http://csrc.nist.gov/groups/ST/BiomResCenter/CTA_BETA/NISTIR_7791.pdf
6

Annex B – Test Assertion Syntax and Testing Levels

Test assertions are expressed according to the operators and operands found in the tables below, except for those instances where the 

assertion cannot be clearly or easily represented in a mathematical format. In those cases where English is used to express the assertion, the 

text will be contained within the < > characters. 

B.1 Operators

The table below includes a complete description of the operators used throughout the requirements and assertion tables.

Table B.1 - Operator Definitions

Operator Definitions

Operator Name Description

AND Logical And Tests if both values are true.

ELSE Else Combined with the IF operator to specify what expressions are evaluated when the IF expression is false.

EQ Equal To Tests for equality between two values.

GT Greater Than Tests if the first value is greater than the second value

GTE Greater Than or Equal To Tests if the first value is greater than or equal to the second value. 

IF Logical If Determines if the value or expression is true or false.

IFF IF and Only IF Tests the bi-conditional where each of the first and second expressions implies the other. 

in Container Specification For X in Y, selects only those X found in Y. 

LT Less Than Tests if the first value is less than the second value.

LTE Less Than or Equal To Tests if the first value is less than or equal to the second value.

MO Member Of Tests if the value is a contained within the set.

MOD Modulo For X MOD Y, provides the remainder of X divided by Y. 

NEQ Not Equal To Tests for non-equality between two values.

NOT Negate Negates any operator or expression that follows.

OR Logical Or Tests if either value is true

P:N in Q Query Selects the Nth occurrence of P in Q. 

ST Such That Enforces a condition upon the specified value or expression. 

THEN Then Combined with the IF operator to specify what expressions are evaluated when the IF expression is true. 

to Range Selection For X to Y, selects a set of values Z ST Z GTE X AND LTE Y

# All Provides all valid values.

: Data Element Selection For X:N, selects the Nth element in X. 
7

, Range Concatenation For X,Y, selects the set of values containing X and Y. 

. Field Selection For X.Y, selects the field specified by Y in Record X. 

< > English Expression Contains English text that could not be reasonably expressed mathematically. 

{ } Value For {X}, provides the value of X. 

[ ] Set The set to be tested.

B.2 Terms

The table below provides a complete description of the terms used throughout the requirements and assertion tables.

Table B.2 - Terms Used Throughout the Requirements and Assertion Tables

Term Definitions

Term Name Description

Field(s) Field Field structure as defined by the AN 1-2011 standard.

Integers Integer Set Set of all integers.

NA Not Applicable The test or condition is not applicable. 

NULL Null Control character with no value.

Record(s) Record Record structure as defined by the AN 1-2011 standard.

RS_Subfield RS Separated Subfield Subfield separated by the ASCII RS separator character

Subfield US or RS Separated Subfield Any field or information item separated by ASCII RS or US

Transaction Transaction Transaction structure as defined by the AN 1-2011 standard. 

TRUE True The test always evaluates to true because the field cannot be checked against a known value.

US_Subfield US Separated Subfield Information Item separated by the ASCII US separator character

B.3 Operands

The table below includes a complete description of the operands (functions) used throughout the requirements and assertion tables. The 

parameter X may represent any combination of operands, terms, and operators.

Table B.3 - Operands Used Throughout the Requirements and Assertion Tables

Operand Definitions

Operand Name Description

All(X) All Occurrences Returns all occurrences of X. 

ASCII(X) ASCII Values Specifies that all values represented by X are ASCII values. 

Bytes(X) Byte Data Returns the byte data contained in X.
8

Count(X) Count Occurrences Returns the number of occurrences of X. 

DataLength(X) Length Of (without Special Characters) Returns the length of X without counting Special Characters (such as US, RS, FS).

FieldNumber(X) Field Number Returns the field number of X.

First(X) First Occurrence Returns the first occurrence of X. 

For(X EQ A to B)

{Expression(s)}

For Loop Evaluates each Expression for the range specified by A to B. 

ForEach(X) 

{Expression(s)}

For Each Evaluates each Expression for every occurrence of X found.

Last(X) Last Occurrence Returns the last occurrence of X. 

Length(X) Length Of Returns the length of X.

Max(X) Maximum Value Returns the maximum value in the set X. 

MaxOccurrences(X) Maximum Occurrences Returns the maximum number of occurrences of X allowed by the 1-2011 

standard.

MaxSize(X) Maximum Size Returns the maximum size of X per occurrence allowed by the 1-2011 standard.

Min(X) Minimum Value Returns the minimum value in the set X. 

MinOccurrences(X) Minimum Occurrences Returns the minimum number of occurrences of X allowed by the 1-2011 

standard.

MinSize(X) Minimum Size Returns the minimum size of X per occurrence allowed by the 1-2011 standard.

Next(X) Next Occurrence Returns the next occurrence of X. Only for use within ForEach Operand’s 

Expression(s).

Pair(A,B) of X Pair Returns all pairs of X. Only for use as a parameter in a ForEach Operand. 

ParentField(X) Parent Field Returns the Field that contains X.

ParentRecord(X) Parent Record Returns the Record that contains X.

Present(X) Value Present Returns TRUE if X is present, FALSE otherwise. For subfields in Traditional 

Encoding, the US and RS separators are always present. Therefore the Present(X) 

operand returns TRUE if the value between the separators is present.

Previous(X) Previous Occurrence Returns the previous occurrence of X. Only for use within ForEach Operand’s 

Expression(s).

Second(X) Second Occurrence Returns the second occurrence of X. 

Sum(X) Summation Returns the summation of all the values that are a member of X. 

Type(X) Record Type Returns the Record Type of X.

Var(X) {Selection 

Statement}

Variable Assigns the entity specified by the Selection Statement to the name X. The 

assignment is valid for the remainder of the assertion text. 

XElm(X) XML Element Returns the XML Element with name X.
9

B.4 Hierarchy of Conformance Tests

Three levels of conformance testing are defined below. For each assertion included in the Tables of Requirements and Assertions in Annex 

C a level of conformance testing is indicated. See Table Headers in C.2 below.

Level 1 – Checking internal content 

In Level 1 testing, an AN-2011 transaction(s) is checked for field-by-field, subfield-by-subfield and information item–by information item 

conformance with the specification of the standard, both in terms of ranges, character types, and cardinality. Since Level 1 testing can be

performed by a simple field-by-field, subfield-by-subfield and information item–by information item reading of the standard and 

comparison to known values, and their encoding, performing this level of conformance testing only requires a transaction or a set of 

ANSI/NIST transactions (as opposed to a computer algorithm or a set of hardware and software). Therefore, any hardware or software 

components of the implementation being tested do not have to come into the possession of the testing lab. Only AN-2011 transactions 

created with those components need to be available. 

Level 2 – Internal consistency checking

In Level 2 testing, an AN-2011 transaction(s) is checked to determine if it is internally consistent. This is achieved by relating values from 

one or more fields, subfields, or information items within a transaction to other values within the same transaction. Level 2 tests involve 

interactions between multiple values from different parts of the AN-2011 standard and sometimes from implicit assumptions that are not 

explicitly stated in the base standard. Thus, Level 2 tests require more complex validation than Level 1. Similar to Level 1 testing, Level 2 

conformance testing only requires an AN-2011 transaction(s). To ensure that all (or almost all) possible internal consistency checks are 

tested, tests are performed whenever possible with a large number of transactions representing as many as possible different structural 

variants.

Level 3 – Content checking

A Level 3 test is intended to test whether an AN-2011 transaction under test is a faithful representation of the original biometric data and 

that it satisfies those requirements of the standard that are not simply a matter of syntax and format. This level of conformance testing for 

some requirements might be significantly difficult or even impossible to test. 

The requirements and assertion tables indicate whether Level 1 or Level 2 conformance testing is required to address the assertion identified 

in the test assertion. Level 3 conformance tests are indicated only when necessary to show that the requirement is not currently testable or 

addressed.
10

Annex C – Tables of Requirements and Assertions for AN-2011 4th Draft

C.1 Changes in the tables from the respective AN-2007 table

The following changes have been made from equivalent tables developed for the AN-2007 version of the standard:

Some Operators, Operands, and Terms have been modified or added to express new assertions.

Changes have been made for requirements addressing character counts within fields. While the AN-2007 standard included special 

characters (0x1E and 0x1F) in the count, the AN-2011 standard does not. This is reflected in the AN-2011 tables, which do not 

include special characters for character counts of fields.

The < > operator is used in the Requirements Summary column of the tables to represent text not found in the standard. This may 

be done in cases where the requirement is implied but not stated. The < > operator is used in the Test Assertions column to 

represent text that could not be expressed mathematically according to the Operators, Operands, and Terms listed in the tables in 

Annex A.

C.2 Table Headers

The following table headers are based on those specified in the Conformance Testing Methodology for AN-2011 (5th Draft). However, 

some minor changes have been made. The “Mnemonic” column was removed because the Mnemonic is now listed either in the 

Requirement or Assertion ID columns were appropriate. “Section” was changed to “Reference in Base Standard” to allow values other than 

clause numbers (such as table numbers and annexes).

The following describe the the headings of the requirements and assertions tables included below:

Requirement ID: Defines a unique identifier for the requirement and associated assertion or set of assertions. It provides reference 

to the type of requirement (e.g., transaction, record, and field). The Requirement ID is in the form of “Type: Description” where 

type may be “Transaction”, “Record”, or “Field”. For requirements found in Annex B of the AN-2011 standard, the Requirement 

ID is preceded by “Traditional-”.

Reference in Base Standard: Identifies the clause where the requirement is included in the standard. In some cases the reference 

includes additional information such as a Table number. This header corresponds to the Section header in the Conformance Testing 

Methodology for AN-2011 (5th draft), but allows references other than clause numbers (i.e., tables, annexes). 
11

Requirement Summary: Provides a summary of the requirement detailed as textual information or an interpretation of the 

requirement in the standard. It carries the essentials of the requirement but may not provide all the text necessary to understand it. 

The < > operator is used in the Requirement Summary column of the tables to represents text not found in the standard, but that may 

help indicate what requirement is being represented. 

Level: Indicates whether Level 1 or Level 2 conformance testing is required to address the assertion identified in the Assertion ID 

column of the same row. Level 3 conformance tests are indicated only when necessary to show that the requirement is not currently 

testable or addressed. 

Status: Reflects the status specified in the standard:

o M: Mandatory 

o O: Optional 

o D: Dependent 

o M⇑: Mandatory if field/repeating subfield present 

o O⇑: Optional if field/repeating subfield present for the field or subfield associated with the assertion.

o -: Varying statuses. The assertion addresses many fields or subfields of multiple statuses. 

Assertion ID: Defines an identifier of a specific test assertion within the set of test assertions associated with a requirement. 

Test Assertion: Provides, whenever possible, a mathematical equation or a procedure using the language specified by the Operators, 

Operands, and Terms.

o The < > operator is used to contain plain text whenever a mathematical formula or simple procedure cannot be detailed.

Test Note: Contains a number of a note included below the table. The test note may include a test procedure when the complexity 

of the test assertion does not allow this procedure to be included in the test assertion column. It could also include an explanatory

note related to the assertion’s implementation. Additionally, all exceptions (requirements specified by the standard but where the

assertion is not included are listed as test notes. Finally, in instances where contradictions or perceived discrepancies are present in 

the standard, test notes may be used to clarify the approach taken in the assertion tables.

Implementation Support: Denotes a supplier’s implementation support of a particular requirement (“Y”/”N”). A note can follow 

the table when providing more details of implementation support (or the lack of it) is required.

Supported Range: Indicates a range of values supported, especially when it is different than the full range of values specified in the 

standard. When an information item is specified as a single value, or does not address a range of values, a N/A should be used. 
12

Test Result: This column is used to denote the test results. For file and record-level results the results are either “Pass” or “Fail”. 

The field-level results should be indicated as “Ok”“Error”, “Warning” and “Note”. Explanatory notes can be added below the table.

Applicability: This table header indicates which assertions differ (in values required or conditions) between Traditional and NIEM 

encoding. This table header does not indicate which assertions are addressed by the XML Schema and which will need to be 

addressed in code. Valid values are:

o T: The assertion only applies to the Traditional encoding as described in Annex B. 

o X: The assertion only applies to the NIEM-conformant (XML) encoding as described in Annex C. 

o B: The assertion is applicable to both Traditional and NIEM (XML) encoding.

 Following the conventions in the AN-2011 standard, test Assertions are expressed using constructs (fields, records, etc.) 

found in Traditional encoding (such as xx.002 for the second field of each record type). The same assertion applies for 

the XML elements that correspond to the Traditional constructs. For example, 10.006 in Traditional Encoding 

corresponds to XML Element <biom:ImageHorizontalLineLengthPixelQuantity>. 

o Some assertions reference subfields, however, NIEM encoding uses nested elements. Expression of Test Assertions that 

include subfields in the XML encoding requires further review. These assertions are listed with the following applicability 

values:

 X* indicates that the assertion applies only to NIEM-conformant (XML) encoding. 

 B* indicates that the assertion is applicable to both Traditional and NIEM (XML) encodings.
13

C.3 Assertion Tables for AN-2011 4th Draft

Table C.1 - Assertions for Data Conventions

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

5: Data Conventions

Transaction: 

Required 

Record Types

5.1, 

Table 1

There shall be at least one data record 

accompanying a Record Type-1. The 

Record types are listed in Table 1.

1 M Transaction

-Required 

Records

Present(Record ST Type(Record) EQ 1)

AND

Present(Record ST Type(Record) MO [2 to 99]) 

AND NOT MO [3,5,6,11,12,22 to 97])

T

1 M NIEMTransaction

-Required 

Records

Present(XElm(itl:PackageInformationRecord))

AND

Count(Records) GTE 2

X

Transaction: 

Single Subject

5.1 All records in a transaction shall pertain to 

a single subject. Biometric data used to 

identify another individual requires a 

separate transaction.

3 M Transaction

-Single 

Subject

<Not tested.> t-1 B

Transaction: 

Records 

Transmitted 

Together

5.1 All of the records belonging to a single 

transaction shall be transmitted together.

3 M Transaction

-Records 

Together

<Not tested.> t-1 B

Transaction:

Record 

Occurrences

5.1 There may be multiple records in a 

transaction of each record type other 

than Type-1. 

1 M Transaction

-Record 

Occurrence

s

TRUE B

Transaction: 

Size

5.2 Although the 2007 and 2008 versions of 

the standard stated “... there is no upper 

limit on the number of logical records 

that may be present in a file...” there was 

an effective upper limit due to the field 

size limits specified in the 2007 version 

(but not the 2008 version). This limit was 

1 M Transaction

_Size

Count(Records in Transaction) LTE 1000 B
14

3 ASCII2 characters for the information 

item holding the total number of records 

of type 2 through 99; thus an upper limit 

of 999 such records. With the addition of 

a Type-1 record, the maximum number of 

records in a transaction was thus 

restricted to 1000. This upper limit of 

1000 records is maintained in this version 

of the standard to ensure backward 

compatibility with the 2007 version.

Transaction: 

Reserved

Records

5.3

Table 1

11 Voice Data (future)

12 Dental Record (future)

22-97 reserved for future use.

1M Records-

Reserved

NOT Present(Records ST Type(Records) MO 

[11,12,22 to 97])

T

1M NIEM-

Records_Re

served

<An invalid record type will cause a parsing error 

in XML because no Record Element Tag is 

defined (see Table 97).>

X

Transaction: 

Type1-

Occurrences

5.3.1 Transmissions to be exchanged are 

required to contain one and only one 

Type-1 record per transaction.

1M Type1_Occ

ur_Once

Count(Records in Transaction ST Type(Record) 

EQ 1) EQ 1

T

1M NIEM-

Type1_Occ

ur_Once

Count(XElm(itl:PackageInformationRecord)) EQ 1X

Transaction: 

Type1-

Record_First

5.3.1 The Type-1 record shall always be the first 

record within the transaction.

1M Type1_First Type(First(Record in Transaction)) EQ 1T

1M NIEM-

Type1_First

First(Record in Transaction) EQ 

XElm(itl:PackageInformationRecord)

X

Transaction: 

Type1- One 

More Record

5.3.1 At least one more record shall be present 

in the file.

1M Type1-One 

More 

Record

<See Requirement ID “Transaction: Required 

Record Types”>

t-2

Record: 

Type1-

Contents

5.3.1 The Type-1 record shall provide 

information describing type and use or 

purpose for the transaction involved, a 

listing of each record included in the 

transaction, the originator or source of

the physical record, and other useful and 

required information items.

M Type1_Con

tents

<The test assertions are included under field 

testing for Record Type-1: Transaction 

Information Record.>

t-2

Record: 

Type2-

Contents

5.3.2 Type-2 records shall contain user-defined 

textual fields providing identification and 

descriptive information associated with 

the subject of the transaction.

M Type2_Con

tents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-2: User-defined descriptive text 

record .>

t-2

Record: 

Type2-

DOM/APS

5.3.2 Each entry in a Type-2 record shall have a 

definition and format that is listed with 

the Domain owner. Data contained in this 

record shall conform in format and 

content to the specifications of the 

domain name(s) as listed in Field 1.013 

Domain name / DOM found in the Type-1 

3M Type2_DO

M/APS

<Not Tested.>t-3B
15

record, if that field is in the transaction. 

The default domain is NORAM. Field 

1.016 Application profile specifications / 

APS allows the user to indicate 

conformance to multiple specifications. If 

Field 1.016 is specified, the Type-2 record 

must conform to each of the application 

profiles.

Transaction: 

Type3-

Deprecated

5.3.3, 

Table 1

Record Type-3 shall not be contained in 

transactions conforming to this version of 

the standard.

M Type3_Uns

upported

<The test assertions are included under field 

testing for Record Type-3: DEPRECATED.>

t-2

Record: 

Type4-

Contents

5.3.4 Type-4 records were designed to convey 

fingerprint images captured by an 

Automated

Fingerprint Identification System (AFIS) 

live-scan reader, or other image capture 

devices operating at a nominal scanning 

resolution of 500 pixels per inch (ppi). 

Many systems still use this record type 

and it will remain an integral part of the 

standard.

M Type4_Con

tents

<The test assertions are included under field 

testing for Record Type-4: Grayscale fingerprint 

image.>

t-2

Transaction: 

Type5-

Deprecated

5.3.5, 

Table 1

Record Type-5 shall not be contained in 

transactions conforming to this version of 

the standard.

M Type5_Uns

upported

<The test assertions are included under field 

testing for Record Type-5: DEPRECATED.>

t-2

Transaction: 

Type6-

Deprecated

5.3.6, 

Table 1

Record Type-6 shall not be contained in 

transactions conforming to this version of 

the standard.

M Type6_Uns

upported

<The test assertions are included under field 

testing for Record Type-6: DEPRECATED.>

t-2

Transaction: 

Type7-

Contents

5.3.7 Type-7 is a legacy record type. It was 

intended as a temporary measure to 

enable the exchange of image data that 

would be defined by specific record types 

in later versions of the standard. Since 

some older systems still use this record 

type, it is included in the standard.

M Type7_Con

tents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-7: User-defined image record .>

t-2

Record: 

Type8-

Contents

5.3.8 Type-8 records shall be used for scanned

binary or vectored signature image data. 

Each

Type-8 record shall contain data 

representing the signature of the subject 

from whom the biometric sample is being 

collected and/or the operator capturing 

biometric data.

M Type8_Con

tents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-8: Signature image record.>

t-2

Record: 

Type9-

Contents

5.3.9 Type-9 records shall contain and be used 

to exchange minutiae or other friction 

ridge feature data. Each record shall 

represent the processed (automated

and/or manual) image data from which 

M Type9_Con

tents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-9: Minutiae data record .>

t-2
16

the characteristics are stated. The primary 

use of this record type shall be for remote 

searching of latent prints. New to this 

version of the standard is the Extended 

Feature Set

(EFS) for latent print markups. There is 

also a capability to have additional 

vendor-specified feature sets. 

Workstation logs may also now be 

transmitted in this record type.

Record: 

Type10-

Contents

5.3.10,

Table 

54

Type-10 image records shall contain and 

be used to exchange textual and image 

data from the face, scars, marks, and 

tattoos (SMT). New to this version of the 

standard is the extension of the record 

type to handle images of other body 

parts. See Table 54 for a list of the images 

types possible in a Type-10 record. 

Textual and analytic information 

pertinent to the digitized image is also 

contained in this record type.

M Type10_Co

ntents

<The test assertions are included under field 

testing for Record Type-10: Facial, other body 

part and SMT image record.>

t-2

Transaction: 

Type11-

Reserved

5.3.11 Type-11 records are reserved for future 

use.

M NA <See Requirement ID “Transaction: Reserved 

Records”>

t-2

Transaction: 

Type12-

Reserved

5.3.12 Type-12 records are reserved for future 

use.

M NA <See Requirement ID “Transaction: Reserved 

Records”>

t-2

Record: 

Type13-

Contents

5.3.13 Type-13 image records shall contain and 

be used to exchange variable-resolution 

latent friction ridge image data 

(fingerprint, palmprint and/or plantar) 

together with fixed and user defined 

textual information fields pertinent to the 

digitized image. In all cases, the scanning 

resolution for latent images shall be at 

least 39.37 ppmm (1000 ppi). The variable

resolution latent image data contained in 

the Type-13 record shall be 

uncompressed or may be the output from 

a lossless compression algorithm.

M Type13_Co

ntents

<The test assertions are included under field 

testing for Record Type-13: Friction-ridge latent 

image record . >

t-2

Record: 

Type14-

Contents

5.3.14 Type-14 image records shall contain 

fingerprint image data. It should be noted 

that as the resolution is increased, more 

detailed ridge and structure information 

becomes available in the fingerprint 

image. However, in all cases the scanning 

resolution class shall be at least 19.69 

M Type14_Co

ntents

<The test assertions are included under field 

testing for Record Type-14: Fingerprint image 

record.>

t-2
17

ppmm (500 ppi).

Record: 

Type15-

Contents

5.3.9 Type-15 image records shall contain and 

be used to exchange palm print image 

data together with fixed and user-defined 

textual information fields pertinent to the 

digitized image.

...in all cases the scanning resolution class 

shall be at least 19.69 ppmm (500 ppi) 

The variable-resolution palm print image 

data contained in the Type-15 record may 

be in a compressed form. 

M Type15_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-15: Palm print image record.>

t-2

Record: 

Type16-

Contents

5.3.9 The Type-16 image record is designed for 

developmental purposes and for the 

exchange of miscellaneous images. This 

record shall contain and be used to 

exchange image data together with 

textual information fields pertinent to the 

digitized image.

M Type16_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-16: User-defined testing image 

record.>

t-2

Record: 

Type17-

Contents

5.3.17 Type-17 image records shall contain iris 

image data. Field 17.018 (Global unique 

identifier) from the 2007 and 2008 

version of the standard has been 

deprecated in this version.

M Type17_Co

ntents

<The test assertions are included under field 

testing for Record Type-17: Iris image record .>

t-2

Record: 

Type18-

Contents

5.3.18 The Type-18 record (new to this version 

of the standard) shall contain and be used 

to exchange DNA and related data. It was 

developed to provide a basic level of 

interoperability with the draft format of 

the ISO/IEC 19794-14 DNA data 

interchange format. With full 

consideration to privacy, this standard 

only uses the non-coding regions of DNA. 

The regions of the DNA that encode 

phenotypic information are deliberately 

avoided.

M Type18_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-18: DNA record .>

t-2

Record: 

Type19-

Contents

5.3.19 Type-19 image records (new to this 

version of the standard) shall contain and 

be used to exchange variable-resolution 

plantar print image data together with 

fixed and user-defined textual 

information fields pertinent to the 

digitized image. ...in all cases the scanning 

resolution used to capture a plantar 

image shall be at least as great as the 

minimum scanning resolution of 19.69 

ppmm (500 ppi). The variable-resolution 

plantar image data contained in the TypeM Type19_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-19: Plantar record.>

t-2
18

19 record may be in a compressed form.

Record: 

Type20-

Contents

5.3.20 The Type-20 record (new to this version 

of the standard) shall contain the source 

representation(s) from which other 

Record Types were derived. Typically, one 

source Type-20 representation is used to 

generate one or more representations for 

use in other record types.

When a source representation (in a Type20 record) is processed and the resulting 

representation is to be used as the source 

for further derivations, then the 

processed representation is contained in 

a Type-20 record. An example would be 

an image used for both facial (Type-10) 

and iris (Type-17) records. In some cases, 

several Type-20 records may be 

processed to derive a single Type-20 

record.

M Type20_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-20: Source representation 

record.>

t-2

Record: 

Type21-

Contents

5.3.21 The Type-21 record shall contain an 

associated context image, audio / visual 

recording or other related data. This 

information does NOT contain 

information used to derive biometric 

information contained in other records. 

Record Type-20 serves that function. 

Record Type21 may be used to convey contextual 

information, such as an image of the area 

where latent fingerprints were captured.

M Type21_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-21: Associated context record.>

t-2

Record: 

Type98-

Contents

5.3.22 The Type-98 record shall contain security 

information that allows for the assurance 

of the authenticity and/or integrity of the 

transaction, including such information as 

binary data hashes, attributes for audit or 

identification purposes, and digital 

signatures.

M Type98_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-98: Information assurance 

record.>

t-2

Record: 

Type99-

Contents

5.3.23 Type-99 records shall contain and be used 

to exchange biometric data that is not 

supported by other ANSI/NIST-ITL record 

types. This provides a basic level of 

interoperability and harmonization with 

other biometric interchange formats. This 

is accomplished by using a basic record 

structure that is conformant with ANSI 

INCITS 398-2005, the Common Biometric 

Exchange Formats Framework (CBEFF) 

M Type99_Co

ntents

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-99: CBEFF biometric data 

record.>

t-2
19

and a biometric data block specification 

registered with the International 

Biometrics Industry Association (IBIA).

Record: 

Type1-ASCII

5.6,

Table 

90

Record Type-1 shall always be recorded in 

all encodings using the 7-bit American 

National Standard Code for Information 

Interchange (ASCII). The eighth (leftmost) 

bit shall contain a zero value.

1 M Type-1-

ASCII

ForEach(Field in Record ST Type(Record) EQ 1)

{

{Bytes(Field)} MO [0x02, 0x03, 0x1C to 0x7E]

}

T

C.4.1 For compatibility with existing 

implementations of the standard, 

implementers may wish to limit content 

to the 128 characters that can be 

represented by 7-bit ASCII.

Nevertheless, senders and receivers of 

XML packages using this standard may 

agree on other character sets, including 

international character sets.

1 M NIEMType1-User 

Defined

TRUE t-4 X

Transaction: 

EncodingBase64

5.6 Base-64 shall be used for converting nonASCII text into ASCII form, where required 

and noted in the standard. 

1 M DataEncodingBase-64<Not tested.> t-4 B

Field: 

EncodingCharSets

5.6,

Table 2

Field 1.015 Character encoding/DCS is an 

optional field that allows the user to 

specify an alternate character encoding... 

Field 1.015 Character encoding/DCS 

contains three information items: the 

character encoding set index/ CSI, the 

character encoding sent name/CSN, and 

the character encoding set version/CSV. 

The first two items are selected from the 

appropriate columns of Table 2. 

3 O DataEncodingCharSets<Not tested.> t-4 B
20

Table C.2 - Assertions for Implementation Domain & Application Profiles

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

6: Implementation Domain and Application Profiles

Field: 

Domain

6 An implementation domain, coded in 

Field 1.013 Domain name / DOM of a 

Type-1 record as an optional field, is a 

group of agencies or organizations that 

have agreed to use preassigned data 

fields with specific meanings (typically in 

Record Type-2) for exchanging

information unique to their installations. 

The implementation domain is usually

understood to be the primary application 

profile of the standard.

3 O FieldsDomain<Not tested.> t-3 B

Field: APS 6 Field 1.016 Application profile 

specifications / APS allows multiple 

application profiles to be referenced. The

organization responsible for the profile, 

the profile name and its version are all 

mandatory for each application profile

specified. A transaction must conform to 

each profile that is included in this field.

3 O Fields-APS <Not tested.> t-3 B
21

Table C.3 - Assertions for Information Associated with Several Records

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

7: Information Associated with Several Records

Field: 

xx.001-

Record 

Header

7.1 The record header appears as the first 

field (xx.001) in each Record Type. It 

contains information particular to the 

encoding format chosen, in order to 

enable proper reading of the record. In 

Traditional encoding, this field contains 

the record length in bytes (including all 

information separators).

1 M xx.001-First ForEach(Record in Transaction ST Type(Record) 

NEQ 4 OR 8)

{

FieldNumber(First(Field in Record)) EQ 1

}

T

1 M NIEMRecordCate

gory-First

ForEach(Record in Transaction)

{

First(Field in Record) EQ 

XElm(<biom:RecordCategoryCode>)

}

X

1 M xx.001-

Record 

Header

ForEach(Record in Transaction)

{

{Record.001} EQ Length (Record)

}

T

C.5.7,

7.1

Record Length. There is no corresponding 

XML element. See Section 7.1.

In NIEM-conformant XML encoding, this 

field contains the RecordCategoryCode, 

which is the numeric representation of 

the Record Type. 

1 M NIEMxx.001-

Record 

Category

< These assertions are included under field 

testing for the associated record types.>

t-2

Field: 

xx.999-

Reserved

7.2 Field xx.999 is reserved in Record Types 

10 and above for data associated with the 

record that is described in the other fields 

of the record. It is mandatory in most of 

these record types (It does not appear in 

Type-18 or Type-98).

M xx.999-

Reserved

< These assertions are included under field 

testing for the associated record types.>

t-2

1 M xx.999-

RecordType

s

ForEach(Field ST FieldNumber(Field) EQ 999) 

{

Type(ParentRecord(Field)) GTE 10 AND NOT MO 

[18, 98]

}

T

1 M NIEM- ForEach(Field ST Field EQ X
22

Image-

RecordCate

goryCode

XElm(nc:BinaryBase64Object)) {

{XElm(biom:RecordCategoryCode) in 

ParentRecord(Field)} GTE 10 AND NOT MO [18, 

98] }

Field: 

xx.002-IDC

7.3.1 Each of the records present in a 

transaction, with the exception of the 

Type-1 record, shall include a field 

(xx.002) containing the information 

designation character / IDC6. The value of 

the IDC shall be a sequentially assigned 

positive integer starting from zero and 

incremented by one up to a maximum of 

99. IDC references are stated in Type-1 

Field 1.003 Transaction content / CNT and 

shall be used to relate information items 

in the CNT field of the Type-1 record to 

the other records in the transaction. Two 

or more records may share a single IDC 

solely to identify and link together 

records that pertain to different 

representations of the same biometric 

trait.

1M xx.002-

IDCExists

ForEach( Record ST Type(Record) NEQ 1) {

Present(Record.002) }

T

1M NIEM-

IDCExists

ForEach(Record ST Record NEQ 

XElm(itl:PackageInformationRecord)) {

Present(XElm(biom:ImageReferenceIdentificatio

n) }

X

1M xx.002-

Second

ForEach( Record ST Type(Record) NEQ 4 OR 8) {

FieldNumber(Second(Field in Record)) EQ 2 }

T

1M NIEM- IDC-

Second

ForEach(Record ST Record NEQ 

XElm(itl:PackageInformationRecord)) {

Second(Field in Record) EQ 

XElm(biom:ImageReferenceIdentification) }

X

2M xx.002-

IDCSeqValu

es

Var(IDC_Fields) {

All(Fields in 

Records ST Type(Records) NEQ 1 AND 

FieldNumber(Fields) EQ 2) }

{First(Field in IDC_Fields)} EQ 0

AND

ForEach(Field in IDC_Fields) {

{Field} LTE 99 AND GTE 0

AND

{Next(Field)} LTE <Current Maximum IDC Value> 

+1

T
23

}

1 M NIEMIDCSeqValu

es

Var(IDC_Fields)

{

All(XElm(biom:ImageReferenceIdentification))

}

{First(Field in IDC_Fields)} EQ 0

AND

ForEach(Field in IDC_Fields)

{

{Field} LTE 99 AND GTE 0

AND

{Next(Field)} LTE <Current Maximum IDC Value> 

+1

}

X

2 M xx.002-

IDCRelate

<See tables in test note.> t-5 B

M 1.003-CNT <These assertions are included under field 

testing for Record Type-1: Transaction 

Information Record.>

t-2

Field: 

xx.002-

IDCImages

7.3.1 Two or more image records may share a 

single IDC only when they are 

enhancements of a single image; such 

transformations shall have identical 

dimensions. 

2 M xx.002-

SameDime

nsion

ForEach(Pair(A,B) of Records <with matching IDC 

fields>)

{

{A.006} EQ {B.006}

AND

{A.007} EQ {B.007}

}

B

3 M xx.002-

SameImage

<Not tested.

Not feasible to test if the samples are from the 

same image, only that the samples come from 

the same type of biometric trait (see Field:

xx.002-IDC)>

t-1 B

Field: 

xx.997-SOR

7.3,

7.3.2

...optional field xx.997 is allowed in 

biometric data sample Record Types 10 

and above that could have the biometric 

sample derived from a source 

1 O xx.997-

SORRecordType

s

ForEach(Field ST Type(Field) EQ 997) 

{

Type(ParentRecord(Field)) GTE 10 AND NOT MO 

[18,21,98]

T
24

representation in Record Type-20. The 

biometric data is stored in Field xx.999.

Record Type-18 (DNA) does not contain a 

field xx.997, since it does not contain a 

field 18.999. Record Type-98 does not 

contain this field, since that is not a

biometric data record type. Record Type21 does not contain biometric data and 

thus does not include field xx.997. This 

field is comprised of one mandatory and 

one optional information item, as 

described below.

}

1 O NIEM-SORRecordType

s

ForEach(Field ST Field EQ 

XElm(biom:SourceRepresentation)) 

{

{XElm(biom:RecordCategoryCode) in 

ParentRecord(Field)} GTE 10 AND NOT MO [18, 

21, 98]

}

X

Field: 

xx.997-SORSRN

7.3,

7.3.2.1

The first information item contains the 

source representation number / SRN. This 

is mandatory for each Field xx.997. It 

contains an index to a particular instance 

of a Type-20 record in the transaction. 

This same index value appears in the 

appropriate instance of

Record Type-20 as Field 20.021: Source 

representation number / SRN. The value 

of the SRN shall be a sequentially 

assigned positive integer starting from 

one and incremented by one, not to 

exceed 255. 

2 M

⇑

xx.997-

SOR-SRN

ForEach(Field ST FieldNumber(Field) EQ 997)

{

Present(Record in Transaction ST

Type(Record) EQ 20

AND

{Record.021} EQ { US_Subfield:1 in Field}

)

}

B*

2 O xx.997-

SOR-SRNSeqValues

Var(SOR_Fields)

{

All(Fields ST FieldNumber(Fields) EQ 997) 

}

Var(MaxSOR){2}

{US_Subfield:1 in RS_Subfield:1 in First(Field in 

ASC_Fields)} EQ 1

AND

ForEach(Field in SOR_Fields)

{

ForEach(RS_Subfield in Field)

{

{US_Subfield:1 in RS_Subfield} MO [1 to 255] 

AND LTE {MaxSOR}

AND IF {US_Subfield:1 in RS_Subfield} EQ 

{MaxSOR} THEN 

Var(MaxSOR) { MaxSOR + 1}

B*

Field: 7.3, The second information item in Field 2 O xx.997- ForEach(Field ST FieldNumber(Field) EQ 997) B*
25

xx.997-SOR-

RSP

7.3.2.2 xx.997 is optional. It is the reference 

segment position / RSP. It contains the 

index to a particular set of segmentation 

coordinates of the source representation 

(There may be more than one segment, 

such as from an audio / visual recording, 

with different frames yielding input for 

separate biometric data record instances 

in the same transaction). This same 

segmentation index value appears in 

Record Type-20 as the reference segment 

position / RSP in Field 20.016: Segments / 

SEG. There may be up to 99 segments 

listed in Field 20.016, but only the 

segment used to produce the biometric

data contained in Field xx.999 of the 

particular instance of Record Type-xx is 

identified in

Field xx.997.

⇑ SOR

-RSP{

Present(US_Subfield in 20.016 ST US_Subfield EQ 

{US_Subfield:2 in Field}) )}

3O xx.997-

SOR-RSP-

CorrectSeg

ment

<Not Tested.

Not feasible to test if the RSP that matches was 

used to produce the biometric data. >

t-1 B*

1O 20.016-

SegmentOc

curences

Count(US_Subfield in 20.016) LTE 99 B*

Field: 

xx.995-ASC

7.3,

7.3.3

New to this version of the standard, 

optional field xx.995 is contained in 

biometric data sample Record Types 10 

and above that may have instances of 

Record Type-21 linked to it...

This field consists of a maximum of 255 

repeating subfields, each of which 

contains two information items, as 

described below.

1O xx.995-ASC-

RecordType s

ForEach(Field ST FieldNumber(Field) EQ 995) {

Type(ParentRecord(Field)) GTE 10 }

T

1O NIEM-ASC-

RecordType s

ForEach(Field ST Field EQ 

XElm(biom:AssociatedContext)) {

{XElm(biom:RecordCategoryCode) in 

ParentRecord(Field)} GTE 10 }

X

1O xx.995-ASC-

SubfieldOcc

urences

ForEach(Field ST FieldNumber(Field) EQ 995) {

Count(RS_Subfields in Field) LTE 255 }

B*

Field: 

xx.995-ASC-

ACN

7.3,

7.3.3.1

The first information item contains the 

associated context number / ACN for a 

particular Record Type-21. This is 

mandatory for each Field xx.995, when 

the field is used. It contains an index to a 

particular instance of a Type-21 record in 

the transaction. This same index value 

appears in the appropriate instance of 

Record Type-21 as Field 21.021:

Associated context number / ACN. The 

value of the ACN shall be a sequentially 

assigned a positive integer starting from 

one and incremented by one, not to 

exceed 255.

2M⇑xx.995-ASC-

ACN

ForEach(Field ST FieldNumber(Field) EQ 995) {

ForEach(RS_Subfield in Field) {

Present(Record in Transaction ST

Type(Record) EQ 21

AND

{Record.021} EQ { US_Subfield:1 in RS_Subfield} )}}

B*

2O xx.995-ASC- Var(ASC_Fields) B*
26

ACNSeqValues{

All(Fields in Transaction ST FieldNumber(Fields) 

EQ 995) 

}

Var(MaxASC){2}

{US_Subfield:1 in RS_Subfield:1 in First(Field in 

ASC_Fields)} EQ 1

AND

ForEach(Field in ASC_Fields)

{

ForEach(RS_Subfield in Field)

{

{US_Subfield:1 in RS_Subfield} MO [1 to 255] 

AND LTE {MaxASC}

AND IF{US_Subfield:1 in RS_Subfield} EQ 

{MaxASC} THEN 

Var(MaxASC) { MaxASC + 1}

}

}

Field: 

xx.995-ASCASP

7.3,

7.3.3.2

The second information item in Field 

xx.995 is optional. It is the associated 

segment position / ASP. It contains the 

index to a particular set of segmentation 

coordinates of the associated context 

data. This same segmentation index value 

appears in Record Type-21 as the 

associated segment position / ASP in Field 

21.016: Segments / SEG. There may be up 

to 99 segments listed in Field 21.016, but 

only the relevant segment is contained in 

Field xx.995.

2 O

⇑

xx.995-ASCASPForEach(Field ST FieldNumber(Field) EQ 995)

{

Present( US_Subfield in 20.016 ST US_Subfield 

EQ {US_Subfield:2 in Field})

)

}

B*

3 O

⇑

xx.995-ASCASPCorrectSeg

ment

<Not Tested.

Not feasible to test if the ASP that matches is the 

one that is relevant. >

t-1 B

1 M 21.016-

SegmentOc

curences

Count(US_Subfield in 21.016) LTE 99 B*

Field: 

10.039-

RefNum

7.3,

7.3.4

There may be several Type-10 images of a 

particular part of the body. For instance, a

photograph of a tattoo may cover the 

entire tattoo. Another may be a zoom-in 

shot of a portion of the tattoo. In order to 

link these two images, the same index 

2 D 10.039-

T10-DiffIDC

IF Count(Records ST Type(Records) EQ 10) GT 1

THEN

ForEach(Pair (A,B) of Records ST Type(Records) 

EQ 10)

{

IF {A.039} EQ {B.039}

T
27

number is assigned to Field 10.039: Type-

10 reference number / T10, which is new 

to this version of the standard. Note that 

these images would have different IDC 

values.

THEN

{A.002} NEQ {B.002} }

2D NIEM-T10-

DiffDC

IF 

Count(XElm(itl:PackageFacialAndSMTImageReco

rd)) GT 1

THEN

ForEach(Pair (A,B) of

XElm(itl:PackageFacialAndSMTImageRecord) {

IF { XElm(nc:IdentificationID) in 

XElm(biom:PhysicalFeatureReferenceIdentificati

on) in A} EQ { XElm(nc:IdentificationID) in 

XElm(biom:PhysicalFeatureReferenceIdentificati

on) in B} 

THEN

{ XElm(nc:IdentificationID) in 

XElm(biom:ImageReferenceIdentification) in A} 

EQ { XElm(nc:IdentificationID) in 

XElm(biom:ImageReferenceIdentification) in B} }

X

3D 10.039-

T10-

SameBodyP

art

<Not Tested.

Not feasible to test if the images are related to 

the same part of the body.>

t-1B

Field: 

14.026-

SimCap

7.3,

7.3.5

In order to accommodate the emergence 

of technology that can simultaneously 

capture fingerprint images on separate 

platens or other technology that does not 

preserve the full relative position of the 

fingers to each other, Field 14.026: 

Simultaneous capture / SCF allows the 

user to use the same index for all images 

that were simultaneously captured.

3O 14.026-SCF <Not Tested.

Not feasible to test if the images were captured 

simultaneously. >

t-1B

Field: 

xx.902-ANN

7.4.1 New for this version of the standard, 

optional field xx.902 is used to store 

annotation, logging, or processing 

information associated with one or more 

processing algorithms or workstations. If 

present, this text field shall consist of one 

or more subfields comprised of a set of 

information items.

1O xx.902-

ANN-

Subfields

ForEach(Record in Transaction) {

IF Present(Record.902) THEN

Count(RS_Subfields in Record.902) GTE 1 

AND

B*
28

Four mandatory information items 

comprise a subfield:

• The first information item is the GMT 

date and time / GMT when the processing

occurred. (See Section 7.7.2.2)

• The second information item (processing algorithm name/version / 

NAV) shall contain an unformatted text 

string of up to 64 characters identifying 

the name and version of the processing 

algorithm or workstation.

• The third information item (algorithm 

owner / OWN) shall contain a text string 

of up to 64 characters with the contact 

information for the organization that 

owns the processing algorithm or latent 

workstation.

• The fourth and final information item (process description / PRO) shall contain 

an unformatted text string of up to 255 

characters describing a process or 

procedure applied to the sample in this 

Type-XX record.

ForEach(RS_Subfield in Record.902) {

Count(US_Subfields in RS_Subfield) EQ 4 }}

1M⇑xx.902-

ANN-GMT

ForEach(Record in Transaction) {

IF Present(Record.902) THEN

ForEach(RS_Subfield in Record.902) {

{US_Subfield:1 in RS_Subfield}

MO [ValidUTC/GMT] }}

t-6T

1M⇑NIEM-

xx.902-

ANN-GMT

< The treatment of subfields for validation in the 

XML version requires further review.>

t-6 X*

1M⇑xx.902-

ANN-

NAV&OWN

ForEach(Record in Transaction) {

IF Present(Record.902) THEN

ForEach(RS_Subfield in Record.902) {

Length(US_Subfield:2 in RS_Subfield) LTE 64

AND

Length(US_Subfield:3 in RS_Subfield) LTE 64 }}

B*

1M⇑xx.902-

ANN-PRO

ForEach(Record in Transaction) {

IF Present(Record.902) THEN

ForEach(RS_Subfield in Record.902) {

B*
29

Length(US_Subfield:4 in RS_Subfield) LTE 255

}

}

Field: 9.901-

ULA

7.4.2 This optional field, which is new to this 

version of the standard, exists only in 

Record Type- 9. This workstation has 

been extensively used and logs generated 

from it were routinely transmitted in Field 

9.901: Universal latent workstation 

annotation information / ULA. This 

version of the standard formally includes 

this field to record latent processing logs 

formatted according to the ULW.

O 9.901-ULW <The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-9: Minutiae data record.>

t-2

Field: 

98.900-ALF

7.4.3 If a user wishes to maintain a log of 

differences between transmissions,... may 

be used to indicate how and why a 

transaction was modified. Record Type-98 

is new to this version of the standard. 

O 98.900-ALF <The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-98: Information assurance 

record.>

t-2

Field: 

Comment

7.4.4 The optional Comment field appears in 

many record types and may be used to 

insert free text information. It is not 

reserved exclusively for log-related 

information but has historically often 

been used for this purpose. It is limited to 

a maximum of 126 characters.

1 O 10.038-

COMLength: 

10.038

Length(10.038) LTE 126 B

1 O xx.020-

COMLength: 

[13,14].020

Length([13,14].038) LTE 126 B

1 O 17.021-

COMLength: 

17.021

Length(17.021) LTE 126 B
30

Field: 

98.003-

IA/DFO

7.5.1 The Record Type-98: Information 

assurance record, which is new to this 

version of the standard, allows special 

data protection procedures to ensure the 

integrity of the transmitted data. Field 

98.003: IA data format owner / DFO and 

Field 98.005: IA data format type / DFT 

define the information assurance regime 

that is employed to store data in Fields

98.200-899: User-defined fields / UDF.

M 98.003-DFO <The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-98: Information assurance 

record.>

t-2

Field: HAS 7.5.2 Optional field xx.996, which is new to this 

version of the standard, is designed for 

use in Record types 10 and above with a 

Field xx.999 storing the biometric data. It 

is comprised of 64 characters 

representing hexadecimal values. Thus, 

each character may be a digit from “0” to 

“9” or a letter “A” through “F”.

1 O xx.996-

HASRecordType

s

ForEach(Field ST FieldNumber(Field) EQ 996) 

{

Type(ParentRecord(Field)) GTE 10 

}

T

1 O NIEM-HASRecordType

s

ForEach(Field ST Field EQ 

XElm(biom:ImageHashValue)) 

{

{XElm(biom:RecordCategoryCode) in 

ParentRecord(Field)} GTE 10 

}

X

1 O xx.996-

HAS-HEX

ForEach(Field ST FieldNumber(Field) EQ 996) 

{

Bytes(Field) MO[ASCII(0 to 9,A to F)]

}

B

1 O xx.996-

HAS-Length

ForEach(Field ST FieldNumber(Field) EQ 996) 

{

Length(Field) EQ 64

}

B

Field: 

Agency 

Codes

7.6, 

Table 19,

Table53,

Table66,

Table67,

Table71

This information appears in a variety of 

fields (often xx.004), and is handled the 

same in all such fields. The data content 

of this field is defined by the user and 

shall be in accordance with the receiving 

agency. In the 2007 version of the 

standard, these fields are comprised of

one information item 

{destination}{originating} agency 

identifier / DAI or ORI. The 2008 version 

1 M 1.007-

DAI/ORILength

Length(US_Subfield:1 in 1.007) GTE 1 B*

1 M 1.008-

DAI/ORILength

Length(US_Subfield:1 in 1.008) GTE 1 B*

1 M [10,13,14,1 Length(US_Subfield:1 in [10,13,14,15,17].004) B*
31

of the standard added a second optional 

information item {destination}

{originating} agency name / DAN or OAN, 

which is a text description of the 

organization name. It may be up to 125 

characters in length. This second 

information item is optional for all 

encodings in this version of the standard 

and may be encoded using an alternate

character encoding set (See Section 5.6).

5, 17].004-

DAI/ORI-

Length

GTE 1

1O 1.007-

DAN/OAN-

Length

Length(US_Subfield:2 in 1.007) LTE 125 B*

1O 1.008-

DAN/OAN-

Length

Length(US_Subfield:2 in 1.008) LTE 125 B*

1O [10,13,14,1

7].004-

DAN/OAN-

Length

Length(US_Subfield:2 in [10,13,14,17].004)) LTE 

125

B*

1M Fields: 

DAN/OAN-

Value

Present(1.007,1.008, [10,13,14,17].004) B*

Field: Device 

ID

7.7.1.1 The DUI shall contain a string uniquely 

identifying the device or source of the 

data. This field shall be one of:

• Host PC MAC address, identified by the 

first character “M”, or

• Host PC processor ID, identified by the 

first character “P.

Fields containing the DUI are: -Field 9.903: Device unique identifier / 

DUI -Field 10.903: Device unique identifier / 

DUI -Field 13.903: Device unique identifier / 

DUI -Field 14.903: Device unique identifier / 

DUI -Field 15.903: Device unique identifier / 

DUI -Field 16.903: Device unique identifier / 

DUI -Field 17.017: Device unique identifier / 

DUI -Field 19.903: Device unique identifier / 

DUI -Field 20.903: Device unique identifier / 

DUI -Field 99.903: Device unique identifier / 

DUI

1O [10,13,14].

903-DUI-

Format

IF(First(Byte in [10,13,14].903) EQ ASCII(M) THEN {

Bytes([10,13,14].903) MO[ASCII(0 to 9, A to F)]

AND 

Length([10,13,14].903) EQ 13 }

IF(First(Byte in [10,13,14].903) EQ ASCII(P) THEN {

Length([10,13,14].903) EQ 17 }

B

1O 17.017-DUI IF(First(Byte in 17.017) EQ ASCII (M) THEN {

Bytes(17.017) MO[ASCII (0 to 9, A to F)]

AND 

Length(17.017) EQ 13 }

IF(First(Byte in 17.017) EQ ASCII (P) THEN {

Length(17.017) EQ 17 }

B
32

The MAC address takes the form of six 

pairs of hexadecimal values (0 through 9 

and A through F). They are represented 

without separators in this standard for a 

total of 13 characters. The processor ID 

may be up to 16 characters.

Field: Make 

Model

7.7.1.2 The MMS contains the make, model and 

serial number for the capture device. It 

shall consist of three information items. 

Each information item shall be 1 to 50 

characters. Any or all information items 

may indicate that information is unknown 

with the value “0”.

Fields containing the MMS are:

-Field 9.904: Make/model/serial number 

-Field 10.904: Make/model/serial number 

-Field 13.904: Make/model/serial number 

-Field 14.904: Make/model/serial number

-Field 15.904: Make/model/serial number

-Field 16.904: Make/model/serial number 

-Field 17.019: Make/model/serial number

-Field 19.904: Make/model/serial number

-Field 20.904: Make/model/serial number 

-Field 99.904: Make/model/serial number 

1 O [10,13,14].

904-MMS

Count(US_Subfields in [10,13,14].904) EQ 3

AND

Length(US_Subfields in [10,13,14].904) LTE 50 

AND GTE 1

B*

1 O 17.019-

MMS

Count(US_Subfields in 17.019) EQ 3

AND

Length(US_Subfields in 17.019) LTE 50 AND GTE 

1

B*

Field: Device 

Monitoring

7.7.1.3,

Table 3

This field describes the level of human 

monitoring that was associated with the 

biometric sample capture. Alphabetic 

values are selected from Table 3. These 

are corresponding fields in the standard:

-Field 10.030: Device monitoring mode / 

DMM

-Field 14.030: Device monitoring mode / 

DMM

-Field 15.030: Device monitoring mode / 

DMM

-Field 16.030: Device monitoring mode / 

DMM

-Field 17.030: Device monitoring mode / 

DMM

-Field 19.030: Device monitoring mode / 

DMM

1 O [10,14,17].

030-DMM

{[10,14,17].030} MO [ASCII(CONTROLLED, 

ASSISTED, OBSERVED, UNATTENDED, 

UNKNOWN)]

B
33

Field: UTC 7.7.2.2 UTC has replaced GMT as the main 

reference time scale terminology, but the 

older terminology is retained in this 

standard for existing record types. In this 

standard, Field

1.014 Greenwich mean time / GMT shall 

be taken to mean the UTC value. Some 

newer record types using this format 

refer to the data as UTC (such as in Field 

18.013: Sample collection date / SCD). 

This time is independent of the actual 

time zone where the time and date is 

recorded. The data is 

YYYYMMDDhhmmssZ, where the Z is 

indicates the zone description of 0 hours.

M Fields-UTC <This requirement applies to any field that 

contains a date or time value. The assertions will 

be applied individually for those fields. >

t-2, t-6

Field: TIX 7.7.2.5,

Table 81,

Table 84

For Type-20 or Type-21 records 

containing video or audio, this field shall 

contain two information items, time index 

start /TIS and time index end / TIE for the 

start and end times of segments within a 

video or audio file, measured in 

hh:mm:ss.sss where ss.sss refers to the 

seconds and milliseconds. This field is 

comprised of one or more subfields. Each 

repeating subfield corresponds to a single 

segment, with a starting and end time as 

separate information items.

D Fields-TIX <The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-98: Information assurance 

record.>

t-2

Field: 

Geographic

7.7.3,

Table 53,

Table 66,

Table 67, 

Table 69, 

Table 70,

Table 71,

Table 74, 

Table 80,

Table 81,

Table 86

New to this version of the standard, this 

optional field (xx.998) is used in Record 

Types 10 and above. It specifies the 

coordinated universal time (UTC) and the 

location where the biometric sample was 

collected. All of this information is 

contained in up to fifteen information 

items.

1 O xx.998-

GeoRecordType

s

ForEach(Field ST FieldNumber(Field) EQ 998) 

{

Type(ParentRecord(Field)) GTE 10}

T

1 O NIEM-GEORecordType

s

ForEach(Field ST Field EQ 

XElm(biom:CaptureLocation)) 

{

{XElm(biom:RecordCategoryCode) in 

ParentRecord(Field)} GTE 10 

}

X

1 O xx.998-

GeoSubfields

ForEach(Field ST FieldNumber(Field) EQ 998) 

{

Count(US_Subfields in Field) LTE 15

}

B*

1 O xx.998- ForEach(Field ST FieldNumber(Field) EQ 998) B*
34

Subfield 

CharType 

ANSU

{

Bytes(US_Subfield:1 in Field}) MO [0x30 to 0x39, 

0x5A, 0x7A]

AND

Bytes(US_Subfield:2,5 in Field) MO 

[0x2B,0x2D,0x2E,0x30 to 0x39]

AND

Bytes(US_Subfield:3,6 in Field) MO [0x2E, 0x30 

to 0x39]

AND

Bytes(US_Subfield:4,7,11,12 Field) MO [0x30 to 

0x39]

AND

Bytes(US_Subfield:8 in Field) MO [0x2D, 0x30 to 

0x39]

AND

Bytes(US_Subfield:9,10 in Field) MO [0x30 to 

0x39, 0x41 to 0x5A, 0x61 to 0x7A]

AND

Present(Bytes(US_Subfield:113 to 15 in Field) 

1O xx.998-

CharCount

ForEach(Field ST FieldNumber(Field) EQ 998) {

DataLength(Field) MO [15 to 365] }

B

1O xx.998-

Subfield 

CharCount

ForEach(Field ST FieldNumber(Field) EQ 998) {

Length(US_Subfield:1 in Field)) EQ 15

AND

Length(US_Subfield:2,14 in Field) MO [1 to 10]

AND

Length(US_Subfield:3,6 in Field) MO [1 to 5]

AND

Length(US_Subfield:4,7 in Field) MO [1 to 2]

AND

Length(US_Subfield:5 in Field) MO [1 to 11]

AND

Length(US_Subfield:8 in Field) MO [1 to 8]

AND

Length(US_Subfield:9 in Field) MO [2 to 6]

AND

Length(US_Subfield:10 in Field) EQ 5

AND

Length(US_Subfield:11,12 in Field) MO [2 to 5]

AND

Length(US_Subfield:13 in Field) MO [1 to 150]

B*
35

AND

Length(US_Subfield:15 in Field) MO [1 to 126] }

Field: 

Geographic-

Subfield 1

7.7.3 The first information item is mandatory. It 

is the coordinated universal time entry 

/UTE. See Section 7.7.2.2.

1M⇑xx.998-

Geo-UTE

ForEach(Field ST FieldNumber(Field) EQ 998) {

Present(US_Subfield:1 in Field)

AND

{US_Subfield:1 in Field} MO [ValidUTC/GMT]

}

t-6T

1M⇑NIEM-

xx.998-

Geo-UTE

< The treatment of subfields for validation in the 

XML version requires further review.>

t-6 X*

Field: 

Geographic-

Conditional

7.7.3 The next eight information items 

(information items 2 through 9) comprise 

the Geographic Coordinate 

Latitude/Longitude. As a group, they are 

optional. However, latitude degree value 

/ LTD and longitude degree value / LGD 

are co-conditional, so they shall both be 

present if either is present. Further, 

“minutes” values LTM and LGM can only 

be present if their corresponding 

“degrees” values are present. LTS and LGS 

can only be present if their corresponding 

“minutes” value is present. The other 

entries are optional.

If a decimal value is used in a particular 

information item, the more granular 

information item shall be empty

(e.g., if Longitude minutes equals 45.27, 

Longitude seconds shall be empty).

The tenth, eleventh and twelfth 

information items are treated as a group 

and are optional.

These three information items together 

are a coordinate which represents a location with a Universal Transverse 

Mercator (UTM) coordinate. If any of these three information items is present, 

all shall be present.

2- xx.998-

Geo-Cond-

Subfields 

2,5

ForEach(Field ST FieldNumber(Field) EQ 998) {

Present{US_Subfield:2 in Field} IFF

Present {US_Subfield:5 in Field} }

B*

2- xx.998-

Geo-Cond-

Subfields 

10 to 12

ForEach(Field ST FieldNumber(Field) EQ 998) {

IF Present(US_Subfield:10 OR US_Subfield:11 OR 

US_Subfield:12 in Field)

THEN

Present(US_Subfield:10 AND US_Subfield:11 

AND US_Subfield:12 in Field) }

B*

2O xx.998-

Geo-Cond-

DMS

ForEach(Field ST FieldNumber(Field) EQ 998) {

IF Present (US_Subfield:4 in Field) THEN

Present(US_Subfield:3 in Field) 

AND

IF Present(US_Subfield:3 in Field) THEN

Present (US_Subfield:2 in Field)

AND

IF Present(US_Subfield:7 in Field) THEN

Present (US_Subfield:6 in Field) 

AND

IF Present(US_Subfield:6 in Field) THEN

Present (US_Subfield:5 in Field)

B*
36

}

2 O xx.998-

Geo-CondDecimals

ForEach(Field ST FieldNumber(Field) EQ 998) 

{

IF {US_Subfield:2 in Field} MOD 1 NEQ 0 THEN

Length(US_Subfield:3 in Field) EQ 0 AND 

Length(US_Subfield:4) EQ 0

AND

IF {US_Subfield:3 in Field} MOD 1 NEQ 0 THEN

Length(US_Subfield:4 in Field) EQ 0

AND

IF {US_Subfield:5 in Field} MOD 1 NEQ 0 THEN

Length(US_Subfield:6 in Field) EQ 0 AND 

Length(US_Subfield:7) EQ 0

AND

IF {US_Subfield:6 in Field} MOD 1 NEQ 0 THEN

Length(US_Subfield:7 in Field) EQ 0 

}

B*

Field: 

GeographicValuesSubFields 2 

to 8

7.7.3 The second information item is latitude 

degree value / LTD. This is a value that 

specifies the degree of latitude. The value 

shall be between -90 (inclusive) and +90 

(inclusive).

The third information item is latitude 

minute value / LTM. This is a value that 

specifies a minute of a degree. The value 

shall be between 0 (inclusive) to 60 

(exclusive).

The fourth information item is the 

latitude second value / LTS. This is a value 

that specifies a second of a minute. The 

integer shall be 0 (inclusive) to 60 

(exclusive).

The fifth information item is the longitude 

degree value / LGD. It is a value that 

specifies the degree of a longitude. The 

value shall be between -180 (inclusive) 

and

1 - xx.998-

GeoValuesSub2 to 8

ForEach(Field ST FieldNumber(Field) EQ 998) 

{

{US_Subfield:2 in Field} GTE -90 AND LTE 90

AND

{US_Subfield:3 in Field} GTE 0 AND LT 60

AND

{US_Subfield:4 in Field} GTE 0 AND LT 60

AND

{US_Subfield:5 in Field} GTE -180 AND LTE 180

AND

{US_Subfield:6 in Field} GTE 0 AND LT 60

AND

B*
37

+180 (inclusive). 

The sixth information item is the 

longitude minute value / LGM. It is a value 

that specifies a minute of a degree. The 

value shall be from 0 (inclusive) to 60 

(exclusive).

The seventh information item is the 

longitude second value / LGS. This is a 

value that specifies a second of a minute. 

The integer shall be 0 (inclusive) to 60

(exclusive). 

The eighth information item is elevation /

ELE. It is expressed in meters. It is a 

numeric value. It is between -422 meters 

(Dead Sea) and 8848 meters (Mount

Everest).

{US_Subfield:7 in Field} GTE 0 AND LT 60

AND

{US_Subfield:8 in Field} GTE -422 AND LTE 8848

}

Field: 

Geographic-

Values-

SubField 9

7.7.3,

Table 4

The ninth information item is the geodetic 

datum code / GDC10. It is an 

alphanumeric value of 3 to 6 characters in 

length. This information item is used to 

indicate which coordinate system was 

used to represent the values in 

information items 2 through 7. If no entry 

is made in this information item, then the 

basis for the values entered in the first 

eight information items shall be WGS84, 

the code for the World Geodetic Survey 

1984 version - WGS 84 (G873). See Table 

4 for values.

1O xx.998-

Geo-

Values-

Sub9

ForEach(Field ST FieldNumber(Field) EQ 998) {

{US_Subfield:9 in Field} MO [ASCII(AIRY, AUST, 

BES, BESN, CLK66, CLK80, EVER, FIS60, FIS68, 

GRS67, HELM, HOUG, INT, KRAS, AIRYM, EVERM, 

FIS60M, SA69, WGS60, WGS66, WGS72, 

WGS84)]

OR 

Length(US_Subfield:9 in Field) MO [3 to 6] AND 

Bytes(US_Subfield:9 in Field) MO [0x30 to 0x39, 

0x41 to 0x5A, 0x61 to 0x7A]

OR

Length(US_Subfield:9 in Field) EQ 0 }

t-7 B*

Field: 

Geographic-

Values-

SubField 10

7.7.3 The tenth information item is the 

geographic coordinate universal 

transverse Mercator zone / GCM. It is an 

alphanumeric value of 5 characters.

• The first two characters represent the 

6° wide UTM zone. Leading zeros are 

included.

• The third character is a letter 

designating the band of latitude.

• The fourth and fifth characters are a 

pair of letters identifying one of the

100,000-meter grid squares within the 

grid zone (UPS area).

1O xx.998-

Geo-

Values-

Sub10

ForEach(Field ST FieldNumber(Field) EQ 998) {

{Bytes:1 in US_Subfield:10 in Field} * 10 + 

{Bytes:2 in US_Subfield:10 in Field} GTE 1 AND 

LTE 60

AND

{Bytes:3 to 5 in US_Subfield:10 in Field } MO 

[ASCII(Cto X)] AND NOT MO [ASCII(I,O)] }

t-8B*
38

1O xx.998-Geo 

-Sub10-

ValidZone

ForEach(Field ST FieldNumber(Field) EQ 998) {

{US_Subfield:10 in Field} MO [ValidZone] }

t-8 B*

Field: 

Geographic-

Values-

SubField 11 

and 12

7.7.3 The eleventh information item is the 

geographic coordinate universal 

transverse

Mercator easting / GCE. It is an integer of 2-digits for 1 kilometer precision, 3-

digits for 100 meter precision, 4-digits for 

10 meter precision and 5-digits for 1

meter precision.

The twelfth information item is the 

geographic coordinate universal 

transverse

Mercator northing / GCN. It is an integer 

of 2-digits for 1 kilometer precision, 3-

digits for 100 meter precision, 4-digits for 

10 meter precision and 5-digits for 1 

meter precision.

2D xx.998-

Geo-

Values-

Sub11,12

ForEach(Field ST FieldNumber(Field) EQ 998) {

Length(US_Subfield:11,12 in Field) GTE 2 AND 

LTE 5

AND

Bytes(US_Subfield:11,12 in Field) MO [ASCII(0 to 

9)] }

B*

Field: 

Geographic-

Values-

SubField 13

7.7.3 The thirteenth information item is 

optional. It is the geographic reference 

text /GRT. This information item is an 

alphanumeric entry of up to 150 

characters. It is a

free form text describing a street address 

or other physical location (such as ‘Corner

of Washington and Madison, Geneva, 

NY’).

1O xx.998-

Geo-

Values-

Sub13

ForEach(Field ST FieldNumber(Field) EQ 998) {

Length(US_Subfield:13 in Field) LTE 150 }

B*

Field: 

Geographic-

Values-

SubField 14

7.7.3 A fourteenth optional information item 

geographic coordinate other system

identifier / OSI allows for other 

coordinate systems. This information 

items specifies the system identifier. It is 

up to 10 characters in length. Examples 

are:

• MGRS (Military Grid Reference System)

• USNG (United States National Grid)

• GARS (Global Area Reference System)

1O xx.998-

Geo-

Values-

Sub14

ForEach(Field ST FieldNumber(Field) EQ 998) {

Length(US_Subfield:14 in Field) LTE 10 }

B*
39

• GEOREF (World Geographic Reference)

• LANDMARK landmark (e.g. hydant) and 

position relative to the landmark.

Field: 

Geographic-

Values-

SubField 15

7.7.3 A fifteenth optional information item is 

the geographic coordinate other system

value / OCV. It shall only be present if OSI 

is present in the record. It can be up to

126 characters in length. If OSI is 

LANDMARK, OCV is free text and may be 

up to 126 characters. For details on the 

formatting of OCV for the other 

coordinate

systems shown in OSI as examples, see

http://earth-

info.nga.mil/GandG/coordsys/grids/refer

encesys.html

1D xx.998-

Geo-

Values-

Sub15

ForEach(Field ST FieldNumber(Field) EQ 998) {

Length(US_Subfield:15 in Field) LTE 126 }

t-7 B*

2D xx.998-

Geo-Cond-

OCV

ForEach(Field ST FieldNumber(Field) EQ 998) {

IF Present(US_Subfield:15 in Field) THEN

Present(US_Subfield:14 in Field) }

B*

Field: 

Impression-

Values

7.7.4.1,

Table 5,

8.4.3,

8.9.3,

8.13.3,

8.14.3,

8.15.3,

8.19.3

This field contains a code from Table 5 for 

how the friction ridge sample was 

collected. It has been expanded in this 

version of the standard to include 

plantars and unknowns.

M [4,9,13,14,

15,19].003-

IMP

<The test assertions for these types vary for this 

requirement, and therefore included under field 

testing for the specific Record Types.>

t-2

Field: FGP-

Values

7.7.4.2,

Table 6,

8.4.4,

8.9.5.9,

8.13.13,

8.14.13,

8.15.13,

8.19.13

This field is used in Record types dealing 

with friction ridges. It specifies which 

friction ridge biometric sample was 

collected. Note that for codes 1-40 and 

60-84, the Table 6 specifies 

recommended MAXIMUM width and 

height. (Individual implementation 

domains and application profiles may use 

different values.)

In previous versions of this standard, FGP 

was used for finger position, and PLP for 

palmprint position. They are now in one 

table, along with the codes added in the

ANSI/NIST-ITL 1a-2009 amendment. New 

to this version, plantar codes are included 

in the table. In order to cover all of these 

cases, the name was changed to friction 

ridge generalized position / FGP.

M 4.004,

9.134,

[13,14,15,1

9].013-FGP

<The test assertions for these types vary for this 

requirement, and therefore included under field 

testing for the specific Record Types.>

t-2

Field: PPD 

Conditional

7.7.4.3 For exemplar fingerprints contained in 

Type-14 records, if the impression is 

known to be an entire joint image (EJI), 

2D Type-14-

Cond-FGP-

PPD

Present(14.014) IFF Present(US_Subfield in 

14.013 ST {US_Subfield} EQ 19)

B*
40

full finger view (FFV), or extreme tip (TIP), 

then Field 14.013: Friction ridge 

generalized position / FGP shall be set to 

19, and Field 14.014: Print position 

descriptors / PPD shall be specified; Field 

14.015: Print position coordinates /PPC 

may be (optionally) specified.

AND

IF Present(14.015) THEN Present(US_Subfield in 

14.013 ST {US_Subfield} EQ 19)

Field: 

SPD,PPC 

Conditional

7.7.4.3 For latent prints contained in Type-13 

records, if all or part of the impression 

should be compared against the medial or 

proximal segments or the extreme tips, 

then Field 13.013: Friction ridge 

generalized position / FGP shall be set to 

19, and Field 13.014: Search position 

descriptors / SPD shall be specified; Field 

13.015: Print position coordinates / PPC 

may be (optionally) specified.

2D Type-13-

Cond-FGP-

SPD-PPC

Present(13.014) IFF Present(US_Subfield in 

13.013 ST {US_Subfield} EQ 19)

AND

IF Present(13.015) THEN Present(US_Subfield in 

13.013 ST {US_Subfield} EQ 19)

B*

Field: 

SPD,PPD 

Values

7.7.4.3,

Table 6,

Table7

The position descriptor, in Field 13.014: 

Search position descriptors / SPD or Field 

14.014: Print position descriptors / PPD 

contains two mandatory information 

items:

For a Type-13 record (latent prints), the 

first information item (probable decimal 

finger position code / PDF) (0-10, 16 or 

17) is taken from Table 6. A “0” indicates

that all the fingers of a possible candidate 

should be searched. For a Type-14 record

(known exemplars), the first information 

item is the friction ridge generalized

position / FGP. It is also taken from Table 

6 with a value of 1 to 10, inclusive or 16

or 17.

The second information item (finger 

image code / FIC) is the code taken from 

Table 7 to indicate the portion of the 

database to search. Full-length finger 

joint images use codes FV1 through FV4. 

Figure 2 is an illustration of the Entire 

Joint Image for a middle finger with each 

of the full finger views and constituent 

parts identified. Multiple portions of the 

EJI may be listed in a separate subfield.

1D 13.014-

Subfield 1-

PDF

ForEach(RS_Subfield in 13.014) {

{US_Subfield:1 in RS_Subfield} MO [0 to 10, 

16,17] }

B*

1D 14.014-

Subfield 1-

FGP

ForEach(RS_Subfield in 14.014) {

{US_Subfield:1 in RS_Subfield} MO [1 to 10, 

16,17] }

B*

1D [13,14].014 -Subfield 2-

FIC

ForEach(RS_Subfield in [13,14].014) {

{US_Subfield:2 in RS_Subfield} MO [ASCII( 

EJI,TIP,FV1,FV2,FV3,FV4,PRX,DST,MED)] }

B*

Field: PPC- 7.7.4.4, When used, Field 13.015: Print position 1O [13,14].015 Count(RS_Subfields in [13,14].015) MO [1 to 12] B*
41

Subfield 

Occurrences

Table7,

Table 66, 

Table 67

coordinates / PPC or Field 14.015: Print

position coordinates / PPC shall consist of 

six (6) mandatory information items 

describing the type or portion of the 

image contained in this record and its

location within an EJI... Individual full 

finger or segment definitions may be 

repeated as repeating sets of information 

items.

- PPC-

Subfield 

Occurrence s

AND

ForEach(RS_Subfield in [13,14].015) {

Count(US_Subfields in RS_Subfield) EQ 6 }

Field: PPC-

Subfield 1

7.7.4.4,

Table7,

Table 66, 

Table 67

The first information item is the full finger 

view / FVC with values of “FV1” through 

“FV4”. Values of “FV1” to “FV4” specify 

the perspective for each full finger view. 

For the case of a fingertip, the first 

information item shall be “TIP”. FVC will 

contain the code “NA” if only a proximal, 

distal or medial segment is available.

1M⇑[13,14].015 - FVCForEach(RS_Subfield in [13,14].015) {

{US_Subfield:1 in RS_Subfield} MO [ASCII(FV1, 

FV2, FV3, FV4, TIP, NA)] }

B*

Field: PPC-

Subfield 2

7.7.4.4,

Table7,

Table 66, 

Table 67

The second information item is used to 

identify the location of a segment / LOS 

within a full finger view. LOS will contain 

the not applicable code “NA” if the image 

portion refers to a full finger view, tip or 

to the entire joint image locations.

Otherwise, it shall contain “PRX”, “DST”, 

“MED” for a proximal, distal, or medial 

segment, respectively.

1M⇑[13,14].015 - LOSForEach(RS_Subfield in [13,14].015) {

{US_Subfield:2 in RS_Subfield} MO [ASCII( PRX, 

DST, MED, NA)] }

B*

Field: PPC-

Subfields 3,4

7.7.4.4,

Table7,

Table 66, 

Table 67

The third information item is the left 

horizontal coordinate / LHC. It is the 

horizontal offset in pixels to the left edge 

of the bounding box relative to the origin 

positioned in the upper left corner of the 

image.

The fourth information item is the right 

horizontal coordinate / RHC. It is the 

horizontal offset in pixels to the right 

edge of the bounding box relative to the 

origin positioned in the upper left corner 

of the image.

2M⇑13.015-

LHC,RHC

ForEach(RS_Subfield in 13.015) {

{US_Subfield:3,4 in RS_Subfield} GTE 1 AND LTE 

{13.006} }

B*

2M⇑14.015-

LHC,RHC

ForEach(RS_Subfield in 14.015) {

{US_Subfield:3,4 in RS_Subfield} GTE 1 AND LTE 

{14.006} }

B*

Field: PPC-

Subfields 5,6

7.7.4.4,

Table7,

Table 66, 

Table 67

The fifth information item is the top 

vertical coordinate / TVC is the vertical 

offset

(pixel counts down) to the top of the 

bounding box.

2M⇑13.015-

TVC,BVC

ForEach(RS_Subfield in 13.015) {

{US_Subfield:5,6 in RS_Subfield} GTE 1 AND LTE 

{13.007} }

B*
42

The sixth information item is the bottom 

vertical coordinate / BVC. It is the vertical 

offset from the upper left corner of the 

image down to the bottom of the

bounding box. It is counted in pixels.

2M⇑14.015-

TVC,BVC

ForEach(RS_Subfield in 14.015) {

{US_Subfield:5,6 in RS_Subfield} GTE 1 AND LTE 

{14.007} }

B*

Field: SAP 

Conditional

7.7.5,

8.10.13

SAP codes are mandatory in Type-10 

records with a face image, optional in 

Type-14 records, and optional in Type-17 

records...

The Subject Acquisition Profile (SAP) is a 

mandatory field when Field 10.003: Image 

type / IMT contains “FACE”. Otherwise, it 

shall not be entered.

2D 10.013-SAP 

Conditional

Present(10.013) IFF

{10.003} EQ ASCII (FACE)

B

Field: SAP 

Values

7.7.5.1,

Table 8

Field 10.013: Subject acquisition profile / 

SAP is used to indicate the SAP level code 

for face as indicated in Table 8. The SAP 

codes 32, 42 and 52 are new to this 

version of the standard.

1D 10.013-SAP 

Values

{10.013} MO [0,1,10-15,20,30,32,40,42,50-52]B

Field: SAP-

Level 

Requiremen

ts

7.7.5.1.1 

to 

7.7.5.1.1

0,

Table 9,

Annex E

<Sections 7.7.5.1.1 to 7.7.5.1.10 describe 

requirements for the image for various 

SAP Levels.>

3D 10.013-SAP 

Levels

<Not Tested. Determining the condition under 

which the image was captured to verify the SAP 

Level is not feasible at this time.> 

t-9

Field: FAP 

Values

7.7.5.2,

Table 10

The profile levels for fingerprint 

acquisition are optional and are based 

upon those listed in the Mobile ID Best 

Practice Recommendation. They are 

entered in Field 14.031:

Subject acquisition profile – fingerprint / 

FAP, which is new to this version of the 

standard.

1O 14.031-FAP 

Values

{14.031} MO [10,20,30,40,50,60]B

Field: FAP-

Level 

Requiremen

ts

7.7.5.2,

Table 10

<Section 7.7.5.2 and Table 10 describe 

requirements for the image for various 

FAP Levels.>

3O 14.031-SAP 

Levels

<Not Tested. Determining the condition under 

which the image was captured to verify the FAP 

Level is not feasible at this time.>

t-9

Field: IAP 

Values

7.7.5.3,

Table 71

The profile levels for iris acquisition, 

which are new to this version of the 

standard, are optional and are based 

upon those listed in the Mobile ID Best 

Practice Recommendation (BPR) (See 

Annex G: Bibliography) . They are entered 

in Field 17.031: Subject acquisition profile – iris / IAP.

1O 17.031-IAP 

Values

{17.031} MO [20,30,40]B

Field: IAP-

Level 

7.7.5.3 <Section 7.7.5.3 describes requirements 

for the image for various IAP Levels.>

3M 17.031-IAP 

Levels

<Not Tested. Determining the condition under 

which the image was captured to verify the IAP 

t-9
43

Requiremen

ts

Level is not feasible at this time.>

Field: 

Resolution 

Tolerance

7.7.6.1,

7.7.6.3,

Table 11

For Appendix F certified devices, 

resolution accuracy shall not vary more 

than 1% from the class resolution. A class 

resolution of 19.69 ppmm (500 ppi) has a 

lower bound of 19.49

ppmm (495ppi) and an upper bound of 

19.89 ppmm (505ppi).

For Personal

Identity Verification (PIV) certified devices 

with fingerprint subject application profile (FAP) Levels 10 to 40 only resolution 

accuracy shall not vary more than 2% 

from the class Resolution. For example, a 

class resolution of 19.69 ppmm (500 ppi) 

has a

lower bound of 19.30 ppmm (490ppi) and 

an upper bound of 20.08 ppmm (510ppi).

Tolerance requirements shall apply to the 

class and nominal resolution 

requirements throughout this document.

This transmitting resolution does not have 

to be the same as the scanning resolution.

However, the transmitting resolution shall

be within the range of permissible 

resolution values for that record type.

1M Field-

Resolution 

Tolerance

<This requirement specifies a tolerance for all 

resolution values expressed throughout the 

standard. If there is a resolution requirement for 

a type, the resolution must follow the 1% or 2% 

tolerance as described in the standard. This 

requirement will be applied to each applicable 

resolution requirement.>

t-2

Field: Image-

Coordinates

7.7.6.2 Each image formatted in accordance with 

this standard shall appear to have been 

captured in an upright position and 

approximately centered horizontally in 

the field of view...

3M Images-

Coordinate s

<Not directly tested, but this convention is used 

when testing for conformance in each of the 

assertions related to images>

t-2

Field: NSR 

Conditional

7.7.6.2.1,

Table 11

If Type-4 records are included in the 

transaction, Field 1.011 Native scanning 

resolution /

NSR contains five characters specifying 

the native scanning resolution in pixels 

per millimeter. It is expressed as two 

numeric characters followed by a decimal 

point and two more numeric characters 

(e.g. 19.69). This field is set to “00.00” if 

no Type-4 records are present in the 

transaction. With the deprecation of 

Record Types-3, 5 and 6, NSR only directly 

1M 1.011-NSR-

Length

Length(1.011) EQ 5B

1M 1.011-NSR-

Values

Bytes:1,2,4,5 in 1.011 MO [0 to 9] 

AND

Byte: 3 in 1.011 EQ “.”

B

2M 1.011-NSR-

Conditional

IF NOT Present(Record ST Type(Record) EQ 4) 

THEN

{1.011} EQ 00.00

T

2M NIEM-NSR-

Conditional

IF NOT 

Present(XElm(itl:PackageHighResolutionGrayScal

eImageRecord)) 

THEN

X
44

applies to Record Type-4 in this version of 

the standard. New to this version of the 

standard, NSR does not apply to Type-7 

records, unless specified as such by an 

implementation domain.

Record Type-14 shall be used if scanning a 

fingerprint image at the 1000 ppi class or 

above.

It can also be used for the 500 ppi 

class.Record Type-4 shall not be used for 

anything but the 500 ppi class. 

{XElm(biom:NativeScanningResolutionValue) in 

XElm(itl:PackageInformationRecord)} EQ 00.00

2M 1.011-NSR-

Type4 500 

ppi Only

{1.011} GTE 19.30 AND LTE 20.08B

Field: 

Exemplar 

Scan 

Resolution

7.7.6.2.1 Exemplar images shall have a minimum 

class scanning resolution of 500 ppi. The 

migration path to higher scanning 

resolutions for image capturing devices 

with a native scanning resolution of the 

500 ppi class shall be at a rate of 100% of 

the current native scanning resolution.

Capture devices with native scanning 

resolutions not in step with this migration 

path shall provide (through subsampling, 

scaling, or interpolating downward) a 

nominal resolution that matches the next 

lower interval in the migration path. For 

example,

a device with native scanning resolution 

of 47.24 ppmm (1200 ppi) shall provide a 

class

resolution of 39.37 ppmm (1000 ppi). The 

scanner resolution is specified for Record 

Types 14, 15, 16, 17, 19 and 20 using

Scanned horizontal pixel scale / SHPS (See 

Section 7.7.8.7) and Scanned vertical pixel

scale / SVPS (See Section 7.7.8.8). These 

Record Types can handle all resolutions, 

and are thus called variable-resolution 

image records.

2M Fields-

Exemplar 

Valid Scan 

Resolutions

<Scanning resolutions for Record Types 

14,15,16,17,19 and 20 must migrate at a rate of 

100% with a minimum of 500 ppi. These 

assertions are included under field testing for 

the specific Record Types.>

t-2

Field: Latent 

Resolution

7.7.6.2.2, 

7.7.6.1

Latent images should have a minimum 

class scanning resolution of 1000 ppi. 

Record Type-13 specifies resolution using 

Scanned horizontal pixel scale / SHPS (See 

Section 7.7.8.7) and Scanned vertical pixel 

scale / SVPS (See Section 7.7.8.8). Record 

Type-13 can handle all resolutions, and is 

thus called a variable-resolution image 

record.

2M Fields-

Latent 

Valid Scan 

Resolutions

IF {13.008} EQ 1 THEN

{13.016} AND {13.017} GTE 990

AND

IF {13.008} EQ 2 THEN

{13.016} AND {13.017} GTE 

390

B
45

..., resolution accuracy shall not vary more 

than 1% from the class resolution.

Field: 

Transmitting 

Resolution 

Required

7.7.6.3 Each image to be exchanged shall have a 

specific resolution associated with the 

transmitted data. This transmitting 

resolution does not have to be the same 

as the scanning resolution.

However, the transmitting resolution shall 

be within the range of permissible 

resolution values for that record type.

M Fields-Tx 

Resolution 

Required 

Type4 

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: Type4 

NTR

7.7.6.3.1 Field 1.012 Nominal resolution / NTR shall 

specify the transmitting resolution in 

pixels per millimeter. It is expressed as 

two numeric characters followed by a 

decimal point and two more numeric 

characters (e.g. 19.69). The transmitting 

resolution shall be within the

range 19.30 ppmm (490 ppi) to 20.08 

ppmm (510 ppi) for a Type-4 record . This 

range

reflects the 2% deviance from 500 ppi 

allowed for PIV certified devices. 

(SeeTable 11). For example, a sensor that 

scans natively at 508 ppi would list both 

NSR and NTR as 20 ppmm ( = 508 ppi). 

These images should not be sampled 

down to exactly 500 ppi. This field is set 

to “00.00” if no Type-4 records are 

present in the transaction. Given that the 

transmitting resolution shall not be 

greater than the scanning resolution, 

images meant for identification 

applications, such as those from Appendix 

F certified devices (See Table 11) are 

restricted to a 1% deviance from 500 ppi.

1M 1.012-NTR-

Length

Length(1.012) EQ 5B

1M 1.012-NTR-

Values

Bytes:1,2,4,5 in 1.012 MO [0 to 9] 

AND

Byte: 3 in 1.012 EQ “.”

B

2M 1.012-NTR-

Conditional

IF NOT Present(Record ST Type(Record) EQ 4) 

THEN

{1.012} EQ 00.00

T

2M NIEM-NTR-

Conditional

IF NOT 

Present(XElm(itl:PackageHighResolutionGrayScal

eImageRecord)) 

THEN

{XElm(biom:NominalTransmittingResolutionValu

e) in XElm(itl:PackageInformationRecord)} EQ 

00.00

X

2M 1.012-NTR 

500 ppi

{1.012} GTE 19.30 AND LTE 20.08B

2M 1.012-NTR 

LTE NSR

{1.012} LTE {1.011}B

Field: 

Variable 

Resolution 

THPS,TVPS

7.7.6.3.2 For variable-resolution friction ridge 

images (those in Record Types 13, 14, 15, 

19 and possibly in Record Types 16 and 

20), the transmitting resolution shall be at 

least as great as the class resolution of 

500 ppi. There is no upper limit on the 

variable-resolution rate for transmission. 

However, the transmitting resolution shall not be greater than the scanning 

resolution. For variable resolution 

records, the Transmitted horizontal pixel 

M Fields-

VarResoluti

on

<The test assertions are included under field 

testing for the respective record types.>

t-2
46

scale / THPS and the Transmitted vertical 

pixel scale / TVPS shall be specified. (See 

Section 7.7.8).

Field: 

Sample 

Quality 

Occurrences

7.7.7 Many of the Record Types contain 

optional quality metric information. In 

addition to thethree information items 

described here, the field may contain 

other information items. Each of the 

information items is contained in a set. 

Multiple sets of information items may be 

present, each indicating a different 

quality algorithm, up to a maximum of 9 

times. Fields using this structure are: -Field 9.135: M1 friction ridge quality data 

/ FQD -Field 9.316: EFS friction ridge quality 

metric / FQM -Field 10.024: Subject quality score / SQS -Field 13.024: Latent quality metric / LQM -Field 14.023: Segmentation quality 

metric / SQM -Field 14.024: Fingerprint quality metric / 

FQM -Field 15.024: Friction ridge quality metric 

/ FQM -Field 16.024: User

-defined image quality 

metric / FQM -Field 17.024: Image quality score / IQS -Field 19.024: Friction ridge - plantar print 

quality metric / FQM -Field 99.102: Biometric data quality / 

BDQ

1- Fields-

Sample 

Quality 

Subfield 

Occurrence s

ForEach( Field in 

[9.135,9.316,10.024,13.024,14.023,14.024,15.02

4,16.024,17.024,19.024, 99.102]) {

Count(RS_Subfields) LTE 9 }

B*

Field: 

Sample 

Quality 

Subfield 1

7.7.7 The first information item shall be a 

quantitative expression of the predicted 

matching performance of the biometric 

sample, which is a quality value / QVU. 

This information item shall contain the 

integer image quality score between 0 

and 100 (inclusive) assigned to the image 

data by a quality algorithm19. Higher 

values Partindicate better quality. An 

entry of “255” shall indicate a failed 

attempt to calculate a quality score. An 

entry of

“254” shall indicate that no attempt to 

calculate a quality score was made.

1- Fields-

Sample 

Quality 

QVU

ForEach( Field in 

[9.135,9.316,10.024, 16.024,17.024, 99.102]) {

ForEach(RS_Subfield in Field)

{

{US_Subfield:1 in RS_Subfield} MO [0 to 100, 

254,255] }}

AND

ForEach( Field in 

[13.024, 14.023, 14.024, 15.024, 19.024]) {

B*
47

ForEach(RS_Subfield in Field)

{

{US_Subfield:2 in RS_Subfield} MO [0 to 100, 

254,255]

}

}

Field: 

Sample 

Quality 

Subfield 2

7.7.7 A second information item shall specify 

the ID of the vendor of the quality 

algorithm used to calculate the quality 

score, which is an algorithm vendor 

identification / QAV. This 4-digit hex value 

(See Section 5.5 Character types) is 

assigned by IBIA and expressed as four 

characters. The IBIA maintains the Vendor 

Registry of CBEFF

Biometric Organizations that map the 

value in this field to a registered 

organization.

1 - FieldsSample 

Quality 

QAV

ForEach( Field in 

[9.135,9.316,10.024, 16.024,17.024, 99.102])

{

ForEach(RS_Subfield in Field)

{

{US_Subfield:2 in RS_Subfield} MO [IBIA Vendor 

Registry]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 4

AND

Bytes(US_Subfield:2 in RS_Subfield) MO [ASCII(A 

to F, 0 to 9)]

}

}

AND

ForEach( Field in 

[13.024, 14.023, 14.024, 15.024, 19.024])

ForEach(RS_Subfield in Field)

{

{US_Subfield:3 in RS_Subfield} MO [IBIA Vendor 

Registry]

AND

Length(US_Subfield:3 in RS_Subfield) EQ 4

AND

Bytes(US_Subfield:3 in RS_Subfield) MO [ASCII(A 

to F, 0 to 9)]

}

}

t-10 B*
48

Field: 

Sample 

Quality 

Subfield 3

7.7.7 A third information item shall specify a 

numeric product code assigned by the 

vendor of the quality algorithm, which 

may be registered with the IBIA, but 

registration is not required. This is the 

algorithm product identification / QAP 

that indicates which of the vendor’s 

algorithms was used in the calculation of 

the quality score. This information item 

contains the integer product code and 

should be within the range 1 to 65,534.

1- Fields-

Sample 

Quality 

QAP

ForEach( Field in 

[9.135,9.316,10.024,13.024,14.023,14.024,15.02

4,16.024,17.024,19.024, 99.102]) {

ForEach(RS_Subfield in Field) {

{US_Subfield:3 in RS_Subfield} MO [1 to 65,534] }}

AND

ForEach( Field in 

[13.024, 14.023, 14.024, 15.024, 19.024]) {

ForEach(RS_Subfield in Field) {

{US_Subfield:4 in RS_Subfield} MO [1 to 65,534] }}

B*

Field: 

Sample 

Quality 

Additional 

Subfield 

7.7.7,

8.13.19, 

Table 66,

8.14.22, 

8.14.23,

Table 67,

8.15.17,

Table69,

8.19.18

Table 80

In addition to thethree information items 

described here, the field may contain 

other information items.

1- ForEach(RS_Subfield in 13.024) {

{US_Subfield:1 in RS_Subfield)} MO [0 to 38, 40 

to 50, 60 to 79, 81 to 84] }

AND

ForEach(Field in [14.023,14.024]) {

ForEach(RS_Subfield in Field) {

{US_Subfield:1 in RS_Subfield} MO [1 to 10, 16, 

17] }}

AND

ForEach(RS_Subfield in 15.024) {

{US_Subfield:1 in RS_Subfield} MO [20 to 38, 81 

B*
49

to 84]

}

AND

ForEach(RS_Subfield in 19.024)

{

{US_Subfield:1 in RS_Subfield} MO [60 to 77]

}

Field: Image 

HLL Value

7.7.8.1 The number of pixels contained on a 

single horizontal line of the image. The 

maximum horizontal size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types. The 

minimum value is 10 pixels. 

1 M [4,8].006-

HLL

{[4,8].006} GTE 10 

AND LTE 65534

B

1 M 9.128-HLL {9.128} GTE 10 

AND LTE 99,999

B

1 M xx.006-HLL {[10,13 to 17,19,20].006} GTE 10 

AND LTE 99,999

B

Field: Image 

HLL 

Metadata

7.7.8.1 <HLL should be checked against the image 

metadata to test for conformance.>

M Fields-HLL 

Metadata

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: Image 

Size

7.7.8.1 The total image size (HLL times VLL) shall 

not that can be accommodated in Field 

xx.001 for Traditional encoding.

2 M xx.006,007-

Image Size

{[4,8,10,13 to 17,19,20].006} *

{[4,8,10,13 to 17,19,20].007}

LTE 

{[4,8,10,13 to 17,19,20].001}

B

2 M 9.128,129-

Image Size

{9.128} *{9.129} LTE {9.001} B

Field: Image 

VLL Value

7.7.8.2 The number of horizontal lines contained 

in the image. The maximum vertical size is 

limited to 65,534 pixels in Record Types-4 

and 8, and to 99,999 for other record 

types.

The minimum value is 10 pixels.

1 M [4,8].007-

VLL

{[4,8].007} GTE 10 

AND LTE 65,534

B

1 M xx.007-VLL {[10,13 to 17,19,20].007} GTE 10 

AND LTE 99,999

B

Field: Image 7.7.8.2 <VLL should be checked against the image M Fields-VLL <The test assertions are included under field t-2
50

VLL 

Metadata

metadata to test for conformance.> Metadata testing for the respective record types.>

Field: Image 

SLC Value

7.7.8.3,

Table 24, 

Table 53,

Table 66,

Table 71,

Table 80,

Table 81

The image sampling frequency (pixel 

density). 

<Tables related to each Record Type 

provide constraints on the value of SLC.>

1 M 9.130-SLC {9.130} MO [0,1,2] B

1 M xx.008-SLC {[10,13 to 17,19,20].008} MO [0,1,2] B

Field: Image 

SLC 

Metadata

7.7.8.3 A value of “1” shall indicate pixels per 

inch.

A value of “2” shall indicate pixels per 

centimeter. A value of “0” in this field 

indicates that no scale is provided, and 

the quotient of THPS/TVPS shall provide 

the pixel aspect ratio.

<SLC should be checked against the image 

metadata to test for conformance.>

M Fields-SLC 

Metadata

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: Image 

THPS Value

7.7.8.4,

Table 24, 

Table 53,

Table 66,

Table 71,

Table 80,

Table 81

<Tables related to each Record Type 

provide constraints on the value of 

THPS.>

1 M 9.131-THPS {9.131} GTE 1 AND LTE 99,999 B

1 M xx.009-

THPS

{[10,13 to 17,19,20].009} GTE 1 AND LTE 99,999 B

Field: Image 

THPS 

Metadata

7.7.8.4 This is the integer pixel density used in 

the horizontal direction of the image if 

SLC has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the horizontal component of the 

pixel aspect ratio, up to 5 digits.

<THPS should be checked against the 

image metadata to test for 

conformance.>

M Fields-THPS 

Metadata

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: Image 

TVPS Value

7.7.8.5,

Table 24, 

Table 53,

Table 66,

Table 71,

Table 80,

 Table 

<Tables related to each Record Type 

provide constraints on the value of TVPS.>

1 M 9.132-TVPS {9.132} GTE 1 AND LTE 99,999 B

1 M xx.010-

TVPS

{[10,13 to 17,19,20].010} GTE 1 AND LTE 99,999 B
51

81

Field: Image 

TVPS 

Metadata

7.7.8.5 This is the integer pixel density used in 

the vertical direction of the image if SLC 

has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the vertical component of the 

pixel aspect ratio, up to 5 digits.

<TVPS should be checked against the 

image metadata to test for 

conformance.>

M Fields-TVPS 

Metadata

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: Image 

BPX Value

7.7.8.6,

7.7.9

Some record types have a mandatory 

field Bits per pixel / BPX. This contains the 

number of bits used to represent a pixel. 

This field shall contain an entry of “8” for 

normal grayscale values of “0” to “255”. 

Any entry in this field greater than “8”

shall represent a grayscale pixel with 

increased proportion. A maximum of 2 

digits is allowed for this field.

Regardless of the compression algorithm 

used, the image shall be represented as 

an array of n rows by m columns by at 

least 8-bit pixels. Each pixel in a gray-scale 

image shall be represented by eight or 

more bits.

1M xx.012-BPX {[13 to 17,19,20].012} GTE 8 AND LTE 99B

Field: Image 

BPX 

Metadata

7.7.8.6 <BPX should be checked against the 

image metadata to test for 

conformance.>

M Fields-BPX 

Metadata

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: Image 

SHPS Value

7.7.8.7 The horizontal pixel density used for the 

scanning of the original image / 

impression providing that the SLC field 

contains a “1” or “2”. Otherwise, this shall 

indicate the horizontal component of the 

pixel aspect ratio, up to 4 digits. This field 

is used if the transmission pixel scale 

differs from the original image scale, as 

listed in Transmitted horizontal pixel scale 

/ THPS . Note that density is directly 

related to resolution.

1O xx.016-

SHPS

{[10,13,14,15,16,19].016} GTE 1 AND LTE 9,999B

1O 17.022 {17.022} GTE 1 AND LTE 9,999B

1O 20.017 {20.017} GTE 1 AND LTE 9,999B

Field: Image 

SVPS Value

7.7.8.8 The vertical pixel density used for the 

scanning of the original image / 

impression providing that the SLC field 

contains a “1” or “2”. Otherwise, this shall 

indicate the vertical component of the 

pixel aspect ratio, up to 4 digits. This field 

1O xx.017-

SVPS

{[10,13,14,15,16,19].017} GTE 1 AND LTE 9,999B

1O 17.023 {17.023} GTE 1 AND LTE 9,999B

1O 20.018 {20.018} GTE 1 AND LTE 9,999B
52

is used if the transmission pixel scale 

differs from the original image scale, as 

listed in Transmitted vertical pixel scale 

/TVPS . Note that density is directly 

related to resolution.

Field: Image 

Bit Depth 

Value

7.7.9 Regardless of the compression algorithm 

used, the image shall be represented as 

an array of n rows by m columns by at 

least 8-bit pixels. Each pixel in a gray-scale 

image shall be represented by eight or 

more bits. 

M Fields-

Image 

Compressio n

<See Requirement ID “Field: Image BPX Value”>t-2

Field: Image 

Format

7.7.9 Color images shall be represented as a 

series of sequential samples of a red, 

green, and blue intensity for each pixel. 

(Other color spaces are also possible. See 

Section 7.7.10.3). The image shall be 

organized in row-major order, with the 

lowest address corresponding to the 

upper left corner of the image. If the 

image is captured in grayscale, then only the luminance component shall be 

compressed and transmitted. 

3M Fields-

Image 

Format

<Not Tested. The actual image data is not tested; 

only metadata.>

t-1B

Field: Image 

JFIF

7.7.9 For JPEG, the data shall be formatted in 

accordance with the JPEG File Interchange 

Format, Version 1.02 (JFIF).

M Fields-

Image JFIF

<This requirement applies to all instances where 

a JPEG image format is used. The test assertions 

are included under field testing for the 

respective record types.>

t-2

Field: Image 

Compressio

n Algorithm 

Value

7.7.9.1,

Table 12

For each of these fields, the entry 

corresponds to the appropriate Label 

entry in Table 12: -Field 13.011: Compression algorithm / 

CGA -Field 14.011: Compression algorithm / 

CGA -Field 15.011: Compression algorithm / 

CGA -Field 16.011: Compression algorithm / 

CGA (when containing a friction ridge 

image) -Field 17.011: Compression algorithm / 

CGA -Field 19.011: Compression algorithm / 

CGA -Field 20.011: Compression algorithm 

/CGA (when containing a friction ridge 

image)

1M [13 to 

17,19,20].0

11

Values

{[13 to 17,19,20].011} MO [ASCII(NONE, WSQ20, 

JPEGB,JPEGL, JP2,JP2L,PNG)]

B

Field: Image 

Compressio

7.7.9.1 <CGA should be checked against the 

image metadata to test for 

M Fields-CGA 

Metadata

<The test assertions are included under field 

testing for the respective record types.>

t-2
53

n Algorithm 

Metadata

conformance.>

Field: Image 

WSQ 3.1

7.7.9.1 Only version 3.1 or higher shall be used 

for compressing grayscale fingerprint data 

at 500 ppi class with a platen area of 2 inches or greater in height. WSQ shall not 

be used for other than the 500 ppi class.

M Fields-

Image WSQ 

3.1 Only

<This requirement applies to all instances where 

the WSQ image format is used. The test 

assertions are included under field testing for 

the respective record types.>

t-2

Field: 

Type17 

Compressio n

7.7.9.2 For iris images, images may be 

uncompressed or compressed. The 

compression code shall

be one of the following, entered in Field 

17.011: Compression algorithm / CGA:

- NONE– An entry of “NONE” indicates 

that the data contained in this record is 

uncompressed. - PNG – This supports lossless 

compression. PNG is formally 

standardized (ISO/IEC

15444) and implementations are freely 

available25 (libpng). -JP2 and JP2L - As with other biometrics, 

while lossless compression is preferred,

iris images can be lossy-compressed. The 

image type (Field 17.032: Iris storage

format / ISF) should be selected 

appropriately, and the compression ratio 

should be set to satisfy some known 

quantified storage or transmission 

bandwidth limitation.

The baseline JPEG algorithm (ISO/IEC 

10918) is not acceptable for iris images 

and shall not be used. It has been shown 

that false match rates increase due to the 

presence of tiling artifacts. While JPEG 

was allowed in prior versions of this 

standard for iris compression, it is not 

allowed for this version. Implementers 

may want to support JPEG decoding for

handling legacy images.

1M 17.011-CGA {17.011} MO [ASCII(NONE, JP2,JP2L,PNG)]B

Field: 

Type10 

Compressio n

7.7.9.4 For non-facial images conveyed in Record 

Type-10, Field 10.011: Compression 

algorithm/ CGA may be set to any value in 

Table 12, except WSQ20. 

1M 10.011-CGA IF {10.003} NEQ ASCII(FACE)

THEN

{10.011} MO [ASCII(NONE, JPEGB,JPEGL, 

JP2,JP2L,PNG)]

t-98B

Field: 

Type16 

7.7.9.4 Non-friction ridge images contained in 

Record Type-16 shall specify the file 

M 16.011-CGA <The test assertions for this type may not be 

supported in this version of the CTM. If they are 

t-2
54

Compressio nextension (suffix) corresponding to the

compression used, such as OOG, JPG, 

WAV, and PNG in Field 16.011: 

Compression algorithm / CGA. A value of 

“NONE” indicates that the data is 

uncompressed.

supported, they are included under field testing 

for Record Type-16: User-defined testing image 

record. >

Field: Image 

CSP Value

7.7.10.3,

Table 13

Several image record types have a field 

Color space / CSP. It shall contain an entry 

from the CODE column of Table 13. If the 

color image type cannot be determined, 

an entry of

“RGB” shall be entered in this field.

1M 10.012-CSP {10.012} MO [ASCII(UNK, GRAY, RGB, SRGB, YCC, 

SYCC)]

B

1M xx.013-CSP {[16,17,20].013} MO [ASCII(UNK, GRAY, RGB, 

SRGB, YCC, SYCC)]

B

Field: Image 

ECL Value

7.7.11,

Table 14

This information appears in Field 10.027: 

Subject eye color / SEC and in Field 

17.020:

Eye color / ECL. The eye color describes 

the eye color of the subject as seen in the 

image.

If unusual or unnatural, such as is the case 

when colored contact lenses are present 

and the ‘real’ eye color cannot be 

ascertained, then the color shall be 

labeled as “XXX”. For near infra-red (NIR) 

images, if this field is entered, it shall be 

'XXX'. Values for these fields shall be the 

alphabetic entries in the “Attribute code” 

column of Table 14.

1- 10.027,17.0

20-

EyeColor

{10.027} AND {17.020} MO [ASCII(BLK, BLU, BRO, 

GRY,GRN,HAZ,MAR,MUL, PNK, XXX)]

B

Field: Image-

Paths

7.8 Several Record Types define open paths 

(also called contours or polylines) and / or 

closed paths (polygons) on an image...

An open path is a series of connected line 

segments that do not close or overlap. A 

closed path (polygon) completes a circuit. 

The closed path side defined by the last 

vertex and the first vertex shall complete 

the polygon. A polygon shall have at least 

3 vertices. The contours in Record Type-

17: Iris image record can be a circle or 

ellipse. A circle only requires 2 points to 

define it (See Table 16).

There are two different approaches to the 

paths in this standard. The 2007 and 2008 

version of the standard used paths for 

Field 14.025: Alternate finger segment 

position(s) / ASEG.

That approach has been retained in this 

version for all paths except in the 

- Fields-

Image-

Paths

<The test assertions are included under field 

testing for the respective record types.>

t-2
55

Extended Feature Set (EFS) of Record 

Type-9.

Field: ImageEFS Paths7.8.1,

Table 26

The vertices for paths in the EFS Type-9 

records are defined in a single 

information item27 for each of the 

following fields (See Table 26 Type-9 

Fields for EFS). If multiple paths are 

present, they are stored within separate 

subfields. Each vertex is expressed as an 

(X,Y) pair of positive integers in units of 10 

micrometers (0.01mm).

The Extended Feature Set used in the 

Record Type-9: Minutiae data record was 

developed as a separate encoding 

structure that has been incorporated into 

this standard. In order to avoid conflicts 

with systems that had already 

programmed using the EFS method of 

specifying paths, that structure is retained 

in this standard. EFS fields using closed 

paths, and requiring at least 3 vertices, 

are:

• Field 9.300: EFS region of interest / ROI

• Field 9.324: EFS distinctive features / 

DIS

• Field 9.357: EFS local quality issues / LQI

An open path is a series of connected 

points in which there is not an implicit 

connection between the last and first 

vertices. Within EFS, open paths are used 

in Field 9.373: EFS ridge path segments / 

RPS.

- FieldsImage-EFS 

Paths

<The test assertions are included under field 

testing for the respective record types.>

t-2

Field: ImageOther Paths7.8.2,

Tables 15 

to 18

The first information item is dependent 

upon the Record Type. The horizontal 

offsets (X) are the pixel counts to the 

right, and the vertical offsets (Y) are the 

pixel counts down from the origin.

- FieldsImageOther 

Paths

<The test assertions are included under field 

testing for the respective record types.>

t-2
56

Table C.4 - Assertions for Record Type 1- Transaction Information Record

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

XML, 

Trad,

Both

8.1: Record Type-1: Transaction Information Record

Transaction: 

Type1 

Mandatory

8.1 Record Type-1 is mandatory. Only one 

Type-1 record is present per transaction.

M Type1-

Mandatory

<See Requirement ID “Transaction: Type1-

Occurrences”>

t-2

Record: 

Type1-

Fields ASCII

8.1 All of the fields in the Type-1 record shall 

be recorded using the 7-bit ASCII code

M Type1-

Fields ASCII

<See Requirement ID “Record: Type1-ASCII”> t-2

Field: Type1-

Subfield 

Occurrence

Table 19 <Table 19 specifies which fields contain 

subfields as well as the number of 

occurrences permitted.>

1 M Type1-

Subfields 

Zero

Count(Subfields in 1.[001, 002, 004 to 006, 009 

to 012, 014]) EQ 0

B*

1 M 1.003-

Subfields

Count(RS_Subfields in 1.003 ) GTE 2

AND

Count(US_Subfields in 1.003 ) EQ 2 * 

Count(RS_Subfields in 1.003)

AND 

Count(RS_Subfields in 1.003) EQ 1 + 

{US_Subfield:2 in RS_Subfield:1 in 1.003}

B*

1 M 1.007-

Subfields

Count(US_Subfields in 1.007 ) EQ 1 OR 2 B*

1 M 1.008-

Subfields

Count(US_Subfields in 1.008 ) EQ 1 OR 2 B*

1 O 1.013-

Subfields

Count(US_Subfields in 1.013 ) EQ 1 OR 2 B*

1 O 1.015-

Subfields

Count(US_Subfields in 1.015 ) MO [1 to 3] B*

1 O 1.016-

Subfields

Count(RS_Subfields in 1.016) LTE 99

AND

Count(US_Subfields in 1.016 ) EQ 3 * 

Count(RS_Subfields in 1.016)

B*

Field: Type1- Table 19 <Table 19 specifies the Condition Code for 1 M Type1- Present(1.001 to 1.005, 1.007 to 1.009, 1.011, B
57

CondCode each field.> Mandatory 

CondCode

1.012)

Field: Type1-

CharType

Table 19 <Table 19 specifies the Character Type for 

each field.>

- Type1-Char 

Type

<See Requirement ID “Record: Type1-ASCII”> t-2

Field: Type1-

CharCount

Table 19 <Table 19 specifies the Character Count 

for each field that contains no subfields.>

1 M 1.001-

CharCount

DataLength(1.001) GTE 1 B

1 M 1.002-

CharCount

DataLength(1.002) EQ 4 B

1 M 1.004-

CharCount

DataLength(1.004) GTE 1 AND LTE 16 B

1 M 1.005-

CharCount

DataLength(1.005) EQ 8 B

1 O 1.006-

CharCount

DataLength(1.006) EQ 1 B

1 M 1.009-

CharCount

DataLength(1.009) GTE 1 B

1 O 1.010-

CharCount

DataLength(1.010) GTE 1 B

1 M 1.011-

CharCount

DataLength(1.011) EQ 5 B

1 M 1.012-

CharCount

DataLength(1.012) EQ 5 B

1 O 1.014-

CharCount

DataLength(1.014) EQ 15 B

Field: Type1-

Subfield 

CharCount

Table 19 <Table 19 specifies the Character Count 

for each subfield.>

1 M 1.003-

Subfield 

CharCount

Length(US_Subfield:1 in 1.003) EQ 1

AND

Length(US_Subfield:2 in 1.003) GTE 1 AND LTE 3

AND 

ForEach(RS_Subfield in 1.003 ST RS_Subfield 

NOT RS_Subfield:1 in 1.003)

{

Length(US_Subfield:1,2 in RS_Subfield) GTE 1 

AND LTE 2

}

B*

1 M 1.007-

Subfield 

CharCount

ForEach(US_Subfield in 1.007)

{

Length(US_Subfield) GTE 1 

}

B*

1 M 1.008-

Subfield 

ForEach(US_Subfield in 1.008)

{

B*
58

CharCount Length(US_Subfield) GTE 1 

}

1 O 1.013-

Subfield 

CharCount

ForEach(US_Subfield in 1.013)

{

Length(US_Subfield) GTE 1 

}

B*

1 O 1.015-

Subfield 

CharCount

Length(US_Subfield:1 in 1.015) GTE 1 AND LTE 3

AND

Length(US_Subfield:2,3 in 1.015) GTE 1 AND LTE 

16

B*

1 O 1.016-

Subfields

ForEach(RS_Subfield in 1.016)

{

Length(US_Subfield:1,2,3 in RS_SUbfield) GTE 1 

AND LTE 126

}

B*

Field: Type1-

Field 

Occurrence

Table 19 <Table 19 specifies the Field Occurrence 

for each field.>

1 M 1.001-

Occurrence

Count(1.001) EQ 1 B

1 M 1.002-

Occurrence

Count(1.002) EQ 1 B

1 M 1.003-

Occurrence

Count(1.003) EQ 1 B

1 M 1.004-

Occurrence

Count(1.004) EQ 1 B

1 M 1.005-

Occurrence

Count(1.005) EQ 1 B

1 O 1.006-

Occurrence

Count(1.006) LTE 1 B

1 M 1.007-

Occurrence

Count(1.007) EQ 1 B

1 M 1.008-

Occurrence

Count(1.008) EQ 1 B

1 M 1.009-

Occurrence

Count(1.009) EQ 1 B

1 O 1.010-

Occurrence

Count(1.010) LTE 1 B

1 M 1.011-

Occurrence

Count(1.011) EQ 1 B

1 M 1.012-

Occurrence

Count(1.012) EQ 1 B

1 O 1.013-

Occurrence

Count(1.013) LTE 1 B

1 O 1.014-

Occurrence

Count(1.014) LTE 1 B
59

1 O 1.015-

Occurrence

Count(1.015) LTE 1 B

1 O 1.016-

Occurrence

Count(1.016) LTE 1 B

Field: 1.001-

Record 

Header 

Value

8.1.1,

Table 19,

7.1

Field 1.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

2 M 1.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.1.1,

C.10.1

The XML name for the Type-1 record is 

<itl:PackageInformationRecord>, and its 

<biom:RecordCategoryCode> element 

shall have a value of 01.

1 M NIEM1.001-

Record 

Header

ForEach(XElm(itl:PackageInformationRecord )

{

{XElm(biom:RecordCategoryCode)} EQ ASCII(01)

}

X

Field: 1.002-

Version 

Number

Value

8.1.2,

Table 19

This mandatory four-character ASCII 

value shall be used to specify the current 

version number of the standard 

implemented by the software or system 

creating the transaction.

The format of this field shall consist of 

four numeric characters. The first two 

characters shall specify the major version 

number. The last two characters shall be 

used to specify the minor revision 

number. This version of the standard has 

the entry “0500”

1 M 1.002-VER {1.002} EQ ASCII(0500) B

Field: 1.003-

Transaction 

Content 

Subfields

8.1.3,

Table 19

This mandatory field shall list and identify 

each of the records in the transaction by 

record type and its IDC value. It also 

specifies the order in which the remaining 

records shall appear in the file. It shall 

consist of two or more subfields. The first 

subfield shall relate to this Type-1 

Transaction record.

M 1.003-

Subfields

<See Requirement ID “Field: Type1-Subfield 

Occurrence” and “Field: xx.002-IDC”>

t-2

Field: 1.003-

Transaction 

Content 

Subfield 1 

REC

Value

8.1.3,

Table 19

The first information item (record 

category code / REC) within this subfield 

shall be “1”. This indicates that the first 

record in the transaction is a Type-1 

record consisting of header information.

1 M 1.003-

Subfield1 

REC

{US_Subfield:1 in RS_Subfield:1 in 1.003} EQ 1 B*

Field: 1.003-

Transaction 

Content 

Subfield 1 

CRC

8.1.3,

Table 19

The second information item of this 

subfield (content record count / CRC) 

shall be the sum of the Type-2 through 

Type-99 records contained in this 

transaction. This number is also equal to 

2 M 1.003-

Subfield1 

CRC

{US_Subfield:2 in 1.003} 

EQ 

Count(Records in Transaction ST Type(Records) 

B*
60

Value the count of the remaining subfields of 

Field 1.003 Transaction content / CNT. 

The maximum value for CRC is 999.

MO [2 to 99]) 

EQ

Count(RS_Subfields in 1.003} -1

Field: 1.003-

Transaction 

Content 

Subfield 2 

REC

Value

8.1.3,

Table 19,

Table 1

Each of the remaining subfields of Field 

1.003 Transaction content / CNT 

corresponds to a single Type-2 through 

Type-99 record contained in the 

transaction. Two information items

shall comprise each of these subfields:

The first information item (record 

category code / REC), shall contain a

number chosen from the “record 

identifier” column of Table 1.

1M 1.003-

Subfield2 

REC

ForEach(RS_Subfield in 1.003 ST RS_Subfield

NOT RS_Subfield:1 in 1.003) {

{US_Subfield:1 in RS_Subfield} MO [2,4,7 to 10, 

13 to 21, 98,99]

AND

Present(Record in Transaction ST Type(Record) 

EQ {US_Subfield:1 in RS_Subfield} }

B*

Field: 1.003-

Transaction 

Content 

Subfield 2 

IDC

Value

8.1.3,

Table 19

The second information item (information 

designation character / IDC) shall be an 

integer equal to or greater than zero and 

less than or equal to 99. See

Section 7.3.1.

1M 1.003-

Subfield2 

IDC

ForEach(RS_Subfield in 1.003 ST NOT 

RS_Subfield:1 in 1.003) {

{US_Subfield:2 in RS_Subfield} MO [0 to 99] }

B*

Field: 1.003-

Transaction 

Content 

Subfield 2 

IDC Matches

8.1.3,

Table 19,

7.3.1

IDC references are stated in Type-1 Field

1.003 Transaction content / CNT and shall 

be used to relate information items in the 

CNT field of the Type-1 record to the 

other records in the transaction.

2M 1.003-

Subfield 2 

IDC 

Matches

ForEach(RS_Subfield in 1.003 ST NOT 

RS_Subfield:1 in 1.003) {

Present(Record ST Type(Record) EQ 

{US_Subfield:1 in RS_Subfield} AND Record.002 

EQ

{US_Subfield:2 in RS_Subfield} ) }

B*

Field: 1.004-

Type of 

Transaction

Value

8.1.4,

Table 19

This mandatory field shall contain an 

identifier, which designates the type of 

transaction and subsequent processing 

that this transaction should be given. This 

shall be a maximum of 16 alphabetic 

characters. The TOT shall be in 

accordance with definitions provided by 

the receiving agency.) Earlier versions of 

this standard specifically restricted the 

character length of TOT to 4 characters.

1M 1.004-TOT TRUEB

Field: 1.005-

Local Date

8.1.5,

Table 19,

This mandatory field shall contain the 

local date that the transaction was 

1M 1.005-DAT {1.005} MO [ValidLocalDate]t-6T

1M NIEM- ForEach(XElm(itl:PackageInformationRecord))t-6X
61

Value 7.7.2.3 submitted. The local date is recorded as 

YYYYMMDD. Note that this may be a 

different date than the corresponding 

GMT, due to time zone differences.

1.005-DAT{

{XElm(nc:Date) in XElm(biom:TransactionDate)} 

MO [NIEM-ValidLocalDate]

}

Field: 1.006-

Priority 

Value

8.1.6,

Table 19

This optional field shall contain a single 

information character to designate the 

urgency with which a response is desired. 

The values shall range from 1 to 9, with 1 

denoting the highest priority. The default 

value shall be defined by the agency 

receiving the transaction.

1O 1.006-PRY {1.006} MO [1 to 9]B

Field: 1.007-

Destination 

Agency 

Value

8.1.7,

Table 19

This mandatory field shall contain the 

identifier of the administration or 

organization designated to receive the 

transmission. The size and data content of 

this field shall be user-defined and in 

accordance with the receiving agency.

M 1.007-DES <See Requirement ID “Field: Agency Codes”>t-2

Field: 1.008-

Originating 

Agency

Value

8.1.8,

Table 19

This mandatory field shall contain the 

identifier of the administration or 

organization originating the transaction. 

The size and data content of this field 

shall be user-defined and in accordance 

with the receiving agency.

M 1.008-ORG <See Requirement ID “Field: Agency Codes”>t-2

Field: 1.009-

Transaction 

Control 

Number

Value

8.1.9,

Table 19

This mandatory field shall contain the 

transaction control number as assigned 

by the originating agency. A unique 

alphanumeric control number shall be 

assigned to each transaction. For any 

transaction that requires a response, the 

respondent shall refer to this number in 

communicating with the originating 

agency.

1M 1.009-TCN TRUEB

Field: 1.010-

Transaction 

Control 

Reference

Value

8.1.10,

Table 19

This optional field shall be used for 

responses that refer to the TCN of a 

previous transaction involving an inquiry 

or other action that required a response.

1O 1.010-TCR TRUEB

Field: 1.011-

Native 

Scanning 

Resolution

Value

8.1.11,

Table 19

This mandatory field shall be set to 

“00.00” if there are no Type-4 records in 

the transaction.

When there are Type-4 records present, 

this field is used to specify the native 

scanning resolution of the friction ridge 

image capture device. This field shall 

specify the resolution in pixels per 

millimeter. The resolution shall be 

expressed as two numeric characters 

M 1.011-NSR <See Requirement IDs “Field: NSR Conditional”.>t-2
62

followed by a decimal point and two 

more numeric characters.

Field: 1.012-

Nominal 

Resolution

Value

8.1.12,

Table 19

This mandatory field shall be set to 

“00.00” if there are no Type-4 records in 

the transaction.

When there are Type-4 records present, 

this field specifies the nominal resolution 

for the image(s) being exchanged. This 

field shall specify the resolution in pixels 

per millimeter.

The resolution shall be within the range 

19.30 ppmm (490 ppi) to 20.08 ppmm 

(510 ppi).

M 1.012-NTR <See Requirement ID“Field: Type4 NTR>t-2

Field: 1.013-

Domain 

Name

Value

8.1.13,

Table 19

The mandatory first information item (domain name / DNM) will uniquely 

identify the agency, entity, or 

implementation used for formatting the 

fields in the Type-2 record. The default 

value for the field shall be the North 

American Domain implementation 

(NORAM).

An optional second information item (domain version number / DVN) shall 

contain the unique version of the 

particular implementation, such as 7.02.

1O 1.013-DOM TRUE B*

Field: 1.013-

Domain 

Name

Occurs Once

8.1.13, The domain name may only appear once 

within a transaction. 

O 1.013-

DOM-

Occurs 

Once

<See Requirement ID “Field: Type1-Field 

Occurrence”>

t-2

Field: 1.014-

Greenwich 

Mean Time

Value

8.1.14,

Table 19

This optional field provides a mechanism 

for expressing the date and time in terms 

of universal Greenwich Mean Time (GMT) 

units.

1O 1.014-GMT {1.014} MO [ValidUTC/GMT]t-6T

1O NIEM-

1.014-GMT

ForEach(XElm(itl:PackageInformationRecord)) {

{XElm(nc:DateTime) in 

XElm(biom:TransactionUTCDate)} MO [NIEM-

ValidUTC/GMT] }

t-6X

Field: 1.015-

Character 

Encoding

Subfield 1 

CSI

Value

8.1.15,

Table 19,

Table 2

The first information item (character 

encoding index / CSI) is the three 

character identifier for the index number 

that references an associated character 

encoding. See the “Character encoding 

index” column of Table 2 for the valid 

values for this information item.

1M⇑1.015-DCS-

CSI

{US_Subfield:1 in 1.015} MO [0,2 to 4, 128 to 

999]

B*

Field: 1.015- 8.1.15, The second information item (character 2M 1.015-DCS- IF {US_Subfield:1 in 1.015} EQ 0 THEN B*
63

Character 

Encoding

Subfield 2 

CSN

Value

Table 19,

Table 2

encoding name / CSN) shall be the

“Character encoding name” associated 

with that index number, taken from

Table 2.

CSN {US_Subfield:2 in 1.015} EQ ASCII(ASCII)

AND

IF {US_Subfield:1 in 1.015} EQ 2 THEN

{US_Subfield:2 in 1.015} EQ ASCII(UTF-16)

AND

IF {US_Subfield:1 in 1.015} EQ 3 THEN

{US_Subfield :2in 1.015} EQ ASCII(UTF-8)

AND

IF {US_Subfield:1 in 1.015} EQ 4 THEN

{US_Subfield:2 in 1.015} EQ ASCII(UTF-32)

Field: 1.015-

Character 

Encoding

Subfield 3 

CSV

Value

8.1.15,

Table 19,

Table 2

The optional third information item 

(character encoding version / CSV) is the 

specific version of the character encoding 

used. In the case of the use of UTF-8, the 

third optional information item may be 

used to hold the specific version used, so 

that the display terminal can be switched 

to the correct font family.

1 O

⇑

1.015-DCSCSVTRUE B*

Field: 1.015-

Character 

Encoding

User 

Defined

This optional field specifies the character 

encoding that may appear within this 

transaction for data with the character 

type listed as “U” or 'user-defined' in the 

record format tables. 

3 O 1.015-DCSUser 

Defined 

Encoding

<Not Tested.> t-1, t-4 B

Field: 1.016-

Application 

Profile

Specification

s

Value

8.1.16,

Table 19

There may be multiple subfields, each 

designating an application profile to 

which this transaction conforms Each 

subfield shall consist of three mandatory 

information items:

The first information item (application 

profile organization / APO) will uniquely 

identify the agency or entity responsible 

for the specification.

The second information item (application 

profile name / APN) shall contain the 

name of the specification.

The third information item (application 

profile version number / APV) shall 

1 O 1.016-APS TRUE B*
64

contain the specific version of the 

specification.

Field: 1.016-

Application 

Profile

Specification

s

Compliance

8.1.16 If multiple Application Profile 

Specifications are included in this field, 

the specifications must be compatible 

with each other: this transaction must be 

in compliance with all of the cited 

specifications. See Section 6.

3 O 1.016 <Not Tested.> t-1, t-3 B
65

Table C.5 - Assertions for Record Type 3 - Deprecated

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.3: Record Type-3: DEPRECATED

Transaction: 

Type3 Zero 

Occurrences

8.3 No instances of Record Type-3 shall be 

included in a transaction conformant with 

this version of the standard.

2 M Type3-Zero 

Occurrence

s

ForEach(Record in Transaction)

{

Type(Record) NEQ 3

}

T

2 M NIEMType3-Zero 

Occurrence

s

<An invalid record type will cause a parsing error 

in XML because no Record Element Tag is 

defined (see Table 97).>

X
66

Table C.6 - Assertions for Record Type 4 - Grayscale Fingerprint Image

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.4: Record Type-4: Grayscale fingerprint image

Record: 

Type4 Scan 

Resolution 

500ppi 

8.4 The Type-4 record is based on the use of a 

captured fingerprint image obtained using 

a class scanning resolution of 500 ppi. 

(See Section 7.7.6). It shall not be used for 

other than 500 ppi. class images.

M Type4-Scan 

Resolution 

500ppi

<See Requirement ID “Field: Type4 NTR”> t-2

Record: 

Type4 Image 

Compressio

n WSQ

8.4 All images shall be compressed using 

WSQ.

M Type4-CGA 

WSQ Only

<See Requirement IDs “Field: 4.008-Compression 

Algorithm Value” and “Field: 4.009-Image Data 

Valid”>.

t-2

Field: Type4-

CondCode

Table 21,

Table 95

<Table 21 specifies the Condition Code for 

each field.>

1 M Type4-

Mandatory 

CondCode

Present(4.001 to 4.009) B

Field: Type4-

CharType

Table 21,

Table 95

Traditional format requires the data in 

binary form (not text) with a fixed byte 

length.

3 M Type4-Char 

Type

<Not tested directly, but Type 4 is parsed as 

unnumbered binary data for Traditional 

encoding>.

t-13 T

Field: Type4-

ByteCount

Table 21,

Table 95

<Table 95 specifies the Byte Count for 

each field.>

1 M 4.001-

ByteCount

Length(4.001) EQ 4 T

1 M NIEM4.001-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord))

{

Length(XElm(biom:RecordCategoryCode) EQ 2

}

X

1 M 4.002-

ByteCount

Length(4.002) EQ 1 T

1 M NIEM4.002-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord))

{

Length(XElm(nc:IdentificationID) in 

XElm(biom:ImageReferenceIdentification)) EQ 1 

OR 2

}

X

1 M 4.003-

ByteCount

Length(4.003) EQ 1 T

1 M NIEM4.003-ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord))

X
67

ByteCount{

Length(XElm(biom:FingerprintImageImpressionC

aptureCategoryCode)) EQ 1 OR 2 }

1M 4.004-

ByteCount

Length(4.004) EQ 6T

1M NIEM-

4.004-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord)) {

Length(All(XElm(biom:FingerPositionCode) in 

XElm(biom:FingerprintImagePosition))) MO [1 to 

3] }

X

1M 4.005-

ByteCount

Length(4.005) EQ 1T

1M NIEM-

4.005-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord)) {

Length(XElm(biom:CaptureResolutionCode) in 

XElm(biom:ImageCaptureDetail)) EQ 1 }

X

1M 4.006-

ByteCount

Length(4.006) EQ 2T

1M NIEM-

4.006-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord)) {

Length(XElm(biom:ImageHorizontalLineLengthPi

xelQuantity)) MO [2 to 5] }

X

1M 4.007-

ByteCount

Length(4.007) EQ 2T

1M NIEM-

4.007-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord)) {

Length(XElm(biom:ImageVerticalLineLengthPixel

Quantity)) MO [2 to 5] }

X

1M 4.008-

ByteCount

Length(4.008) EQ 1T

1M NIEM-

4.008-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord)) {

Length(XElm(biom:ImageCompressionAlgorithm

Code)) EQ 1 }

X

2M 4.009- Length(4.009) EQ {4.001} – 18T
68

ByteCount

1M NIEM-

4.009-

ByteCount

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord)) {

Length(XElm(nc:BinaryBase64Object)) GTE 1 }

X

Field: 4.001-

Record 

Header 

Value

8.4.1,

Table 21,

7.1

Field 4.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

M 4.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.4.1,

C.10.4

The XML name for the Type-4 recordis 

<itl:PackageHighResolutionGrayscaleImag

eRecord>, and its 

<biom:RecordCategoryCode> element 

shall

have a value of “04”.

1M NIEM-

4.001-

Record 

Header

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord ) {

{XElm(biom:RecordCategoryCode)} EQ ASCII(04) }

X

Field: 4.002-

Information 

Designation 

Character

Value

8.4.2,

Table 21,

7.3.1

This mandatory field shall be the IDC of 

this Type-4 record as found in the 

information item IDC of Field 1.003 

Transaction content/CNT. 

M 4.002-IDC <See Requirement IDs“Field: xx.002-IDC and 

“Field: 1.003-Transaction Content Subfield 2 IDC 

Matches”>

t-2

Field: 4.003-

Impression 

Type Value

8.4.3

Table 21,

7.7.4.1

This mandatory field shall indicate the 

manner by which the fingerprint was 

obtained. See Section 7.7.4.1 for details. 

1M 4.003-IMP {4.003} MO [0 to 3, 8, 20 to 29, 36 to 39]B

Field: 4.004-

Friction 

Ridge 

Generalized 

Position 

Value

8.4.4,

Table 21,

Table 6,

7.7.4.2

This mandatory field shall contain the 

decimal code number corresponding to 

the finger position and shall be taken 

from Table 6 (only finger numbers 0-10 

apply to Type-4). Up to five additional 

finger positions shall be referenced by 

entering the alternate finger positions 

using the same format. If fewer than five 

finger position references are to be used, 

the unused position references shall be 

filled with 255. Six values shall be entered

in each record.

1M 4.004-FGP Bytes(4.004) MO [0x00 to 0x0A, 0xFF]T

1M NIEM-

4.004-FGP

ForEach(XElm(itl:PackageHighResolutionGrayscal

eImageRecord ) {

{All(XElm(biom:FingerPositionCode) in 

XElm(biom:FingerprintImagePosition))} MO [0 to 

10, 255] }

X

Field: 4.005-

Image 

Scanning 

Resolution 

Value

8.4.5,

Table 21

The mandatory ISR field relates to the 

scanning resolution of this image. 

Previous versions of this standard stated 

that 0 in this field represents the 

'minimum scanning resolution.' The 

minimum scanning resolution was 

defined in ANSI/NIST-ITL 1-2007 as “19.69 

ppmm plus or minus 0.20 ppmm (500 ppi 

plus or minus 5 ppi).” Therefore, if the 

image scanning resolution corresponds to 

the Appendix F certification level (See 

2M 4.005-ISR IF {1.011} LTE 19.49 OR GTE 19.89 THEN {4.005} EQ 1 

ELSE

{4.005} EQ 0

B
69

Table

11 Class resolutions with maximum 

variance), a 0 shall be entered in this field.

A value of 1 is entered if the actual 

scanning resolution (outside of the 

Appendix F certification range) is 

specified in Field 1.011 Native scanning 

resolution / NSR.

Field: 4.006-

Horizontal 

Line Length

Value

8.4.6,

Table 21

This mandatory field shall contain the 

number of pixels on a single horizontal 

line of the transmitted image.

M 4.006-HLL <See Requirement ID “Field: Image HLL Value”>t-2

Field: 4.006-

Horizontal 

Line Length 

Metadata

8.4.6,

Table 21,

WSQ 

Standard

<The HLL is verified by checking the image 

metadata if compression is used. >

2M 4.006-HLL 

WSQ 

Metadata

IF {4.008} EQ 1 THEN

{4.006} EQ {Image Width-WSQ}

t-11B

Field: 4.007-

Vertical Line 

Length

Value

8.4.7,

Table 21

This mandatory field shall contain the 

number of pixels on a single horizontal 

line of the transmitted image.

M 4.007-VLL <See Requirement ID“Field: Image VLL Value”>

Field: 4.007-

Vertical Line 

Length 

Metadata

8.4.7,

Table 21

<The VLL is verified by checking the image 

metadata if compression is used.>

2M 4.007-VLL 

WSQ 

Metadata

IF {4.008} EQ 1 THEN

{4.007} EQ {Image Height-WSQ}

t-11B

Field: 4.008-

Compressio

n Algorithm 

Value

8.4, 

8.4.8,

Table 21

All images shall be compressed using 

WSQ. 

This is a mandatory field, used to specify 

the type of compression algorithm used. 

A zero denotes no compression. 

Otherwise, the contents shall be a 

number allocated to the particular 

compression technique used by the 

interchange parties. The specific code for 

each algorithm can be found in Table 12.

1M 4.008-CGA {4.008} EQ 0 OR 1t-98

Field: 4.008-

Compressio

n Algorithm 

Metadata

8.4.8,

Table 21

<The CGA is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2M 4.008-CGA 

WSQ 

Metadata

IF {4.008} EQ 1 THEN

Present(SOI-WSQ)

t-11B

Field: 4.009-

Image Data 

Valid

8.4.9 This is a mandatory field. Each pixel of the 

uncompressed grayscale image shall be 

quantized to eight bits (256 gray levels) 

contained in a single byte. For the 

exchange of an uncompressed binary 

image, eight pixels shall be left justified 

and packed into a single unsigned byte. 

The most significant bit of the byte shall 

2M 4.009-

DATA 

Uncompres

sed Valid

IF {4.008} EQ 0 THEN

Length(4.009) EQ {4.006} * {4.007}

B

2M 4.009-

DATA WSQ 

Valid

IF {4.008} EQ 1 THEN

Present(SOI-WSQ,SOF-WSQ,SOB-WSQ,EOI-WSQ)

t-11B
70

be the first of the eight pixels scanned. If 

compression is used, the pixel data shall 

be compressed in accordance with the 

compression technique specified in the 

Field 4.008: Compression algorithm /

CGA / BCA.

Field: 4.009-

Image WSQ 

Version 3.1

8.4.9,

7.7.9.1

Wavelet Scalar Quantization (WSQ) shall 

be used for compressing grayscale friction 

ridge data at 500 ppi class. Only version 

3.1 or higher shall be used for 

compressing grayscale fingerprint data at 

500 ppi class with a platen area of 2 

inches or greater in height. WSQ shall not 

be used for other than the 500 ppi class.

2 M 4.009-

DATA WSQ 

Version

IF {4.008} EQ 1 THEN

{Encoder Version } EQ 2

t-11 B
71

Table C.7 - Assertions for Record Type 5 - Deprecated

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.5: Record Type-5: DEPRECATED

Transaction: 

Type5 Zero 

Occurrences

8.5 No instances of Record Type-5 shall be 

included in a transaction conformant with 

this version of the standard.

2 M Type5-Zero 

Occurrence

s

ForEach(Record in Transaction)

{

Type(Record) NEQ 5

}

T

2 M NIEMType5-Zero 

Occurrence

s

<An invalid record type will cause a parsing error 

in XML because no Record Element Tag is 

defined (see Table 97).>

X

Table C.8 - Assertions for Record Type 6 - Deprecated

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.6: Record Type-6: DEPRECATED

Transaction: 

Type6 Zero 

Occurrences

8.6 No instances of Record Type-6 shall be 

included in a transaction conformant with 

this version of the standard.

2 M Type6-Zero 

Occurrence

s

ForEach(Record in Transaction)

{

Type(Record) NEQ 6

}

T

2 M NIEMType6-Zero 

Occurrence

s

<An invalid record type will cause a parsing error 

in XML because no Record Element Tag is 

defined (see Table 97).>

X
72

Table C.9 - Assertions for Record Type 10 - Facial, Other Body Parts & SMT Image Record

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.10: Record Type-10: Facial, other body part and SMT image record

Field: 

Type10-

Subfield 

Occurrence

Table 53 <Table 53 specifies which fields contain 

subfields as well as the number of 

occurrences permitted.>

1 M Type10-

Subfields 

Zero

Count(Subfields in 10.[001 to 003, 005 to 013, 

016, 017, 020, 021, 027, 030, 031, 038, 039, 903, 

996, 999]) EQ 0

T

1 M 10.004-

Subfields

Count(US_Subfields in 10.004) EQ 1 OR 2 T

1 D 10.014-

Subfields

Count(US_Subfields in 10.014 ) EQ 4 OR 5 T

1 D 10.018-

Subfields

Count(US_Subfields in 10.018 ) EQ 3 T

1 D 10.019-

Subfields

Count(US_Subfields in 10.019 ) MO [1 to 3] T

1 D 10.023-

Subfields

IF {US_Subfield:1 in 10.023} EQ ASCII(VENDOR) 

THEN 

Count(US_Subfields in 10.023 ) EQ 1 OR 2

ELSE

Count(US_Subfields in 10.023) EQ 1

T

1 D 10.024-

Subfields

Count(RS_Subfields in 10.024 ) MO [1 to 9]

AND

ForEach(RS_Subfield in 10.024)

{

Count(US_Subfields in RS_Subfield) EQ 3

}

T

1 D 10.025-

Subfields

Count(US_Subfields in 10.025 ) MO [3 to 6] T

1 D 10.026-

Subfields

Count(US_Subfields in 10.026) MO [1 to 50] T

1 D 10.028-

Subfields

Count(US_Subfields in 10.028 ) EQ 1 OR 2 T

1 D 10.029-

Subfields

Count(RS_Subfields in 10.029 ) MO [1 to 88]

AND

T
73

ForEach(RS_Subfield in 10.029) {

Count(US_Subfields in RS_Subfield) EQ 4 }

1D 10.032-

Subfields

Count(RS_Subfields in 10.032 ) MO [1 to 88]

AND

ForEach(RS_Subfield in 10.032) {

Count(US_Subfields in RS_Subfield) EQ 5 }

T

1D 10.033-

Subfields

Count(RS_Subfields in 10.033 ) MO [1 to 12]

AND

ForEach(RS_Subfield in 10.033) {

Count(US_Subfields in RS_Subfield) EQ 2 + 

2*{US_Subfield:2 in RS_Subfield} }

T

1D 10.040-

Subfields

Count(US_Subfields in 10.040) MO [1 to 3]T

1D 10.041-

Subfields

Count(US_Subfields in 10.041) EQ 2T

2D 10.042-

Subfields

Count(RS_Subfields in 10.042) MO [1 to 9]

AND

ForEach(RS_Subfield in 10.042) {

Present(US_Subfield:2,3 in RS_Subfield) 

IFF

{US_Subfield:1 in RS_Subfield} MO 

[ASCII(TATTOO, CHEMICAL, BRANDED, CUT)] 

THEN

AND

IF {US_Subfield:1 in RS_Subfield} MO 

[ASCII(TATTOO, CHEMICAL, BRANDED, CUT)] 

THEN

Count(US_Subfields in RS_Subfield) MO [3,4]

ELSE

Count(US_Subfields in RS_Subfield) EQ 1

T
74

}

2D 10.043-

Subfields

Count(RS_Subfields in 10.043) EQ 

Count(RS_Subfields in 10.042)

AND

ForEach(RS_Subfield in 10.043) {

Count(US_Subfields in RS_Subfield) MO [1 to 6] }

T

1O 10.044-

Subfields

Count(US_Subfields in 10.044) MO [1 to 18]T

2D 10.045-

Subfields

Count(RS_Subfields in 10.045 ) MO [1 to 16]

AND

ForEach(RS_Subfield in 10.045) {

Count(US_Subfields in RS_Subfield) EQ 3 + 2*{ 

US_Subfield:3 in RS_Subfield} }

T

1O 10.902-

Subfields

Count(RS_Subfields in 10.902 ) GTE 1

AND

ForEach(RS_Subfield in 10.902) {

Count(US_Subfields in RS_Subfield) EQ 4 }

T

1O 10.904-

Subfields

Count(US_Subfields in 10.904 ) EQ 3T

1O 10.995-

Subfields

Count(RS_Subfields in 10.995 ) MO [1 to 255]

AND

ForEach(RS_Subfield in 10.995) {

Count(US_Subfields in RS_Subfield) EQ 1 OR 2 }

T

1O 10.997-

Subfields

Count(RS_Subfields in 10.997 ) MO [1 to 255]

AND

ForEach(RS_Subfield in 10.997) {

T
75

Count(US_Subfields in RS_Subfield) EQ 1 OR 2 }

O 10.998-

Subfields

<See Requirement ID: “Field: Geographic-

Conditional”>

t-2

Field: 

Type10-

CondCode

Table 53<Table 53 specifies the Condition Code for 

each field.>

1M Type10-

CondCode

Present(10.001 to 10.012, 10.999)

AND

NOT Present(10.015,10.022, 10.034 to 

10.037,10.046 to 10.199, 10.901, 10.905 to 

10.994)

B

Field: 

10.013-SAP 

CondCode 

Dependent

Table 53,

8.10.13

The Subject Acquisition Profile (SAP) is a 

mandatory field when Field 10.003: Image

type / IMT contains “FACE”. Otherwise, it 

shall not be entered.

D 10.013-

CondCode 

Dependent

<See Requirement ID: “Field: SAP Conditional”>t-2

Field: 

10.014-FIP 

CondCode 

Dependent

Table 53,

8.10.14

If the face image (IMT = 'FACE') contains 

more than one face, or is not cropped to a 

“head only” or “head and shoulders” 

composition, this optional field contains 

offsets to the location of the bounding 

box of the face of the subject within a 

larger image. This field is only appropriate 

for images that do not comply with SAP 

Levels 30, 40, 50 or 51, because those 

images shall be cropped to a “head only” 

or “head and shoulders”composition.

2D 10.014-

CondCode 

Dependent

IF Present(10.014) THEN

{10.003} EQ ASCII(FACE)

AND

{10.013} NOT MO [30,40,50,51] 

B

Field: 

10.018-DIST 

CondCode 

Dependent

Table 53,

8.10.17

This optional field (which can be used 

only if IMT is 'FACE')...

2D 10.018-

CondCode 

Dependent

IF Present(10.018) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.019-LAF 

CondCode 

Dependent

Table 53,

8.10.18

This optional field ...is only applicable to 

face images (IMT = 'FACE').

2D 10.019-

CondCode 

Dependent

IF Present(10.019) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.020-POS 

CondCode 

Dependent

Table 53,

8.10.19

This optional field is to be used for the 

exchange of facial image data

2D 10.020-

CondCode 

Dependent

IF Present(10.020) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.021-POA 

CondCode 

Dependent

Table 53,

8.10.20

This shall only be used for the exchange 

of facial image data (IMT = 'FACE'). It may 

be used if Field 10.020: Subject pose / 

POS contains an “A” to indicate an angled 

pose of the subject. The field shall not be 

used if the entry in POS is an “F”, “R”, “L” 

2D 10.021-

CondCode 

Dependent

IF Present(10.021) THEN

{10.003} EQ ASCII(FACE)

AND

{10.020} EQ ASCII(A) 

B
76

or “D”.

Field: 

10.023-PAS 

CondCode 

Dependent

Table 53,

8.10.21

This field is mandatory if the SAP entry (Field 10.013: Subject acquisition profile / 

SAP) is “40” or greater for face image 

records. (IMT=FACE only).

2D 10.023-

CondCode 

Dependent

IF {10.013} GTE 40 THEN

Present(10.023)

B

Field: 

10.024-SQS 

CondCode 

Dependent

Table 53,

8.10.22

This optional field shall specify quality 

score data for facial images (IMT = 'FACE')

2D 10.024-

CondCode 

Dependent

IF Present(10.024) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.025-SPA 

CondCode 

Dependent

Table 53,

8.10.23

This field shall be present when Field 

10.020: Subject pose / POS contains a “D” 

to indicate a set of determined 3D pose 

angles of the same subject for a facial 

image (IMT = 'FACE'). If the entry in POS is 

an “F”, “L”, “R” or “D”, this field shall not 

be used

2D 10.025-

CondCode 

Dependent

IF Present(10.025) THEN

{10.003} EQ ASCII(FACE)

AND

{10.020} EQ ASCII(D) 

B

Field: 

10.026-SXS 

CondCode 

Dependent

Table 53,

8.10.24

This field is mandatory if the SAP entry for 

a facial image (Field 10.013: Subject 

acquisition profile / SAP) is 40, 50 or 51. 

(IMT=FACE only). In other cases, this field 

is optional for facial images.

2D 10.026-

CondCode 

Dependent

IF {10.013} MO [40,50,51] 

AND {10.003} EQ ASCII(FACE)

THEN

Present(10.026)

B

Field: 

10.027-SEC 

CondCode 

Dependent

Table 53,

8.10.25

This field is mandatory if the SAP entry (Field 10.013: Subject acquisition profile / 

SAP) is “40” or greater. For other facial 

images (IMT = 'FACE'), the field is 

optional.

2D 10.027-

CondCode 

Dependent

IF {10.013} GTE 40 

AND {10.003} EQ ASCII(FACE)

THEN

Present(10.027)

B

Field: 

10.028-SHC 

CondCode 

Dependent

Table 53,

8.10.26

This field is mandatory if the SAP entry (Field 10.013: Subject acquisition profile / 

SAP) is “40” or greater. For other facial 

image s(IMT = 'FACE'), it is optional.

2D 10.028-

CondCode 

Dependent

IF {10.013} GTE 40 

AND {10.003} EQ ASCII(FACE)

THEN

Present(10.028)

B

Field: 

10.029-FFP 

CondCode 

Dependent

Table 53,

8.10.27

The optional field shall be used for the 

exchange of facial image data (IMT = 

'FACE') feature points or landmarks.

2D 10.029-

CondCode 

Dependent

IF Present(10.029) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.031-TMC 

CondCode 

Dependent

Table 53,

8.10.29

This optional field describes the specific 

facial (IMT = 'FACE') feature points

2D 10.031-

CondCode 

Dependent

IF Present(10.031) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.032-3DF 

CondCode 

Dependent

Table 53,

8.10.30

The optional field shall describe ...facial 

feature points of the captured facial 

image(IMT = 'FACE').

2D 10.032-

CondCode

Dependent

IF Present(10.032) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

10.033-FEC 

CondCode 

Table 53,

8.10.31,

8.10.29

...refers to a specific contour on the face (IMT = 'FACE')2D 10.033-

CondCode Dependent

IF Present(10.033) THEN

{10.003} EQ ASCII(FACE) AND {10.031} EQ 5

B
77

Dependent Field 10.031: This optional field describes 

the specific facial (IMT= ‘FACE’) feature 

points contained in Field 10.029: 2d Facial 

feature points/ FFP and if level 5, 

contours shall be contained in Field 

10.033: Feature contours/ FEC. 

Field: 

10.039-T10 

CondCode 

Dependent

Table 53,

8.10.33

This field shall

not be used if there are no multiple 

images of the same SMT or body part in 

the transaction

2D 10.039-

CondCode 

Dependent

IF Present(10.039) THEN

Count(Records ST Type(Record) EQ 10) GTE 2

T

2M NIEM- T10-

CondCode 

Dependent

IF 

Present(XElm(biom:PhysicalFeatureReferenceIde

ntification)

THEN

Count(XElm(itl:PackageFacialAndSMTImageReco

rd)) GTE 2

X

Field: 

10.040-SMT 

CondCode 

Dependent

Table 53,

8.10.34

This field shall be used only when Field 

10.003: Image type / IMT = “SCAR”, 

“MARK”, or “TATTOO”. It is not used for 

other images

2D 10.040-

CondCode 

Dependent

IF Present(10.040) THEN

{1.003} MO [ASCII(SCAR,MARK,TATTOO)]

B

Field: 

10.041-SMS 

CondCode 

Dependent

Table 53,

8.10.35

This field shall be used only when Field 

10.003: Image type / IMT =“SCAR”, 

“MARK”, or “TATTOO”.

2D 10.041-

CondCode 

Dependent

IF Present(10.041) THEN

{1.003} MO [ASCII(SCAR,MARK,TATTOO)]

B

Field: 

10.042-SMD 

CondCode 

Dependent

Table 53,

8.10.36

This field shall be used only when Field 

10.003: Image type /IMT = “SCAR”, 

“MARK”, or “TATTOO”.

2D 10.042-

CondCode 

Dependent

IF Present(10.042) THEN

{1.003} MO [ASCII(SCAR,MARK,TATTOO)]

B

Field: 

10.043-COL 

CondCode 

Dependent

Table 53,

8.10.37

This optional field shall contain one 

subfield corresponding to each subfield 

contained in

Field 10.042: SMT descriptors / SMD

2D 10.043-

CondCode 

Dependent

IF Present(10.043) THEN

Present(10.042)

B

Field: 

10.045-OCC 

CondCode 

Dependent

Table 53,

8.10.37

This optional field defines ...the image of 

the face (IMT = 'FACE').

2D 10.045-

CondCode 

Dependent

IF Present(10.045) THEN

{10.003} EQ ASCII(FACE)

B

Field: 

Type10-

CharType

8.10,

Table 53

<Table 53 specifies the Character Type for 

each field that contains no subfields. Note 

that even though some Character Types 

are listed as U (user defined), they may 

still have character type limitations 

defined in the standard text. >

1- Type10-

CharType N

Bytes(10.[001,002,005 to 010, 

013,016,017,031,039]) MO [0x30 to 0x39]

B

1- Type10-

CharType A

Bytes(10.[011,012,020,027,030]) MO [0x41 to 

0x5A, 0x61 to 0x7A]

B

1- Type10-

CharType U

Present(Bytes(10.042) 

AND

{10.026} MO[0x41 to 0x5A, 0x61 to 0x7A]

B

1M 10.003-

CharType 

AS

Bytes(10.003) MO [0x2D, 0x41 to 0x5A, 0x61 to 

0x7A]

B

1D 10.021- Bytes(10.021) MO [0x2B,0x2D,0x30 to 0x39]B
78

CharType 

NS

1D 10.025-

CharType 

N_US

Bytes(10.025) MO [0x1F, 0x2B, 0x2D, 0x30 to 

0x39]

B

1O 10.038-

CharType 

Text ANS

Bytes(10.038) MO [0x20, 0x7E]B

1O 10.903-

CharType 

Text ANS

Bytes(10.903) MO [0x20, 0x7E]B

1O 10.996-

CharType H

Bytes(10.996) MO [0x30 to 0x39,0x41 to 0x46, 

0x61 to 0x66]

B

1M 10.999-

CharType B

Present(Bytes(10.999))B

Field: 

Type10-

Subfield

CharType

<Table 53 specifies the Character Type for 

each subfield.>

1M 10.004-

Subfield 

CharType U

Present(Bytes(US_Subfields:1,2 in 10.004) B*

1D 10.014-

Subfield 

CharType 

AN

Bytes(US_Subfields:1 to 4 in 10.014) MO [0x30 to 

0x39]

AND

Bytes(US_Subfields:5 in 10.014) MO [0x41 to 

0x5A, 0x61 to 0x7A]

B*

1M 10.018-

Subfield 

CharType A

Bytes(All(US_Subfields in 10.018)) MO [0x41 to 

0x5A, 0x61 to 0x7A]

B*

1D 10.019-

Subfield 

CharType A

Bytes(All(US_Subfields in 10.019)) MO [0x41 to 

0x5A, 0x61 to 0x7A]

B*

1D 10.023-

Subfield 

CharType 

ASU

Bytes(US_Subfields:1 in 10.023) MO [0x30, 0x32, 

0x41 to 0x5A, 0x61 to 0x7A]

AND

Present(Bytes(US_Subfields:2 in 10.023))

B*

1D 10.024-

Subfield 

CharType 

NH

ForEach(RS_Subfield in 10.024) {

Bytes(US_Subfields:1,3 in RS_Subfield) MO [0x30 

to 0x39]

AND

Bytes(US_Subfields:2 in RS_Subfield) MO [0x30 

to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1D 10.026-

Subfield 

CharType U-A

Bytes(All(US_Subfields in 10.018)) MO [0x41 to 

0x5A, 0x61 to 0x7A]

B*

1D 10.028- Bytes(All(US_Subfields in 10.028)) MO [0x41 to B*
79

Subfield 

CharType A

0x5A, 0x61 to 0x7A]

1D 10.029-

Subfield 

CharType 

ANS

ForEach(RS_Subfield in 10.029) {

Bytes(US_Subfields:1,3,4 in RS_Subfield) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:2 in RS_Subfield) MO [0x2E, 

0x30 to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1D 10.032-

Subfield 

CharType 

ANS

ForEach(RS_Subfield in 10.032) {

Bytes(US_Subfields:1,3,4 in RS_Subfield) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:2 in RS_Subfield) MO [0x2E, 

0x30 to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1D 10.033-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 10.033) {

Bytes(US_Subfield:1 in RS_Subfield) MO [0x41 to 

0x5A, 0x61 to 0x7A]

AND

Bytes(US_Subfield:2 in RS_Subfield) MO [0x30 to 

0x39]

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Bytes(US_Subfield) MO [0x30 to 0x39] }}

B*

1D 10.040-

Subfield 

CharType 

AN

Bytes(All(US_Subfields in 10.040)) MO [0x30 to 

0x39, 0x41 to 0x5A, 0x61 to 0x7A]

B*

1D 10.041-

Subfield 

CharType N

Bytes(All(US_Subfields in 10.041)) MO [0x30 to 

0x39]

B*

1D 10.042-

Subfield 

CharType 

AU

ForEach(RS_Subfield in 10.042) {

Bytes(US_Subfields:1 to 3 in RS_Subfield) MO 

[0x41 to 0x46, 0x61 to 0x66]

AND

Present(Bytes(US_Subfields:4 in RS_Subfield) ) }

B*

1D 10.043- Bytes(All(US_Subfields in 10.043)) MO [0x41 to B*
80

Subfield 

CharType A

0x46, 0x61 to 0x66]

1O 10.044-

Subfield 

CharType

Bytes(All(US_Subfields in 10.044)) MO [0x41 to 

0x46, 0x61 to 0x66]

B*

1D 10.045-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 10.045) {

Bytes(US_Subfields:1,2 in RS_Subfield) MO [0x41 

to 0x5A, 0x61 to 0x7A]

AND

Bytes(US_Subfield:3 in RS_Subfield)) MO [0x30 

to 0x39]

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Bytes(US_Subfield) MO [0x30 to 0x39] }}

B*

1O 10.902-

Subfield 

CharType U

ForEach(RS_Subfield in 10.902) {

Present(Bytes(US_Subfields:2 to 4 in 

RS_Subfield)) 

AND

Bytes(US_Subfield:1 in RS_Subfield) MO [0x30 to 

0x39,0x5A] }

B*

1O 10.904-

Subfield 

CharType U

Present(Bytes(All(US_Subfields in 10.904))) B*

1O 10.995-

Subfield 

CharType N

Bytes(All(US_Subfields in 10.995)) MO [0x30 to 

0x39]

B*

1O 10.997-

Subfield 

CharType N

Bytes(All(US_Subfields in 10.997)) MO [0x30 to 

0x39]

B*

O 10.998-

Subfield 

CharType 

ANSU

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type10-

CharCount

Table 53<Table 53 specifies the Character Count 

for each field that contains no subfields.>

1M 10.001-

CharCount

DataLength(10.001) GTE 1B

1M 10.002-

CharCount

DataLength(10.002) EQ 1 OR 2B

1M 10.003-

CharCount

DataLength(10.003) MO [1 to 11]B
81

1M 10.005-

CharCount

DataLength(10.005) EQ 8B

1M 10.006-

CharCount

DataLength(10.006) MO [2 to 5]B

1M 10.007-

CharCount

DataLength(10.007) MO [2 to 5]B

1M 10.008-

CharCount

DataLength(10.008) EQ 1B

1M 10.009-

CharCount

DataLength(10.009) MO [1 to 5]B

1M 10.010-

CharCount

DataLength(10.010) MO [1 to 5]B

1M 10.011-

CharCount

DataLength(10.011) MO [3 to 5]B

1M 10.012-

CharCount

DataLength(10.012) MO [3 to 4]B

1D 10.013-

CharCount

DataLength(10.013) MO [1 to 3]B

1O 10.016-

CharCount

DataLength(10.016) MO [1 to 4]B

1O 10.017-

CharCount

DataLength(10.017) MO [1 to 4]B

1D 10.019-

CharCount

DataLength(10.019) MO [1 to 3]B

1D 10.020-

CharCount

DataLength(10.020) EQ 1B

1D 10.021-

CharCount

DataLength(10.021) MO [1 to 4]B

1D 10.027-

CharCount

DataLength(10.027) EQ 3B

1O 10.030-

CharCount

DataLength(10.030) MO [7 to 10]B

1D 10.031-

CharCount

DataLength(10.031) MO [1 to 3]B

1O 10.038-

CharCount

DataLength(10.038) MO [1 to 126]B

1D 10.039-

CharCount

DataLength(10.039) MO [1 to 3]B

1O 10.903-

CharCount

DataLength(10.903) MO [13 to 16]B

1O 10.996-

CharCount

DataLength(10.996) EQ 64B

O 10.998- <See Requirement ID: “Field: Geographic”>t-2
82

CharCount

Field: 

Type10-

Subfield 

CharCount

Table 53<Table 53 specifies the Character Count 

for each subfield.>

1M 10.004-

Subfield 

CharCount

Length(All(US_Subfields in 10.004)) GTE 1 B*

1D 10.014-

Subfield 

CharCount

Length(US_Subfield:1 to 4 in 10.014) MO [1 to 5]

AND

Length(US_Subfield:5 in 10.014) EQ 1

B*

1D 10.018-

Subfield 

CharCount

Length(US_Subfield:1 in 10.018) MO [6 to 10]

AND

Length(US_Subfield:2 in 10.018) EQ 1

AND

Length(Last(US_Subfield in 10.018)) MO [4 to 8]

B*

1D 10.019-

Subfield 

CharCount

Length(All(US_Subfields in 10.019) EQ 1 B*

1D 10.023-

Subfield 

CharCount

Length(US_Subfield:1 in 10.023) MO [6 to 13]

AND

Length(US_Subfield:2 in 10.023) MO [1 to 64]

B*

1D 10.024-

Subfield 

CharCount

ForEach(RS_Subfield in 10.024) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 4

AND

Length(Last(US_Subfield in RS_Subfield)) MO [1 

to 5] }

B*

1D 10.026-

Subfield 

CharCount

Length(All(US_Subfields in 10.026)) MO [3 to 20] B*

1D 10.028-

Subfield 

CharCount

Length(All(US_Subfields in 10.028)) EQ 3 B*

1D 10.029-

Subfield 

CharCount

ForEach(RS_Subfield in 10.029) {

Length(US_Subfield:1 in RS_Subfield) EQ 1

AND

Length(US_Subfield:2 in RS_Subfield) MO [3 to 5]

AND

Length(US_Subfields:3,4 in RS_Subfield)) MO [1 

to 5] }

B*

1D 10.032-

Subfield 

CharCount

ForEach(RS_Subfield in 10.032) {

Length(US_Subfield:1 in RS_Subfield) EQ 1

B*
83

AND

Length(US_Subfield:2 in RS_Subfield) MO [3, 4]

AND

Length(US_Subfields:3 to 5 in RS_Subfield)) MO 

[1 to 5] }

1D 10.033-

Subfield 

CharCount

ForEach(RS_Subfield in 10.033) {

Length(US_Subfield:1 in RS_Subfield) MO [4 to 

14]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1D 10.040-

Subfield 

CharCount

Length(All(US_Subfields in 10.040)) MO [3 to 10] B*

1D 10.041-

Subfield 

CharCount

Length(US_Subfields:1,2 in 10.041)) MO [1 to 3] B*

1D 10.042-

Subfield 

CharCount

ForEach(RS_Subfield in 10.042) {

Length(US_Subfield:1 in RS_Subfield) MO [3 to 

20]

AND

Length(US_Subfield:2 in RS_Subfield) MO [4 to 8]

AND

Length(US_Subfield:3 in RS_Subfield)) MO [3 to 

9]

AND

Length(US_Subfield:4 in RS_Subfield)) MO [1 to 

256] }

B*

1D 10.043-

Subfield 

CharCount

Length(All(US_Subfields in 10.043)) MO [3 to 7] B*

1O 10.044-

Subfield 

CharCount

Length(All(US_Subfields in 10.044)) MO [3 to 11] B*

1D 10.045-

Subfield 

CharCount

ForEach(RS_Subfield in 10.045) {

Length(US_Subfield:1,2 in RS_Subfield) EQ 1

B*
84

AND

Length(US_Subfield:3 in RS_Subfield) EQ 1 OR 2

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

1O 10.902-

Subfield 

CharCount

ForEach(RS_Subfield in 10.902) {

Length(US_Subfield:1 in RS_Subfield) EQ 15

AND

Length(US_Subfields:2,3 in RS_Subfield) MO [1 

to 64]

AND

Length(US_Subfield:4 in RS_Subfield)) MO [1 to 

255] }

B*

1O 10.904-

Subfield 

CharCount

Length(All(US_Subfields in 10.904)) MO [1 to 50] B*

1O 10.995-

Subfield 

CharCount

ForEach(RS_Subfield in 10.995) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

1O 10.997-

Subfield 

CharCount

ForEach(RS_Subfield in 10.997) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

O 10.998-

Subfield 

CharCount

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type10-Field 

Occurrence

Table 53<Table 53 specifies the Field Occurrence 

for each field.>

12- Type10-

Occurrence 

Zero

Count(10.[015 ,022, 046 to 199,901,905 to 994]) 

EQ 0

B

1M Type10-

Occurrence 

One

Count(10.[001 to 012, 999]) EQ 1B

1- Type10-

Occurrence 

One or 

Count(10.[013,014,016 to 021,023 to 033,038 to 

045, 902 to 904, 995 to 998) LTE 1

B
85

Fewer

Field: 

10.001-

Record 

Header 

Value

8.10.1,

Table 53,

7.1

Field 10.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

M 10.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.10.1,

C.10.8

The XML name for the Type-10 recordis 

<itl:PackageFacialAndSMTImageRecord>, 

and its <biom:RecordCategoryCode> 

element shall

have a value of “10”.

1M NIEM-

10.001-

Record 

Header

ForEach(itl:PackageFacialAndSMTImageRecord) {

{XElm(biom:RecordCategoryCode)} EQ ASCII(10) }

X

Field: 

10.002-

Information 

Designation 

Character

Value

8.10.2,

Table 53,

7.3.1

This mandatory field shall be the IDC of 

this Type-10 record as found in the 

information item IDC of Field 1.003 

Transaction content/CNT. 

M 10.002-IDC <See Requirement IDs“Field:

xx.002-IDC and “Field: 1.003-Transaction 

Content Subfield 2 IDC Matches”>

t-2

Field: 

10.003-

Image Type 

Value

8.10.3,

Table 53,

Table 54

This mandatory field shall be used to 

indicate the type of image contained in 

this record. It shall contain a character 

string from the “Image Code” column of 

Table 54: Type-10 image types to indicate 

the appropriate image type. 

1M 10.003-IMT {10.003} MO 

[ASCII(SCAR,TATTOO,FACE,MARK,FRONTAL-

C,REAR-C,FRONTAL-N,REAR-N,TORSO-

BACK,TORSO-

FRONT,CONDITION,MISSING,OTHER,CHEST,FEET,

HANDS-PALM,HANDS-

BACK,GENITALS,BUTTOCKS,RIGHT LEG, LEFT LEG, 

RIGHT ARM, LEFT ARM)]

t-1B

Field: 

10.004-

Originating 

Agency 

Value

8.10.4,

7.6

The data content of this field is defined by 

the user and shall be in accordance with 

the receiving agency.

M 10.004-

ORG

<See Requirement ID “Field: Agency Codes”>t-2

Field: 

10.005-

Photo 

Capture 

Date Value

8.10.5,

7.7.2.3

This mandatory field shall contain the 

date that the image contained in the 

record was captured.

1M 10.005-PCD {10.005} MO [ValidLocalDate]t-6T

1M NIEM-

10.005-PCD

ForEach(XElm(itl:PackageFacialAndSMTImageRec

ord)) {

{XElm(nc:Date) in XElm(biom:CaptureDate)} MO 

[NIEM-ValidLocalDate]

}

t-6X

Field:

10.006-

Horizontal 

Line Length 

Value

8.10.6,

Table 53,

7.7.8.1

The maximum

horizontal size is limited to 65,534 pixels 

in Record Types-4 and 8, and to 99,999 

for

other record types. The minimum value is 

10 pixels.

M 10.006-HLL <See Requirement ID “Field: Image HLL Value”>t-2

Field: 

10.006-

Horizontal 

Line Length 

8.10.6,

Table 53,

7.7.8.1

<The HLLis verified by checking the image 

metadata if compression is used.>

2M 10.006-HLL 

Metadata 

JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{10.006} EQ {ImageWidth-JPEGB,JPEGL}

t-11B
86

Metadata2M 10.006-HLL 

Metadata 

JP2, JP2L

IF {10.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{10.006} EQ {ImageWidth-JP2,JP2L}

t-11B

2M 10.006-HLL 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) THEN

{10.006} EQ {ImageWidth-PNG}

t-11B

Field: 

10.007-

Vertical Line 

Length 

Value

8.10.7,

Table 53,

7.7.8.2

The maximum vertical size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types.

The minimum value is 10 pixels.

M 10.007-VLL <See Requirement ID “Field: Image VLL Value”>t-2

Field: 

10.007-

Vertical Line 

Length 

Metadata

8.10.7,

Table 53,

7.7.8.2

<The VLLis verified by checking the image 

metadata if compression is used.>

2M 10.007-VLL 

Metadata 

JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{10.007} EQ {ImageHeight-JPEGB,JPEGL}

t-11B

2M 10.007-VLL 

Metadata 

JP2, JP2L

IF {10.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{10.007} EQ {ImageHeight-JP2,JP2L}

t-11B

2M 10.007-VLL 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) THEN

{10.007} EQ {ImageHeight-PNG}

t-11B

Field: 

10.008-Scale 

Units Value

8.10.8,

Table 53,

7.7.8.3

<Table 53 lists the value constraints for 

SLC>

M 10.008-SLC <See Requirement ID “Field: Image SLC Value”>t-2

Field: 

10.008-

Scale Units 

Metadata

8.10.8,

Table 53,

7.7.8.3

A value of “1” shall indicate pixels per 

inch.

A value of “2” shall indicate pixels per 

centimeter. A value of “0” in this field 

indicates that no scale is provided, and 

the quotient of THPS/TVPS shall provide 

the pixel aspect ratio.

<The SLC is verified by checking the image 

metadata if compression is used.>

2M 10.008-SLC 

Metadata 

JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{10.008} EQ {SamplingUnits-JPEGB,JPEGL}

t-11B

M 10.008-SLC 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 10.008-SLC 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) THEN

IF {10.008} EQ 1 OR 2 THEN { SamplingUnits-

PNG} EQ 1, ELSE IF {10.008} EQ 0 THEN { 

SamplingUnits-PNG} EQ 0

t-11B

Field: 

10.009-

Transmitted 

Horizontal 

Pixel Scale 

Value

8.10.9,

Table 53,

7.7.8.4

<Table 53 lists the value constraints for 

THPS.>

M 10.009-

THPS

<See Requirement ID “Field: Image THPS Value”

>

t-2

Field: 

10.009-

Transmitted 

Horizontal 

Pixel Scale 

8.10.9,

Table 53,

7.7.8.4

This is the integer pixel density used in 

the horizontal direction of the image if 

SLC has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the horizontal component of the 

2M 10.009-

THPS 

Metadata 

JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{10.008} EQ 1 OR 2

THEN {10.009} EQ {HorizontalDensity-

JPEGB,JPEGL}

t-11B
87

Metadata pixel aspect ratio, up to 5 digits. 

<The THPS is verified by checking the 

image metadata if compression is used.>

M 10.009-

THPS 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 10.009-

THPS 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) AND {10.008} EQ 1 

THEN {10.009} EQ {HorizontalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF 10.011} EQ ASCII(PNG) AND {10.008} EQ 2

THEN {10.009} EQ {HorizontalDensity-PNG} * 

0.01 (meters/cm)

t-11B

2M 10.009-

THPS 

Aspect 

Ratio 

Metadata 

JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

AND {10.008} NEQ 1 OR 2 

THEN {10.009}/{10.010} EQ {HorizontalDensity-

JPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

t-11B

M 10.009-

THPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 10.009-

THPS 

Aspect 

Ratio 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) AND {10.008} NEQ 1 

OR 2

THEN {10.009}/{10.010} EQ {HorizontalDensity-

PNG} / {VerticalDensity-PNG}

t-11B

Field: 

10.010-

Transmitted 

Vertical 

Pixel Scale 

Value

8.10.10,

Table 53,

7.7.8.5

<Table 53 lists the value constraints for 

TVPS.>

M 10.010-

TVPS

<See Requirement ID “Field: Image TVPS Value”

>

t-2

Field: 

10.010-

Transmitted 

Vertical 

Pixel Scale 

Metadata

8.10.10,

Table 53,

7.7.8.5

This is the integer pixel density used in 

the Vertical direction of the image if SLC 

has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the Vertical component of the 

pixel aspect ratio, up to 5 digits.

<The TVPS is verified by checking the 

image metadata if compression is used.>

2M 10.010-

TVPS 

Metadata JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{10.008} EQ 1 OR 2

THEN {10.010} EQ {VerticalDensity-

JPEGB,JPEGL}

t-11B

10.010-

TVPS 

Metadata 

JP2, JP2L

<Not Tested.>t-12B
88

2 M 10.010-

TVPS 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) AND {10.008} EQ 1

THEN {10.010} EQ {VerticalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF 10.011} EQ ASCII(PNG) AND {10.008} EQ 

2

THEN {10.010} EQ {VerticalDensity-PNG} * 0.01 

(meters/cm)

t-11 B

2 M 10.010-

TVPS 

Aspect 

Ratio 

Metadata 

JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{10.008} NEQ 1 OR 2

THEN {10.009}/{10.010} EQ {HorizontalDensityJPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

t-11 B

M 10.010-

TVPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.> t-12 B

2 M 10.010-

TVPS 

Aspect 

Ratio 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) AND {10.008} NEQ 1 

OR 2

THEN {10.009}/{10.010} EQ { HorizontalDensity -

PNG} / {VerticalDensity-PNG}

t-11 B

Field: 

10.011-

Compressio

n Algorithm 

Value

8.10.11,

Table 53,

7.7.9.3,

7.7.9.4

For non-facial images conveyed in Record 

Type-10 Field 10.011: Compression 

algorithm / CGA may be set to any value 

in Table 12, except WSQ20. 

M 10.011-CGA <See Requirement ID: “Field: Type10 

Compression”>

t-2, t-98

Field: 

10.011-

Compressio

n Algorithm 

Metadata

8.10.11,

Table 53

<The CGA is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2 M 10.011-

CGAMetad

ata JPEGB, 

JPEGL

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

Present(SOI -JPEG,JPEGL)

t-11 B

2 M 10.011-CGA 

Metadata 

JP2, JP2L

IF {10.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox)

t-11 B

2 M 10.011-CGA 

Metadata 

PNG

IF {10.011} EQ ASCII(PNG) THEN

Present(PNGSig)

B

Field: 

10.012-Color 

Space Value

8.10.12,

Table 53,

7.7.10

Table 13 lists the codes and their 

descriptions for each of the available 

color spaces used within this standard.

All other color spaces are to be marked as 

M 10.012-CSP <See Requirement ID: “Field: Image CSP Value>t-2
89

undefined.

Field: 

10.013-

Subject 

Acquisition 

Profile Value

8.10.13,

Table 53,

7.7.5.1

<Table 53 lists the value constraints for 

SAP.>

D 10.013-SAP <See Requirement ID: “Field: SAP Values”>t-2

Field: 

10.013-

Subject 

Acquisition 

Profile 

Conditional

8.10.13,

7.7.5

The Subject Acquisition Profile (SAP) is a 

mandatory field when Field 10.003: Image 

type / IMT contains “FACE”. Otherwise, it 

shall not be entered.

D 10.013-SAP 

Conditional

<See Requirement ID: “Field: SAP Conditional”>t-2

Field: 

10.014-Face 

Image 

Position 

Value

8.10.14,

Table 53

<Table 53 lists the value constraints for 

FIP.>

2M⇑10.014-FIP-

Value 

Subfield 1 

{US_Subfield:1 in 10.014} GTE 1 AND LTE 

{10.006}

B*

2M⇑10.014-FIP-

Value 

Subfield 2

{US_Subfield:2 in 10.014} GTE 1 AND LTE 

{10.006}

B*

2M⇑10.014-FIP-

Value 

Subfield 3 

{US_Subfield:3 in 10.014)} GTE 1 AND LTE 

{10.007}

B*

2M⇑10.014-FIP-

Value 

Subfield 4

{US_Subfield:4 in 10.014)} GT {US_Subfield:3 in 

10.014} AND LTE {10.007}

B*

2O⇑10.014-FIP-

Value 

Subfield 5 

{US_Subfield:5 in 10.014)} MO [ASCII(S,H,F,N,X)] B*

Field: 

10.014- Face 

Image 

Position 

Conditional

8.10.14 This field is only appropriate for images 

that do not comply with SAP Levels 30, 

40, 50 or 51.

D 10.014-FIP 

Conditional

<See Requirement ID: “Field: 10.014-FIP 

CondCode Dependent”>

t-2

Field: 

10.015-

Reserved

Table 53 Reserved for future useonly by 

ANSI/NIST-ITL.

- 10.015-

Reserved

<See Requirement ID: “Field: Type10-

CondCode>.

t-2

Field: 

10.016-

Scanned 

Horizontal 

Pixel Scale 

Value

8.10.15,

Table 53

<Table 53 lists the value constraints for 

SHPS.>

O 10.016-

SHPS

<See Requirement ID: “Field: Image SHPS 

Value”>

t-2

Field: 

10.017-

Scanned 

Verticall 

Pixel Scale 

8.10.15,

Table 53

<Table 53 lists the value constraints for 

SVPS.>

O 10.017-

SVPS

<See Requirement ID: “Field: Image SVPS 

Value”>

t-2
90

Value

Field: 

10.018-

Distortion 

Value

8.10.17,

Table 53

<Table 53 lists the value constraints for 

DIST.>

1M⇑10.018-

DIST- Value 

Subfield 1 

{US_Subfield:1 in 10.018} MO [ASCII(Barrel, 

Inflated, Pincushion)]

B*

1M⇑10.018-

DIST- Value 

Subfield 2

{US_Subfield:2 in 10.018} EQ ASCII(E) OR ASCII(C) B*

1M⇑10.018-

DIST- Value 

Subfield 3 

{US_Subfield:3 in 10.018)} MO 

[ASCII(Mild,Moderate,Severe)]

B*

Field: 

10.019-

Lighting 

Artifacts 

Value

8.10.18,

Table 53

<Table 53 lists the value constraints for 

LAF.>

1D 10.019-LAF {10.019} MO [ASCII(F,H,R)]B

Field: 

10.020-

Subject Pose 

Value

8.10.19,

Table 56

When included, this field shall contain 

one character code selected from Table 

56 to describe the pose of the subject.

1D 10.020-POS {10.020} MO [ASCII(F,R,L,A,D)]B

Field: YAW 

POA 

Opposite

8.10.19 Note that the offset angle in Field 10.021: 

Pose offset angle / POA is opposite from 

the yaw angle in Field 10.025 as indicated 

by a minus sign. 

2D Fields- YAW 

POA 

Opposite

IF Present(US_Subfield:4 in 10.025) THEN

{10.021} EQ { US_Subfield:4 in 10.025} *-1

B*

Field: 

10.021- Pose 

Offset Angle 

Value

8.10.20,

Table 53

When included, this field shall contain 

one character code selected from Table 

56 to describe the pose of the subject.

1D 10.021-

POA

{10.021} GTE -180 AND LTE 180B

Field: 

10.022-

Deprecated

Table 53 Not to be used in new transactions. - 10.022-

Deprecated

<See Requirement ID: “Field: Type10-

CondCode>.

t-2

Field: 

10.023-

Photo 

Acquisition 

Source 

Value

8.10.21,

Table 53,

Table 57

When included, the first information item 

in this field shall contain an attribute code 

selected from Table 57 to describe the 

source of captured image data.

1M⇑10.023-PAS {US_Subfield:1 in 10.023} MO 

[ASCII(UNSPECIFIED, UNKOWN PHOTO, DIGITAL 

CAMERA, SCANNER, UNKNOWN VIDEO, ANALOG 

VIDEO, DIGITAL VIDEO, VENDOR, TYPE20)]

B*

Field: 

10.023-

Photo 

Acquisition 

Source 

VENDOR

8.10.21,

Table 53,

Table 57

When “VENDOR” is

specified, a second information item may 

be entered with up to 64 characters to 

describe the specific source.

D 10.023-PAS 

VENDOR

<See Requirement ID: “Field: Type10-Subfield 

Occurrence” and “Field: Type10-Subfield 

CharCount.>

t-2

Field: 

10.023-

Photo 

Acquisition 

8.10.21,

Table 53,

Table 57

When “Type-20” is selected, then Field 

10.997: Source representation / SOR shall 

be contained in this record, and the 

corresponding Record Type-20 shall be 

2D 10.023-PAS 

Type-20

IF {US_Subfield:1 in 10.023} EQ ASCII(TYPE20) 

THEN

Present(10.997) AND

Present(Record ST Type(Record) EQ 20)

B*
91

Source Type-

20

included in the transaction.

Field: 

10.024-

Subject 

Quality 

Scores Type-

20

8.10.22,

Table 53,

7.7.7

<Table 53 lists the value constraints for 

SQS.>

D 10.024-SQS<See Requirement ID: “Field: Sample Quality 

Subfield 1” and “Field: Sample Quality Subfield 2” and “Field: Sample Quality Subfield 3”.>

t-2

Field: 

10.025-

Subject Pose 

Angles Value

8.10.23,

Table 53

<Table 53 lists the value constraints for 

SPA.>

1M⇑10.025-

SPA- Value 

Subfield 1 

{US_Subfield:1 in 10.025} GTE -180 AND LTE 180 B*

1M⇑10.025-

SPA- Value 

Subfield 2

{US_Subfield:2 in 10.025} GTE -90 AND LTE 90 B*

1M⇑10.025-

SPA- Value 

Subfield 3

{US_Subfield:3 in 10.025)} GTE -180 AND LTE 180 B*

1O⇑10.025-

SPA- Value 

Subfield 4

to 6

{US_Subfields:4 to 6 in 10.025)} GTE 0 AND LTE 

90

B*

Field: 

10.026-

Subject 

Facial 

Description 

Value

8.10.24,

Table 53,

Table 58

The value should be selected from the 

“Attribute code” column of Table 58.

D 10.026-SXS <Cannot check for values because the standard 

allows user-defined Alphabetic Text. See 

Requirement ID: “Field: Type10-Subfield 

CharType” and “Field: Type10-Subfield 

CharCount”>

t-2

Field: 

10.027-

Subject Eye 

Color Value

8.10.25,

Table 53,

Table 14

<Table 53 lists the value constraints for 

SEC.>

D 10.027-SEC <See Requirement ID: “Field: Image ECL Value”>.t-2

Field: 

10.028-

Subject Hair 

Color Value

8.10.26,

Table 53,

Table 59

<Table 53 lists the value constraints for 

SHC.>

When the subject is predominantly bald, 

but hair color is discernible, then the 

appropriate hair color attribute code shall 

follow “BAL” in a second entry.

For streaked hair, use “STR” in the first 

entry; use the second entry to describe 

the principal color of the hair.

1M⇑10.028-SHC {US_Subfield:1 in 10.028} MO [ASCII(XXX, BAL, 

BLK, BLN, BRO, GRY, RED, SDY, WHI, BLU, GRN, 

ONG, PNK, PLE, STR)]

AND

{US_Subfield:2 in 10.028} MO [ASCII(XXX, BLK, 

BLN, BRO, GRY, RED, SDY, WHI, BLU, GRN, ONG, 

PNK, PLE)]

B*

Field: 

10.029- 2D 

Facial 

Feature 

Points Value

8.10.27,

Table 53

<Table 53 lists the value constraints for 

FFP.>

The first information item, feature point 

type / FPT is a one character value. It is 

1M⇑10.029-FFP-

Value 

Subfield 1 

ForEach(RS_Subfield in 10.029) {

{US_Subfield:1 in RS_Subfield} EQ 1 OR 2 }

B*

2M 10.029-FFP- ForEach(RS_Subfield in 10.029) B*
92

mandatory. It shall be either

1 = Denoting an MPEG4 Feature point.

2 = Anthropometric landmark. (This is 

new to this version).

The second information item, feature 

point code / FPC is 3 to 5 characters. If 

FPT is 1, this information item shall be 

“A.B” with A and B defined in

Section 8.10.27.1 and illustrated in Figure 

12. If FPT is 2, the codes are entered as 

shown in the “Feature Point ID” column 

of Table 61. This is one to four alphabetic 

characters.

⇑ Value 

Subfield 2

{

IF({US_Subfield:1 in RS_Subfield} EQ 1 THEN

{US_Subfield:2 in RS_Subfield} MO [Figure 11, 

Figure 12]

ELSE

{US_Subfield:2 in RS_Subfield} MO [Table 61] }

1M⇑10.029-FFP-

Value 

Subfield 3

ForEach(RS_Subfield in 10.029) {

{US_Subfield:3 in RS_Subfield} GTE 1 AND LTE 

{10.006} }

B*

1M⇑10.029-FFP-

Value 

Subfield 4

ForEach(RS_Subfield in 10.029) {

{US_Subfield:4 in RS_Subfield} GTE 1 AND LTE 

{10.007} }

B*

Field: 

10.030-

Device 

Monitoring 

Mode Value

8.10.28,

Table 53,

<Table 53 lists the value constraints for 

DMM.>

O 10.030-

DMM

<See Requirement ID: “Field: Device 

Monitoring”>.

t-2

Field: 

10.031-

Tiered 

Markup 

Collection 

Value

8.10.29,

Table 53,

<Table 53 lists the value constraints for 

TMC.>

1D 10.031-

TMC

{10.031} MO [1 to 5, 100 to 999]B

Field: 

10.032- 3D 

Facial 

Feature 

Points Value

8.10.30,

Table 53

<Table 53 lists the value constraints for 

3DF.>

The first information item, feature point 

type / FPT is a one character value. It is 

mandatory. It shall be either

1 = Denoting an MPEG4 Feature point, 

but using a Z coordinate

2 = Anthropometric landmark, with a Z 

coordinate.

The second information item, feature 

point code / FPC is 3 to 5 characters. If 

FPT is 1, this information item shall be 

“A.B” with A and B defined in

1M⇑10.032-

3DF- Value 

Subfield 1 

ForEach(RS_Subfield in 10.032) {

{US_Subfield:1 in RS_Subfield} EQ 1 OR 2 }

B*

2M⇑10.032-

3DF- Value 

Subfield 2

ForEach(RS_Subfield in 10.032) {

IF({US_Subfield:1 in RS_Subfield} EQ 1 THEN

{US_Subfield:2 in RS_Subfield} MO [Figure 11, 

Figure 12]

ELSE

{US_Subfield:2 in RS_Subfield} MO [Table 61]

B*
93

Section 8.10.27.1 and illustrated in Figure 

12. If FPT is 2, the codes are entered as 

shown in the “Feature Point ID” column 

of Table 61. This is one to four alphabetic 

characters.

}

1M⇑10.032-

3DF- Value 

Subfield 3

ForEach(RS_Subfield in 10.032) {

{US_Subfield:3 in RS_Subfield} GTE 1 AND LTE 

{10.006} }

B*

1M⇑10.032-

3DF- Value 

Subfield 4 

ForEach(RS_Subfield in 10.032) {

{US_Subfield:4 in RS_Subfield} GTE 1 AND LTE 

{10.007} }

B*

1M⇑10.032-

3DF- Value 

Subfield 5

ForEach(RS_Subfield in 10.032) {

{US_Subfield:5 in RS_Subfield} GTE 1 AND LTE 

65534 }

B*

Field: 

10.033-

Feature 

Contours 

Value

8.10.31,

Table 53.

Table 15

<Table 53 lists the value constraints 

for3DF.>

1M⇑10.033-

FEC- Value 

Subfield 1 

ForEach(RS_Subfield in 10.033) {

{US_Subfield:1 in RS_Subfield} MO 

[ASCII(eyetop, eyebottom, upperliptop, 

upperlipbottom, lowerliptop, lowerlipbottom, 

rightnostril, leftnostril, lefteyebrow, 

righteyebrow, chin, faceoutline] }

B*

1M⇑10.033-

FEC- Value 

Subfield 2

ForEach(RS_Subfield in 10.033) {

{US_Subfield:2 in RS_Subfield} MO [3 to 99] }

B*

1M⇑10.033-

FEC- Value 

Subfield 

Pair

ForEach(RS_Subfield in 10.033) {

For(X EQ 3 to {US_Subfield:2 in RS_Subfield}) {

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{10.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{10.006} }}

B*

Field: 10.034 

to 10.037-

Reserved

Table 53 Reserved for future useonly by 

ANSI/NIST-ITL.

- 10.034 to 

10.037-

Reserved

<See Requirement ID: “Field: Type10-

CondCode>.

t-2

Field: 

10.038-

Comment 

8.10.32,

7.4.4

Table 53

<Table 53 lists the value constraints for 

COM.>

O 10.038-

COM

<See Requirement ID: “Field: Comment”>.t-2
94

Value

Field: 

10.039-

Type-10 

Reference 

Number 

Value

8.10.33,

Table 53

<Table 53 lists the value constraints for 

T10.>

1D 10.039-T10 {10.039} MO [1 to 255]B

Field: 

10.040- NCIC 

SMT Code 

Value

8.10.34,

Table 53,

Table 98

<Table 53 lists the value constraints for 

SMT.>

1D 10.040-T10 ForEach(US_Subfield in 10.040) {

{US_Subfield} MO [Table 98] }

B*

Field: 

10.041- SMT 

Size Value

8.10.35,

Table 53

<Table 53 lists the value constraints for 

SMS.>

1D 10.041-

SMS

ForEach(US_Subfield in 10.041) {

{US_Subfield} GTE 1 AND MO[Integers] }

B*

Field: 

10.042- SMT 

Descriptors 

Value

8.10.36,

Table 53,

Table 54,

Table 63

<Table 53 lists the value constraints for 

SMD.>

1M⇑10.042-

SMD- Value 

Subfield 1 

ForEach(RS_Subfield in 10.042) {

{US_Subfield:1 in RS_Subfield} MO 

[ASCII(SCAR,PIERCING, TATTOO, CHEMICAL, 

BRANDED, CUT)] }

B*

1D 10.042-

SMD- Value 

Subfield 2

ForEach(RS_Subfield in 10.042) {

{US_Subfield:2 in RS_Subfield} MO 

[ASCII(Human, Animal, Plant, Flag, Object, 

Abstract, Symbol, Other) ] }

B*

2D 10.042-

SMD- Value 

Subfield 3

ForEach(RS_Subfield in 10.042) {

IF {US_Subfield:2 in RS_Subfield} EQ 

ASCII(HUMAN) 

THEN

{US_Subfield:3 in RS_Subfield} MO 

[ASCII(MFACE,FFACE, ABFACE, MBODY, FBODY, 

ABBODY, ROLES, SPORT, MBPART, FBPART, 

ABBPART, MHUMAN, SKULL)]

ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ 

ASCII(ANIMAL) 

THEN

{US_Subfield:3 in RS_Subfield} MO [ASCII(CAT, 

DOG, DOMESTIC, VICIOUS, HORSE, WILD, SNAKE, 

DRAGON, BIRD, INSECT, ABSTRACT, PARTS, 

MANIMAL)]

ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ 

B*
95

ASCII(PLANT) 

THEN

{US_Subfield:3 in RS_Subfield} MO 

[ASCII(NARCOTICS, REDFL, BLUEFL, YELFL, DRAW, 

ROSE, TULIP, LILY, MPLANT)]

ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ ASCII(FLAG) 

THEN

{US_Subfield:3 in RS_Subfield} MO [ASCII(USA, 

STATE, NAZI, CONFED, BRIT, MFLAG)] ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ 

ASCII(Object) 

THEN

{US_Subfield:3 in RS_Subfield} MO [ASCII(FIRE, 

WEAP,PLANE,VESSEL,TRAIN,VEHICLE,MYTH,SPOR

T,NATURE, MOBJECTS)]

ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ 

ASCII(Abstract) 

THEN

{US_Subfield:3 in RS_Subfield} MO 

[ASCII(FIGURE, SLEEVE, BRACE, ANKLET, NECKLC, 

SHIRT, BODBND, HEDBND, MABSTRACT)]

ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ 

ASCII(Symbol) 

THEN

{US_Subfield:3 in RS_Subfield} MO 

[ASCII(NATION, POLITIC, MILITARY, FRATERNAL, 

PROFESS, GANG, MSYMBOLS)]

ELSE 

IF {US_Subfield:2 in RS_Subfield} EQ 

ASCII(OTHER) 

THEN

{US_Subfield:3 in RS_Subfield} MO 

[ASCII(WORDING, FREEFRM, MISC)] }

1D 10.042-

SMD- Value 

Subfield 4

TRUE B*

Field: 

10.042- SMT 

Descriptors 

Subfields 

Dependent

8.10.36,

Table 53

...does not apply to scars and marks. D 10.042-

Subfields 

Dependent

<See Requirement ID: “Field: Type10-Subfield 

Occurrence” >

t-2

Field: 8.10.37, <Table 53 lists the value constraints for 1- 10.043- ForEach(US_Subfield in 10.043) B*
96

10.043-

Tattoo Color 

Value

Table 53 COL.> COL- Value {

{US_Subfield} MO [BLACK, BROWN, GRAY, BLUE, 

GREEN, ORANGE, PURPLE, RED, YELLOW, WHITE, 

MULTI, OUTLINE] }

Field: 

10.044-

Image 

Transform 

Value

8.10.38,

Table 53,

Table 65

<Table 53 lists the value constraints for 

ITX.>

1M⇑10.044-ITX-

Value 

ForEach(US_Subfield in 10.044) {

{US_Subfield} MO [AGE, AXIS, COLORSHIFT, 

CONTRAST, CROP, DIST, DOWNSAMPLE, GRAY, 

ILLUM, IMGFUSE, INTERPOLATE, MULTCOMP, 

MULTIVIEW, POSE, ROTATE, SNIR, SUPERRES, 

WHITE] }

B*

Field: 

10.045-

Occlusions 

Value

8.10.30,

Table 17, 

Table 18

<Table 53 lists the value constraints for 

OCC.>

1M⇑10.045-

OCC- Value 

Subfield 1 

ForEach(RS_Subfield in 10.045) {

{US_Subfield:1 in RS_Subfield} MO [ASCII(T, I, L, 

S)] }

B*

1M⇑10.045-

OCC- Value 

Subfield 2

ForEach(RS_Subfield in 10.045) {

{US_Subfield:2 in RS_Subfield} MO 

[ASCII(H,S,C,R,O)] }

B*

1M⇑10.045-

OCC- Value 

Subfield 3

ForEach(RS_Subfield in 10.045) {

{US_Subfield:3 in RS_Subfield} GTE 2 AND LTE 99 }

B*

1M⇑10.045-

OCC- Value 

Subfield 

Pairs

ForEach(RS_Subfield in 10.045) {

For(X EQ 1 to (US_Subfield:3 in RS_Subfield}) {

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{10.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{10.006} }}

B*

Field: 10.046 

to 10.199-

Reserved

Table 53 Reserved for future useonly by 

ANSI/NIST-ITL.

- 10.046 to 

10.199-

Reserved

<See Requirement ID: “Field: Type10-

CondCode>.

t-2

Field: 10.200 

to 10.900-

User 

Defined

Table 53 User Defined Fields-- 10.200 to 

10.900-

User 

Defined

TRUEB
97

Field: 10.901 

Reserved

Table 53 Reserved for future useonly by 

ANSI/NIST-ITL.

- 10.901-

Reserved

<See Requirement ID: “Field: Type10-

CondCode>.

t-2

Field: 

10.902-

Annotated 

Information 

Value

8.10.41,

Table 53

This is an optional field, listing the 

operations performed on the original 

source in order

to prepare it for inclusion in a biometric 

record type. See Section 7.4.1.

O 10.902-

ANN-Value

<See Requirement ID: “Field: xx.902-ANN” >.t-2

Field: 

10.903-

Device 

Unique 

Identifier 

Value

8.10.42,

Table 53

This is an optional field. See Section 

7.7.1.1.

O 10.903-DUI 

Value

<See Requirement ID: “Field: Device ID” >.t-2

Field: 

10.904-

Make/Mode

l/Serial 

Number 

Value

8.10.43,

Table 53

This is an optional field. See Section 

7.7.1.2.

O 10.904-

MMS Value

<See Requirement ID: “Field: Make Model” >.t-2

Field: 10.905 

to 10.994-

Reserved

Table 53 Reserved for future useonly by 

ANSI/NIST-ITL.

- 10.905 to 

10.994-

Reserved

<See Requirement ID: “Field: Type10-

CondCode>.

t-2

Field: 

10.995-

Associated 

Context 

Value

8.10.44,

Table 53

See Section 7.3.3O 10.995-ASC 

Value

<See Requirement IDs: “Field: xx.995-ASC” and 

“Field: xx.995-ASC-ACN” and

“Field: xx.995-ASC-ASP”>.

t-2

Field: 

10.996-

Hash Value

8.10.45,

Table 53

See Section 7.5.2O 10.996-HAS 

Value

<See Requirement ID: “Field: HAS”>t-2

Field: 

10.997-

Source 

Representati

on Value

8.10.46,

Table 53

See Section 7.3.2O 10.997-SOR 

Value

<See Requirement IDs: “Field: xx.997-SOR” and 

“Field: xx.997-SOR-SRN” and

“Field: xx.997-SOR-RSP”>.

t-2

Field: 

10.998-

Geographic 

Sample 

Acquisition 

Location 

Value

8.10.47,

Table 53

See Section 7.7.3O 10.998-

GEO Value

<See Requirement IDs: “Field: Geographic”, 

“Field: Geographic-Conditional”,“Field: 

Geographic-Subfield 1” through “Field: 

Geographic-Values-SubField 15” >.

t-2

Field: 

10.999-

Image Data 

Valid

8.10.48, 

7.7.9.4,

Table 53

This is a mandatory field contains the 

image.

For non-facial images conveyed in Record 

2M 10.999-

DATA 

Uncompres

sed Valid 

IF {10.011} EQ ASCII(NONE) THEN

Length(10.999) EQ 10.006} * {10.007}

B
98

Type-10, Field 10.011: Compression 

algorithm/ CGA may be set to any value in 

Table 12, except WSQ20. 

<The image metadata is checked for 

validity.>

2 M 10.999-

DATA JPEGJPEGL Valid

IF {10.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

Present(JFIF, 

SOI-JPEGB,JPEGL,

SOF-JPEGB,JPEGL,

EOI-JPEG, JPEGL)

t-11 B

2 M 10.999-

DATA JP2-

JP2L Valid

IF {10.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox, 

HeadBox, 

ImgBox)

t-11 B

2 M 10.999-

DATA PNG 

Valid

IF {10.011} EQ ASCII(PNG) THEN

Present(PNGSig,

IHDR,

IDAT,

IEND)

B
99

Table C.10 - Assertions for Record Type 11 - Reserved for Voice 

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.11: Record Type-11: Reserved for voice

Transaction: 

Type11 Zero 

Occurrences

8.11 Reserved for voice. A committee was 

established at the second Workshop for 

this version of the standard,

held March 1-3, 2011 to develop 

specifications for this record type.

M Type11-

Zero 

Occurrence

s

<See Requirement ID “Transaction: Reserved 

Records”>

t-2

Table C.11 - Assertions for Record Type 12 - Reserved for Dental Records

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.12: Record Type-12: Reserved for dental records

Transaction: 

Type12 Zero 

Occurrences

8.12 Reserved for dental records. A committee 

was established at the second Workshop 

for this version of the standard,

held March 1-3, 2011 to develop 

specifications for this record type.

M Type12-

Zero 

Occurrence

s

<See Requirement ID “Transaction: Reserved 

Records”>

t-2
100

Table C.12 - Assertions for Record Type 13 - Friction-Ridge Latent Image Record

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.13: Record Type-13: Friction-ridge latent image record

Field: 

Type13-

Subfield 

Occurenece

Table 66 <Table 66 specifies which fields contain 

subfields as well as the number of 

occurrences permitted.>

1 - Type13-

Subfields 

Zero

Count(Subfields in 13.[001 to 003, 005 to 012, 

016, 017, 020, 903, 996, 999]) EQ 0

T

1 M 13.004-

Subfields

Count(US_Subfields in 13.004) EQ 1 OR 2 T

1 M 13.013-

Subfields

Count(US_Subfields in 13.013 ) MO [1 to 6] T

1 D 13.014-

Subfields

Count(RS_Subfields in 13.014) MO [1 to 9]

AND

ForEach(RS_Subfield in 13.014)

{

Count(US_Subfields in RS_Subfield) EQ 2

}

T

D 13.015-

Subfields

<See Requirement ID: “Field: PPC-Subfield 

Occurrences”>

t-2

1 O 13.024-

Subfields

Count(RS_Subfields in 13.024) MO [1 to 9]

AND

ForEach(RS_Subfield in 13.024)

{

Count(US_Subfields in RS_Subfield) EQ 4

}

T

1 O 13.902-

Subfields

Count (RS_Subfields in 13.902) GTE 1

AND

ForEach(RS_Subfield in 13.902)

{

Count(US_Subfields in RS_Subfield) EQ 4

}

T

1 O 13.904- Count(US_Subfields in 13.904) EQ 3 T
101

Subfields

1 O 13.995-

Subfields

Count(RS_Subfields in 13.995) MO [1 to 255]

AND

ForEach(RS_Subfield in 13.995)

{

Count(US_Subfields in RS_Subfield) EQ 1 OR 2

}

T

1 O 13.997-

Subfields

Count(RS_Subfields in 13.997) MO [1 to 255]

AND

ForEach(RS_Subfield in 13.997)

{

Count(US_Subfields in RS_Subfield) EQ 1 OR 2

}

T

O 13.998-

Subfields

<See Requirement ID: “Field: GeographicConditional”>t-2

Field: 

Type13-

CondCode

Table 66 <Table 66 specifies the Condition Code for 

each field.>

1 - Type13-

CondCode

Present(13.001 to 13.013, 13.999)

AND

NOT Present(13.018, 13.019, 13.021 to 13.023, 

13.025 to 13.199, 13.901, 13.905 to 13.994)

B

Field: 

13.014-

Search 

Position 

Descriptors 

Dependent

Table 66,

8.13.14

This field shall be present if and only if the 

finger position code “19” appears in Field

13.013: Friction ridge generalized position 

/ FGP.

D 13.014-

CondCode 

Dependent

<See Requirement ID: “Field: SPD,PPC 

Conditional”>

t-2

Field: 

13.015-Print 

Position 

Coordinates 

Dependent

Table 53,

8.13.14

This field may be present if and only if the 

finger position code “19” appears in Field

13.013: Friction ridge generalized position 

/ FGP. 

D 13.015-

CondCode 

Dependent

<See Requirement ID: “Field: SPD,PPC 

Conditional”>

t-2

Field: 

Type13-

CharType

8.13,

Table 66

<Table 66 specifies the Character Type for 

each field that contains no subfields. Note 

that even though some Character Types 

are listed as U (user defined), they may 

still have character type limitations 

defined in the standard text. >

1 - Type13-

CharType N

Bytes(13.[001,002,003, 005 to 010, 012, 016, 

017]) MO [0x30 to 0x39]

B

1 - Type13-

CharType A

Bytes(13.011) MO [0x41 to 0x5A, 0x61 to 0x7A] B

1 - Type13-

CharType U

Present(Bytes(13.020) B

1 O 13.903-

CharType 

Text ANS

Bytes(10.903) MO [0x20, 0x7E] B
102

1O 13.996-

CharType H

Bytes(10.996) MO [0x30 to 0x39,0x41 to 0x46, 

0x61 to 0x66]

B

Field: 

Type13-

Subfield

CharType

8.13,

Table 66

<Table 66 specifies the Character Type for 

each subfield.>

1M 13.004-

Subfield 

CharType U

Present( Bytes( US_Subfields:1,2 in 13.004 ) B*

1M 13.013-

Subfield 

CharType N

Bytes(All(US_Subfields in 13.013)) MO [0x30 to 

0x39]

B*

1D 13.014-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 13.014) {

Bytes(US_Subfield:1 in RS_Subfield) MO [0x30 to 

0x39]

AND

Bytes(US_Subfield:2 in RS_Subfield) MO [0x30 to 

0x39, 0x41 to 0x5A, 0x61 to 0x7A] }

B*

1D 13.015-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 13.015) {

Bytes(US_Subfields:1,2 in RS_Subfield)) MO 

[0x30 to 0x39, 0x41 to 0x5A, 0x61 to 0x7A]

AND

Bytes(US_Subfields:3 to 6 in RS_Subfield)) MO 

[0x30 to 0x39] }

B*

1O 13.024-

Subfield 

CharType 

HN

ForEach(RS_Subfield in 13.024) {

Bytes(US_Subfields:1,2,4 in RS_Subfield)) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:3 in RS_Subfield)) MO [0x30 

to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1O 13.902-

Subfield 

CharType

ANU

ForEach(RS_Subfield in 13.902) {

Present(Bytes(US_Subfields:2 to 4 in 

RS_Subfield)) 

AND

Bytes(US_Subfield:1 in RS_Subfield) MO [0x30 to 

0x39, 0x5A] }

B*

1O 13.904-

Subfield 

CharType U

Present(Bytes(All(US_Subfields in 13.904))) B*

1O 13.995-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 13.995)) MO [0x30 

to 0x39]

B*
103

1 O 13.997-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 13.997)) MO [0x30 

to 0x39]

B*

O 13.998-

Subfield 

CharType 

ANSU

<See Requirement ID: “Field: Geographic”> t-2

Field: 

Type13-

CharCount

Table 66 <Table 66 specifies the Character Count 

for each field that contains no subfields.>

1 M 13.001-

CharCount

DataLength(13.001) GTE 1 B

1 M 13.002-

CharCount

DataLength(13.002) EQ 1 OR 2 B

1 M 13.003-

CharCount

DataLength(13.003) EQ 1 OR 2 B

1 M 13.005-

CharCount

DataLength(13.005) EQ 8 B

1 M 13.006-

CharCount

DataLength(13.006) MO [2 to 5] B

1 M 13.007-

CharCount

DataLength(13.007) MO [2 to 5] B

1 M 13.008-

CharCount

DataLength(13.008) EQ 1 B

1 M 13.009-

CharCount

DataLength(13.009) MO [1 to 5] B

1 M 13.010-

CharCount

DataLength(13.010) MO [1 to 5] B

1 M 13.011-

CharCount

DataLength(13.011) MO [3 to 5] B

1 M 13.012-

CharCount

DataLength(13.012) EQ 1 OR 2 B

1 O 13.016-

CharCount

DataLength(13.016) MO [1 to 4] B

1 O 13.017-

CharCount

DataLength(13.017) MO [1 to 4] B

1 O 13.020-

CharCount

DataLength(13.020) MO [1 to 126] B

1 O 13.903-

CharCount

DataLength(13.903) MO [13 to 16] B

1 O 13.996-

CharCount

DataLength(13.995) EQ 64 B

1 M 13.999-

CharCount

DataLength(13.999) GTE 1 B

Field: 

Type13-

Table 66 <Table 66 specifies the Character Count 

for each subfield.>

2 M 13.004-

Subfield 

Length(All(US_Subfields in 13.004)) GTE 1 B*
104

Subfield 

CharCount

CharCount

2M 13.013-

Subfield 

CharCount

Length(All(US_Subfields in 13.013)) EQ 1 OR 2 B*

1D 13.014-

Subfield 

CharCount

ForEach(RS_Subfield in 13.014) {

Length(US_Subfield:1 in RS_Subfield) EQ 1 OR 2

AND

Length(US_Subfield:2 in RS_Subfield) EQ 3 }

B*

1D 13.015-

Subfield 

CharCount

ForEach(RS_Subfield in 13.015) {

Length(US_Subfields:1,2 in RS_Subfield)) EQ 2 

OR 3

AND

Length(US_Subfields:3 to 6 in RS_Subfield)) MO 

[1 to 5] }

B*

1O 13.024-

Subfield 

CharCount

ForEach(RS_Subfield in 13.024) {

Length(US_Subfield:1 in RS_Subfield)) EQ 1 OR 2

AND

Length(US_Subfields:2 in RS_Subfield)) MO [1 to 

3]

AND

Length(US_Subfields:3 in RS_Subfield)) EQ 4

AND

Length(US_Subfields:4 in RS_Subfield)) MO [1 to 

5] }

B*

1O 13.902-

Subfield 

CharCount

ForEach(RS_Subfield in 13.902) {

Length(US_Subfield:1 in RS_Subfield) EQ 15

AND

Length(US_Subfields:2,3 in RS_Subfield) MO [1 

to 64]

AND

Length(US_Subfield:4 in RS_Subfield)) MO [1 to 

255] }

B*

1O 13.904-

Subfield 

CharCount

Length(All(US_Subfields in 13.904)) MO [1 to 50] B*

1O 13.995- ForEach(RS_Subfield in 13.995) B*
105

Subfield 

CharCount

{

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

1O 13.997-

Subfield 

CharCount

ForEach(RS_Subfield in 13.997) {

Length(US_Subfield:2 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

O 13.998-

Subfield 

CharCount

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type13-Field 

Occurrence

Table 66<Table 66 specifies the Field Occurrence 

for each field.>

1- Type13-

Occurrence 

Zero

Count(13.[016, 017, 021 to 023, 025 to 

199,901,905 to 994]) EQ 0

B

1M Type13-

Occurrence 

One

Count(13.[001 to 013, 999]) EQ 1B

1- Type13-

Occurrence 

One or 

Fewer

Count(13.[ 014 to 017,020, ,024, 902 to 904, 995 

to 998) LTE 1

B

Field: 

13.001-

Record 

Header 

Value

8.13.1,

Table 66,

7.1

Field 13.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

M 13.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.13.1,

C.10.11

The XML name for the Type-13 record is 

<itl:PackageLatentImageRecord>, and its

<biom:RecordCategoryCode> element 

shall have a value of “13”.

1M NIEM-

13.001-

Record 

Header

ForEach(itl:PackageLatentImageRecord) {

{XElm(biom:RecordCategoryCode)} EQ ASCII(13) }

X

Field: 

13.002-

Information 

Designation 

Character

Value

8.13.2,

Table 66,

7.3.1

This mandatory field shall be the IDC of 

this Type-13 record as found in the 

information item IDC of Field 1.003 

Transaction content/CNT. 

M 13.002-IDC <See Requirement IDs“Field:

xx.002-IDC and “Field: 1.003-Transaction 

Content Subfield 2 IDC Matches”>

t-2

Field: 

13.003-

Impression 

Type

Value

8.13.3,

Table 66,

7.7.4.1

This mandatory field shall indicate the 

manner by which the latent print was 

obtained.

See Section 7.7.4.1 for details. Valid 

values are 4 through 7, 12 through 15 and 

32 through 39.

1M 13.003-IMP {13.003} MO [4 to 7, 12 to 15, 32 to 39]B

Field: 

13.004-

8.13.4,

7.6

This is a mandatory field. See Section 7.6 

for details.

M 13.004-

ORG

<See Requirement ID “Field: Agency Codes”>t-2
106

Originating 

Agency 

Value

Field: 

13.005-

Latent 

Capture 

Date Value

8.13.5,

7.7.2.3

This mandatory field shall contain the 

date that the latent biometric data 

contained in the record was captured.

1M 13.005-LCD {13.005} MO [ValidLocalDate]t-6T

1M NIEM-

13.005-LCD

ForEach(XElm(itl:PackageLatentImageRecord)) {

{XElm(nc:Date) in XElm(biom:CaptureDate)} MO 

[NIEM-ValidLocalDate]

}

t-6X

Field: 

13.006-

Horizontal 

Line Length 

Value

8.13.6,

Table 66,

7.7.8.1

The maximum

horizontal size is limited to 65,534 pixels 

in Record Types-4 and 8, and to 99,999 

for

other record types. The minimum value is 

10 pixels.

M 13.006-HLL <See Requirement ID “Field: Image HLL Value”>t-2

Field: 

13.006-

Horizontal 

Line Length 

Metadata

8.13.6,

Table 66,

7.7.8.1

<The HLL is verified by checking the image 

metadata if compression is used.>

2M 13.006-HLL 

Metadata 

JPEGL

IF {13.011} EQ ASCII(JPEGL) THEN

{13.006} EQ {ImageWidth-JPEGB,JPEGL}

t-11B

2M 13.006-HLL 

Metadata 

JP2L

IF {13.011} EQ ASCII(JP2L) THEN

{13.006} EQ {ImageWidth-JP2,JP2L}

t-11B

2M 13.006-HLL 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) THEN

{13.006} EQ {ImageWidth-PNG}

t-11B

2M 13.006-HLL 

Metadata 

WSQ

IF {13.011} EQ ASCII(WSQ20) THEN

{13.006} EQ {ImageWidth-WSQ}

t-11B

Field: 

13.007-

Vertical Line 

Length 

Value

8.13.7,

Table 66,

7.7.8.2

The maximum vertical size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types.

The minimum value is 10 pixels.

M 13.007-VLL <See Requirement ID “Field: Image VLL Value”>t-2

Field: 

13.007-

Vertical Line 

Length 

Metadata

8.13.7,

Table 66,

7.7.8.2

<The VLL is verified by checking the image 

metadata if compression is used.>

2M 13.007-VLL 

Metadata 

JPEGL

IF {13.011} EQ ASCII (JPEGL) THEN

{13.007} EQ {ImageHeight-JPEGB,JPEGL}

t-11B

2M 13.007-VLL 

Metadata 

JP2L

IF {13.011} EQ ASCII(JP2L) THEN

{13.007} EQ {ImageHeight-JP2,JP2L}

t-11B

2M 13.007-VLL 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) THEN

{13.007} EQ {ImageHeight-PNG}

t-11B

2M 13.007-VLL 

Metadata 

WSQ

IF {13.011} EQ ASCII(WSQ20) THEN

{13.007} EQ {ImageHeight-WSQ}

t-11B

Field: 

13.008-Scale 

8.13.8,

Table 66,

<Table 66 lists the value constraints for 

SLC>

M 13.008-SLC <See Requirement ID “Field: Image SLC Value”>t-2
107

Units Value 7.7.8.3

Field: 

13.008-

Scale Units 

Metadata

8.13.8,

Table 66,

7.7.8.3

A value of “1” shall indicate pixels per 

inch.

A value of “2” shall indicate pixels per 

centimeter. A value of “0” in this field 

indicates that no scale is provided, and 

the quotient of THPS/TVPS shall provide 

the pixel aspect ratio.

<The SLC is verified by checking the image 

metadata if compression is used.>

2M 13.008-SLC 

Metadata 

JPEGL

IF {13.011} EQ ASCII(JPEGL) THEN

{13.008} EQ {SamplingUnits-JPEGB,JPEGL}

t-11B

2M 13.008-SLC 

Metadata 

JP2L

<Not Tested.>t-12B

2M 13.008-SLC 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) THEN

IF {13.008} EQ 1 OR 2 THEN { SamplingUnits-

PNG} EQ 1, ELSE IF {13.008} EQ 0 THEN { 

SamplingUnits-PNG} EQ 0

t-11B

M 13.008-SLC 

Metadata 

WSQ

<Not Tested.>t-12B

Field: 

13.009-

Transmitted 

Horizontal 

Pixel Scale 

Value

8.13.9,

Table 66,

7.7.8.4

<Table 66 lists the value constraints for 

THPS.>

M 13.009-

THPS

<See Requirement ID “Field: Image THPS Value”

>

t-2

Field: 

13.009-

Transmitted 

Horizontal 

Pixel Scale 

Metadata

8.13.9,

Table 66,

7.7.8.4

This is the integer pixel density used in 

the horizontal direction of the image if 

SLC has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the horizontal component of the 

pixel aspect ratio, up to 5 digits. 

<The THPS is verified by checking the 

image metadata if compression is used.>

2M 13.009-

THPS 

Metadata 

JPEGL

IF {13.011} EQ ASCII(JPEGL) AND {13.008} EQ 1 

OR 2 

THEN {13.009} EQ {HorizontalDensity-

JPEGB,JPEGL}

t-11B

M 13.009-

THPS 

Metadata 

JP2L

<Not Tested.>t-12B

2M 13.009-

THPS 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) AND {13.008} EQ 1 

THEN {13.009} EQ {HorizontalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF {13.011} EQ ASCII(PNG) AND {13.008} EQ 

2 

THEN {13.009} EQ {HorizontalDensity-PNG} * 

0.01 (meters/cm)

t-11B

M 13.009-

THPS 

Metadata 

WSQ

<Not Tested.>t-12B

2M 13.009-

THPS 

Aspect 

Ratio 

Metadata 

JPEGL

IF {13.011} EQ ASCII(JPEGL) AND {13.008} NEQ 1 

OR 2

THEN {13.009}/{13.010} EQ {HorizontalDensity-

JPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

t-11B
108

M 13.009-

THPS 

Aspect 

Ratio 

Metadata 

JP2L

<Not Tested.>t-12B

2M 13.009-

THPS 

Aspect 

Ratio 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) AND {13.008} NEQ 1 

OR 2

THEN {13.009}/{13.010} EQ {HorizontalDensity-

PNG} / {VerticalDensity-PNG}

t-11B

M 13.009-

THPS 

Aspect 

Ratio 

Metadata 

WSQ

<Not Tested.>t-12B

Field: 

13.010-

Transmitted 

Vertical 

Pixel Scale 

Value

8.13.10,

Table 66,

7.7.8.5

<Table 66 lists the value constraints for 

TVPS.>

M 13.010-

TVPS

<See Requirement ID “Field: Image TVPS Value”

>

t-2

Field: 

13.010-

Transmitted 

Vertical 

Pixel Scale 

Metadata

8.13.10,

Table 66,

7.7.8.5

This is the integer pixel density used in 

the Vertical direction of the image if SLC 

has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the Vertical component of the 

pixel aspect ratio, up to 5 digits.

<The TVPS is verified by checking the 

image metadata if compression is used.>

2M 13.010-

TVPS 

Metadata 

JPEGL

IF {13.011} EQ ASCII(JPEGL) AND {13.008} EQ 1 

OR 2 

THEN {13.010} EQ {VerticalDensity-JPEGB,JPEGL}

t-11B

M 13.010-

TVPS 

Metadata 

JP2L

<Not Tested.>t-12B

2M 13.010-

TVPS 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) AND {13.008} EQ 1 

THEN {13.010} EQ {VerticalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF {13.011} EQ ASCII(PNG) AND {13.008} EQ 2

THEN {13.010} EQ {VerticalDensity-PNG} * 0.01 

(meters/cm)

t-11B

M 13.010-

TVPS 

Metadata 

WSQ

<Not Tested.>t-12B

2M 13.010-

TVPS 

IF {13.011} EQ ASCII(JPEGL) AND {13.008} NEQ 1 

OR 2

t-11B
109

Aspect 

Ratio 

Metadata 

JPEGL

THEN {13.009}/{13.010} EQ {HorizontalDensityJPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

M 13.010-

TVPS 

Aspect 

Ratio 

Metadata 

JP2L

<Not Tested.> t-12 B

2 M 13.010-

TVPS 

Aspect 

Ratio 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) AND {13.008} NEQ 1 

OR 2

THEN {13.009}/{13.010} EQ { HorizontalDensity -

PNG} / {VerticalDensity-PNG}

t-11 B

M 13.010-

TVPS 

Aspect 

Ratio 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

13.011-

Compressio

n Algorithm 

Value

8.13.11,

Table 66,

7.7.9.1,

5.3.13

For each of these fields, the entry 

corresponds to the appropriate Label 

entry in Table 12: Field 13.011: 

Compression algorithm / CGA.

The variable-resolution for latent image 

data contained in the Type-13 record shall 

be uncompressed or may be the output 

from a lossless compression algorithm.

1 M 13.011-CGA {13.011} MO [ASCII(NONE, JPEGL, JP2L, PNG, 

WSQ)]

t-98 B

Field: 

13.011-

Compressio

n Algorithm 

Metadata

8.13.11,

Table 66

<The CGA is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2 M 13.011-

CGAMetad

ata JPEGL

IF {13.011} EQ ASCII(JPEGL) THEN

Present(SOI -JPEG,JPEGL)

t-11 B

2 M 13.011-CGA 

Metadata 

JP2L

IF {13.011} EQ ASCII(JP2L) THEN

Present(SigBox)

t-11 B

2 M 13.011-CGA 

Metadata 

PNG

IF {13.011} EQ ASCII(PNG) THEN

Present(PNGSig)

t-11 B

2 M 13.011-CGA 

Metadata 

WSQ

IF {13.011} EQ ASCII(WSQ20) THEN

Present(SOI-WSQ)

t-11 B

Field: 

13.012-Bits 

Per Pixel 

8.13.12,

Table 66,

7.7.8.6

This field shall contain an entry of “8” for 

normal grayscale values of “0” to “255”. 

Any entry in this field greater than “8”

M 13.012-BPX <See Requirement ID “Field: Image BPX Value” > t-2
110

Value shall represent a grayscale pixel with 

increased proportion.

Field: 

13.012- Bits 

Per Pixel 

Metadata

8.13.12,

Table 66

<The BPX is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2 M 13.012-BPX 

Metadata 

JPEGL

{13.012} EQ {BPX-JPEG, JPEGL} t-11 B

2 M 13.012-BPX 

Metadata 

JP2L

{13.012} EQ {BPX-JP2,JP2L} t-11 B

2 M 13.012-BPX 

Metadata 

PNG

{13.012} EQ {BPX-PNG} t-11 B

M 13.012-BPX 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

13.013-

Friction 

Ridge 

Generalized 

Position 

Value

8.13.13,

Table 66,

7.7.4.2,

Table 6

See Section 7.7.4.2 and Table 6 for 

details.

1 M 13.013-FGP 

Value

{13.013} MO [0 to 38, 40 to 50, 60 to 79, 81 to 

84]

B

Field: 

13.013-

Friction 

Ridge 

Generalized 

Position 

Conditional

8.13.13,

Table 66

If code 19 is used, fields 13.014 and 

13.015 shall be used.

M 13.013-FGP 

Conditional

<See Requirement ID: “Field: SPD,PPC 

Conditional”>

t-2

Field: 

13.014-

Search 

Position 

Descriptors 

Value

8.13.14,

Table 66,

7.7.4.3

...described in Section 7.7.4.3 D 13.014-SPD 

Value

<See Requirement ID: “Field: SPD,PPD Values”> t-2

Field: 

13.014-

Search 

Position 

Descriptors 

Conditional

8.13.14,

Table 66

This field shall be present if and only if the 

finger position code “19” appears in Field

13.013: Friction ridge generalized position 

/ FGP.

D 13.014-SPD 

Conditional

<See Requirement ID: “Field: SPD,PPC 

Conditional”>

t-2

Field: 

13.015-Print 

Position 

Coordinates 

Value

8.13.15,

Table 66,

7.7.4.4

See section 7.7.4.4 D 13.015-PPC 

Value

<See Requirement IDs: “Field: PPC-Subfield 1”

through “Field: PPC-Subfields 5,6”.>

t-2

Field: 8.13.15, This field may be present if and only if the D 13.015-PPC <See Requirement ID: “Field: SPD,PPC t-2
111

13.015- Print 

Position 

Coordinates 

Conditional

Table 66 finger position code “19” appears in Field

13.013: Friction ridge generalized position 

/ FGP.

Conditional Conditional”>

Field: 

13.016-

Scanned 

Horizontal 

Pixel Scale 

Value

8.13.16,

Table 66,

7.7.8.7

See section 7.7.8 for details. O 13.016-

SHPS Value

<See Requirement IDs: “Field: Image SHPS 

Value”>

t-2

Field: 

13.017-

Scanned 

Vertical 

Pixel Scale 

Value

8.13.17,

Table 66,

7.7.8.8

See section 7.7.8 for details. O 13.016-

SVPS Value

<See Requirement IDs: “Field: Image SVPS 

Value”>

t-2

Field: 

13.018, 

13.019-

Reserved

Table 66 Reserved for future useonly by 

ANSI/NIST-ITL.

- 13.018, 

13.019-

Reserved

<See Requirement ID: “Field: Type13-

CondCode>.

t-2

Field: 

13.020-

Comment 

Value

8.13.17,

Table 66,

7.4.4

See section 7.4.4 for details. O 13.020-

COM Value

<See Requirement ID: “Field: Comment>. t-2

Field: 

13.021, 

13.023-

Reserved

Table 66 Reserved for future useonly by 

ANSI/NIST-ITL.

- 13.021, 

13.023-

Reserved

<See Requirement ID: “Field: Type13-

CondCode>.

t-2

Field: 

13.024-

Latent 

Quality 

Metric 

Value

Table 66,

Table 6,

8.13.19

The first information item shall be the 

friction ridge code/ FRC. See Section 7.7.7 

for a description of the remaining three 

information items. 

O 13.024-

LQM Value

<See Requirement IDs: “Field: Sample Quality 

Subfield 1”, “Field: Sample Quality Subfield 2”, 

“Field: Sample Quality Subfield 3”, “Field: Sample 

Quality Additional Subfield”>.

t-2

Field:

13.025, 

13.199-

Reserved

Table 66 Reserved for future useonly by 

ANSI/NIST-ITL.

- 13.025, 

13.199-

Reserved

<See Requirement ID: “Field: Type13-

CondCode>.

t-2

Field: 13.200 

to 13.900-

User 

Defined

Table 66 User Defined Fields - 13.200 to 

13.900-

User 

Defined

TRUE B

Field: 

13.901-

Reserved

Table 66 Reserved for future useonly by 

ANSI/NIST-ITL.

- 13.901-

Reserved

<See Requirement ID: “Field: Type13-

CondCode>.

t-2

Field: 8.13.21, This is an optional field, listing the O 13.902- <See Requirement ID: “Field: xx.902-ANN” >. t-2
112

13.902-

Annotated 

Information 

Value

Table 66 operations performed on the original 

source in order to prepare it for inclusion 

in a biometric record type. See Section 

7.4.1.

ANN-Value

Field: 

13.903-

Device 

Unique 

Identifier 

Value

8.13.22,

Table 66

This is an optional field. See Section 

7.7.1.1.

O 13.903-DUI 

Value

<See Requirement ID: “Field: Device ID” >.t-2

Field: 

13.904-

Make/Mode

l/Serial 

Number 

Value

8.13.23,

Table 66

This is an optional field. See Section 

7.7.1.2.

O 13.904-

MMS Value

<See Requirement ID: “Field: Make Model” >.t-2

Field: 

13.905, 

13.994-

Reserved

Table 66 Reserved for future useonly by 

ANSI/NIST-ITL.

- 13.905, 

13.994-

Reserved

<See Requirement ID: “Field: Type13-

CondCode>.

t-2

Field: 

13.995-

Associated 

Context 

Value

8.13.24,

Table 66

See Section 7.3.3O 13.995-ASC 

Value

<See Requirement IDs: “Field: xx.995-ASC” and 

“Field: xx.995-ASC-ACN” and

“Field: xx.995-ASC-ASP”>.

t-2

Field: 

13.996-

Hash Value

8.13.25,

Table 66

See Section 7.5.2O 13.996-HAS 

Value

<See Requirement ID: “Field: HAS”>t-2

Field: 

13.997-

Source 

Representati

on Value

8.13.26,

Table 66

See Section 7.3.2O 13.997-SOR 

Value

<See Requirement IDs: “Field: xx.997-SOR” and 

“Field: xx.997-SOR-SRN” and

“Field: xx.997-SOR-RSP”>.

t-2

Field: 

13.998-

Geographic 

Sample 

Acquisition 

Location 

Value

8.13.27,

Table 66

See Section 7.7.3O 13.998-

GEO Value

<See Requirement IDs: “Field: Geographic”, 

“Field: Geographic-Conditional”,“Field: 

Geographic-Subfield 1” through “Field: 

Geographic-Values-SubField 15” >.

t-2

Field: 

13.999-

Image Data 

Valid

8.13.28, 

Table 66

This is a mandatory field contains the 

image.

<The image metadata is checked for 

validity.>

2M 13.999-

DATA 

Uncompres

sed Valid 

IF {13.011} EQ ASCII(NONE) THEN

Length(13.999) EQ 13.006} * {13.007}

B

2M 13.999-

DATA 

IF {13.011} EQ ASCII(JPEGL) THEN

Present(JFIF, 

t-11B
113

JPEGL Valid SOI-JPEGB,JPEGL,

SOF-JPEGB,JPEGL,

EOI-JPEG, JPEGL)

2 M 13.999-

DATA JP2L 

Valid

IF {13.011} EQ ASCII(JP2L) THEN

Present(SigBox, 

HeadBox, 

ImgBox)

t-11 B

2 M 13.999-

DATA PNG 

Valid

IF {13.011} EQ ASCII(PNG) THEN

Present(PNGSig,

IHDR,

IDAT,

IEND)

t-11 B

2 M 13.999-

DATA WSQ 

Valid

IF {13.999} EQ ASCII(WSQ20) THEN

Present(SOI-WSQ,SOF-WSQ,SOB-WSQ,EOI-WSQ)

t-11 B

Field: 

13.999-

Image WSQ 

Version 3.1

7.7.9.1 Only version 3.1 or higher shall be used 

for compressing grayscale fingerprint data 

at 500 ppi class with a platen area of 2 

inches or greater in height. WSQ shall not 

be used for other than the 500 ppi class.

2 M 13.999-

DATA WSQ 

Version

IF {13.011} EQ ASCII(WSQ20) THEN

{Encoder Version } EQ 2

t-11 B
114

Table C.13 - Assertions for Record Type 14 - Fingerprint Image Record

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.14: Record Type-14: Fingerprint image record

Record: 

Type14-

Fingerprint 

Type

8.14 The Type-14 record shall contain and be 

used to exchange exemplar fingerprint 

image data, such as a rolled tenprint, an 

identification flat, or a complete friction 

ridge exemplar. All fingerprint 

impressions shall be acquired from a card, 

a single or multiple-finger flat-capture 

device, contactless fingerprint sensor that 

outputs 2D fingerprint images, or a livescan device. Captured images may be 

transmitted to agencies that will 

automatically extract the desired feature 

information from the images for matching 

purposes.

3 M Type14-

Fingerprint 

Type

<Not Tested. It is not feasible to test if the image 

represents an exemplar fingerprint or how the 

image was acquired.>

t-1 B

Field: 

Type14-

Subfield 

Occurrence

Table 67 <Table 67 specifies which fields contain 

subfields as well as the number of 

occurrences permitted.>

1 - Type14-

Subfields 

Zero

Count(Subfields in 14.[001 to 003, 005 to 012, 

016, 017, 020, 026, 027, 030, 031, 903, 996, 

999]) EQ 0

T

1 M 14.004-

Subfields

Count(US_Subfields in 14.004) EQ 1 OR 2 T

1 M 14.013-

Subfields

Count(US_Subfields in 14.013 ) EQ 1 T

1 D 14.014-

Subfields

Count(US_Subfields in 14.014) EQ 2 T

D 14.015-

Subfields

<See Requirement ID: “Field: PPC-Subfield 

Occurrences”>

t-2

1 O 14.018-

Subfields

Count(RS_Subfields in 14.018) MO [1 to 4]

AND

ForEach(RS_Subfield in 14.018)

{

Count(US_Subfields in RS_Subfield) EQ 2

}

T

1 D 14.021- Count(RS_Subfields in 14.021) MO [1 to 4] T
115

Subfields

AND

ForEach(RS_Subfield in 14.021) {

Count(US_Subfields in RS_Subfield) EQ 5 }

1O 14.022-

Subfields

Count(RS_Subfields in 14.022) MO [1 to 4]

AND

ForEach(RS_Subfield in 14.022) {

Count(US_Subfields in RS_Subfield) EQ 2 }

T

1O 14.023-

Subfields

Count(RS_Subfields in 14.023) MO [1 to 9]

AND

ForEach(RS_Subfield in 14.023) {

Count(US_Subfields in RS_Subfield) EQ 4 }

T

1O 14.024-

Subfields

Count(RS_Subfields in 14.024) MO [1 to 9]

AND

ForEach(RS_Subfield in 14.024) {

Count(US_Subfields in RS_Subfield) EQ 4 }

T

1O 14.025-

Subfields

Count(RS_Subfields in 14.025) MO [1 to 4]

AND

ForEach(RS_Subfield in 14.025) {

Count(US_Subfields in RS_Subfield) EQ 2 + 

2*{US_Subfield:2 in RS_Subfield} }

T

1O 14.902-

Subfields

Count(RS_Subfields in 14.902) GTE 1

AND

ForEach(RS_Subfield in 14.902) {

Count(US_Subfields in RS_Subfield) EQ 4

T
116

}

1 O 14.904-

Subfields

Count(US_Subfields in 14.904) EQ 3 T

1 O 14.995-

Subfields

Count(RS_Subfields in 14.995) MO [1 to 255]

AND

ForEach(RS_Subfield in 14.995)

{

Count(US_Subfields in RS_Subfield) EQ 1 OR 2

}

T

1 O 14.997-

Subfields

Count(RS_Subfields in 14.997) MO [1 to 255]

AND

ForEach(RS_Subfield in 14.997)

{

Count(US_Subfields in RS_Subfield) EQ 1 OR 2

}

T

O 14.998-

Subfields

<See Requirement ID: “Field: GeographicConditional”>t-2

Field: 

Type14-

CondCode

Table 67 <Table 67 specifies the Condition Code for 

each field.>

1 - Type14-

CondCode

Present(14.001 to 14.013, 14.999)

AND

NOT Present(14.019, 14.028, 14.029, 14.032 to 

14.199, 14.901, 14.905 to 14.994)

B

Field: 

14.014-Print 

Position 

Descriptors 

Dependent

Table 67,

8.14.14

This field shall be present if and only if the 

finger position code “19” appears in Field

14.013: Friction ridge generalized position 

/ FGP.

D 14.014-

CondCode 

Dependent

<See Requirement ID: “Field: PPD Conditional”> t-2

Field: 

14.015-Print 

Position 

Coordinates 

Dependent

Table 67,

8.14.15

This field may be present if and only if the 

finger position code “19” appears in Field

14.013: Friction ridge generalized position 

/ FGP. 

D 14.015-

CondCode 

Dependent

<See Requirement ID: “Field: PPD Conditional”> t-2

Field: 

14.021-

Finger 

Segment 

Position 

Dependent

Table 67, 

8.14.20

This optional field shall contain offsets to 

the locations of image segments 

containing the individual fingers within 

the flat images of simultaneous fingers 

from each hand or the two simultaneous 

thumbs. (FGP = 13, 14, 15 or 40-50 from 

Table 6 as entered in Field 14.013:

Friction ridge generalized position / FGP).

2 D 14.021-

CondCode 

Dependent

IF {US_Subfield:1 in RS_Subfield:1 in 14.013} MO 

[13 to 15, 40 to 50] THEN

Present(14.021)

B*
117

Field: 

14.027-

Stitched 

Image Flag 

Dependent

Table 67, 

8.14.20

This field signifies that images captured 

separately were stitched together to form 

a single image. This field is mandatory if 

an image has been stitched, and the value 

shall be set to 'Y'. Otherwise, this field 

shall not appear in the record.

3D 14.027-

CondCode 

Dependent

<Not Tested. It is not feasible to detect if the 

image was stitched.>

t-1B

Field: 

Type14-

CharType

8.14,

Table 67

<Table 67 specifies the Character Type for 

each field that contains no subfields.>

1- Type14-

CharType N

Bytes(14.[001,002,003, 005 to 010, 012, 016, 

017, 026, 031]) MO [0x30 to 0x39]

B

1- Type14-

CharType A

Bytes(14.[011, 027, 030]) [0x41 to 0x5A, 0x61 to 

0x7A]

B

1- Type14-

CharType U

Present(Bytes(14.020)B

1O 14.020-

CharType 

ANS

Bytes(14.020) MO [0x20, 0x7E]B

1O 14.903-

CharType 

Text ANS

Bytes{14.903} MO [0x20, 0x7E]B

1O 14.996-

CharType H

Bytes(10.996) MO [0x30 to 0x39,0x41 to 0x46, 

0x61 to 0x66]

B

Field: 

Type14-

Subfield

CharType

8.14,

Table 67

<Table 67 specifies the Character Type for 

each subfield.>

1M 14.004-

Subfield 

CharType U

Present( Bytes( US_Subfields:1,2 in 14.004 ) B*

1M 14.013-

Subfield 

CharType N

Bytes(All(US_Subfields in 14.013)) MO [0x30 to 

0x39]

B*

1D 14.014-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 14.014) {

Bytes(US_Subfield:1 in RS_Subfield) MO [0x30 to 

0x39]

AND

Bytes(US_Subfield:2 in RS_Subfield) MO [0x30 to 

0x39, 0x41 to 0x5A, 0x61 to 0x7A] }

B*

1D 14.015-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 14.015) {

Bytes(US_Subfields:1 in RS_Subfield)) MO [0x30 

to 0x39, 0x41 to 0x5A, 0x61 to 0x7A]

AND

Bytes(US_Subfields:2 in RS_Subfield)) MO [0x41 

to 0x5A, 0x61 to 0x7A]

AND

Bytes(US_Subfields:3 to 6 in RS_Subfield)) MO 

[0x30 to 0x39] }

B*

1O 14.018- ForEach(RS_Subfield in 14.018) B*
118

Subfield 

CharType 

AN

{

Bytes(US_Subfields:1 in RS_Subfield)) MO [0x30 

to 0x39]

AND

Bytes(US_Subfields:2 in RS_Subfield)) MO [0x41 

to 0x5A, 0x61 to 0x7A] }

1D 14.021-

Subfield 

CharType N

Bytes(All(US_Subfields in 14.021)) MO [0x30 to 

0x39]

B*

1O 14.022-

Subfield 

CharType N

Bytes(All(US_Subfields in 14.022)) MO [0x30 to 

0x39]

B*

1O 14.023-

Subfield 

CharType 

HN

ForEach(RS_Subfield in 14.023) {

Bytes(US_Subfields:1,2,4 in RS_Subfield)) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:3 in RS_Subfield)) MO [0x30 

to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1O 14.024-

Subfield 

CharType 

HN

ForEach(RS_Subfield in 14.024) {

Bytes(US_Subfields:1,2,4 in RS_Subfield)) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:3 in RS_Subfield)) MO [0x30 

to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1O 14.025-

Subfield 

CharType N

Bytes(All(US_Subfields in 14.025)) MO [0x30 to 

0x39]

B*

1O 14.902-

Subfield 

CharType 

ANU

ForEach(RS_Subfield in 14.902) {

Present(Bytes(US_Subfields:2 to 4 in 

RS_Subfield)) 

AND

Bytes(US_Subfield:1 in RS_Subfield) MO [0x30 to 

0x39,0x5A] }

B*

1O 14.904-

Subfield 

CharType U

Present(Bytes(All(US_Subfields in 14.904))) B*

1O 14.995-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 14.995)) MO [0x30 

to 0x39]

B*
119

1 O 14.997-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 14.997)) MO [0x30 

to 0x39]

B*

O 14.998-

Subfield 

CharType 

ANSU

<See Requirement ID: “Field: Geographic”> t-2

Field: 

Type14-

CharCount

Table 67 <Table 67 specifies the Character Count 

for each field that contains no subfields.>

1 M 14.001-

CharCount

DataLength(14.001) GTE 1 B

1 M 14.002-

CharCount

DataLength(14.002) EQ 1 OR 2 B

1 M 14.003-

CharCount

DataLength(14.003) EQ 1 OR 2 B

1 M 14.005-

CharCount

DataLength(14.005) EQ 8 B

1 M 14.006-

CharCount

DataLength(14.006) MO [2 to 5] B

1 M 14.007-

CharCount

DataLength(14.007) MO [2 to 5] B

1 M 14.008-

CharCount

DataLength(14.008) EQ 1 B

1 M 14.009-

CharCount

DataLength(14.009) MO [1 to 5] B

1 M 14.010-

CharCount

DataLength(14.010) MO [1 to 5] B

1 M 14.011-

CharCount

DataLength(14.011) MO [3 to 5] B

1 M 14.012-

CharCount

DataLength(14.012) EQ 1 OR 2 B

1 O 14.016-

CharCount

DataLength(14.016) MO [1 to 4] B

1 O 14.017-

CharCount

DataLength(14.017) MO [1 to 4] B

1 O 14.020-

CharCount

DataLength(14.020) MO [1 to 126] B

1 O 14.026-

CharCount

DataLength(14.026) MO [1 to 3] B

1 D 14.027-

CharCount

DataLength(14.027) EQ 1 B

1 O 14.030-

CharCount

DataLength(14.030) MO [8 to 10] B

1 O 14.031-

CharCount

DataLength(14.031) EQ 2 B
120

1 O 14.903-

CharCount

DataLength(14.903) MO [13 to 16] B

1 O 14.996-

CharCount

DataLength(14.995) EQ 64 B

1 M 14.999-

CharCount

DataLength(14.999) GTE 1 B

Field: 

Type14-

Subfield 

CharCount

Table 67 <Table 67 specifies the Character Count 

for each subfield.>

1 M 14.004-

Subfield 

CharCount

Length(All(US_Subfields in 14.004)) GTE 1 B*

1 M 14.013-

Subfield 

CharCount

Length(All(US_Subfields in 14.013)) EQ 1 OR 2 B*

1 D 14.014-

Subfield 

CharCount

Length(US_Subfield:1 in 14.014) EQ 1 OR 2

AND

Length(US_Subfield:2 in 14.014) EQ 3

B*

1 D 14.015-

Subfield 

CharCount

ForEach(RS_Subfield in 14.015)

{

Length(US_Subfields:1 in RS_Subfield) EQ 2 OR 3

AND

Length(US_Subfields:2 in RS_Subfield) EQ 3

AND

Length(US_Subfields:3 to 6 in RS_Subfield) MO 

[1 to 5]

}

B*

1 O 14.018-

Subfield 

CharCount

ForEach(RS_Subfield in 14.018)

{

Length(US_Subfields:1 in RS_Subfield) EQ 1 OR 2

AND

Length(US_Subfields:2 in RS_Subfield) EQ 2

}

B*

1 D 14.021-

Subfield 

CharCount

ForEach(RS_Subfield in 14.021)

{

Length(US_Subfields:1 in RS_Subfield) EQ 1 OR 2

AND

Length(US_Subfields:2 to 5 in RS_Subfield) MO 

[1 to 5]

}

B*

1 O 14.022-

Subfield 

CharCount

ForEach(RS_Subfield in 14.022)

{

Length(US_Subfields:1 in RS_Subfield) EQ 1 OR 2

AND

B*
121

Length(US_Subfields:2 to 5 in RS_Subfield)) MO 

[1 to 3] }

1O 14.023-

Subfield 

CharCount

ForEach(RS_Subfield in 14.023) {

Length(US_Subfields:1 in RS_Subfield) EQ 1 OR 2

AND

Length(US_Subfields:2 in RS_Subfield) MO [1 to 

3]

AND

Length(US_Subfields:3 in RS_Subfield) EQ 4

AND

Length(US_Subfields:4 in RS_Subfield) MO [1 to 

5] }

B*

1O 14.024-

Subfield 

CharCount

ForEach(RS_Subfield in 14.024) {

Length(US_Subfield:1 in RS_Subfield) EQ 1 OR 2

AND

Length(US_Subfields:2 in RS_Subfield) MO [1 to 

3]

AND

Length(US_Subfields:3 in RS_Subfield) EQ 4

AND

Length(US_Subfields:4 in RS_Subfield) MO [1 to 

5] }

B*

1O 14.025-

Subfield 

CharCount

ForEach(RS_Subfield in 14.025) {

Length(US_Subfields:1,2 in RS_Subfield) EQ 1 OR 2

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1O 14.902-

Subfield 

CharCount

ForEach(RS_Subfield in 14.902) {

Length(US_Subfield:1 in RS_Subfield) EQ 15

AND

Length(US_Subfields:2,3 in RS_Subfield) MO [1 

B*
122

to 64]

AND

Length(US_Subfield:4 in RS_Subfield) MO [1 to 

255] }

1O 14.904-

Subfield 

CharCount

Length(All(US_Subfields in 14.904) MO [1 to 50] B*

1O 14.995-

Subfield 

CharCount

ForEach(RS_Subfield in 14.995) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

1O 14.997-

Subfield 

CharCount

ForEach(RS_Subfield in 14.997) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

O 14.998-

Subfield 

CharCount

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type14-Field 

Occurrence

Table 67<Table 67 specifies the Field Occurrence 

for each field.>

1- Type14-

Occurrence 

Zero

Count(14.[019 ,028, 029, 032 to 199,901,905 to 

994]) EQ 0

B

1M Type14-

Occurrence 

One

Count(14.[001 to 013, 999]) EQ 1B

1- Type14-

Occurrence 

One or 

Fewer

Count(14.[014 to 018,020 to 027,030, 031, 902 

to 904, 995 to 998) LTE 1

B

Field: 

14.001-

Record 

Header 

Value

8.14.1,

Table 67,

7.1

Field 14.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

M 14.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.14.1,

C.10.12

The XML name for the Type-14 record is 

<itl:PackageFingerprintImageRecord>, 

and its <biom:RecordCategoryCode> 

element shall

have a value of “14”.

1M NIEM-

14.001-

Record 

Header

ForEach(XElm(itl:PackageFingerprintImageRecor

d) {

{XElm(biom:RecordCategoryCode)} EQ ASCII(14) }

X

Field: 

14.002-

Information 

Designation 

8.14.2,

Table 67,

7.3.1

This mandatory field shall be the IDC of 

this Type-14 record as found in the 

information item IDC of Field 1.003 

Transaction content/CNT. 

M 14.002-IDC <See Requirement IDs“Field: xx.002-IDC“and 

“Field: 1.003-Transaction Content Subfield 2 IDC 

Matches”>

t-2
123

Character

Value

Field: 

14.003-

Impression 

Type

Value

8.14.3,

Table 67,

7.7.4.1

This mandatory field shall indicate the 

manner by which the latent print was 

obtained.

See Section 7.7.4.1 for details.

<Table 67 lists the valid values for IMP.>

1M 14.003-IMP {14.003} MO [0 to 3, 8, 20 to 29]B

Field: 

14.004-

Originating 

Agency 

Value

8.14.4,

7.6

This is a mandatory field. See Section 7.6 

for details.

M 14.004-

ORG

<See Requirement ID “Field: Agency Codes”>t-2

Field: 

14.005-

Fingerprint 

Capture 

Date Value

8.14.5,

7.7.2.3

This mandatory field shall contain the 

date that the fingerprint data contained 

in the record was captured.

1M 14.005-FCD {14.005} MO [ValidLocalDate]t-6T

1M NIEM-

14.005-FCD

ForEach(XElm(itl:PackageFingerprintRecord)) {

{XElm(nc:Date) in XElm(biom:CaptureDate)} MO 

[NIEM-ValidLocalDate]

}

t-6X

Field: 

14.006-

Horizontal 

Line Length 

Value

8.14.6,

Table 67,

7.7.8.1

The maximum horizontal size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types. The 

minimum value is 10 pixels.

M 14.006-HLL <See Requirement ID “Field: Image HLL Value”>t-2

Field: 

14.006-

Horizontal 

Line Length 

Metadata

8.14.6,

Table 67,

7.7.8.1

<The HLL is verified by checking the image 

metadata if compression is used.>

2M 14.006-HLL 

Metadata 

JPEGB,JPEG L

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{14.006} EQ {ImageWidth-JPEGB,JPEGL}

t-11B

2M 14.006-HLL 

Metadata 

JP2,JP2L

IF {14.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{14.006} EQ {ImageWidth-JP2,JP2L}

t-11B

2M 14.006-HLL 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) THEN

{14.006} EQ {ImageWidth-PNG}

t-11B

2M 14.006-HLL 

Metadata 

WSQ

IF {14.011} EQ ASCII(WSQ20) THEN

{14.006} EQ {ImageWidth-WSQ}

t-11B

Field: 

14.007-

Vertical Line 

Length 

Value

8.14.7,

Table 67,

7.7.8.2

The maximum vertical size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types.

The minimum value is 10 pixels.

M 14.007-VLL <See Requirement ID “Field: Image VLL Value”>t-2

Field: 

14.007-

Vertical Line 

Length 

8.14.7,

Table 67,

7.7.8.2

<The VLL is verified by checking the image 

metadata if compression is used.>

2M 14.007-VLL 

Metadata 

JPEGB, 

JPEGL

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{14.007} EQ {ImageHeight-JPEGB,JPEGL}

t-11B
124

Metadata2M 14.007-VLL 

Metadata 

JP2, JP2L

IF {14.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{14.007} EQ {ImageHeight-JP2,JP2L}

t-11B

2M 14.007-VLL 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) THEN

{14.007} EQ {ImageHeight-PNG}

t-11B

2M 14.006-VLL 

Metadata 

WSQ

IF {14.011} EQ ASCII(WSQ20) THEN

{14.007} EQ {ImageHeight-WSQ}

t-11B

Field: 

14.008-Scale 

Units Value

8.14.8,

Table 67,

7.7.8.3

<Table 67 lists the value constraints for 

SLC>

M 14.008-SLC <See Requirement ID “Field: Image SLC Value”>t-2

Field: 

14.008-

Scale Units 

Metadata

8.14.8,

Table 67,

7.7.8.3

A value of “1” shall indicate pixels per 

inch.

A value of “2” shall indicate pixels per 

centimeter. A value of “0” in this field 

indicates that no scale is provided, and 

the quotient of THPS/TVPS shall provide 

the pixel aspect ratio.

<The SLC is verified by checking the image 

metadata if compression is used.>

2M 14.008-SLC 

Metadata 

JPEGB,JPEG L

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN {14.008} EQ {SamplingUnits-JPEGB,JPEGL}

t-11B

14.008-SLC 

Metadata 

JP2,JP2L

<Not Tested.>t-12B

2M 14.008-SLC 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) THEN

IF {14.008} EQ 1 OR 2 THEN { SamplingUnits-

PNG} EQ 1, ELSE IF {14.008} EQ 0 THEN { 

SamplingUnits-PNG} EQ 0

t-11B

14.008-SLC 

Metadata 

WSQ

<Not Tested.>t-12B

Field: 

14.009-

Transmitted 

Horizontal 

Pixel Scale 

Value

8.14.9,

Table 67,

7.7.8.4

<Table 67 lists the value constraints for 

THPS.>

M 14.009-

THPS

<See Requirement ID “Field: Image THPS Value”

>

t-2

Field: 

14.009-

Transmitted 

Horizontal 

Pixel Scale 

Metadata

8.14.9,

Table 67,

7.7.8.4

This is the integer pixel density used in 

the horizontal direction of the image if 

SLC has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the horizontal component of the 

pixel aspect ratio, up to 5 digits. 

<The THPS is verified by checking the 

image metadata if compression is used.>

2M 14.009-

THPS 

Metadata 

JPEGB,JPEG L

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{14.008} EQ 1 OR 2

THEN {14.009} EQ {HorizontalDensity-

JPEGB,JPEGL}

t-11B

14.009-

THPS 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 14.009-

THPS 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) AND {14.008} EQ 1 

THEN {14.009} EQ {HorizontalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF {14.011} EQ ASCII(PNG) AND {14.008} EQ 

t-11B
125

2

THEN {14.009} EQ {HorizontalDensity-PNG} * 

0.01 (meters/cm)

14.009-

THPS 

Metadata 

WSQ

<Not Tested.> t-12 B

2 M 14.009-

THPS 

Aspect 

Ratio 

Metadata 

JPEGB,JPEG

L

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{14.008} NEQ 1 OR 2

THEN {14.009}/{14.010} EQ {HorizontalDensityJPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

t-11 B

14.009-

THPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.> t-12 B

2 M 14.009-

THPS 

Aspect 

Ratio 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) AND {14.008} NEQ 1 

OR 2

THEN {14.009}/{14.010} EQ {HorizontalDensityPNG} / {VerticalDensity-PNG}

t-11 B

14.009-

THPS 

Aspect 

Ratio 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

14.010-

Transmitted 

Vertical 

Pixel Scale 

Value

8.14.10,

Table 67,

7.7.8.5

<Table 67 lists the value constraints for 

TVPS.>

M 14.010-

TVPS

<See Requirement ID “Field: Image TVPS Value”

>

t-2

Field: 

14.010-

Transmitted 

Vertical 

Pixel Scale 

Metadata

8.14.10,

Table 67,

7.7.8.5

This is the integer pixel density used in 

the Vertical direction of the image if SLC 

has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the Vertical component of the 

pixel aspect ratio, up to 5 digits.

<The TVPS is verified by checking the 

2 M 14.010-

TVPS 

Metadata 

JPEGB,JPEG

L

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

AND{14.008} EQ 1 OR2 

THEN 

{14.010} EQ {VerticalDensity-JPEGB,JPEGL}

t-11 B

14.010-

TVPS 

Metadata 

<Not Tested.> t-12 B
126

image metadata if compression is used.> JP2, JP2L

2 M 14.010-

TVPS 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG)) AND {14.008} EQ 1 

THEN {14.010} EQ {VerticalDensity-PNG} * 

0.0254 (meters/inch),

ELSE IF {14.011} EQ ASCII(PNG)) AND {14.008} EQ 

2

THEN {14.010} EQ {VerticalDensity-PNG} * 0.01 

(meters/cm)

t-11 B

14.010-

TVPS 

Metadata 

WSQ

<Not Tested.> t-12 B

2 M 14.010-

TVPS 

Aspect 

Ratio 

Metadata 

JPEGB,JPEG

L

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{14.008} NEQ 1 OR 2

THEN {14.009}/{14.010} EQ {HorizontalDensityJPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

t-11 B

14.010-

TVPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.> t-12 B

2 M 14.010-

TVPS 

Aspect 

Ratio 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) AND{14.008} NEQ 1 

OR 2

THEN {14.009}/{14.010} EQ {HorizontalDensity -

PNG} / {VerticalDensity-PNG}

t-11 B

14.010-

TVPS 

Aspect 

Ratio 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

14.011-

Compressio

n Algorithm 

Value

8.14.11,

Table 67,

7.7.9.1

For each of these fields, the entry 

corresponds to the appropriate Label 

entry in Table 12: Field 14.011: 

Compression algorithm / CGA.

1 M 14.011-CGA {14.011} MO [ASCII(NONE, JPEGB, JPEGL, JP2, 

JP2L, PNG, WSQ)]

t-98 B

Field: 

14.011-

Compressio

8.14.11,

Table 67

<The CGA is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2 M 14.011-

CGAMetad

ata 

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

Present(SOI -JPEG,JPEGL)

t-11 B
127

n Algorithm 

Metadata

JPEGB,JPEG L

2M 14.011-CGA 

Metadata 

JP2, JP2L

IF {14.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox)

t-11B

2M 14.011-CGA 

Metadata 

PNG

IF {14.011} EQ ASCII(PNG) THEN

Present(PNGSig)

t-11B

2M 14.011-CGA 

Metadata 

WSQ

IF {14.011} EQ ASCII(WSQ20) THEN

Present(SOI-WSQ)

t-11B

Field: 

14.012-Bits 

Per Pixel 

Value

8.14.12,

Table 67,

7.7.8.6

This field shall contain an entry of “8” for 

normal grayscale values of “0” to “255”. 

Any entry in this field greater than “8”

shall represent a grayscale pixel with 

increased proportion.

M 14.012-BPX <See Requirement ID “Field: Image BPX Value”>t-2

Field: 

14.012- Bits 

Per Pixel 

Metadata

8.14.12,

Table 67

<The BPX is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2M 14.012-BPX 

Metadata 

JPEGB,JPEG L

{14.012} EQ {BPX-JPEG, JPEGL}t-11B

2M 14.012-BPX 

Metadata 

JP2, JP2L

{14.012} EQ {BPX-JP2,JP2L}t-11B

2M 14.012-BPX 

Metadata 

PNG

{14.012} EQ {BPX-PNG}t-11B

14.012-BPX 

Metadata 

WSQ

<Not Tested.>t-12B

Field: 

14.013-

Friction 

Ridge 

Generalized 

Position 

Value

8.14.13,

Table 67,

7.7.4.2,

Table 6

See Section 7.7.4.2 for details.1M 14.013-FGP 

Value

{14.013} MO [1 to 19, 33 to 36, 40 to 50]B

Field: 

14.014-

Search 

Position 

Descriptors 

Value

8.14.14,

Table 67,

7.7.4.3

...described in Section 7.7.4.3D 14.014-PPD 

Value

<See Requirement ID: “Field: SPD,PPD Values”>t-2

Field: 

14.014-

Search 

Position 

8.14.14,

Table 67

This field shall be present if and only if the 

finger position code “19” appears in Field

14.013: Friction ridge generalized position 

/ FGP.

D 14.014-PPD 

Conditional

<See Requirement ID: “Field: PPD Conditional”>t-2
128

Descriptors 

Conditional

Field: 

14.015-Print 

Position 

Coordinates 

Value

8.14.15,

Table 67,

7.7.4.4

See section 7.7.4.4D 14.015-PPC 

Value

<See Requirement IDs: “Field: PPC-Subfield 1”

through “Field: PPC

-Subfields 5,6”.>

t-2

Field: 

14.015- Print 

Position 

Coordinates 

Conditional

8.14.15,

Table 67

This field may be present if and only if the 

finger position code “19” appears in Field

14.013: Friction ridge generalized position 

/ FGP.

D 14.015-PPC 

Conditional

<See Requirement ID: “Field: SPD,PPC 

Conditional”>

t-2

Field: 

14.016-

Scanned 

Horizontal 

Pixel Scale 

Value

8.14.16,

Table 67,

7.7.8.7

See section 7.7.8 for details. O 14.016-

SHPS Value

<See Requirement IDs: “Field: Image SHPS 

Value”>

t-2

Field: 

14.017-

Scanned 

Vertical 

Pixel Scale 

Value

8.14.17,

Table 67,

7.7.8.8

See section 7.7.8 for details. O 14.016-

SVPS Value

<See Requirement IDs: “Field: Image SVPS 

Value”>

t-2

Field: 

14.018-

Amputated 

Or 

Bandaged 

Value

8.14.18,

Table 67,

Table 68

<Table 67 lists the value constraints for 

AMP.>

1M⇑14.018-

Subfield 1-

FGP

ForEach(RS_Subfield in 14.018) {

{US_Subfield:1 in RS_Subfield} MO [1 to 10, 

16,17] }

B*

1M⇑14.018-

Subfield 2-

FMC

ForEach(RS_Subfield in 14.018) {

{US_Subfield:2 in RS_Subfield} MO [ASCII( 

XX,UP)] }

B*

Field: 

14.019-

Reserved

Table 67 Reserved for future useonly by 

ANSI/NIST-ITL.

- 14.019-

Reserved

<See Requirement ID: “Field: Type14-

CondCode>.

t-2

Field: 

14.020-

Comment 

Value

8.14.19,

Table 67,

7.4.4

See section 7.4.4 for details. O 14.020-

COM

<See Requirement ID: “Field: Comment>.t-2

Field: 

14.021-

Fingerprint 

Segment 

Position 

8.14.20,

Table 67,

Table 6

<Table 67 lists the value constraints for 

SEG.>

1M⇑14.021-

Subfield 1-

FGP

ForEach(RS_Subfield in 14.021) {

{US_Subfield:1 in RS_Subfield} MO [1 to 10, 

16,17] }

B*
129

Value2M⇑14.021-

Subfield 2-

LHC

ForEach(RS_Subfield in 14.021) {

{US_Subfield:2 in RS_Subfield} LTE {14.006} }

B*

2M⇑14.021-

Subfield 3-

LHC

ForEach(RS_Subfield in 14.021) {

{US_Subfield:3 in RS_Subfield} LTE {14.006} AND 

GTE {US_Subfield:2 in 14.021} }

B*

2M⇑14.021-

Subfield 4-

LHC

ForEach(RS_Subfield in 14.021) {

{US_Subfield:4 in RS_Subfield} LTE {14.007} }

B*

2M⇑14.021-

Subfield 5-

LHC

ForEach(RS_Subfield in 14.021) {

{US_Subfield:2 in RS_Subfield} LTE {14.007} AND 

GTE {US_Subfield:4 in 14.021} }

B*

Field: 

14.021-

Fingerprint 

Segment 

Position 

Conditional

8.14.15,

Table 67

This optional field shall contain offsets to 

the locations of image segments 

containing the individual fingers within 

the flat images of simultaneous fingers 

from each hand or the two simultaneous 

thumbs. (FGP = 13, 14, 15 or 40-50 from 

Table 6 as entered in Field 14.013:

Friction ridge generalized position / FGP).

D 14.021-SEG 

Conditional

<See Requirement ID: “Field: 14.021-Finger 

Segment Position Dependent”>

t-2

Field: 

14.022-NIST 

Quality 

Metric 

Value

8.14.21,

Table 67,

Table 6

<Table 67 lists the value constraints for 

NQM.>

1M⇑14.022-

Subfield 1-

FGP

ForEach(RS_Subfield in 14.022) {

{US_Subfield:1 in RS_Subfield} MO [1 to 10, 

16,17] }

B*

1M⇑14.022-

Subfield 2-

IQS

ForEach(RS_Subfield in 14.022) {

{US_Subfield:2 in RS_Subfield} MO [1 to 5, 254, 

255] }

B*

Field: 

14.023-

Segmentatio

n Qualtiy 

Metric 

Value

8.14.22,

Table 67,

Table 6

<Table 67 lists the value constraints for 

SQM.>

M⇑14.023-

SQM

<See Requirement ID: “Field: Sample Quality 

Occurrences”, “Field: Sample Quality Subfield 1”, “Field: Sample Quality Subfield 2”, and “Field: 

Sample Quality Subfield 3”.>

t-2

Field: 

14.024-

Finger 

Quality 

8.14.23,

Table 67,

Table 6

<Table 67 lists the value constraints for 

FQM.>

O 14.024-

FQM

<See Requirement ID: “Field: Sample Quality 

Occurrences”, “Field: Sample Quality Subfield 1”, “Field: Sample Quality Subfield 2”, and “Field: 

Sample Quality Subfield 3”.>

t-2
130

Metric 

Value

Field: 

14.025-

Alternate 

Finger 

Segment 

Position(s) 

Value

8.14.24,

Table 67,

Table 6

<Table 67 lists the value constraints for 

ASEG.>

1M⇑14.025-

Subfield 1 -

FGP

ForEach(RS_Subfield in 14.025) {

{US_Subfield:1 in RS_Subfield} MO [1 to 10, 16, 

17] }

B*

1M⇑14.025-

Subfield 2-

NOP

ForEach(RS_Subfield in 14.025) {

{US_Subfield:2 in RS_Subfield} MO [3 to 99] }

B*

2M⇑14.025-

Subfield 

Pair

ForEach(RS_Subfield in 14.025) {

For(X EQ 3 to {US_Subfield:2 in RS_Subfield}) {

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{14.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{14.006} }}

B*

Field: 

14.025-

Alternate 

Finger 

Segment 

Position(s) 

Polygon

8.14.24,

Table 67,

Section 

7.8

The order of the vertices shall be in their 

consecutive order around the perimeter of the polygon, either clockwise or 

counterclockwise. 

2O 14.025-

ASEG Order

<Angle.Direction.First EQ ((X,Y).1 To

(X,Y).2).Angle.Direction; ((X,Y).2 To N‐

1 to (X,Y).3 To N).Angle.Direction EQ

Angle.Direction.First; ((X,Y).N To

(X,Y).1).Angle.Direction EQ

Angle.Direction.First.>

B*

No two vertices may occupy the same 

location.

2O 14.025-

ASEG 

Polygon

<Each Vertex (X, Y) is unique> B*

The polygon side defined by the last 

vertex and the first vertex shall complete 

the polygon.

The polygon shall be a simple, plane 

figure with no sides crossing and no 

interior holes.

2O 14.025-

ASEG 

Polygon

<Not Tested.>t-14

Field: 

14.026-

Simultaneou

s Capture 

Value

8.14.25,

Table 67

<Table 67 lists the value constraints for 

SCF.>

1O 14.026-SCF {14.026} MO [1 to 255]B

Field: 

14.027-

Stitched 

8.14.26,

Table 67

<Table 67 lists the value constraints for 

SCF.>

1D 14.027-SIF {14.027} EQ ASCII(Y)B
131

Image Flag 

Value

Field: 

14.027-

Stitched 

Image Flag 

Conditional

8.14.26,

Table 67

This field signifies that images captured 

separately were stitched together to form 

a single image. This field is mandatory if 

an image has been stitched, and the value 

shall be set to 'Y'. Otherwise, this field 

shall not appear in the record.

D 14.027-SIF 

Conditional <See Requirement ID: “Field: 14.027-Stitched 

Image Flag Dependent”>

t-2

Field: 

14.028, 

14.029-

Reserved

Table 67 Reserved for future useonly by 

ANSI/NIST-ITL.

- 14.028, 

14.029 

Reserved

<See Requirement ID: “Field: Type14-

CondCode>.

t-2

Field: 

14.030-

Device 

Monitoring 

Mode Value

8.14.27,

Table 67

<Table 67 lists the value constraints for 

DMM.>

1O 14.030-

DMM

{14.030} MO ASCII(CONTROLLED, ASSISTED, 

OBSERVED, UNATTENDED, UNKNOWN)

B

Field: 

14.031-

Subject 

Acquisition 

Profile-

Fingerprint 

Value

8.14.28,

Table 67

<Table 67 lists the value constraints for 

FAP.>

1O 14.031-FAP {14.031} MO [10, 20, 30, 40, 45, 50, 60]B

Field: 14.032 

to 14.199-

Reserved

Table 67 Reserved for future useonly by 

ANSI/NIST-ITL.

- 14.032 to 

14.199 

Reserved

<See Requirement ID: “Field: Type14-

CondCode>.

t-2

Field: 14.200 

to 14.900-

User 

Defined

Table 67 User Defined Fields- 14.200 to 

14.900-

User 

Defined

TRUEB

Field: 

14.901-

Reserved

Table 67 Reserved for future useonly by 

ANSI/NIST-ITL.

- 14.901-

Reserved

<See Requirement ID: “Field: Type14-

CondCode>.

t-2

Field: 

14.902-

Annotated 

Information 

Value

8.14.30,

Table 67

This is an optional field, listing the 

operations performed on the original 

source in order to prepare it for inclusion 

in a biometric record type. See Section 

7.4.1.

O 14.902-

ANN-Value

<See Requirement ID: “Field: xx.902-ANN” >.t-2

Field: 

14.903-

Device 

Unique 

Identifier 

Value

8.14.31,

Table 67

This is an optional field. See Section 

7.7.1.1.

O 14.903-DUI 

Value

<See Requirement ID: “Field: Device ID” >.t-2

Field: 8.14.32, This is an optional field. See Section O 14.904- <See Requirement ID: “Field: Make Model” >.t-2
132

14.904-

Make/Mode

l/Serial 

Number 

Value

Table 67 7.7.1.2. MMS Value

Field: 

14.905, 

14.994-

Reserved

Table 67 Reserved for future useonly by 

ANSI/NIST-ITL.

- 14.905, 

14.994-

Reserved

<See Requirement ID: “Field: Type14-

CondCode>.

t-2

Field: 

14.995-

Associated 

Context 

Value

8.14.33,

Table 67

See Section 7.3.3O 14.995-ASC 

Value

<See Requirement IDs: “Field: xx.995-ASC” and 

“Field: xx.995-ASC-ACN” and

“Field: xx.995-ASC-ASP”>.

t-2

Field: 

14.996-

Hash Value

8.14.34,

Table 67

See Section 7.5.2O 14.996-HAS 

Value

<See Requirement ID: “Field: HAS”>t-2

Field: 

14.997-

Source 

Representati

on Value

8.14.35,

Table 67

See Section 7.3.2O 14.997-SOR 

Value

<See Requirement IDs: “Field: xx.997-SOR” and 

“Field: xx.997-SOR-SRN” and

“Field: xx.997-SOR-RSP”>.

t-2

Field: 

14.998-

Geographic 

Sample 

Acquisition 

Location 

Value

8.14.36,

Table 67

See Section 7.7.3O 14.998-

GEO Value

<See Requirement IDs: “Field: Geographic”, 

“Field: Geographic-Conditional”,“Field: 

Geographic-Subfield 1” through “Field: 

Geographic-Values-SubField 15” >.

t-2

Field: 

14.999-

Image Data 

Valid

8.14.37, 

Table 67

This is a mandatory field contains the 

image.

<The image metadata is checked for 

validity.>

2M 14.999-

DATA 

Uncompres

sed Valid 

IF {14.011} EQ ASCII(NONE) THEN

Length(14.999) EQ 14.006} * {14.007}

B

2M 14.999-

DATA 

JPEGB,JPEG

L Valid

IF {14.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

Present(JFIF, 

SOI-JPEGB,JPEGL,

SOF-JPEGB,JPEGL,

EOI-JPEG, JPEGL)

t-11B

2M 14.999-

DATA 

JP2,JP2L 

Valid

IF {14.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox, 

HeadBox, 

ImgBox)

t-11B

2M 14.999-

DATA PNG 

Valid

IF {14.011} EQ ASCII(PNG) THEN

Present(PNGSig,

IHDR,

t-11B
133

IDAT,

IEND)

2 M 14.999-

DATA WSQ 

Valid

IF {14.999} EQ ASCII(WSQ20) THEN

Present(SOI-WSQ,SOF-WSQ,SOB-WSQ,EOI-WSQ)

t-11 B

Field: 

14.999-

Image WSQ 

Version 3.1

7.7.9.1 Only version 3.1 or higher shall be used 

for compressing grayscale fingerprint data 

at 500 ppi class with a platen area of 2 

inches or greater in height. WSQ shall not 

be used for other than the 500 ppi class.

2 M 14.999-

DATA WSQ 

Version

IF {14.011} EQ ASCII(WSQ20) THEN

{Encoder Version } EQ 2

t-11 B

Table C.14 - Assertions for Record Type 15 - Palm Print Image Record

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.15: Record Type-15: Palm print image record

Record: 

Type15-

Palm Print 

Image

8.15 The Type-15 record shall contain and be 

used to exchange palm print image data 

together with fixed and user-defined 

textual information fields pertinent to the 

digitized image. 

The image data shall be acquired directly 

from a subject using a live-scan device, a 

palmprint card, or other media that 

contains the subject using a live-scan 

device, aag

3 M Type15-

Palm Print 

Image

<Not Tested. It is not feasible to test if the image 

represents a palm print or how the image was 

captured.>

t-1 B

Record: 

Type15-

Palm Print 

Area

8.15 Any method used to acquire the palm 

print images shall be capable of capturing 

a set of images for each hand. This set 

may include the writerl be capable of 

capturing a set of

3 M Type15-

Palm Print 

Area

<Not Tested. It is not feasible to test which area 

of the palm is represented in the image.>

t-1 B
134

and the entire area of the full palm 

extending from the wrist bracelet to the 

tips of the fingers as one or two scanned 

images. (See Figure 1)

If two images are used to represent the 

full palm, the lower image shall extend 

from the wrist bracelet to the top of the 

interdigital area (third finger joint) and 

shall include the thenar, and hypothenar 

areas of the palm. The upper image shall 

extend from the bottom of the 

interdigital area to the upper tips of the 

fingers. This provides an adequate 

amount of overlap between the two 

images.

Field: 

Type15-

Subfield 

Occurence

Table 69 <Table 69 specifies which fields contain 

subfields as well as the number of 

occurrences permitted.>

1- Type15-

Subfields 

Zero

Count(Subfields in 15.[001 to 003, 005 to 013, 

016, 017, 020, 030, 903, 996, 999]) EQ 0

T

1M 15.004-

Subfields

Count(US_Subfields in 15.004) EQ 1 OR 2T

1O 15.024-

Subfields

Count(RS_Subfields in 15.024) MO [1 to 9]

AND

ForEach(RS_Subfield in 15.024) {

Count(US_Subfields in RS_Subfield) EQ 4 }

T

O 15.902-

Subfields

Count(RS_Subfields in 15.902) GTE 1

AND

ForEach(RS_Subfield in 15.902) {

Count(US_Subfields in RS_Subfield) EQ 4 }

T

1O 15.904-

Subfields

Count(US_Subfields in 15.904) EQ 3T

1O 15.995-

Subfields

Count(RS_Subfields in 15.995) MO [1 to 255]

AND

ForEach(RS_Subfield in 15.995) {

Count(US_Subfields in RS_Subfield) EQ 1 OR 2

T
135

}

1O 15.997-

Subfields

Count(RS_Subfields in 15.997) MO [1 to 255]

AND

ForEach(RS_Subfield in 15.997) {

Count(US_Subfields in RS_Subfield) EQ 1 OR 2 }

T

O 15.998-

Subfields

<See Requirement ID: “Field: Geographic-

Conditional”>

t-2

Field: 

Type15-

CondCode

Table 69 <Table 69 specifies the Condition Code for 

each field.>

1- Type15-

CondCode

Present(15.001 to 15.013, 15.999)

AND

NOT Present(15.014, 15.015, 15.018, 15.019, 

15.021 to 15.023, 15.025 to 15.029, 15.031 to 

15.199, 15.901, 15.905 to 15.994)

B

Field: 

Type15-

CharType

8.15,

Table 69

<Table 69 specifies the Character Type for 

each field that contains no subfields.>

1- Type15-

CharType N

Bytes(15.[001 to 003, 005 to 010, 012, 013, 016, 

017]) MO [0x30 to 0x39]

B

1- Type15-

CharType A

Bytes(15.030) [0x41 to 0x5A, 0x61 to 0x7A]B

1- Type15-

CharType U

Present(Bytes(15. 020))B

1M 15.011-

CharType 

AN

Bytes(15.011) MO [0x30 to 0x39, 0x41 to 0x5A, 

0x61 to 0x7A]

B

1O 15.025-

CharType 

NS

Bytes(15.025) MO [0x1E, 0x1F, 0x30 to 0x39]B

1O 15.903-

CharType 

Text ANS

Bytes{15.903} MO [0x20, 0x7E]B

1O 15.996-

CharType H

Bytes(10.996) MO [0x30 to 0x39,0x41 to 0x46, 

0x61 to 0x66]

B

Field: 

Type15-

Subfield

CharType

8.15,

Table 69

<Table 69 specifies the Character Type for 

each subfield.>

1M 15.004-

Subfield 

CharType U

Present( Bytes( US_Subfields:1,2 in 15.004 ) B*

1O 15.024-

Subfield 

CharType 

HN

ForEach(RS_Subfield in 15.024) {

Bytes(US_Subfields:1,2,4 in RS_Subfield)) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:3 in RS_Subfield)) MO [0x30 

to 0x39,0x41 to 0x46, 0x61 to 0x66]

B*
136

}

1O 15.902-

Subfield 

CharType 

ANU

ForEach(RS_Subfield in 15.902) {

Present(Bytes(US_Subfields:2 to 4 in 

RS_Subfield)) 

AND

Bytes(US_Subfield:1 in RS_Subfield) MO [0x30 to 

0x39,0x5A] }

B*

1O 15.904-

Subfield 

CharType U

Present(Bytes(All(US_Subfields in 15.904))) B*

1O 15.995-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 15.995)) MO [0x30 

to 0x39]

B*

1O 15.997-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 15.997)) MO [0x30 

to 0x39]

B*

O 15.998-

Subfield 

CharType 

ANSU

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type15-

CharCount

Table 69 <Table 69 specifies the Character Count 

for each field that contains no subfields.>

1M 15.001-

CharCount

DataLength(15.001) GTE 1B

1M 15.002-

CharCount

DataLength(15.002) EQ 1 OR 2B

1M 15.003-

CharCount

DataLength(15.003) EQ 2B

1M 15.005-

CharCount

DataLength(15.005) EQ 8B

1M 15.006-

CharCount

DataLength(15.006) MO [2 to 5]B

1M 15.007-

CharCount

DataLength(15.007) MO [2 to 5]B

1M 15.008-

CharCount

DataLength(15.008) EQ 1B

1M 15.009-

CharCount

DataLength(15.009) MO [1 to 5]B

1M 15.010-

CharCount

DataLength(15.010) MO [1 to 5]B

1M 15.011-

CharCount

DataLength(15.011) MO [3 to 5]B

1M 15.012-

CharCount

DataLength(15.012) EQ 1 OR 2B
137

1M 15.013-

CharCount

DataLength(15.013) EQ 2B

1O 15.016-

CharCount

DataLength(15.016) MO [1 to 4]B

1O 15.017-

CharCount

DataLength(15.017) MO [1 to 4]B

1O 15.020-

CharCount

DataLength(15.020) MO [1 to 126]B

1O 15.030-

CharCount

DataLength(15.030) MO [8 to 10]B

1O 15.903-

CharCount

DataLength(15.903) MO [13 to 16]B

1O 15.996-

CharCount

DataLength(15.995) EQ 64B

1M 15.999-

CharCount

DataLength(15.999) GTE 1B

Field: 

Type15-

Subfield 

CharCount

Table 69 <Table 69 specifies the Character Count 

for each subfield.>

1M 15.004-

Subfield 

CharCount

Length(All(US_Subfields in 15.004)) GTE 1 B*

1O 15.024-

Subfield 

CharCount

ForEach(RS_Subfield in 15.024) {

Length(US_Subfield:1 in RS_Subfield)) EQ 1 OR 2

AND

Length(US_Subfields:2 in RS_Subfield)) MO [1 to 

3]

AND

Length(US_Subfields:3 in RS_Subfield)) EQ 4

AND

Length(US_Subfields:4 in RS_Subfield)) MO [1 to 

5] }

B*

1O 15.902-

Subfield 

CharCount

ForEach(RS_Subfield in 15.902) {

Length(US_Subfield:1 in RS_Subfield) EQ 15

AND

Length(US_Subfields:2,3 in RS_Subfield) MO [1 

to 64]

AND

Length(US_Subfield:4 in RS_Subfield)) MO [1 to 

255] }

B*

1O 15.904-

Subfield 

CharCount

Length(All(US_Subfields in 15.904)) MO [1 to 50] B*

1O 15.995- ForEach(RS_Subfield in 15.995) B*
138

Subfield 

CharCount

{

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

1O 15.997-

Subfield 

CharCount

ForEach(RS_Subfield in 15.997) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

O 15.998-

Subfield

CharCount

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type15-Field 

Occurrence

Table 69 <Table 69 specifies the Field Occurrence 

for each field.>

1- Type15-

Occurrence 

Zero

Count(15.[014, 015, 018, 019, 021 to 023, 025 to 

029, 031 to 199,901,905 to 994]) EQ 0

B

1M Type15-

Occurrence 

One

Count(15.[001 to 013, 999]) EQ 1B

1- Type15-

Occurrence 

One or 

Fewer

Count(15.[016, 017, 020, 024, 030, 902 to 904, 

995 to 998) LTE 1

B

Field: 

15.001-

Record 

Header 

Value

8.15.1,

Table 69,

7.1

Field 15.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

M 15.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.15.1,

C.10.13

The XML name for the Type-15 record is 

<itl:PackagePalmpprintImageRecord>, 

and its <biom:RecordCategoryCode> 

element shall

have a value of “15”.

1M NIEM-

15.001-

Record 

Header

ForEach(XElm(itl:PackagePalmprintImageRecord) {

{XElm(biom:RecordCategoryCode) EQ ASCII(15) }

X

Field: 

15.002-

Information 

Designation 

Character

Value

8.15.2,

Table 69,

7.3.1

This mandatory field shall be the IDC of 

this Type-15 record as found in the 

information item IDC of Field 1.003 

Transaction content/CNT. 

M 15.002-IDC <See Requirement IDs “Field: xx.002-IDC “and 

“Field: 1.003-Transaction Content Subfield 2 IDC 

Matches” >

t-2

Field: 

15.003-

Impression 

Type

Value

8.15.3,

Table 69,

7.7.4.1,

Table 5

This mandatory field shall indicate the 

manner by which the latent print was 

obtained.

See Section 7.7.4.1 for details.

<Table 69 lists the valid values for IMP.>

1M 15.003-IMP {15.003} EQ 10 OR 11B

Field: 8.15.4, This is a mandatory field. See Section 7.6 M 15.004- <See Requirement ID “Field: Agency Codes” >t-2
139

15.004-

Originating 

Agency 

Value

7.6 for details. ORG

Field: 

15.005-

Palmprint 

Capture 

Date Value

8.15.5,

7.7.2.3

This mandatory field shall contain the 

date that the fingerprint data contained 

in the record was captured.

1M 15.005-PCD {15.005} MO [ValidLocalDate]t-6T

1M NIEM-

15.005-PCD

ForEach(XElm(itl:PackagePalmprintRecord)) {

{XElm(nc:Date) in XElm(biom:CaptureDate)} MO 

[NIEM-ValidLocalDate]

}

t-6X

Field: 

15.006-

Horizontal 

Line Length 

Value

8.15.6,

Table 69,

7.7.8.1

The maximum horizontal size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types. The 

minimum value is 10 pixels.

M 15.006-HLL <See Requirement ID “Field: Image HLL Value” >t-2

Field: 

15.006-

Horizontal 

Line Length 

Metadata

8.15.6,

Table 69,

7.7.8.1

<The HLL is verified by checking the image 

metadata if compression is used.>

2M 15.006-HLL 

Metadata 

JPEGB,JPEG L

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{15.006} EQ {ImageWidth-JPEGB,JPEGL}

t-11B

2M 15.006-HLL 

Metadata 

JP2,JP2L

IF {15.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{15.006} EQ {ImageWidth-JP2,JP2L}

t-11B

2M 15.006-HLL 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) THEN

{15.006} EQ {ImageWidth-PNG}

t-11B

2M 15.006-HLL 

Metadata 

WSQ

IF {15.011} EQ ASCII(WSQ20) THEN

{15.006} EQ {ImageWidth-WSQ}

t-11B

Field: 

15.007-

Vertical Line 

Length 

Value

8.15.7,

Table 69,

7.7.8.2

The maximum vertical size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types.

The minimum value is 10 pixels.

M 15.007-VLL <See Requirement ID “Field: Image VLL Value” >t-2

Field: 

15.007-

Vertical Line 

Length 

Metadata

8.15.7,

Table 69,

7.7.8.2

<The VLL is verified by checking the image 

metadata if compression is used.>

2M 15.007-VLL 

Metadata 

JPEGB, 

JPEGL

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

{15.007} EQ {ImageHeight-JPEGB,JPEGL}

t-11B

2M 15.007-VLL 

Metadata 

JP2, JP2L

IF {15.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{15.007} EQ {ImageHeight-JP2,JP2L}

t-11B

2M 15.007-VLL 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) THEN

{15.007} EQ {ImageHeight-PNG}

t-11B

2M 15.006-VLL 

Metadata 

WSQ

IF {15.011} EQ ASCII(WSQ20) THEN

{15.007} EQ {ImageHeight-WSQ}

t-11B
140

Field: 

15.008-Scale 

Units Value

8.15.8,

Table 69,

7.7.8.3

<Table 69 lists the value constraints for 

SLC>

M 15.008-SLC <See Requirement ID “Field: Image SLC Value” >t-2

Field: 

15.008-

Scale Units 

Metadata

8.15.8,

Table 69,

7.7.8.3

A value of “1” shall indicate pixels per 

inch.

A value of “2” shall indicate pixels per 

centimeter. A value of “0” in this field 

indicates that no scale is provided, and 

the quotient of THPS/TVPS shall provide 

the pixel aspect ratio.

<The SLC is verified by checking the image 

metadata if compression is used.>

2M 15.008-SLC 

Metadata 

JPEGB,JPEG L

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN {15.008} EQ {SamplingUnits-JPEGB,JPEGL}

t-11B

15.008-SLC 

Metadata 

JP2,JP2L

<Not Tested.>t-12B

2M 15.008-SLC 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) THEN

IF {15.008} EQ 1 OR 2 THEN { SamplingUnits-

PNG} EQ 1, ELSE IF {15.008} EQ 0 THEN { 

SamplingUnits-PNG} EQ 0

t-11B

15.008-SLC 

Metadata 

WSQ

<Not Tested.>t-12B

Field: 

15.009-

Transmitted 

Horizontal 

Pixel Scale 

Value

8.15.9,

Table 69,

7.7.8.4

<Table 69 lists the value constraints for 

THPS.>

M 15.009-

THPS

<See Requirement ID “Field: Image THPS Value” >t-2

Field: 

15.009-

Transmitted 

Horizontal 

Pixel Scale 

Metadata

8.15.9,

Table 69,

7.7.8.4

This is the integer pixel density used in 

the horizontal direction of the image if 

SLC has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the horizontal component of the 

pixel aspect ratio, up to 5 digits. 

<The THPS is verified by checking the 

image metadata if compression is used.>

2M 15.009-

THPS 

Metadata 

JPEGB,JPEG L

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{15.008} EQ 1 OR 2 

THEN {15.009} EQ {HorizontalDensity-

JPEGB,JPEGL}

t-11B

15.009-

THPS 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 15.009-

THPS 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) AND {15.008} EQ 1 

THEN {15.009} EQ {HorizontalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF {15.011} EQ ASCII(PNG) AND {15.008} EQ 

2 

THEN {15.009} EQ {HorizontalDensity-PNG} * 

0.01 (meters/cm)

t-11B

15.009-

THPS 

Metadata 

WSQ

<Not Tested.>t-12B

2M 15.009-

THPS 

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{15.008} NEQ 1 OR 2

t-11B
141

Aspect 

Ratio 

Metadata 

JPEGB,JPEG

L

THEN {15.009}/{15.010} EQ {HorizontalDensityJPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

15.009-

THPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.> t-12 B

2 M 15.009-

THPS 

Aspect 

Ratio 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) AND {15.008} NEQ 1 

OR 2 

THEN {15.009}/{15.010} EQ {HorizontalDensityPNG} / {VerticalDensity-PNG}

t-11 B

15.009-

THPS 

Aspect 

Ratio 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

15.010-

Transmitted 

Vertical 

Pixel Scale 

Value

8.15.10,

Table 69,

7.7.8.5

<Table 69 lists the value constraints for 

TVPS.>

M 15.010-

TVPS

<See Requirement ID “Field: Image TVPS Value” 

>

t-2

Field: 

15.010-

Transmitted 

Vertical 

Pixel Scale 

Metadata

8.15.10,

Table 69,

7.7.8.5

This is the integer pixel density used in 

the Vertical direction of the image if SLC 

has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the Vertical component of the 

pixel aspect ratio, up to 5 digits.

<The TVPS is verified by checking the 

image metadata if compression is used.>

2 M 15.010-

TVPS 

Metadata 

JPEGB,JPEG

L

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{15.008} EQ 1 OR 2 

THEN {15.010} EQ {VerticalDensity-JPEGB,JPEGL}

t-11 B

15.010-

TVPS 

Metadata 

JP2, JP2L

<Not Tested.> t-12 B

2 M 15.010-

TVPS 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) AND {15.008} EQ 1 

THEN {15.010} EQ {VerticalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF {15.011} EQ ASCII(PNG) AND {15.008} EQ 

2 

THEN {15.010} EQ {VerticalDensity-PNG} * 0.01 

(meters/cm)

t-11 B
142

15.010-

TVPS 

Metadata 

WSQ

<Not Tested.> t-12 B

2 M 15.010-

TVPS 

Aspect 

Ratio 

Metadata 

JPEGB,JPEG

L

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) AND 

{15.008} NEQ 1 OR 2

THEN {15.009}/{15.010} EQ {HorizontalDensityJPEGB,JPEGL} / {VerticalDensity-JPEGB,JPEGL}

t-11 B

15.010-

TVPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.> t-12 B

2 M 15.010-

TVPS 

Aspect 

Ratio 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) AND {15.008} NEQ 1 

OR 2

THEN {15.009}/{15.010} EQ { HorizontalDensity -

PNG} / {VerticalDensity-PNG}

t-11 B

15.010-

TVPS 

Aspect 

Ratio 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

15.011-

Compressio

n Algorithm 

Value

8.15.11,

Table 69,

7.7.9.1

For each of these fields, the entry 

corresponds to the appropriate Label 

entry in Table 12: Field 15.011: 

Compression algorithm / CGA.

1 M 15.011-CGA {15.011} MO [ASCII(NONE, JPEGB, JPEGL, JP2, 

JP2L, PNG, WSQ)]

t-98 B

Field: 

15.011-

Compressio

n Algorithm 

Metadata

8.15.11,

Table 69

<The CGA is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2 M 15.011-

CGAMetad

ata 

JPEGB,JPEG

L

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

Present(SOI -JPEG,JPEGL)

t-11 B

2 M 15.011-CGA 

Metadata 

JP2, JP2L

IF {15.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox)

t-11 B

2 M 15.011-CGA 

Metadata 

PNG

IF {15.011} EQ ASCII(PNG) THEN

Present(PNGSig)

t-11 B

2 M 15.011-CGA IF {15.011} EQ ASCII(WSQ20) THEN t-11 B
143

Metadata 

WSQ

Present(SOI-WSQ)

Field: 

15.012-Bits 

Per Pixel 

Value

8.15.12,

Table 69,

7.7.8.6

This field shall contain an entry of “8” for 

normal grayscale values of “0” to “255”. 

Any entry in this field greater than “8” 

shall represent a grayscale pixel with 

increased proportion.

M 15.012-BPX <See Requirement ID “Field: Image BPX Value” > t-2

Field: 

15.012- Bits 

Per Pixel 

Metadata

8.15.12,

Table 69

<The BPX is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2 M 15.012-BPX 

Metadata 

JPEGB,JPEG

L

{15.012} EQ {BPX-JPEG, JPEGL} t-11 B

2 M 15.012-BPX 

Metadata 

JP2, JP2L

{15.012} EQ {BPX-JP2,JP2L} t-11 B

2 M 15.012-BPX 

Metadata 

PNG

{15.012} EQ {BPX-PNG} t-11 B

15.012-BPX 

Metadata 

WSQ

<Not Tested.> t-12 B

Field: 

15.013-

Friction 

Ridge 

Generalized 

Position 

Value

8.15.13,

Table 69,

7.7.4.2,

Table 6

See Section 7.7.4.2 for details. 1 M 15.013-FGP 

Value

{15.013} MO [20 to 38, 81 to 84] B

Field: 

15.014, 

15.015-

Reserved

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.014, 

15.015 

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2

Field: 

15.016-

Scanned 

Horizontal 

Pixel Scale 

Value

8.15.14,

Table 69,

7.7.8.7

See section 7.7.8 for details. O 15.016-

SHPS Value

<See Requirement IDs: “Field: Image SHPS 

Value”>

t-2

Field: 

15.017-

Scanned 

Vertical 

Pixel Scale 

Value

8.15.15,

Table 69,

7.7.8.8

See section 7.7.8 for details. O 15.016-

SVPS Value

<See Requirement IDs: “Field: Image SVPS 

Value”>

t-2

Field: 

15.018, 

15.019-

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.018, 

15.019 

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2
144

Reserved

Field: 

15.020-

Comment 

Value

8.15.16,

Table 69,

7.4.4

See section 7.4.4 for details. O 15.020-

COM

<See Requirement ID: “Field: Comment>.t-2

Field: 15.021 

to 15.023-

Reserved

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.021 to 

15.023 

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2

Field: 

15.024-Palm 

Quality 

Metric 

Value

8.15.17,

Table 69,

Table 6

<Table 69 lists the value constraints for 

PQM.>

O 15.024-

PQM

<See Requirement IDs: “Field: Sample Quality 

Occurrences”, to “Field: Sample Quality 

Additional Subfield”.>

t-2

Field: 15.025 

to 15.029-

Reserved

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.025 to 

15.029 

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2

Field: 

15.030-

Device 

Monitoring 

Mode Value

8.15.27,

Table 69

<Table 69 lists the value constraints for 

DMM.>

1O 15.030-

DMM

{15.030} MO ASCII(CONTROLLED, ASSISTED, 

OBSERVED, UNATTENDED, UNKNOWN)

B

Field: 15.031 

to 15.199-

Reserved

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.031 to 

15.199 

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2

Field: 15.200 

to 15.900-

User 

Defined

Table 69 User Defined Fields- 15.200 to 

15.900-

User 

Defined

TRUEB

Field: 

15.901-

Reserved

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.901-

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2

Field: 

15.902-

Annotated 

Information 

Value

8.15.20,

Table 69

This is an optional field, listing the 

operations performed on the original 

source in order to prepare it for inclusion 

in a biometric record type. See Section 

7.4.1.

O 15.902-

ANN-Value

<See Requirement ID: “Field: xx.902-ANN” >.t-2

Field: 

15.903-

Device 

Unique 

Identifier 

Value

8.15.31,

Table 69

This is an optional field. See Section 

7.7.1.1.

O 15.903-DUI 

Value

<See Requirement ID: “Field: Device ID” >.t-2

Field: 

15.904-

Make/Mode

l/Serial 

8.15.32,

Table 69

This is an optional field. See Section 

7.7.1.2.

O 15.904-

MMS Value

<See Requirement ID: “Field: Make Model” >.t-2
145

Number 

Value

Field: 

15.905, 

15.994-

Reserved

Table 69 Reserved for future useonly by 

ANSI/NIST-ITL.

- 15.905, 

15.994-

Reserved

<See Requirement ID: “Field: Type15-

CondCode>.

t-2

Field: 

15.995-

Associated 

Context 

Value

8.15.33,

Table 69

See Section 7.3.3O 15.995-ASC 

Value

<See Requirement IDs: “Field: xx.995-ASC” and 

“Field: xx.995-ASC-ACN” and

“Field: xx.995-ASC-ASP”>.

t-2

Field: 

15.996-

Hash Value

8.15.34,

Table 69

See Section 7.5.2O 15.996-HAS 

Value

<See Requirement ID: “Field: HAS”>t-2

Field: 

15.997-

Source 

Representati

on Value

8.15.35,

Table 69

See Section 7.3.2O 15.997-SOR 

Value

<See Requirement IDs: “Field: xx.997-SOR” and 

“Field: xx.997-SOR-SRN” and

“Field: xx.997-SOR-RSP”>.

t-2

Field: 

15.998-

Geographic 

Sample 

Acquisition 

Location 

Value

8.15.36,

Table 69

See Section 7.7.3O 15.998-

GEO Value

<See Requirement IDs: “Field: Geographic”, 

“Field: Geographic-Conditional”,“Field: 

Geographic-Subfield 1” through “Field: 

Geographic-Values-SubField 15” >.

t-2

Field: 

15.999-

Image Data 

Valid

8.15.37, 

Table 69

This is a mandatory field contains the 

image.

<The image metadata is checked for 

validity.>

2M 15.999-

DATA 

Uncompres

sed Valid 

IF {15.011} EQ ASCII(NONE) THEN

Length(15.999) EQ 15.006} * {15.007}

B

2M 15.999-

DATA 

JPEGB,JPEG

L Valid

IF {15.011} EQ ASCII(JPEGB) OR ASCII(JPEGL) 

THEN

Present(JFIF, 

SOI-JPEGB,JPEGL,

SOF-JPEGB,JPEGL,

EOI-JPEG, JPEGL)

t-11B

2M 15.999-

DATA 

JP2,JP2L 

Valid

IF {15.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox, 

HeadBox, 

ImgBox)

t-11B

2M 15.999-

DATA PNG 

Valid

IF {15.011} EQ ASCII(PNG) THEN

Present(PNGSig,

IHDR,

IDAT,

IEND) 

t-11B

2M 15.999- IF {15.999} EQ ASCII(WSQ20) THENt-11B
146

DATA WSQ 

Valid

Present(SOI-WSQ,SOF-WSQ,SOB-WSQ,EOI-WSQ)

Field: 

15.999-

Image WSQ 

Version 3.1

7.7.9.1 Only version 3.1 or higher shall be used 

for compressing grayscale fingerprint data 

at 500 ppi class with a platen area of 2 

inches or greater in height. WSQ shall not 

be used for other than the 500 ppi class.

2 M 15.999-

DATA WSQ 

Version

IF {15.011} EQ ASCII(WSQ20) THEN

{Encoder Version } EQ 2

t-11 B
147

Table C.15 - Assertions for Record Type 17 - Iris Image Record

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

8.17: Record Type-17: Iris image record

Field: 

Type17-

Subfield 

Occurrence

Table 71 <Table 71 specifies which fields contain 

subfields as well as the number of 

occurrences permitted.>

1 - Type17-

Subfields 

Zero

Count(Subfields in 17.[001 to 003, 005 to 015, 

017, 020 to 023, 026, 030 to 032, 040, 041, 996]) 

EQ 0

T

1 M 17.004-

Subfields

Count(US_Subfields in 17.004) EQ 1 OR 2 T

1 O 17.016-

Subfields

Count(US_Subfields in 17.016) EQ 3 T

1 O 17.019-

Subfields

Count(US_Subfields in 17.019) EQ 3 T

1 O 17.024-

Subfields

Count(RS_Subfields in 17.024) MO [1 to 9]

AND

ForEach(RS_Subfield in 17.024)

{

Count(US_Subfields in RS_Subfield) EQ 3

}

T

1 M 17.025-

Subfields

IF {US_Subfield:1 in 17.025} EQ ASCII(DEFINED)

THEN

Count(US_Subfields in 17.025) EQ 3

ELSE

Count(US_Subfields in 17.025) EQ 1

}

T

1 O 17.033-

Subfields

Count(US_Subfields in 17.033) EQ 2 + 

2*{US_Subfield:2 in 17.033}

}

T

1 O 17.034-

Subfields

Count(US_Subfields in 17.034) EQ 2 + 

2*{US_Subfield:2 in 17.034}

}

T

1 O 17.035-

Subfields

Count(US_Subfields in 17.035) EQ 2 + 2*{ 

US_Subfield:2 in 17.035}

}

T

1 O 17.036-

Subfields

Count(US_Subfields in 17.036) EQ 2 + 2*{ 

US_Subfield:2 in 17.036}

}

T

1 O 17.037- Count(US_Subfields in 17.037) EQ 3 + T
148

Subfields 2*{US_Subfield:3 in 17.037)}

}

1 O 17.902-

Subfields

Count(RS_Subfields in 17.902) GTE 1

AND

ForEach(RS_Subfield in 17.902)

{

Count(US_Subfields in RS_Subfield) EQ 4

}

T

1 O 17.995-

Subfields

Count(RS_Subfields in 17.995) MO [1 to 255]

AND

ForEach(RS_Subfield in 17.995)

{

Count(US_Subfields in RS_Subfield) EQ 2OR 3

}

T

1 O 17.997-

Subfields

Count(RS_Subfields in 17.997) MO [1 to 255]

AND

ForEach(RS_Subfield in 17.997)

{

Count(US_Subfields in RS_Subfield) EQ 1 OR 2

}

T

O 17.998-

Subfields

<See Requirement ID: “Field: GeographicConditional”>t-2

Field: 

Type17-

CondCode

Table 71 <Table 71 specifies the Condition Code for 

each field.>

1 - Type17-

CondCode

Present(17.001 to 17.013, 17.025, 17.032, 

17.999)

AND

NOT Present(17.018, 17.027 to 17.029, 17.038, 

17.039, 17.042 to 17.199, 17.901, 17.903 to 

17.994)

B

Field: 

17.015-

Rotation 

Uncertainty 

Dependent

Table 71,

8.17.15

This field is mandatory if Field 17.014: 

Rotation angle of eye / RAE is present.

2 D 17.015-

CondCode 

Dependent

IF Present(17.014) THEN Present(17.015) B

Field: 

Type17-

CharType

8.17,

Table 71

<Table 71 specifies the Character Type for 

each field that contains no subfields.>

1 - Type17-

CharType N

Bytes(17.[001,002,003, 005 to 010, 012, 022, 

023, 026, 031, 032, 040, 041]) MO [0x30 to 0x39]

B

1 - Type17-

CharType A

Bytes(17.[013, 020, 030]) MO [0x41 to 0x5A, 

0x61 to 0x7A]

B
149

1- Type17-

CharType 

AN

Bytes(17.[011, 014, 015]) [0x30 to 0x39, 0x41 to 

0x5A, 0x61 to 0x7A]

B

1O 17.017-

CharType 

ANS

Bytes(17.017) MO [0x20, 0x7E]B

1O 17.996-

CharType H

Bytes(10.996) MO [0x30 to 0x39,0x41 to 0x46, 

0x61 to 0x66]

B

Field: 

Type17-

Subfield

CharType

8.17,

Table 71

<Table 71 specifies the Character Type for 

each subfield.>

1M 17.004-

Subfield 

CharType U

Present( Bytes( US_Subfields:1,2 in 17.004 ) B*

1O 17.016-

Subfield 

CharType N

Bytes(All(US_Subfields in 17.016)) MO [0x30 to 

0x39]

B*

1O 17.019-

Subfield 

CharType U

Present( Bytes( US_Subfields:1 to 3 in 17.019) B*

1O 17.024-

Subfield 

CharType 

HN

ForEach(RS_Subfield in 17.024) {

Bytes(US_Subfields:1,3 in RS_Subfield)) MO 

[0x30 to 0x39]

AND

Bytes(US_Subfields:2 in RS_Subfield)) MO [0x30 

to 0x39,0x41 to 0x46, 0x61 to 0x66] }

B*

1M 17.025-

Subfield 

CharType 

AN

Bytes(US_Subfields:1 in 17.025)) MO [0x41 to 

0x5A, 0x61 to 0x7A]]

AND

Bytes(US_Subfields:2,3 in 17.025)) MO [0x30 to 

0x39]

B*

1M 17.033-

Subfield 

CharType 

AN

Bytes(US_Subfields:1 in 17.033)) MO [0x41 to 

0x5A, 0x61 to 0x7A]]

For(X EQ 2 to Count(US_Subfields in 17.033)) {

Bytes(US_Subfield:X in 17.033) MO [0x30 to 

0x39] }

B*

1O 17.034-

Subfield 

CharType 

AN

Bytes(US_Subfields:1 in 17.034)) MO [0x41 to 

0x5A, 0x61 to 0x7A]]

For(X EQ 2 to Count(US_Subfields in 17.034)) {

Bytes(US_Subfield:X in 17.034) MO [0x30 to 

0x39] }

B*
150

1O 17.035-

Subfield 

CharType 

AN

Bytes(US_Subfields:1 in 17.035)) MO [0x41 to 

0x5A, 0x61 to 0x7A]]

For(X EQ 2 to Count(US_Subfields in 17.035)) {

Bytes(US_Subfield:X in 17.035) MO [0x30 to 

0x39] }

B*

1O 17.036-

Subfield 

CharType 

AN

Bytes(US_Subfields:1 in 17.036)) MO [0x41 to 

0x5A, 0x61 to 0x7A]]

For(X EQ 2 to Count(US_Subfields in 17.036)) {

Bytes(US_Subfield:X in 17.036) MO [0x30 to 

0x39] }

B*

1O 17.037-

Subfield 

CharType 

AN

ForEach(RS_Subfield in 17.037) {

Bytes(US_Subfields:1,2 in RS_Subfield)) MO 

[0x41 to 0x5A, 0x61 to 0x7A]]

AND

For(X EQ 3 to Count(US_Subfields in 

RS_Subfield)) {

Bytes(US_Subfield:X in RS_Subfield) MO [0x30 to 

0x39] }}

B*

1O 17.995-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 17.995)) MO [0x30 

to 0x39]

B*

1O 17.997-

Subfield 

CharType N

Bytes(All(US_Subfields:1,2 in 17.997)) MO [0x30 

to 0x39]

B*

O 17.998-

Subfield 

CharType 

ANSU

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type17-

CharCount

Table 71 <Table 71 specifies the Character Count 

for each field that contains no subfields.>

1M 17.001-

CharCount

DataLength(17.001) GTE 1B

1M 17.002-

CharCount

DataLength(17.002) EQ 1 OR 2B

1M 17.003-

CharCount

DataLength(17.003) EQ 1 B

1M 17.005- DataLength(17.005) EQ 8B
151

CharCount

1M 17.006-

CharCount

DataLength(17.006) MO [2 to 5]B

1M 17.007-

CharCount

DataLength(17.007) MO [2 to 5]B

1M 17.008-

CharCount

DataLength(17.008) EQ 1B

1M 17.009-

CharCount

DataLength(17.009) MO [1 to 5]B

1M 17.010-

CharCount

DataLength(17.010) MO [1 to 5]B

1M 17.011-

CharCount

DataLength(17.011) MO [3 to 4]B

1M 17.012-

CharCount

DataLength(17.012) EQ 1 OR 2B

1M 17.013-

CharCount

DataLength(17.013) MO [3 to 4]B

1O 17.014-

CharCount

DataLength(17.014) MO [1 to 5]B

1D 17.015-

CharCount

DataLength(17.015) MO [1 to 5]B

1O 17.017-

CharCount

DataLength(17.017) MO [13 to 16]B

1O 17.020-

CharCount

DataLength(17.020) EQ 3B

1O 17.021-

CharCount

DataLength(17.021) MO [1 to 126]B

1O 17.022-

CharCount

DataLength(17.022) MO [1 to 4]B

1O 17.023-

CharCount

DataLength(17.023) MO [1 to 4]B

1O 17.026-

CharCount

DataLength(17.026) MO [2 to 4]B

1O 17.030-

CharCount

DataLength(17.030) MO [7 to 10]B

1O 17.031-

CharCount

DataLength(17.031) EQ 2B

1M 17.032-

CharCount

DataLength(17.032) MO [7 to 10]B

1O 17.040-

CharCount

DataLength(17.040) MO [1 to 7]B

1O 17.041-

CharCount

DataLength(17.041) EQ 1 OR 2B
152

1 O 17.996-

CharCount

DataLength(17.995) EQ 64 B

1 M 17.999-

CharCount

DataLength(17.999) GTE 1 B

Field: 

Type17-

Subfield 

CharCount

Table 71 <Table 71 specifies the Character Count 

for each subfield.>

1 M 17.004-

Subfield 

CharCount

Length(All(US_Subfields in 17.004)) GTE 1 B*

1 O 17.016-

Subfield 

CharCount

Length(All(US_Subfields in 17.016)) EQ 1 B*

1 O 17.019-

Subfield 

CharCount

Length(All(US_Subfields in 17.019)) MO [1 to 50] B*

1 O 17.024-

Subfield 

CharCount

ForEach(RS_Subfield in 17.024)

{

Length(US_Subfields:1 in RS_Subfield)) MO [1 to 

3]

AND

Length(US_Subfields:2 in RS_Subfield)) EQ 4

AND

Length(US_Subfields:3 in RS_Subfield)) MO [1 to 

5]

}

B*

1 M 17.025-

Subfield 

CharCount

ForEach(RS_Subfield in 17.025)

{

Length(US_Subfields:1 in RS_Subfield)) MO [3 to 

9]

AND

Length(US_Subfields:2,3 in RS_Subfield)) EQ 3

}

B*

1 O 17.023-

Subfield 

CharCount

ForEach(RS_Subfield in 17.023)

{

Length(US_Subfields:1 in RS_Subfield)) EQ 1 OR 

2

AND

Length(US_Subfields:2 in RS_Subfield)) MO [1 to 

3]

AND

Length(US_Subfields:3 in RS_Subfield)) EQ 4

AND

Length(US_Subfields:4 in RS_Subfield)) MO [1 to

5]

}

B*
153

1O 17.024-

Subfield 

CharCount

ForEach(RS_Subfield in 17.024) {

Length(US_Subfield:1 in RS_Subfield)) EQ 1 OR 2

AND

Length(US_Subfields:2 in RS_Subfield)) MO [1 to 

3]

AND

Length(US_Subfields:3 in RS_Subfield)) EQ 4

AND

Length(US_Subfields:4 in RS_Subfield)) MO [1 to 

5] }

B*

1O 17.025-

Subfield 

CharCount

ForEach(RS_Subfield in 17.025) {

Length(US_Subfields:1,2 in RS_Subfield)) EQ 1 

OR 2

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1O 17.033-

Subfield 

CharCount

ForEach(RS_Subfield in 17.033) {

Length(US_Subfields:1 in RS_Subfield)) EQ 1 

AND

Length(US_Subfields:2 in RS_Subfield)) EQ 1 OR 

2 

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1O 17.034-

Subfield 

CharCount

ForEach(RS_Subfield in 17.034) {

Length(US_Subfields:1 in RS_Subfield)) EQ 1 

AND

Length(US_Subfields:2 in RS_Subfield)) EQ 1 OR 

2 

AND

ForEach(<additional US_Subfield in 

RS_Subfield>)

B*
154

{

Length(US_Subfield) MO [1 to 5] }}

1O 17.035-

Subfield 

CharCount

ForEach(RS_Subfield in 17.035) {

Length(US_Subfields:1 in RS_Subfield)) EQ 1 

AND

Length(US_Subfields:2 in RS_Subfield)) EQ 1 OR 

2 

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1O 17.036-

Subfield 

CharCount

ForEach(RS_Subfield in 17.036) {

Length(US_Subfields:1 in RS_Subfield)) EQ 1 

AND

Length(US_Subfields:2 in RS_Subfield)) EQ 1 OR 

2 

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1O 17.037-

Subfield 

CharCount

ForEach(RS_Subfield in 17.037) {

Length(US_Subfields:1,2 in RS_Subfield)) EQ 1 

AND

Length(US_Subfields:3 in RS_Subfield)) MO [1 to 

3] 

AND

ForEach(<additional US_Subfield in 

RS_Subfield>) {

Length(US_Subfield) MO [1 to 5] }}

B*

1O 17.902-

Subfield 

CharCount

ForEach(RS_Subfield in 17.902) {

Length(US_Subfield:1 in RS_Subfield) EQ 15

AND

B*
155

Length(US_Subfields:2,3 in RS_Subfield) MO [1 

to 64]

AND

Length(US_Subfield:4 in RS_Subfield)) MO [1 to 

255] }

1O 17.995-

Subfield 

CharCount

ForEach(RS_Subfield in 17.995) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

1O 17.997-

Subfield 

CharCount

ForEach(RS_Subfield in 17.997) {

Length(US_Subfield:1 in RS_Subfield) MO [1 to 3]

AND

Length(US_Subfield:2 in RS_Subfield) EQ 1 OR 2 }

B*

O 17.998-

Subfield 

CharCount

<See Requirement ID: “Field: Geographic”>t-2

Field: 

Type17-Field 

Occurrence

Table 71 <Table 71 specifies the Field Occurrence 

for each field.>

1- Type17-

Occurrence 

Zero

Count(17.[018 ,027 to 029, 038, 039, 042 to 

199,901,903 to 994]) EQ 0

B

1M Type17-

Occurrence 

One

Count(17.[001 to 013, 025, 032, 999]) EQ 1B

1- Type14-

Occurrence 

One or 

Fewer

Count(17.[014 to 017,019 to 024,026, 030, 031, 

033 to 037, 040, 041, 902, 995 to 998) LTE 1

B

Field: 

17.001-

Record 

Header 

Value

8.17.1,

Table 71,

7.1

Field 17.001 Record header. In Traditional 

encoding, this field contains the record 

length in bytes (including all information 

separators)

M 17.001-

Record 

Header

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

8.17.1,

C.10.15

The XML name for the Type-17 record is 

<itl:PackageIrisImageRecord>, and its 

<biom:RecordCategoryCode> element 

shall have a value of “17”.

1M NIEM-

17.001-

Record 

Header

ForEach(XElm(itl:PackageIrisImageRecord) {

{XElm(biom:RecordCategoryCode)} EQ ASCII(17) }

X

Field: 

17.002-

Information 

Designation 

Character

8.17.2,

Table 71,

7.3.1

This mandatory field shall be the IDC of 

this Type-17 record as found in the 

information item IDC of Field 1.003 

Transaction content/CNT. 

M 17.002-IDC <See Requirement IDs “Field: xx.002-IDC” and 

“Field: 1.003-Transaction Content Subfield 2 IDC 

Matches” >

t-2
156

Value

Field: 

17.003-Eye 

Label

Value

8.17.3,

Table 71,

7.7.4.1

<Table 71 lists the valid values for ELR.>1M 17.003-ELR {17.003} MO [0 to 2]B

Field:

17.004-

Originating 

Agency 

Value

8.17.4,

7.6

This is a mandatory field. See Section 7.6 

for details.

M 17.004-

ORG

<See Requirement ID “Field: Agency Codes” >t-2

Field: 

17.005-Iris 

Capture 

Date Value

8.17.5,

7.7.2.3

This mandatory field shall contain the 

date that the iris biometric data 

contained in the record was captured.

1M 17.005-ICD {17.005} MO [ValidLocalDate]t-6T

1M NIEM-

17.005-ICD

ForEach(XElm(itl:PackageIrisImageRecord)) {

{XElm(nc:Date) in XElm(biom:CaptureDate)} MO 

[NIEM-ValidLocalDate]

}

t-6X

Field: 

17.006-

Horizontal 

Line Length 

Value

8.17.6,

Table 71,

7.7.8.1

The maximum horizontal size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types. The 

minimum value is 10 pixels.

M 17.006-HLL <See Requirement ID “Field: Image HLL Value” >t-2

Field: 

17.006-

Horizontal 

Line Length 

Metadata

8.17.6,

Table 71,

7.7.8.1

<The HLL is verified by checking the image 

metadata if compression is used.>

2M 17.006-HLL 

Metadata 

JP2,JP2L

IF {17.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{17.006} EQ {ImageWidth-JP2,JP2L}

t-11B

2M 17.006-HLL 

Metadata 

PNG

IF {17.011} EQ ASCII(PNG) THEN

{17.006} EQ {ImageWidth-PNG}

t-11B

Field: 

17.007-

Vertical Line 

Length 

Value

8.17.7,

Table 71,

7.7.8.2

The maximum vertical size is limited to 

65,534 pixels in Record Types-4 and 8, 

and to 99,999 for other record types.

The minimum value is 10 pixels.

M 17.007-VLL <See Requirement ID “Field: Image VLL Value” >t-2

Field: 

17.007-

Vertical Line 

Length 

Metadata

8.17.7,

Table 71,

7.7.8.2

<The VLL is verified by checking the image 

metadata if compression is used.>

2M 17.007-VLL 

Metadata 

JP2, JP2L

IF {17.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

{17.007} EQ {ImageHeight-JP2,JP2L}

t-11B

2M 17.007-VLL 

Metadata 

PNG

IF {17.011} EQ ASCII(PNG) THEN

{17.007} EQ {ImageHeight-PNG}

t-11B

Field: 

17.008-Scale 

Units Value

8.17.8,

Table 71,

7.7.8.3

<Table 71 lists the value constraints for 

SLC>

M 17.008-SLC <See Requirement ID “Field: Image SLC Value” >t-2

Field: 

17.008-

Scale Units 

Metadata

8.17.8,

Table 71,

7.7.8.3

A value of “1” shall indicate pixels per 

inch.

A value of “2” shall indicate pixels per 

centimeter. A value of “0” in this field 

indicates that no scale is provided, and 

17.008-SLC 

Metadata 

JP2,JP2L

<Not Tested.>t-12B

2M 17.008-SLC 

Metadata 

IF {17.011} EQ ASCII(PNG) THEN

IF {17.008} EQ 1 OR 2 THEN { SamplingUnits-

t-11B
157

the quotient of THPS/TVPS shall provide 

the pixel aspect ratio.

<The SLC is verified by checking the image

metadata if compression is used.>

PNG PNG} EQ 1, ELSE IF {17.008} EQ 0 THEN { 

SamplingUnits-PNG} EQ 0

Field: 

17.009-

Transmitted 

Horizontal 

Pixel Scale 

Value

8.17.9,

Table 71,

7.7.8.4

<Table 71 lists the value constraints for 

THPS.>

M 17.009-

THPS

<See Requirement ID “Field: Image THPS Value” >t-2

Field: 

17.009-

Transmitted 

Horizontal 

Pixel Scale 

Metadata

8.17.9,

Table 71,

7.7.8.4

This is the integer pixel density used in 

the horizontal direction of the image if 

SLC has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the horizontal component of the 

pixel aspect ratio, up to 5 digits. 

<The THPS is verified by checking the 

image metadata if compression is used.>

17.009-

THPS 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 17.009-

THPS 

Metadata 

PNG

IF {17.011} EQ ASCII(PNG) AND {17.008} EQ 1

THEN {17.009} EQ {HorizontalDensity-PNG} * 

0.0254 (meters/inch)

ELSE IF {17.011} EQ ASCII(PNG) AND {17.008} EQ 2

THEN {17.009} EQ {HorizontalDensity-PNG} * 

0.01 (meters/cm)

t-11B

17.009-

THPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 17.009-

THPS 

Aspect 

Ratio 

Metadata 

PNG

IF {17.011} EQ ASCII(PNG) AND {17.008} NEQ 1 

OR 2 

THEN {17.009}/{17.010} EQ {HorizontalDensity-

PNG} / {VerticalDensity-PNG}

t-11B

Field: 

17.010-

Transmitted 

Vertical 

Pixel Scale 

Value

8.17.10,

Table 71,

7.7.8.5

<Table 71 lists the value constraints for 

TVPS.>

M 17.010-

TVPS

<See Requirement ID “Field: Image TVPS Value” >t-2

Field: 

17.010-

Transmitted 

Vertical 

Pixel Scale 

8.17.10,

Table 71,

7.7.8.5

This is the integer pixel density used in 

the Vertical direction of the image if SLC 

has a value of “1” or “2”. If SLC has a 

value of “0”, this information item shall 

contain the Vertical component of the 

17.010-

TVPS 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 17.010- IF {17.011} EQ ASCII(PNG) AND {17.008} EQ 1t-11B
158

Metadata pixel aspect ratio, up to 5 digits.

<The TVPS is verified by checking the 

image metadata if compression is used.>

TVPS 

Metadata 

PNG

THEN {17.010} EQ {VerticalDensity-PNG} * 

0.0254 (meters/inch), 

ELSE IF {17.011} EQ ASCII(PNG) AND {17.008} EQ 2

THEN {17.010} EQ {VerticalDensity-PNG} * 0.01 

(meters/cm)

17.010-

TVPS 

Aspect 

Ratio 

Metadata 

JP2, JP2L

<Not Tested.>t-12B

2M 17.010-

TVPS 

Aspect 

Ratio 

Metadata 

PNG

IF {17.011} EQ ASCII(PNG) AND {17.008} NEQ 1 

OR 2 

THEN {17.009}/{17.010} EQ { HorizontalDensity -

PNG} / {VerticalDensity-PNG}

t-11B

Field: 

17.011-

Compressio

n Algorithm 

Value

8.17.11,

Table 71,

7.7.9.1

For each of these fields, the entry 

corresponds to the appropriate Label 

entry in Table 12: Field 17.011: 

Compression algorithm / CGA.

M 17.011-CGA <See Requirement ID “Field: Type17 

Compression”.>

t-2

Field: 

17.011-

Compressio

n Algorithm 

Metadata

8.17.11,

Table 71

<The CGA is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2M 17.011-CGA 

Metadata 

JP2, JP2L

IF {17.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox)

t-11B

2M 17.011-CGA 

Metadata 

PNG

IF {17.011} EQ ASCII(PNG) THEN

Present(PNGSig)

t-11B

Field: 

17.012-Bits 

Per Pixel 

Value

8.17.12,

Table 71,

7.7.8.6

This field shall contain an entry of “8” for 

normal grayscale values of “0” to “255”. 

Any entry in this field greater than “8” 

shall represent a grayscale pixel with 

increased proportion.

M 17.012-BPX <See Requirement ID “Field: Image BPX Value” >t-2

Field: 

17.012- Bits 

Per Pixel 

Metadata

8.17.12,

Table 71

<The BPX is verified by checking the 

image metadata for the compression type 

signature if compression is used.>

2M 17.012-BPX 

Metadata 

JP2, JP2L

{17.012} EQ {BPX-JP2,JP2L}t-11B

2M 17.012-BPX 

Metadata 

PNG

{17.012} EQ {BPX-PNG}t-11B

Field: 

17.013-Color 

Space Value

8.17.13,

Table 71,

7.7.10

Table 13 lists the codes and their 

descriptions for each of the available 

color spaces used within this standard.

All other color spaces are to be marked as 

undefined.

M 17.013-CSP <See Requirement ID: “Field: Image CSP Value”.>t-2
159

Field: 

17.014-

Rotation 

Angle of Eye 

Value

8.17.14,

Table 71

The in-plane eye rotation angle shall be 

recorded as angle = round (65536 * angle 

/ 360) modulo 65536. The value “FFFF” 

indicates rotation angle of eye is 

undefined.

<Table 71 lists the value constraints for 

RAE.>

1 O 17.014-RAE {17.014} MO [0 to 65535] OR EQ ASCII(FFFF) B

Field: 

17.015-

Rotation 

Uncertainty 

Value

8.17.15,

Table 71

The rotation uncertainty is non-negative 

and equal to [round (65536 * uncertainty 

/ 180)]. The uncertainty is measured in 

degrees and is the absolute value of 

maximum error. The value “FFFF” 

indicates uncertainty is undefined.

<Table 71 lists the value constraints for 

RAU.>

1 D 17.014-

RAU

{17.015} MO [0 to 65535] OR EQ ASCII(FFFF) B

Field: 

17.015-

Rotation 

Uncertainty 

Conditional

8.17.15,

Table 71

This optional field shall indicate the 

uncertainty in the in-plane eye rotation 

given in Field 17.014: Rotation angle of 

eye / RAE. This field is mandatory if Field 

17.014: Rotation angle of eye / RAE is 

present.

D 17.014-

RAU 

Conditional

<See Requirement ID: “Field: 17.015-Rotation 

Uncertainty Dependent”.>

t-2

Field: 

17.016-

Image 

Property 

Code Value

8.17.16,

Table 71

<Table 71 lists the value constraints for 

IPC.>

1 O 17.016-IPC {US_Subfield:1,2 in 17.016} MO [0 to 2]

AND

{US_Subfield:3 in 17.016} EQ 0 OR 1

B*

Field: 

17.017-

Device 

Unique 

Value

8.17.17,

Table 71

See Section 7.7.1.1 for details.

<Table 71 lists the value constraints for 

DUI.>

O 17.017-DUI <See Requirement ID: “Field: Device ID”.> t-2

Field: 

17.018-

Deprecated

Table 71 Deprecated; See ANSI/NIST-ITL 1-2007 for 

a description of this field. Not to be used 

for any new transactions. 

- 17.019-

Deprecated

<See Requirement ID: “Field: Type17-

CondCode>.

t-2

Field: 

17.019-

Make/Mode

l/Serial 

Number 

Value

8.17.18,

7.7.1.2, 

Table 71

See Section 7.7.1.2 for details.

<Table 71 lists the value constraints for 

MMS.>

O 17.019-

MMS

<See Requirement ID: “Field: Make Model”.> t-2

Field: 

17.020-Eye 

Color Value

8.17.19,

7.7.11,

Table 71, 

Table 14

See Section 7.7.11 and Table 14 for 

details on entering values to this field. 

<Table 71 lists the value constraints for 

ECL.>

O 17.020-ECL <See Requirement ID: “Field: Image ECL Value”.> t-2
160

Field: 

17.021-

Comment 

Value

8.17.20,

Table 71,

7.4.4

See section 7.4.4 for details. O 17.021-

COM 

<See Requirement ID: “Field: Comment>.t-2

Field: 

17.022-

Scanned 

Horizontal 

Pixel Scale 

Value

8.17.21,

7.7.8.7, 

7.4.4

See section 7.7.8.7 for details. O 17.021-

SHPS

<See Requirement ID: “Field: Image SHPS 

Value”.>

t-2

Field: 

17.023-

Scanned 

Vertical 

Pixel Scale 

Value

8.17.22,

7.7.8.8,

7.4.4

See section 7.7.8.8 for details.O 17.021-

SVPS

<See Requirement ID: “Field: Image SVPS 

Value”.>

t-2

Field: 

17.024-

Image 

Quality 

Score Value

8.17.23,

Table 71

<Table 71 lists the value constraints for 

IQS.>

O 17.024-IQS <See Requirement ID: “Field: Sample Quality 

Occurrences”,“Field: Sample Quality Subfield 1”, 

“Field: Sample Quality Subfield 2”’ “Field: Sample 

Quality Subfield 3”.>

t-2

Field: 

17.025-

Effective 

Acquisition 

Spectrum 

Value

8.17.24,

Table 71,

Table 72

<Table 71 lists the value constraints for 

EAS.>

1M 17.025-EAS {US_Subfield:1 in 17.025} MO [ASCII(NIR, 

DEFINED, VIS, RED, UNDEFINED)]

AND

{US_Subfields:2,3 in 17.025} MO [500 to 999]

B*

Field: 

17.025-

Effective 

Acquisition 

Spectrum 

Conditional 

Subfields

8.17.24,

Table 71,

Table 72

The second and third information items 

are conditional upon the value of SPV. 

These values are mandatory only when 

SPV = “DEFINED”; otherwise, they are not 

used.

M 17.025-EAS 

Conditional 

Subfields

<See Requirement ID: “Field: Type17-Subfield

Occurrence”.>

t-2

Field: 

17.026-Iris 

Diameter 

Value

8.17.25,

Table 71,

Table 72

<Table 71 lists the value constraints for 

IRD.>

1O 17.026-IRD {17.026} MO [10 to 9999]B

Field: 

17.027-

17.029 

Reserved

Table 71 Reserved for future useonly by 

ANSI/NIST-ITL.

- 17.027 to 

17.029 

Reserved

<See Requirement ID: “Field: Type17-

CondCode>.

t-2

Field: 

17.030-

Device 

Monitoring 

8.17.26,

7.7.1.3,

Table 71,

Table 3

See Section 7.7.1.3 for details. 

<Table 71 lists the value constraints for 

DMM.>

O 17.030-

DMM

<See Requirement ID: “Field: Device Monitoring” 

>.

t-2
161

Mode Value

Field: 

17.031-

Subject 

Acquisition 

Profile-Iris 

Value

8.17.27 <Table 71 lists the value constraints for 

IAP.>

O 17.031-IAP <See Requirement ID: “Field: IAP Values” >.t-2

Field: 

17.032-Iris 

Storage 

Format 

Value

8.17.28 <Table 71 lists the value constraints for 

ISF.>

1M 17.032-ISF {17.032} MO [1 to 3, 7]B

Field: 

17.033-Iris 

Pupil 

Boundary 

Value

8.17.29,

Table 71,

Table 16

<Table 71 lists the value constraints for 

IPB.>

1M⇑17.033-

Subfield 1 -

BYC

{US_Subfield:1 in 17.033} MO [ASCII(C,E,P)] B*

1M⇑17.033-

Subfield 2-

NOP

{US_Subfield:2 in 17.033} MO [2 to 99] B*

1M⇑17.033-

Subfield 

Pair

For(X EQ 3 to {US_Subfield:2 in 17.033}) {

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.006} }

B*

Field: 

17.034-Iris 

Sclera 

Boundary 

Value

8.17.30,

Table 71,

Table 16

<Table 71 lists the value constraints for 

ISB.>

1M⇑17.034-

Subfield 1 -

BYC

{US_Subfield:1 in 17.034} MO [ASCII(C,E,P)] B*

1M⇑17.034-

Subfield 2-

NOP

{US_Subfield:2 in 17.034} MO [2 to 99] B*

1M⇑17.034-

Subfield 

Pair

For(X EQ 3 to {US_Subfield:2 in 17.034}) {

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.006} }

B*

Field: 

17.035-

8.17.31,

Table 71,

<Table 71 lists the value constraints for 

UEB.>

1M⇑17.035-

Subfield 1 -

{US_Subfield:1 in 17.035} MO [ASCII(C,E,P)] B*
162

Upper Eyelid 

Boundary 

Value

Table 16 BYC

1 M

⇑

17.035-

Subfield 2-

NOP

{US_Subfield:2 in 17.035} MO [2 to 99] B*

1 M

⇑

17.035-

Subfield 

Pair

For(X EQ 3 to {US_Subfield:2 in 17.035})

{

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.006}

}

B*

Field: 

17.036-

Lower Eyelid 

Boundary 

Value

8.17.32,

Table 71,

Table 16

<Table 71 lists the value constraints for 

LEB.>

1 M

⇑

17.036-

Subfield 1 -

BYC

{US_Subfield:1 in 17.036} MO [ASCII(C,E,P)] B*

1 M

⇑

17.036-

Subfield 2-

NOP

{US_Subfield:2 in 17.036} MO [2 to 99] B*

1 M

⇑

17.036-

Subfield 

Pair

For(X EQ 3 to {US_Subfield:2 in 17.036})

{

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.007}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.006}

}

B*

Field: 

17.037-NonEyulid 

Occlusions 

Value

8.17.33,

Table 71,

Table 17, 

Table 18

<Table 71 lists the value constraints for 

NEO.>

1 M

⇑

17.037-

Subfield 1 -

BYC

ForEach(RS_Subfield in 17.037)

{

{US_Subfield:1 in RS_Subfield} MO [ASCII(T,I,L,S)]

}

B*

1 M

⇑

17.037-

Subfield 2-

NOP

ForEach(RS_Subfield in 17.037)

{

{US_Subfield:2 in RS_Subfield} MO 

[ASCII(L,S,C,R,O)]

}

B*

1 M

⇑

17.037-

Subfield 2-

NOP

ForEach(RS_Subfield in 17.037)

{

{US_Subfield:3 in RS_Subfield} MO [3 to 99]

}

B*

1 M 17.037- ForEach(RS_Subfield in 17.037) B*
163

⇑ Subfield 

Pair

{

For(X EQ 4 to {US_Subfield:2 in RS_Subfield}) {

IF X MOD 2 EQ 0

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.006}

ELSE

{US_Subfield:X in RS_Subfield} GTE 1 AND LTE 

{17.007} }}

Field: 

17.038, 

17.039 

Reserved

Table 71 Reserved for future useonly by 

ANSI/NIST-ITL.

- 17.038,17.0

39 

Reserved

<See Requirement ID: “Field: Type17-

CondCode>.

t-2

Field: 

17.040-

Range Value

8.17.34,

Table 71

<Table 71 lists the value constraints for 

RAN.>

1O 17.040-

RAN

{17.040} MO [Integers]B

Field: 

17.041-

Frontal Gaze 

Value

8.17.35,

Table 71

<Table 71 lists the value constraints for 

GAZ.>

1O 17.041-GAZ {17.041} MO [0 to 90]B

Field: 17.042 

to 17.199 

Reserved

Table 71 Reserved for future useonly by 

ANSI/NIST-ITL.

- 17.042 to 

17.199 

Reserved

<See Requirement ID: “Field: Type17-

CondCode>.

t-2

Field: 17.200 

to 17.900-

User 

Defined

Table 71 User Defined Fields- 17.200 to 

17.900-

User 

Defined

TRUEB

Field: 17.901 

Reserved

Table 71 Reserved for future useonly by 

ANSI/NIST-ITL.

- 17.901 

Reserved

<See Requirement ID: “Field: Type17-

CondCode>.

t-2

Field: 

17.902-

Annotated 

Information 

Value

8.17.37,

Table 71,

7.4.1

This is an optional field, listing the 

operations performed on the original 

source in order to prepare it for inclusion 

in a biometric record type. See Section 

7.4.1.

O 17.902-

ANN-Value

<See Requirement ID: “Field: xx.902-ANN” >.t-2

Field: 17.903 

to 17.994 

Reserved

Table 71 Reserved for future useonly by 

ANSI/NIST-ITL.

- 17.903 to 

17.994 

Reserved

<See Requirement ID: “Field: Type17-

CondCode>.

t-2

Field: 

17.995-

Associated 

Context 

Value

8.17.38,

Table 71

See Section 7.3.3O 17.995-ASC 

Value

<See Requirement IDs: “Field: xx.995-ASC” and 

“Field: xx.995-ASC-ACN” and

“Field: xx.995-ASC-ASP”>.

t-2

Field: 8.17.39, See Section 7.5.2O 17.996-HAS <See Requirement ID: “Field: HAS”>t-2
164

17.996-

Hash Value

Table 71 Value

Field: 

17.997-

Source 

Representati

on Value

8.17.40,

Table 71

See Section 7.3.2 O 17.997-SOR 

Value

<See Requirement IDs: “Field: xx.997-SOR” and 

“Field: xx.997-SOR-SRN” and

“Field: xx.997-SOR-RSP”>.

t-2

Field: 

17.998-

Geographic 

Sample 

Acquisition 

Location 

Value

8.17.41,

Table 71

See Section 7.7.3 O 17.998-

GEO Value

<See Requirement IDs: “Field: Geographic”, 

“Field: Geographic-Conditional”, “Field: 

Geographic-Subfield 1” through “Field: 

Geographic-Values-SubField 15” >.

t-2

Field: 

17.999-

Image Data 

Valid

8.17.42, 

Table 71

This is a mandatory field contains the 

image.

<The image metadata is checked for 

validity.>

2 M 17.999-

DATA 

Uncompres

sed Valid 

IF {17.011} EQ ASCII(NONE) THEN

Length(17.999) EQ 17.006} * {17.007}

B

2 M 17.999-

DATA 

JP2,JP2L 

Valid

IF {17.011} EQ ASCII(JP2) OR ASCII(JP2L) THEN

Present(SigBox, 

HeadBox, 

ImgBox)

t-11 B

2 M 17.999-

DATA PNG 

Valid

IF {17.011} EQ ASCII(PNG) THEN

Present(PNGSig,

IHDR,

IDAT,

IEND) 

t-11 B
165

Table C.16 - Assertions for Annex B - Traditional Encoding

Requireme

nt

ID

Referen

ce in 

Base 

Standar

d

Requirement

Summary

L

e

v

e

l

S

t

a

t

u

s

Assertion

ID

Test

Assertion

Test

Note

Implemen

tation 

Support

Supporte

d Range

Test 

Result

Applicab

ility

Annex B: Traditional Encoding

TraditionalField: 

xx.001-

Length, First 

Annex B The first field in all records shall be 

labeled as field ”1” and contain the length 

in bytes of the record. 

M Traditional: 

xx.001-

Length, 

First

<See Requirement ID: “Field: xx.001-Record 

Header”.>

t-2

TraditionalField: 

xx.002-IDC

Annex B With the exception of the Type-1 record 

(See Section 8.1), the second field shall be 

labeled as field Type-1 record (See ed as 

field ueesignation character (IDC). See 

Section 7.3.1.

M Traditional: 

xx.002-IDC

<See Requirement ID: “Field: xx.002-IDC”.> t-2

TraditionalRecord: 

Type1-7-bit 

ASCII

Annex B The data in the Type-1 record shall always 

be recorded in variable length fields using 

the 7-bit American Standard Code for 

Information Interchange (ASCII) as 

described in ISO/IEC 64656. For purposes 

of compatibility, the eighth (leftmost) bit 

shall contain a value of zero. All field 

numbers and information separators shall 

be recorded in 7-bit ASCII as described in 

ISO/IEC 646.

M Traditional: 

Type-1-

ASCII

<See Requirement ID: “Record: Type1-ASCII”> t-2

TraditionalField: 

xx.001, 

xx.002, 

xx.999 

Ordered

Annex B Textual fields in Record Types 10-99 may 

occur in any order after the first two 

fields and contain the information as 

described for that particular numbered 

field, except for field 999, which shall be 

the concluding field, when it is included in 

a record.

M Traditional: 

xx.001-First

<See Requirement ID: “Field: xx.001-Record 

Header”.>

t-2

M Traditional: 

xx.002-

Second

<See Requirement ID: “Field: xx.002-IDC”.> t-2

1 M Traditional: 

xx.999-Last

ForEach(Record in Transaction ST Type(Record) 

NEQ 4 OR 8)

{

FieldNumber(Last(Field in Record)) EQ 999

}

T

TraditionalTransaction: 

Separators

Annex B,

Table 90

In the Type-1, Type-2, Type-9 through 

Type-99 records, information is delimited 

by the four ASCII information separators. 

The delimited information may be items 

1 M Traditional:

Separators 

FS

ForEach(Record in Transaction ST Type(Record) 

MO [1,2,9 to 99])

{

Last(Byte in Record) EQ 0x1C

}

T
166

within a field or subfield, fields within a 

logical record, or multiple occurrences of 

subfields.

1 M Traditional:

Separators 

GS

<Not directly tested. The GS separator is used 

when parsing fields within a record.>

t-13

1 M Traditional:

Separators 

RS,US

<Not directly tested. The RS and US separators 

are used when parsing subfields and information 

items.>

t-13

TraditionalTransaction: 

FS Separator

Annex B Multiple records within a transaction are 

separated by the “FS” character, which 

signals the end of a logical record.

M Traditional: 

FS 

Separator

<See Requirement ID: “Traditional-Transaction: 

Separators”.>

t-2

TraditionalTransaction: 

US, RS, GS, 

Separators

Annex B The “USe x Bonal-Transaction: US, RS, iple

items within a field or subfield; the “RShin 

a field or subfield; the , 

ipleSeparatorsated the

“GSeleSeparatorsated ated ; the , 

ipleSeparatorsa

M Traditional: 

US, RS, GS 

Separators

<See Requirement ID: “Traditional-Transaction: 

Separators”.>

t-2

TraditionalTransaction: 

Data Length 

Minimum

B.1 Each information item, subfield, field, and 

logical record shall contain one or more 

bytes of data

1 M Traditional:

Data 

Length 

Minimum

<This assertion is testing during the Character 

Count and Byte Length testing for each Record 

Type, which test for 1 byte of data at a 

minimum. See the following Type-10 

Requirement ID’s as an example: 

Field: Type10-CharCount and 

Field: Type10-Subfield CharCount .>

t-2

TraditionalTransaction: 

Big-Endian

B.1.1 Within a file, the order for transmission of 

both the ASCII and the binary 

representations of bytes shall be most 

significant byte first and least significant 

byte last otherwise referred to as BigEndian format. Within a byte, the order of 

transmission shall be the most significant 

bit first and the least significant bit last.

2 M Traditional:

Data BigEndian

<Not directly tested. However, the parsing 

methods use the Big-Endian format when 

processing transactions.>

t-13

TraditionalTransaction: 

Date Format

B.1.2 Dates shall appear as eight digits in the 

format YYYYMMDD. The YYYY characters 

shall represent the year of the 

transaction; the MM characters shall be 

the tens and units values of the month; 

and the DD characters shall be the day in 

the month.

1 M Traditional: 

Date 

Format

<This assertion is tested for each field or subfield 

that requires a date entry. For example, see 

Requirement ID “Field: 1.005-Local Date Value”.>

t-2
167

TraditionalField: 

Agency Code 

Subfield 2

B.1.3 The 2007 version of the standard included 

only the first information item in agency 

code fields (See Section 7.6). New to this 

version, a second, optional, information 

item is allowed in Traditional encoding in 

order to maintain consistency with the 

2008 version of the standard.

M Traditional: 

Agency 

Code 

Subfield 2

<See Requirement ID: “Field: Agency Codes”.>

TraditionalTransaction: 

GMT/UTC

B.1.4 GMT/UTC shall be represented as 

YYYYMMDDHHMMSSZ, a 15-character 

string that is the concatenation of the 

date with the time and concludes with 

the character nal enco

YYYY characters shall represent the year 

of the transaction. The MM characters 

shall be the tens and units values of the 

month. The DD characters shall be the 

tens and units values of the day of the 

month. The HH characters represent the 

hour; the MM the minute; and the SS 

represents the second.

M Traditional: 

GMT/UTC

<This assertion is tested for each field or subfield 

that requires a GMT/UTC entry. For example, see 

Requirement ID “Field: Geographic-Subfield 1”.>

t-2

TraditionalTransaction: 

Field 

Numbering

B.1.5 For the Type-1, Type-2, Type-9 through 

Type-99 records, each information field 

that is used shall be numbered in 

accordance with this standard. The 

format for each field shall consist of the 

logical record type number followed by a 

period rmat for each field followed by a 

colon al record type number followed by 

a pepriate to that field. The field number 

may be any one to nine-digit number 

occurring between the period field. The

colon may be any one to nine-digit 

number occurring betweeneld number. 

This implies that a field number of y one 

to nine-digit numberand shall be 

interpreted in the same manner as a field 

number of “2.000000123:.

1 M Traditional: 

Field 

Numbering

<Not directly tested. However, the parsing 

methods use the described format when 

processing transactions.>

t-13
168

Traditional-

Record: 

Types 1,2,9 

ASCII

B.1.5 Logical Type

-1, Type-2, and Type-9 

records contain only ASCII textual data 

fields. The ASCII File Separator ment ID a 

fields. The (signifying the end of the 

logical record or transaction) shall follow 

the last byte of ASCII information and 

shall be included in the length of the 

record.

M Traditional: 

Type1-

ASCII

<See Requirement ID: “Record: Type1-ASCII”.>t-2

1M Traditional: 

Types 2,9-

ASCII

ForEach(Field in Record ST Type(Record) EQ 2 OR 

9) {

{Bytes(Field)} MO [0x02, 0x03, 0x1C to 0x7E] }

T

M Traditional: 

Types 

1,2,9-FS 

Separator

<See Requirement ID: “Traditional-Transaction: 

Separators”.>

t-2

Traditional-

Record: 

Types 4,8 

Binary

B.1.5 The Record Type

-4: Grayscale fingerprint 

image and the Record Type-8: Signature 

image record contain only binary data 

recorded as ordered fixed-length binary 

fields. The entire length of the record 

shall be recorded in the first four-byte 

binary field of each record. For these 

binary records, neither the record 

number with its period, nor the field

identifier number and its following colon, 

shall be recorded. Furthermore, as all the 

field lengths of these six records are 

either fixed and specified, none of the 

four separato characters (“US”, “RS”,” 

GS”, or “FS”) shall be interpreted as 

anything other than binary data. For 

these binary records, the ”FS” character 

shall not be used as a record separator or 

transaction terminating character.

M Traditional: 

Type4-

Binary

<See Requirement ID: “Field: Type4-CharType”.>t-2

M Traditional: 

Type8-

Binary

<The test assertions for this type may not be 

supported in this version of the CTM. If they are 

supported, they are included under field testing 

for Record Type-8: Signature image record.>

t-2

Traditional-

Record: 

Types 10 to 

99 Format

B.1.5 The Type

-10 through Type-99 records 

combine ASCII fields with a single binary 

sample field. Each ASCII field contains a 

numeric field identifier and its descriptive 

data. When Field 999 is present in a 

record it shall appear as the last entry in 

the record and shall contain the data 

placed immediately following the colon 

(er and its descriptive data. When record 

length field shall contain the length of the 

M Traditional: 

Types 10 to 

99, xx.999 

last

<See Requirement ID: “Traditional-Field: xx.001, 

xx.002, xx.999 Ordered” .>

t-2

M Traditional: 

Types 10 to 

99, Record 

Length

<See Requirement ID: “Field: xx.001-Record 

Header”.>

t-2

M Traditional: 

Types 10 to 

99, FS 

Separator

<See Requirement ID: “Traditional-Transaction: 

Separators”.>

t-2
169

record. The ASCII File Separator 

“FS”control character shall follow the last 

byte of the compressed or uncompressed 

sample data. The “FS” character shall 

signify the end of the logical record or 

transaction and shall be included as part 

of the record length.

TraditionalTransaction: 

Base 64

B.1.5 The Base-64 encoding scheme (See Annex 

A: Character encoding information) shall

be used for converting non-ASCII text into 

ASCII form. The field number including 

the period and colon, for example II text 

into ASCII form. The “US”, “RS”, “GS”, and 

“FS” information separators shall appear 

in the transaction as 7-bit ASCII characters 

without conversion to Base-64 encoding.

Traditional: 

Base 64

<Not tested.> t-4

TraditionalTransaction: 

Encoding 

Sets

B.1.6 In order to effect data and transaction 

interchanges between non-English 

speaking or foreign-based agencies, a 

technique is available to encode 

information using character encoding sets

other than 7-bit ASCII.

Traditional:

Additional 

Encoding 

Sets

<Not Tested.> t-4

TraditionalField: 1.001 

Record 

Header

B.2.1 Field 1.001 Record header shall begin

with d header ecordode is renamed UTF16, a

record including every character of every 

field contained in the record and the

information separators. The cter of every 

field contained in the record and theng 

setsField 1.001 from the next field.

M Traditional: 

1.001-

Record 

Length

<See Requirement ID “Field: xx.001-Record 

Header”>

t-2

M Traditional: 

1.001-GS 

Separator

<See Requirement ID: “Traditional-Transaction: 

Separators”.>

t-2

TraditionalField: 1.005 

Date Format

B.2.1 The year, month, and day values in Field 

1.005 Date / DAT are concatenated

“YYYYMMDD”

M Traditional: 

1.005-Date 

Format

<See Requirement ID “Field: 1.005-Local Date 

Value”.>

t-2

TraditionalField: 1.013 

DOM

B.2.1 In Field 1.013 Domain name / DOM, the 

default is “1.013:NORAM‘US’‘GS’”

Traditional: 

1.013-DOM

<Not Tested.> t-3

Traditional- B.2.1 Immediately following the last M Traditional: <See Requirement ID: “Traditional-Transaction: t-2
170

Transaction: 

FS Separator 

Replaces GS

information item in the Type-1 record 

(See Section 8.1), an tFSFSn 8.1 following 

the last information item in the from the 

next logical record. This “FS” character 

shall replace the “GS” character that is 

normally used between information

fields. This is the case with all Record 

Types.

FS Replaces 

GS

Separators”.>

TraditionalRecord: 

Type4-Fields 

Fixed

B.2.2 The order of fields for Type-4 records is 

fixed. All fields and data in this record 

type shall be recorded as binary 

information.

2 M Traditional: 

Type4 

Fields Fixed

<Not tested directly, but Type 4 is parsed as 

unnumbered binary data>.

t-13

TraditionalRecord: 

Type7-

Requiremen

ts TBD

B.2.3 <This section contains requirements 

regarding Type-7 records. If this type is 

supported by the CTM, the requirements 

will be added.>

- Traditional: 

Type7 

Assertions 

TBD

<This section contains requirements regarding 

Type-7 records. If this type is supported by the 

CTM, the assertions will be added.>

t-15

TraditionalRecord: 

Type8-

Requiremen

ts TBD

B.2.4 <This section contains requirements 

regarding Type-8 records. If this type is 

supported by the CTM, the requirements 

will be added.>

- Traditional: 

Type8

Assertions 

TBD

<This section contains requirements regarding 

Type-8 records. If this type is supported by the 

CTM, the assertions will be added.>

t-15

TraditionalRecord: 

Type9-

Requiremen

ts TBD

B.2.5 <This section contains requirements 

regarding Type-9 records. If this type is 

supported by the CTM, the requirements 

will be added.>

- Traditional: 

Type9

Assertions 

TBD

<This section contains requirements regarding 

Type-9 records. If this type is supported by the 

CTM, the assertions will be added.>

t-15

TraditionalFields 

10.029, 

10.032 

Feature 

Points

B.2.6 For facial feature points (Field 10.029: 2D 

Facial feature points / FFP and Field

10.032: 3D facial feature points/ 3DF), the 

first information item is followed by “US” 

separator character. The second 

information item is feature point code, 

followed by “US”. The third is the X 

coordinate, followed by USem is feature 

point code, followed byrtedal

Field 10.032, the fifth information item is 

the Z coordinate. Each feature block shall 

O Traditional: 

10.029, 

10.032 

Feature 

Points

<See Requirement IDs: “Field: 10.029- 2D Facial 

Feature Points Value” and “Field: 10.032- 3D 

Facial Feature Points Value”.>

t-2
171

be separated by the tRSn item is the Z 

coordi

TraditionalTransaction: 

Type11-

Reserved

B.2.7 This Record Type is reserved for future 

use as Voice data.

M Traditional: 

Type11-

Reserved

<See Requirement ID: “Transaction: Reserved 

Records”.>

t-2

TraditionalTransaction: 

Type12-

Reserved

B.2.8 This Record Type is reserved for future 

use as Dental data.

M Traditional: 

Type12-

Reserved

<See Requirement ID: “Transaction: Reserved 

Records”.>

t-2

TraditionalField: 13.014 

RS 

Separated

B.2.9 For Field 13.014: Search position 

descriptors / SPD, multiple portions of the 

EJI may be listed and separated by the 

”RS” character. 

M Traditional: 

13.014-RS 

Separated

<See Requirement ID: 

“Field: SPD,PPD Values .>

t-2

TraditionalField: 13.015 

Subfields

B.2.9 For Field Field 13.015: Print position 

coordinates / PPC, the six information 

items within the field are separated by 

five sUS PPCDDental data.SUblock shall 

belowed by tedal definitions may be 

repeated as subfields separated by the 

dRSblock shall 

M Traditional: 

13.015-

Subfields

<See Requirement ID: 

“Field: PPC-Subfield Occurrences”.>

t-2

TraditionalField: 13.024 

Subfields

B.2.9 Field Field 13.024: Latent quality metric / 

LQM may contain one or more subfields,

each consisting of four information items 

separated by the”US” character. The 

subfield may be repeated for each latent 

image and quality algorithm used, 

separated by the “RS” character.

M Traditional: 

13.024-

Subfields

<See Requirement IDs: “Field: Sample Quality 

Occurrences” to 

“Field: Sample Quality Additional Subfield”.>

t-2

TraditionalField: 14.025 

Format

B.2.10 Field 14.025: Alternate finger segment 

position(s) / ASEG shall consist of one to 

four subfields. Each subfield shall consist 

of a finger number between 1 and 10, or 

16 or 17; the total number of vertices of 

the polygon encompassing the finger; and 

the set of consecutive vertices. Each 

vertex shall be represented as horizontal 

and vertical pixel offsets relative to the 

origin positioned in the upper left corner 

M Traditional: 

14.025-

Format

<See Requirement ID: “Field: 14.025-Alternate 

Finger Segment Position(s) Value” and “Field: 

Type14-Subfield Occurrence”.>

t-2
172

of the image. The horizontal offsets (X) 

are the pixel counts to the right, and the 

vertical offsets (Y) are the pixel counts 

down from the origin. A minimum of 

three points is required to describe a

finger location. A rom the origin. A 

minimum of three points is required to 

describe a finger location. A uUSed to 

describe ainimum of three points is requir

number, the number of vertices, each X 

coordinate, and each Y coordinate.

Subfields representing each finger are 

delimited by the g each fingerd each Y 

coo 

TraditionalField: 19.018 

Requiremen

ts TBD

B.2.15 Field 19.018: Friction ridge - plantar 

segment position(s) / FSP shall consist of 

one to four subfields. Each subfield shall 

consist of a plantar number between 1 

and 10, the total number of vertices of 

the polygon encompassing the plantar, 

and the set of consecutive vertices. Each 

vertex shall be represented as horizontal 

and vertical pixel offsets relative to the 

origin positioned in the upper left corner 

of the image. The horizontal offsets (X)

are the pixel counts to the right, and the 

vertical offsets (Y) are the pixel counts 

down from the origin. A minimum of 

three points is required to describe a 

plantar location. A “USom the origin. A 

minimum of three points is required to 

dethe number of vertices, each X 

coordinate, and each Y coordinate. 

Subfields representing each plantar are 

delimited by the orSinate, and each Y 

coor

- Traditional: 

19.018

Assertions 

TBD

<This section contains requirements regarding 

Type-19 records. If this type is supported by the 

CTM, the assertions will be added.>

t-15
173

C.4 Test Notes

The following test notes provide clarification of the assertion text included in the Test Assertion columns. The test notes contain various 

types of information including:

Additional information to help clarify complex assertions such as image metadata and IDC comparisons. 

Explanations of decisions made when the base standard is not clear or contains possible discrepancies. 

“Exception” which refers to any AN-2011 requirement that does not have an associated assertion defined in this document.

t-1. Semantic (Level 3) assertions are not included in the tables except to intentionally clarify that the assertion is L3. An explanation 

may be given explaining why the assertion is considered L3. 

t-2. The assertions for this requirement are listed in another section of a table as described in the “Test Assertion” column.

t-3. Assertions related to Domain Names and Application Profile Specifications are not addressed in the tables. 

t-4. Assertions related to Character Sets other than 7-bit ASCII or binary are not addressed in the tables.

t-5. Refer to the IDC tables below to determine the test output based upon the types being compared for matching IDCs.

Table C-16 - IDC ID Location Comparison

IDC: ID Location Comparison

Record Type Field 10.003 Biometric Field For Comparison ID

4 NA FINGER Byte 1 of 4.004

10 FACE FACE NA

10 SCAR SCAR (1,1) of 10.040

10 MARK MARK (1,1) of 10.040

10 TATTOO TATTOO (1,1) of 10.040

13 NA FINGER (1,1) of 13.013

14 NA FINGER (1,1) of 14.013

17 NA IRIS 17.003 IF 17.003 = 1 Or 2

Table C-17 - IDC Comparison Results

IDC: Comparison Results

First Record Second Record Comparison IDs Result

FINGER FINGER Same Ok

FINGER FINGER Different Error
174

FINGER NEQFINGER NA Error

FACE FACE NA Ok

FACE NEQ FACE NA Error

IRIS IRIS Both = 1 Or Both 

= 2

Ok

IRIS IRIS Not (Both = 1 Or 

Both = 2)

Error

IRIS NEQ IRIS NA Error

SCAR SCAR Same Ok

SCAR SCAR Different Warning

SCAR MARK Or 

TATTOO

Same or Different Warning

SCAR FINGER, 

FACE Or IRIS

NA Error

MARK MARK Same Ok

MARK MARK Different Warning

MARK SCAR Or 

TATTOO

Same or Different Warning

MARK FINGER, 

FACE Or IRIS

NA Error

TATTOO TATTOO Same Ok

TATTOO TATTOO Different Warning

TATTOO SCAR Or 

MARK

Same or Different Warning

TATTOO FINGER, 

FACE Or IRIS

NA Error

t-6. UTC has replaced GMT. Date and time are defined in section 7.7.2 of the standard. The set of values ValidUTC/GMT is described 

in section 7.7.2.2 of the standard and is always less than the current date and time. ValidUTC/GMT is in the form 

YYYYMMDDHHMMSSZ; NIEM-ValidUTC/GMT is in the form YYYY-MM-DDThh:mm:ssZ. The ValidLocalDate is in the 

form YYYYMMDD; NIEM-ValidLocalDate is in the form YYYY-MM-DD.

t-7. Assertions for alternate coordinate systems are not included in the tables. 

t-8. Refer to http://earth-info.nga.mil/GandG/coordsys/grids/utm.html to determine valid values for the band of latitude and grid zone. 

There are possible discrepancies in the AN-2011 standard regarding the 10th information item for field xx.998. While the standard 

states that the coordinates are UTM (defined only for the area between 84N and 80S), it also allows values outside of UTM. 
175

However, allowing these extraneous values which are valid in UPS causes problems with the formatting such as the band of latitude, 

which doesn’t exist for those values. Therefore, this draft of the AN-2011 Assertion Tables does not allow values A,B,Y, and Z for 

the 10th information item. 

t-9. L2 and L3 assertions associated with SAP, FAP, and IAP are not included in the tables. Some of the assertions, such as determining

the conditions under which the samples were collected to ensure the SAP, FAP, or IAP levels, are not feasible to test at this time. 

t-10. IBIA Vendor Registry is a registry of CBEFF Biometric Organizations that map the value QAV to a registered organization. The 

assertions will accept any values, as the standard does not require that the value be registered with IBIA. 

t-11. All image-related assertions associated with compressed image types are tested against the image metadata only and not against the 

image itself. Features of each of the image type’s metadata are defined in the “Image Metadata” table below. Combining the 

“Term” with the “Image Type” gives the specific implementation. For example, {Image Height-PNG} is equivalent to “2nd

parameter of the IHDR chunk”. Also, IHDR means Image Header Chunk, so the full definition becomes “2nd parameter of the 

Image Header Chunk in a PNG image.” Note that for NIEM encoding, the image data must first be converted from Base-64. 

Table C-18 - Image Metadata

Image Metadata 

Term Image Type(s) Implementation

Image Width

JPEG, JPEGL 4

th parameter of the Frame Header not counting the SOF marker

JP2, JP2L 2

nd parameter of Image Header box

PNG 1

st parameter of IHDR chunk

WSQ 5

th parameter of SOF not counting the SOF marker

Image Height

JPEG, JPEGL 3

rd

 parameter of the Frame Header not counting the SOF marker

JP2, JP2L 1

st

 parameter of Image Header box

PNG 2

nd parameter of IHDR chunk

WSQ 4

th parameter of SOF not counting the SOF marker

Sampling Units

JPEG, JPEGL 4

th parameter in JFIF Header not counting the APP0 Marker

JP2, JP2L Undefined

PNG 3

rd parameter of PHYS chunk

WSQ Undefined

Horizontal Density

JPEG, JPEGL 5

th parameter in JFIF Header not counting the APP0 Marker

JP2, JP2L Undefined

PNG 1

st parameter in PHYS Chunk

WSQ Undefined

Vertical Density JPEG, JPEGL 6

th parameter in JFIF Header not counting the APP0 Marker

JP2, JP2L Undefined
176

PNG 2

nd

 parameter in PHYS Chunk

WSQ Undefined

BPX

JPEG, JPEGL 2nd parameter of the Frame Header not counting the SOF marker

JP2, JP2L 7 LSB of 4th parameter of ImgBox + 1 if 4

th parameter of ImgBox is not 255

PNG 3

rd parameter of IHDR chunk

WSQ Undefined

CSP

JPEG, JPEGL Undefined

JP2, JP2L 4

th parameter of Colour Specification box

PNG 4

th

 parameter of IHDR chunk

WSQ Undefined

Encoder Version WSQ 10th parameter of SOF not counting the SOF marker

SOI JPEG, JPEGL Start of JPEG type image. 

WSQ Start of WSQ image.

SOF JPEG, JPEGL Start of frame in a JPEG type image. 

WSQ Start of WSQ image.

EOI JPEG, JPEGL End of a JPEG type image. 

WSQ End of WSQ image.

SOB WSQ Start of block in a WSQ image.

SigBox JP2,JP2L Signature Box that marks the start of a JP2 type image.

HeadBox JP2,JP2L Header Box in a JP2 type image.

ImgBox JP2, JP2L Image Header Box in a JP2 type image.

PNGSig PNG Signature of a PNG image.

IHDR PNG Image Header Chunk in a PNG image.

IDAT PNG Image Data Chunk in a PNG image.

IEND PNG Image End Chunk in a PNG image.

JFIF Header JPEG, JPEGL Frame for specifying JPEG type image metadata. Its inclusion is required by the standard.

PHYS Chunk PNG An optional Chunk in a PNG image that may be used if present to verify image attributes.

t-12. The image metadata required to implement the assertion is not defined in the image standard documentation.

t-13. The assertion is addressed during parsing. 

t-14. Further research is needed to determine the feasibility of testing for ASEG requirements related to the polygon structure. 

t-15. These requirements are related to record types currently not supported. 

t-98. There are some discrepancies in the 4th draft of the standard regarding compression algorithms for various record types. For Type4 records, Table 21 and section 8.4.8 state that the value can be 0 to 6 (any compression algorithm) while section 8.4 states that 

“All images shall be compressed using WSQ”. The assertions only allow WSQ and uncompressed types (values 0 and 1). For 
177

Type 10, section 7.7.9.3 does not define which compression algorithms are valid for facial images. The assertions allow all 

compression algorithms (except WSQ) for facial images. For Types 13 and 14, section 7.7.9.1 indicates that WSQ shall be used 

for grayscale friction ridges at 500 ppi. It does not specify if any other types may be used. Also, section 5.3.13 specifies that 

Type-13 should only allow uncompressed and lossless compression. The assertions will support WSQ and lossless for Type 13, 

and will allow any compression for Type 14. For Type 17, the section 7.7.9.2 clearly states that the baseline JPEG algorithm may 

not be used. The assertions will support compression algorithms specified by Table 71: NONE, PNG, JP2, and JP2L. The 

assertions will be modified later on according to the content of the 5th draft.

t-99. Further research is needed to determine the assertions required to test for conformance to this requirement.
178

Annex D: Exceptions Table

An “exception” refers to any AN-2011 requirement that does not have an associated assertion defined in this document. Table C.1 identifies 

and provides justification for all exceptions present in the tables. 

Table D.1 - Exceptions Table

Exception Section Requirement Summary Justification

Domain 

Names / 

Application 

Profile 

Specifications

5.3.2 Data contained in this record shall conform in format and content to the 

specifications of the domain name(s) as listed in Field 1.013 Domain name / DOM 

found in the Type-1 record, if that field is in the transaction. The default domain is 

NORAM. Field 1.016 Application profile specifications / APS allows the user to 

indicate conformance to multiple specifications. If Field 1.016 is specified, the 

Type-2 record must conform to each of the application profiles. 

A DOM or APS reference uniquely identifies data contents and formats. Each 

domain and application profile shall have a point of contact responsible for 

maintaining this list. The contact shall serve as a registrar and maintain a 

repository including documentation for all of its common and user-specific Type-2 

data fields. As additional fields are required by specific agencies for their own 

applications, new fields and definitions may be registered and reserved to have a 

specific meaning. When this occurs, the domain or application profile registrar is 

responsible for registering a single definition for each number used by different 

members of the domain or application profile .

The format and content of the 

record are defined by the DOM 

or APS. Each DOM and APS has 

related record-content definitions 

that may be updated. The 

evolving nature of the DOM and 

APS definitions and nature of 

using registrars makes testing for 

conformance via the CTS very 

difficult.

6 An implementation domain, coded in Field 1.013 Domain name / DOM of a Type1 record as an optional field, is a group of agencies or organizations that have 

agreed to use preassigned data fields with specific meanings (typically in Record 

Type-2) for exchanging information unique to their installations. The 

implementation domain is usually understood to be the primary application profile 

of the standard.

New to this version of the standard, Field 1.016 Application profile specifications / 

APS allows multiple application profiles to be referenced. The organization 

responsible for the profile, the profile name and its version are all mandatory for 

each application profile specified. A transaction must conform to each profile that 

is included in this field. It is possible to use Field 1.016 and / or Field 1.013.

Since the “transaction must 

conform to each profile” 

included in the field, and those 

profiles are defined by the listed 

agency, the CTS would have to 

retrieve the latest requirements 

from the agency. 

Also, testing that all specified 

DOM and APS have the same 

definitions for fields, subfields, 

and information items is not 
179

A specified implementation domain and specified application profiles must all 

have the same definition for fields, subfields and information items that are 

contained in the transaction.

feasible.

Alternate

Character 

Sets

5.6,

Table 2

Field 1.015 Character encoding/DCS is an optional field that allows the user to 

specify an alternate character encoding... Field 1.015 Character encoding/DCS 

contains three information items: the character encoding set index/ CSI, the 

character encoding sent name/CSN, and the character encoding set version/CSV. 

The first two items are selected from the appropriate columns of Table 2.

Table 2 lists ASCII, UTF-16, 

UTF-8, and UTF-32 as possible 

encodings. However, the table 

also allows “User-defined” 

character encoding sets. Testing 

for conformance to user-defined 

character encoding sets is not 

feasible for the CTS. Further 

research is needed to support 

Character sets other than 7-bit 

ASCII.

Alternate 

Coordinate 

System

7.7.3,

Table 4

The ninth information item is the geodetic datum code / GDC10. It is an 

alphanumeric value of 3 to 6 characters in length. This information item is used to 

indicate which coordinate system was used to represent the values in information 

items 2 through 7. If no entry is made in this information item, then the basis for 

the values entered in the first eight information items shall be WGS84, the code 

for the World Geodetic Survey 1984 version - WGS 84 (G873). See Table 4 for 

values.

Table 4 lists 22 coordinate 

systems and the option to include 

“Other” types as well. It is not 

feasible for the CTS to test 

conformance to all coordinate 

systems, specifically those that 

are listed by the user under 

“Other”. 

7.7.3 A fourteenth optional information item geographic coordinate other system 

identifier / OSI allows for other coordinate systems. This information items

specifies the system identifier. It is up to 10 characters in length. Examples are:

• MGRS (Military Grid Reference System)

• USNG (United States National Grid)

• GARS (Global Area Reference System)

• GEOREF (World Geographic Reference)

• LANDMARK (e.g. hydrant) and position relative to the landmark.

A fifteenth optional information item, is the geographic coordinate other system

value / OCV. It shall only be present if OSI is present in the record. It can be up to 

126 characters in length. If OSI is LANDMARK, OCV is free text and may be up 

to 126 characters. For details on the formatting of OCV for the other coordinate 

While some examples are listed 

(MGRS, USNG, GARS, 

GEOREF, LANDMARK), there 

may be others that are not listed. 

It is not feasible for the CTS to 

test conformance to these 

coordinate systems, specifically 

those that may be included but 

are not listed as examples. 
180

systems shown in OSI as examples, see http://earthinfo.nga.mil/GandG/coordsys/grids/referencesys.html 

Subject 

Acquisition 

Profiles

SAP/FAP/IAP

7.7.5,

Table 8, 

Table 9,

Table 10

A subject acquisition profile is used to describe a set of characteristics concerning 

the capture of the biometric sample. These profiles have mnemonics SAP for face, 

FAP for fingerprints and IAP for iris records.

It is not feasible to test if the 

image was captured under the 

conditions specified by the SAP, 

FAP or IAP level as defined in 

Tables 8, 9 and 10. However, the 

fields will be tested for valid 

level values. 

Open and 

Closed Paths

7.8 Several Record Types define open paths (also called contours or polylines) and / 

or closed paths (polygons) on an image. They are comprised of a set of vertices. 

For each, the order of the vertices shall be in their consecutive order along the 

length of the path, either clockwise or counterclockwise. (A straight line of only 

two points may start at either end). A path may not have any sides crossing. No 

two vertices shall occupy the same position.

There may be up to 99 vertices.

An open path is a series of connected line segments that do not close or overlap. A 

closed path (polygon) completes a circuit. The closed path side defined by the last 

vertex and the first vertex shall complete the polygon. A polygon shall have at 

least 3 vertices. The contours in Record Type-17: Iris image record can be a circle 

or ellipse. A circle only requires 2 points to define it (See Table 16).

There are two different approaches to the paths in this standard. The 2007 and 

2008 version of the standard used paths for Field 14.025: Alternate finger segment 

position(s) / ASEG.

That approach has been retained in this version for all paths except in the 

Extended Feature Set (EFS) of Record Type-9. The EFS adopted an approach 

expressing the path in a single information item, which is different than that used 

in other record types.

Further research is needed to 

determine the feasibility of 

testing for: 

-simple, plane figure

-no sides crossing

-no interior holes