NIST SP 500-304 Annex D: Test Notes 

and Exceptions for the ANSI/NISTITL 1-2011 Update 2013 Conformance 

Testing Methodology Framework

[er|(Integrated Errata Edition)|er]1

Christofer J. McGinnis

Dylan J. Yaga

This publication is available free of charge from:

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

November 2015

 

1

[er|This edition integrates all errata discovered since NIST SP 500-304 Annex D was published. Any modifications 

from the originally published document are marked and contained within the [er||er] markers and highlighted for 

easy reference.|er]
Reports on Information Technology

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

(NIST) stimulates U.S. economic growth and industrial competitiveness through technical leadership 

and collaborative research in critical infrastructure technology, including tests, test methods, 

reference data, and forward-looking standards, to advance the development and productive use of 

information technology. To overcome barriers to usability, scalability, interoperability, and security 

in information systems and networks, ITL programs focus on a broad range of networking, security, 

and advanced information technologies, as well as the mathematical, statistical, and computational 

sciences. Special Publication 500-series reports on ITL's research in tests and test methods for 

information technology, and its collaborative activities with industry, government and academic 

organizations.

This publication is a contribution of the National Institute of Standards and Technology and is not 

subject to copyright. Any organization interested in reproducing “Annex D: Test Notes and 

Exceptions for the ANSI/NIST-ITL 1-2011 Update 2013 Conformance Testing Methodology 

Framework” is free to do so. However, there shall be no alteration to any of the material information 

contained in the publication. NIST retains the sole right to submit this publication to any other forum 

for any purpose.

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

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

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

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

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

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

conformance to the required standard(s) can, in many cases, jeopardize the expected biometric 

recognition performance or prevent access to the data (as well as impact the overall operational 

performance) since implementers may handle non-conformant records in different ways during 

processing.

Although no conformance test can be comprehensive enough to test all the different combinations of 

mandatory requirements of a standard and all possible combinations of conditional and optional 

characteristics that could be included in American National Standards Institute (ANSI)/NIST-ITL 

2011 Update: 2013 (AN-2013) transactions, a well-designed conformance test tool that faithfully 

implements a standard conformance testing methodology could raise the level of confidence on the 

test results. Therefore, transactions tested with such a tool (and reported to be conformant to the 

standard), are more likely to conform to the standard. 

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 associated conformance test 

architectures and test suites and develops these test tools to support users who require conformance 

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

standards by using the same testing tools available to users. Testing laboratories can also benefit 

from the use of these test tools. Under the conformance test software called “BioCTS”, NIST/ITL 

CSD develops Conformance Test Architectures (CTAs) and Conformance Test Suites (CTSs) to test 

implementations of national and international biometric data interchange formats. These testing tools 

and related documentation can be found and downloaded at: 

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

Foreword ............................................................................................................................. 3

Annex D: Test Notes and Test Exceptions ....................................................................... 1

D.1 Test Notes .................................................................................................................. 1

D.1.1 Valid Image Resolution and Compression Algorithm Value Tables .................... 16

Type-4 Images ................................................................................................................................................16

Type-10 Images ..............................................................................................................................................18

Type-13 Images ..............................................................................................................................................20

Type-14 Images ..............................................................................................................................................22

Type 15, 16, 19, and 20 Images......................................................................................................................24

Type-17 Images ..............................................................................................................................................26

D.2 Test Exceptions ........................................................................................................ 27

Tables

Table D.1 - IDC ID Location Comparison .......................................................................... 2

Table D.2 - IDC Comparison Results: Special Cases....................................................... 2

Table D.3 - IDC Comparison Results................................................................................. 4

Table D.5 – Date and Time Formats .................................................................................. 7

Table D.4 – Standard Discrepancies and CTFM Assumptions...................................... 12

Figure D.5: Type-4 Image Constraints ............................................................................ 16

Figure D.6: Type-4 Resolution Constraints .................................................................... 16

Figure D.7: Type-10 Image Constraints .......................................................................... 18

Figure D.8: Type-10 Resolution Constraints .................................................................. 18

Figure D.9: Type-13 Image Constraints .......................................................................... 20

Figure D.10: Type-13 Resolution Constraints ................................................................ 20

Figure D.11: Type-14 Image Constraints ........................................................................ 22

Figure D.12: Type-14 Resolution Constraints ................................................................ 23

Figure D.13: Types 15, 16, 19, and 20 Image Constraints.............................................. 24

Figure D.14: Types 15, 16, 19, and 20 Resolution Constraints...................................... 24

Figure D.15: Type-17 Image Constraints ........................................................................ 26
Figure D.16: Type-17 Resolution Constraints ................................................................ 26

Table D.17- Exceptions Table .......................................................................................... 27
1

Annex D: Test Notes and Test Exceptions

[er|Errata

This edition integrates all errata discovered since NIST SP 500-304 Annex D was published. Any modifications from the originally 

published document are marked and contained within the [er||er] markers and highlighted for easy reference. |er]

D.1 Test Notes

The following test notes provide clarification of the assertion text provided in the Test Assertion column. The test notes describe:

 Clarifications: Additional information to help clarify complex assertions. Examples include image metadata and IDC comparisons, 

which depend upon the Record Type and are not easily defined using the Assertion Syntax. 

 Discrepancies: Approach used when the base standard contains possible discrepancies or lacks clarity so that the requirement 

cannot be clearly understood from the provided information. For example, two separate sections of the standard list a Field as 

Optional and Mandatory respectively. In such a case, the approach used by the CTMF will provide justification for deciding which 

section is correct.

 Exceptions: Any AN-2013 requirements that are not addressed by the CTMF. These are considered exceptions because they are 

requirements in the base standard, but they are not yet addressed by the CTMF. See also: Test Exceptions.

t1. Exception-Character Sets. Requirements related to Character Sets other than 7-bit ASCII or binary are not addressed (for the 

Traditional encoding). See also: Test Exceptions.

t2. Clarification-IDC Comparisons. From 7.3.1: “Two or more records may share a single IDC solely to identify and link together 

records that pertain to different representations of the same biometric trait... two or more image records may share a single IDC 

only when they are enhancements of a single image; such transformations shall have identical dimensions, and shall not be distorted 

with respect to each other”. For records with matching IDC’s, refer to the tables below to determine the conformance status based 

upon the biometric sample types being compared. For matching IDC’s that belong to record types not listed below, the result is a 

warning. Table D.1 is used to determine the biometric type of the record and the location of the Comparison ID used to compare two 

