FREE EFT EDITOR EDITOR

EFT File Format Explained: What's Actually Inside Your .eft File

A technical deep-dive into the Electronic Biometric Transmission Specification (EBTS) format and what data is actually stored inside an EFT fingerprint file.

Most applicants who upload an EFT file to the ATF eForms portal never look inside it. While the file functions as a black box during submission, many filers assume it is simply an image of their fingerprints. In reality, an EFT file is a structured database transaction built to the FBI's Electronic Biometric Transmission Specification (EBTS), a profile of the broader ANSI/NIST-ITL standard. Alongside compressed fingerprint images, the file contains a transaction header, demographic records, capture metadata, and resolution details. This guide details each record type inside the file to clarify exactly what you submit to the ATF.

An EFT file is a structured container

Opening an EFT file in a standard text editor reveals readable ASCII text mixed with binary data. This layout is normal and reflects the file's design.

The file operates as a container. The header sections contain plain text declaring the specification version, the transaction purpose, and the applicant's identity. Below this header, individual fingerprint records house the compressed image data alongside metadata fields. These fields detail the image resolution, the compression type, the corresponding finger position, and quality metrics.

By combining these elements, a single file provides the receiving database with all the context required to process the biometric submission: the parent standard, the compression format, finger indexing, and integrity checks. A standard image file (such as a JPEG or PNG) lacks this structured metadata, which is why the federal specification is required.

The standard underneath: ANSI/NIST-ITL and the FBI EBTS

EFT files are built to two nested specifications, and it's useful to know which is which.

ANSI/NIST-ITL 1-2011 (Update: 2015) is the parent standard. It's published by NIST as Special Publication 500-290, and it defines a general-purpose data format for interchanging biometric information - fingerprints, palm prints, iris images, facial photos, and more - between systems run by different agencies and different countries. It defines the record types, the field numbering, and the encoding rules. If two biometric systems can both speak ANSI/NIST-ITL, they can exchange data regardless of which vendor built them.

The FBI's Electronic Biometric Transmission Specification (EBTS) is a profile of ANSI/NIST-ITL that narrows the general standard down to the specific subset the FBI's Criminal Justice Information Services (CJIS) accepts for its own biometric systems, including the Next Generation Identification (NGI) system that processes criminal and civil fingerprint submissions. EBTS is published by the FBI and lives at the record-type and field level - it says which ANSI/NIST-ITL records are mandatory, which fields are required within each record, and which values are acceptable.

An EFT file submitted to the ATF eForms portal is, concretely, an ANSI/NIST-ITL transaction that conforms to the FBI EBTS profile. The ATF eForms system is the destination; the FBI owns the file format.

How the file is encoded - ASCII control characters, not JSON

EFT files predate modern data-interchange formats by decades. The encoding reflects that history.

Instead of nesting fields inside JSON objects or XML tags, the traditional ANSI/NIST-ITL encoding - which EBTS uses - delimits records and fields with four ASCII control characters that have been part of the character set since 1967:

  • FS (File Separator, 0x1C) marks the end of a logical record.
  • GS (Group Separator, 0x1D) marks the end of a field.
  • RS (Record Separator, 0x1E) separates repeated subfields within a field.
  • US (Unit Separator, 0x1F) separates information items within a subfield.

Each field is prefixed by a numeric identifier in the form {record-type}.{field-number}, followed by a colon, followed by the value. A field like 1.003:1{US}1{GS}14{US}2{GS}14{US}3{FS} means: in record type 1, field 003, the file contains a Type-1 record at index 1, a Type-14 record at index 2, and a Type-14 record at index 3. The control characters do the structural work that curly braces and angle brackets do in more modern formats.

There is a newer XML-based encoding for ANSI/NIST-ITL - NIEM-conformant and occasionally called "NIEM XML encoding" - but the ATF eForms portal and the FBI's NGI intake both use the traditional encoding. That's what SLAP & ROLL generates, and it's what every .eft file you'll encounter in the NFA workflow looks like.

The record types you'll find inside

