ANNEX 39

EXCHANGES OF DNA, FINGERPRINTS AND VEHICLE REGISTRATION DATA

CHAPTER 0

GENERAL PROVISIONS

Article 1 Aim The aim of this Annex is to lay down the necessary data protection, administrative and technical provisions for the implementation of Title II of Part Three of this Agreement.

Article 2 Technical specifications States shall observe common technical specifications in connection with all requests and answers related to searches and comparisons of DNA profiles, dactyloscopic data and vehicle registration data. These technical specifications are laid down in Chapters 1 to 3.

Article 3 Communications network The electronic exchange of DNA data, dactyloscopic data and vehicle registration data between States shall take place using the Trans European Services for Telematics between Administrations (TESTA II) communications network and further developments thereof.

Article 4 Availability of automated data exchange States shall take all necessary measures to ensure that automated searching or comparison of DNA data, dactyloscopic data and vehicle registration data is possible 24 hours a day and seven days a week. In the event of a technical fault, the States' national contact points shall immediately inform each other and shall agree on temporary alternative information exchange arrangements in accordance with the legal provisions applicable. Automated data exchange shall be re-established as quickly as possible.

Article 5 Reference numbers for DNA data and dactyloscopic data The reference numbers referred to in Articles 529 and 533 of this Agreement shall consist of a combination of the following: (a) a code allowing the States, in the case of a match, to retrieve personal data and other information in their databases in order to supply it to one, several or all of the States in accordance with Article 536 of this Agreement; (b) a code to indicate the national origin of the DNA profile or dactyloscopic data; and (c) with respect to DNA data, a code to indicate the type of DNA profile.

Article 6 Principles of DNA data exchange 1. States shall use existing standards for DNA data exchange, such as the European Standard Set (ESS) or the Interpol Standard Set of Loci (ISSOL). 2. The transmission procedure, in the case of automated searching and comparison of DNA profiles, shall take place within a decentralised structure. 3. Appropriate measures shall be taken to ensure confidentiality and integrity of data being sent to other States, including their encryption. 4. States shall take the necessary measures to guarantee the integrity of the DNA profiles made available or sent for comparison to the other States and to ensure that those measures comply with international standards such as ISO 17025. 5. States shall use State codes in accordance with the ISO 3166-1 alpha-2 standard.

Article 7 Rules for requests and answers in connection with DNA data 1. A request for an automated search or comparison, as referred to in Article 530 or 531 of this Agreement, shall include only the following information: (a) the State code of the requesting State; (b) the date, time and indication number of the request; (c) DNA profiles and their reference numbers; (d) the types of DNA profiles transmitted (unidentified DNA profiles or reference DNA profiles); and (e) information required for controlling the database systems and quality control for the automatic search processes. 2. The answer (matching report) to the request referred to in paragraph 1 shall contain only the following information: (a) an indication as to whether there were one or more matches (HITs) or no matches (No-HITs); (b) the date, time and indication number of the request; (c) the date, time and indication number of the answer; (d) the State codes of the requesting and requested States; (e) the reference numbers of the requesting and requested States; (f) the type of DNA profiles transmitted (unidentified DNA profiles or reference DNA profiles); (g) the requested and matching DNA profiles; and (h) information required for controlling the database systems and quality control for the automatic search processes. 3. Automated notification of a match shall only be provided if the automated search or comparison has resulted in a match of a minimum number of loci. That minimum is set out in Chapter 1. 4. The States shall ensure that requests comply with declarations issued pursuant to Article 529(3) of this Agreement.

Article 8 Transmission procedure for automated searching of unidentified DNA profiles in accordance with Article 530 1. If, in a search with an unidentified DNA profile, no match has been found in the national database or a match has been found with an unidentified DNA profile, the unidentified DNA profile may then be transmitted to all other States' databases and if, in a search with this unidentified DNA profile, matches are found with reference DNA profiles and/or unidentified DNA profiles in other States' databases, these matches shall be automatically communicated and the DNA reference data transmitted to the requesting State; if no matches can be found in other States' databases, it shall be automatically communicated to the requesting State. 2. If, in a search with an unidentified DNA profile, a match is found in other States' databases, each State concerned may insert a note to that effect in its national database.

Article 9 Transmission procedure for automated search of reference DNA profiles in accordance with Article 530 If, in a search with a reference DNA profile, no match has been found in the national database with a reference DNA profile or a match has been found with an unidentified DNA profile, this reference DNA profile may then be transmitted to all other States' databases and if, in a search with this reference DNA profile, matches are found with reference DNA profiles and/or unidentified DNA profiles in other States' databases, these matches shall be automatically communicated and the DNA reference data transmitted to the requesting State; if no matches can be found in other States' databases, it shall be automatically communicated to the requesting State.

Article 10 Transmission procedure for automated comparison of unidentified DNA profiles in accordance with Article 531 1. If, in a comparison with unidentified DNA profiles, matches are found in other States' databases with reference DNA profiles and/or unidentified DNA profiles, these matches shall be automatically communicated and the DNA reference data transmitted to the requesting State. 2. If, in a comparison with unidentified DNA profiles, matches are found in other States' databases with unidentified DNA profiles or reference DNA profiles, each State concerned may insert a note to that effect in its national database.

Article 11 Principles for the exchange of dactyloscopic data 1. The digitalisation of dactyloscopic data and their transmission to the other States shall be carried out in accordance with the uniform data format specified in Chapter 2. 2. Each State shall ensure that the dactyloscopic data it transmits are of sufficient quality for a comparison by the automated fingerprint identification systems (AFIS). 3. The transmission procedure for the exchange of dactyloscopic data shall take place within a decentralised structure. 4. Appropriate measures shall be taken to ensure the confidentiality and integrity of dactyloscopic data being sent to other States, including their encryption. 5. The States shall use State codes in accordance with the ISO 3166-1 alpha-2 standard.

Article 12 Search capacities for dactyloscopic data 1. Each State shall ensure that its search requests do not exceed the search capacities specified by the requested State. The United Kingdom shall declare their maximum search capacities per day for dactyloscopic data of identified persons and for dactyloscopic data of persons not yet identified. 2. The maximum numbers of candidates accepted for verification per transmission are set out in Chapter 2.

Article 13 Rules for requests and answers in connection with dactyloscopic data 1. The requested State shall check the quality of the transmitted dactyloscopic data without delay by a fully automated procedure. Should the data be unsuitable for an automated comparison, the requested State shall inform the requesting State without delay. 2. The requested State shall conduct searches in the order in which requests are received. Requests shall be processed within 24 hours by a fully automated procedure. The requesting State may, if its domestic law so prescribes, ask for accelerated processing of its requests and the requested State shall conduct these searches without delay. If deadlines cannot be met for reasons of force majeure, the comparison shall be carried out without delay as soon as the impediments have been removed.

Article 14 Principles of automated searching of vehicle registration data 1. For automated searching of vehicle registration data States shall use a version of the European Vehicle and Driving Licence Information System (Eucaris) software application especially designed for the purposes of Article 537 of this Agreement, and amended versions of that software. 2. Automated searching of vehicle registration data shall take place within a decentralised structure. 3. The information exchanged via the Eucaris system shall be transmitted in encrypted form. 4. The data elements of the vehicle registration data to be exchanged are specified in Chapter 3. 5. In the implementation of Article 537 of this Agreement, States may give priority to searches related to combating serious crime.

Article 15 Costs Each State shall bear the costs arising from the administration, use and maintenance of the Eucaris software application referred to in Article 14(1).

Article 16 Purpose 1. Processing of personal data by the receiving State shall be permitted solely for the purposes for which the data have been supplied in accordance with Title II of Part Three of this Agreement. Processing for other purposes shall be permitted solely with the prior authorisation of the State administering the file and subject only to the domestic law of the receiving State. Such authorisation may be granted provided that processing for such other purposes is permitted under the domestic law of the State administering the file. 2. Processing of data supplied pursuant to Articles 530, 531 and 534 of this Agreement by the searching or comparing State shall be permitted solely in order to: (a) establish whether the compared DNA profiles or dactyloscopic data match; (b) prepare and submit a police or judicial request for legal assistance in compliance with domestic law if those data match; (c) record within the meaning of Article 19 of this Chapter. 3. The State administering the file may process the data supplied to it in accordance with Articles 530, 531 and 534 of this Agreement solely where this is necessary for the purposes of comparison, providing automated replies to searches or recording pursuant to Article 19 of this Chapter. The supplied data shall be deleted immediately following data comparison or automated replies to searches unless further processing is necessary for the purposes referred to in points (b) and (c) of paragraph 2 of this Article. 4. Data supplied in accordance with Article 537 of this Agreement may be used by the State administering the file solely where this is necessary for the purpose of providing automated replies to search procedures or recording pursuant to Article 19 of this Chapter. The data supplied shall be deleted immediately following automated replies to searches unless further processing is necessary for recording pursuant to Article 19 of this Chapter. The Member State may use data received in a reply solely for the procedure for which the search was made.

Article 17 Accuracy, current relevance and storage time of data 1. The States shall ensure the accuracy and current relevance of personal data. The receiving State shall be notified without delay if it transpires ex officio, or from a notification by the data subject, that incorrect data or data which should not have been supplied have been supplied. The State(s) concerned shall be obliged to correct or delete the data. Moreover, personal data supplied shall be corrected if they are found to be incorrect. If the receiving body has reason to believe that the supplied data are incorrect or should be deleted, the supplying body shall be informed forthwith. 2. Data, the accuracy of which the data subject contests and the accuracy or inaccuracy of which cannot be established shall, in accordance with the domestic law of the States, be marked with a flag at the request of the data subject. If a flag exists, this may be removed subject to the domestic law of the States and only with the permission of the data subject or on the basis of a decision of the competent court or independent data protection authority. 3. Personal data supplied which should not have been supplied or received shall be deleted. Data which are lawfully supplied and received shall be deleted: (a) if they are not or no longer necessary for the purpose for which they were supplied; if personal data have been supplied without request, the receiving body shall immediately check if they are necessary for the purposes for which they were supplied; (b) following the expiry of the maximum period for keeping data laid down in the domestic law of the supplying State, where the supplying body informed the receiving body of that maximum period at the time of supplying the data. 4. Where there is reason to believe that deletion would prejudice the interests of the data subject, the data shall be blocked instead of being deleted in compliance with domestic law. Blocked data may be supplied or used solely for the purpose which prevented their deletion.