or more record types that are allowed to have matching IDC values. After determining the biometric type and comparison ID (if 

applicable) from Table D.1, Table D.3 is used to determine the conformance status (note: Table D.2 should be referenced instead of 

Table D.3 for special record types, indicated in Table D.1 with an asterisk *). For example, for two records with matching IDC 

values, if the first record is of type Finger and the second record is of type Finger, then according to Table D.3, the comparison ID’s 

will need to be compared to determine the conformance result. In another example, if the two records are of a special type (indicated 

by an asterisk) such as Type 7, then the information in Table D.2 is used instead of Table D.3. 
2

Table D.1 - IDC ID Location Comparison

IDC: ID Location Comparison

Record Type Biometric Field For Comparison ID

4 FINGER {Byte:1 in 4.004}

7* USER-DEFINED* NA

8 SIGNATURE NA

9 MINUTIAE NA

10 {10.003}

<SCAR, MARK, TATTOO, 

or FACE>

IF {10.003} MO [ASCII(SCAR,MARK, 

TATTOO)] THEN 

{InfoItem:1 in 10.040}

11 VOICE NA

12 DENTAL NA

13 FRICTIONRIDGE {InfoItem:1 in SubField:1 in 13.013}

14 FINGER {InfoItem:1 in SubField:1 in 14.013}

15 PALM {15.013}

16* USER-DEFINED-OTHER* NA

17 IRIS {17.003}

18 DNA NA

19 PLANTAR {19.013}

20* SOURCE* NA

2, 21-99* NOTBIOMETRIC* NA

*For these types, see Table D.2

Table D.2 - IDC Comparison Results: Special Cases
3

IDC: Special Case Comparison Results

First Record Second Record Comparison IDs Notes Result

ANY NOTBIOMETRIC NA ANY represents any 

type-IDC values can 

only be the same for 

biometric traits

Error

ANY SOURCE NA Validity depends on 

contents of the 

Type-20 Record

Warning

ANY USER-DEFINED NA ANY represents any 

type. Validity 

depends on contents 

of Type-7 Record.

Warning

ANY (Except 

USER-DEFINEDOTHER)

USER-DEFINED-OTHER NA ANY represents any 

type. User-definedother must be a type 

not already defined 

by the standard, so 

the traits are always 

from a different 

sample type.

Error

NOTBIOMETRIC ANY NA ANY represents any 

type-IDC values can 

only be the same for 

biometric traits

Error

SOURCE ANY NA Validity depends on 

contents of the 

Type-20 Record

Warning

USER-DEFINED ANY NA ANY represents any 

type. Validity 

depends on contents 

of Type-7 Record.

Warning

USER-DEFINEDOTHERUSER-DEFINED-OTHER NA Validity depends on 

contents of the 

Type-16 Record.

Warning
4

USER-DEFINEDOTHERANY (Except USERDEFINED-OTHER)NA ANY represents any 

type. User-definedother must be a type 

not already defined 

by the standard, so 

the traits are always 

from a different 

sample type.

Error

Table D.3 - IDC Comparison Results

IDC: Comparison Results

First Record Second Record Comparison IDs Notes Result

DENTAL DENTAL NA Ok

DENTAL NEQ DENTAL NA Error

DNA DNA NA Ok

DNA NEQ DNA NA Error

FINGER FINGER Same Ok

FINGER FINGER Different Error

FINGER MINUTIAE NA Ok

FINGER FRICTIONRIDGE Same Ok

FINGER FRICTIONRIDGE Different Error

FINGER PALM All EQ 33 OR All 

EQ 36

33 and 36 are 

hypothenar codes 

(palm) but are part 

of the extended 

fingerprint set

Ok

FINGER PALM Any NEQ 33 OR 

Any NEQ 36

33 and 36 are 

hypothenar codes 

(palm) but are part 

Error
5

of the extended 

fingerprint set

FINGER NOT MO[ FINGER, 

MINUTIAE, 

FRICTIONRIDGE, PALM]

NA Error

FACE FACE NA Ok

FACE NEQ FACE NA Error

FRICTIONRIDGE FRICTIONRIDGE, FINGER, 

PALM, or PLANTAR

Same Ok

FRICTIONRIDGE FRICTIONRIDGE, FINGER, 

PALM, or PLANTAR

Different Error

FRICTIONRIDGE MINUTIAE NA Ok

FRICTIONRIDGE NOT MO[ FRICTIONRIDGE, 

FINGER, PALM, PLANTAR, 

MINUTIAE]

NA Error

IRIS IRIS Same Ok

IRIS IRIS Different Error

IRIS NEQ IRIS NA Error

SCAR SCAR Same Ok

SCAR SCAR Different Warning

SCAR MARK or TATTOO Same or 

Different

Warning

SCAR NOT MO[ SCAR, MARK, 

TATTOO]

NA Error

MARK MARK Same Ok

MARK MARK Different Warning

MARK SCAR or TATTOO Same or 

Different

Warning

MARK NOT MO[ SCAR, MARK, 

TATTOO]

NA Error

MINUTIAE MINUTIAE NA Ok

MINUTIAE FINGER, PALM, PLANTAR, 

or FRICTIONRIDGE

NA Ok
6

MINUTIAE NOT MO[ MINUTIAE, 

FINGER, FRICTIONRIDGE, 

PALM, PLANTAR]

NA Error

SIGNATURE SIGNATURE NA Ok

SIGNATURE NEQ SIGNATURE NA Error

TATTOO TATTOO Same Ok

TATTOO TATTOO Different Warning

TATTOO SCAR or MARK Same or 

Different

Warning

TATTOO NOT MO[ SCAR, MARK, 

TATTOO]

NA Error

PALM PALM Same Ok

PALM PALM Different Error

PALM FRICTIONRIDGE Same Ok

PALM FRICTIONRIDGE Different Error

PALM MINUTIAE NA Ok

PALM FINGER Same AND Both 

EQ 33 OR 36

33 and 36 are 

hypothenar codes 

(palm) but are part 

of the extended 

fingerprint set

Ok

PALM FINGER Different OR 

Both NEQ 33 OR 

36

33 and 36 are 

hypothenar codes 

(palm) but are part 

of the extended 

fingerprint set

Error

PALM NOT MO[ PALM, 

MINUTIAE, 

FRICTIONRIDGE, FINGER]

NA Error

PLANTAR PLANTAR Same Ok

PLANTAR PLANTAR Different Error

PLANTAR FRICTIONRIDGE Same Ok

PLANTAR FRICTIONRIDGE Different Error

PLANTAR MINUTIAE NA Ok
7

