77
Response Message Template Format 2Response Message Template Format 2 is the flexible, explicitly-tagged sibling of Response Message Template Format 1 (80, referenced alongside it): rather than a fixed AIP-then-AFL byte layout, it's a proper constructed BER-TLV template that can carry the Application Interchange Profile (82) and Application File Locator (94) as explicitly tagged fields, in whatever order, alongside whatever else a card chooses to return - which is exactly why it's also the template GENERATE AC uses to return the Application Cryptogram (9F26) and its companions, a job format 1 was never designed to do at all. Because nearly every tag covered in this dictionary that appears in a GPO or GENERATE AC response can arrive wrapped in 77, it's arguably the single most load-bearing constructed template in the whole EMV transaction flow - a parser bug in how a terminal walks 77's nested TLV structure doesn't corrupt one field, it potentially corrupts the terminal's read of the entire response, which is why 77-parsing correctness is foundational to everything downstream of it. See EMV 4.4 Book 3.
Interactive decoder
Paste a hex value for this tag to decode it in your browser. Nothing is sent anywhere.
This tag is not a bitmap; the decoder shows a format-based interpretation.
Decoded example
Tag 77 is the wrapper the card uses to answer GET PROCESSING OPTIONS and GENERATE AC when it wants to be explicit about what it is returning. Where its sibling Response Message Template Format 1 (80) packs the Application Interchange Profile and the Application File Locator into a fixed layout with no internal tags, Format 2 returns a constructed template whose value is a sequence of properly tagged TLV objects — and that explicitness is what makes it the format modern kernels and multi-application cards prefer.
Reading it is exactly what the decoder on this page does: open the value as nested BER-TLV and list the objects inside. A typical response carries the Application Interchange Profile (82), the Application File Locator (94), and on GENERATE AC the Cryptogram Information Data (9F27), the Application Cryptogram (9F26) and the Application Transaction Counter (9F36). Because every element is tagged, the terminal finds each one by tag rather than by byte offset, which is robust against cards that omit or reorder fields.
The reason this matters is that a parser bug here corrupts the entire downstream transaction. If the terminal mis-parses the boundary between two TLV objects inside 77 — reading the length wrong, or stopping early — it will attach the wrong value to the wrong tag, and every subsequent decision (which authentication method, which records to read, which cryptogram type) is built on scrambled data. The symptom is usually a cascade of "field missing" errors on a card that is perfectly conformant.
The integration trap is assuming every response uses Format 2. The card chooses between Format 1 (template 80) and Format 2 (template 77) based on its own preferences, and a terminal that only handles one will misread the other. The correct approach is to read the outer tag of the response and dispatch: if it is 77, parse as constructed TLV; if it is 80, read the fixed AIP-then-AFL layout. Hardcoding one path is the most common cause of "works on some cards, fails on others".
One nuance for decoders: 77 is constructed, so its value is the concatenation of the child objects' bytes, and parsing it requires a real BER-TLV parser that handles multi-byte tags (9F26, 9F36), long-form lengths and nested templates. A naive parser that assumes single-byte tags will misread every 9Fxx object inside.
Properties
| Tag | 77 |
|---|---|
| Name | Response Message Template Format 2 |
| Format | Binary |
| Length | variable |
| Source | Card (ICC) |
| Templates | — |
| Books | EMV 4.4 Book 3 |
Frequently asked questions
- What is EMV tag 77?
- Tag 77 is Response Message Template Format 2: a constructed BER-TLV template the card uses to wrap its responses to GET PROCESSING OPTIONS and GENERATE AC. Unlike Format 1 (tag 80), its value is a sequence of explicitly tagged TLV objects (82, 94, 9F26, 9F27, 9F36...), so the terminal finds each field by tag rather than by byte offset.
- What is the difference between tag 77 and tag 80?
- Both wrap card responses, but they pack the content differently. Tag 80 (Format 1) uses a fixed layout where the AIP and AFL sit at known byte offsets with no internal tags. Tag 77 (Format 2) uses constructed TLV, so every field inside is explicitly tagged. The card chooses which to use; a terminal must handle both.
- How do I parse the contents of tag 77?
- Open its value with a BER-TLV parser, the same way the decoder on this page does. Each child is a tagged object — read its tag, length and value, then recurse if the child is itself constructed. Handle multi-byte tags (9F26, 9F36) and long-form lengths; a parser that assumes single-byte tags will misread every 9Fxx object inside.
- Why do I get "field missing" errors on a card that should be conformant?
- Usually a boundary mis-parse inside 77. If the terminal reads a length wrong or stops early, it attaches the wrong value to the wrong tag, and every downstream field lookup fails. The card is fine; the parser is scrambling the TLV boundaries. Test against a known-good hex dump to isolate it.
Sources
- EMV_v4.4_Book_3_Application_Specification, p. 200
Receive site updates
Subscribe to receive site updates directly to your email
We won't send spam. You can unsubscribe at any time.