Over the past few years, we have seen a significant increase in regulations aimed at strengthening tax compliance and the automatic exchange of tax information. In Europe for example, the DAC7 directive now requires collaborative platforms such as Airbnb and Booking.com to report users' income along with tax information. Financial institutions are also already required to perform international tax reporting under FATCA and CRS.
As a result, there is an increasing need for TIN validation. During our research, we found that while this space was already occupied by a few established providers, many of the products felt brittle, lacked transparency, and were often surprisingly expensive. We felt there was room for a different approach.
What we are bringing to the table that we believe is different:
1. Support of all 249 ISO 3166-1 countries and territories:
Most competitors support 100+ countries, which covers the vast majority of use cases. However, smaller territories are often left unsupported. While this is understandable, platforms and financial institutions still receive tax information from those jurisdictions.
Some territories do not issue TINs, some use alternative identifiers, and some have very small populations. We preferred to explicitly support and model these cases rather than simply returning "not supported".
2. Validation across multiple TIN types per country:
Most countries do not have a single TIN format. Typically, individuals and companies have different identifiers, and some countries have several formats depending on the type of taxpayer.
TIN Validate explicitly supports these distinctions and provides users with that level of detail, rather than treating every identifier within a country as the same thing.
3. Transparent multi-step validation:
This is probably the aspect we care most about.
When testing competing validators, we often encountered situations where one service would return "valid" while another would return "invalid". As users, we had no way of understanding why. Were they actually running validation? How thorough was it? Which result should be trusted?
This is why our validation process is broken down into individual rules. Instead of simply returning "valid" or "invalid", we show which checks passed and which failed, whether those checks relate to structure, length, character requirements, checksum logic, or other country-specific rules.
Our aim was to make TIN validation less of a black box and give users enough information to understand and trust the result.
The use cases:
During our research, we identified a number of use cases for the product, including financial institutions, collaborative platforms reporting to tax authorities, and more generally any application that collects tax identifiers and wants to validate them as early as possible.
We would love to hear any feedback, criticism, or suggestions from the HN community.