PLANTAR NOT MO [PLANTAR, 

FRICTION RIDGE, 

MINUTIAE]

NA Error

VOICE VOICE NA Ok

VOICE NEQ VOICE NA Error

t3. Discrepancy-Time and Date. This test note describes how the CTMF addresses the various date and time format requirements and 

indicates the approach taken for several discrepancies found throughout the standard. See table below. Year zero (0000) is invalid 

for all date and time types. Month/Day combinations must be valid based upon the valid calendar combinations (e.g. February 31) is 

invalid. Note that Section 7.7.2.1 provides general requirements for date and time values, including the following allowed values: 

month/MM (01 through 12); day/DD (01 through 31); hour/hh (00 through 23); minute/mm (0 through 59); and second/ss (0 through

59).

Table D.5 – Date and Time Formats 

Date and Time Formats

Date Format Title References Standard Definition Discrepancies CTMF Implementation

Local Date (Trad) 7.7.2.3, 

Annex B

YYYYMMDD

YYYY designates the four-digit year; MM 

designates the month (01 through 12); 

DD represents the day of the month (01 

through 31)

Some instances of Local 

Date in the standard 

indicate that zero values are 

allowed for the month and 

day when they are not 

known. This conflicts with 

the standard definition, 

which specifies that 01 is 

the minimum value. 

Same as Standard Definition. 

Referred to in Assertion Syntax as: 

ValidLocalDate. 

Instances of local dates that allow zero values 

are treated as special cases and considered to 

be a “Local Date Estimate” (see definition in 

this table). 

Local Date (XML) 7.7.2.3, 

Annex C

Common dates (other than GMT) shall 

be represented in the form YYYY-MMDD (contained in<nc:Date>) , YYYY-MM 

(contained in <nc:YearMonth>), or 

YYYY (contained in <nc:Year>). 

YYYY designates the four-digit year; MM 

designates the month (01 through 12); 

Some instances of Local 

Date in the standard 

indicate that zero values are 

allowed for the month and 

day when they are not 

known. This conflicts with 

the standard definition, 

Same as Standard Definition. 

Referred to in Assertion Syntax as: NIEMValidLocalDate, NIEM-ValidLocalYearMonth, 

or NIEM-ValidLocalYear. 

Instances of local dates that allow zero values 

are treated as special cases and considered to 

be a “Local Date Estimate” (see definition in 

this table). 
8

DD represents the day of the month (01 

through 31)

which specifies that 01 is 

the minimum value.

Note: The Schema also allows the 

<nc:DateTime> element, which is not valid. 

The CTMF allows only the <nc:Date>, 

<nc:YearMonth>, and< nc:Year elements>. 

Local Date & Time (Trad) 7.7.2.4 None / Missing.

Section 7.7.2.4 indicates that the format 

is different for each encoding, but 

Annex B does not provide a definition.

Undefined in standard. YYYYMMDDhhmmss

Referred to in standard as 

ValidLocalDateTime

YYYY designates the four-digit year; MM 

designates the month (01 through 12); DD 

represents the day of the month (01 through 

31); hh represents the hour (00 through 23); 

mm represents the minute (00 through 59); 

and ss represents the seconds (00 through 

59). 

This is modeled after the UTC/GMT definition, 

but does not indicate the time zone (Z). 

Local Date & Time (XML) 7.7.2.4 None / Missing.

Section 7.7.2.4 indicates that the format 

is different for each encoding, but 

Annex C does not provide a definition.

Undefined in standard. YYYY-MM-DDThh:mm:ss

Referred to in standard as NIEMValidLocalDateTime

YYYY designates the four-digit year; MM 

designates the month (01 through 12); DD 

represents the day of the month (01 through 

31); hh represents the hour (00 through 23); 

mm represents the minute (00 through 59); 

and ss represents the seconds (00 through 

59). T is a constant indicating time. 

This is modeled after the UTC/GMT definition, 

but does not indicate the time zone (Z).

Must be contained in <nc:DateTime>

Local Date Estimate 

(Trad)

8.10.5, 

8.20.5

This type is not formally defined in the 

standard, but is mentioned in the 

description text for certain fields 

(namely 10.005 and 20.005):

“It may not be possible to know the 

exact date of imagery capture. In such a

case, specify the date to the level known 

and fill the rest of the date with zeros.”

This does not match the 

definition of Local Date in 

7.7.2.3 because non-zero 

values are not allowed. 

Same as ValidLocalDate, but allows zeros for 

unknown values. 

Referred to in CTMF as 

ValidLocalDateEstimate. 

These instances include, but may not be 

limited to: 10.005-PHD and 20.005-ACD
9

Local Date Estimate 

(XML)

8.10.5, 

8.20.5

This type is not formally defined in the 

standard, but is mentioned in the 

description text for certain fields 

(namely 10.005 and 20.005):

“It may not be possible to know the 

exact date of imagery capture. In such a

case, specify the date to the level known 

and fill the rest of the date with zeros.”

This does not match the 

definition of Local Date in 

7.7.2.3 because non-zero 

values are not allowed.

Same as NIEM-ValidLocalDate, NIEMValidLocalYearMonth, or NIEMValidLocalYear, but allows zeros for unknown 

values. 

Referred to in CTMF as NIEMValidLocalDateEstimte, NIEMValidLocalYearMonthEstimate, NIEMValidLocalYearEstimate. 

These instances include, but may not be 

limited to: 10.005-PHD and 20.005-ACD

GMT/UTC (Trad) 7.7.2.2,

Annex B

YYYYMMDDHHMMSSZ, a 15-character 

string that is the concatenation of the 

date with the time and concludes with 

the character “Z”. The YYYY characters 

shall represent the year of the 

transaction. The MM characters shall be

the tens and units values of the month. 

The DD characters shall be the tens and

units values of the day of the month. 

The HH characters represent the hour; 

the MM the minute; and the SS 

represents the second.

None. Same as Standard Definition.

Referred to in CTMF as ValidUTC/GMT.

GMT/UTC (XML) 7.7.2.2,

Annex C

YYYY-MM-DDThh:mm:ssZ

T and Z are constants.

Contained in <nc:DateTime>

None. Same as Standard Definition.

Referred to in CTMF as NIEM-ValidUTC/GMT.

Date Range Estimate 

(Trad)

8.10, 8.12, 

8.20

This type is not formally defined in the 

standard, but is mentioned in the 

description text for certain fields.

“time measure indicator followed by 1 

or 2 digits. May be concatenated, with 

larger time units first. Units: Y year, M 

month, D day”

