[114110] in cryptography@c2.net mail archive
Re: Lack of fraud reporting paths considered harmful.
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Sun Jan 27 12:13:20 2008
Date: Sat, 26 Jan 2008 23:11:25 -0500
From: Anne & Lynn Wheeler <lynn@garlic.com>
To: "Perry E. Metzger" <perry@piermont.com>
CC: cryptography@metzdowd.com
In-Reply-To: <87r6g9fb4h.fsf@snark.cb.piermont.com>
Perry E. Metzger wrote:
> This evening, a friend of mine who shall remain nameless who works for
> a large company that regularly processes customer credit card payments
> informed me of an interesting fact.
>
> His firm routinely discovers attempted credit card fraud. However,
> since there is no way for them to report attempted fraud to the credit
> card network (the protocol literally does not allow for it), all they
> can do is refuse the transaction -- they literally have no mechanism
> to let the issuing bank know that the card number was likely stolen.
>
> This seems profoundly bad. I hope that someone on the list has the
> right contacts to get the right people to do something about this.
>
>
some chance they are doing this to save money on transactions that aren't
likely to be approved ... i.e. rather than be charged for a transaction that
they send thru to the issuer that they are sure to be rejected ... they
reject it upfront.
now the associations have standard procedure to perform "stand-in" when
the network accepts a transaction from an acquirer but isn't able to forward
it to the issuer. stand-in allows the network to decide whether to approve
or reject the transaction using simplified rules. later, when contact is
re-established with the issuer ... the issuer has to be informed of all
the stand-in activity.
a possible simplified mechanism is to be able to generate a simulated
stand-in
report of rejected transactions. the issue then in such a simulated stand-in
role ... for all the reasons that they chose to reject a transaction ...
do they map
into the standard iso 8583 codes for reasons that the issuer would reject
the transaction.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