Article 18 Technical and organisational measures to ensure data protection and data security 1. The supplying and receiving bodies shall take steps to ensure that personal data is effectively protected against accidental or unauthorised destruction, accidental loss, unauthorised access, unauthorised or accidental alteration and unauthorised disclosure. 2. The features of the technical specification of the automated search procedure are regulated in the implementing measures as referred to in Article 539 of this Agreement which guarantee that: (a) state-of-the-art technical measures are taken to ensure data protection and data security, in particular data confidentiality and integrity; (b) encryption and authorisation procedures recognised by the competent authorities are used when having recourse to generally accessible networks; and (c) the admissibility of searches in accordance with paragraphs 2, 5 and 6 of Article 19 of this Chapter can be checked.

Article 19 Logging and recording: special rules governing automated and non-automated supply 1. Each State shall guarantee that every non-automated supply and every non-automated receipt of personal data by the body administering the file and by the searching body is logged in order to verify the admissibility of the supply. Logging shall contain the following information: (a) the reason for the supply; (b) the data supplied; (c) the date of the supply; and (d) the name or reference code of the searching body and of the body administering the file. 2. The following shall apply to automated searches for data based on Articles 530, 534 and 537 of this Agreement and to automated comparison pursuant to Article 531 of this Agreement: (a) only specially authorised officers of the national contact points may carry out automated searches or comparisons; the list of officers authorised to carry out automated searches or comparisons shall be made available upon request to the supervisory authorities referred to in paragraph 6 and to the other States; (b) each State shall ensure that each supply and receipt of personal data by the body administering the file and the searching body is recorded, including notification of whether or not a HIT exists; recording shall include the following information: (i) the data supplied; (ii) the date and exact time of the supply; and (iii) the name or reference code of the searching body and of the body administering the file. 3. The searching body shall also record the reason for the search or supply as well as an identifier for the official who carried out the search and the official who ordered the search or supply. 4. The recording body shall immediately communicate the recorded data upon request to the competent data protection authorities of the relevant State at the latest within four weeks following receipt of the request; recorded data may be used solely for the following purposes: (a) monitoring data protection; (b) ensuring data security. 5. The recorded data shall be protected with suitable measures against inappropriate use and other forms of improper use and shall be kept for two years. After the conservation period, the recorded data shall be deleted immediately. 6. Responsibility for legal checks on the supply or receipt of personal data lies with the independent data protection authorities or, as appropriate, the judicial authorities of the respective States. Anyone can request those authorities to check the lawfulness of the processing of data in respect of their person in compliance with domestic law. Independently of such requests, those authorities and the bodies responsible for recording shall carry out random checks on the lawfulness of supply, based on the files involved. 7. The results of such checks shall be kept for inspection for 18 months by the independent data protection authorities. After that period, they shall be immediately deleted. Each data protection authority may be requested by the independent data protection authority of another State to exercise its powers in accordance with domestic law. The independent data protection authorities of the States shall perform the inspection tasks necessary for mutual cooperation, in particular by exchanging relevant information.

Article 20 Data subjects' rights to damages Where a body of one State has supplied personal data under Title II of Part Three of this Agreement, the receiving body of the other State cannot use the inaccuracy of the data supplied as grounds to evade its liability vis-à-vis the injured party under domestic law. If damages are awarded against the receiving body because of its use of inaccurate transfer data, the body which supplied the data shall refund the amount paid in damages to the receiving body in full.

Article 21 Information requested by the States The receiving State shall inform the supplying State on request of the processing of supplied data and the result obtained.

Article 22 Declarations and designations 1. The United Kingdom shall communicate its declarations pursuant to Article 529(3) of this Agreement, and Article 12(1) of this Chapter, as well as its designations pursuant to Articles 535(1) and 537(3) of this Agreement to the Specialised Committee on Law Enforcement and Judicial Cooperation. 2. Factual information provided by the United Kingdom through these declarations and designations, and by Member States in accordance with Article 539(3) of this Agreement, are included in the Manual as referred to in Article 18(2) of Decision 2008/616/JHA. 3. States may amend declarations and designations submitted in accordance with paragraph 1 at any time by means of a notification submitted to the Specialised Committee on Law Enforcement and Judicial Cooperation. The Specialised Committee on Law Enforcement and Judicial Cooperation shall forward any declarations received to the General Secretariat of the Council. 4. The General Secretariat of the Council shall communicate any changes in the Manual referred to in paragraph 2 to the Specialised Committee on Law Enforcement and Judicial Cooperation.

Article 23 Preparation of decisions as referred to in Article 540 1. The Council shall take a decision as referred to in Article 540 of this Agreement on the basis of an evaluation report which shall be based on a questionnaire. 2. With respect to the automated data exchange in accordance with Title II of Part Three of this Agreement, the evaluation report shall also be based on an evaluation visit and a pilot run that shall be carried out if required when the United Kingdom has informed the Specialised Committee on Law Enforcement and Judicial Cooperation that they have implemented the obligations imposed on them under Title II of Part Three of this Agreement and submit the declarations provided for in Article 22 of this Chapter. Further details of the procedure are set out in Chapter 4 of this Annex.

Article 24 Statistics and reporting 1. An evaluation of the administrative, technical and financial application of the data exchange pursuant to Title II of Part Three of this Agreement shall be carried out on a regular basis. The evaluation shall be carried out with respect to the data categories for which data exchange has started among the States concerned. The evaluation shall be based on reports of the respective States. 2. Each State shall compile statistics on the results of the automated data exchange. In order to ensure comparability, the model for statistics will be compiled by the relevant Council Working Group. These statistics will be forwarded annually to the Specialised Committee on Law Enforcement and Judicial Cooperation. 3. In addition, States will be requested on a regular basis not to exceed once per year to provide further information on the administrative, technical and financial implementation of automated data exchange as needed to analyse and improve the process. 4. Statistics and reporting made by Member States in accordance with Decisions 2008/615/JHA and 2008/616/JHA shall apply in relation to this Article.

CHAPTER 1

EXCHANGE OF DNA-DATA

1. DNA related forensic issues, matching rules and algorithms

1.1. Properties of DNA-profiles

The DNA profile may contain 24 pairs of numbers representing the alleles of 24 loci which are also used in the DNA-procedures of Interpol. The names of those loci are provided in the following table:

VWA TH01 D21S11 FGA D8S1179 D3S1358 D18S51 Amelogenin TPOX CSF1P0 D13S317 D7S820 D5S818 D16S539 D2S1338 D19S433 Penta D Penta E FES F13A1 F13B SE33 CD4 GABA

The seven grey loci in the top row are both the present ESS and the ISSOL.

Inclusion Rules:

The DNA-profiles made available by the States for searching and comparison as well as the DNA-profiles sent out for searching and comparison shall contain at least six full designated (1) loci and may contain additional loci or blanks depending on their availability. The reference DNA profiles shall contain at least six of the seven ESS of loci. In order to raise the accuracy of matches, all available alleles shall be stored in the indexed DNA profile database and be used for searching and comparison. Each State should implement as soon as practically possible any new ESS of loci adopted by the EU.

Mixed profiles are not allowed, so that the allele values of each locus will consist of only two numbers, which may be the same in the case of homozygosity at a given locus.

Wild-cards and Micro-variants are to be dealt with using the following rules:

— Any non-numerical value except amelogenin contained in the profile (e.g. "o", "f", "r", "na", "nr" or "un") has to be automatically converted for the export to a wild card (*) and searched against all,

— Numerical values "0", "1" or "99" contained in the profile have to be automatically converted for the export to a wild card (*) and searched against all,

— If three alleles are provided for one locus the first allele will be accepted and the remaining two alleles have to be automatically converted for the export to a wild card (*) and searched against all,

— When wild card values are provided for allele 1 or 2 then both permutations of the numerical value given for the locus will be searched (e.g. 12, * could match against 12,14 or 9,12),

— Pentanucleotide (Penta D, Penta E and CD4) micro-variants will be matched according to the following: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x.4 — x.4 = x.3, x.4, x + 1,

— Tetranucleotide (the rest of the loci are tetranucleotides) micro-variants will be matched according to the following: — x.1 = x, x.1, x.2 — x.2 = x.1, x.2, x.3 — x.3 = x.2, x.3, x + 1.

1.2. Matching rules

The comparison of two DNA-profiles will be performed on the basis of the loci for which a pair of allele values is available in both DNA-profiles. At least six full designated loci (exclusive of amelogenin) must match between both DNA-profiles before a HIT response is provided.

A full match (Quality 1) is defined as a match, when all allele values of the compared loci commonly contained in the requesting and requested DNA-profiles are the same. A near match is defined as a match, when the value of only one of all the compared alleles is different in the two DNA profiles (Quality 2, 3 and 4). A near match is only accepted if there are at least six full designated matched loci in the two compared DNA profiles.

The reason for a near match may be:

— a human typing error at the point of entry of one of the DNA-profiles in the search request or the DNA-database,

— an allele-determination or allele-calling error during the generation procedure of the DNA-profile.

1.3. Reporting rules

Full matches, near matches and "No-HITs" will all be reported.