ANSI/NIST-ITL defines more than a dozen record types, each carrying a different kind of biometric or descriptive information. An ATF-bound EFT file only uses a small subset of them. The ones you'll see:

  • Type-1 - Transaction Information. The header record. Every EFT file has exactly one. It declares the version of the standard the file conforms to, the transaction type, the date of the transaction, the originating agency, and an index of every other record in the file.
  • Type-2 - User-Defined Descriptive Text. Carries the subject's identifying information: name, date of birth, place of birth, citizenship, sex, race, and often a height, weight, eye color, and reason the prints were taken. This is the record that holds the personally identifying information the ATF needs to link the fingerprints to the applicant on the eForm.
  • Type-4 - Grayscale Fingerprint Image. A fixed-resolution fingerprint image record. Type-4 records are always 500 pixels per inch and are compressed with WSQ. Type-4 is the older of the two fingerprint record types defined in the standard, and it's the one most widely generated by EFT vendors and livescan systems today.
  • Type-14 - Variable-Resolution Fingerprint Image. A newer fingerprint image record. Type-14s support a range of resolutions (500 PPI, 1000 PPI, and above), multiple compression algorithms, and a richer set of metadata fields including per-finger quality scores.

Other record types exist in the broader ANSI/NIST-ITL standard - Type-9 for fingerprint minutiae data, Type-13 for latent prints, Type-15 for palm prints, Type-17 for iris images, Type-10 for mugshots and scars/marks/tattoos - but none of them appear in a standard ATF eForm EFT submission. If you open an .eft for an eForm 1 or eForm 4 and see only Type-1, Type-2, and either Type-4 or Type-14 records, that is exactly what you should be seeing.

Type-4 and Type-14 - the two records that carry your fingerprints

The single most common question about EFT files, once you know they contain records, is: which kind of fingerprint record is in mine, and does it matter?

Type-4 records carry one finger's image (or in the case of slap-capture Type-4s, four fingers' images) at a fixed resolution of 500 pixels per inch, compressed with WSQ (Wavelet Scalar Quantization - an FBI-developed compression algorithm designed specifically for 500 PPI fingerprint images). The 500 PPI resolution is baked into the record format itself. Type-4 is the older of the two fingerprint record types and remains the more widely produced one across the EFT ecosystem today - most livescan capture systems and EFT-generating tools you'll encounter output Type-4s.

Type-14 records are variable-resolution fingerprint image records. A Type-14 carries the image resolution as a field inside the record rather than as a baked-in constant, which means a Type-14 can hold a 500 PPI, 1000 PPI, or higher-resolution image as appropriate. Type-14s can use WSQ or JPEG 2000 compression, and they carry fields for per-finger quality scores (including the NIST Fingerprint Image Quality score - see the NFIQ guide), capture dates, and finger-position metadata that Type-4s either don't carry or carry in less structured form.

Both are currently accepted by the ATF eForms portal, and neither is a better or worse submission. SLAP & ROLL generates both formats and lets you download either, so you can hold both versions of your file. We do this because the format landscape is set by the receiving agencies, and the list of accepted record types can change over time; holding both versions means a change at the portal side does not cost you a re-roll.

From the reader's perspective: if you open your EFT file and see fields prefixed 14., you have Type-14s; if you see fields prefixed 4., you have Type-4s. Nothing about your application outcome changes based on which one you have.

What's actually inside a fingerprint record

