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.
actually, arguing that fraud filters must be private is interesting. Would you make the same argument about keeping encryption algorithms private? :) The two concepts are similar but not exactly the same. Unlike encryption algorithms, a fraud filter is not bullet proof. It is just an alert mechanism. So, yeah, it probably needs to be kept secret.
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.
(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
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/
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.
It's not true that zip codes are unique to a particular city and state in the United States. Where I live, for instance, several couple of cities share the same post office - and thus zip code. It does cause confusion in some instances, especially with address verification.
There have been times when I have had to put the wrong city in my address because of zip code enforcement. Fortunately, the post office does a pretty good job delivering anyway.
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.
For cases where one zip code covers parts of two or three cities, it would also be possible to present some kind of drop-down to select the city. This should still be much faster and less error prone than typing, and it only applies to a tiny fraction of zip codes.
Good point, but as far as I've seen, zipcode seems to identifies locality good enough. If you have the right zipcode it doesn't make a material difference for either sending/receiving mail or for credit card checks.
Given postal code, asking for city and state is pretty much useless.
This view is US-centric. Others have pointed out that there are cases even in the US where this may cause confusion.
But for me, the bigger problem is that asking for state is counter-productive. The state and country are the same thing for me. Some sites force users to put something in the state field, whatever country. Other sites explicitly check the country and reject input if there is a state specified for a country that doesn't have them. You never know. Most of the time it fortunately makes no difference. But it's a slight annoyance.
We're thinking of actually open sourcing this iframe - it took a lot of work and analytics to get it to where it should be and we think the community could benefit.
I would definitely like to see this open sourced, ideally not in an iframe, and maybe with a few different variants for collecting different amounts of information, for those with different priorities among security/convenience.
Actually, I think asking for the customer name in your payment form is good. It's what's expected and it gives you more information to match against (i.e. the name in your customer database to the name they link to the card).
Seems to me that the form itself is just one small corner of a larger battlefield and the real trick to using it effectively is threefold.
For users, it's about creating a user experience that is comforting and normal enough to gain user confidence and easy/frictionless enough to make the transactions painless.
For merchants it's about information gathering and screening. It's about being able to collect information about the user's payment card and comparing it to what you already know about the prospective buyer and depending on the your size and fraud levels, the form may also be a point where you make it more difficult to programmatically try cards (i.e. randomized form fields, rate limiting, err... captcha).
For #1, the zip code 42223 spans Christian KY and Montgomery TN. The zip code 97635 spans Lake OR and Modoc CA. 95961 can be the city of Arboga, Olivehurst, or Plumas Lake.
The mapping isn't unique. I think the best you can do is restrict your pulldown to the possible choices. Even then, sometimes there are small cities and towns that you don't expect.
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 support@balancedpayments.com 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)
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.