Discrepancy between the 

standard text and the 

character min and max 

restrictions in the record 

layout tables. The text states 

that single-digit year, 

month, and day values may 

be used, but the tables 

indicate a minimum length 

of 3, which indicates only 

two-digit values are 

allowed. This CTMF 

Same as Standard Definition.

Referred to in CTMF as DateRangeEstimate
10

assumes a minimum 

character count of 2

Date Range Estimate 

(XML)

8.10, 8.12, 

8.20

This type is not formally defined in the 

standard, but is mentioned in the 

description text for certain fields.

Defined by XML Schema type 

xsd:duration. 

None. Same as Standard Definition.

Referred to in CTMF as NIEMDateRangeEstimate

Must validate against XML Schema type 

xsd:duration.

Date Time Offset (Trad) 8.10, 8.12, 

8.20

This type is not formally defined in the 

standard, but is mentioned in the 

description text for certain fields.

“time measure indicator followed by 1 

or 2 digits. May be concatenated, with 

larger time units first. Units: Y year, M 

month, D day, h hour, m minute”

Discrepancy between the 

standard text and the 

character min and max 

restrictions in the record 

layout tables. The text states 

that single-digit year, 

month, and day values may 

be used, but the tables 

indicate a minimum length 

of 3, which indicates only 

two-digit values are 

allowed. This CTMF 

assumes a minimum 

character count of 2

Same as Standard Definition.

Referred to in CTMF as 

DateTimeRangeEstimate

Date Time Offset (XML) 8.10, 8.12, 

8.20

This type is not formally defined in the 

standard, but is mentioned in the 

description text for certain fields.

Defined by XML Schema type 

xsd:duration.

None. Same as Standard Definition.

Referred to in CTMF as NIEMDateTimeRangeEstimate

Must validate against XML Schema type 

xsd:duration.

Time Index (Trad) 7.7.2.5 hh:mm:ss.sss where ss.sss refers

to the seconds and milliseconds. Thus,

the allowed special characters are the 

colon and the period

None. Same as Standard Definition.

Referred to in CTMF as TimeIndex

Time Index (XML) 7.7.2.5 hh:mm:ss.sss where ss.sss refers

to the seconds and milliseconds. Thus, 

the allowed special characters are the 

colon and the period

None. Same as Standard Definition.

Referred to in CTMF as NIEM-TimeIndex

t4. Clarification-Image Tests. All assertions associated with compressed image types refer to the image metadata and not the image 

data itself. See the test assertion syntax in the CTMF for the defined Image Metadata Tags. 
11

t5. Clarification-Rounding. Some image formats (such as PNG) use scale units other than pixels per inch (ppi) or pixels per centimeter 

(ppc), which are the measurements used in the requirements of the base standards. For those image formats, the use of a conversion 

factor is necessary to convert the pixel scale to the correct units (either ppi or ppc). This conversion may result in a decimal value 

that cannot be held in the THPS or TVPS fields, which hold Integer values only. In all such cases, section 7.7.8.4 of AN-2013 

specifies that the result should be rounded up for values greater than or equal to X.5 and rounded down for values less than X.5.

t6. [er| This test note no longer applies. It previously addressed missing ASEG assertions, but they have been added.|er]

t7. Clarification-WSQ version. WSQ specification version 2.0 or higher is required, but there is no known method for determining the 

specification version of a WSQ image. Therefore, this is a level 3 requirement. The Ev field specifies the encoder version, but there 

is no requirement for WSQ specification versions to contain certain encoder versions (other than 3.1 containing an Ev of 2). 

t8. Clarification-NCIC Codes. The NCIC codes (NCIC_Codes) are available at http://oregon.gov/OSP/CJIS/NCIC.shtml. Any values 

found in Annex E of NIST SP 500-271 are also valid. 

t9. Clarification-Sequential. The term “sequentially assigned” has several interpretations. This testing methodology uses the following 

interpretation: order within the Transaction is not important; however, when rearranged and viewed in numeric order, the values 

must be sequential and incremented by 1.

t10. Clarification-XML Schema. The structural formatting of XML elements is best described using the XML Schema. Therefore, 

most structural NIEM requirements are tested using XML Schema Validation. This includes presence, cardinality, and ordering of 

elements and their child elements within the transaction. If discrepancies or errors are discovered in the XML Schema, a modified 

version will be developed and released to assist in conformance testing for XML structural requirements. Any exceptions to this 

approach will be documented as a separate assertion in the CTMF and associated CTM documents.

t11. Clarification-Image Requirements. This test note gathers the information found in various sections of AN-2013 regarding the 

valid constraints for resolution and compression algorithm values for the various image-type records, in an attempt to clarify the 

requirements. References are provided below the tables indicating the sections of the standard that were referenced to derive the 

information. Text shown in red indicates interpretations for values not specified in AN-2013. An explanation of these interpretations 

is provided below each table. For Type-10, the Character Type allowed should be Alphabetic, not Alphanumeric, because WSQ20 is 

not allowed. See Valid Image Resolution and Compression Values.

t12. Exception-Paths. For fields specifying paths (circles, ellipses, or open or closed paths) defined in Section 7.7.12 of AN-2013, there 

may be requirements regarding the structure of the vertices or points that are not addressed by the CTMF. See also: Test Exceptions.

t13. Discrepancy-Type-10 Oral Data. This test note addresses discrepancies in Sections 8.10.44 and B.2.6, and indicates the approach 

used by this version of the CTMF to address these issues. Field 10.048 has varying definitions among section B.2.6, Table 58, 

Section 8.10.44, and the XML Schema. The value of 10.048-PARC depends upon the text of ANSI/ADA Standard No. 1077 –

Dental Biometric Descriptors, which was in the process of being published when the CTMF was published. Therefore, Character 

Type and Value Constraint assertions are not defined and Occurrence Max# is 1 for 10.048-PARC in the CTMF. Also, 10.048-

PADT is treated as D↑ in this version of the CTMF based upon the description that it “shall appear in a subfield if PARC is not 

present in the subfield”. The XML encoding is treated such that biom:PatternedInjuryDetail may repeat and contain optional PARC 

and PADT elements to match Traditional encoding. 
12

t14. Discrepancy explanations. This test note indicates that there is a discrepancy among two or more sections of the standard text. In 

these cases, an assumption must be made regarding how the requirement should be implemented. These discrepancies and the 

assumptions made in this CTFM are listed below. 

Table D.4 – Standard Discrepancies and CTFM Assumptions

Standard Discrepancies and CTFM Assumptions

Standard 