Zooming in on a single Type-14 record - the richer of the two formats, useful as a reference because it exposes every field a fingerprint record can carry - these are the fields that matter:

  • 14.003 - Image Designation Character (IDC). A short identifier that links this record to its entry in the Type-1 file index.
  • 14.004 - Impression Type. A code describing how the print was captured: rolled, plain, live-scan rolled, non-live-scan rolled, and so on. Inked prints rolled on an FD-258 card use specific impression-type codes for "rolled" and "plain impression" depending on the finger position.
  • 14.005 - Source Agency Case Identifier. The case number or transaction reference.
  • 14.006 - Horizontal Pixel Count and 14.007 - Vertical Pixel Count. The image dimensions.
  • 14.008 - Horizontal Pixel Scale (HPS) and 14.009 - Vertical Pixel Scale (VPS). The resolution in pixels per inch, one for each axis. This is the field that makes Type-14 "variable-resolution" - HPS and VPS are written into the record rather than assumed.
  • 14.011 - Compression Algorithm. Identifies which algorithm compressed the image data: WSQ, JP2 (JPEG 2000), or others defined by the spec.
  • 14.013 - Finger Position. Which finger the image corresponds to. The FBI's finger-position codes number the ten fingers from 1 (right thumb) through 10 (left little finger), with additional codes for slap captures (e.g., 13 for the right four-finger slap, 14 for the left four-finger slap, 15 for both thumbs).
  • 14.022 - NIST Quality Metric (NQM). The NFIQ 1 quality score for the print, on a 1–5 scale. Carried per finger inside slap records.
  • 14.024 - Fingerprint Quality Metric (FQM). A newer quality field that can carry an NFIQ 2 score (0–100) along with an algorithm identifier.
  • 14.999 - Image Data. The actual compressed fingerprint image, as a binary blob. This is where the bulk of the file's byte count lives.

Each Type-14 record bundles the raw biometric data with the instructions needed to parse it correctly. Without these metadata tags, the matching system could not determine the scan resolution, identify the compression algorithm, associate the image with the correct finger, or assess quality scores. The metadata ensures the transaction complies with federal ingestion standards.

WSQ vs. JPEG 2000: Specialized biometric compression

The two compression algorithms an EFT file uses are both lossy, and both exist for a specific reason: raw 500 PPI fingerprint images are large, and general-purpose compression algorithms damage the ridge detail that the FBI's matcher relies on.

WSQ (Wavelet Scalar Quantization) was developed in the early 1990s by the FBI, Los Alamos National Laboratory, and NIST specifically for 500 PPI grayscale fingerprint compression. It achieves roughly 15:1 compression while preserving enough ridge detail for automated matchers to extract minutiae reliably. WSQ is the compression algorithm used in every Type-4 record and in most Type-14 records at 500 PPI.

JPEG 2000 (JP2) is an international standard maintained by the ISO, not the FBI. The FBI certifies specific JPEG 2000 implementations for fingerprint compression at 1000 PPI and above. JPEG 2000 uses a wavelet-based approach broadly similar to WSQ, but it's designed as a general-purpose image codec and handles higher resolutions and color imagery that WSQ doesn't.

In practice: EFT files with 500 PPI fingerprints (the FBI minimum, and what SLAP & ROLL generates from a scanned FD-258) use WSQ. EFT files from modern livescan hardware capturing at 1000 PPI use JPEG 2000. Either is a valid compression identifier in field 14.011, and either is accepted by the ATF eForms portal and the FBI's NGI intake.

Why the ATF eForms portal cares about the file format

The ATF eForms portal enforces strict upload criteria: the file must use the .eft extension, comply with the FBI EBTS standard, specify the FAUF (Federal Applicant User Fee) transaction code in the Type-1 record, and remain under 12 MB. Files meeting these criteria are accepted by the portal during application submission.

This format is mandatory because the ATF routes fingerprint background checks to the FBI for processing. The FBI's Criminal Justice Information Services division publishes the EBTS spec to ensure that biometric data from various agencies, livescan terminals, and software tools arrives in a uniform, parseable structure.

Consequently, when SLAP & ROLL or other capture systems generate an EFT file, the output is designed to satisfy the FBI specifications required by the portal. A file that complies with the FBI's EBTS standard naturally satisfies the ATF's upload validation.

How to open an EFT file yourself

The best way to internalize all of the above is to look at your own file.

SLAP & ROLL ships a free browser-based EFT editor that parses the records, renders the images, and shows every field in every record. You can open any EFT file you have on hand - whether it was generated by us, by a kiosk, by a livescan operator, or by a mail-in service - and see the Type-1 header, the Type-2 demographics, and each Type-4 or Type-14 fingerprint record with its fields laid out. The editor runs entirely in your browser; your file never leaves your device.

If you want to go deeper, the authoritative references are:

Ultimately, an EFT file is a structured database record defined by federal specifications. It is designed to bundle biometric data, demographics, and formatting metadata into a single package compatible with agency matching systems. Software tools, kiosks, and livescan devices are simply different interfaces used to produce this standardized transaction file.