每次 GENERATE AC 都会带回的一个字节。最高两位说卡片生成了哪种密文——拒绝、批准，还是交给发卡行定；低位说要不要通知发卡行、原因是什么。贴进来，直接看判决。
b8 b7 承载所有人最关心的答案——tag 9F26 里装的是哪种密文：00 AAC，卡片拒绝；01 TC，卡片批准；10 ARQC，卡片要发卡行来定。11 是保留值（早期 EMV 在这里定义过 AAR，后来废弃了）。b6 b5 保留，应为零。b4 是卡片要求终端给发卡行发通知报文，b3–b1 是原因：0 未提供信息、1 不允许该服务、2 PIN 尝试次数超限、3 发卡行认证失败。
第一次 GENERATE AC 时，终端按自己行为分析的结论开口要——TC、ARQC 或 AAC。卡片可以降级这个请求（要 TC 却返回 ARQC 或 AAC），但永远不能升级：终端想联机核实的，卡片没权直接批。联机交易在拿到发卡行响应后还有第二次 GENERATE AC，那次的 CID 才是终局——TC 或 AAC。
CID 永远给随行的密文贴标签：9F27 和 9F26 是一对，DE55 里应该同时找到两个。只有密文没有 CID 的数据是没法核验的。
清算记录里的 TC 是卡片签过字的批准——脱机批的，或者发卡行说了 OK 之后批的。原因码为 2 的 AAC 说明卡片自己因 PIN 超限拒了：这笔交易很可能压根没到发卡行主机，别去授权日志里白翻。带 advice 位的 AAC 表示虽然没联机、卡片也要求把这事报给发卡行——终端悄悄丢弃 advice 的话，这条线索就断了。至于记录里躺着一个从没等到联机应答的 ARQC，那是死在半路的交易，不是拒绝。