Conformance Test Architecture and 

Test Suite for ANSI/NIST-ITL 1-2007

Fernando L. Podio

Dylan Yaga

Christofer J. McGinnis

NISTIR 7791
NISTIR 7791

Conformance Test Architecture and 

Test Suite for ANSI/NIST-ITL 1-2007

Fernando L. Podio

Dylan Yaga

Christofer J. McGinnis

June 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

Gary Locke, Secretary

National Institute of Standards and Technology

Patrick D. Gallagher, 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

76 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

Acknowledgment

The authors would like to acknowledge Mark Jerde from ID Technology Partners (NIST contractor 

for this project) as the principal software developer of the Conformance Test Architecture/Test Suite 

addressed in this publication.

Sponsor

The work described in this document was sponsored by The Department of Homeland Security/USVISIT Program.

Feedback

The Conformance Test Architecture (CTA)/Test Suite (CTS), sample data and documentation can be 

downloaded from the following web site: 

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

Feedback on the CTA/CTS, the sample data and documentation are welcome. Please send comments 

to csdbiomcta@nist.gov.

Abstract

The Computer Security Division 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 these standards and the associated conformance test architectures 

and test suites. 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 specified in its Traditional Format,

is Part 1: ANSI/NIST-ITL 1-2007. Although a revised and augmented version of the standard is 

under development, the 2007 version is still widely used. The Conformance Test Architecture and 

Test Suite described in this publication are designed to test implementations of ANSI/NIST ITL 1-

2007. The code (Beta 0.4) is currently designed to support testing of selected record types of the 

standard but can be extended to support other record types as required. A high-level overview of the 

architecture and test suite as well as software details and the code structure are provided. A quick 

start user guide and a comprehensive table of the standard’s requirements and the associated 

implemented conformance test assertions (over five-hundred and thirty) are 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 Support for the ANSI/NIST- ITL 1-2007 Standard .................................................... 2

1.4 Requirements in the Standard and Conformance Test Assertions .......................... 2

1.5 Hierarchy of Conformance Tests .............................................................................. 3

1.6 Target Audience ....................................................................................................... 4

2 CTA/CTS Overview ........................................................................................................ 5

2.1 High-Level Architecture ............................................................................................ 5

2.2 Software Details........................................................................................................ 6

3 Quick Start...................................................................................................................... 7

3.1 Installation................................................................................................................. 7

3.2 Loading and Running Implementations .................................................................... 8

4 Test Results ................................................................................................................. 10

4.1 Overall Results........................................................................................................ 10

4.2 Detailed Results...................................................................................................... 10

Annex A - Code Structure.................................................................................................. 16

Annex B - References ........................................................................................................ 19

Annex C - Standard Requirements and Conformance Test Assertions ....................... 20

List of Figures and Tables

Figure 2-1: CTA/CTS High-Level Architecture................................................................... 5

Figure 3-1: CTA/CTS Welcome............................................................................................ 7

Figure 3-2: ANSI/NIST-ITL 1-2007 Test Window ................................................................ 8

Figure 4-1: Pass/Fail Results............................................................................................. 10

Figure 4-2: ANSI/NIST-ITL 1-2007 Detailed Results ........................................................ 11

Figure 4-3: Output Options................................................................................................ 11

Figure 4-4: Header Sample ................................................................................................ 12

Figure 4-5: TOC Sample..................................................................................................... 12

Figure 4-6: Type Selection Menu ...................................................................................... 12
vi

Figure 4-7: Type Selection Menu ...................................................................................... 13

Figure 4-8: Field-Level Parse Test Sample ...................................................................... 13

Figure 4-9: L1, L2 Tests Sample........................................................................................ 14

Figure 4-10: File-Level Results Sample............................................................................ 14

Figure 4-11: Record-Level Results Sample...................................................................... 14

Figure 4-12: Field-Level Results Sample.......................................................................... 15

Figure 4-13: Fields Option Not Selected .......................................................................... 15

Figure A-1: Class Diagram for the An107 File Class....................................................... 17

Figure A-2: Class Diagram for the Data Types ................................................................ 18

Table C-1 – Operators Use in Table C-4 Test Assertions ............................................... 20

Table C-2 - Description of the Operands Used in Table C-4 Test Assertions .............. 21

Table C-3 Terms Used in Table C-4 Test Assertions ...................................................... 22

Table C-4 - Requirements and Conformance Test Assertions ...................................... 23
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 first version of the standard dates to 1986. Over the years, 

it has been updated and expanded to cover more biometric modalities beyond the original record type 

of fingerprint minutiae. Current modalities are:

Fingerprint minutiae 

Fingerprint image (flat/plain, rolled and latent) 

Scars, marks and tattoos 

Facial image 

Iris image 

Palmprint image 

The current version of the ANSI/NIST-ITL standard is:

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, there is an extension to the table of finger position codes in both parts of the standard to 

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

The standard is now in the process of being revised. A workshop was held July 27-29, 2010 at NIST 

to determine what new biometric modalities and associated data should be included in a new version 

of the standard. Working groups established at this workshop provided input for the updated 

standard. Two drafts were developed (the first draft incorporated the output of the working groups). 

The second draft incorporated changes based on comments received after the first draft was issued. 

A second workshop, to discuss this draft was held on March 1-3, 2011 at NIST in Gaithersburg, 

MD., USA. A third draft was developed after the second workshop. At the time of this writing a 

new draft (fourth draft) was made available for review and comment. The fourth draft can be 

downloaded from the ANSI/NIST-ITL Standard Homepage [4].

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. 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. NIST/ITL CSD develops these 

conformance test tools to support users that require conformance to selected biometric standards and 

to also support 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 
2

assessment programs to validate conformance to biometric standards. Conformance testing provides 

developers, users, and purchasers with increased levels of confidence in product quality and increases 

the probability of successful interoperability. A Conformance Test Architecture (CTA) as well as 

Conformance Test Suites (CTS) designed to test implementations of selected biometric data 

interchange formats developed by Technical Committee M1- Biometrics [5] of the InterNational 

Committee for Information Technology Standards (INCITS) and Subcommittee 37 (SC 37) –

Biometrics of the Joint Technical Committee 1 (JTC 1) of ISO and IEC [6] are available for 

download at a NIST/ITL CSD web page [7]. 

1.3 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 

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

were considered the first-priority tier. In addition to testing Record Type 1, “Transaction 

Information Record”, the selected records supported by the CTA/CTS are:

Type 4, High-resolution grayscale fingerprint image

Type 10, Facial and SMT image

Type 13, Variable-resolution latent image

Type 14, Variable-resolution fingerprint image

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 tool is designed to detail a transaction’s level of 

conformance to the standard. The granularity of the output information in the test results is provided 

in section 4. The CTA/CTS can also be used as an analysis tool for determining which parts of the 