Reference(s)

Description CTFM Assumption Justification

8.9.7.31 The TPD value description in 8.9.7.31 does not 

allow 85 or 86 even though WC indicates wrist 

or bracelet. Also, the statement is unclear as 

written because there is an overlap in the FPP 

values allowed: 21, 23, 26, and 28. 

1.) The palm codes should 

include 85 and 86 

2.) If ALL FGP values contain 

EXCLUSIVE palm codes (not 

the overlap) then TPD is 

limited to RLC, PTC, DTC, 

WC or PDC. And if ALL FGP 

values contain EXCLUSIVE 

finger codes (not the 

overlap) then TPD is limited 

to DIP, PIP or PDC. 

Otherwise, any Table46 

value is valid.

WC indicates wrist or wrist bracelet, so 

values 85 and 86 should be allowed.

There are multiple FGP instances 

allowed, so in order to restrict the TPD 

value, all of the FGP instances must 

indicate the same type of code (palm 

or finger). Otherwise, the TPD could 

be referring to any type and therefore 

any code should be allowed.

8.10.45,

Table 58

There are several issues with the Char Count 

and Occurrence values indicated in Table 58 for 

information items in Field 10.049. These issues 

are related to information items which make 

use of “lists of values” using the ‘|’ character to 

separate values. 

I.) For 10.049-ULCL and 

10.049-LLCL:

Min/Max Characters are 1 

to 2 (XML) and 1 to 19 

(Traditional). 

Max# Occurrences is 5 

(XML) and 1 (Traditional). 

II.) For 10.049-LPPL:

Min/Max Characters are 1 

to 2 (XML) and 1 to 38 

(Traditional)

Because XML does not use the list of 

values format, the Character Min# and 

Max# and Occurrences are different 

for the two encodings.
13

Max# Occurrences is 3 

(XML) and 1 (Traditional)

III.) For 10.049-LPPL:

Min/Max Characters are 1 

(XML) and 1 to 5 

(Traditional)

Max# Occurrences is 3 

(XML) and 1 (Traditional)

8.10.45 The description for 10.049-LPCT states that 

LPCT is “mandatory if LPCL contains the value 

O”; however, LPCL is not defined in the 

standard

LPCT is mandatory if either 

ULCL or LLCL contain O

LPCL seems to have been split into two 

fields (ULCL and LLCL) but the 

reference to LPCL was not removed. 

8.10.45 Many of the information items in Field 10.049 

should be dependent based upon their 

descriptions in Section 8.10.45, but they are 

listed as optional.

The following information 

items Cond Code are 

treated as Dependent 

rather than optional:

10.049-LPCT, 10.049-LPPT, 

10.049-LPST, 10.049-LPMT

The description text in Section 8.10.45 

indicates these values should be 

Dependent. 

8.10.46 In Field 10.050, “visual image comparison 

descriptive text” is sometimes referred to as 

VICD and sometimes VICT. 

“visual image comparison 

descriptive text” in 10.050 

is 10.050-VICD.

VICD was chosen over VICT because it 

was used more frequently. 

8.10.46,

Table 58

The description for Field 10.050 states that 

“This field shall only be used if Field 10.003: 

Image type / IMT has a value of EXTRAORAL or 

INTRAORAL.” This indicates Dependent, but the 

field is listed as Optional in Table 58. 

10.050 is Dependent The description text in Section 8.10.46 

indicates that the field should be 

Dependent. 

8.10.46,

Table 58

Two information items in Field 10.050 should 

be optional based upon their descriptions in 

10.050-VIDT and 10.050-

VICD are Optional.

The description text in Section 8.10.46 

does not indicate that there are any 
14

Section 8.10.46, but they are listed as 

dependent in Table 58.

dependencies for 10.050-VIDT or 

10.050-VICD to be present. 

8.10.47,

Table 58

All information items in Field 10.051 should be 

optional based upon their descriptions in 

Section 8.10.47, but they are listed as 

dependent in Table 58.

10.051-RSU, 10.051-RSM, 

and 10.051-RSO are 

Optional.

The description text in Section 8.10.47 

does not indicate that there are any 

dependencies for 10.051-VRSU, 

10.051-RSM, and 10.051-RSO to be 

present. 

Table 90 The lower bounds for Field 13.015-RHC and 13.015-

BVC should be "greater than", not "greater than 

equal to". Type-13 is the only record type that 

contains the "greater than equal to" lower-bounds

restriction for THC and BVC; all other records contain 

"greater than".

The constraint for 13.015-

RHC is: LHC < RHC <= HLL.

The constraint for 13.015-

BVC is: TVC < BVC <= VLL

Type-13 is the only record type that 

contains the "greater than equal to" lowerbounds restriction for THC and BVC; all 

other records contain "greater than". This 

appears to be a typo.

Table 92 Field 14.021-LHC should use less than (<) for the 

upper bound, not less than equal to (=<). 

0 <= LHC < HLL This is based upon note #215 and is 

consistent with other record types.

[er|

Table 92

Fields 14.023 and 14.024 Subfields should have an 

Occurrence Max# of 9 according to Section 7.7.7 (and 

not 5 as shown in the table).

9 Subfields is the correct 

upper limit, not 5. 

Section 7.7.7, which is text-based, 

takes precedence over the conflicting 

table data in Table 92 regarding the 

number of Subfields allowed for Fields 

14.023 an 14.024 |er]

Table 100 xx.992-T2C is a common Optional field. For 18.992 

the text states the field is optional, but the record 

layout tables list them as mandatory. 

18.992 is Optional All other xx.992-T2C fields are optional in 

all other cases; therefore, it seems that the 

record layout table for Types 18 is 

incorrect.

8.22.5, 

Table 111, 

Annex G, 

XML Schema

Table 111 and Annex G both indicate that Field 

22.006 is Mandatory. 

However, Section 8.22.5 reads “This optional 

field may be used ... if this record contains an 

image of a human body.”

Field 22.006 is Optional. Field 22.006 is optional because Type22 is not required to contain a bodytype image.

Table 113 98.900-IID has a minimum character count of 15 in 

Table 113, but section 8.23.8 shows examples with 

shorter character counts. 

98.900-IID has a maximum character count of 30 in 

Table 113, but some fields allow unlimited subfields, 

which could increase the value of 98.900-IID beyond 

For 98.900-IID: 

Character Min#: 12

Character Max#: * 

(unlimited)

Some examples of valid values found in 

8.23.8 are shorter than the specified 

minimum, for example: 3,9.373,4,NA 

(which has 12). Also, some fields allow 