The matching report will be sent to the requesting national contact point and will also be made available to the requested national contact point (to enable it to estimate the nature and number of possible follow-up requests for further available personal data and other information associated with the DNA-profile corresponding to the HIT in accordance with Article 536 of this Agreement.

2. State code number table

In accordance with Title II of Part Three of this Agreement, ISO 3166-1 alpha-2 code are used for setting up the domain names and other configuration parameters required in the Prüm DNA data exchange applications over a closed network.

ISO 3166-1 alpha-2 codes are the following two-letter State codes:

State names Code State names Code Belgium BE Lithuania LT Bulgaria BG Luxemburg LU Czech Republic CZ Hungary HU Denmark DK Malta MT Germany DE Netherlands NL Estonia EE Austria AT Ireland IE Poland PL Greece EL Portugal PT Spain ES Romania RO France FR Slovakia SK Croatia HR Slovenia SI Italy IT Finland FI Cyprus CY Sweden SE Latvia LV United Kingdom UK

3. Functional analysis

3.1. Availability of the system

Requests pursuant to Article 530 of this Agreement should reach the targeted database in the chronological order that each request was sent; responses should be dispatched to reach the requesting State within 15 minutes of the arrival of requests.

3.2. Second step

When a State receives a report of a match, its national contact point is responsible for comparing the values of the profile submitted as a question and the values of the profile(s) received as an answer to validate and check the evidential value of the profile. National contact points can contact each other directly for validation purposes.

Legal assistance procedures start after validation of an existing match between two profiles, on the basis of a "full match" or a "near match" obtained during the automated consultation phase.

4. DNA interface control document

4.1. Introduction

4.1.1. Objectives

This Chapter defines the requirements for the exchange of DNA profile information between the DNA database systems of all States. The header fields are defined specifically for the Prüm DNA exchange; the data part is based on the DNA profile data part in the XML schema defined for the Interpol DNA exchange gateway.

Data are exchanged by Simple Mail Transfer Protocol (SMTP) and other state-of-the-art technologies, using a central relay mail server provided by the network provider. The XML file is transported as mail body.

4.1.2. Scope

This ICD defines the content of the message (or "mail") only. All network-specific and mail-specific topics are defined uniformly in order to allow a common technical base for the DNA data exchange.

This includes:

— the format of the subject field in the message to enable/allow for an automated processing of the messages,

— whether content encryption is necessary and if yes which methods should be chosen,

— the maximum length of messages.

4.1.3. XML structure and principles

The XML message is structured into:

— the header part, which contains information about the transmission, and

— the data part, which contains profile specific information, as well as the profile itself.

The same XML schema shall be used for request and response.

For the purpose of complete checks of unidentified DNA profiles, as provided for in Article 531 of this Agreement, it shall be possible to send a batch of profiles in one message. A maximum number of profiles within one message must be defined. The number depends on the maximum allowed mail size and shall be defined after selection of the mail server.

XML example:

<?version="1.0" standalone="yes"?>

<PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<header>

(…)

</header>

<datas>

(…)

</datas>

[<datas> datas structure repeated, if multiple profiles sent by (…) a single SMTP message, only allowed for Article 531 of this Agreement cases

</datas>]

</PRUEMDNA>

4.2. XML structure definition

The following definitions are for documentation purposes and better readability; the real binding information is provided by an XML schema file (PRUEM DNA.xsd).

4.2.1. Schema PRUEMDNAx

It contains the following fields:

Fields Type Description header PRUEM_header Occurs: 1 datas PRUEM_datas Occurs: 1 … 500

4.2.2. Content of header structure

4.2.2.1. PRUEM header This is a structure describing the XML file header. It contains the following fields: Fields Type Description direction PRUEM_header_dir Direction of message flow ref String Reference of the XML file generator String Generator of XML file schema_version String Version number of schema to use requesting PRUEM_header_info Requesting State info requested PRUEM_header_info Requested State info

4.2.2.2. PRUEM_header dir Type of data contained in message, value can be: Value Description R Request A Answer

4.2.2.3. PRUEM header info Structure to describe State as well as message date/time. It contains the following fields: Fields Type Description source_isocode String ISO 3166-2 code of the requesting State destination_isocode String ISO 3166-2 code of the requested State request_id String unique Identifier for a request date Date Date of creation of message time Time Time of creation of message

4.2.3. Content of PRUEM Profile data

4.2.3.1. PRUEM_datas This is a structure describing the XML profile data part. It contains the following fields: Fields Type Description reqtype PRUEM request type Type of request (Article 530 or 531) date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of request agency String Name of corresponding unit responsible for the profile profile_ident String Unique State profile ID message String Error Message, if result = E profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (HIT) empty match_id String In case of a HIT PROFILE_ID of the requesting profile quality PRUEM_hitquality_type Quality of HIT hitcount Integer Count of matched Alleles rescount Integer Count of matched profiles. If direction = R (Request), then empty. If quality!=0 (the original requested profile), then empty.

4.2.3.2. PRUEM_request_type Type of data contained in message, value can be: Value Description 3 Requests pursuant to Article 530 4 Requests pursuant to Article 531

4.2.3.3. PRUEM_hitquality_type Value Description 0 Referring original requesting profile: Case "No-HIT": original requesting profile sent back only; Case "HIT": original requesting profile and matched profiles sent back. 1 Equal in all available alleles without wildcards 2 Equal in all available alleles with wildcards 3 HIT with Deviation (Microvariant) 4 HIT with mismatch

4.2.3.4. PRUEM_data_type Type of data contained in message, value can be: Value Description P Person profile S Stain

4.2.3.5. PRUEM_data_result Type of data contained in message, value can be: Value Description U Undefined, If direction = R (request) H HIT N No-HIT E Error

4.2.3.6. IPSG_DNA_profile Structure describing a DNA profile. It contains the following fields: Fields Type Description ess_issol IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile

4.2.3.7. IPSG_DNA_ISSOL Structure containing the loci of ISSOL (Standard Group of Interpol loci). It contains the following fields: Fields Type Description vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 d21s11 IPSG_DNA_locus Locus d21s11 fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 amelogenin IPSG_DNA_locus Locus amelogin

4.2.3.8. IPSG_DNA_additional_loci Structure containing the other loci. It contains the following fields: Fields Type Description tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 gaba IPSG_DNA_locus Locus gaba

4.2.3.9. IPSG_DNA_locus Structure describing a locus. It contains the following fields: Fields Type Description low_allele String Lowest value of an allele high_allele String Highest value of an allele

5. Application, security and communication architecture

5.1. Overview

In implementing applications for the DNA data exchange within the framework of Title II of Part Three of this Agreement, a common communication network shall be used, which will be logically closed among the States. In order to exploit this common communication infrastructure of sending requests and receiving replies in a more effective way, an asynchronous mechanism to convey DNA and dactyloscopic data requests in a wrapped SMTP e-mail message is adopted. In fulfilment of security concerns, the mechanism s/MIME as extension to the SMTP functionality will be used to establish a true end-to-end secure tunnel over the network.

The operational Trans European Services for Telematics between Administrations (TESTA) is used as the communication network for data exchange among the States. TESTA is under the responsibility of the European Commission. Taking into account that national DNA databases and the current national access points of TESTA may be located on different sites in the States, access to TESTA may be set up either by:

1. using the existing national access point or establishing a new national TESTA access point; or

2. setting up a secure local link from the site where the DNA database is located and managed by the competent national agency to the existing national TESTA access point.

The protocols and standards deployed in the implementation of Title II of Part Three of this Agreement applications comply with the open standards and meet the requirements imposed by national security policy makers of the States.

5.2. Upper Level Architecture

In the scope of Title II of Part Three of this Agreement, each State will make its DNA data available to be exchanged with and/or searched by other States in conformity with the standardised common data format. The architecture is based upon an any-to-any communication model. There exists neither a central computer server nor a centralised database to hold DNA profiles.

In addition to the fulfilment of domestic legal constraints at States' sites, each State may decide what kind of hardware and software should be deployed for the configuration at its site to comply with the requirements set out in Title II of Part Three of this Agreement.

5.3. Security Standards and Data Protection

Three levels of security concerns have been considered and implemented.

5.3.1. Data Level

DNA profile data provided by each State shall have to be prepared in compliance with a common data protection standard, so that requesting States will receive an answer mainly to indicate HIT or No-HIT along with an identification number in case of a HIT, which does not contain any personal information. The further investigation after the notification of a HIT will be conducted at bilateral level pursuant to the existing domestic legal and organisational regulations of the respective States' sites.

5.3.2. Communication Level

Messages containing DNA profile information (requesting and replying) will be encrypted by means of a state-of-the-art mechanism in conformity with open standards, such as s/MIME, before they are forwarded to the sites of other States.

5.3.3. Transmission Level

All encrypted messages containing DNA profile information will be forwarded onto other States' sites through a virtual private tunnelling system administered by a trusted network provider at the international level and the secure links to this tunnelling system under national responsibility. This virtual private tunnelling system does not have a connection point with the open Internet.

5.4. Protocols and Standards to be used for encryption mechanism: s/MIME and related packages

The open standard s/MIME as extension to de facto e-mail standard SMTP will be deployed to encrypt messages containing DNA profile information. The protocol s/MIME (V3) allows signed receipts, security labels, and secure mailing lists and is layered on Cryptographic Message Syntax (CMS), an Internet Engineering Task Force (IETF) specification for cryptographic protected messages. It can be used to digitally sign, digest, authenticate or encrypt any form of digital data.

The underlying certificate used by the s/MIME mechanism has to be in compliance with X.509 standard. In order to ensure common standards and procedures with other Prüm applications, the processing rules for s/MIME encryption operations or to be applied under various Commercial Product of the Shelves (COTS) environments, are as follows:

— the sequence of the operations is: first encryption and then signing,

— the encryption algorithm AES (Advanced Encryption Standard) with 256 bit key length and RSA with 1024 bit key length shall be applied for symmetric and asymmetric encryption respectively,

— the hash algorithm SHA-1 shall be applied.

s/MIME functionality is built into the vast majority of modern e-mail software packages including Outlook, Mozilla Mail as well as Netscape Communicator 4.x and inter-operates among all major e-mail software packages.

Because of s/MIME's easy integration into national IT infrastructure at all States' sites, it is selected as a viable mechanism to implement the communication security level. For achieving the goal "Proof of Concept" in a more efficient way and reducing costs the open standard JavaMail API is however chosen for prototyping DNA data exchange. JavaMail API provides simple encryption and decryption of e-mails using s/MIME and/or OpenPGP. The intent is to provide a single, easy-to-use API for e-mail clients that want to send and receive encrypted e-mail in either of the two most popular e-mail encryption formats. Therefore any state-of-the-art implementations to JavaMail API will suffice for the requirements set by Title II of Part Three of this Agreement, such as the product of Bouncy Castle JCE (Java Cryptographic Extension), which will be used to implement s/MIME for prototyping DNA data exchange among all States.

5.5. Application Architecture

Each State will provide the other States with a set of standardised DNA profile data which are in conformity with the current common ICD. This can be done either by providing a logical view over individual national database or by establishing a physical exported database (indexed database).

The four main components: E-mail server/s/MIME, Application Server, Data Structure Area for fetching/feeding data and registering incoming/outgoing messages, and Match Engine implement the whole application logic in a product-independent way.

In order to provide all States with an easy integration of the components into their respective national sites, the specified common functionality has been implemented by means of open source components, which could be selected by each State depending on its national IT policy and regulations. Because of the independent features to be implemented to get access to indexed databases containing DNA profiles covered by Title II of Part Three of this Agreement, each State can freely select its hardware and software platform, including database and operating systems.

A prototype for the DNA Data Exchange has been developed and successfully tested over the existing common network. The version 1.0 has been deployed in the productive environment and is used for daily operations. States may use the jointly developed product but may also develop their own products. The common product components will be maintained, customised and further developed according to changing IT, forensic and/or functional police requirements.

5.6. Protocols and Standards to be used for application architecture:

5.6.1. XML

The DNA data exchange will fully exploit XML-schema as attachment to SMTP e-mail messages. The eXtensible Markup Language (XML) is a W3C-recommended general-purpose markup language for creating special-purpose markup languages, capable of describing many different kinds of data. The description of the DNA profile suitable for exchange among all States has been done by means of XML and XML schema in the ICD document.

5.6.2. ODBC

Open DataBase Connectivity provides a standard software API method for accessing database management systems and making it independent of programming languages, database and operating systems. ODBC has, however, certain drawbacks. Administering a large number of client machines can involve a diversity of drivers and DLLs. This complexity can increase system administration overhead.

5.6.3. JDBC

Java DataBase Connectivity (JDBC) is an API for the Java programming language that defines how a client may access a database. In contrast to ODBC, JDBC does not require to use a certain set of local DLLs at the Desktop.

The business logic of processing DNA profile requests and replies at each States' site is described in the following diagram. Both requesting and replying flows interact with a neutral data area comprising different data pools with a common data structure.

5.7. Communication Environment

5.7.1. Common Communication Network: TESTA and its follow-up infrastructure

The application DNA data exchange will exploit the e-mail, an asynchronous mechanism, to send requests and to receive replies among the States. As all States have at least one national access point to the TESTA network, the DNA data exchange will be deployed over the TESTA network. TESTA provides a number of added-value services through its e-mail relay. In addition to hosting TESTA specific e-mail boxes, the infrastructure can implement mail distribution lists and routing policies. This allows TESTA to be used as a clearing house for messages addressed to administrations connected to the EU wide Domains. Virus check mechanisms may also be put in place.

The TESTA e-mail relay is built on a high availability hardware platform located at the central TESTA application facilities and protected by firewall. The TESTA Domain Name Systems (DNS) will resolve resource locators to IP addresses and hide addressing issues from the user and from applications.

5.7.2. Security Concern

The concept of a Virtual Private Network (VPN) has been implemented within the framework of TESTA. Tag Switching Technology used to build this VPN will evolve to support Multi-Protocol Label Switching (MPLS) standard developed by the IETF.

MPLS is an IETF standard technology that speeds up network traffic flow by avoiding packet analysis by intermediate routers (hops). This is done on the basis of so-called labels that are attached to packet by the edge routers of the backbone, on the basis of information stored in the forwarding information base (FIB). Labels are also used to implement VPNs.

MPLS combines the benefits of layer 3 routing with the advantages of layer 2 switching. Because IP addresses are not evaluated during transition through the backbone, MPLS does not impose any IP addressing limitations.

Furthermore, e-mail messages over the TESTA will be protected by s/MIME driven encryption mechanism. Without knowing the key and possessing the right certificate, nobody can decrypt messages over the network.

5.7.3. Protocols and Standards to be used over the communication network

5.7.3.1. SMTP SMTP is the de facto standard for e-mail transmission across the Internet. SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified and then the message text is transferred. SMTP uses TCP port 25 upon the specification by the IETF. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS (Domain Name Systems) record is used. Since this protocol started as purely ASCII text-based it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. Today, most SMTP servers support the 8BITMIME and s/MIME extension, permitting binary files to be transmitted almost as easily as plain text. The processing rules for s/MIME operations are described in the section s/MIME (see Section 5.4). SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client shall use POP3 or IMAP. Within the framework of implementing DNA data exchange it is decided to use the protocol POP3.

5.7.3.2. POP Local e-mail clients use the Post Office Protocol version 3 (POP3), an application-layer Internet standard protocol, to retrieve e-mail from a remote server over a TCP/IP connection. By using the SMTP Submit profile of the SMTP protocol, e-mail clients send messages across the Internet or over a corporate network. MIME serves as the standard for attachments and non-ASCII text in e-mail. Although neither POP3 nor SMTP requires MIME-formatted e-mail, essentially Internet e-mail comes MIME-formatted, so POP clients must also understand and use MIME. The whole communication environment of Title II of Part Three of this Agreement will therefore include the components of POP.

5.7.4. Network Address Assignment

Operative environment

A dedicated block half B class subnet has currently been allocated by the European IP registration authority (RIPE) to TESTA. The assignment of IP addresses to States is based upon a geographical schema in Europe. The data exchange among States within the framework of Title II of Part Three of this Agreement is operated over a European wide logically closed IP network.

Testing Environment

In order to provide a smooth running environment for the daily operation among all connected States, it is necessary to establish a testing environment over the closed network for new States which prepare to join the operations. A sheet of parameters including IP addresses, network settings, e-mail domains as well as application user accounts has been specified and should be set up at the corresponding State's site. Moreover, a set of pseudo DNA profiles has been constructed for test purposes.

5.7.5. Configuration Parameters

A secure e-mail system is set up using the eu-admin.net domain. That domain with the associated addresses will not be accessible from a location not on the TESTA EU wide domain, because the names are only known on the TESTA central DNS server, which is shielded from the Internet.

The mapping of these TESTA site addresses (host names) to their IP addresses is done by the TESTA DNS service. For each Local Domain, a Mail entry will be added to this TESTA central DNS server, relaying all e-mail messages sent to TESTA Local Domains to the TESTA central Mail Relay. That TESTA central Mail Relay will then forward them to the specific Local Domain e-mail server using the Local Domain e-mail addresses. By relaying the e-mail in this way, critical information contained in e-mails will only pass the Europe-wide closed network infrastructure and not the insecure Internet.

It is necessary to establish sub-domains (bold italics) at the sites of all States upon the following syntax:

"application-type.State-code.pruem.testa.eu", where: "State-code" takes the value of one of the two letter-code State codes (i.e. AT, BE, etc.);

"application-type" takes one of the values: DNA, FP and CAR.

By applying the above syntax, the sub domains for the States are shown in the following table:

States' sub domains syntax State Sub Domains Comments BE dna.be.pruem.testa.eu fp.be.pruem.testa.eu car.be.pruem.testa.eu test.dna.be.pruem.testa.eu test.fp.be.pruem.testa.eu test.car.be.pruem.testa.eu BG dna.bg.pruem.testa.eu fp.bg.pruem.testa.eu car.bg.pruem.testa.eu test.dna.bg.pruem.testa.eu test.fp.bg.pruem.testa.eu test.car.bg.pruem.testa.eu CZ dna.cz.pruem.testa.eu fp.cz.pruem.testa.eu car.cz.pruem.testa.eu test.dna.cz.pruem.testa.eu test.fp.cz.pruem.testa.eu test.car.cz.pruem.testa.eu DK dna.dk.pruem.testa.eu fp.dk.pruem.testa.eu car.dk.pruem.testa.eu test.dna.dk.pruem.testa.eu test.fp.dk.pruem.testa.eu test.car.dk.pruem.testa.eu DE dna.de.pruem.testa.eu fp.de.pruem.testa.eu car.de.pruem.testa.eu test.dna.de.pruem.testa.eu test.fp.de.pruem.testa.eu test.car.de.pruem.testa.eu EE dna.ee.pruem.testa.eu fp.ee.pruem.testa.eu car.ee.pruem.testa.eu test.dna.ee.pruem.testa.eu test.fp.ee.pruem.testa.eu test.car.ee.pruem.testa.eu IE dna.ie.pruem.testa.eu fp.ie.pruem.testa.eu car.ie.pruem.testa.eu test.dna.ie.pruem.testa.eu test.fp.ie.pruem.testa.eu test.car.ie.pruem.testa.eu EL dna.el.pruem.testa.eu fp.el.pruem.testa.eu car.el.pruem.testa.eu test.dna.el.pruem.testa.eu test.fp.el.pruem.testa.eu test.car.el.pruem.testa.eu ES dna.es.pruem.testa.eu fp.es.pruem.testa.eu car.es.pruem.testa.eu test.dna.es.pruem.testa.eu test.fp.es.pruem.testa.eu test.car.es.pruem.testa.eu FR dna.fr.pruem.testa.eu fp.fr.pruem.testa.eu car.fr.pruem.testa.eu test.dna.fr.pruem.testa.eu test.fp.fr.pruem.testa.eu test.car.fr.pruem.testa.eu HR dna.hr.pruem.testa.eu fp.hr.pruem.testa.eu car.hr.pruem.testa.eu test.dna.hr.pruem.testa.eu test.fp.hr.pruem.testa.eu test.car.hr.pruem.testa.eu IT dna.it.pruem.testa.eu fp.it.pruem.testa.eu car.it.pruem.testa.eu test.dna.it.pruem.testa.eu test.fp.it.pruem.testa.eu test.car.it.pruem.testa.eu CY dna.cy.pruem.testa.eu fp.cy.pruem.testa.eu car.cy.pruem.testa.eu test.dna.cy.pruem.testa.eu test.fp.cy.pruem.testa.eu test.car.cy.pruem.testa.eu LV dna.lv.pruem.testa.eu fp.lv.pruem.testa.eu car.lv.pruem.testa.eu test.dna.lv.pruem.testa.eu test.fp.lv.pruem.testa.eu test.car.lv.pruem.testa.eu LT dna.lt.pruem.testa.eu fp.lt.pruem.testa.eu car.lt.pruem.testa.eu test.dna.lt.pruem.testa.eu test.fp.lt.pruem.testa.eu test.car.lt.pruem.testa.eu LU dna.lu.pruem.testa.eu fp.lu.pruem.testa.eu car.lu.pruem.testa.eu test.dna.lu.pruem.testa.eu test.fp.lu.pruem.testa.eu test.car.lu.pruem.testa.eu HU dna.hu.pruem.testa.eu fp.hu.pruem.testa.eu car.hu.pruem.testa.eu test.dna.hu.pruem.testa.eu test.fp.hu.pruem.testa.eu test.car.hu.pruem.testa.eu MT dna.mt.pruem.testa.eu fp.mt.pruem.testa.eu car.mt.pruem.testa.eu test.dna.mt.pruem.testa.eu test.fp.mt.pruem.testa.eu test.car.mt.pruem.testa.eu NL dna.nl.pruem.nl.testa.eu fp.nl.pruem.testa.eu car.nl.pruem.testa.eu test.dna.nl.pruem.testa.eu test.fp.nl.pruem.testa.eu test.car.nl.pruem.testa.eu AT dna.at.pruem.testa.eu fp.at.pruem.testa.eu car.at.pruem.testa.eu test.dna.at.pruem.testa.eu test.fp.at.pruem.testa.eu test.car.at.pruem.testa.eu PL dna.pl.pruem.testa.eu fp.pl.pruem.testa.eu car.pl.pruem.testa.eu test.dna.pl.pruem.testa.eu test.fp.pl.pruem.testa.eu test.car.pl.pruem.testa.eu PT dna.pt.pruem.testa.eu fp.pt.pruem.testa.eu car.pt.pruem.testa.eu test.dna.pt.pruem.testa.eu test.fp.pt.pruem.testa.eu test.car.pt.pruem.testa.eu RO dna.ro.pruem.testa.eu fp.ro.pruem.testa.eu car.ro.pruem.testa.eu test.dna.ro.pruem.testa.eu test.fp.ro.pruem.testa.eu test.car.ro.pruem.testa.eu SI dna.si.pruem.testa.eu fp.si.pruem.testa.eu car.si.pruem.testa.eu test.dna.si.pruem.testa.eu test.fp.si.pruem.testa.eu test.car.si.pruem.testa.eu SK dna.sk.pruem.testa.eu fp.sk.pruem.testa.eu car.sk.pruem.testa.eu test.dna.sk.pruem.testa.eu test.fp.sk.pruem.testa.eu test.car.sk.pruem.testa.eu FI dna.fi.pruem.testa.eu fp.fi.pruem.testa.eu car.fi.pruem.testa.eu test.dna.fi.pruem.testa.eu test.fp.fi.pruem.testa.eu test.car.fi.pruem.testa.eu SE dna.se.pruem.testa.eu fp.se.pruem.testa.eu car.se.pruem.testa.eu test.dna.se.pruem.testa.eu test.fp.se.pruem.testa.eu test.car.se.pruem.testa.eu UK dna.uk.pruem.testa.eu fp.uk.pruem.testa.eu car.uk.pruem.testa.eu test.dna.uk.pruem.testa.eu test.fp.uk.pruem.testa.eu test.car.uk.pruem.testa.eu

CHAPTER 2

EXCHANGE OF DACTYLOSCOPIC DATA (INTERFACE CONTROL DOCUMENT)

The purpose of the following document interface Control Document is to define the requirements for the exchange of dactyloscopic information between the Automated Fingerprint Identification Systems (AFIS) of the States. It is based on the Interpol-Implementation of ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b).