transaction (e.g., non-conformant 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.

1.4 Requirements in the Standard and Conformance Test Assertions

The CTA/CTS code implements the assertions required to test all of the mandatory, conditional and 

optional requirements for Record Type 1 and the other supported Record Types1. One or more 

assertions are required to adequately test conformance for a given requirement. Section 1.5, below, 

briefly describes Levels 1, 2 and 3 test assertions; more detail is available in the standards identified 

in the footnote 22. In addition to parsing tests which are initially performed, over five-hundred Level 

 

1 Although the standard specifies the Record Type fields as either being Mandatory or Optional, many of the Optional fields are

conditional to the content of other fields/requirements.

2 The concepts addressed in sections 1.4 and 1.5 are based on definitions and discussions included in the following standards: 

ISO/IEC 29109-1:2009, Conformance testing methodology for biometric data interchange formats defined in ISO/IEC 19794 –

Biometric Data Format Standard - Part 1: Generalized conformance testing methodology and the 7th draft of Conformance testing 

methodology for ANSI/NIST- ITL 1- 2011 developed by the ANSI/NIST-ITL Conformance Working Group, February 22, 2011.
3

1 and 2 assertions were implemented in the code. The assertions also apply to a particular scope, 

with the scope being “File”, “Record” or “Field.”. Level 3 assertions were not implemented.

Table C-3 of Appendix C documents the requirements and test assertions for the selected Record 

Types. Requirements in the standard that are not tested in the current CTA/CTS release version 

(Beta Version 0.4) are noted in the table. They include: (a) requirements related to International 

Character Sets; (b) image-based requirements where the image metadata required to implement the 

assertion is not defined in the image standard; and (c) four assertions related to the alternate finger 

segment position(s) (ASEG) specified in field 14.025. The required algorithms to implement these 

assertions are under research.

1.5 Hierarchy of Conformance Tests

Three levels of conformance testing are defined below:

Level 1 – Checking internal content 

In Level 1 testing, an ANSI/NIST-ITL 1-2007 transaction(s) is checked for field-by-field, subfieldby-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 ANSI/NIST-ITL 1-2007 transactions created with those components need to be available. 

Level 2 – Internal consistency checking

In Level 2 testing, an ANSI/NIST-ITL 1-2007 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 ANSI/NIST-ITL 1-2007 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 ANSI/NIST-ITL 1-2007 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 ANSI/NIST-ITL 1-2007 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. 
4

1.6 Target Audience

Although this publication is written for users of the Architecture/Conformance Test Suite, technical 

details of the architecture, operations, and the code structure are provided for more technicallyinclined readers.
5

2 CTA/CTS Overview

2.1 High-Level Architecture

The high-level architecture implemented for the CTA/CTS can be described using four key 

components. As depicted in Figure 2-1, each of these components addresses different testing levels. 

These components are identified as Pre-Parse testing and Field, Record and File-level testing. 

Figure 2-1: CTA/CTS High-Level Architecture

Pre-Parsing Operations

This operation verifies that the file exists (e.g., it’s not NULL) and that the proper arguments are sent 

to the software. In addition, the file is opened and tests are performed to verify that the first two 

characters in the file are “1.” since every ANSI/NIST-ITL 1-2007 transaction must start with Record 

Type 1.

Structure Discovery/Field Testing

During structure discovery, the Table of Contents (TOC) in Record Type 1 is read and the file is

parsed based on the TOC. As the software parses the file, it builds an array containing all fields that 

are found in each of the records in the transaction. Level 1 testing is then performed for these fields, 

using the Field definitions (XML file) shown in Figure 2-1. The field definitions file includes 

metadata on each field such as:

Type/fields number

Length min and max

Min and max occurrences

Required Level 1 tests 

AN2007 Module

AN2007

File Pre-Parsing Record-Level 

Testing

Structure 

Discovery/Field 

Testing

File-Level 

Testing

Field 

definitions

(XML)

Test 

Report
6

Level 1 test messages (errors, warning, notes, etc.) are maintained with the corresponding fields

within the structure data in memory.

Once this operation is performed and the structure is built, record-level testing is ready to be 

performed as detailed below. The structure discovery module is designed to allow the parsing 

method to change based on the type of data present (e.g., binary, ASCII, ASCII/binary). This 

flexible approach allows also for future revisions of the test tool to allow additional data types to be 

parsed. The structure discovery/fields testing module includes information on all Level 1 assertions,

messages, and message types that will be included in a test report. 

Record-Level Testing

In this module, initial Level 2 tests are performed such as:

Does the record length equal the number of bytes read?

Are the correct Record types included in each record?

For each record, is field 1 first, field 2 second and field 999 last?

Final record Level 2 tests are performed such as checking whether all mandatory and conditional 

fields are present and whether the field occurrences are correct.

File-Level Testing

Level 2 tests that include fields of more than one record are performed within this module, such as 

the requirements associated with the Image Designation Character (IDC) values for each record.

2.2 Software Details

The code is developed in C# under the Microsoft® .NET 4.0 Framework. The code structure uses 

interfaces that allow the CTS to treat every Record Type in the same manner while testing. This 

allows the high-level structure in the code that pertains to all Record Types to be expanded to other 

Record Types (not supported in this CTA/CTS version) without having redundant code for this level 

of testing. Derived classes from these interfaces can implement specific tests required for each 

supported Record Type. Annex A provides a description and class diagram for the code structure, 

and is oriented towards readers interested in technical details of the code structure.
7

3 Quick Start

3.1 Installation

Run the installation program NIST ITL CSD CTA Beta 0.4.exe, and follow the on 

screen prompts. The CTA/CTS runs in a Windows environment. It is developed under .NET 

v 4.0.

After installation, the loaded application should resemble the image below:

Figure 3-1: CTA/CTS Welcome 
8

3.2 Loading and Running Implementations

The “ANSI/NIST-ITL 1-2007” tab must be selected before files can be loaded. An image 

of the test window is shown in Figure 3-2.

Figure 3-2: ANSI/NIST-ITL 1-2007 Test Window

Loading Files

There are two options for loading files:

1. Click the “AN1” button to specify the file path. If this option is used, the 

selected files will be loaded but the tests will not run until the “Run” button is 

selected. 

2. Drag and drop one or many files into the window. If this method is chosen, the tests 

will automatically run and display as passed or failed. 
9

If necessary, click the “C” (Clear) button to remove the loaded files. 

Running Tests

Click the “Run” button to run the tests. The files loaded in the window will display as 

passed or failed, indicated by a green or red circle respectively.

Sample Data Location

The sample data is available from the following locations for these versions of Microsoft®

Windows®:

XP: C:\Documents and Settings\All Users\Documents\ ANSI NIST-ITL 1-2007 

Sample Files

Vista: C:\Users\Public\Documents\ANSI NIST-ITL 1-2007 Sample Files

7: C:\Users\Public\Documents\ANSI NIST-ITL 1-2007 Sample Files
10

4 Test Results

To generate the test results, specify the file path using the “AN1” button and click the “Run” 

button to run the tests. Alternatively, drag and drop the files into the GUI and the tests will 

run automatically. 

4.1 Overall Results

After running the tests using one of the methods mentioned previously, the overall pass/fail 

results of the tests will be displayed in the “ANSI/NIST-ITL 1-2007” window. An example 

of the pass/fail results is shown below, with red (darker) circles representing failures and 

green circles representing successes. 

Figure 4-1: Pass/Fail Results

The complete file path to the implementation is also listed for reference. In addition to these 

overall results, a detailed summary is also displayed in a separate window. The detailed 

summary is discussed in the next section.

4.2 Detailed Results

The detailed results are displayed in a new window titled “ANSI/NIST-ITL 1-2007”, with the 

tab titled “Full”. The contents of this window are defined by the “Output Options” that are 

selected before running the tests. These options may also be selected after running the tests 

to update the detailed results dynamically. The image below depicts the detailed summary 

window with sample results. 
11

Figure 4-2: ANSI/NIST-ITL 1-2007 Detailed Results

The “Save” button, shown in Figure 4-2 below the “ANSI/NIST-ITL 1-2007” tile bar, may 

be clicked to save the test results to a text file. After clicking the “Save” button, a Windows 

Explorer browser window will open to allow a file location and name to be selected.

Output Options

On the “ANSI/NIST-ITL 1-2007” tab depicted in Figure 3-2, several options are available for 

formatting the test results detailed output as shown in Figure 4-3 below. 

Figure 4-3: Output Options 
12

Header

The “Header” option displays general information about the implementation including the 

pass/fail status and the file path. A sample header is shown below for a passing 

implementation. 

Figure 4-4: Header Sample 

TOC 

The “TOC” option displays a table of contents describing all of the content for a given 

implementation, including Type, IDC, Offset, and Length. The number preceding each line 

in the TOC (such as #01 shown in Figure 4-5) is an identifier assigned to each record found 

inside of the file as it is sequentially parsed. This identifier clarifies the ordering of record

types found within each file.

Figure 4-5: TOC Sample 

Type Selection 

The type selection window allows the user to select which Record Types should be 

displayed, including Record Types 1, 4, 10, 13, 14, and 17 (or all record types included in the 

file). Only the option selected will be displayed in the results. For the unsupported Record 

Types (any type other than those shown in Figure 4-6), only the name and length of the 

record will be displayed in the results.

Figure 4-6: Type Selection Menu 

For example, the implementation below contains multiple types as shown in the TOC, but 

only the selected type (14) is shown in the results.
13

Figure 4-7: Type Selection Menu 

Parse Tests

The “Parse Tests” option displays parse test results (i.e., tests that are executed during 

parsing of the file, before the testing of L1 and L2 assertions). The “File Level Results” 

checkbox must be selected to view the parse tests. See Figure 4-8 for an example of parse 

tests in the file level results. 

Figure 4-8: Field-Level Parse Test Sample

L1 Tests/ L2 Tests 

The “L1 Tests” and “L2 Tests” options display L1 and/or L2 test results at the File, Record, 

and Field levels. The "Fields" checkbox and at least one of the File, Record, or Field Level 

checkboxes must be selected to view these results. 
14

Figure 4-9: L1, L2 Tests Sample

File Level Results

The “File Level Results” option displays results related to the file contents. 

Figure 4-10: File-Level Results Sample

Record Level Results

The “Record Level Results” option displays a summary of test results for the record.

Figure 4-11: Record-Level Results Sample

Since some Record Types are not supported, the presence of these Records in a file or 

transaction is noted but no action on the content of the record is taken. The Record length is 

stated in the test result.
15

Field Level Results

The “Field Level Results” option displays all test results for each field. Figure 4-12 depicts a 

sample of the Field Level Results. 

Figure 4-12: Field-Level Results Sample

Fields

The “Fields” option displays the fields within each test. If this option is not selected, “Field 

Level Results” will not be displayed. The image below shows the output when the “Fields” 

option is not selected, and thus no fields are displayed. 

Figure 4-13: Fields Option Not Selected

Hide Ok 

The “Hide Ok” option removes all tests results that return the status "Ok" from the detailed 

summary with the exception of Records/Fields in error. 

Field Range

Specifies which fields of the existing Record Types are displayed by the selected lower and 

upper bounds in these windows.
16

Annex A - Code Structure

This Annex discusses the elements of the code structure depicted in Figures A-1 and A-2 

below. 

The An107File Class is the entry point into the CTA/CTS module. It contains a list of all 

the Record Types encountered in a given transaction (file). After determining that the file 

exists, the parsing operation begins. As each Record in the file is parsed, it is added to the 

list of Records within the An107File Class.

IRecordType is an interface that defines required methods and attributes. There is a base 

Class that derives from this interface called “RecordBase” that performs all common 

Level 1 and Level 2 assertions for each Record. From RecordBase specific 

implementations for each Record Type to perform Record Type-specific parsing/testing can 

be derived. Parsing at this level could, as required, override the general parsing performed at 

the RecordBase level.

IField is the interface for fields which describes the content of fields in the file under test. 

IRecordType contains a list of IFields. FieldBase is a specific implementation of 

IField.

After each test is performed the code updates the list of results at every testing level (File, 

Record, Field, Subfield, and Subfield data). Possible results, listed in order of increasing 

severity are: (a) “Ok”; (b) “Note”; (c) “Warning”; (d) “Error”; and “Critical Error3”. There is 

also an overall result, once all tests have been completed. A Transaction is determined to be 

“passing” or “failing” in the OverallResult.

 

3 The module tries to run all assertions on all applicable data. That is, processing continues after results of 

Ok, Note, Warning and Error. But the result Critical Error means processing cannot continue because the 

next valid data element (field or record) could not be parsed successfully.
17

Figure A-1: Class Diagram for the An107 File Class
18

Figure A-2: Class Diagram for the Data Types
19

Annex B - References

[1] NIST Special Publication 500-271, ANSI/NIST-ITL 1-2007 (Revision of ANSI/NISTITL 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/NIST-ITL 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] ANSI/NIST Standard Homepage - http://www.nist.gov/itl/iad/ig/ansi_standard.cfm

[5] INCITS M1 – Biometrics Public Homepage -

http://standards.incits.org/a/public/group/m1

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

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

[7] NIST/ITL CSD Biometric Conformance Test Architectures and Test Suites 

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

Annex C - Standard Requirements and Conformance Test Assertions

Test assertions documented in Table C-4 below are expressed according to the operators and operands included in Tables C-1 and C-2 respectively, except 

for those instances where the assertion cannot be clearly or easily represented in a mathematical format. Table C-3 includes terms used throughout the assertions 

table. In the tool implementation all image-related assertions associated with compressed image types are tested against the image metadata only and not 

against the image itself. Even though Logical Record types 3 to 6 are not ASCII data, and are not represented in implementations as a tagged-field (e.g. 

4.001), they are represented as such in this table to make it easier to understand. For assertions formulated from several sections of the AN Standard, the 

assertion is listed once on the first requirement encountered.

Table C-1 – Operators Use in Table C-4 Test Assertions

Operator Description

EQ Equal. Tests for equality between two values. 

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

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

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

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

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

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

AND Logical And. Tests if both values are true.

OR Logical OR. Tests if any values are true. 

NOT Negate. Negates any operator or calculation that follows. 

ST Such That. For example, (X,Y) ST X GTE 0 AND Y LTE 10

IF Logical IF. Tests if the condition is true. 

IFF IF and Only IF. Tests that the condition guarantees another.

MOD The modulo operator. X MOD Y = the remainder of a X divided by Y

# All. Represents all legal values. 

: Data Element Selector. X:N selects the Nth data element in X. 

in The selector operator. X in Y selects only those X found in Y. 

to Range Selector. X to Y provides set of values Z ST Z GTE X AND Z LTE Y

, Range concatenation. X,Y provides the set of values X AND Y. 
21

Table C-2 - Description of the Operands Used in Table C-4 Test Assertions

Operand Description

Present(Value) Determines if Value is present.

Present(X in Y) Determines if X is present in Y.

Sum(Values) The summation of Values.

Count(Value) The number of occurrences of Value.

Count(X in Y) The number of X found in Y.

{X} Value of X.

Bytes(Value) All of the byte data contained within Value.

MinOccurrences(Value) The minimum number of occurrences allowed.

MaxOccurrences(Value) The maximum number of occurrences allowed.

MinSize(Value) The minimum size allowed per occurrence.

MaxSize(Value) The maximum size allowed per occurrence.

Min(Value)= The minimum of the set represented by Value.

Length(Value) The length of the Value.

First(X in Y) The first X found in Y.

Second(X in Y) The second X found in Y.

Last(X in Y) The last X found in Y.

Type(Value) The type of Record represented by Value.

FieldNumber(Value) The value of the field number for the field represented by Value.

ForEach(X in Y) {Expression(s)} Evaluate Expression for every X in Y.

Valid(X) A set of all valid values for X as defined by the requirement.

Note: When a data range is used in a calculation, the calculation is applied independently for each data element in the range. As an example, the 

expression:

Count(Subfields in 1.001,1.002) EQ 0 

is equivalent to:

Count(Subfields in 1.001) EQ 0 AND Count(Subfields in 1.002) EQ 0
22

Table C-3 Terms Used in Table C-4 Test Assertions

Term Description

NULL Control character with no value.

NA Not Applicable

Table C-4 includes the requirements (or a summary of the requirements) specified in ANSI/NIST-ITL 1-2007 standard and associated required 

conformance test assertions. Although references are included for all Record Types when appropriate (for example when a requirement detailed for 

“tagged-filed records”), the table focuses on requirements and assertions for the Record Types of interest: Record Type 1 and Record Types 4, 10, 13, 14, 

and 17. Explanations of the heading for each column in the table are included below. 

Table C-4 can be used for conformance test tool developers, implementers of the standard, and end-users as well as testing laboratories File, Record and 

Field-level requirements and assertions are included.

The table includes the following headings4:

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., file, record, and field). It could refer to more than one Record Type. 

Reference in the 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.

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.

Level: Indicates whether Level 1 or Level 2 conformance testing is required to address the requirement in the previous column. Assertions for Level 3 

conformance test are not included. A single cell is included for each assertion.

Status: Reflects the status specified in the standard (Mandatory (M) or Optional (O)) for each field. It might also indicate whether the requirement in 

the standard (e.g., field content, presence of field) is considered Mandatory or Optional. Conditional requirements (e.g., conditional to other 

information items) are tested according to the requirements but are not indicated as such in this column.

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

 

4

The table headings are derived from the tables of requirements and conformance test assertions specified in ISO/IEC 29109-1:2009, Conformance testing methodology for biometric data interchange 

formats defined in ISO/IEC 19794 – Biometric Data Format Standard - Part 1: Generalized conformance testing methodology and the 7th draft of the Conformance testing methodology for 

ANSI/NIST- ITL 1-2011 developed by the ANSI/NIST-ITL Conformance Working Group, February 22, 2011.
23

Test assertion: Provides, whenever possible, a mathematical equation or a procedure. Plain text is included 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.

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.

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. 

Table C-4 - Requirements and Conformance Test Assertions

Requirement

ID

Reference in 

Base 

Standard

Requirement

Summary

Level Status Assertion

ID

Test

Assertion

Test

Note

Implementation

Support

Supported

Range

Test

Result

File-Level Requirements and Assertions

7_Bit_ASCII 7, 

Table 4

7.1

The standard defines logical records, 

some of which include ASCII tagged 

textual fields. The data in the Type-1 

record shall always be recorded in 

variable length fields using 7-bit ASCII.

Text data in the Type-2, Type-9 and 

tagged-field records will normally use 7-

bit ASCII encoding. Mechanisms for 

using character sets other than 7-bit 

ASCII are given in section 8.2.3, 

International Character Sets. 

1 M 7-Bit_Ascii::1.001 to 

1.015

{ 1.001 to 1.015} LT 128

1 M 7-Bit_Ascii::10.001

to 10.013

{10.001 to 10.013} LT 128

1 M 7-Bit_Ascii::10.016, 

10.017

{10.016, 10.017} LT 128

1 M 7-Bit_Ascii::10.020

to 10.030

{10.020 to 10.030} LT 128

1 M 7-Bit_Ascii::10.040

to 10.043

{10.040 to 10.043} LT 128

1 M 7-Bit_Ascii::13.001

to 13.017

{13.001 to 13.017} LT 128

1 M 7-Bit_Ascii::13.020, 

13.024

{13.020, 13.024} LT 128

1 M 7-Bit_Ascii::14.001

to 14.018

{14.001 to 14.018} LT 128

1 M 7-Bit_Ascii::14.020

to 14.025

{14.020 to 14.025} LT 128

1 M 7-Bit_Ascii::14.030 {14.030} LT 128

1 M 7-Bit_Ascii::17.001 {17.001 to 17.026} LT 128
24

to 17.026

1 M 7-Bit_Ascii::17.030 {17.030} LT 128

(1,2,9).001-Fld1First 7.1 The first field in all tagged-field records 

(Types 1, 2 and 9) shall be labeled as 

field "1".

2 M 1,2,9.001-Fld1First See 1.001-First (handled in Record 

Type assertions)

(1,2,9).002-

Fld2Second

7.1 The second field in all tagged-field 

records (Types 1, 2 and 9) shall be 

labeled as field "2".

2 M 1.002-Fld2Second See 1.002-Second (handled in Record 

Type assertions)

(1,2,9).001-

RecBytes

7.1 The first field in all tagged-field records 

shall contain the length in bytes of the 

record.

2 M 1.001-RecBytes {1.001} EQ Length(Record) 

(3-6, 8).Contents 7.1 For the binary image Type-3, Type-4, 

Type-5, Type-6, and Type-8 logical 

records, the content and order of the 

recorded fields are specified by this 

standard. With the exception of the first 

two fields, the remaining fields of the 

Type-7 logical image record are all userdefined. All fields and data in these 

record types shall be recorded as binary 

information.

2 M 3-6,8.#-Contents

The test assertions are included below 

under field testing for Record Type 4

(3-6, 8).Field_Order 7.1, 

11.1

For the binary image Type-3, Type-4, 

Type-5, Type-6, and Type-8 logical 

records, the content and order of the 

recorded fields are specified by this 

standard. With the exception of the first 

two fields, the remaining fields of the 

Type-7 logical image record are all userdefined. All fields and data in these 

record types shall be recorded as binary 

information.

Within each logical record, entries shall 

be provided in nine ordered and 

unnumbered fields

Table 10 lists the contents of each of the 

nine fields (for Type-3 through Type-6).

2 M Type-4.-

Fields_In_Order

IF Type(Record) EQ 4 THEN

Count(Fields) EQ 9 AND Fields:1 to 

Fields: 9 must be ordered.

File-OneType-1 7.2 Files to be exchanged are required to 

contain one and only one Type-1 logical

record per transaction.

2 M File-OneType-1 Count(Records ST Type(Records) EQ 1) 

EQ 1

File-Type-1_First 7.2 The Type-1 logical record shall always be 

the first logical record within the file.

2 M File-Type-1_First Type(First(Record in Transaction)) EQ 1

XX(-1).002-IDCRqd 7.4 With the exception of the Type-1 logical 

record, each of the remaining logical 

records present in a file shall include a 

separate field containing the Image 

2 M 4.002-HasIdc Present(4.002)

2 M 10.002-HasIdc Present(10.002)

2 M 13.002-HasIdc Present(13.002)

2 M 14.002-HasIdc Present(14.002)
25

Designation Character (IDC). 2 M 17.002-HasIdc Present(17.002)

Valid IDC 7.4 The IDC shall be used to relate 

information items in the file content 

field of the Type-1 record to each logical 

record.

2 M See Below

1.003-

CNT_ListsRecs

The test assertion is addressed for each 

individual supported Record Type 

below

002-IDC_-Sequence 7.4 The value of the IDC shall be a 

sequentially assigned positive integer 

starting from zero and incremented by 

one (up to a maximum of 255).

2 M 002-IDC_ZeroFirst

{First(Field in Transaction) ST 

FieldNumber(Field) EQ 2} EQ 0

2 M 002-IDC_Zero_Min-

_Value

{#.002} GTE 0

2 M 002-IDC_255_Max-

_Value

{#.002} LTE 255

2 M 002-IDC_IncByOne Each new IDC is one greater than the 

previous maximum IDC value.

002-RelatedIDCs 7.4

The IDC shall be used to properly 

identify and link together logical records 

that pertain to the same entity such as a 

particular finger or face.

2 M IDC_Entity_-

Supported_Types_

Only

Type(Record) MO [1,4,10,13,14, 17]

2 M IDC_Entity_Has_IDC Type(Record) MO [4, 10,13,14,17]

2 M IDC_Entity_-

Choose_-

Biometric_And_-

Comparison_Id

Record

Type

Field 

10.003

BiometricField 

For 

Comparison 

ID

4 NA FINGE

R

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 TATTO

O

TATTO

O

(1,1) of 

10.040

13 NA FINGE

R

(1,1) of 

13.013

14 NA FINGE

R

(1,1) of 

14.013

17 NA IRIS 17.003 

IF 

17.003 

= 1 Or 2

2 M IDC_Entity_-

Compare_Records_

With_The_Same_-

IDC_Value

First 

Record

Second 

Record

Compar

ison IDs

Result

FINGE

R

FINGE

R

Same Ok

FINGE

R

FINGE

R

Differen

t

Error

FINGE

R

NEQFI

NGER

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 NA Error
26

IRIS

SCAR SCAR Same Ok

SCAR SCAR Differen

t

Warning

SCAR MARK 

Or 

TATTO

O

Same or 

Differen

t

Warning

SCAR FINGE

R, 

FACE 

Or IRIS

NA Error

MARK MARK Same Ok

MARK MARK Differen

t

Warning

MARK SCAR 

Or 

TATTO

O

Same or 

Differen

t

Warning

MARK FINGE

R, 

FACE 

Or IRIS

NA Error

TATTO

O

TATTO

O

Same Ok

TATTO

O

TATTO

O

Differen

t

Warning

TATTO

O

SCAR 

Or 

MARK

Same or 

Differen

t

Warning

TATTO

O

FINGE

R, 

FACE 

Or IRIS

NA Error

Record-Level Requirements and Assertions

File::OneOrMoreRe

cs

8.2 A transaction file shall consist of one or 

more logical records.

2 M File::OneOrMoreRecsCount(Records in Transaction) GTE 1 ???

AppropriateFieldsPerRecord8.2 For each logical record contained in the 

file, several information fields 

appropriate to that record type shall be 

present.

2 M AppropriateFields These test assertions are included in 

the tests for the supported Record 

Types below.

No_Subfields 8.2, 

8.2.1,

Various subsections of

9.1,

15.1,

18.1,

19.1,

22.2

Sections 8.2 and 8.2.1 describe the 

mechanism that enables a field to 

contain multiple information items 

known as subfields. The following fields 

are defined to have a single information 

field and contain no subfields:

1.001, 1.002, 1.004 to 1.012, 1.014

10.001 to 10.013, 10.016, 10.017, 

10.020, 10.021, 10.027, 10.030

13.001 to 13.012, 13.016, 13.017

13.020

14.001 to 14.012, 14.016, 14.017, 

14.020, 14.030

1 M Single_NoSubFields:

:1.001, 1.002

Count(Subfields in 1.001, 1.002 ) EQ 0

1 M Single_NoSubFields:

:1.004 to 1.012

Count(1.Subfields in 004 to 1.012 ) EQ 

0

1 M Single_NoSubFields:

:1.014

Count(Subfields in 1.014 ) EQ 0

1 M Single_NoSubFields:

:10.001 to 10.013

Count(Subfields in 10.001 to 10.013 ) 

EQ 0

1 M Single_NoSubFields:

:10.016, 10.017

Count(Subfields in 10.016, 10.017 ) EQ 

0

1 M Single_NoSubFields:

:10.020, 10.021

Count(Subfields in 10.020, 10.021 ) EQ 

0

1 M Single_NoSubFields:

:10.027

Count(Subfields in 10.027 ) EQ 0

1 M Single_NoSubFields:

:10.030

Count(Subfields in 10.030 ) EQ 0

1 M Single_NoSubFields:

:13.001 to 13.012

Count(Subfields in 13.001 to 13.012 ) 

EQ 0
27

17.001 to 17.015, 17.017, 17.018, 

17.020 to 17.023, 17.025, 17.026, 

17.030

1 M Single_NoSubFields:

:13.016, 13.017

Count(Subfields in 13.016, 13.017 ) EQ 

0

1 M Single_NoSubFields:

:13.020

Count(Subfields in 13.020 ) EQ 0

1 M Single_NoSubFields:

:14.001 to 14.012

Count(Subfields in 14.001 to 14.012 ) 

EQ 0

1 M Single_NoSubFields:

:14.016, 14.017

Count(Subfields in 14.016, 14.017 ) EQ 

0

1 M Single_NoSubFields:

:14.020, 14.030

Count(Subfields in 14.020, 14.030 ) EQ 

0

1 M Single_NoSubFields:

:17.001 to 17.015

Count(Subfields in 17.001 to 17.015 ) 

EQ 0

1 M Single_NoSubFields:

:17.017, 17.018

Count(Subfields in 17.017, 17.018 ) EQ 

0

1 M Single_NoSubFields:

:17.020 to 17.023

Count(Subfields in 17.020 to 17.023 ) 

EQ 0

1 M Single_NoSubFields:

:17.025, 17.026

Count(Subfields in 17.025, 17.026 ) EQ 

0

1 M Single_NoSubFields:

:17.030

Count(Subfields in 17.030 ) EQ 0

Valid_Record_Type 8.2.2 For tagged-field logical records each 

field shall begin with the logical record 

type number chosen from Table 4.

1 M RecordTypeValid::1.

001 to 1.015

IF Type(Record) EQ 1 THEN 

Type(1.001 to 1.015) EQ 1

1 M RecordTypeValid::1

0.001 to 10.013

IF Type(Record) EQ 10 THEN 

Type(10.001 to 10.013) EQ 10

1 M RecordTypeValid::1

0.016, 10.017

IF Type(Record) EQ 10 THEN 

Type(10.016,10.017) EQ 10

1 M RecordTypeValid::1

0.020 to 10.030

IF Type(Record) EQ 10 THEN 

Type(10.020 to 10.030) EQ 10

1 M RecordTypeValid::1

0.040 to 10.043

IF Type(Record) EQ 10 THEN 

Type(10.040 to 10.043) EQ 10

1 M RecordTypeValid::1

0.999

IF Type(Record) EQ 10 THEN 

Type(10.999) EQ 10

1 M RecordTypeValid::1

3.001 to 13.017

IF Type(Record) EQ 13 THEN 

Type(13.001 to 13.017) EQ 13

1 M RecordTypeValid::1

3.020, 13.024

IF Type(Record) EQ 13 THEN 

Type(13.020, 13.024) EQ 13

1 M RecordTypeValid::1

3.999

IF Type(Record) EQ 13 THEN 

Type(13.999) EQ 13

1 M RecordTypeValid::1

4.001 to 14.018

IF Type(Record) EQ 14 THEN 

Type(14.001 to 14.018) EQ 14

1 M RecordTypeValid::1

4.020 to 14.025

IF Type(Record) EQ 14 THEN 

Type(14.020 to 14.025) EQ 14

1 M RecordTypeValid::1

4.030

IF Type(Record) EQ 14 THEN 

Type(14.030) EQ 14

1 M RecordTypeValid::1

4.999

IF Type(Record) EQ 14 THEN 

Type(14.999) EQ 14

1 M RecordTypeValid::1 IF Type(Record) EQ 17 THEN 
28

7.001 to 17.026 Type(17.001 to 17.026) EQ 17

1 M RecordTypeValid::1

7.030

IF Type(Record) EQ 17 THEN 

Type(17.030) EQ 17

1 M RecordTypeValid::1

7.999

IF Type(Record) EQ 17 THEN 

Type(17.999) EQ 17

(1,2,9)-FsAtEnd 8.2.2 The ASCII File Separator ASCII FS control

character (signifying the end of the 

logical record or transaction) shall follow 

the last byte of ASCII information for 

each Type-1, Type-2, and Type-9 record.

2 M 1-FsAtEnd Last(Byte in Record) EQ ASCII FS

(1,2,9)-LenInclEndFs 8.2.2 The ASCII File Separator ASCII FS control

character (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 for each Type-1, Type-2, and 

Type-9 record.

2 M 1-LenInclEndFs Length(Record) EQ Sum(Field Lengths) 

+ 1

The last byte, ASCII FS, is included in 

the Record Length

(3-8).001-Length 8.2.2 The entire length of the record shall be

recorded in the first four-byte binary 

field of each Type-3 through Type-8 

record.

2 M 4.001-Length {4.001} EQ Length(Record)

(10,13-

17,99).999Last

8.2.2 The last physical field in a tagged-field 

image record (Types 10, 13, 14, 15, 16, 

17 & 99) shall always be numbered 

"999".

2 M 10.999Last FieldNumber(Last (Field in Record)) EQ 

999

2 M 13.999Last FieldNumber (Last (Field in Record)) EQ 

999

2 M 14.999Last FieldNumber (Last (Field in Record)) EQ 

999

2 M 17.999Last FieldNumber (Last (Field in Record)) EQ 

999

(10,13-17,99)-

FsAtEnd

8.2.2 The ASCII File Separator ASCII FS control 

character shall follow the last byte of the 

compressed or uncompressed image 

data in a tagged-field image record 

(Types 10, 13, 14, 15, 16, 17 & 99).

2 M 10-FsAtEnd Last(Byte in Record) EQ ASCII FS

2 M 13-FsAtEnd Last(Byte in Record) EQ ASCII FS

2 M 14-FsAtEnd Last(Byte in Record) EQ ASCII FS

2 M 17-FsAtEnd Last(Byte in Record) EQ ASCII FS

(10,13-17,99)-

LenInclEndFs

8.2.2 The ASCII FS character shall signify the 

end of the logical record or transaction 

and shall be included as part of the 

record length of a tagged-field image 

record (Types 10, 13, 14, 15, 16, 17 & 

99).

2 M 10-LenInclEndFs Length(Record) EQ Sum(Field Lengths) 

+ 1

The last byte, ASCII FS, is included in 

the Record Length

2 M 13-LenInclEndFs Length(Record) EQ Sum(Field Lengths) 

+ 1

The last byte, ASCII FS, is included in 

the Record Length

2 M 14-LenInclEndFs Length(Record) EQ Sum(Field Lengths) 

+ 1

The last byte, ASCII FS, is included in 
29

the Record Length

2 M 17-LenInclEndFs Length(Record) EQ Sum(Field Lengths) 

+ 1

The last byte, ASCII FS, is included in 

the Record Length

Intn’l Char Sets 8.2.3 NA NA NA NA Not supported in this version 1

Type 1 Requirements and Assertions

Length_Minimum_

Tagged_Field

9.1 

(Table 8), 

15.1 

(Table 17), 

18.1 

(Table 31),

19.1 

(Table 33),

22.1 

(Table 37)

This requirement is inferred from the 

Tables describing the Minimum Field 

size per occurrence and Minimum Occur 

count values for each record type. The 

length of the data shall be greater than 

or equal to the field's min size per 

occurrence times the min Occur count.

1 M LengthMin::1.001

to 1.015

Length(1.001 to 1.015) GTE 

MinSize(1.001 to 1.015) * 

MinOccurrences(1.001 to 1.015)

1 M LengthMin::10.001

to 10.013

Length(10.001 to 10.013) GTE 

MinSize(10.001 to 10.013) * 

MinOccurrences(10.001 to 1.013)

1 M LengthMin::10.016, 

10.017

Length(10.016,10.017) GTE 

MinSize(10.016, 10.017) * 

MinOccurrences(10.016, 10.017)

1 M LengthMin::10.020

to 10.030

Length(10.020 to 10.030) GTE 

MinSize(10.020 to 10.030) * 

MinOccurrences(10.020, 10.030)

1 M LengthMin::10.040

to 10.043

Length(10.040 to 10.043) GTE 

MinSize(10.040, to 10.043) * 

MinOccurrences(10.040 to 10.043)

1 M LengthMin::10.999 Length(10.999) GTE MinSize(10.999) * 

MinOccurrences(10.999)

1 M LengthMin::13.001

to 13.017

Length(13.001 to 13.017) GTE 

MinSize(13.001 to 13.017) * 

MinOccurrences(13.001 to 13.017)

1 M LengthMin::13.020 Length(13.020) GTE MinSize(13.020) * 

MinOccurrences(13.020)

1 M LengthMin::13.024 Length(13.024) GTE MinSize(13.024) * 

MinOccurrences(13.024)

1 M LengthMin::13.999 Length(13.999) GTE MinSize(13.999) * 

MinOccurrences(13.9999)

1 M LengthMin::14.001

to 14.018

Length(14.001 to 14.018) GTE 

MinSize(14.001 to 14.018) * 

MinOccurrences(14.001 to 14.018)

1 M LengthMin::14.020

to 14.025

Length(14.020 to 14.025) GTE 

MinSize(14.020 to 14.025) * 

MinOccurrences(14.020 to 14.025)

1 M LengthMin::14.030 Length(14.030) GTE MinSize(14.030) * 

MinOccurrences(14.030)

1 M LengthMin::14.999 Length(14.999) GTE MinSize(14.999) * 

MinOccurrences(14.999)

1 M LengthMin::17.001

to 17.026

Length(17.001 to 17.026) GTE 

MinSize(17.001 to 17.026) * 

MinOccurrences(17.001 to 17.026)

1 M LengthMin::17.030 Length(17.030) GTE MinSize(17.030) * 
30

MinOccurrences(17.030)

1 M LengthMin::17.999 Length(17.999) GTE MinSize(17.999) * 

MinOccurrences(17.999)

Length_Maximum_

Tagged _Field

9.1 

(Table 8), 

15.1 

(Table 17), 

18.1 

(Table 31),

19.1 

(Table 33),

22.1 

(Table 37)

This requirement is inferred from the 

Tables describing the Maximum Field 

size per occurrence and Maximum Occur 

count values for each record type. The 

length of the data shall be less than or 

equal to the field's max size per 

occurrence times the max Occur count.

1 M LengthMax::1.001

to 1.015

Length(1.001 to 1.015) LTE

MaxSize(1.001 to 1.015) * 

MaxOccurrences(1.001 to 1.015)

1 M LengthMax::10.001

to 10.013

Length(10.001 to 10.013) LTE

MaxSize(10.001 to 10.013) * 

MaxOccurrences(10.001 to 1.013)

1 M LengthMax::10.016, 

10.017

Length(10.016,10.017) LTE

MaxSize(10.016, 10.017) * 

MaxOccurrences(10.016, 10.017)

1 M LengthMax::10.020

to 10.030

Length(10.020 to 10.030) LTE

MaxSize(10.020 to 10.030) * 

MaxOccurrences(10.020, 10.030)

1 M LengthMax::10.040

TO 10.043

Length(10.040 to 10.043) LTE

MaxSize(10.040, to 10.043) * 

MaxOccurrences(10.040 to 10.043)

1 M LengthMax::10.999 Length(10.999) LTE MaxSize(10.999) * 

MaxOccurrences(10.999)

1 M LengthMax::13.001 

TO 13.017

Length(13.001 to 13.017) LTE

MaxSize(13.001 to 13.017) * 

MaxOccurrences(13.001 to 13.017)

1 M LengthMax::13.020 Length(13.020) LTE MaxSize(13.020) * 

MaxOccurrences(13.020)

1 M LengthMax::13.024 Length(13.024) LTE MaxSize(13.024) * 

MaxOccurrences(13.024)

1 M LengthMax::13.999 Length(13.999) LTE MaxSize(13.999) * 

MaxOccurrences(13.9999)

1 M LengthMax::14.001

TO 14.018

Length(14.001 to 14.018) LTE

MaxSize(14.001 to 14.018) * 

MaxOccurrences(14.001 to 14.018)

1 M LengthMax::14.020

TO 14.025

Length(14.020 to 14.025) LTE

MaxSize(14.020 to 14.025) * 

MaxOccurrences(14.020 to 14.025)

1 M LengthMax::14.030 Length(14.030) LTE MaxSize(14.030) * 

MaxOccurrences(14.030)

1 M LengthMax::14.999 Length(14.999) LTE MaxSize(14.999) * 

MaxOccurrences(14.999)

1 M LengthMax::17.001

TO 17.026

Length(17.001 to 17.026) LTE

MaxSize(17.001 to 17.026) * 

MaxOccurrences(17.001 to 17.026)

1 M LengthMax::17.030 Length(17.030) LTE MaxSize(17.030) * 

MaxOccurrences(17.030)

1 M LengthMax::17.999 Length(17.999) LTE MaxSize(17.999) * 

MaxOccurrences(17.999)

CharType_Numbers Table 8, 

Table 17, 

Table 31, 

Table 33, 

This requirement is inferred from the 

Tables describing the Char type for each 

record type. The following fields shall 

contain only numbers (ASCII 0x30 

1 M CharType_Numbers

::1.001, 1.002

Bytes(1.001,1.002) MO [0 to 9]

1 M CharType_Numbers

::1.005, 1.006

Bytes(1.005,1.006) MO [0 to 9]
31

Table 37 through 0x39):

1.001,1.002,1.005,1.006

10.001,10.002,10.005 to 

10.009,10.013,10.016,10.017

13.001 to 13.003, 13.005 to 13.010, 

13.012,13.013,13.016,13.017

14.001 to 14.003, 14.005 to 14.010, 

14.012, 14.016,14.017

17.001 to 17.003, 17.005 to 17.010, 

17.012, 17.020, 17.022, 17.023, 17.025, 

17.026

1 M CharType_Numbers

::10.001, 10.002

Bytes(10.001,10.002) MO [0 to 9]

1 M CharType_Numbers

::10.005 to 10.009

Bytes(10.005 to 10.009) MO [0 to 9]

1 M CharType_Numbers

::10.013

Bytes(10.013) MO [0 to 9]

1 M CharType_Numbers

::10.016,10.017

Bytes(10.016,10.017) MO [0 to 9]

1 M CharType_Numbers

::10.017

Bytes(10.017) MO [0 to 9]

1 M CharType_Numbers

::13.001 to 13.003

Bytes(13.001 to 13.003)MO [0 to 9]

1 M CharType_Numbers

::13.005 to 13.010

Bytes(13.005 to 13.010) MO [0 to 9]

1 M CharType_Numbers

::13.012, 13.013

Bytes(13.012, 13.013) MO [0 to 9]

1 M CharType_Numbers

::13.016, 13.017

Bytes(13.016,13.017) MO [0 to 9]

1 M CharType_Numbers

::14.001 to 14.003

Bytes(14.001 to 14.003) MO [0 to 9]

1 M CharType_Numbers

::14.005 to 14.010

Bytes(14.005 to 14.010) MO [0 to 9]

1 M CharType_Numbers

::14.012

Bytes(14.012) MO [0 to 9]

1 M CharType_Numbers

::14.016, 14.017

Bytes(14.016,14.017) MO [0 to 9]

1 M CharType_Numbers

::17.001 to 17.003

Bytes(17.001 to 17003) MO [0 to 9]

1 M CharType_Numbers

::17.005 to 17.010

Bytes(17.005 to 17.010) MO [0 to 9]

1 M CharType_Numbers

::17.012

Bytes(17.012) MO [0 to 9]

1 M CharType_Numbers

::17.020

Bytes(17.020) MO [0 to 9]

1 M CharType_Numbers

::17.022, 17.023

Bytes(17.022, 17.023) MO [0 to 9]

1 M CharType_Numbers

::17.025, 17.026

Bytes(17.025, 17.026) MO [0 to 9]

1 M CharType_Numbers

::17.030

Bytes(17.030) MO [0 to 9]

1.001-First 9.1 Within a Type-1 logical record, entries 

shall be provided in numbered fields. It 

is required that the first two fields of the 

record are ordered.1.001 must be the 

first field.

2 M 1.001-First IF Type(Record) EQ 1 THEN

FieldNumber (First(Field in Record)) EQ 

1 

1.002-Second 9.1 Within a Type-1 logical record, entries 

shall be provided in numbered fields. It 

is required that the first two fields of the 

record are ordered. 1.002 must be the 

second field.

2 M 1.002-Second IF Type(Record) EQ 1 THEN

FieldNumber(Second(Field in Record)) 

EQ 2 
32

1.xxx-Mandatory 9.1

Table 8

Table 8 lists the “condition code” as 

being mandatory “M” or optional “O”

2 M 1.xxx-Mandatory Present(Mandatory Fields)

1.xxxMaxOccurances9.1

Table 8

The “Occur count Max” column of Table 

8 lists the maximum number of times a 

field can occur in a Type-1 record.

2 M 1.xxxMaxOccurancesCount(1.xxx) LTE 

MaxOccurrences(1.xxx)

Version=0400 9.1.2 The entry for this 2007 version of the 

approved standard shall be '0400'.

1 M Value_0400::1.002 {1.002} EQ 0400

CharType_Numbers

_Subfields

9.1.3, 

15.1.22,

15.1.23,

15.1.31,

18.1.21,

19.1.13,

19.1.21 to 

19.1.25,

22.2.16,

22.2.24

The following fields shall only contain 

numbers (ASCII 0x30 through 0x39), 

ASCII US (0x1F) and ASCII RS (0x1E):

1.003 

10.024, 10.025, 10.041

13.024

14.013, 14.021 to 14.025

17.016, 17.024

1 M CharType_Numbers

_US_RS::1.003

Bytes(1.003) MO [0 to 9, ASCII US, 

ASCII RS]

1 M CharType_Numbers

_US_RS::10.024, 

10.025

Bytes(10.024,10.025) MO [0 to 9, ASCII 

US, ASCII RS]

1 M CharType_Numbers

_US_RS::10.041

Bytes(10.041) MO [0 to 9, ASCII US, 

ASCII RS]

1 M CharType_Numbers

_US_RS::13.024

Bytes(13.024) MO [0 to 9, ASCII US, 

ASCII RS]

1 M CharType_Numbers

_US_RS::14.013

Bytes(14.013) MO [0 to 9, ASCII US, 

ASCII RS]

1 M CharType_Numbers

_US_RS::14.021 to 

14.025

Bytes(14.021 to 14.025) MO [0 to 9, 

ASCII US, ASCII RS]

1 M CharType_Numbers

_US_RS::17.016

Bytes(17.016) MO [0 to 9, ASCII US, 

ASCII RS]

1 M CharType_Numbers

_US_RS::17.024

Bytes(17.024) MO [0 to 9, ASCII US, 

ASCII RS]

Subfields_Nx2 9.1.3, 

18.1.14, 

19.1.18, 

19.1.22

The following fields shall contain one or 

more RS_Subfields, which each contain 

two US_Subfields:

13.014, 14.018, 14.022

Field 1.003 shall contain two or more 

RS_Subfields, which each contain two 

US_Subfields

1 M Nx2::1.003 Count(RS_Subfields in 1.003 ) GTE 2 

AND

ForEach(RS_Subfield in 1.003 )

{

Count(US_Subfields) EQ 2

}

2

1 M Nx2::13.014 Count(RS_Subfields in 13.014 ) GTE 1 

AND

ForEach(RS_Subfield in 13.014 )

{

Count(US_Subfields) EQ 2

}

2

1 M Nx2::14.018 Count(RS_Subfields in 14.018 ) GTE 1 

AND

ForEach(RS_Subfield in 14.018 )

{

Count(US_Subfields) EQ 2

}

2

1 M Nx2::14.022 Count(RS_Subfields in 14.022 ) GTE 1 

AND

ForEach(RS_Subfield in 14.022 )

{

Count(US_Subfields) EQ 2

}

2

1.003- 9.1.3 Field 1.003, File Content (CNT) shall list 2 M 1.003- Field 1.003, File Content (CNT) shall list 
33

CNT_ListsRecs and identify each of the logical records 

in the file by record type. It also specifies 

the order in which the remaining logical 

records shall appear in the file. 

Each of the subfields after the first 

subfield of Field 1.003 relate to a single

Type-2 through Type-99 logical record 

contained in the file. Two information 

items shall comprise each subfield. The 

first information item shall be the record 

identifier character(s) chosen from Table 

4 that identifies the record type. This 

identifier must match the record type of 

the corresponding record in the field.

CNT_ListsRecs and identify each of the logical records 

in the file by record type. It also 

specifies the order in which the 

remaining logical records shall appear 

in the file. 

Each of the subfields after the first 

subfield of Field 1.003 relate to a single 

Type-2 through Type-99 logical record 

contained in the file. Two information 

items shall comprise each subfield. The 

first information item shall be the 

record identifier character(s) chosen 

from Table 4 that identifies the record 

type. This identifier must match the 

record type of the corresponding 

record in the field.

1.003-NumFollowingRecs=NumFollowingSubfields9.1.3 The second information item of the first 

subfield of Field 1.003 (CNT) shall be the 

sum of the Type-2 through Type-99 

logical records contained in this file. 

This number is also the number of 

remaining subfields in the CNT field.

2 M 1.003-NumFollowingRecs=NumFollowingSubfieldsThe second information item of the 

first subfield of Field 1.003 (CNT) shall 

be the sum of the Type-2 through 

Type-99 logical records contained in 

this file. This number is also the 

number of remaining subfields in the 

CNT field.

1.003-

CNT_IDCsMatchRec

s

9.1.3 Each of the subfields after the first 

subfield of Field 1.003 relate to a single 

Type-2 through Type-99 logical record 

contained in the file. Two information 

items shall comprise each subfield. The 

second item shall be the IDC associated 

with the logical record pertaining to that

subfield. 

2 M 1.003-CNT_IDCsMatchRecsEach of the subfields after the first 

subfield of Field 1.003 relate to a single 

Type-2 through Type-99 logical record 

contained in the file. Two information 

items shall comprise each subfield. The 

second item shall be the IDC associated 

with the logical record pertaining to 

that subfield. 

Unspecified Data

9.1.1, 

Various subsections of 

9.1,

11.2,

15.1, 

18.1

19.1,

22.2

This requirement is not explicitly stated, 

but instead is a generalization for all 

fields where the content cannot be 

checked against any known value. For 

all such fields that allow unspecified 

data, the content of the field is always 

accepted. These fields include:

1.001, 1.004, 1.007 to 1.013

4.001, 4.002, 4.006, 4.007, 4.009

10.001, 10.002, 10.004, 10.006, 10.007, 

10.009, 10.010, 10.016, 10.017, 10.025, 

10.026, 10.041

13.001, 13.002, 13.004, 13.006 to 

13.010, 13.016, 13.017

13.020

1 M Opaque::1.001 True

1 M Opaque::1.004 True

1 M Opaque::1.007 to 

1.013

True

1 M Opaque::4.001, 

4.002

True

1 M Opaque::4.006, 

4.007

True

1 M Opaque::4.009 True

1 M Opaque::10.001, 

10.002

True

1 M Opaque::10.004 True

1 M Opaque::10.006, 

10.007

True

1 M Opaque::10.009, 

10.010

True

1 M Opaque::10.016, 

10.017

True
34

14.001, 14.002, 14.004, 14.006, 14.007, 

14.009, 14.010, 14.016, 14.017, 14.020

17.001, 17.002, 17.004, 17.006, 17.007, 

17.009, 17.010, 17.014, 17.015, 17.018, 

17.019, 17.021 to 17.024, 17.026

1 M Opaque::10.025, 

10.026

True

1 M Opaque::10.041 True

1 M Opaque::13.001, 

13.002

True

1 M Opaque::13.004 True

1 M Opaque::13.006 to 

13.010

True

1 M Opaque::13.016, 

13.017

True

1 M Opaque::13.020 True

1 M Opaque::14.001, 

14.002

True

1 M Opaque::14.004 True

1 M Opaque::14.006, 

14.007

True

1 M Opaque::14.009, 

14.010

True

1 M Opaque::14.016, 

14.017

True

1 M Opaque::14.020 True

1 M Opaque::17.001, 

17.002

True

1 M Opaque::17.004 True

1 M Opaque::17.006, 

17.007

True

1 M Opaque::17.009, 

17.010

True

1 M Opaque::17.014, 

17.015

True

1 M Opaque::17.018, 

17.019

True

1 M Opaque::17.021 to 

17.024

True

1 M Opaque::17.026 True

AlphaNumeric 9.1 

(Table 8), 

15.1 

(Table 17), 

18.1 

(Table 31),

19.1 

(Table 33),

22.1 

(Table 37)

The field shall only contain alphanumeric 

characters (ASCII 0x20 through 0x7E).

1 M AlphaNumeric::1.00

4

Bytes(1.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::1.00

7 to 1.010

Bytes(1.007 to 1.010) MO [0x20 to 

0x7E]

1 M AlphaNumeric::1.01

4

Bytes(1.014) MO [0x20 to 0x7E]

1 M AlphaNumeric::10.0

03, 10.004

Bytes(10.003, 10.004) MO [0x20 to 

0x7E]

1 M AlphaNumeric::10.0

10 to 10.012

Bytes(10.010 to 10.012) MO [0x20 to 

0x7E]

1 M AlphaNumeric::10.0

20

Bytes(10.020) MO [0x20 to 0x7E]

1 M AlphaNumeric::10.0

27

Bytes(10.027) MO [0x20 to 0x7E]
35

1 M AlphaNumeric::10.0

30

Bytes(10.030) MO [0x20 to 0x7E]

1 M AlphaNumeric::13.0

04

Bytes(13.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::13.0

11

Bytes(13.011) MO [0x20 to 0x7E]

1 M AlphaNumeric::13.0

20

Bytes(13.020) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

04

Bytes(14.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

11

Bytes(14.011) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

20

Bytes(14.020) MO [0x20 to 0x7E]

1 M AlphaNumeric::14.0

30

Bytes(14.030) MO [0x20 to 0x7E]

1 M AlphaNumeric::17.0

04

Bytes(17.004) MO [0x20 to 0x7E]

1 M AlphaNumeric::17.0

11

Bytes(17.011) MO [0x20 to 0x7E]

1 M AlphaNumeric::17.0

13 to 17.015

Bytes(17.013 to 17.015) MO [0x20 to 

0x7E]

1 M AlphaNumeric::17.0

17, 17.018

Bytes(17.017, 17.018) MO [0x20 to 

0x7E]

YYYYMMDD_Valid 9.1.5, 

15.1.5, 

18.1.5, 

19.1.5, 

22.2.5

The date shall appear as eight digits in 

the format YYYYMMDD.

1 M YYYYMMDD_Valid::

1.005

{1.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

10.005

{10.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

13.005

{13.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

14.005

{14.005} MO Valid(YYYYMMDD)

1 M YYYYMMDD_Valid::

17.005

{17.005} MO Valid(YYYYMMDD)

YYYYMMDD_NotFu

ture

9.1.5 The transaction date shall not be future. 1 M YYYYMMDD_NotFu

ture::1.005

{1.005} LTE Date.Today

Values_1To9 9.1.6 The value shall be in the range 1 to 9. 1 O Values_1To9::1.006 {1.006} MO [1 to 9]

1.011-NSR_-

ZeroIfNoBinaryRecs

9.1.11 For transactions that do not contain

Type-3 through Type-7 fingerprint image 

records, field 1.011 (NSR) shall be set to 

“00.00”.

2 M 1.011-NSR_-

ZeroIfNoBinaryRecs

If NOT Present(Type 3 to Type 7) Then

{1.011} EQ “00.00”

AlphaNumeric_Subf

ields

9.1 

(Table 8), 

9.1.13,

9.1.15, 

15.1.20, 

15.1.21, 

15.1.26, 

15.1.30, 

The field shall only contain alphanumeric 

characters (ASCII 0x20 through 0x7E), 

ASCII US (0x1F) and ASCII RS (0x1E).

1 M AlphaNumeric_US_

RS::1.013

Bytes(1.013) MO [0x20 to 0x7E, ASCII 

US, ASCII RS]

1 M AlphaNumeric_US_

RS::1.015

Bytes(1.015) MO [0x20 to 0x7E, ASCII 

US, ASCII RS]

1 M AlphaNumeric_US_

RS::10.022, 10.023

Bytes(10.022,10.023) MO [0x20 to 

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::10.028, 10.029

Bytes(10.028,10.029) MO [0x20 to 

0x7E, ASCII US, ASCII RS]
36

15.1.32, 

15.1.33, 

18.1.14, 

18.1.15, 

19.1.14, 

19.1.15, 

19.1.18, 

22.2.19

1 M AlphaNumeric_US_

RS::10.040

Bytes(10.040) MO [0x20 to 0x7E, ASCII 

US, ASCII RS]

1 M AlphaNumeric_US_

RS::10.042, 10.043

Bytes(10.042,10.043) MO [0x20 to 

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::13.014, 13.015

Bytes(13.014,13015) MO [0x20 to 

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::14.014,14.015

Bytes(14.014,14.015) MO [0x20 to 

0x7E, ASCII US, ASCII RS]

1 M AlphaNumeric_US_

RS::14.018

Bytes(14.018) MO [0x20 to 0x7E, ASCII 

US, ASCII RS]

1 M AlphaNumeric_US_

RS::17.019

Bytes(17.019) MO [0x20 to 0x7E, ASCII 

US, ASCII RS]

Numbers2Dot2 9.1.11, 

9.1.12

The field shall consist of two numbers 

followed by a period followed by two 

numbers.

1 M Numbers2Dot2::1.0

11, 1.012

{1.011, 1.012} MO '##.##'

1.012-NTR_-

ZeroIfNoBinaryRecs

9.1.12 For transactions that do not contain

Type-3 through Type-7 fingerprint image 

records, field 1.012 (NTR) shall be set to 

“00.00”.

2 M 1.012-NTR_-

ZeroIfNoBinaryRecs

If NOT Present(Type 3 to Type 7) Then

{1.012} EQ “00.00”

GMT 9.1.14 The GMT is represented as 

YYYYMMDDHHMMSSZ, a 15-character

string that is the concatenation of the 

date with the GMT and concludes with a 

Z.

1 O GMT_Valid::1.014 {1.014} Valid(YYYYMMDDHHMMSSZ)

GMT_NotFuture 9.1.14 The GMT shall not exceed the current 

date.

1 O GMT_NotFuture::1.

014

{1.014} LTE {Date Today}

1.014-

GMT_NotFuture

9.1.14 The complete GMT date shall not exceed 

the current date.

2 M 1.014-

GMT_NotFuture

{1.014} LTE {Current DateTime}

SubFields 9.1.13, 

9.1.15, 

15.1.27, 

15.1.32, 

19.1.25

The field shall contain subfields. 1 O SubFields 

Expected::1.013

Present( Subfield in 1.013)

1 O SubFields 

Expected::1.015

Present(Subfield in 1.015 )

1 O SubFields 

Expected::10.029

Present(Subfield in 10.029 )

1 O SubFields 

Expected::10.042

Present(Subfield in 10.042 )

1 O SubFields 

Expected::14.025

Present(Subfield in 14.025 )

NotSupported 9.1.15 The field is not supported. 1 O NotSupported::1.01

5

True

1.015-DCS 9.1.15 Not supported in this version 1

(Not Needed) 9.2 Immediately following the last 

information field in the Type-1 logical 

record, an ASCII FS separator character 

shall be used to separate it from the 

next logical record. This ASCII FS

character shall replace the “GS” 

character that is normally used between

information fields.

2 M See Above

1-FsAtEnd

Last(Byte in Record) EQ ASCII FS

Type 4 Requirements and Assertions
37

4::MandatoryFields 11.1 In a Type 4 record, entries shall be 

provided in nine ordered and 

unnumbered fields. The data recorded is 

in binary form – no ASCII data. The first 

eight fields are fixed length and total

eighteen bytes. These fields precede the 

image data contained in field nine. 

Table 10 lists the contents of each of the 

nine fields.

2 M 4::MandatoryFields In a Type 4 record, entries shall be 

provided in nine ordered and 

unnumbered fields. The data recorded 

is in binary form – no ASCII data. The 

first eight fields are fixed length and 

total eighteen bytes. These fields 

precede the image data contained in 

field nine. Table 10 lists the contents 

of each of the nine fields.

4::LenData=LEN-18 11.1 In a Type-4 record the size of the ninth

field is eighteen bytes less than the 

value specified in the LEN field.

2 M 4::LenData=LEN-18 Length(4.009) EQ Length(Record) - 18

Length_Maximum_

Binary _Field

11.2 

(Table 10)

The field length shall be as specified. 1 M LengthMax::4.001

to 4.009

Length(4.001 to 4.009) LTE 

{Length.Max}

Length_Minimum_

Binary_Field

11.2 

(Table 10)

The field length shall be as specified. 1 M LengthMin::4.001 Length(4.001 to 4.009) GTE 

{Length.Min}

4.001::RecBytes 11.2.1 The mandatory four-byte binary LEN 

field shall occupy bytes one through four 

of each record type. It shall contain the 

length of the logical record specifying 

the total number of bytes, including 

every byte of all nine fields contained in 

the record.

2 M 4.001::RecBytes Length(Record) EQ {4.001}

4.002-

CNT_IDCsMatchRec

s

11.2.2 The mandatory one-byte binary IDC field 

shall be a binary representation of the 

IDC found in the file content (CNT) field 

of the Type-1 record.

2 M 4.003-

CNT_IDCsMatchRec

s

See Above

1.003-CNT_IDCsMatchRecs

Table_11_Finger 11.2.3 The field value shall be selected from 

Table 11.

1 M Table_11_Finger::4.

003

{4.003} MO Table 11

Table_12_0To14 11.2.4 The field value shall be selected from 

Table 12.

1 M Table_12_0-

14_Binary::4.004

{4.004} MO [0 to 14]

Values_0To1 11.2.5 The value shall be 0 or 1. 1 M 0-1_Binary::4.005 {4.005} MO [0, 1]

4.006-HLL 11.2.6 Field 4.006 shall be used to specify the 

number of pixels contained on a single 

horizontal line of the transmitted image. 

2 M 4.006-JPEGB-JPEGLHLL{4.006} EQ {Image Width} 3

2 M 4.006-WSQ-HLL {4.006} EQ {Image Width} 3

4.007-VLL 11.2.7 Field 4.007 shall be used to specify the 

number of horizontal lines contained in 

the transmitted image. 

2 M 4.007-JPEGB-JPEGLVLL{4.007} EQ {Image Height} 3

2 M 4.007-WSQ-VLL {4.007} EQ {Image Height} 3

Table_1_No_4-6 11.2.8 The field value shall be selected from 

Table 1. Values 4 through 6 are not 

valid. 

1 M Table_1_No_4-

6::4.008

{4.008} NOT MO [4-6] AND {4.008} MO 

Table 1

4.008-

ConfirmedCGA

11.2.8 Field 4.008 shall be used to specify the 

type of compression used (if any). For 

the Type-4 logical record, the WSQ or 

the JPEG standard algorithms are 

recommended. 

2 M 4.011-JPEGB-JPEGL {4.008} corresponds to {SOF marker} 3

2 M 4.011-WSQ Present(SOF, Image Height, Image 

Width) 

3

4.009-ValidImage 11.2.9 Field 4.009 shall contain the image data. 2 M 4.009-ValidUncompLength(4.009) EQ {4.006} * {4.007} 
38

2 M 4.009-Valid-JPEGBJPEGLPresent(SOI, SOF, EOI) 3

2 M 4.009-Valid-WSQ Present(SOI, SOF, SOB, EOI) 3

Type 10 Requirements and Assertions

10::FixedPositionFi

elds

15.1 It is required that the first two fields of 

the Type-10 record are ordered, and the 

field containing the image data shall be 

the last physical field in the record.

2 M 10:001::LEN_First First(Field in Record) ST Type(Record) 

EQ 10 AND Field EQ 10.001 

2 M 10:002::IDC_Second Second(Field in Record) ST 

Type(Record) EQ 10 AND Field EQ 

10.002 

2 M 10:999::DATA_Last Last(Field in Record) ST Type(Record) 

EQ 10 AND Field EQ 10.999 in a Type10 record.

10::MandatoryField

s

15.1, 

(Table 17)

For each field of the Type-10 record, 

Table 17 lists the "condition code" as 

being mandatory "M" or optional 

"O"...and occurrence limits.

2 M 10::CondCode_M IF "Cond code" EQ "M" in Table 17, 

Present(Field in Record)

2 M 10.xxxMaxOccurancesCount(10.xxx) LTE 

MaxOccurrences(10.xxx)

2 M 10.xxxMinOccurancesCount(10.xxx) GTE 

MinOccurrences(10.xxx)

10::IMG=FAC_Fields 15.1 Fields with “FAC” in the “IMG” column 

of Table 17 apply to mugshot or facial 

image Type-10 records.

2 M 10::IMG=FAC_

FaceOK

Fields with “FAC” in the “IMG” column 

of Table 17 apply to mugshot or facial 

image Type-10 records.

2 M 10::IMG=FAC_

SmtBad

Fields with “SMT” in the “IMG” column 

of Table 17 do not apply to mugshot or 

facial image Type-10 records.

10::IMG=SMT_Field

s

15.1 Fields with “SMT” in the “IMG” column 

of Table 17 apply to scar, mark or tattoo 

image Type-10 records

2 M 10::IMG=SMT_-

SmtOk

Fields with “SMT” in the “IMG” column 

of Table 17 apply to scar, mark or 

tattoo image Type-10 records.

2 M 10::IMG=SMT_-

FaceBad

Fields with “FAC” in the “IMG” column 

of Table 17 do not apply to scar, mark 

or tattoo image Type-10 records.

10::Len=Bytes 15.1.1 Field 10.001: Logical record length (LEN)

This mandatory ASCII field shall contain 

the total count of the number of bytes in 

the Type-10 logical record. Field 10.001 

shall specify the length of the record 

including every character of every field 

contained in the record and the 

information separators.

2 M 10.001::Len=Bytes

{10.001} EQ Length(Record)

10::IDC=CNT_IDC 15.1.2 Field 10.002: Image designation 

character (IDC)

This mandatory ASCII field shall be used 

to identify the facial or SMT image data 

contained in the record. This IDC shall 

match the IDC found in the file content 

(CNT) field of the Type-1 record.

2 M 10.002::IDC=CNT_-

IDC {10.002} EQ {1.003}
39

FaceScarMarkTatto

o

15.1.3 The value shall be FACE, SCAR, MARK or 

TATTOO.

1 M FaceScarMarkTatto

o::10.003

{10.003} MO ['FACE', 'SCAR', 'MARK', 

'TATTOO']

10.006-HLL 15.1.6 Field 10.006 shall contain the number of 

pixels contained on a single horizontal 

line of the transmitted image. 

2 M 10.006-JPEGBJPEGL-HLL{10.006} EQ {Image Width}

2 M 10.006-JP2-JP2LHLL{10.006} EQ {Image Width} 

2 M 10.006-PNG-HLL {10.006} EQ {Image Width}

NotifyOnZero 15.1.6, 

15.1.7, 

18.1.6, 

18.1.7, 

19.1.6, 

19.1.7, 

22.2.6, 

22.2.7

If the field value is zero note this fact in 

the output. 

1 M NotifyOnZero::10.0

06, 10.007

{10.006,10.007} NEQ 0

1 M NotifyOnZero::13.0

06, 13.007

{13.006, 13.007} NEQ 0

1 M NotifyOnZero::14.0

06, 14.007

{14.006, 14.007} NEQ 0

1 M NotifyOnZero::17.0

06, 17.007

{17.006,17.007} NEQ 0

10.007-VLL 15.1.7 Field 10.007 shall contain the number of 

horizontal lines contained in the 

transmitted image. 

2 M 10.007-JPEGBJPEGL-VLL{10.007} EQ {Image Height}

2 M 10.007-JP2-JP2LVLL{10.007} EQ {Image Height} 

2 M 10.007-PNG-VLL {10.007} EQ {Image Height}

Values_0To2 15.1.8, 

19.1.8, 

22.2.3, 

22.2.8

The value shall be 0, 1 or 2. 1 M Values_0To2::10.00

8

{10.008} MO [0-2]

1 M Values_0To2::14.00

8

{14.008} MO [0-2]

1 M Values_0To2::17.00

3

{17.003} MO [0-2]

1 M Values_0To2::17.00

8

{17.008} MO [0-2]

10.008-SLC 15.1.8 Field 10.008 shall specify the units used 

to describe the image sampling 

frequency (pixel density). 

2 M 10.008-JPEGBJPEGL-SLCIF Present(JFIF Header) THEN

{10.008} EQ {Sampling Units}

3

2 M 10.008-JP2-JP2LSLCNot Implemented 4

2 M 10.008-PNG-SLC IF Present(PHYS chunk) THEN

IF {10.008} EQ “1” OR “2” THEN 

{Sampling Units} EQ 1, ELSE IF {10.008} 

EQ 0 THEN{Sampling Units} EQ 0

3

10.009-HPS 15.1.9 Field 10.010 shall specify the integer 

pixel density used in the horizontal

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the horizontal component of 

the pixel aspect ratio.

2 M 10.009-JPEGBJPEGLIF {10.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{10.009} EQ {Horizontal Density}

3

2 M 10.009-JP2-JP2LHPSNo Implementation 4

2 M 10.009-PNG-HPS IF Present(PHYS Chunk) THEN

IF {10.008} EQ “1”, THEN

{10.009} EQ {Horizontal Density} * 

0.0254 (meters/inch)

ELSE IF {10.008} EQ “2”, THEN

{10.009} EQ {Horizontal Density} * 0.01 

(meters/cm)

3

2 M 10.009-JPEGB- IF {13.008} NEQ “1” OR “2”, THEN 3
40

JPEGL-HorzAspect {13.009} EQ {Horizontal Density} / 

{Vertical Density}

2 M 10.009-JP2-JP2LHorzAspectNo Implementation 4

2 M 10.009-PNGHorzAspectIF Present(PHYS Chunk), THEN

IF {10.008} NEQ “1” OR “2”, THEN 

{10.009} EQ {Horizontal Density} / 

{Vertical Density}

3

10.010-VPS 15.1.10 Field 10.010 shall specify the integer 

pixel density used in the vertical 

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the vertical component of the 

pixel aspect ratio.

2 M 10.010-JPEGBJPEGL-VPSIF {10.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{10.010} EQ {Vertical Density}

3

2 M 10.010-JP2-JP2LVPSNo Implementation 4

2 M 10.010-PNG-VPS IF Present(PHYS Chunk) THEN

IF {10.008} EQ “1”, THEN

{10.010} EQ {Vertical Density} * 0.0254 

(meters/inch)

ELSE IF {10.008} EQ “2”, THEN

{10.010} EQ {Vertical Density} * 0.01 

(meters/cm) 

3

2 M 10.010-JPEGBJPEGL-VerAspectIF {10.008} NEQ “1” OR “2”, THEN 

{10.010} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 10.010-JP2-JP2LVerAspectNo Implementation 4

2 M 10.010-PNGVerAspectIF Present(PHYS Chunk), THEN

IF {10.008} NEQ “1” OR “2”, THEN 

{10.010} EQ {Horizontal Density} / 

{Vertical Density}

3

Table_1_No_WSQ 15.1.11 The field value shall be selected from 

Table 1. WSQ is not valid. 

1 M Table_1_No_WSQ::

10.011

{10.011} NOT WSQ AND {10.011} MO 

Table 1

10.011-

ConfirmedCGA

15.1.11 Field 10.011 shall contain an entry from 

Table 1 (other than WSQ) to specify the 

algorithm used to compress the 

transmitted grayscale images.

2 M 10.011-JPEGBJPEGL-CGA{10.011} corresponds to {SOF marker} 3

2 M 10.011-JP2-JP2LCGA{5th parameter of ImgBox} EQ “7” 3

2 M 10.011-PNG-CGA Present(IHDR) 3

Table_3 15.1.12, 

22.2.13

The field value shall be selected from 

Table 3.

1 M Table_3::10.012 {10.012} MO Table 3

1 M Table_3::17.013 {17.013} MO Table 3

10.012-CSP 15.1.12 Field 15.012 shall contain an entry from 

Table 3 to identify the color space used. 

If the color space for an RGB image 

cannot be determined, an entry of 

“RGB” shall be entered.

2 M 10.012-JPEGBJPEGL-CSPNo Implementation 4

2 M 10.012-JP2-JP2LCSPIF Present(Colour Specification box), 

THEN {10.012} corresponds to {CSP}

3

2 M 10.012-PNG-CSP {10.012} corresponds to {CSP} 3

Table_18 15.1.13 The field value shall be selected from 

Table 18.

1 M Table_18::10.013 {10.013} MO [0, 1, 10, 11, 12, 13, 14, 

15, 20, 30, 40, 50, 51]

5

10.003::IMT=FACE_

SAP_Mandatory

15.1.13 Field 10:013, the Subject Acquisition 

Profile (SAP), is mandatory when field 

10.003 contains "FACE”.

2 M 10.003::IMT=FACE_

SAP_Mandatory

Field 10:013, the Subject Acquisition 

Profile (SAP), is mandatory when field 

10.003 contains "FACE”.
41

RESERVED_FIELDS 15.1.14 Fields 10.014 and 10.015 are reserved 

for definition and inclusion in future 

revisions of this standard. None of these 

fields are to be used at this revision 

level. If any of these fields are present, 

they are to be ignored.

- - 10.014::Reserved Present(10.014)

- - 10.015::Reserved Present(10.015)

RESERVED_FIELDS 15.1.17 Fields 10.018 and 10.019 are reserved 

for definition and inclusion in future 

revisions of this standard. None of these 

fields are to be used at this revision 

level. If any of these fields are present, 

they are to be ignored.

- - 10.018::Reserved Present(10.018)

- - 10.019::Reserved Present(10.019)

SubjectPose_Table_

19

15.1.18 The value shall be selected from Table 

19.

1 O SubjectPose::10.02

0

{10.020} MO ['F', 'R', 'L', 'A', 'D']

-180_To_180 15.1.19 The offset angle shall be measured from 

the full-face pose position and have a 

range of values from -180 degrees to 

+180 degrees.

1 O -

180_To_180::10.02

1

{10.021} LTE 180 AND {10.021} GTE -

180

5

10.021::POS=A_-

POA_Mandatory

15.1.19 Field 10.021, Pose offset angle (POA), 

shall only be used for the exchange of 

facial image data if Field 10.020 (POS) 

contains an "A" to indicate an angled 

pose of the subject. This field should be 

omitted for a full face or a profile. If the 

entry in the POS field is an "F", "L", or 

"R", the contents of this field are 

ignored. 

2 O 10.021::POS=A_-

POA_Mandatory

IF{10.020} EQ “A” THEN

Present(10.021) 

Photo_Description 15.1.20 This optional ASCII field, retained for 

legacy systems, is used for the exchange 

of facial image data. When present, it 

shall consist of one or more subfields 

and shall describe special attributes of 

the captured facial image. Attributes 

associated with the facial image may be 

selected from Table 20 and entered in 

this field as one or more subfields 

separated by the ASCII RS separator 

character between the items. Physical 

characteristics, such as FRECKLES may be 

entered as a subfield consisting of two 

information items. The first is PHYSICAL 

followed by the ASCII US separator, 

followed by the characteristic as listed in 

the Ninth (or current) Edition of the 

NCIC Code Manual, December, 2000. 

The OTHER category is used to enter 

unlisted or miscellaneous attributes of 

the facial image. This information shall 

be entered as a two-information item 

subfield. The first is OTHER followed by 

the ASCII US separator, followed by the 

1 O Photo_Descriptors::

10.022

{10.022} MO Table 20
42

unformatted text used to describe the 

attribute. Multiple attributes and 

subfields may be listed but must be 

separated by the ASCII RS character. 

Table_21 15.1.21 The field value shall be selected from 

Table 21.

1 O 10.023_Table_21::1

0.023

{10.023} MO Table 21

Subfields_1x[1,2] 15.1.21 The field shall be single or have two 

subfields. The subfields shall be 

separated by ASCII US. 

1 O 1x1_Or_1x2::10.02

3

Count(US_Subfields in 10.023 ) EQ 0

OR 

Count(US_Subfields in 10.023 ) EQ 2

2

10.023::SAP>=40_-

PAS_Mandatory

15.1.21 Field 10.023, Photo acquisition source 

(PAS), is mandatory if the SAP entry 

(Field 10.013) is "40" or greater.

2 O 10.023::SAP>=40_-

PAS_Mandatory

IF {10.013} GTE 40 THEN

Present(10.023) 

SubFields_Nx3 15.1.22, 

22.2.24

Each subfield shall contain three 

information items separated by the 

ASCII US separator character. The field 

shall contain one or more rows of 

subfields.

1 O SubFields_Nx3::10.

024

ForEach(Subfield in 10.024 ){ 

Count(items) EQ 3}

1 O SubFields_Nx3::17.

024

ForEach(Subfield in 17.024 ){ 

Count(items) EQ 3}

Subject_Quality_Sc

ore

15.1.22 This optional ASCII field shall specify 

quality score data for facial images 

stored in this record. Each subfield shall 

contain three information items 

separated by the ASCII US separator 

character. They identify a quality score 

and the algorithm used to create the 

quality score. This information is useful 

to enable the recipient of the quality 

score to differentiate between quality 

scores generated by different algorithms 

and adjust for any differences in 

processing or analysis as necessary. 

1. The first information item shall be a 

quantitative expression of the predicted 

matching performance of the biometric 

sample. This item contains the ASCII 

representation of the integer image 

quality score between 0 and 100 

assigned to the image data by a quality 

algorithm. Higher values indicate 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. The use of additional values 

to convey other information should be 

harmonized with ISO/IEC 19794 

standards.

2. The second information item shall 

specify the ID of the vendor of the 

quality algorithm used to calculate the 

1 O Subject_Quality_Sc

ore::10.024

ForEach(RS_Subfield in 14.024)

{

Count(US_Subfield) EQ 3

AND

{US_Subfield:1} GTE 0 AND

{US_Subfield:1} LTE 100 OR

{US_Subfield:1} MO [254,255]

AND

{US_Subfield:2} MO [IBIA Vendor 

Registry]

AND

{US_Subfield:3} GTE 1 AND

{US_Subfield:3} LTE 65535 OR

}

2
43

quality score. This 4-digit hex value is 

assigned by IBIA and expressed as four 

ASCII characters. The IBIA shall maintain 

the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

this field to a registered organization.

3. The 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 it is not required to be registered. It 

indicates which of the vendor’s 

algorithms was used in the calculation of 

the quality score. This field contains the 

ASCII representation of the integer 

product code and should be within the 

range 1 to 65,535. 

IBIA_Quality_-

Vendor

15.1.22 Field 10.024: Subject quality score (SQS)

This optional ASCII field shall specify 

quality score data for facial images 

stored in this record. ...

2. The second information item shall 

specify the ID of the vendor of the 

quality algorithm used to calculate the 

quality score. This 4-digit hex value is 

assigned by IBIA and expressed as four 

ASCII characters. The IBIA shall maintain 

the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

this field to a registered organization.

....

2 O 10.024::IBIA_-

Quality_Vendor

The code exists in the IBIA Vendor 

Registry of CBEFF Biometric 

Organizations.

10.025::POS=D_-

SPA_Mandatory

15.1.23 Field 10.025, Subject pose angles (SPA), 

is mandatory when Field 10.020 (POS) 

contains a "D".

2 O 10.025::POS=D_-

SPA_Mandatory

IF{10.020} EQ “D” THEN

Present(10.025) 

Single_Or_SubField

s

15.1.20, 

15.1.24, 

15.1.30, 

15.1.33

The field can have one or more 

subfields.

1 O SingleOrSubFields::

10.022

True

1 O SingleOrSubFields::

10.026

True

1 O SingleOrSubFields::

10.040

True

1 O SingleOrSubFields::

10.043

True

AlphaNumeric_RS 15.1.24 The field shall only contain alphanumeric 

characters (ASCII 0x20 through 0x7E) 

and ASCII RS (0x1E).

1 O AlphaNumeric_RS::

10.026

Bytes(10.026) MO [0x20-0x7E, ASCII 

RS]
44

10.026::SAP_>=_40

_Mandatory

15.1.24 Field 10.026, Subject facial description 

(SXS), is mandatory if the SAP entry 

(Field 10.013) is "40" or greater.

2 O 10.026::SAP_>=_40

_Mandatory

IF {10.013} GTE “40” THEN

Present(10.026) 

EyeColor 15.1.25 The field value shall be selected from 

Table 23.

1 O EyeColor::10.027 {10.027} MO Table 30

1 O EyeColor::17.020 {17.020} MO Table 30

10.027::SAP_>=_40

_Mandatory

15.1.25 Field 10.027, Subject eye color (SEC), is 

mandatory if the SAP entry (Field 

10.013) is "40" or greater.

2 O 10.027::SAP_>=_40

_Mandatory

IF{10.013} GTE “40” THEN

Present(10.027) 

Subfields_[1,2]x1 15.1.26 The field shall be single or have two 

subfields. The subfields shall be 

separated by ASCII RS.

1 O 1x1_Or_2x1::10.02

8

Count(Subfields in 10.028 ) EQ 0 OR 

Count(Subfields in 10.028 ) EQ 2

Subject_Hair_Color 15.1.26 This optional ASCII field shall be used for 

the exchange of facial image data. This 

field is mandatory if the SAP entry (Field 

10.013) is 40 or greater. When present, 

it shall contain an entry form Table 24 

that describes the hair color of the 

subject as seen in the photograph. For 

unusual or unnatural colors not listed in 

the table, or the real color cannot be 

ascertained, the hair color should be 

labeled as XXX. If the subject is 

completely bald, or has a completely 

shaved head, then the hair color shall be 

labeled as BAL. When the subject is 

predominantly bald, but hair color is 

discernable, then the appropriate hair 

color attribute code shall follow BAL 

(separated by the ASCII RS character). 

1 O Subject_Hair_Color:

:10.028

{10.028} MO Table 24

10.028::SAP_>=_40

_Mandatory

15.1.26 Field 10.028, Subject hair color (SHC), is 

mandatory if the SAP entry (Field 

10.013) is "40" or greater.

2 O 10.028::SAP_>=_40

_Mandatory

IF {10.013} GTE “40” THEN

Present(10.028) 

10.028::Bald_2nd_C

olor

15.1.26 Field 10.028: Subject hair color (SHC)

If the subject is completely bald, or has a 

completely shaved head, then the hair 

color shall be labeled as “BAL”. When 

the subject is predominantly bald, but 

hair color is discernable, then the

appropriate hair color attribute code 

shall follow “BAL” (separated by the 

ASCII RS).

2 O 10.028::Bald_2nd_-

Color

IF (1,1) = “BAL”

 (2,1) = {NULL Or {All Color Attributes 

Except “BAL”}}

FeaturePoint 15.1.27 The optional ASCII field shall be used for 

the exchange of facial image data. When 

present, it shall describe special 

attributes of manually or automatically 

detected facial feature points of the 

captured facial image. This information 

shall be entered as a four-information 

item feature point block as described in 

Table 25. The first information item is 

1 O Subject_Feature_Po

ints::10.029 ForEach(RS_Subfield in 10.029)

{

US_Subfield:1 EQ 1 

AND

US_Subfield:2 EQ A.B ST A.B MO Figure 

5 AND A.B NOT MO [Prior A.B]

2
45

feature point type. For this version of 

the standard the only allowable value is1 

which is followed by the ASCII US 

separator character. The second is 

feature point code, followed by the 

ASCII US separator character. The third 

is the X coordinate of a feature point, 

followed by the ASCII US separator 

character. The fourth and final item is 

the Y coordinate of a feature point in the 

facial image. Multiple facial points may 

be listed using these four information 

items. But each feature block must be 

separated by the ASCII RS separator 

character. The maximum number of 

feature points shall be 88, with the use 

of 84 MPEG4 feature points and 4 

additional eye and nostril center feature 

points. 

AND

{US_Subfield:3} > 0 AND 

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

AND

{US_Subfield:4} > 0 AND 

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

}

10.029::No_-

Duplicate_-

Feature_Points

15.1.27 Field 10.029: Facial feature points (FFP)

The optional ASCII field shall be used for 

the exchange of facial image data. ... 

The maximum number of feature points 

shall be 88, with the use of 84 MPEG4 

feature points and 4 additional eye and 

nostril center feature points.

2 O 10.029::No_-

Duplicate_-

Feature_Points

All Facial Feature Points (FPP) (X,Y) are 

unique.

Table_27 15.1.28, 

19.1.27, 

22.2.28, 

Table 27

The field value shall be selected from 

Table 27.

1 O Table_27::10.030 {10.030} MO Table 27

1 O Table_27::14.030 {14.030} MO Table 27

1 O Table_27::17.030 {17.030} MO Table 27

RESERVED_FIELDS 15.1.29 Field 10.031-039: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 10.031-039::-

Reserved

Present(10.031 to 10.039)

NCIC_Designation_

Code

15.1.30 This field is mandatory for a Type-10 

record containing SMT image data. It is 

used to identify a general location of the 

captured scar, mark, tattoo, or other 

characteristic (including piercings) in an 

image. The contents of this field will be 

an entry chosen from the December, 

2000 ninth (or current) edition of the 

NCIC Code Manual. The captured image 

can encompass an area larger than that 

1 O NCIC_Designation_

Code::10.040

{10.040} MO [NCIC Designation Codes] 5
46

specified by a single NCIC body part 

code for the particular image type. This 

situation can be accommodated by 

listing multiple NCIC codes separated by 

the ASCII RS separator character. In this 

case the primary code is listed first. For 

the marks category, the NCIC manual 

lists the common locations for needle 

track marks. For other body part 

locations not listed under the marks 

category, use the body location codes 

listed for scars.

10.040::SMT_-

Image_Data_-

SMT_Field_-

Mandatory

15.1.30 Field 10.040, NCIC designation code 

(SMT), is mandatory for a Type-10 

record containing SMT image data.

2 O 10.040::SMT_-

Image_Data_-

SMT_Field_-

Mandatory

Field 10.040, NCIC designation code 

(SMT), is mandatory for a Type-10 

record containing SMT image data.

Subfields_1x2 15.1.31, 

19.1.14

The field shall have two subfields 

separated by ASCII US.

1 O 1x2::10.041 Count(Subfields in 10.041 ) EQ 2

1 O 1x2::14.014 Count(Subfields in 14.014 ) EQ 2

SMT_Descriptors 15.1.32 This optional field is used to describe the 

content of the SMT image. It shall 

consist of one or more subfields. Each 

subfield shall contain three or four 

information items that provide 

progressively detailed information 

describing the total image or a portion 

of the image. The first information item 

of each subfield shall identify the source 

of the image as being a scar, a mark, or a 

tattoo. It shall contain SCAR to indicate 

healed scar tissue that was the result an 

accident or medical procedure. An entry

of MARK shall be used for the pattern 

resulting from needle or track marks. For 

either case the second and third 

information items shall contain OTHER 

and MISC and the fourth information 

item shall contain a textual description 

or other information concerning the scar 

or mark pattern. For deliberately applied 

or drawn images, the first information 

item will contain TATTOO to indicate a 

common tattoo or indelible image 

resulting from the pricking of the skin 

with a coloring matter; CHEMICAL if the 

image was created by the use of 

chemicals to burn the image into the 

skin; BRANDED if the image was burned 

into the skin using a branding iron or 

other form of heat; or CUT if the image 

was caused by incision of the skin. 

1 O SMT_Descriptors::1

0.042 ForEach(RS_Subfield in 10.042)

{

US_Subfield:1 MO [‘SCAR’, ‘MARK’, 

‘TATTOO’, ‘CHEMICAL’, ‘BRANDED’, 

‘CUT’]

AND

IF US_Subfield:1 MO [‘SCAR’,’MARK’] 

THEN

{

US_Subfield:2 EQ ‘OTHER’ AND 

US_Subfield:3 EQ ‘MISC’

}

ELSE

{

US_Subfield:2 MO Table 28 AND 

US_Subfield:3 MO Table 29 a to h

}

}

2

15.1.32 Field 10.042: SMT descriptors (SMD) 2 O 10.042::SCAR_- IF (N,1) = “SCAR”
47

10.042::SCAR_-

MARK_OTHER_-

MISC_Text

This optional field is used to describe the 

content of the SMT image. It shall 

consist of one or more subfields. Each 

subfield shall contain three or four 

information items that provide 

progressively detailed information 

describing the total image or a portion 

of the image.

The first information item of each 

subfield shall identify the source of the 

image as being a scar, a mark, or a 

tattoo. It shall contain “SCAR” to 

indicate healed scar tissue that was the 

result an accident or medical procedure. 

An entry of “MARK” shall be used for the 

pattern resulting from needle or track 

marks. For either case the second and 

third information items shall contain 

“OTHER” and “MISC” and the fourth 

information item shall contain a textual 

description or other information 

concerning the scar or mark pattern.

For deliberately applied or drawn 

images, the first information item will 

contain "TATTOO" ...

MARK_OTHER_-

MISC_Text

 (N,2) = “OTHER”

 (N,3) = “MISC”

 (N,4) = Text

10.042::SCAR_-

MARK_(1x4)

15.1.32 The first information item of each 

subfield shall identify the source of the 

image as being a scar, a mark, or a 

tattoo. It shall contain “SCAR” to 

indicate healed scar tissue that was the 

result an accident or medical procedure. 

An entry of “MARK” shall be used for the 

pattern resulting from needle or track 

marks. For either case the second and 

third information items shall contain 

“OTHER” and “MISC” and the fourth 

information item shall contain a 

textual description or other information 

concerning the scar or mark pattern.

2 O 10.042::SCAR_-

MARK_(1x4)

IF(N,1) = “SCAR”

 Row N is (N,4)

10.042::TATTOO 15.1.32 Field 10.042: SMT descriptors (SMD)

This optional field is used to describe the 

content of the SMT image...

The first information item of each 

subfield shall identify the source of the 

image as being a scar, a mark, or a 

2 O 10.042::TATTOO IF(N,1) In {“TATTOO”, “CHEMICAL”, 

“BRANDED”, “CUT”}

 (N,2) In {Table 28}

 (N,3) In {Table 29}

 (N,4) In {NULL, Text}
48

tattoo. It shall contain “SCAR” ...

For deliberately applied or drawn 

images, the first information item will 

contain "TATTOO" to indicate a common 

tattoo or indelible image resulting from 

the pricking of the skin with a coloring 

matter; "CHEMICAL" if the image was 

created by the use of chemicals to burn 

the image into the skin; "BRANDED" if 

the image was burned into the skin 

using a branding iron or other form of 

heat; or “CUT” if the image was caused 

by incision of the skin.

The second information item shall be 

the general class code of tattoo chosen 

from Table 28. For each general class of 

tattoo, there are several defined 

subclasses. The third information item of 

the subfield shall be the appropriate 

subclass code selected from Table 29 a-h 

which lists the various subclasses of 

tattoos for each of the general classes.

The final and optional information item 

in this subfield shall be an ASCII text 

string that provides additional qualifiers 

to describe the image or portion of the 

image. For example, to fully describe a 

tattoo, there may be a class description 

of "ANIMAL", with a subclass description 

of "DOG", and qualified by "golden 

retriever with an overbite". The ASCII US 

separator character will be used 

between information items.

10.042::TATTOO_-

(1x3)_Or_(1x4)

15.1.32 Field 10.042: SMT descriptors (SMD)

This optional field is used to describe the 

content of the SMT image...

The first information item of each 

subfield shall identify the source of the 

image as being a scar, a mark, or a 

tattoo. It shall contain “SCAR” ...

For deliberately applied or drawn 

images, the first information item will 

contain "TATTOO" to indicate a ... 

The final and optional information 

2 O 10.042::TATTOO_-

(1x3)_Or_(1x4)

IF (N,1) In {“TATTOO”, “CHEMICAL”, 

“BRANDED”, “CUT”}

 (N,2) Is Not NULL

 (N,3) Is Not NULL

 (N,4) Is NULL Or Not NULL

 (Optional)
49

item in this subfield shall be an ASCII 

text string that provides additional 

qualifiers to describe the image or 

portion of the image. For example, to 

fully describe a tattoo, there may be a 

class description of "ANIMAL", with a 

subclass description of "DOG", and 

qualified by "golden retriever with an 

overbite". The ASCII US separator 

character will be used between 

information items.

Color_Tattoo 15.1.33 This optional field shall contain one 

subfield corresponding to each subfield 

contained in Field 10.042. Each subfield 

shall contain one or more information 

items that list the color(s) of the tattoo 

or part of the tattoo. For each subfield, 

the first information item in the subfield 

shall be the predominant color chosen 

from Table 30. Additional colors for the 

sub-field shall be entered as information 

items in the subfield separated by the 

ASCII US separator character.

1 O Color::10.043 {10.043} MO Table 30

10.043::NumSubfields15.1.33 Field 10.043: Color (COL)

This optional field shall contain one 

subfield corresponding to each subfield 

contained in Field 10.042.

2 O 10.043::NumSubfieldsIF Present(10.043) THEN

Count(Subfields in10.043) EQ 

Count(Subfields in 10.042)

RESERVED_FIELDS 15.1.34 Field 10.044-199: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 10:044-199::-

Reserved

Present(10.044 to 10.199)

Binary_Tagged_Fiel

d

15.1.36, Binary data is opaque. 1 M BinaryData::10.999 True

1 M BinaryData::13.999 True

1 M BinaryData::14.999 True

1 M BinaryData::17.999 True

10.999-ValidImage 15.1.36 Field 10.999 shall contain all of the 

grayscale or color image data from a 

face, scar, mark, tattoo, or other image.

2 M 10.999-ValidUncompLength(10.999) EQ {10.006} * {10.007} 

2 M 10.999-ValidJPEGB-JPEGLPresent(SOI, SOF, EOI)

2 M 10.999-Valid-JP2-

JP2L

Present(SigBox, HeadBox, ImgBox)

2 M 10.999-Valid-PNG Present(PNGSIG, IHDR, IDAT, IEND)
50

10::FsAtEnd 15.2 End of Type-10 logical record

For the sake of consistency, immediately 

following the last byte of data from field 

10.999 an ASCII FS separator shall be 

used to separate it from the next logical 

record. This separator must be included 

in the length field of the Type-10 record.

2 M 10::FsAtEnd Last(Byte in Record) EQ ASCII FS

Type 13 Requirements and Assertions

13::MandatoryField

s

18.1, 

Table 31

For each field of the Type-13 record, 

Table 31 lists the "condition code" as 

being mandatory "M" or optional 

"O"...and occurrence limits.

2 M 13::CondCode_M IF "Cond code" EQ "M" in Table 31, the 

Field must be present in the record. 

2 M 13.xxxMaxOccurrencesCount(13.xxx) LTE 

MaxOccurrences(13.xxx)

2 M 13.xxxMinOccurrencesCount(13.xxx) GTE 

MinOccurrences(13.xxx)

13::FixedPositionFields18.1 It is required that the first two fields of 

the record are ordered, and the field 

containing the image data shall be the

last physical field in the record.

2 M 13.001::LEN_First First(Field in Record) ST Type(Record) 

EQ 13 AND Field EQ 13.001 

2 M 13.002::IDC_Second Second(Field in Record) ST 

Type(Record) EQ 13 AND Field EQ 

13.002

2 M 13.999::DATA_Last Last(Field in Record) ST Type(Record) 

EQ 13 AND Field EQ 13.999

13::Len=Bytes 18.1.1 Field 13.001: Logical record length (LEN)

This mandatory ASCII field shall contain 

the total count of the number of bytes in 

the Type-13 logical record. Field 13.001 

shall specify the length of the record 

including every character of every field 

contained in the record and the 

information separators.

2 M 13:001::Len=Bytes {13.001} EQ Length(Record)

13::IDC=CNT_IDC 18.1.2 Field 13.002: Image designation 

character (IDC)

This mandatory ASCII field shall be used 

to identify the latent image data 

contained in the record. This IDC shall 

match the IDC found in the file content 

(CNT) field of the Type-1 record.

2 M 13.002::IDC=CNT_-

IDC

The IDC matches the value of the 

corresponding CNT field of the Type-1 

record.

Table_11_LatentFn

grPlm

18.1.3 The field value shall be selected from 

Table 11.

1 M Table_11_LatentFin

gerPalm::13.003

{13.003} MO [4-7, 12-15]

13.006-HLL 18.1.6 Field 13.006 shall contain the number of 

pixels contained on a single horizontal 

line of the transmitted image. 

2 M 13.006-JPEGL-HLL {13.006} EQ {Image Width} 3

2 M 13.006-JP2L-HLL {13.006} EQ {Image Width} 3

2 M 13.006-PNG-HLL {13.006} EQ {Image Width} 3

13.007-VLL 18.1.7 Field 13.007 shall contain the number of 

horizontal lines contained in the 

2 M 13.007-JPEGL-VLL {13.007} EQ {Image Height} 3

2 M 13.007-JP2L-VLL {13.007} EQ {Image Height} 3
51

transmitted image. 2 M 13.007-PNG-VLL {13.007} EQ {Image Height} 3

13.008-SLC 18.1.8 Field 13.008 shall specify the units used 

to describe the image sampling 

frequency (pixel density). 

2 M 13.008-JPEGL-SLC IF Present(JFIF Header) THEN

{13.008} EQ {Sampling Units}

2 M 13.008-JP2L-SLC No Implementation 4

2 M 13.008-PNG-SLC IF Present(PHYS Chunk) THEN

IF {13.008} EQ 1 OR 2 THEN 

{Sampling Units} EQ 1, ELSE IF {13.008}

EQ 0 THEN

{Sampling Units} EQ 0

3

13.009-HPS 18.1.9 Field 13.010 shall specify the integer 

pixel density used in the horizontal

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the horizontal component of 

the pixel aspect ratio.

2 M 13.009-JPEGL-HPS IF {13.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{13.009} EQ {Horizontal Density}

3

2 M 13.009-JP2L-HPS No Implementation 4

2 M 13.009-PNG-HPS IF Present(PHYS Chunk) THEN

IF {13.008} EQ “1”, THEN

{13.009} EQ {Horizontal Density} * 

0.0254 (meters/inch)

ELSE IF {13.008} EQ “2”, THEN

{13.009} EQ {Horizontal Density} * 0.01 

(meters/cm)

3

2 M 13.009-JPEGLHorzAspectIF {13.008} NEQ “1” OR “2”, THEN 

{13.009} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 13.009-JP2LHorzAspectNo Implementation 4

2 M 13.009-PNGHorzAspectIF Present(PHYS Chunk), THEN

IF {13.008} NEQ “1” OR “2”, THEN 

{13.009} EQ {Horizontal Density} / 

{Vertical Density}

3

13.010-VPS 18.1.10 Field 13.010 shall specify the integer 

pixel density used in the vertical 

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the vertical component of the 

pixel aspect ratio.

2 M 13.010-JPEGL-VPS IF {13.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{13.010} EQ {Vertical Density}

3

2 M 13.010-JP2L-VPS No Implementation 4

2 M 13.010-PNG-VPS IF Present(PHYS Chunk) THEN

IF {13.008} EQ “1”, THEN

{13.010} EQ {Vertical Density} * 0.0254 

(meters/inch)

ELSE IF {13.008} EQ “2”, THEN

{13.010} EQ {Vertical Density} * 0.01 

(meters/cm) 

3

2 M 13.010-JPEGLVerAspectIF {13.008} NEQ “1” OR “2”, THEN 

{13.010} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 13.010-JP2LVerAspectNo Implementation 4

2 M 13.010-PNGVerAspectIF Present(PHYS Chunk), THEN

IF {13.008} NEQ “1” OR “2”, THEN 

{13.010} EQ {Horizontal Density} / 

{Vertical Density}

3

Table_1_No_Lossy 18.1.11 The field value shall be selected from 1 M Table_1_No_Lossy:: {13.011} MO [“NONE”, “JPEGL”, “JP2L”, 3
52

Table 1. Lossy algorithms are not valid. 13.011 “PNG”]

13.011-

ConfirmedCGA

8.1.10, 

18.1.11

The variable-resolution latent image 

data contained in the Type-13 logical 

record shall be uncompressed or may be 

the output from a lossless compression 

algorithm.

Field 13.011 shall specify the algorithm 

used to compress the transmitted 

grayscale images.

2 M 13.011-JPEGL-CGA {13.011} corresponds to {SOF }

2 M 13.011-JP2L-CGA {5th parameter of Image Header box} 

EQ “7” 

3

2 M 13.011-PNG-CGA Present(IHDR) 3

Bits_Per_Pixel 18.1.12, 

19.1.12, 

22.2.12

This mandatory ASCII field shall contain 

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

1 M Table_BPX_ASCII::1

3.012

{13.012} MO [8-16]

1 M Table_BPX_ASCII::1

4.012

{14.012} MO [8-16]

1 M Table_BPX_ASCII::1

7.012

{17.012} MO [8-16]

13.012-

ConfirmedBPX

18.1.12 Field 13.012 shall contain the number of 

bits used to represent a pixel. 

2 M 13.012-JPEGL-CBPX {13.012} EQ {BPX} 3

2 M 13.012-JP2L-CBPX IF {4th parameter of Image Header box} 

NEQ “255”, THEN {13.012} EQ {BPX}

3

2 M 13.012-PNG-CBPX {13.012} EQ {BPX} 3

Finger_Palm_Positi

on

18.1.13 This mandatory tagged field shall 

contain one or more possible finger or 

palm positions that may match the 

latent image. The decimal code number 

corresponding to the known or most 

probable finger position shall be taken 

from Table 12 or the most probable 

palm position from Table 35 and entered 

as a one- or two-character ASCII 

subfield. Additional finger and/or palm 

positions may be referenced by entering 

the alternate position codes as subfields 

separated by the ASCII RS separator 

character. The code 0, for 'Unknown 

Finger', shall be used to reference every 

finger position from one through ten. 

The code 20, for 'Unknown Palm', shall 

be used to reference every listed 

palmprint position. Code 19 shall be 

used to reference one or more parts of 

an EJI or tip.

1 M Finger_Palm_Positi

on::13.013

{13.013} MO Table 12 OR {13.013} MO 

Table 35

Subfields_Nx1 18.1.13, 

19.1.13

The field shall contain one or more 

subfields. Subfields are separated by 

ASCII RS. 

1 M Nx1::13.013 Count(RS_Subfields in 13.013 ) GTE 1 2

1 M Nx1::14.013 Count(RS_Subfields in 14.013 ) GTE 1 2

13.013::Finger_-

Palm_Position

18.1.13 

This mandatory tagged field shall 

contain one or more possible finger or 

palm positions that may match the 

latent image. The decimal code number 

corresponding to the known or most 

probable finger position shall be taken 

2 M 13.013::Finger_-

Palm_Position

ForEach(RS_Subfield in 13.013)

{

{RS_Subfield} MO [Table12, Table35]

}
53

from Table 12 or the most probable 

palm position from Table 35 and entered 

as a one- or two-character ASCII 

subfield. Additional finger and/or palm 

positions may be referenced by entering 

the alternate position codes as subfields 

separated by the ASCII RS separator 

character.

Search_Position_De

scriptors

18.1.14 This ASCII field shall be present if and 

only if the finger position code 19 

appears in Field 13.013. It is used to 

narrow the search of the latent image in 

this record against a database. This field 

shall consist of two mandatory 

information items. The first is the 

probable decimal finger position code 

(0-10) taken from Table 12. A “0”

indicates that all the fingers of a possible 

candidate should be searched. The 

second information item is the code 

taken from Table 32 to indicate the 

portion of the EJI or tip image in the 

database to search. Latent images of 

full-length fingers use codes FV1 through 

FV4 as defined in Table 32. Figure 7 is an 

illustration of the Entire Joint Image for 

a middle finger with each of the full 

finger views and constituent parts 

identified. The EJI code is used for the 

case where all four finger images are to 

be considered. For the case where the 

latent is to be compared to proximal, 

distal, or medial segments of a finger, 

this information item will contain the 

appropriate finger segment character. 

Multiple portions of the EJI can be listed 

and separated by the ASCII RS separator 

character. 

1 O Search_Position_De

scriptors::13.014

US_SubField:1 GTE 0 AND 

US_SubField:1 LTE 10

AND

US_SubField:2 MO Table 32

2,5

13.014::Search_-

Position_-

Descriptors_-

Present

18.1.14 Field 13.014: Search Position Descriptors 

(SPD)

This ASCII field shall be present if and 

only if the finger position code "19" 

appears in Field 13.013.

2 O 13.014::Search_-

Position_-

Descriptors_-

Present

IF {13.013} EQ “19” THEN

Present(13.014) 

Subfields_Nx6 18.1.15, 

19.1.15

The field shall contain one or more rows 

of six subfields.

1 O Nx6::13.015 Count(Subfields in 13.015 ) MOD 6 EQ 

0 AND Count(Subfields in 13.015 ) GT 0

5

1 O Nx6::14.015 Count(Subfields in 14.015 ) MOD 6 EQ 

0 AND Count(Subfields in 14.015 ) GT 0

5

PPC 18.1.15, 

19.1.15

If finger position code 19 appears in field 

13.013 or 14.013, this field contains 

offsets to the locations for the bounding 

1 O Print_Position_Coor

dinates::13.015

Count(US_Subfields in 13.015 ) EQ 6

AND

US_Subfield:1 MO 

5
54

box of the EJI, each of the full finger 

views, or segments within the EJI. When 

used, this field shall consist of six (6) 

mandatory information items to 

describe the type or portion of the 

latent image contained in this record 

and its location within an entire joint 

image. The first information item is the 

number of the full finger view with 

values of FV1 through FV4. Values of FV1 

to FV4 specify the bounding coordinates 

for each full finger view. The second 

information item is used to identify the 

location of a segment within a full finger 

view. It will contain the not applicable 

code NA if the image portion refers to a 

full finger view or to the entire joint 

image locations. It shall contain PRX, 

DST, MED for a proximal, distal, or 

medial segment.

[‘FV1’,’FV2’,’FV3’,’FV4’] 

AND

US_Subfield:2 MO 

[‘NA’,’PRX’,’DST’,’MED’]

1 O Print_Position_Coor

dinates::14.015

Count(US_Subfields in 14.015 ) EQ 6

AND

US_Subfield:1 MO 

[‘FV1’,’FV2’,’FV3’,’FV4’] 

AND

US_Subfield:2 MO 

[‘NA’,’PRX’,’DST’,’MED’]

2,5

PPC_Numbers 18.1.15, 

19.1.15

The next four information items are the 

horizontal and vertical 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. The location of the 

image portion is defined by the 

sequence of X coordinates (LEFT, RIGHT) 

and the Y coordinates (TOP, BOTTOM), 

of its bounding box.

1 O PPC_Numbers::13.0

15

{US_Subfield:3 to 6 in 13.015} GTE 0 5

1 O PPC_Numbers::14.0

15

{US_Subfield:3 to 6 in 14.015} GTE 0 5

RESERVED_FIELDS 18.1.18 Field 13.018-019: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 13.018-019::-

Reserved

Present(13.018 to 13.019)

RESERVED_FIELDS 18.1.20 Field 13.021-023: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 13.021-023::-

Reserved

Present(13.021 to 13.023)

Latent_Quality_Me

tric

18.1.21 This optional ASCII field is used to 

specify one or more different metrics of 

1 O Latent_Quality_Met

ric::13.024

ForEach(RS_Subfield in 13.024)

{

2
55

latent image quality score data for the 

image stored in this record. The 

meaning attributed to this metric must 

be defined and interpreted by the 

producer of the scoring algorithm or by 

the person or system used to assign the 

metric to the latent image. The metric 

may be a predictor of AFIS matcher 

accuracy performance or a different 

metric to indicate a value associated 

with the quality of the latent image for a 

particular function.

This field may contain one or more 

subfields, each consisting of four 

information items separated by the "US" 

separator character. The first 

information item is the code as chosen 

from Table 12 or Table 35.

The other three items identify a quality 

score and the algorithm used to create 

the quality score. This information is 

useful to enable the recipient of the 

quality score to differentiate between

quality scores generated by different 

algorithms and adjust for any 

differences in processing or analysis as 

necessary.

The second information item shall be a 

quantitative expression of the predicted 

matching performance of the biometric 

sample. This item contains the ASCII 

representation of the integer image 

quality score between 0 and 100 

assigned to the image data by a quality

algorithm. Higher values indicate 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. The use of additional 

values to convey other information 

should be harmonized with ISO/IEC 

19794 standards.

The third information item shall specify 

the ID of the vendor of the quality 

algorithm used to calculate the quality 

score. This 4-digit hex value is assigned 

by IBIA and expressed as four ASCII 

Count(US_Subfield) EQ 4

AND

US_Subfield:1 MO Table12 or Table 35

AND

US_Subfield:2 GTE 0 AND 

US_Subfield:2 LTE 100 OR 

US_Subfield:2 MO [254,255]

AND

US_Subfield:3 MO [IBIA Vendor 

Registry]

AND

US_Subfield:4 GTE 1 AND 

US_Subfield:4 LTE 65535 }
56

characters. The IBIA shall maintain the 

Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

this field to a registered organization.

The fourth 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. It indicates 

which of the vendor’s algorithms was 

used in the calculation of the quality 

score. This field contains the ASCII 

representation of the integer product 

code and should be within the range 1 

to 65,535.

Subfields_Nx4 18.1.21, 

19.1.23, 

19.1.24

The field shall contain one or more rows 

of four subfields.

1 O Nx4::13.024 Count(Subfields in 13.024 ) MOD 4 EQ 

0 AND Count(Subfields in 13.024 ) GT 0

1 O Nx4::14.023 Count(Subfields in 14.023 ) MOD 4 EQ 

0 AND Count(Subfields in 14.023 ) GT 0

1 O Nx4::14.024 Count(Subfields in 14.024 ) MOD 4 EQ 

0 AND Count(Subfields in 14.024 ) GT 0

IBIA_Quality_-

Vendor

18.1.21 Field 13.024: Latent quality metric 

(LQM)

This optional ASCII field is used to 

specify one or more different metrics of 

latent image quality score data for the 

image stored in this record. ...

The third information item shall specify 

the ID of the vendor of the quality 

algorithm used to calculate the quality 

score. This 4-digit hex value is assigned 

by IBIA and expressed as four ASCII 

characters. The IBIA shall maintain the 

Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

this field to a registered organization.

2 O 13.024::IBIA_-

Quality_Vendor

The code exists in the IBIA Vendor 

Registry of CBEFF Biometric 

Organizations.

RESERVED_FIELDS 18.1.22 Field 13.025-199: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 13.025-199::-

Reserved

Present(13.025 to 13.199)

13.999-ValidImage 18.1.24 Field 13.999 shall contain all of the data 

from a captured latent image.

2 M 13.999-ValidUncompLength(Field 13.999) EQ {13.006} * 

{13.007}

2 M 13.999-Valid-JPEGL Present(SOI, SOF, EOI)
57

2 M 13.999-Valid-JP2L Present(SigBox, HeadBox, Image 

Header box)

2 M 13.999-Valid-PNG Present(PNGSIG, IHDR, IDAT, IEND)

13::FsAtEnd 18.2 End of Type-13 variable-resolution latent 

image record

For the sake of consistency, immediately 

following the last byte of data from field 

13.999 an ASCII FS separator shall be

used to separate it from the next logical 

record. This separator must be included 

in the length field of the Type-13 record.

2 M 13::FsAtEnd Last(Byte in Record) EQ ASCII FS

Type 14 Requirements and Assertions

14::MandatoryField

s

19.1,

Table 33

For each field of the Type-14 record, 

Table 33 lists the "condition code" as 

being mandatory "M" or optional 

"O"...and occurrence limits.

2 M 14::CondCode_M IF "Cond code" EQ "M" in Table 33, the 

Field must be present in the record. 

2 M 14.xxxMaxOccurrencesCount(14.xxx) LTE 

MaxOccurrences(14.xxx)

2 M 14.xxxMinOccurrencesCount(14.xxx) GTE 

MinOccurrence(14.xxx)

14::FixedPositionFi

elds

19.1 It is required that the first two fields of 

the record are ordered, and the field 

containing the image data shall be the 

last physical field in the record.

2 M 14.001::LEN_First First(Field in Record) ST Type(Record) 

EQ 14 AND Field EQ 14.001 

2 M 14.002::IDC_Second Second(Field in Record) ST 

Type(Record) EQ 14 AND Field EQ 

14.002 

2 M 14.999::DATA_Last Last(Field in Record) ST Type(Record) 

EQ 14 AND Field EQ 14.999 

14::Len=Bytes 19.1.1 Field 14.001: Logical record length (LEN)

This mandatory ASCII field shall contain 

the total count of the number of bytes in 

the Type-14 logical record. Field 14.001 

shall specify the length of the record 

including every character of every field 

contained in the record and the 

information separators.

2 M 14.001::Len=Bytes {14.001} EQ Length(Record)

14::IDC=CNT_IDC 19.1.2 Field 14.002: Image designation 

character (IDC)

This mandatory ASCII field shall be used 

to identify the fingerprint image data 

contained in the record. This IDC shall 

match the IDC found in the file content 

(CNT) field of the Type-1 record.

2 M 14.002::IDC=CNT_-

IDC

The IDC matches the value of the 

corresponding CNT field of the Type-1 

record.

Table_11_Finger_T

agFld

19.1.3 The field value shall be selected from 

Table 11.

1 M Table_11_Finger::1

4.003

{14.003} MO Table 11

14.006-HLL 19.1.6 Field 14.006 shall contain the number of 

pixels contained on a single horizontal 

2 M 14.006-JPEGBJPEGL-HLL{14.006} EQ { Image Width} 3
58

line of the transmitted image. 2 M 14.006-JP2-JP2LHLL{14.006} EQ { Image Width} 3

2 M 14.006-PNG-HLL {14.006} EQ { Image Width} 3

2 M 14.006-WSQ-HLL {14.006} EQ { Image Width} 3

14.007-VLL 19.1.7 Field 14.007 shall contain the number of 

horizontal lines contained in the 

transmitted image. 

2 M 14.007-JPEGBJPEGL-VLL{14.007} EQ { Image Height } 3

2 M 14.007-JP2-JP2LVLL{14.007} EQ { Image Height } 3

2 M 14.007-PNG-VLL {14.007} EQ { Image Height } 3

2 M 14.007-WSQ-VLL {14.007} EQ { Image Height } 3

14.008-SLC 19.1.8 Field 14.008 shall specify the units used 

to describe the image sampling 

frequency (pixel density). 

2 M 14.008-JPEGBJPEGL-SLCIF Present(JFIF Header) THEN

Field 14.008 EQ {Sampling Units}

3

2 M 14.008-JP2-JP2LSLCNo Implementation 4

2 M 14.008-PNG-SLC IF Present(PHYS Chunk) THEN

IF {14.008} EQ 1 OR 2 THEN 

{Sampling Units} EQ 1, ELSE IF {14.008}

EQ 0 THEN

{Sampling Units} EQ 0

3

2 M 14.008-WSQ-SLC No Implementation 4

14.009-HPS 19.1.9 Field 14.009 shall specify the integer 

pixel density used in the horizontal

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the horizontal component of 

the pixel aspect ratio.

2 M 14.009-JPEGBJPEGL-HPSIF {14.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{14.009} EQ {Horizontal Density}

3

2 M 14.009-JP2-JP2LHPSNo Implementation 4

2 M 14.009-PNG-HPS IF Present(PHYS Chunk) THEN

IF {14.008} EQ “1”, THEN

{14.009} EQ {Horizontal Density} * 

0.0254 (meters/inch)

ELSE IF {14.008} EQ “2”, THEN

{14.009} EQ {Horizontal Density} * 0.01 

(meters/cm)

3

2 M 14.009-WSQ-HPS No Implementation 4

2 M 14.009-JPEGBJPEGL-HorzAspectIF {14.008} NEQ “1” OR “2”, THEN 

{14.009} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 14.009-JP2-JP2LHorzAspectNo Implementation 4

2 M 14.009-PNGHorzAspectIF Present(PHYS Chunk), THEN

IF {14.008} NEQ “1” OR “2”, THEN 

{14.009} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 14.009-WSQHorzAspectNo Implementation 4

14.010-VPS 19.1.10 Field 14.010 shall specify the integer 

pixel density used in the vertical 

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the vertical component of the 

pixel aspect ratio.

2 M 14.010-JPEGBJPEGL-VPSIF {14.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{14.010} EQ {Vertical Density}

3

2 M 14.010-JP2-JP2LVPSNo Implementation 4

2 M 14.010-PNG-VPS IF Present(PHYS Chunk) THEN 3
59

IF {14.008} EQ “1”, THEN

{14.010} EQ {Vertical Density} * 0.0254 

(meters/inch)

ELSE IF {14.008} EQ “2”, THEN

{14.010} EQ {Vertical Density} * 0.01 

(meters/cm) 

2 M 14.010-WSQ-VPS No Implementation 4

2 M 14.010-JPEGBJPEGL-VerAspectIF {14.008} NEQ “1” OR “2”, THEN 

{14.010} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 14.010-JP2-JP2LVerAspectNo Implementation 4

2 M 14.010-PNGVerAspectIF Present(PHYS Chunk), THEN

IF {14.008} NEQ “1” OR “2”, THEN 

{14.010} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 14.010-WSQVerAspectNo Implementation 4

Table_1_ASCII 19.1.11 The field value shall be selected from 

Table 1.

1 M Table_1_ASCII::14.0

11

{14.011} MO Table 1

14.011-

ConfirmedCGA

19.1.11 Field 14.011 shall specify the algorithm 

used to compress the color or grayscale 

image.

2 M 14.011-JPEGBJPEGL-CGA{14.011} corresponds to {SOF} 3

2 M 14.011-JP2-JP2LCGA{5th parameter of Image Header box} 

EQ “7” 

2 M 14.011-PNG-CGA Present(IHDR) 3

2 M 14.011-WSQ-CGA Present(SOF) AND Present(4th and 5th 

parameters not counting the SOF 

marker) 

3

14.012-

ConfirmedBPX

19.1.12 Field 14.012 shall contain the number of 

bits used to represent a pixel. 

2 M 14.012-JPEGBJPEGL-CBPX{14.012} EQ {BPX} 3

2 M 14.012-JP2-JP2LCBPXIF {4th parameter of Image Header box} 

NEQ “255”, THEN {14.012} EQ {BPX}

3

2 M 14.012-PNG-CBPX {14.012} EQ {BPX} 3

2 M 14.012-WSQ-CBPX No Implementation 4

Table_12_Subfields 19.1.13 The field value shall be selected from 

Table 12.

1 M Table_12_Subfields:

:14.013

{14.013} MO Table 12

14.013::FGP++ 19.1.13 Field 14.013: Finger position (FGP)

Additional finger positions may be 

referenced in the transaction by 

entering the alternate finger positions as 

subfields separated by the ASCII RS 

separator character.

2 M 14.013::FGP++ Additional finger positions may be 

referenced in the transaction by 

entering the alternate finger positions 

as subfields separated by the ASCII RS 

separator character.

Print_Position_Des

criptors

19.1.14 This ASCII field shall be present if and 

only if the finger position code 19 

appears in Field 14.013. This field shall 

consist of two mandatory information 

items. The first is the probable decimal 

finger position code (0-10) taken from 

Table 12. The second information item is 

1 O Print_Position_Desc

riptors::14.014

{US_Subfield:1} GTE 0 AND 

{US_Subfield:1} LTE 10 

AND

{US_Subfield:2} MO Table 32

2,5
60

the code taken from Table 32 to indicate 

the portion of the EJI or tip image that is 

stored as a single image in the database. 

There may be up to 17 such images for a 

single finger. Images of full-length 

fingers use codes FV1 through FV4 as 

defined in Table 32. Figure 7 is an 

illustration of the Entire Joint Image for 

a middle finger with each of the full 

finger views and constituent parts 

identified.

14.014::Print_-

Position_-

Descriptors_-

Present

19.1.14 Field 14.014: Print Position Descriptors 

(PPD)

This ASCII field shall be present if and 

only if the finger position code "19" 

appears in Field 14.013.

2 O 14.014::Print_-

Position_-

Descriptors_-

Present

IF {14.013} EQ “19” THEN

Present(14.014) 

Amputated_Or_Ba

ndaged

19.1.18 The value shall be XX or UP. 1 O Amputated_Or_Da

maged::14.018

{14.018} MO [XX, UP]

RESERVED_FIELDS 19.1.19 Field 14.019: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 14.019::Reserved Present(14.019)

Subfields_Nx5 19.1.21 The field shall contain one or more rows 

of five subfields.

1 O Nx5::14.021 Count(Subfields in 14.021 ) MOD 5 EQ 

0 AND Count(Subfields in 14.021 ) GT 0

Finger_Segment_Po

sitions

19.1.21 This optional ASCII field shall contain 

offsets to the locations of image 

segments containing the individual 

fingers within the flat images of the four 

simultaneous fingers from each hand or 

the two simultaneous thumbs. The 

offsets are 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. A finger segment is defined by 

the FINGER NUMBER, the X coordinates 

(LEFT, RIGHT) and the Y coordinates 

(TOP, BOTTOM), of its bounding box. 

The five information items within a 

finger segment definition are separated 

by the ASCII US separator character.

Individual finger segment definitions are 

1 O Finger_Segment_Po

sitions::14.021

ForEach(RS_Subfield in 14.021)

{

Count(US_Subfield) EQ 5

AND

{US_Subfield:1} MO Table 12

AND

{US_Subfield:2 to 5} GTE 0

}

2
61

separated by the ASCII RS separator 

character.. If more than one algorithm is 

used to segment the image, successive 

sets finger segmentation positions shall 

be formatted as above and immediately 

follow the previous set. 

NIST_Quality_Metri

c

19.1.22 This optional ASCII field shall contain the 

NIST Fingerprint Image Quality (NFIQ) 

scores for the individual finger(s) derived 

from the slap impressions or individual 

rolled fingerprints. It consists of two 

information items. The first item is the 

finger number between one and ten as 

chosen from Table 12. The second item 

is the quality score which is a 

quantitative expression of the predicted 

AFIS matcher accuracy performance of 

the fingerprint image. The scores range 

from 1 for the best quality image, to 5 

for the worst quality image. A 254 

indicates that no score was ever 

computed while an entry of 255 shall 

indicate a failed attempt to calculate the 

image quality metric. These two 

information items are separated by the 

ASCII US separator character. Individual 

finger quality definitions are separated 

by the ASCII RS separator character.

1 O NIST_Quality_Metri

c::14.022

ForEach(RS_Subfield in 14.022){ 

{US_Subfield:1} GTE 1 AND 

{US_Subfield:1} LTE 10 AND 

{US_Subfield:2} MO 

[1,2,3,4,5,254,255]}

2

Segmentation_Qual

ity_Metric

19.1.23 This optional ASCII field provides a 

measure of estimated correctness 

regarding the accuracy of the location of 

the segmented finger within the right or 

left four finger or two thumbs slap 

image. For each segmented finger, this 

field shall contain four information items 

separated by the ASCII US separator 

character. The first information item is 

the finger number between one and ten 

as chosen from Table 12. The other 

three items identify a quality score and 

the algorithm used to create the quality 

score. This information is useful to 

enable the recipient of the quality score 

to differentiate between quality scores 

generated by different algorithms and 

adjust for any differences in processing 

or analysis as necessary. The second 

information item shall be a measure of 

estimated correctness regarding the 

accuracy of the location of the 

segmented finger. This item contains the 

ASCII representation of the integer 

1 O Segmentation_Qual

ity_Metric::14.023

ForEach(RS_Subfield in 14.023)

{

Count(US_Subfield) EQ 4

AND

{US_Subfield:1} GTE 1 AND 

{US_Subfield:1} LTE 10

AND

{US_Subfield:2} GTE 0 AND

{US_Subfield:2} LTE 100 OR

{US_Subfield:2} MO [254,255]

AND

{US_Subfield:3} MO [IBIA Vendor 

Registry]

AND

{US_Subfield:4} GTE 1 AND

{US_Subfield:4} LTE 65535 OR

2
62

image quality score between 0 and 100 

assigned to the image data by a quality 

algorithm. Higher values indicate 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. The use of additional values 

to convey other information should be 

harmonized with ISO/IEC 19794 

standards. The third information item 

shall specify the ID of the vendor of the 

quality algorithm used to calculate the 

quality score. This 4-digit hex value is 

assigned by IBIA and expressed as four 

ASCII characters. The IBIA shall maintain 

the Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

this field to a registered organization. 

The fourth 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. It indicates 

which of the vendor’s algorithms was 

used in the calculation of the quality 

score. This field contains the ASCII 

representation of the integer product 

code and should be within the range 1 

to 65535. This subfield is repeated for 

each segmented finger whose 

coordinates appear in field 14.021. The 

ASCII RS separator character, separates 

each set of four information items. For 

the case where more than one 

segmentation algorithm is applied to a 

multi-finger plain image, the set of 

segmentation information items for 

each finger shall be ordered 

corresponding to the entries in field 

14.021. 

}

IBIA_Quality_-

Vendor

19.1.23 Field 14.023: Segmentation quality 

metric (SQM)

The third information item shall specify 

the ID of the vendor of the quality 

algorithm used to calculate the quality 

score. This 4-digit hex value is assigned 

by IBIA and expressed as four ASCII 

characters. The IBIA shall maintain the 

Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

2 O 14.023::IBIA_-

Quality_Vendor

The code exists in the IBIA Vendor 

Registry of CBEFF Biometric

Organizations.
63

this field to a registered organization.

Fingerprint_Quality

_Metric

19.1.24 This optional ASCII field is used to 

specify one or more different metrics of 

fingerprint image quality score data for 

the image stored in this record. The 

meaning attributed to this metric must 

be defined and interpreted by the 

producer of the scoring algorithm or by 

the person or system used to assign the 

metric to the fingerprint image. The 

metric may be a predictor of AFIS 

matcher accuracy performance or a 

different metric to indicate a value 

associated with the quality of the 

fingerprint image for a particular 

function.

1 O Fingerprint_Quality

_Metric::14.024

ForEach(RS_Subfield in 14.024)

{

Count(US_Subfield) EQ 4

AND

{US_Subfield:1} GTE 1 AND 

{US_Subfield:1} LTE 10

AND

{US_Subfield:2} GTE 0 AND

{US_Subfield:2} LTE 100 OR

{US_Subfield:2} MO [254,255]

AND

{US_Subfield:3} MO [IBIA Vendor 

Registry]

AND

{US_Subfield:4} GTE 1 AND

{US_Subfield:4} LTE 65535 OR

}

2

IBIA_Quality_-

Vendor

19.1.24 Field 14.024: Fingerprint quality metric 

(FQM)

The third information item shall specify 

the ID of the vendor of the quality 

algorithm used to calculate the quality 

score. This 4-digit hex value is assigned 

by IBIA and expressed as four ASCII 

characters. The IBIA shall maintain the 

Vendor Registry of CBEFF Biometric 

Organizations that will map the value in 

this field to a registered organization.

2 O 14.024::IBIA_-

Quality_Vendor

The code exists in the IBIA Vendor 

Registry of CBEFF Biometric 

Organizations.

ASEG_1-4_Subfields 19.1.25 The field shall consist of 1 to 4 subfields. 1 O ASEG_1_To_4_Subf

ields::14.025

Count(Subfields in 14.025 ) MO [1-4]

ASEG_3To99 19.1.25 This field uses an n-vertex polygon to 

encompass each finger image segment, 

where 'n' is between 3 and 99.

1 O ASEG_3_To_99_Seg

ments::14.025

Count(Subfield Vertices in 14.025 ) MO 

[3 to 99]

ASEG_FingerNum 19.1.25 Each subfield shall consist of a finger 

number between 1 and 10, the total 

number of vertices of the polygon 

encompassing the finger, and the set of 

consecutive vertices.

1 O ASEG_Finger_Numb

er_1-10::14.025

ForEach(ASCII RS_Subfield in Record)

{

First(US_Subfield in RS_Subfield) MO [1

to 10]

}

ASEG_Order 19.1.25 The order of the vertices must be in 1 O ASEG_Consecutive_ Angle.Direction.First EQ ((X,Y).1 To 
64

their consecutive order around the 

perimeter of the polygon, either 

clockwise or counterclockwise.

Order::14.025 (X,Y).2).Angle.Direction; ((X,Y).2 To N1 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 

ASEG_XY_GE_Zero 19.1.25 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.

1 O ASEG_XY_GE_Zero::

14.025

(X,Y) ST X GTE 0 AND Y GTE 0

14.025 ASEG 19.1.25 The order of the vertices must be in 

their consecutive order around the 

perimeter of the polygon, either 

clockwise or counterclockwise.

2 O ASEG_Consecutive_

Order

Not supported in this version 6

14.025 ASEG 19.1.25 No two vertices may occupy the same 

location. 

2 O ASEG_No_Duplicate

_Vertices

Each Vertex (X, Y) is unique

14.025 ASEG 19.1.25 The polygon must be a simple, plane 

figure with no sides crossing and no 

interior holes.

2 O ASEG_Simple_Plane

_Figure

No implementation 6

14.025 ASEG 19.1.25 2 O ASEG_No_Sides_-

Crossing

No implementation 6

14.025 ASEG 19.1.25 2 O ASEQ_No_-

Interior_Holes

No implementation 6

14.025 ASEG 19.1.25 This field shall consist of one to four 

subfields. 

2 O ASEG_Num_Subfields1 LTE Count( Subfields) LTE 4

14.025 ASEG 19.1.25 Each subfield shall consist of a finger 

number between 1 and 10, the total 

number of vertices of the polygon 

encompassing the finger, and the set of 

consecutive vertices. A minimum of 

three points is required to describe a 

finger location.

1 O ASEG_FingerNumber1 LTE Finger Number LTE 10

1 O ASEG_3_To_99_-

Segments

3 LTE Segments LTE 99

2 O ASEG_Expected_-

Information_Items

Expected Cols EQ 1 (Finger #) + 1 (# 

Vertices) + (2 * # Vertices ((x, y) pairs))

ExpectedCols = 2 + 2 * # Vertices

14.025 ASEG 19.1.25 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.

2 O

ASEG_XY_Offsets_G

E_Zero

For Each (X, Y)

 X GTE 0 AND

 Y GTE0

14.025 ASEG 19.1.25 An ASCII US separator character shall be 

used to separate the finger number, the 

number of vertices, each X coordinate, 

and each Y coordinate. 

2 O 14.025-US Character separator between finger 

number, the number of vertices, each 

X coordinate, and each Y coordinate EQ 

“US” 

14.025 ASEG 19.1.25 Subfields representing each finger are 

delimited by the ASCII RS separator 

2 O 14.025-RS Character separator between subfields 

representing each finger EQ ASCII RS
65

character.

RESERVED_FIELDS 19.1.26 Field 14.026-029: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 14.026-029::-

Reserved

Present(14.026 to 14.029)

RESERVED_FIELDS 19.1.28 Field 14.031-199: Reserved for future 

definition (RSV)

These fields are reserved for definition 

and inclusion in future revisions of this 

standard. None of these fields are to be 

used at this revision level. If any of these 

fields are present, they are to be 

ignored.

- - 14.031-199::-

Reserved

Present(14.031 to 14.199)

14.999-ValidImage 19.1.30 Field 14.999 shall contain all of the data 

from a captured tenprint image.

2 M 14.999-ValidUncompLength(Field 14.999) EQ {14.006} * 

{14.007}

2 M 14.999-ValidJPEGB-JPEGLPresent(SOI, SOF, EOI) 3

2 M 14.999-Valid-JP2-

JP2L

Present(SigBox, HeadBox, Image 

Header box)

3

2 M 14.999-Valid-PNG Present(PNGSIG, IHDR, IDAT, IEND) 3

2 M 14.999-Valid-WSQ Present(SOI, SOF, SOB, EOI) 3

14::FsAtEnd 19.2 End of Type-14 variable-resolution 

fingerprint image record

For the sake of consistency, immediately 

following the last byte of data from field 

14.999 an ASCII FS separator shall be 

used to separate it from the next logical 

record. This separator must be included 

in the length field of the Type-14 record.

1 M 14::FsAtEnd Last(Byte in Record) EQ ASCII FS

Type 17 Requirements and Assertions

17::FixedPositionFi

elds

22.2 It is required that the first two fields of 

the record are ordered, and the field 

containing the iris binary data shall be 

the last physical field in the record.

2 M 17.001::LEN_First First(Field in Record) ST Type(Record) 

EQ 17 AND Field EQ 17.001 

2 M 17.002::IDC_Second Second(Field in Record) ST 

Type(Record) EQ 17 AND Field EQ 

17.002 

2 M 17.999::DATA_Last Last(Field in Record) ST Type(Record) 

EQ 17 AND Field EQ 17.999 

17::MandatoryField

s

22.2,

Table 37

For each field of the Type-17 record, 

Table 37 lists the "condition code" as 

being mandatory "M" or optional 

"O"...and occurrence limits.

2 M 17::CondCode_M IF "Cond code" EQ "M" in Table 37, the 

Field must be present in the record. 

2 M 17.xxxMaxOccurrencesCount(17.xxx) LTE 

MaxOccurrences(17.xxx)
66

2 M 17.xxxMinOccurrencesCount(17.xxx) GTE 

MinOccurrences(17.xxx)

17::Len=Bytes 22.2.1 Field 17.001: Logical record length (LEN)

This mandatory ASCII field shall contain 

the total count of the number of bytes in 

the Type-17 logical record. Field 17.001 

shall specify the length of the record 

including every character of every field 

contained in the record and the 

information separators.

2 M 17.001::-

Value=Bytes

{17.001} EQ Length(Record)

17::IDC=TOC_IDC 22.2.2 Field 17.002: Image designation 

character (IDC)

This mandatory ASCII field shall be used 

to identify the iris image data contained 

in the record. This IDC shall match the 

IDC found in the file content (CNT) field 

of the Type-1 record.

2 M 17.002::IDC=TOC_-

IDC

The IDC value matches the 

corresponding IDC value in the content 

(CNT) field in the Type-1 record.

17.006-HLL 22.2.6 Field 17.006 shall contain the number of 

pixels contained on a single horizontal 

line of the transmitted image. 

2 M 17.006-JPEGBJPEGL-HLL{17.006} EQ {Image Width} 3

2 M 17.006-JP2-JP2LHLL{17.006} EQ {Image Width} 3

17.007-VLL 22.2.7 Field 17.007 shall contain the number of 

horizontal lines contained in the 

transmitted image. 

2 M 17.007-JPEGBJPEGL-VLL{17.007} EQ {Image Height} 3

2 M 17.007-JP2-JP2LVLL{17.007} EQ {Image Height} 3

17.008-SLC 22.2.8 Field 17.008 shall specify the units used 

to describe the image sampling 

frequency (pixel density). 

2 M 17.008-JPEGBJPEGL-SLCIF Present(JFIF Header) THEN

{17.008} EQ {Sampling Units}

3

2 M 17.008-JP2-JP2LSLCNo Implementation 4

17.009-HPS 22.2.9 Field 17.009 shall specify the integer 

pixel density used in the horizontal

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the horizontal component of 

the pixel aspect ratio.

2 M 17.009-JPEGBJPEGL-HPSIF {17.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{17.009} EQ {Horizontal Density}

3

2 M 17.009-JP2-JP2LHPSNo Implementation 4

2 M 17.009-JPEGBJPEGL-HorzAspect

IF {17.008} NEQ “1” OR “2”, THEN 

{17.009} EQ {Horizontal Density} / 

{Vertical Density}

3
67

2 M 17.009-JP2-JP2LHorzAspectNo Implementation 4

17.010-VPS 22.2.10 Field 17.010 shall specify the integer 

pixel density used in the vertical 

direction of the transmitted image if the 

SLC field contains a 1 or 2. Otherwise, it 

indicates the vertical component of the 

pixel aspect ratio.

2 M 17.010-JPEGBJPEGL-VPSIF {17.008} EQ “1” OR “2”, THEN

IF Present(JFIF Header) THEN

{17.010} EQ {Vertical Density}

3

2 M 17.010-JP2-JP2LVPSNo Implementation 4

2 M 17.010-JPEGBJPEGL-VerAspect

IF {17.008} NEQ “1” OR “2”, THEN 

{17.010} EQ {Horizontal Density} / 

{Vertical Density}

3

2 M 17.010-JP2-JP2LVerAspectNo Implementation 4

Table_1_No_WSQ_

PNG

22.2.11 The field value shall be selected from 

Table 1. WSQ and PNG are not valid. 

1 M Table_1_No_WSQ_

PNG::17.011

{17.011} NOT MO [‘WSQ’, ‘PNG’] AND 

{17.011} MO Table 1

17.011-

ConfirmedCGA

22.2.11 Field 17.011 shall specify the algorithm 

used to compress the color or grayscale 

image.

2 M 17.011-JPEGBJPEGL-CGA{17.011} corresponds to {SOF} 3

2 M 17.011-JP2-JP2LCGA

{5th parameter of Image Header box} 

EQ “7” 

3

17.012-

ConfirmedBPX

22.2.12 Field 17.012 shall contain the number of 

bits used to represent a pixel. 

2 M 17.012-JPEGBJPEGL-CBPX{17.012} EQ {BPX} 3

2 M 17.012-JP2-JP2LCBPX

IF {4th parameter of Image Header box} 

NEQ “255”, THEN {17.012} EQ {BPX}

4

17.013-CSP 22.2.13 Field 17.013 shall contain an entry from 

Table 3 to identify the color space used. 

2 M 17.013-JPEGBJPEGL-CSPNo Implementation 3

2 M 17.013-JP2-JP2LCSP

IF Present(Colour Specification box), 

THEN {17.013} corresponds to {CSP}

3

SubFields_1x3 22.2.16, 

22.2.19

The field shall contain three subfields 

separated by an ASCII US separator 

character.

1 O SubFields_1x3::17.0

16

(Rows, Cols) ST Rows EQ 1 AND Cols EQ 

3

1 O SubFields_1x3::17.0

19

Count(Subfields in 17.019 ) EQ 3

DeviceUniqueID 22.2.17 This optional field shall contain a 1 O DeviceUniqueID::17 First(Byte in 17.017) MO [D, M, P] OR
68

sixteen-byte string uniquely identifying 

the device or source of the data. This 

data can be one of: (1) Device Serial 

number, identified by the first character 

“D”, (2) Host PC Mac address, identified 

by the first character “M”, (3) Host PC 

processor ID, identified by the first 

character “P”, and (4) No serial number, 

identified by all zero’s.

.017 Sum(Bytes(17.017)) EQ 0

IBIA_Quality_-

Vendor

22.2.24 Field 17.024: Image Quality Score (IQS)

... The second information item shall 

specify the ID of the vendor of the 

quality algorithm used to calculate the 

quality score. This 4-digit hex value is 

assigned by IBIA and expressed as four 

ASCII characters. The IBIA shall maintain 

the Vendor Registry of CBEFF Biometric

Organizations that will map the value in 

this field to a registered organization.

2 O 17.024::IBIA_-

Quality_Vendor

The value is in the IBIA Vendor Registry 

of CBEFF Biometric Organizations.

NirVisOther 22.2.25 This optional field indicates the lighting 

spectrum used in capturing the iris 

image. Values shall be one of the 

following: NIR for near-infrared 

illumination (~700-850nm), VIS for 

visible full spectrum illumination (~380-

740nm), or OTHER for other 

illumination.

1 O NIR_VIS_OTHER::17

.025

{17.025} MO [‘NIR’, ‘VIS’, ‘OTHER’]

17.026-IRD 22.2.26, 

Table 37

Field 17.026 shall specify the expected 

iris diameter in pixels. 

2 O 17.026-IRD {17.026} LTE Min({17.006},{17.007})

17.999-ValidImage 22.2.31 Field 17.999 shall contain the iris image. 2 M 17.999-ValidUncompLength(F13.999) EQ {13.006} * {13.007}

2 M 17.999-ValidJPEGB-JPEGLPresent(SOI, SOF, EOI)

2 M 17.999-Valid-JP2-

JP2L

Present(SigBox, HeadBox, ImgBox)

Test Notes:

1. Requirements related to International Character Sets are not tested in this version of the CTS.

2. Subfields are defined as follows:

RS_Subfield:N= Any subfield that uses the ASCII RS separator character. If N is specified, N represents the Nth such subfield in the field

US_Subfield:N = Any subfield that uses the ASCII US separator character. If N is specified, N represents the Nth such subfield in the field

Subfield(s) = If a prefix is not specified (US or RS), then the type of subfield should be clear from the context of the requirement.
69

3. The table lists assertions for multiple image format types, however, based upon the compression algorithm specified in the record, specific image formats 

are to be tested in different ways. Features of the image metadata are defined as follows:

Image Width 

o JPEG, JPEGL: 4th parameter of the Frame Header not counting the SOF marker

o JP2,JP2L: 2nd parameter of Image Header box

o PNG: 1st parameter of IHDR chunk

o WSQ: 5th parameter of SOF not counting the SOF marker

Image Height 

o JPEG, JPEGL: 3rd parameter of the Frame Header not counting the SOF marker

o JP2,JP2L: 1st parameter of Image Header box

o PNG: 2nd parameter of IHDR chunk

o WSQ: 4th parameter of SOF not counting the SOF marker

Image metadata markers 

o JPEG, JPEGL: SOI – Start of Image, SOF – Start of Frame, EOI – End of Image

o JP2, JP2L: SigBox – JP2 Signature box, HeadBox – JP2 Header box, ImgBox – Image Header box

o PNG: PNGSig – PNG Signature, IHDR – IHDR Chunk, IDAT – IDAT Chunk, IEND – IEND Chunk

o WSQ: SOI – Start of Image, SOF – Start of Frame , SOB – Start of Block, EOI – End of Image

Sampling Units 

o JPEG, JPEGL: 4th parameter in JFIF Header not counting the APP0 Marker

o JP2, JP2L: Undefined

o PNG: 3rd parameter of PHYS chunk

o WSQ: Undefined

Horizontal Density 

o JPEG, JPEGL: 5th parameter in JFIF Header not counting the APP0 Marker

o JP2, JP2L: Undefined

o PNG: 1st parameter in PHYS Chunk

o WSQ: Undefined

Vertical Density 

o JPEG, JPEGL: 6th parameter in JFIF Header not counting the APP0 Marker

o JP2, JP2L: Undefined

o PNG: 2nd parameter in PHYS Chunk

o WSQ: Undefined

BPX 
70

o JPEG, JPEGL: 2nd parameter of the Frame Header not counting the SOF marker

o JP2, JP2L: 7 LSB of 4th parameter of Image Header box + 1 

o PNG: 3rd parameter of IHDR chunk

o WSQ: Undefined

CSP 

o JPEG,JPEGL: Undefined

o JP2, JP2L: 4th parameter of Colour Specification box

o PNG: 4th parameter of IHDR chunk

o WSQ: Undefined

4. The image metadata required to implement the assertion is not defined in the image standard documentation.

5. While the ANSI/NIST-ITL 1-2007 standard defines only the “M” and “O” statuses for each field, this field is conditional upon the content of the other 

field(s).

6. The required algorithm for this assertion is under research.