unlimited subfields, so the max should be 

extended beyond 30. Since it is unknown 
15

30 characters (for example 9.373 allows unlimited 

subfields).

how many characters will be needed, the 

max is unlimited. 

t15. Clarification-Field 20.016-NOP: 20.106-NOP is the only NOP instance in the standard that is optional. Because the number of 

HPO and VPO information items pairs is dependent upon NOP, it is unclear how many pairs are allowed when NOP is missing. This

CTMF assumes that if NOP is missing (meaning that no data is present for NOP, but its information item separator is still present), 

then no instances of HPO or VPO, nor their information item separators shall be present. 

t16. Clarification-Field 9.380: Several values in Field 9.380 are specified as having to be less than HLL or VLL. Values in 9.380 are 

expressed in 10 μm units, but HLL and VLL are specified in pixels, so the values are not comparable. The conversion is as follows, 

where X is the value specified in 10 μm units: X*500/2540 < HLL (or VLL). This conversion was created using the 500ppi 

requirement (see 8.9.7.0.1: “In all cases for the EFS...distances are stated in terms...of pixels at 500 pixels per inch”) and the 

number of times 10 μm will divide into an inch (2540).

t17. Clarification-Field 11.033-COM: The standard lists the Character Min# for 11.033-COM as 0. However, by definition, if an 

information item is present, it must have data. The CTMF assumes the minimum Character Min# is therefore 1. Note, however, that 

this does not affect the ability of the user to omit 11.033-COM. This is a clarification that information items without data are 

considered to be not present. 

t18. [er| Clarification-Field xx.902-PRO: Section 7.4.1 (note 20) states that the upper bound of 255 has been removed, even though not 

all of the record layout tables reflect this change (namely Type-12, Type-13, Type-14, Type-15, Type-16, Type-17, Type-18, Type19, Type-20, and Type-21). |er]
16

D.1.1 Valid Image Resolution and Compression Algorithm Value Tables

In the tables below, “Valid” indicates the value is valid, “X” indicates the value is invalid, and “Legacy” indicates that the value is valid 

only for legacy systems.

Type-4 Images

Type-4 images may only be used at the 500ppi transmitting resolution class, and only WSQ20 may be used for compression. JPEGB and JPEGL 

are allowed as legacy values. Type-4 is subject to tolerance for resolution values. 

Figure D.5: Type-4 Image Constraints

Compression Algorithm

NONE 

(0)

WSQ2

0

(1)

JPEGB

(2)

JPEGL

(3)

JP2

(4)

JP2L

(5)

PNG

(6)

Transmitting 

Resolution

500 ppi Valid Valid Legacy Legacy X X X

Unspecified Valid Valid Legacy Legacy X X X

Figure D.6: Type-4 Resolution Constraints

Resolution Min Max Tolerance

Transmitting 500 ppi 500 ppi 2%

Scanning 500 ppi Unbounded* 2%

*Must be transmitted at 500ppi.

References:

 Only CGA values of NONE and WSQ20 (0 and 1) are valid for 500ppi as stated in 7.7.9.1.

 CGA values JPEGB and JPEGL are legacy for 500 ppi only as stated in 7.7.9.1.
17

 The same CGA constraints apply to unspecified resolutions because section 7.7.6 states that Record Type-4 shall not be used for 

anything but the 500 ppi class.

 Exemplar friction ridge images have a minimum scanning resolution of 500 ppi as stated in 7.7.6.2.1

 The transmitting resolution may only be 500 ppi as stated in 8.1.12. 

Interpretations:

 The tolerance for fingerprint types is either 1% or 2% as specified in 7.7.6.1. This is dependent upon the FAP value, which is not available 

in Type-4 records. Therefore, 2% tolerance is assumed because it is the least restrictive. 
18

Type-10 Images

Type-10 compression algorithm constraints are different for face and non-face types, and are independent of the resolution value. Specific 

resolution values constraints are not defined for Type-10 records. 

Figure D.7: Type-10 Image Constraints

Compression Algorithm

NON

E

WSQ2

0

JPEGB JPEGL JP2 JP2L PNG

Any Transmitting Resolution

SAP Value (Face Only)

< 30 Valid X Valid Valid Valid Valid Valid

30 or 32 Valid X Valid Valid X X X

>= 40 Valid X X X Valid Valid X

Unspecified Valid X Valid Valid Valid Valid Valid

Non

Face

Type

Valid X Valid Valid Valid Valid Valid

Figure D.8: Type-10 Resolution Constraints

Resolution Min Max Tolerance

Transmittin

g

Non-zero Unbounded None

Scanning Non-zero Unbounded None
19

References:

 Only CGA of JPEGB or JPEGL are valid for FACE types with SAP of 30 or 32 as specified in E.6.1.

 Only CGA of JP2 or JP2L are valid for FACE types with SAP of 40 or greater as specified in E.6.1.

 The only invalid CGA value for non-FACE types is WSQ20 as specified in 7.7.9.4.

Interpretations:

 CGA value NONE is valid for all image types. 

 Since no statement is made concerning SAP values < 30, it is assumed that any CGA values (except the fingerprint format WSQ20) are 

valid. 

 Since no statement is made concerning unspecified SAP values, it is assumed that any CGA values (except the fingerprint format 

WSQ20) are valid. 

 Since no resolution restrictions are made, it is assumed that a non-zero value must be present. 
20

Type-13 Images

Type-13 compression algorithm constraints depend upon the transmitting resolution. The minimum scanning resolution is 1000ppi and the 

minimum transmitting resolution is 500ppi. 

Figure D.9: Type-13 Image Constraints

Compression Algorithm

NONE WSQ2

0

JPEGB JPEGL JP2 JP2L PNG

Transmitting Resolution

500 ppi Valid X X Legacy X Valid Valid

1000 ppi Valid X X X X Valid X

>= 2000 ppi Valid X X X X Valid X

Unspecified Valid X X Legacy* X Valid Valid*

*Note that these cases apply only for 500 ppi resolution.

Figure D.10: Type-13 Resolution Constraints

Resolution Min Max Tolerance

Transmitting† 500 ppi Scanning 

Resolution

None

Scanning 1000 ppi Unbounded None

†

Increments by 100%
21

References:

 CGA of WSQ20, JPEGB, and JP2 are invalid for all resolutions, because they are excluded from Table 90 “Value Constraints” for 13.011-

CGA.

 Only CGA values NONE, JP2L, and PNG are valid for 500 ppi as stated in 7.7.9.1.

 CGA value JPEGL is legacy for 500 ppi only as stated in 7.7.9.1.

 Only CGA of JP2L is valid for 1000 ppi (if compressed) as stated in 7.7.9.1.

 Latent images shall have a minimum scanning resolution of 1000 ppi as stated in 7.7.6.2.2.

 The transmitting resolution has a minimum of 500 ppi and must not be greater than the scanning resolution (see 7.7.6.3.2).

 According to section 7.7.6.2.3, the transmitting resolution value for all friction ridge types (Types 4, 13, 14, 15, 19, and sometimes 16 and 

20) must be a member of the resolution migration path that starts at 500ppi and increments by 100%: (i.e.: 500ppi, 1000ppi, 2000ppi, 

4000ppi...). The scanning resolution does not necessarily follow the resolution migration path, but it must be scaled down or interpolated 

to achieve the proper value for transmission.

Interpretations:

 CGA value NONE is valid for all resolutions. 

 Since no statement is made regarding resolutions greater than 1000 ppi, it is assumed that the recommendations for 1000 ppi should 

apply for higher resolutions. 

 Since no statement is made regarding unspecified resolutions (when THPS/TVPS are aspect ratio for example), it is assumed that the 

values indicated in Table 90 are valid. JPEGL is treated as legacy. PNG is treated as a 500 ppi class image. 

 It is assumed that tolerance does not apply to Type-13. Section 7.7.6.1 indicates that fingerprint types are subject to a 1% or 2% 

tolerance, but Type-13 is not necessarily a fingerprint. 
22

Type-14 Images

Type-14 compression algorithm constraints depend upon the transmitting resolution. The minimum scanning and transmitting resolution is 500ppi. 

Type-14 is subject to a tolerance for the resolution values that depends on the FAP value. 

Figure D.11: Type-14 Image Constraints

Compression Algorithm

NONE WSQ20 JPEGB JPEGL JP2 JP2L PNG

Transmitting Resolution

500 ppi

Valid Valid Legacy Legacy X X X

1000 ppi

Valid X X X Valid Valid X

>= 2000 ppi

Valid X X X Valid Valid X

Unspecified

Valid Valid Legacy* Legacy* Valid Valid Valid

*Note that these cases apply only for 500 ppi resolution.
23

Figure D.12: Type-14 Resolution Constraints

Resolution Min Max Tolerance

Transmitting† 500 ppi Scanning 

Resolution

FAP Tolerance

10,20,30,40 2%

45, 50, 60 1%

Unspecified 2%

Scanning 500 ppi Unbounded

FAP Tolerance

10,20,30,40 2%

45, 50, 60 1%

Unspecified 2%

†

Increments by 100%

References:

 Only WSQ20 is valid for 500 ppi as stated in 7.7.9.1.

 CGA values JPEGB and JPEGL are legacy for 500 ppi only as stated in 7.7.9.1.

 Only CGA values of JP2 and JP2L are valid for 1000 ppi (if compressed) as stated in 7.7.9.1. 

 Exemplar friction ridge images have a minimum scanning resolution of 500 ppi as stated in 7.7.6.2.1

 The transmitting resolution has a minimum of 500 ppi and must not be greater than the scanning resolution (see 7.7.6.3.2).

 According to section 7.7.6.2.3, the transmitting resolution value for all friction ridge types (Types 4, 13, 14, 15, 19, and sometimes 16 and 

20) must be a member of the resolution migration path that starts at 500ppi and increments by 100%: (i.e.: 500ppi, 1000ppi, 2000ppi, 

4000ppi...). The scanning resolution does not necessarily follow the resolution migration path, but it must be scaled down or interpolated 

to achieve the proper value for transmission.

Interpretations:

 CGA value NONE is valid for all resolutions. 

 Since no statement is made regarding resolutions greater than 1000 ppi, it is assumed that the recommendations for 1000 ppi should 

apply for higher resolutions. 

 Since no statement is made regarding unspecified resolutions (when THPS/TVPS are aspect ratio for example), it is assumed that any 

compression algorithm value is valid. JPEGB and JPEGL are treated as legacy. 

 The tolerance for fingerprint types is either 1% or 2% as specified in 7.7.6.1. This is dependent upon the FAP value, which may not be 

defined (it is optional). Therefore, 2% tolerance is assumed when FAP is undefined because it is the least restrictive.
24

Type 15, 16, 19, and 20 Images

Note: Types 16 and 20 are only subject to the terms defined in this section if they contain friction ridge data. Friction ridge types 15 and 19 (and 

sometimes 16 and 20) have compression algorithm constraints that depend upon the transmitting resolution. The minimum scanning and 

transmitting resolution is 500ppi. These types are not subject to a tolerance for the resolution values.

Figure D.13: Types 15, 16, 19, and 20 Image Constraints

Compression Algorithm

NONE WSQ20 JPEGB JPEGL JP2 JP2L PNG

Transmitting Resolution

500 ppi

Valid Valid Legacy Legacy X X X

1000 ppi

Valid X X X Valid Valid X

>= 2000 ppi

Valid X X X Valid Valid X

Unspecified

Valid Valid Legacy* Legacy* Valid Valid Valid

*Note that these cases apply only for 500 ppi resolution.

Figure D.14: Types 15, 16, 19, and 20 Resolution Constraints

Resolution Min Max Tolerance

Transmitting† 500 ppi Scanning 

Resolution None

Scanning 500 ppi Unbounded None

†

Increments by 100%
25

References:

 Only WSQ20 is valid for 500 ppi as stated in 7.7.9.1.

 CGA values JPEGB and JPEGL are legacy for 500 ppi only as stated in 7.7.9.1.

 Only CGA values of JP2 and JP2L are valid for 1000 ppi (if compressed) as stated in 7.7.9.1.

 Exemplar friction ridge images have a minimum scanning resolution of 500 ppi as stated in 7.7.6.2.1

 The transmitting resolution has a minimum of 500 ppi and must not be greater than the scanning resolution (see 7.7.6.3.2).

 According to section 7.7.6.2.3, the transmitting resolution value for all friction ridge types (Types 4, 13, 14, 15, 19, and sometimes 16 and 

20) must be a member of the resolution migration path that starts at 500ppi and increments by 100%: (i.e.: 500ppi, 1000ppi, 2000ppi, 

4000ppi...). The scanning resolution does not necessarily follow the resolution migration path, but it must be scaled down or interpolated 

to achieve the proper value for transmission.

Interpretations:

 CGA value NONE is valid for all resolutions. 

 Since no statement is made regarding resolutions greater than 1000 ppi, it is assumed that the recommendations for 1000 ppi should 