This version shall cover all basic definitions for Logical Records Type-1, Type-2, Type-4, Type-9, Type-13 and Type-15 required for image- and minutiæ-based dactyloscopic processing.

1. File Content Overview

A dactyloscopic file consists of several logical records. There are sixteen types of record specified in the original ANSI/NIST-ITL 1-2000 standard. Appropriate ASCII separation characters are used between each record and the fields and subfields within the records.

Only 6 record types are used to exchange information between the originating and the destination agency:

Type-1 → Transaction information Type-2 → Alphanumeric persons/case data Type-4 → High resolution greyscale dactyloscopic images Type-9 → Minutiæ Record Type-13 → Variable resolution latent image record Type-15 → Variable resolution palmprint image record

1.1. Type-1 — File header

This record contains routing information and information describing the structure of the rest of the file. This record type also defines the types of transaction which fall under the following broad categories:

1.2. Type-2 — Descriptive text

This record contains textual information of interest to the sending and receiving agencies.

1.3. Type-4 — High resolution greyscale image

This record is used to exchange high resolution greyscale (eight bit) dactyloscopic images sampled at 500 pixels/inch. The dactyloscopic images shall be compressed using the WSQ algorithm with a ratio of not more than 15:1. Other compression algorithms or uncompressed images shall not be used.

