9F4B

Signed Dynamic Application Data is the card's own digital signature, computed fresh for this specific transaction using the private key that corresponds to the public key certified in 9F46 - this is the field that actually delivers on DDA and CDA's promise over SDA: proof that this transaction, not just this card's static data, came from the genuine card. The terminal verifies it using the ICC public key it reconstructed from 9F46, plus 9F47 and, if present, 9F48, and because the signed content includes transaction-specific data, a captured 9F4B from one transaction is cryptographically useless if replayed in another - exactly the replay weakness SDA's static signature (93) can't address. It only travels in template 77, the modern GENERATE AC response, which matches its role: CDA in particular ties this signature to the same GENERATE AC step that produces the Application Cryptogram (9F26), binding data authentication and transaction authentication into a single cryptographic operation. A terminal that accepts a transaction as DDA/CDA-verified without actually validating 9F4B against freshly-reconstructed key material has effectively downgraded the transaction to no data authentication at all, silently. See EMV Contactless Book C-2 and EMV 4.4 Book 2.