apply for higher resolutions. 

 Since no statement is made regarding unspecified resolutions (when THPS/TVPS are aspect ratio for example), it is assumed that any 

compression algorithm value is valid. JPEGB and JPEGL are treated as legacy. 
26

Type-17 Images

Type-17 images have no restrictions on resolution values, and the compression algorithm values are not dependent on any other values in the 

record type.

Figure D.15: Type-17 Image Constraints

Compression Algorithm

NONE WSQ2

0

JPEGB JPEGL JP2 JP2L PNG

Transmitting 

Resolution

Any 

Resolution Valid X X X Valid Valid Valid

Figure D.16: Type-17 Resolution Constraints

Resolution Min Max Tolerance

Transmitting Non-zero Unbounded None

Scanning Non-zero Unbounded None

References:

 Only CGA values of NONE, JP2, JP2L, and PNG for any resolution value as stated in 7.7.9.2.

Interpretations:

 Since no resolution restrictions are made, it is assumed that a non-zero value must be present. 
27

D.2 Test Exceptions

An “exception” refers to any AN-2013 requirement that is not fully addressed by the CTMF. Table D.17 identifies and provides 

justification for all exceptions present in the tables. 

Table D.17- Exceptions Table

Exception Section Requirement Summary Justification

Domain 

Names / 

Application 

Profile 

Specifications

5.3.2 Data contained in this record shall conform in format and content to the 

specifications of the domain name(s) as listed in Field 1.013 Domain name / DOM 

found in the Type-1 record, if that field is in the transaction. The default domain is 

NORAM. Field 1.016 Application profile specifications / APS allows the user to 

indicate conformance to multiple specifications. If Field 1.016 is specified, the 

Type-2 record must conform to each of the application profiles. 

A DOM or APS reference uniquely identifies data contents and formats. Each 

domain and application profile shall have a point of contact responsible for 

maintaining this list. The contact shall serve as a registrar and maintain a 

repository including documentation for all of its common and user-specific Type-2 

data fields. As additional fields are required by specific agencies for their own 

applications, new fields and definitions may be registered and reserved to have a 

specific meaning. When this occurs, the domain or application profile registrar is 

responsible for registering a single definition for each number used by different 

members of the domain or application profile.

The format and content of the 

record are defined by the DOM 

or APS. Each DOM and APS has 

related record-content definitions 

that may be updated. The 

evolving nature of the DOM and 

APS definitions and nature of 

using registrars means that the 

requirements are not defined in 

the base standard, and therefore 

not included in the CTMF.2

6 An implementation domain, coded in Field 1.013 Domain name / DOM of a Type1 record as an optional field, is a group of agencies or organizations that have 

agreed to use pre-assigned data fields with specific meanings (typically in Record 

Type-2) for exchanging information unique to their installations. The 

implementation domain is usually understood to be the primary application profile 

of the standard.

New to this version of the standard, Field 1.016 Application profile specifications / 

APS allows multiple application profiles to be referenced. The organization 

responsible for the profile, the profile name and its version are all mandatory for 

each application profile specified. A transaction must conform to each profile that 

is included in this field. It is possible to use Field 1.016 and / or Field 1.013.

The “transaction must conform to 

each profile” included in the 

field, and those profiles are 

defined by the listed agency, 

which may be updated over time. 

The CTMF does not contain 

these requirements.

1

 

2 Requirements related to user, profile, or domain-specific information are not within the scope of the CTMF.
28

A specified implementation domain and specified application profiles must all 

have the same definition for fields, subfields and information items that are 

contained in the transaction.

Alternate

Character 

Sets

5.6,

Table 4

Field 1.015 Character encoding/DCS is an optional field that allows the user to 

specify an alternate character encoding... Field 1.015 Character encoding/DCS 

contains three information items: the character encoding set index/ CSI, the 

character encoding sent name/CSN, and the character encoding set version/CSV. 

The first two items are selected from the appropriate columns of Table 2.

Table 4 lists ASCII, UTF-16, 

UTF-8, and UTF-32 as possible 

encodings. However, the table 

also allows “User-defined” 

character encoding sets.

Requirements related to the use 

of alternate character sets may 

not be specifically defined in the 

CTMF.1

Alternate 

Coordinate 

System

7.7.3,

Table 6

The ninth information item is the geodetic datum code / GDC10. It is an 

alphanumeric value of 3 to 6 characters in length. This information item is used to 

indicate which coordinate system was used to represent the values in information 

items 2 through 7. If no entry is made in this information item, then the basis for 

the values entered in the first eight information items shall be WGS84, the code 

for the World Geodetic Survey 1984 version - WGS 84 (G873). See Table 4 for 

values.

Table 6 lists 22 coordinate 

systems and the option to include 

“Other” types as well. It is not 

feasible for the CTMF to define

conformance to coordinate 

systems listed by the user under 

“Other”.1 The CTM lists 

requirements for conformance to 

WGS84 because it is the default 

coordinate system used in the 

base standard.

7.7.3 A fourteenth optional information item geographic coordinate other system 

identifier / OSI allows for other coordinate systems. This information items

specifies the system identifier. It is up to 10 characters in length. Examples are:

• MGRS (Military Grid Reference System)

• USNG (United States National Grid)

• GARS (Global Area Reference System)

• GEOREF (World Geographic Reference)

• LANDMARK (e.g. hydrant) and position relative to the landmark, for example: 

Landmark: hydrant 143 sector 5 Position: 5.2 meters directly E

A fifteenth optional information item is the geographic coordinate other system 

value / OCV. It shall only be present if OSI is present in the record and 

OSI is set to LANDMARK. OCV is free text and may be up to 126 characters.

While some examples of other 

coordinate systems are listed in 

the standard (MGRS, USNG, 

GARS, GEOREF, 

LANDMARK), those values are 

not all-inclusive, and the user 

may indicate other coordinate 

systems that are not listed.1
29

Subject 

Acquisition 

Profiles

SAP/FAP/IAP

7.7.5,

Table 

10, 

Table11,

Table 12

A subject acquisition profile is used to describe a set of characteristics concerning 

the capture of the biometric sample. These profiles have mnemonics SAP for face, 

FAP for fingerprints and IAP for iris records.

The CTMF does not define 

requirements for testing if the 

image was captured under the 

conditions specified by the SAP, 

FAP, or IAP level as defined in 

Tables 10 through 13. However, 

requirements for valid profile 

level values are defined.

[er| Removed exception regarding polygons and ASEG. |er]