TIN Validation at Scale: What Fails Between 200 Payees and 50,000

A CRS return goes out in the spring. Some weeks later the receiving tax authority returns a rejection file listing several hundred records whose tax identification numbers cannot be processed. Each has to be corrected and refiled. Correcting them means going back to customers onboarded eighteen months earlier, a proportion of whom no longer respond, to ask again for a number they already supplied once.

Nothing failed at filing time. The numbers were collected, stored and reported exactly as they were given. They were never checked against the format the issuing jurisdiction actually uses, and by the time anyone found out, the cheapest moment to fix them had already passed.

What changes between 200 records and 50,000

A team validating 200 clients can look things up. Someone opens the tax authority’s page, reads the format, and applies judgement to the handful of records that look odd. The process is slow and it works.

At 50,000 payees the failure modes are different in kind, not simply more numerous.

The first is that nobody in the organisation knows a jurisdiction changed its format years ago. Institutional knowledge does not extend across a hundred jurisdictions, and a format change that happened before most of the team joined leaves no trace in the customer file. The records look exactly as they always did.

The second is that a fixed fraction of every batch is structurally impossible and nothing surfaces it. A mis-keyed number still looks like a number. Manual review confirms that a field is populated; it does not confirm that a Portuguese NIF carries nine digits or that a Swiss number begins with the right prefix. The invalid records pass through every internal check and stop only at the tax authority.

The third is that remediation is detached in time from collection. The failure is discovered at filing, months or years after the customer was onboarded, and the fix requires contacting that customer again. Response rates to a request for information a customer has already provided are poor, and the records that stay unresolved are the ones that come back in the next rejection file.

Across validations processed through OpenTIN between 23 March and 12 August 2026, excluding test accounts, 8.6% were rejected. Roughly one identification number in twelve that a customer believed was in order turned out to be structurally impossible. These are API calls rather than distinct numbers, so a retried number is counted more than once.

The distribution of those failures is the useful part:

Reason for rejection	Share of failures
Invalid length for the jurisdiction	69%
Invalid format for the jurisdiction	20%
Invalid checksum	5%
Jurisdiction is not an OECD member	2%
Invalid structure	2%
Jurisdiction issues no TIN	1%

Length dominates, and length is not an exotic edge case. It is truncation on import, padding added by a spreadsheet, digits dropped during a manual re-key. These are the failures a human reviewer skims past and a validator catches every time.

The same check applied at the point of collection changes the economics entirely. When a number is validated while the customer is still in the onboarding flow, the correction costs one form field and a few seconds of their attention. The customer has the document in front of them. Discovering the same error at reporting time costs an outreach campaign, a remediation log and a refiling.

What a structural check proves, and what it does not

An invalid TIN is rejected by the receiving tax authority. Validating before filing moves that rejection to a point where it is cheap to fix. That is the whole causal chain, and it is the reason structural validation belongs upstream rather than in the reporting layer.

There is a distinction here that most of the market blurs, and it is worth stating plainly.

Structural validation proves that a number cannot be real. Matching proves that a number belongs to a named person. These are different operations against different sources.

In United States usage, TIN matching refers to the IRS TIN Matching programme: a name and number pair is submitted and the IRS confirms whether the two correspond to a registered taxpayer. That is an authoritative lookup against a government database.

Access to that database is closed. The IRS restricts the service to payers and their authorised agents who submit information returns, and a payer must appear in the IRS Payer Account File, which requires having filed the relevant 1099 returns reporting backup withholding within the previous two years. An authorised agent performs matching under the account the payer established, not under its own. No vendor holds general access to resell. A provider offering TIN matching to a United States payer is operating inside that payer’s own entitlement, and a provider offering it to anyone else is describing something other than an IRS lookup.

Comparable access elsewhere is restricted or absent, for a reason that is easy to miss. A large share of the identifiers reported under CRS belong to natural persons, and a natural person’s tax identification number is personal data under the GDPR. A public endpoint confirming that a given name and tax number belong together would confirm an individual’s identity to anyone who queried it, which is why no tax authority operates one openly. Most publish nothing at all, and where an equivalent exists it is closed to outside parties in the way the IRS programme is.

Where an open verification service does exist, it covers legal persons. The EU’s VIES system validates VAT numbers, and a VAT number identifies a business rather than a person, so it sits outside the scope of the GDPR entirely. Company registration data is public by design in most jurisdictions. Natural-person tax data is protected by design. The asymmetry is deliberate, and it sets the boundary of what any validation service can honestly offer.

