nexo FAST calls it the Terminal Configuration Data: a stack of tables, one per subject. Each top-level block in the file – e2, eb, f0… – is one of those tables, and inside them the same DFxx tag does not mean the same thing from one table to the next. This tool resolves every field within its own block, cites the section it comes from, and decodes the ones that carry a bit table.
File format read: sepaConfig (XML).
The configuration is a stack of tables. Each top-level block is one of the tables defined by nexo FAST, and its XML name is the tag from the specification: <e2> in the file is tag E2 in the dictionary. Here is what each one is for.
Three vocabularies sit on top of the same object, and only one of the three comes from nexo. Worth knowing which one you are using, and in front of whom.
catm.003 AcceptorConfigurationUpdate, split into data sets and grouped into TerminalParameters, ApplicationParameters, AcquirerParameters, MerchantParameters, SecurityParameters. When it travels as a file, the nexo naming convention even prefixes it “PA”, for Acceptor Configuration.A field can also come from another nexo specification without being in nexo FAST: the parameter set version number, present on every record, is a terminal management notion described by the TMS Message Usage Guide. The inspector labels it “nexo TMS”, not “vendor field”.
Why it matters: calling Terminal Configuration Data a “sepaConfig” works perfectly well between people using the same tool, and stops working the moment you open the specification or talk to another supplier.
Three blocks you will see in a file match no table in the specification. But it is the container that is not nexo, not the contents: the fields they carry are almost all normative. The inspector tells the two apart instead of labelling everything “vendor”.
Each block has its own entry table, so DFxx tags are local to the block. The same tag changes meaning from one table to the next, and nothing on screen warns you. A decoder that resolves tags flat gets it wrong without saying so: that is the main trap in these files.
DF03 means Supported Services in the application profile selection table, but CA Public Key Algorithm Indicator in the public key table, and Application Label in the per-AID kernel table.DF01 has fourteen different meanings depending on the block: profile AID, terminal RID, acquirer number, limit set identifier, DCC prefix…DF10 on its own is Service Settings, but DF10 inside the selection table is Application Profile Kernel ID. Same tag, two definitions, in the same file.A tag is a BER-TLV identifier (ISO/IEC 8825-1, carried over by EMV Book 3 Annex B). Its first byte states its class and whether it is primitive or constructed, and that reads without any dictionary. But the allocation of private class tags is standardised nowhere: whoever writes the application picks them. A DFxx no dictionary knows is therefore not a gap, it is a proprietary tag.
The tables above say where a parameter is stored in the file. The specification says at which level it is defined, which is not the same thing. Two levels carry almost everything (§4.2):
Precedence rule: a few parameters exist at both levels. When they do, the application profile wins and replaces the terminal value. Terminal Capabilities is the example the specification gives. Reading only the terminal-level value can therefore give you a wrong answer.
Normative names stay in English: they are the identifiers you use to find the line in the specification. Sources: the data dictionary of for the tables and the meanings, ISO/IEC 8825-1 and EMV 4.3 Book 3 Annex B for tag encoding.