Fraud prevention for small merchants – an interview

by February 7th, 2011

Last week I gave an interview at, a blog dedicated to small merchants. I really like this market and I also think Mike is doing an amazing job maintaining this blog and creating quality content (and since his readership is growing fast, I believe this potential is not overlooked by merchants!).

Will be happy to hear your opinions about my answers to Mike’s questions, here.

with 0 comments | labels:

Learning the Basics of Fraud

by December 29th, 2010

How do I learn more about fraud? This question keeps popping out in every payment or data meeting I’m attending. The terminology and dynamics of fraud are not only interesting but are also important for any business that creates an incentive for users to try and game the system. Interestingly enough, it also serves as inspiration for consumer facing product managers, when they try to better understand user behavior patterns and how they interact with the product. Fraudsters are, actually, a unique class of users; they have an incentive to try and uncover all the quirks and bugs in your product. When properly tracked and analyzed, their behavior can tell you a lot about your legitimate users as well.

More after the jump…

with 0 comments | labels: Tags: , ,

PayPal Digital Goods Risk Management Talk is Live

by December 14th, 2010

I gave a risk management talk with a few other risk experts in PayPal’s Innovate convention last October. The video is now live and can be found here.

There is also a risk best practices guide I put together with Mike L from PayPal’s risk management team, and can be found here [Careful – PDF!]. Mike is, among other things, in charge of risk management for digital goods and is doing an impressive job.

with 2 comments | labels:

Merchant Fraud: A Nasty Little Secret

by October 31st, 2010

Over the years we’ve been accustomed to talk about risk from buyers. The paradigm was simple: established and new businesses go to ecommerce to go global, expand reach and sell more conveniently to multiple buyers. Since this is a card not present transaction, the retailers are liable for risks of chargebacks and other types of complaints, and they need to protect themselves from fraudulent buyers, flakes and defaults. The barrier to becoming a merchant was pretty high almost everywhere – getting a merchant account required interaction with a bank and documents that at least looked real. The strain in this process meant that becoming a merchant was not a scalable operation for fraudsters who were looking to make a quick gain; buying multiple stolen credit cards and running them through retail websites was much easier. Sure, there were fraudulent sellers on eBay but that was a rather contains phenomenon. This is not the case anymore.

More after the jump…

with 0 comments | labels:

Smart risk management: why the “factory” approach could bring you down

by October 26th, 2010

If you deal with payments in any shape or form, you know you’re going to end up with a “risk management” team. A lot of times it creeps up on you: volume picks up and so you know you need someone to look at orders. If you’re running a small shop it’s most probably going to be you, but a lot of companies just hire one or two folks. These people use whatever tool you have to look at transactions – most times a customer service tool – and make up their technique as they go. With time, and sometimes with chargebacks coming in, you realize that your few analysts can’t review all transactions, so you turn to set up a few rules to make queue and transaction hold decisions. Since your analysts are not technology people you resort to hard coding some logic based on a product manager’s refinement of the analysts’ thoughts, again based on a few (or many) cases they’ve already seen. Not a long while passes, and you realize that the analysts are caught in a cat and mouse game where they try to create a rule to stop the latest attack that found its way to the chargeback report, and put a lot of strain on the engineers who maintain the rule-set. Even after coding some simple rule writing interface the situation isn’t better since the abundance of rules creates unpredictable results, especially if you allowed the rules to actually make automated decisions and place restrictions on transactions and accounts.

More after the jump…

with 0 comments | labels: