An Issuer Identification Number (IIN, more commonly called a BIN) is the first 6 digits of a credit or debit card, and it identifies the bank that issued it – and if you want to know if a number is a real credit card or just a bunch or random digits, it’s a huge help. While credit card numbers do use the Luhn algorithm (mod 10 check) to see if the number is valid, it still produces a huge false-positive rate.
For an application like ccsrch, having this data available would be very handy to reduce false positives when scanning a large file system (scanning a large server produces a huge number of possible hits), but for what I would call fairly misguided reasons, the official registrar of these numbers (the ABA) doesn’t make this data publicly available. As a result many people have pulled together what data they could find and made it freely available.
So I’ll add my name to that list.
I’ve pulled data from many public sources (sorry, I didn’t keep very good notes as to the sources) and cleaned it up to a reasonable point. All told, I’ve probably spent 40 hours or more cleaning this data up and getting it to a usable state. It contains over 60,000 entries, including major credit cards (Visa, MasterCard, Amex, Discover) as well as a few merchant entries.
Each record contains the following:
- IIN
- Type (Mastercard, Visa, Visa Credit, etc.)
- Name (Issuer name)
- Length
Data Quality
It’s not perfect. It’s from public sources so there may be errors, and there are some duplicates from cases where I wasn’t able to determine who the IIN actually belongs to. I’ve also updated for name changes and mergers where possible, but I’m sure I’ve missed a few and there are some where the assets where split, so I don’t know who the correct owner actually is (Washing Mutual being the leading example of this).
In general, I leaned to the side of caution – so if I didn’t know for sure, I left the duplicate in.
If you need absolutely correct data – contact the ABA, they are the only source that can give you the completely accurate listing. If you need to have a decent idea if a number is valid for most cases – I would say that this data is good enough.
Warranty
Just to make it really, really, really clear: There is no guarantee that this data is accurate, that it won’t cause to lose your job, cause your house to burn down, or cause Rebecca Black’s Friday to get stuck in your head (yup, you’re welcome 
).
Copyright
Based on my understanding of US copyright law, it is my understanding that this data is not subject to copyright as it is a compilation of facts and doesn’t constitute an original expression. Thus, to the best of my knowledge, this data is in the public domain.
Download
Here (zipped CSV)
A couple of days ago I was sent a link to Robert Cringely’s latest treatise: The second coming of Java – and to say I disagreed was a bit of an understatement. To me, it represents a fundamental flaw in his perception of developers, and more importantly the economics of software development.
The key to Cringely’s argument comes down to this:
When SSDs gain enough capacity there will be a shift from the Ruby world back to the Java world. Not for prototyping, because, well, it’s prototyping. But simply because the statement “Ruby is incredibly slow but I don’t care because my database is slower” will no longer be true.
What he’s missing here is the real reason people use frameworks like Rails; it’s not about it being Ruby, or being the latest cool thing – it’s about developer productivity. That’s it, and that’s all there is to it – Rails allows a developer to do more in less time. That’s one of the key reasons so many Java web developers jumped ship (though I can think of a few others), and what pushed Microsoft to invest so heavily in their MVC framework.
I could fully rehash the argument, but in what I consider to be one of Jeff Atwood’s best articles, Hardware is Cheap, Programmers are Expensive, he covers a key point to my argument – developer time is vastly more expensive than hardware. Atwood’s take on the issue is clear:
Clearly, hardware is cheap, and programmers are expensive. Whenever you’re provided an opportunity to leverage that imbalance, it would be incredibly foolish not to.
When there’s a choice between developer productivity, and spending money on hardware – the conclusion should be the same. It’s much cheaper to throw more hardware at a slower framework than it is to invest more developer time in a faster framework. For any non-trivial application, throwing more front-end servers at it will always be cheaper than slowing the development process down with a non-productivity-centric toolkit.
It’s simple economics; server hardware is getting faster and cheaper, developer time is only getting more expensive.
This morning, the latest version of my favorite forum software, bbPress, was released. While this is a beta and not a final release, it’s still a major event for the project: this release is in the form of a WordPress plugin, instead of a stand-alone application as it’s been in the past. In December 2009 I wrote about this decision – and at the time I was rather disappointed with the change in direction; but now my views have changed. I’m also excited to see that Matt and his company, Automattic have decided to invest the time and money needed to make this happen; there for a while it looked like bbPress really was dying.
Thanks to services like StackExchange and its numerous clones, it seems the days of standalone forums are numbered; when combined with the increasing strength of WordPress as a full-blown CMS, this move actually makes a lot of sense.
I’m excited both as a user and developer – this opens many new doors from both perspectives, and will certainly increase adoption of the software, as integration with the current version is a bit tricky.
Congratulations to the entire team on this release; it really is a major milestone for the project!
Earlier today, a rather surprising tweet hit, being retweeted at least 80 times, including by a few rather influential people in the .NET world:
@RoyOsherove
Roy OsheroveMicrosoft announces to mvps at #msteched that VB6 will be released as open source on codeplex end of june! w00t
FavoriteRetweet
Needless to say, that’s not an announcement that anybody was expecting, but given the talk going on at the time – and the high-profile people talking about it, there wasn’t much reason to doubt. Announcing a product that has been dead for years is going open source would certainly be a strategy shift for Microsoft, but does it make any sense? Kevin Dente of Herding Code fame certainly thought that Microsoft had better things to release:
@kevindente
Kevin DenteInstead of VB6 I’d rather see MS open source IE6. Then at least we could build a standalone version of it.
FavoriteRetweet
Shortly after the initial tweet, Doug Seven, the Director of Product Management, Visual Studio Tools & Languages, replied asking Roy Osherove (the original poster) to email him. Hmm, it’s starting to smell like something odd is going on. A couple of hours later, Doug set the story straight:
To which, Roy then tried to unset:
It’s worth pointing out that Roy Osherove currently has a full ten-times the followers that Doug Seven has, meaning his altered retweet was seen by more people (at least initially). For several hours word was going around, and accepted by a number of people who thought Microsoft was actually going to open the code to VB6 (including journalists who were too busy writing articles to do any fact checking) – all based on one person who made it all up.
Lesson here: be careful about what you re-tweet, it’s easy to endorse a lie as several people unwittingly did today (@blowdart summed it rather well).
On my fresh Ubuntu 11.04 box running Ruby 1.9.2 instead of the standard Ruby 1.8, I ran into some undocumented errors while installing the mysql2 gem. Here’s what I was seeing:
$ gem install mysql2
Building native extensions. This could take a while...
ERROR: Error installing mysql2:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.9.1 extconf.rb
<internal:lib/rubygems/custom_require>:29:in `require':
no such file to load -- mkmf (LoadError)
from <internal:lib/rubygems/custom_require>:29:in `require'
from extconf.rb:2:in `<main>'
Gem files will remain installed in
/usr/lib/ruby/gems/1.9.1/gems/mysql2-0.3.2 for inspection.
Results logged to
/usr/lib/ruby/gems/1.9.1/gems/mysql2-0.3.2/ext/mysql2/gem_make.out
This obviously isn’t all that helpful, nor did I find anything all that useful on Google – thankfully the issue is easy to solve. All that’s needed is to ensure that the following packages are installed:
sudo apt-get install libmysqlclient-dev libmysql-ruby1.9 ruby1.9.1-dev
Then you can try installing the gem, it should work, hopefully
On March 11, 2011, Twitter said goodbye to some of it’s most loyal and passionate users.
In a message on their Development Talk group entitled “consistency and ecosystem opportunities” – they make their position clear: we no longer need you. To demonstrate this, let me point out a couple quotes that deserve attention:
Twitter will provide the primary mainstream consumer client experience on phones, computers, and other devices by which millions of people access Twitter content (tweets, trends, profiles, etc.), and send tweets.
and this gem:
More specifically, developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.
Independent, 3rd-party developers have driven the progression of Twitter from an extremely simplistic group SMS service, to a massive and near ubiquitous communications system used by millions of people. As Twitter fought whales and struggled to keep servers running, outside developers were busy building new and better ways of using the service; now that Twitter has gone mainstream and is doubtlessly looking at revenue options, they’ve told these passionate users that they are no longer needed. The users that evangelized the service, and promoted it in countless ways, suffering through long stretches of downtime remained loyal and energized, pushing the service to become ever more. Twitter, it seems, has no such loyalty to these champions and flag bearers of the service.
If you want to build an application in the Twitter ecosystem now, you are pushed to the outskirts; building integration as a feature of a separate system (such as instagram), or building for vertical markets which by definition have a far more limited market potential. This is a dangerous time to be invested in an application that relies too much on Twitter; there’s no telling what or who they will ban next.
Twitter did make it fairly clear that existing applications can “continue to serve your user base” - there was an air of a threat in the statement, and given their willingness to ban a major player, I can’t help but think that they will be looking for chances to kill off other clients, to further solidify their control of what users see.
If you are an existing developer of client apps, you can continue to serve your user base, but we will be holding you to high standards to ensure you do not violate users’ privacy, that you provide consistency in the user experience, and that you rigorously adhere to all areas of our Terms of Service.
At best Twitter has alienated passionate users, at worst they have inspired new competition with the goal of being what many of these users wanted Twitter to become, before they shifted their strategy away from the core service, to controlling and enforcing a sub-par user experience.