1.4. Type-9 — Minutiæ record

Type-9 records are used to exchange ridge characteristics or minutiæ data. Their purpose is partly to avoid unnecessary duplication of AFIS encoding processes and partly to allow the transmission of AFIS codes which contain less data than the corresponding images.

1.5. Type-13 — Variable-Resolution Latent Image Record

This record shall be used to exchange variable-resolution latent fingerprint and latent palmprint images together with textural alphanumerical information. The scanning resolution of the images shall be 500 pixels/inch with 256 grey-levels. If the quality of the latent image is sufficient it shall be compressed using WSQ-algorithm. If necessary the resolution of the images may be expanded to more than 500 pixels/inch and more than 256 grey-levels by mutual agreement. In that case, it is strongly recommended to use JPEG 2000 (see Appendix 39-7).

1.6. Variable-Resolution Palmprint Image Record

Type-15 tagged field image records shall be used to exchange variable-resolution palmprint images together with textural alphanumerical information. The scanning resolution of the images shall be 500 pixels/inch with 256 grey-levels. To minimise the amount of data, all palmprint images shall be compressed using WSQ-algorithm. If necessary the resolution of the images may be expanded to more than 500 pixels/inch and more than 256 grey-levels by mutual agreement. In that case, it is strongly recommended to use JPEG 2000 (see Appendix 39-7).

2. Record format

A transaction file shall consist of one or more logical records. For each logical record contained in the file, several information fields appropriate to that record type shall be present. Each information field may contain one or more basic single-valued information items. Taken together these items are used to convey different aspects of the data contained in that field. An information field may also consist of one or more information items grouped together and repeated multiple times within a field. Such a group of information items is known as a subfield. An information field may therefore consist of one or more subfields of information items.

2.1. Information separators

In the tagged-field logical records, mechanisms for delimiting information are implemented by use of four ASCII information separators. The delimited information may be items within a field or subfield, fields within a logical record, or multiple occurrences of subfields. These information separators are defined in the standard ANSI X3.4. These characters are used to separate and qualify information in a logical sense. Viewed in a hierarchical relationship, the File Separator "FS" character is the most inclusive followed by the Group Separator "GS", the Record Separator "RS", and finally the Unit Separator "US" characters. Table 1 lists these ASCII separators and a description of their use within this standard.

Information separators should be functionally viewed as an indication of the type data that follows. The "US" character shall separate individual information items within a field or subfield. This is a signal that the next information item is a piece of data for that field or subfield. Multiple subfields within a field separated by the "RS" character signals the start of the next group of repeated information item(s). The "GS" separator character used between information fields signals the beginning of a new field preceding the field identifying number that shall appear. Similarly, the beginning of a new logical record shall be signalled by the appearance of the "FS" character.

The four characters are only meaningful when used as separators of data items in the fields of the ASCII text records. There is no specific meaning attached to these characters occurring in binary image records and binary fields — they are just part of the exchanged data.

Normally, there should be no empty fields or information items and therefore only one separator character should appear between any two data items. The exception to this rule occurs for those instances where the data in fields or information items in a transaction are unavailable, missing, or optional, and the processing of the transaction is not dependent upon the presence of that particular data. In those instances, multiple and adjacent separator characters shall appear together rather than requiring the insertion of dummy data between separator characters.

For the definition of a field that consists of three information items, the following applies. If the information for the second information item is missing, then two adjacent "US" information separator characters would occur between the first and third information items. If the second and third information items were both missing, then three separator characters should be used — two "US" characters in addition to the terminating field or subfield separator character. In general, if one or more mandatory or optional information items are unavailable for a field or subfield, then the appropriate number of separator character should be inserted.

It is possible to have side-by-side combinations of two or more of the four available separator characters. When data are missing or unavailable for information items, subfields, or fields, there shall be one separator character less than the number of data items, subfields, or fields required.

Table 1

Separators Used

Code Type Description Hexadecimal Value Decimal Value US Unit Separator Separates information items 1F 31 RS Record Separator Separates subfields 1E 30 GS Group Separator Separates fields 1D 29 FS File Separator Separates logical records 1C 28

2.2. Record layout

For tagged-field logical records, each information field that is used shall be numbered in accordance with this standard. The format for each field shall consist of the logical record type number followed by a period ".", a field number followed by a colon ":", followed by the information appropriate to that field. The tagged-field number can be any one-to-nine digit number occurring between the period "." and the colon ":". It shall be interpreted as an unsigned integer field number. This implies that a field number of "2.123:" is equivalent to and shall be interpreted in the same manner as a field number of "2.000000123:".

For purposes of illustration throughout this document, a three-digit number shall be used for enumerating the fields contained in each of the tagged-field logical records described herein. Field numbers will have the form of "TT.xxx:" where the "TT" represents the one- or two-character record type followed by a period. The next three characters comprise the appropriate field number followed by a colon. Descriptive ASCII information or the image data follows the colon.

Logical Type-1 and Type-2 records contain only ASCII textual data fields. The entire length of the record (including field numbers, colons, and separator characters) shall be recorded as the first ASCII field within each of these record types. The ASCII File Separator "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.

In contrast to the tagged-field concept, the Type-4 record contains only binary data recorded as ordered fixed-length binary fields. The entire length of the record shall be recorded in the first four-byte binary field of each record. For this binary record, neither the record number with its period, nor the field identifier number and its following colon, shall be recorded. Furthermore, as all the field lengths of this record is either fixed or specified, none of the four separator characters ("US", "RS", "GS", or "FS") shall be interpreted as anything other than binary data. For the binary record, the "FS" character shall not be used as a record separator or transaction terminating character.