For a legal person, an authoritative check against an official register is therefore possible, and it is a different product from this one. Open Automation’s Global Biz Verify API queries national business registries directly to confirm that a company is registered and that the name provided matches the name the registry holds. For a natural person, no such register is open to query. Structural validation is what remains available, and it is the check the constraint permits.

OpenTIN validates structure. It checks length, format, and where a jurisdiction publishes one, the check digit. It does not confirm that a number was ever issued, and it does not confirm that it belongs to the person who provided it.

What structural validation gives in return is certainty in one direction. A number that fails a correctly implemented structural check cannot be a valid identification number for that jurisdiction under any circumstances. There is no interpretation under which it is correct and no follow-up required to establish that. It is wrong, it will be rejected downstream, and it can be sent back for correction immediately.

Where the rules come from

The OECD publishes jurisdiction-by-jurisdiction TIN specifications through its Automatic Exchange of Information portal. Those specifications determine what is accepted and what is rejected in CRS reporting, and they are public, so the baseline is visible to anyone. Open Automation mirrors changes to them within hours of publication.

The published specification is mostly length and format. OpenTIN goes further where the source material allows it. Where a tax authority publishes a check digit algorithm, that algorithm is implemented. Where the number encodes a real quantity such as a date of birth, the encoded value is checked for validity as a date rather than merely for the presence of digits. All of this comes from official published sources.

The checksum failures in the table above, a twentieth of all rejections, are the measurable form of that. Those numbers carry the correct length and the correct format and are still impossible. A validator implementing format alone would have passed every one of them through to the tax authority.

Coverage follows what the OECD has published. Of the 126 jurisdictions committed to CRS as at August 2026, 112 have TIN specifications published by the OECD, and those are the ones OpenTIN validates against. The remaining 14 committed some years ago without their format documentation having been published since, so there is no rule to validate against and no structural claim to make about a number from those jurisdictions. Saying so is more useful than inferring a format from sample data.

Within the published set, seven jurisdictions issue no tax identification number at all: the United Arab Emirates, Bahrain, Bermuda, the Bahamas, the Cayman Islands, Monaco and the British Virgin Islands. Returning “this jurisdiction issues no TIN” is a valid CRS answer and it stops a team pursuing a customer for a number that does not exist.

A worked example: Switzerland

In 2008 Switzerland replaced the eleven-digit AHV social insurance number with a thirteen-digit number beginning 756. The old number was a speaking identifier that encoded date of birth and sex. Its replacement is non-speaking and carries a check digit. Every resident was reissued, and the two formats were not valid concurrently.

Any eleven-digit Swiss number sitting in a customer record today is therefore stale by close to two decades, and it will fail CRS reporting. It looks entirely plausible in a spreadsheet. It has digits, it has separators, and it was correct when it was collected.

Switzerland rejects at 35% in the data above, the fourth-highest rate among jurisdictions with meaningful call volume, behind Thailand, China and Argentina. That rate is a property of the data held about Swiss customers rather than of Swiss filers, and the 2008 renumbering explains most of it.

Integrating validation into an onboarding flow

The check is a single call. A request supplies the jurisdiction, the entity type, and the number.

GET /tin_validate/CH/I/7561234567897

{
  "tin_valid": 1,
  "message": "The TIN is valid",
  "ctry_spec_ver": "[[version]]",
  "ctry_spec_chk_dt": "[[date]]"
}

The same customer, with the pre-2008 number still on file:

GET /tin_validate/CH/I/12345678901

{
  "tin_valid": 0,
  "message": "Error: the TIN has invalid length for the specified country",
  "ctry_spec_ver": "[[version]]",
  "ctry_spec_chk_dt": "[[date]]"
}

The response carries the specification version used and the date that specification was last checked, which is what makes a validation reconstructable during an audit years later. A rejection recorded in 2026 can be shown to have been assessed against the rules that were in force in 2026.

Two authentication routes are available. The first is a long-lived JWT with an IP allowlist held per subscription. The second is AWS Data Exchange, where authentication is handled entirely through IAM and there is no key to store or rotate.

Either marketplace route also removes a procurement step. OpenTIN is listed on the AWS and Azure marketplaces, and a Google Cloud Marketplace listing is planned. Consumption therefore lands on a cloud bill the organisation already receives under an agreement it has already signed. There is no new vendor to onboard, no separate security review and no additional payment relationship to establish. For a platform team that has already been told no once this quarter, that is often the difference between shipping the check and deferring it. The IAM handling described above is specific to AWS Data Exchange; on Azure the API is reached through the token route.

CRS, and the regimes next to it

CRS is not the only regime that turns on a foreign tax identification number, and the neighbouring regimes are where the forms get confused.

Form 1099 is for payments to US persons. A payee documented as foreign on a Form W-8 is exempt from backup withholding and from Form 1099 reporting, and US-source income paid to that payee is reported on Form 1042-S instead. Status rather than address decides which applies, so a US citizen living abroad still provides a Form W-9 and still receives a 1099. The practical consequence for a platform with a global user base is that its foreign users generate almost no 1099s at all.

Where the foreign identifier actually appears is the Form W-8 itself. Form W-8BEN carries the foreign TIN at line 6a for individuals, and Form W-8BEN-E carries it at line 9b for entities. For a form documenting an account held at a US office of a financial institution where the holder receives income reportable on Form 1042-S, the foreign TIN is required, and a form submitted without one and without a reasonable explanation for its absence is not valid. An invalid W-8 removes the basis for treaty relief and returns the payment to full statutory withholding. The identifier that has to be right, across every jurisdiction the platform’s users live in, is the foreign one.

Two lists exist here and they are not the same list. The OECD documents jurisdictions that issue no tax identification number at all. Separately, the IRS maintains a List of Jurisdictions That Do Not Issue Foreign TINs, which at the time of writing names Australia, Bermuda, the British Virgin Islands, the Cayman Islands and Japan. Australia and Japan do issue tax identification numbers; they appear because Notice 2018-20 extended the exception to jurisdictions whose laws restrict collection or disclosure of their residents’ numbers. A withholding agent that treats the two lists as interchangeable will either demand a number that cannot be supplied or excuse one that can.

DAC7 makes the verification obligation explicit rather than implied. A reporting platform operator has to determine whether the seller information it holds is reliable, using its own records together with any electronic interface a Member State or the Union makes available free of charge to check a tax identification number or VAT number. Collecting whatever a seller types into a field does not meet that standard. The European Commission publishes a free TIN online check module covering the structural validity of a natural person’s number for Member State jurisdictions, and a platform operating only inside the EU should use it.

DAC8 and the OECD’s Crypto-Asset Reporting Framework extend the same pattern to crypto-asset service providers, with obligations running from 1 January 2026 and first reports due in 2027. A reporting provider must obtain a self-certification from each user establishing jurisdictions of tax residence together with a tax identification number for each reportable jurisdiction. The United States sits outside the first wave. It has committed to CARF on a later timetable without signing the framework’s multilateral competent authority agreement, and it is not a CRS participating jurisdiction at all, operating FATCA in place of it. Its domestic digital asset reporting runs through Form 1099-DA under section 6045 of the Internal Revenue Code. For a US-based exchange that returns to the earlier point: 1099-DA covers its US users, and the W-8 population is where the foreign numbers sit.

The scope statement is straightforward. OpenTIN does not generate 1099 or 1099-DA forms, does not produce Form 1042-S, does not implement DAC7 or DAC8 reporting logic, and does not file anything with any authority. It answers one question about one field, before that field reaches a system that will reject it or a form that will be invalid without it.

That is a narrower claim than the regimes themselves, and it is the same claim in each of them. A marketplace with forty thousand sellers or an exchange reporting under several frameworks holds a payee population larger than most private banks, spread across more jurisdictions, with a compliance function a fraction of the size. The validation problem at that scale is a data quality problem in a customer database, and it is solved in the same place regardless of which form the number eventually lands on.

Where this leaves a filing team

The rejection file arrives either way. The only variable is whether it arrives from the tax authority, months after onboarding, or from a validation call while the customer is still on the page.

Open Automation’s existing note on why TIN validation matters for CRS compliance covers the compliance case. This piece covers the mechanics of doing it at volume. The OpenTIN API is available on the AWS and Azure marketplaces, with a Google Cloud Marketplace listing planned, and the technical documentation is at open-automation.io/opentin-technical-documentation.

Figures and availability in this article are stated as at August 2026. Jurisdiction coverage changes as further jurisdictions commit to CRS and as the OECD publishes specifications for those already committed. Rejection rates cover validations processed between 23 March and 12 August 2026 and are reported as a share of API calls rather than of distinct identification numbers.