[bop-devel] BOP-FraudPrevention ?

Ivan Kohler ivan at 420.am
Tue May 15 21:49:34 PDT 2007


On Tue, May 15, 2007 at 09:37:03PM -0700, Jo Rhett wrote:
> Ivan Kohler wrote:
> >> Anyone else interested in this project, or am I doing it myself?
> > 
> > See Business::FraudDetect for the framework.
> 
> Hm. Wow, apparently I didn't google correctly.  But this appears to be a 
> generic wrapper, without any mojo of its own, yes?

Right.  There's some mojo for an existing provider in B:FD:preCharge.

>  So... my proposal would be to implement an class for FraudDetect to 
> use which is generic and non-provider, specific -yes?

Right (presumably anything that wedged in as its own separate B:FD 
module is non-provider-specific).

> > It does seem to me that you haven't considered the non-technical hurdles 
> > in offering a distributed fraud detection database.  Getting the legal 
> > framework in place for people to share checksums with a central 
> > non-profit seems like a larger amount of work than writing some roughly 
> > working code.
> 
> I think you're thinking farther than I am.  I simply meant to do
> 
> 1. Check for rate of queries from a given visitor
> 2. Check for number of false positives from unique visitor
> 
> Frankly, that's all it appears that most of the expensive packages are 
> doing.  So I wanted to make this available to everyone.

Oh, okay.

> I am perhaps lacking insight into how checksums could be used in this 
> circumstance.  The only thing I think a central DB could do is identify 
> "known compromised cards" so that anyone who tries to use one of the 
> cards would be identified quickly.  That would be useful!

Right.  Distributed Checksum/hash database of bad cards (and other 
info).

> BUT... the socio-political responsibilities of managing that data 
> don't interest me in the least.
> 
> ...you can read that as "scare the beejesus out of me" and be right ;-)
> 
> So no.  Very simple rate-of-inquiry ratio to failed transactions 
> detection.   Simple thing to code, zero centralized data.

Sure, go for it.  Seems like it could be included in the base B:OP 
distribution along with B:FD and B:FS:preCharge if you like.

How were you thinking of storing the state information locally?

-- 
_ivan


More information about the bop-devel mailing list