BillGuard

Now that would make a juicy, tempting target for a hacker.

For instance, there are consumers who if they decide they no longer what to subscribe to your service don't bother trying to cancel--they just call their bank and claim they don't recognize the charge, and so generate a chargeback to the merchant. (This is bad for the merchant because not only do they have to give back the money, they get hit with a charge back fee in the $15-30 range...in fact they get hit with the fee even if the successfully challenge the charge back).

The idea would be when merchants make a sale, they would report to the service a hash of the credit card number, the amount of the charge, what kind of merchant they are, what kind of good or service was purchased, whether this was an initial charge or part of a recurring service, and whether the charge was accepted or declined. If a customer of theirs charges back or refunds, the merchant would report that, and whether or not it was reasonable.

From this data, the service could develop a profile for each card concerning its refund and charge back behavior. The service could also develop a profile of the merchants, noting merchants that have unusually high charge back and refund rates, and so weight data from those merchants less when developing the card profiles.

Merchants, before accepting a credit card, could query the service and get a report on that card's charge back and refund behavior.

One might note that some of this seems similar to the systems the banks already have in place to detect fraud. It is, but those systems are not for the benefit of the merchant. They are primarily for the bank's protection and secondarily for the consumer's protection. The system I'm suggesting would be for the merchant's benefit and protection.