Multiple Type 13 (Latents)

[Jeremy-M-Int]

Can we have multiple Type 13 (Latents) in a NIST file?
NIST authorizes it, the v5.03 also, but the new v6.00 only authorizes 1 Type 13 per file.

[Jeremy-M-Int]

What would be the impact on Type 2? Would there be multiple Type 2 records and how to link Type 2 and Type 13 records.

[epcondon]

The Interpol Standards 6.0 Working Group (WG) discussed this issue and the restriction to limit one mark per NIST transaction was a deliberate position.
The rational was that this made the alignment of records within the transaction much simpler, easier to implement and more consistent with existing binary implementation. Where you have multiple marks in the same NIST transaction you would need a mechanism:
a) to align the template(s) (Type 9 and Type 99) to mark images, and specific marks images to any other images, within the case construct.
b) to align any search response to a specific mark; you could not rely just on the TCN/TCR but also need to reference the specific mark (increasing complexity in any system processing the transaction). It also means the one to one cardinality of TCN to TCR for search responses does not hold (making auditing and monitoring of outstanding responses more challenging).
Given that this is anticipated as being a system to system interaction sending multiple NIST transactions (with the same case reference to tie them in the receiving system) was not seen as an undue overhead, helped the automation of search initiation upon receipt and also protected against very large sized NIST files which could have detrimental impacts on transmission mechanisms.

If the next revision of the standard wants to remove this limitation, a description of the mechanism to tie the record types together will be required and a decision if this new construct is mandatory for all transactions or just where there is more than one mark within a case. (The NIST standard appears to have such a mechanism)

Having multiple Type 2 records with in the same NIST transaction, whilst not prohibited by the NIST standard, would be a step change from the current and historic usage. I believe it was introduced (2013) to cater for where you may have multiple individuals/ identities associated with another record e.g. voice recording of a conversation. It would make implementation more challenging and also require definition of how to tie to the relevant other records in the transaction (assumed that same as for other record types). Ensuring that you did not have one mark associated with multiple type 2 would be challenging to enforce (and beyond the ability of schema / MRT files to validate)

[Jeremy-M-Int]

As discussed with the INSIWG:

• Multiple evidences/latents/encodings can indeed be authorized/supported
• Some ToTs (such as the MPS or MMS from PRUM) will be still limited to only 1 latent for file
• A link between Latents and Evidences will be made by using the fields 13.997 (SRN) -> 20.021 (SRN)
• A link between Encodings and Latents will be made on the basis of aligned IDCs
• Reference (& more contextual?) information per Evidence/Latent/Encoding pending NIST Standard revision Add Reference and more contextual information to Type 9/13/20 #28

[tsaracouvert]

IDC is changing in case of retransmission.
Waiting from 2025 NIST update for the field.

[gfiumara]

Multiple Type 13 may change the limitation of a single Type 20:

Multiple Type 20 records are not supported Even though the ANSI/NIST standard supports transmitting multiple Type 20 records in a single file, this is not allowed in INTERPOL’s implementation. This also means that there is no need to specify a reference to a specific Type 20 record in Type 9 and Type 13 records.
Given the implementation limitations on Type 9 and Type 13, it is implied that if the Type 20 image contains multiple latents, you still need to send multiple files, one per latent.