> Ah, so you're talking about the edge case where the terminal claims to have, but did not actually, perform ODA? Yes, that's somewhat of a gap in the EMV protocol. As I've mentioned in my other comment, I could see CDA eventually becoming mandatory, as well as keeping the entire CDA output terminal-side. That trace does provide non-repudiation.
No, not even that. Remember that transaction settlement is based only on what’s actually sent over the network. All kinds of stuff can happen between the terminal and card, but if that info isn’t actually sent over the network, it may as well not exist (from a settlement perspective).
So we have no reason to believe that CDA wasn’t performed. Instead we had a network participant effectively mutating presentment messages so they no longer matched the cryptogram produced by the card. We already knew the presentment were mutated because they indicated our card were approving transactions offline that they were configure not to approve. But during the dispute process, we had the acquirer claim that they had valid cryptograms, so we had no right to chargeback. In turn we actually had to go and start decryption cryptograms, and as we expected, the decrypted cryptograms didn’t match the transactions they had been sent with. The transaction amounts didn’t match up.
The sloppy processing was a little more complicated, and was a bit more complex than just badly configured terminals. The types of transactions in question where fairly complex multi-step transactions, that to process correctly required properly supporting some of the slightly more niche network features by both issuers and acquirers. Due to a lack of proper support by many issuer (although we had proper support), the acquirer took some shortcuts to reduce customer complaints, but drastically increasing their own risk exposure. Unfortunately for them an OCG had figured out they could exploit this nuance.
I doubt the OCG had any understanding of the underlying transaction mechanisms. They had just figured out if they followed a specific set of steps, they got free money (or something trivially easy to covert into money).
But to deal with the losses the acquirer was seeing. Some bright spark over there decided they would start forging network messages to try and cover their losses, and shift them onto us. Unfortunately for them, we were more technically competent than most issuers, and more importantly, really couldn’t afford to take the losses.
> I suspect that all of that is a big reason why the networks don't love offline processing if it can be avoided.
Nah the networks don’t care. They get paid regardless, and they’re never on the hook for any losses that might appear. But certainly offline transactions carry a lot of additional risks for issuers (notably it’s impossible to ensure funds will exist to cover any offline payments that might have happened), which are easily mitigated by simply configuring your cards to always go online, and thus shifting the liability on to the merchant if stuff goes wrong.
> And I couldn't agree more to your last paragraph – the industry does have an unfortunate history of propping up questionable security engineering with legal threats. But I'm slightly more optimistic on EMV, at least some implementations: Decades later, we can actually have some nice things :)
Eh, ultimately everything in this world boils down to who has the larger capacity for violence, regardless of what may be correct. Thankfully in most countries we’ve replaced violence with government, police and courts. So now it’s more a question of who has the larger capacity to hire lawyers.
Even if the technical layer supported non-repudiation, I doubt it would make much difference in a court of law. It’s extra evidence for sure, but ultimately most of these things are resolved via settlement based on what makes the most financial sense for the parties involved, which includes many more factors than just the state of the transactions are the heart of such a dispute.