[bop-devel] BOP-FraudPrevention ?
Bowen, Peter
pbowen at corp.untd.com
Wed May 16 05:00:12 PDT 2007
I've been thinking that fraud looks similar to other fraud. I haven't had time to do it, but a beysian like filter could be effective... Like order spam... Something like spamprobe for credit cards.
-Peter
-----Original Message-----
From: Ivan Kohler [mailto:ivan at 420.am]
Sent: Tuesday, May 15, 2007 09:50 PM Pacific Standard Time
To: Development of the Business::OnlinePayment perl modules
Subject: Re: [bop-devel] BOP-FraudPrevention ?
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
_______________________________________________
bop-devel mailing list
bop-devel at 420.am
http://420.am/cgi-bin/mailman/listinfo/bop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://420.am/pipermail/bop-devel/attachments/20070516/b2914d5b/attachment.htm
More information about the bop-devel
mailing list