3. Type-1 Logical Record: the File Header

This record describes the structure of the file, the type of the file, and other important information. The character set used for Type-1 fields shall contain only the 7-bit ANSI code for information interchange.

3.1. Fields for Type-1 Logical Record

3.1.1. Field 1.001: Logical Record Length (LEN)

This field contains the total count of the number of bytes in the whole Type-1 logical record. The field begins with "1.001:", followed by the total length of the record including every character of every field and the information separators.

3.1.2. Field 1.002: Version Number (VER)

To ensure that users know which version of the ANSI/NIST standard is being used, this four byte field specifies the version number of the standard being implemented by the software or system creating the file. The first two bytes specify the major version reference number, the second two the minor revision number. For example, the original 1986 Standard would be considered the first version and designated "0100" while the present ANSI/NIST-ITL 1-2000 standard is "0300".

3.1.3. Field 1.003: File Content (CNT)

This field lists each of the records in the file by record type and the order in which the records appear in the logical file. It consists of one or more subfields, each of which in turn contains two information items describing a single logical record found in the current file. The subfields are entered in the same order in which the records are recorded and transmitted.

The first information item in the first subfield is "1", to refer to this Type-1 record. It is followed by a second information item which contains the number of other records contained in the file. This number is also equal to the count of the remaining subfields of field 1.003.

Each of the remaining subfields is associated with one record within the file, and the sequence of subfields corresponds to the sequence of records. Each subfield contains two items of information. The first is to identify the Type of the record. The second is the record's IDC. The "US" character shall be used to separate the two information items.

3.1.4. Field 1.004: Type of Transaction (TOT)

This field contains a three letter mnemonic designating the type of the transaction. These codes may be different from those used by other implementations of the ANSI/NIST standard.

CPS: Criminal Print-to-Print Search. This transaction is a request for a search of a record relating to a criminal offence against a prints database. The person's prints shall be included as WSQ-compressed images in the file.

In case of a No-HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record.

In case of a HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record,

— 1-14 Type-4 Record.

The CPS TOT is summarised in Table A.6.1 (Appendix 39-6).

PMS: Print-to-Latent Search. This transaction is used when a set of prints is searched against an Unidentified Latent database. The response will contain the HIT/No-HIT decision of the destination AFIS search. If multiple unidentified latents exist, multiple SRE transactions will be returned, with one latent per transaction. The person's prints shall be included as WSQ-compressed images in the file.

In case of a No-HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record.

In case of a HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record,

— 1 Type-13 Record.

The PMS TOT is summarised in Table A.6.1 (Appendix 39-6).

MPS: Latent-to-Print Search. This transaction is used when a latent is to be searched against a Prints database. The latent minutiæ information and the image (WSQ-compressed) shall be included in the file.

In case of a No-HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record.

In case of a HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record,

— 1 Type-4 or Type-15 Record.

The MPS TOT is summarised in Table A.6.4 (Appendix 39-6).

MMS: Latent-to-Latent Search. In this transaction the file contains a latent which is to be searched against an Unidentified Latent database in order to establish links between various scenes of crime. The latent minutiæ information and the image (WSQ-compressed) must be included in the file.

In case of a No-HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record.

In case of a HIT, the following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record,

— 1 Type-13 Record.

The MMS TOT is summarised in Table A.6.4 (Appendix 39-6).

SRE: This transaction is returned by the destination agency in response to dactyloscopic submissions. The response will contain the HIT/No-HIT decision of the destination AFIS search. If multiple candidates exist, multiple SRE transactions will be returned, with one candidate per transaction.

The SRE TOT is summarised in Table A.6.2 (Appendix 39-6).

ERR: This transaction is returned by the destination AFIS to indicate a transaction error. It includes a message field (ERM) indicating the error detected. The following logical records will be returned:

— 1 Type-1 Record,

— 1 Type-2 Record.

The ERR TOT is summarised in Table A.6.3 (Appendix 39-6).

Table 2

Permissible Codes in Transactions

Transaction Type Logical Record Type 1 2 4 9 13 15 CPS M M M — — — SRE M M C — (C in case of latent HITs) C C MPS M M — M (1*) M — MMS M M — M (1*) M — PMS M M M* — — M* ERR M M — — — —

Key:

M = Mandatory, M* = Only one of both record-types may be included, O = Optional, C = Conditional on whether data is available, — = Not allowed, 1* = Conditional depending on legacy systems.

3.1.5. Field 1.005: Date of Transaction (DAT)

This field indicates the date on which the transaction was initiated and shall conform to the ISO standard notation of: YYYYMMDD

where YYYY is the year, MM is the month and DD is the day of the month. Leading zeros are used for single figure numbers. For example, "19931004" represents 4 October 1993.

3.1.6. Field 1.006: Priority (PRY)

This optional field defines the priority, on a level of 1 to 9, of the request. "1" is the highest priority and "9" the lowest. Priority "1" transactions shall be processed immediately.

3.1.7. Field 1.007: Destination Agency Identifier (DAI)

This field specifies the destination agency for the transaction.

It consists of two information items in the following format: CC/agency.

The first information item contains the Country Code, defined in ISO 3166, two alpha-numeric characters long. The second item, agency, is a free text identification of the agency, up to a maximum of 32 alpha-numeric characters.

3.1.8. Field 1.008: Originating Agency Identifier (ORI)

This field specifies the file originator and has the same format as the DAI (Field 1.007).

3.1.9. Field 1.009: Transaction Control Number (TCN)

This is a control number for reference purposes. It should be generated by the computer and have the following format: YYSSSSSSSSA

where YY is the year of the transaction, SSSSSSSS is an eight-digit serial number, and A is a check character generated by following the procedure given in Appendix 39-2.

Where a TCN is not available, the field, YYSSSSSSSS, is filled with zeros and the check character generated as above.

3.1.10. Field 1.010: Transaction Control Response (TCR)

Where a request was sent out, to which this is the response, this optional field will contain the transaction control number of the request message. It therefore has the same format as TCN (Field 1.009).

3.1.11. Field 1.011: Native Scanning Resolution (NSR)

This field specifies the normal scanning resolution of the system supported by the originator of the transaction. The resolution is specified as two numeric digits followed by the decimal point and then two more digits.

For all transactions pursuant to Articles 533 and 534 of this Agreement the sampling rate shall be 500 pixels/inch or 19,68 pixels/mm.

3.1.12. Field 1.012: Nominal Transmitting Resolution (NTR)

This five-byte field specifies the nominal transmitting resolution for the images being transmitted. The resolution is expressed in pixels/mm in the same format as NSR (Field 1.011).

3.1.13. Field 1.013: Domain name (DOM)

This mandatory field identifies the domain name for the user-defined Type-2 logical record implementation. It consists of two information items and shall be "INT-I{}{US}}4.22{}{GS}}".

3.1.14. Field 1.014: Greenwich mean time (GMT)

This mandatory field provides a mechanism for expressing the date and time in terms of universal Greenwich Mean Time (GMT) units. If used, the GMT field contains the universal date that will be in addition to the local date contained in Field 1.005 (DAT). Use of the GMT field eliminates local time inconsistencies encountered when a transaction and its response are transmitted between two places separated by several time zones. The GMT provides a universal date and 24-hour clock time independent of time zones. It is represented as "CCYYMMDDHHMMSSZ", a 15-character string that is the concatenation of the date with the GMT and concludes with a "Z". The "CCYY" characters shall represent the year of the transaction, the "MM" characters shall be the tens and units values of the month, and the "DD" characters shall be the 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. The complete date shall not exceed the current date.

4. Type-2 Logical Record: Descriptive Text

The structure of most of this record is not defined by the original ANSI/NIST standard. The record contains information of specific interest to the agencies sending or receiving the file. To ensure that communicating dactyloscopic systems are compatible, it is required that only the fields listed below are contained within the record. This document specifies which fields are mandatory and which optional, and also defines the structure of the individual fields.

4.1. Fields for Type-2 Logical Record

4.1.1. Field 2.001: Logical Record Length (LEN)

This mandatory field contains the length of this Type-2 record, and specifies the total number of bytes including every character of every field contained in the record and the information separators.

4.1.2. Field 2.002: Image Designation Character (IDC)

The IDC contained in this mandatory field is an ASCII representation of the IDC as defined in the File Content field (CNT) of the Type-1 record (Field 1.003).

4.1.3. Field 2.003: System Information (SYS)

This field is mandatory and contains four bytes which indicate which version of the INT-I this particular Type-2 record complies with.

The first two bytes specify the major version number, the second two the minor revision number. For example, this implementation is based on INT-I version 4 revision 22 and would be represented as "0422".

4.1.4. Field 2.007: Case Number (CNO)

This is a number assigned by the local dactyloscopic bureau to a collection of latents found at a scene-of-crime. The following format is adopted: CC/number

where CC is the Interpol Country Code, two alpha-numeric characters in length, and the number complies with the appropriate local guidelines and may be up to 32 alpha-numeric characters long.

This field allows the system to identify latents associated with a particular crime.

4.1.5. Field 2.008: Sequence Number (SQN)

This specifies each sequence of latents within a case. It can be up to four numeric characters long. A sequence is a latent or series of latents which are grouped together for the purposes of filing and/or searching. This definition implies that even single latents will still have to be assigned a sequence number.

This field together with MID (Field 2.009) may be included to identify a particular latent within a sequence.

4.1.6. Field 2.009: Latent Identifier (MID)

This specifies the individual latent within a sequence. The value is a single letter or two letters, with "A" assigned to the first latent, "B" to the second, and so on up to a limit of "ZZ". This field is used analogue to the latent sequence number discussed in the description for SQN (Field 2.008).

4.1.7. Field 2.010: Criminal Reference Number (CRN)

This is a unique reference number assigned by a national agency to an individual who is charged for the first time with committing an offence. Within one country no individual ever has more than one CRN, or shares it with any other individual. However, the same individual may have Criminal Reference Numbers in several countries, which will be distinguishable by means of the country code.

The following format is adopted for CRN field: CC/number

where CC is the Country Code, defined in ISO 3166, two alpha-numeric characters in length, and the number complies with the appropriate national guidelines of the issuing agency, and may be up to 32 alpha-numeric characters long.

For transactions pursuant to Articles 533 and 534 of this Agreement this field will be used for the national criminal reference number of the originating agency which is linked to the images in Type-4 or Type-15 Records.

4.1.8. Field 2.012: Miscellaneous Identification Number (MN1)

This fields contains the CRN (Field 2.010) transmitted by a CPS or PMS transaction without the leading country code.

4.1.9. Field 2.013: Miscellaneous Identification Number (MN2)

This fields contains the CNO (Field 2.007) transmitted by an MPS or MMS transaction without the leading country code.

4.1.10. Field 2.014: Miscellaneous Identification Number (MN3)

This fields contains the SQN (Field 2.008) transmitted by an MPS or MMS transaction.

4.1.11. Field 2.015: Miscellaneous Identification Number (MN4)

This fields contains the MID (Field 2.009) transmitted by an MPS or MMS transaction.

4.1.12. Field 2.063: Additional Information (INF)

In case of an SRE transaction to a PMS request this field gives information about the finger which caused the possible HIT. The format of the field is:

NN where NN is the finger position code defined in Table 5, two digits in length.

In all other cases the field is optional. It consists of up to 32 alpha-numeric characters and may give additional information about the request.

4.1.13. Field 2.064: Respondents List (RLS)

This field contains at least two subfields. The first subfield describes the type of search that has been carried out, using the three-letter mnemonics which specify the transaction type in TOT (Field 1.004). The second subfield contains a single character. An "I" shall be used to indicate that a HIT has been found and an "N" shall be used to indicate that no matching cases have been found (No-HIT). The third subfield contains the sequence identifier for the candidate result and the total number of candidates separated by a slash. Multiple messages will be returned if multiple candidates exist.

In case of a possible HIT the fourth subfield shall contain the score up to six digits long. If the HIT has been verified the value of this subfield is defined as "999999".

Example: "CPS{}{RS}}I{}{RS}}001/001{}{RS}}999999{}{GS}}"

If the remote AFIS does not assign scores, then a score of zero should be used at the appropriate point.

4.1.14. Field 2.074: Status/Error Message Field (ERM)

This field contains error messages resulting from transactions, which will be sent back to the requester as part of an Error Transaction.

Table 3

Error messages

Numeric code (1-3) Meaning (5-128) 003 ERROR: UNAUTHORISED ACCESS 101 Mandatory field missing 102 Invalid record type 103 Undefined field 104 Exceed the maximum occurrence 105 Invalid number of subfields 106 Field length too short 107 Field length too long 108 Field is not a number as expected 109 Field number value too small 110 Field number value too big 111 Invalid character 112 Invalid date 115 Invalid item value 116 Invalid type of transaction 117 Invalid record data 201 ERROR: INVALID TCN 501 ERROR: INSUFFICIENT FINGERPRINT QUALITY 502 ERROR: MISSING FINGERPRINTS 503 ERROR: FINGERPRINT SEQUENCE CHECK FAILED 999 ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY.

Error messages in the range between 100 and 199:

These error messages are related to the validation of the ANSI/NIST records and defined as: <error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF <error_code 2>: IDC <idc_number 2> FIELD <field_id 2> <dynamic text 2>… where — error_code is a code uniquely related to a specific reason (see Table 3), — field_id is the ANSI/NIST field number of the incorrect field (e.g. 1.001, 2.001, …) in the format <record_type>.<field_id>.<sub_field_id>, — dynamic text is a more detailed dynamic description of the error, — LF is a Line Feed separating errors if more than one error is encountered, — for type-1 record the ICD is defined as "-1".

Example:

201: IDC - 1 FIELD 1.009 WRONG CONTROL CHARACTER {}{LF}} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION

This field is mandatory for error transactions.

4.1.15. Field 2.320: Expected Number of Candidates (ENC)

This field contains the maximum number of candidates for verification expected by the requesting agency. The value of ENC shall not exceed the values defined in Table 11.

5. Type-4 Logical Record: High Resolution GreyScale Image

It should be noted that Type-4 records are binary rather than ASCII in nature. Therefore each field is assigned a specific position within the record, which implies that all fields are mandatory.

The standard allows both image size and resolution to be specified within the record. It requires Type-4 Logical Records to contain dactyloscopic image data that are being transmitted at a nominal pixel density of 500 to 520 pixels per inch. The preferred rate for new designs is at a pixel density of 500 pixels per inch or 19,68 pixels per mm. 500 pixels per inch is the density specified by the INT-I, except that similar systems may communicate with each other at a non-preferred rate, within the limits of 500 to 520 pixels per inch.

5.1. Fields for Type-4 Logical Record

5.1.1. Field 4.001: Logical Record Length (LEN)

This four-byte field contains the length of this Type-4 record, and specifies the total number of bytes including every byte of every field contained in the record.

5.1.2. Field 4.002: Image Designation Character (IDC)

This is the one-byte binary representation of the IDC number given in the header file.

5.1.3. Field 4.003: Impression Type (IMP)

The impression type is a single-byte field occupying the sixth byte of the record.

Table 4

Finger Impression Type

Code Description 0 Live-scan of plain fingerprint 1 Live-scan of rolled fingerprint 2 Non-live scan impression of plain fingerprint captured from paper 3 Non-live scan impression of rolled fingerprint captured from paper 4 Latent impression captured directly 5 Latent tracing 6 Latent photo 7 Latent lift 8 Swipe 9 Unknown

5.1.4. Field 4.004: Finger Position (FGP)

This fixed-length field of six bytes occupies the seventh through twelfth byte positions of a Type-4 record. It contains possible finger positions beginning in the left most byte (byte seven of the record). The known or most probable finger position is taken from Table 5. Up to five additional fingers may be referenced by entering the alternate finger positions in the remaining five bytes using the same format. If fewer than five finger position references are to be used the unused bytes are filled with binary 255. To reference all finger positions code 0, for unknown, is used.

Table 5

Finger position code and maximum size

Finger position Finger code Width (mm) Length (mm) Unknown 0 40,0 40,0 Right thumb 1 45,0 40,0 Right index finger 2 40,0 40,0 Right middle finger 3 40,0 40,0 Right ring finger 4 40,0 40,0 Right little finger 5 33,0 40,0 Left thumb 6 45,0 40,0 Left index finger 7 40,0 40,0 Left middle finger 8 40,0 40,0 Left ring finger 9 40,0 40,0 Left little finger 10 33,0 40,0 Plain right thumb 11 30,0 55,0 Plain left thumb 12 30,0 55,0 Plain right four fingers 13 70,0 65,0 Plain left four fingers 14 70,0 65,0

For scene of crime latents only the codes 0 to 10 should be used.

5.1.5. Field 4.005: Image Scanning Resolution (ISR)

This one-byte field occupies the 13th byte of a Type-4 record. If it contains "0" then the image has been sampled at the preferred scanning rate of 19,68 pixels/mm (500 pixels per inch). If it contains "1" then the image has been sampled at an alternative scanning rate as specified in the Type-1 record.

5.1.6. Field 4.006: Horizontal Line Length (HLL)

This field is positioned at bytes 14 and 15 within the Type-4 record. It specifies the number of pixels contained in each scan line. The first byte will be the most significant.

5.1.7. Field 4.007: Vertical Line Length (VLL)

This field records in bytes 16 and 17 the number of scan lines present in the image. The first byte is the most significant.

5.1.8. Field 4.008: Greyscale Compression Algorithm (GCA)

This one-byte field specifies the greyscale compression algorithm used to encode the image data. For this implementation, a binary code 1 indicates that WSQ compression (Appendix 39-7) has been used.

5.1.9. Field 4.009: The Image

This field contains a byte stream representing the image. Its structure will obviously depend on the compression algorithm used.

6. Type-9 Logical Record: Minutiæ Record

Type-9 records shall contain ASCII text describing minutiæ and related information encoded from a latent. For latent search transaction, there is no limit for these Type-9 records in a file, each of which shall be for a different view or latent.

6.1. Minutiæ extraction

6.1.1. Minutia type identification

This standard defines three identifier numbers that are used to describe the minutia type. These are listed in Table 6. A ridge ending shall be designated Type 1. A bifurcation shall be designated Type 2. If a minutia cannot be clearly categorised as one of the above two types, it shall be designated as "other", Type 0.

Table 6

Minutia types

Type Description 0 Other 1 Ridge ending 2 Bifurcation

6.1.2. Minutia placement and type

For templates to be compliant with Section 5 of the ANSI INCITS 378-2004 standard, the following method, which enhances the current INCITS 378-2004 standard, shall be used for determining placement (location and angular direction) of individual minutiæ.

The position or location of a minutia representing a ridge ending shall be the point of forking of the medial skeleton of the valley area immediately in front of the ridge ending. If the three legs of the valley area were thinned down to a single-pixel-wide skeleton, the point of the intersection is the location of the minutia. Similarly, the location of the minutia for a bifurcation shall be the point of forking of the medial skeleton of the ridge. If the three legs of the ridge were each thinned down to a single-pixel-wide skeleton, the point where the three legs intersect is the location of the minutia.

After all ridge endings have been converted to bifurcations, all of the minutiæ of the dactyloscopic image are represented as bifurcations. The X and Y pixel coordinates of the intersection of the three legs of each minutia can be directly formatted. Determination of the minutia direction can be extracted from each skeleton bifurcation. The three legs of every skeleton bifurcation shall be examined and the endpoint of each leg determined. Figure 6.1.2 illustrates the three methods used for determining the end of a leg that is based on a scanning resolution of 500 ppi.

The ending is established according to the event that occurs first. The pixel count is based on a scan resolution of 500 ppi. Different scan resolutions would imply different pixel counts.

— a distance of 0,064" (the 32nd pixel),

— the end of skeleton leg that occurs between a distance of 0,02" and 0,064" (the 10th through the 32nd pixels); shorter legs are not used,

— a second bifurcation is encountered within a distance of 0,064" (before the 32nd pixel).

The angle of the minutiæ is determined by constructing three virtual rays originating at the bifurcation point and extending to the end of each leg. The smallest of the three angles formed by the rays is bisected to indicate the minutiæ direction.

