9F10 的条目都只有一行：发卡行应用数据——私有格式。这话没错，但当争议单的关键就压在 DE55 里这十几个字节上时，一句「私有」等于什么都没说。实际上大多数 IAD 都落在少数几种卡组织布局里，而每种布局的核心都是同一块货：CVR（Card Verification Results，卡片验证结果）——卡片视角的 TVR。想知道「卡片当时是怎么判断的」，只能看这里。
EMV Book 3 给 9F10 的全部定义就一句：发卡行应用的私有数据，最长 32 字节。它跟着密文一起走在 DE55 里，但和 TVR、TSI 不同，它根本不是写给终端看的。IAD 是卡片写给自己发卡行的便条，中间所有环节——终端、收单、卡组织——都只负责原样转发，不负责读懂。
这张便条之所以存在，是因为发卡行主机没法凭空验 ARQC。要核对密文、给这笔交易下结论，它得知道三件事：这张卡的密钥由哪把发卡行主密钥派生（DKI / KDI，密钥派生索引）、密文是用哪套算法配方算的（CVN，密文版本号）、以及卡片在交易过程中自己验了些什么（CVR）。这三样，加上发卡行自己想塞的其它东西，就是 IAD。
这是所有一行式手册都跳过、但真正要紧的部分：IAD 的内部结构随它携带的 CVN 而变，而且发卡行可以完全自定义布局。下面给出的字节地图，是常见实现的读法——Visa 的 VIS、Mastercard 的 M/Chip，再叠加发卡行的个人化选择。凡是取值会影响判断的场合，以你的对端（发卡行或卡组织）提供的规范为准，不是这一页，也不是任何一张通用表。这不是免责套话，而是这个字段的本性：拿一张表硬套所有卡，得出的结论看着精确，其实是错的。
工具能诚实做到的，是把字节拆开、并根据形状提示可能的布局。我们的 IAD 解析工具用两条摆在明面上的启发式规则：首字节 06 按 Visa 格式 0/1/3 读，总长 18、20 或 26 字节按 Mastercard M/Chip 候选读。两条都不中的值，只给逐字节网格——对完全自定义的配置来说，这才是唯一可靠的解读。
常见的 Visa 布局带长度前缀：字段以 06 开头，宣告后面跟 6 字节 Visa 自主数据，后面还可能再挂一段带长度前缀的发卡行自主数据。
| 位置 | 内容 | 含义 |
|---|---|---|
字节 1 | 06 | 长度指示：后面跟 6 字节 Visa 自主数据 |
字节 2 | DKI | 密钥派生索引——这张卡的密钥由发卡行哪把主密钥派生 |
字节 3 | CVN | 密文版本号——密文用哪套算法算的，也是解读 CVR 各位的钥匙 |
字节 4–7 | CVR | 卡片验证结果，4 字节；其自身首字节 03 是 CVR 长度 |
字节 8 | 长度 | 发卡行自主数据的长度指示（有第二段时才出现） |
字节 9+ | IDD | 发卡行自主数据——含义由发卡行个人化方案决定 |
拿 7 字节的 06101203A40000 贴进 IAD 解析工具：长度指示 06、DKI 0x10、CVN 18（0x12）、CVR 为 03A40000。长一点的 06101203A4000011223344 前 7 字节解法相同，字节 8（0x11）被读作第二段的长度指示，223344 是发卡行自主数据。银联卡采用与 Visa 类似的结构，所以这套切法对银联卡也是合理的第一猜测。
M/Chip 没有长度前缀，上来就是正文——所以工具只能靠总长（18、20 或 26 字节）来认它：
| 位置 | 内容 | 含义 |
|---|---|---|
字节 1 | KDI | 密钥派生索引 |
字节 2 | CVN | 密文版本号 |
字节 3–8 | CVR | 卡片验证结果，6 字节 |
字节 9+ | — | DAC / IC 卡动态数 / 明文计数器——取决于 M/Chip 版本和个人化配置 |
把 18 字节的 0110A50003220000000000000000000000FF 丢进工具：KDI 0x01、CVN 16（0x10）、6 字节 CVR 为 A50003220000，尾部按 M/Chip 版本读作 DAC、IC 卡动态数或明文计数器。注意偏移：CVR 比 Visa 切法早开始一个字节，还长出两个字节。
这几个偏移就是全部要害，而最经典的误读就是拿 Visa 的表去套别家的卡。下图取同一串 18 字节——06101203A400000A112233445566778899AA——按两种布局各切一遍：
把这个值喂给解析工具，它给出的是 Visa 切法：两条规则同时命中时，首字节 06 优先——同时它会把这次拆分标注为推测，因为事实就是推测。真正能定夺的信息在字段之外：先查 AID，再选表。如果 AID 和 IAD 的形状对不上，两边都先别信，搞清原因再说。
值得费这番功夫的货是 CVR（卡片验证结果）。TVR 记录的是终端在这笔交易里看到了什么；CVR 记录的是卡片自己判了什么——上一笔联机交易有没有正常完成、脱机 PIN 验得怎么样还剩几次、发卡行认证过没过、执行了几条发卡行脚本。当终端日志和发卡行的说法对不上时，TVR 是你这边的案卷，CVR 是对方那边的证词。「卡片当时是怎么判断的」这个问题只有一个出处，就是 9F10。
但有一样东西这篇文章和解析工具都不会给你：一张通用的 CVR 位表。因为 CVR 的位定义由紧挨着它的那个 CVN 选定——VIS 的 CVN 10 和 CVN 18 给同一个位置赋予不同含义，M/Chip 的 6 字节 CVR 又是另一套体系。拿错表解出来的是一本正经的胡话：一张从没输过 PIN 的卡，能解出「PIN 次数超限」。先读 CVN，再去卡组织规范或发卡行个人化文档里找对应的那张表——找你的对端实际实现的那张。
IAD 最出活的场景是和发卡行掰扯的争议单。终端侧看起来莫名其妙的拒绝，解释往往就藏在这里：联机之前脱机 PIN 已经失败过、上一笔的发卡行认证没过、某个脚本计数器从来没动过。三个习惯能把它用出价值：