npcomplete's comments

Absolutely. There's nothing wrong with differing from the interviewer so long as you can clearly articulate the issue.

Encryption algorithms are fraud filters are very very different (as you already mentioned). Most functions used are one way and the inverse is (to the best of our current knowledge) intractable (or to be more technical - their complexity class is unknown and widely thought to be intractable). So, it can be made public. Requesting fraud filters to be made public is like asking Google to make their spam detection public. This can (and probably will) defeat the purpose.

Happy to hear this about Mozilla and I hope other companies follow the same culture. Balanced cannot possibly be completely open in the sense you refer to since it is a financial services company. For example, the fraud filtering algorithms/rules cannot be open to public (for obvious reasons). So, there are limits. To this end, "open" must not be treated as binary. Balanced is much more "open" than most other companies since it opens up (among possibly others): 1. It's dashboard (which is core product) 2. Specs (again, core product) and openly discusses product features - including limitations in public.

(I work for Balanced) Just a simple thing to keep bots and Nigerian princess promising giant riches for small exchange of name/address/ssn/bank account/horoscope off. Also, we have explicit emails from people who decoded and it and found it fun. So, yes, this was a data driven decision

Thanks for bringing this up. I responded here: http://news.ycombinator.com/item?id=5339604. There's no unique way of solving this and you have a pretty good suggestion

Good to know and thanks for the input. I would assume this is a corner case and does not represent a typical situation. In this case, one could just send in the zip code for avs match. AVS will return specific codes related to postal code match. Here gain there's a tradeoff, I don't see the point of compromising the UX for 99% to cover the 1% case.

You can save a bunch of fields in the form (and has nothing to do with fraud):

1. Given postal code, asking for city and state is pretty much useless. There is a unique mapping from postal code -> city, state. Maxmind used to have free db, but you can download it from geonames here: http://download.geonames.org/export/zip/

2. You don't need to ask for card type given card number. Again, simple regex. Reference: http://stackoverflow.com/questions/72768/how-do-you-detect-c...

3. Only American Express supports name verification. Most other banks don't. So, asking name is pretty much useless. If you already have the customer name in you database, use that to fill them in.

4. Things like 'Company' are just not needed.

5. Phone verification is again something supported by very few banks.

That just cut down 7 fields with no compromise on fraud.

Also, any good payment processor will let you store card information (in a secure manner adhering to standards set by Visa, a.k.a being PCI complaint). So, you could just display the last four of the card along with card type and charge them at a later point of time (think Amazon checkout).

So, payment forms need not be nearly as bad as the one pointed out in OP. But, sometime bad design choices and legacy thinking comes in way.

I work for Balanced Payments. When we were PoundPay (previous avatar of our product), we used to serve the payment frame via iframe. Our form looked like this: http://imgur.com/wF2Z2qZ

It encapsulates lot of points I discussed earlier.

Not sure what makes you think her job is not 'real'. Her title rocks and there's nothing unreal about it. And BTW, here are some 'real world titles': Jolly Good Fellow Intergalactic Federation King Almighty and Commander of the Universe. Chief Culture Officer. FYI, above titles are from one of the smartest companies on the planet - Google. Source: http://www.businessinsider.com/11-google-job-titles-you-wont...

(I work for balanced) The buyer and seller were the same person. Instead of us focusing on the actual case and investigating it, the fraudster effectively distracted us on something completely different.

May be, we should have clarified it in the end. But, thanks for pointing it out.

(I work for balanced, I wrote the blog and handle fraud) I am sorry you had to deal with this. Of course, we look at all other signals and of course we use machine learning. What I posted was partial information. the list by no means is complete. When dealing with opening up on fraud, you deal with two conflicting things - (1) If you open your algorithms/data and make it completely open source, the fraudsters have all the access as you do and (2) If you shut down all access and keep it closed, there's no exchange of information. Most payment processors opt for (2), we really wanted to strike a middle ground. If I can't expose the fact '@apple.com' email address is more trustworthy than a throwaway email address and regard this piece of information as the bed rock of fraud protection, I am nuts. Summary: you expose something, gain knowledge, hide the rest. There are several more signals we look at when dealing with fraud (esp. digital goods). We have built a machine learning system that has learned (is learning) from our data. We also built visualization layers on top of that. Send us an email at [email protected] and I will provide more information.

(balanced employee) You are 100% on the money. Customer support part of user experience is largely controlled by the marketplace. We would be happy to provide any guidance in this regard.

(I wrote the post) I am not aware of any. That's actually one of the motivations to do this. Someone needs to start !

(I wrote the post) Thanks! There are certain aspects of fraud which can be open and will definitely help the community of anti-fraudsters. This was our way of contributing something back.

Chad (disclaimer: I work for Balanced https://www.balancedpayments.com/ and we handle the payment processing for gittip. I mainly focus on fraud). It's wonderful you are doing this. It enable forms of donation other than via github. Not sure, what information you collect via twitter login, but I would watch out for:

1. Twitter account creation date 2. Number of followers/following 3. Location information (if available) 4. # of tweets

Esp. (1) and (2) would be very useful. When I last analyzed the github accounts, almost all fraudsters had relatively recent github accounts and (unsurprisingly) zero/almost zero followers for their repos. As with most things related to fraud, these do not guarantee fraud protection, but serve as very strong signals.

Can we get the table of contents?