6.1.3. Coordinate system

The coordinate system used to express the minutiæ of a fingerprint shall be a Cartesian coordinate system. Minutiæ locations shall be represented by their x and y coordinates. The origin of the coordinate system shall be the upper left corner of the original image with x increasing to the right and y increasing downward. Both x and y coordinates of a minutiæ shall be represented in pixel units from the origin. It should be noted that the location of the origin and units of measure is not in agreement with the convention used in the definitions of the Type 9 in the ANSI/NIST-ITL 1-2000.

6.1.4. Minutiæ direction

Angles are expressed in standard mathematical format, with zero degrees to the right and angles increasing in the counter clockwise direction. Recorded angles are in the direction pointing back along the ridge for a ridge ending and toward the centre of the valley for a bifurcation. This convention is 180 degrees opposite of the angle convention described in the definitions of the Type 9 in the ANSI/NIST-ITL 1-2000.

6.2. Fields for Type-9 Logical record INCITS-378 Format

All fields of the Type-9 records shall be recorded as ASCII text. No binary fields are permissible in this tagged-field record.

6.2.1. Field 9.001: Logical record length (LEN)

This mandatory ASCII field shall contain the length of the logical record specifying the total number of bytes, including every character of every field contained in the record.

6.2.2. Field 9.002: Image designation character (IDC)

This mandatory two-byte field shall be used for the identification and location of the minutiæ data. The IDC contained in this field shall match the IDC found in the file content field of the Type-1 record.

6.2.3. Field 9.003: Impression type (IMP)

This mandatory one-byte field shall describe the manner by which the dactyloscopic image information was obtained. The ASCII value of the proper code as selected from Table 4 shall be entered in this field to signify the impression type.

6.2.4. Field 9.004: Minutiæ format (FMT)

This field shall contain a "U" to indicate that the minutiæ are formatted in M1-378 terms. Even though information may be encoded in accordance with the M1-378 standard, all data fields of the Type-9 record shall remain as ASCII text fields.

6.2.5. Field 9.126: CBEFF information

This field shall contain three information items. The first information item shall contain the value "27" (0x1B). This is the identification of the CBEFF Format Owner assigned by the International Biometric Industry Association (IBIA) to INCITS Technical Committee M1. The <US> character shall delimit this item from the CBEFF Format Type that is assigned a value of "513" (0x0201) to indicate that this record contains only location and angular direction data without any Extended Data Block information. The <US> character shall delimit this item from the CBEFF Product Identifier (PID) that identifies the "owner" of the encoding equipment. The vendor establishes this value. It can be obtained from the IBIA website (www.ibia.org) if it is posted.

6.2.6. Field 9.127: Capture equipment identification

This field shall contain two information items separated by the <US> character. The first shall contain "APPF" if the equipment used originally to acquire the image was certified to comply with Appendix F (IAFIS Image Quality Specification, 29 January 1999) of CJIS-RS-0010, the Federal Bureau of Investigation's Electronic Fingerprint Transmission Specification. If the equipment did not comply, it will contain the value of "NONE". The second information item shall contain the Capture Equipment ID which is a vendor-assigned product number of the capture equipment. A value of "0" indicates that the capture equipment ID is unreported.

6.2.7. Field 9.128: Horizontal line length (HLL)

This mandatory ASCII field shall contain the number of pixels contained on a single horizontal line of the transmitted image. The maximum horizontal size is limited to 65534 pixels.

6.2.8. Field 9.129: Vertical line length (VLL)

This mandatory ASCII field shall contain the number of horizontal lines contained in the transmitted image. The maximum vertical size is limited to 65534 pixels.

6.2.9. Field 9.130: Scale units (SLC)

This mandatory ASCII field shall specify the units used to describe the image sampling frequency (pixel density). A "1" in this field indicates pixels per inch, or a "2" indicates pixels per centimetre. A "0" in this field indicates no scale is given. In this case, the quotient of HPS/VPS gives the pixel aspect ratio.

6.2.10. Field 9.131: Horizontal pixel scale (HPS)

This mandatory ASCII field shall specify the integer pixel density used in the horizontal direction providing the SLC contains a "1" or a "2". Otherwise, it indicates the horizontal component of the pixel aspect ratio.

6.2.11. Field 9.132: Vertical pixel scale (VPS)

This mandatory ASCII field shall specify the integer pixel density used in the vertical direction providing the SLC contains a "1" or a "2". Otherwise, it indicates the vertical component of the pixel aspect ratio.

6.2.12. Field 9.133: Finger view

This mandatory field contains the view number of the finger associated with this record's data. The view number begins with "0" and increments by one to "15".

6.2.13. Field 9.134: Finger position (FGP)

This field shall contain the code designating the finger position that produced the information in this Type-9 record. A code between 1 and 10 taken from Table 5 or the appropriate palm code from Table 10 shall be used to indicate the finger or palm position.

6.2.14. Field 9.135: Finger quality

The field shall contain the quality of the overall finger minutiæ data and shall be between 0 and 100. This number is an overall expression of the quality of the finger record, and represents quality of the original image, of the minutia extraction and any additional operations that may affect the minutiæ record.

6.2.15. Field 9.136: number of minutiæ

The mandatory field shall contain a count of the number of minutiæ recorded in this logical record.

6.2.16. Field 9.137: Finger minutiæ data

This mandatory field has six information items separated by the <US> character. It consists of several subfields, each containing the details of single minutiae. The total number of minutiae subfields must agree with the count found in field 136. The first information item is the minutiae index number, which shall be initialised to "1" and incremented by "1" for each additional minutia in the fingerprint. The second and third information items are the "x" coordinate and "y" coordinates of the minutiae in pixel units. The fourth information item is the minutiae angle recorded in units of two degrees. This value shall be nonnegative between 0 and 179. The fifth information item is the minutiae type. A value of "0" is used to represent minutiae of type "OTHER", a value of "1" for a ridge ending and a value of "2" for a ridge bifurcation. The sixth information item represents the quality of each minutiae. This value shall range from 1 as a minimum to 100 as a maximum. A value of "0" indicates that no quality value is available. Each subfield shall be separated from the next with the use of the <RS> separator character.

6.2.17. Field 9.138: Ridge count information

This field consists of a series of subfields each containing three information items. The first information item of the first subfield shall indicate the ridge count extraction method. A "0" indicates that no assumption shall be made about the method used to extract ridge counts, nor their order in the record. A "1" indicates that for each centre minutiæ, ridge count data was extracted to the nearest neighbouring minutiæ in four quadrants, and ridge counts for each centre minutia are listed together. A "2" indicates that for each centre minutiæ, ridge count data was extracted to the nearest neighbouring minutiæ in eight octants, and ridge counts for each centre minutia are listed together. The remaining two information items of the first subfield shall both contain "0". Information items shall be separated by the <US> separator character. Subsequent subfields will contain the centre minutiæ index number as the first information item, the neighbouring minutiæ index number as the second information item, and the number of ridges crossed as the third information item. Subfields shall be separated by the <RS> separator character.

6.2.18. Field 9.139: Core information

This field will consist of one subfield for each core present in the original image. Each subfield consists of three information items. The first two items contain the "x" and "y" coordinate positions in pixel units. The third information item contains the angle of the core recorded in units of 2 degrees. The value shall be a nonnegative value between 0 and 179. Multiple cores will be separated by the <RS> separator character.

6.2.19. Field 9.140: Delta information

This field will consist of one subfield for each delta present in the original image. Each subfield consists of three information items. The first two items contain the "x" and "y" coordinate positions in pixel units. The third information item contains the angle of the delta recorded in units of 2 degrees. The value shall be a nonnegative value between 0 and 179. Multiple cores will be separated by the <RS> separator character.

7. Type-13 variable-resolution latent image record

The Type-13 tagged-field logical record shall contain image data acquired from latent images. These images are intended to be transmitted to agencies that will automatically extract or provide human intervention and processing to extract the desired feature information from the images.

Information regarding the scanning resolution used, the image size, and other parameters required to process the image, are recorded as tagged-fields within the record.

Table 7

Type-13 variable-resolution latent record layout

Ident Cond. code Field Number Field name Char type Field size per occurrence Occur count Max byte count min. max. min max LEN M 13.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 IDC M 13.002 IMAGE DESIGNATION CHARACTER N 2 5 1 1 12 IMP M 13.003 IMPRESSION TYPE A 2 2 1 1 9 SRC M 13.004 SOURCE AGENCY/ORI AN 6 35 1 1 42 LCD M 13.005 LATENT CAPTURE DATE N 9 9 1 1 16 HLL M 13.006 HORIZONTAL LINE LENGTH N 4 5 1 1 12 VLL M 13.007 VERTICAL LINE LENGTH N 4 5 1 1 12 SLC M 13.008 SCALE UNITS N 2 2 1 1 9 HPS M 13.009 HORIZONTAL PIXEL SCALE N 2 5 1 1 12 VPS M 13.010 VERTICAL PIXEL SCALE N 2 5 1 1 12 CGA M 13.011 COMPRESSION ALGORITHM A 5 7 1 1 14 BPX M 13.012 BITS PER PIXEL N 2 3 1 1 10 FGP M 13.013 FINGER POSITION N 2 3 1 6 25 RSV 13.014 RESERVED FOR FUTURE DEFINITION — — — — — — 13.019 COM O 13.020 COMMENT A 2 128 0 1 135 RSV 13.021 RESERVED FOR FUTURE DEFINITION — — — — — — 13.199 UDF O 13.200 USER-DEFINED FIELDS — — — — — — 13.998 DAT M 13.999 IMAGE DATA B 2 — 1 1 —

Key for character type: N = Numeric; A = Alphabetic; AN = Alphanumeric; B = Binary

7.1. Fields for the Type-13 logical record

The following paragraphs describe the data contained in each of the fields for the Type-13 logical record.

Within a Type-13 logical record, entries shall be provided in numbered fields. 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. For each field of the Type-13 record, Table 7 lists the "condition code" as being mandatory "M" or optional "O", the field number, the field name, character type, field size, and occurrence limits. Based on a three digit field number, the maximum byte count size for the field is given in the last column. As more digits are used for the field number, the maximum byte count will also increase.