In June 2026, we transmitted a FATCA Model 2 filing for a Hong Kong investment fund as Third-Party Transmitter under our own GIIN.
It was accepted on the first submission.
What makes that worth writing about isn't the acceptance — it's what the validation engine caught before the file ever reached the IRS. Four separate data errors, all in the client's spreadsheet, all of which would each have triggered an IDES rejection if left alone.
None of the four are unusual. In fact, they're the kind of errors that show up in almost every FATCA spreadsheet a compliance team hands over. The difference is whether a human finds them after IDES rejects the file days later — or whether an automated validation layer finds them in seconds, before anything is transmitted.
Here's what each one was, why it matters, and how to catch it in your own data.
The Filing, Briefly
-
Filing type: FATCA Model 2 (direct IRS submission via IDES)
-
Jurisdiction: Hong Kong
-
Reporting FI: a Hong Kong-based investment fund
-
Transmitter: Novus Compliance, acting as Third-Party Transmitter under our own GIIN
-
Data source: the client's completed Novus FATCA 2 Excel template
Hong Kong operates under FATCA Model 2 — meaning the fund files directly with the IRS, without an intervening local tax authority. That matters for the error story because Model 2 filing involves the full IDES packaging pipeline: signed XML, AES-256 encryption, metadata, correctly named archive. A single formatting error anywhere in the source data can fail the whole package.
The client had no prior IRS filing experience. Their data arrived on the standard template, fully populated, and looked complete. It wasn't.
Error 1: TIN Format — Dashes Where the Schema Expects Digits
What the client entered:
054-85-8541
What the schema requires:
054858541
Why it matters:
The FATCA XML schema expects the TIN as nine raw digits. Dashes, spaces, or any other formatting cause XSD validation to fail on the payload — which means the entire package gets rejected by IDES, not just the individual record.
This is the single most common formatting error in FATCA submissions, and it's completely invisible to the person entering it. It looks correct in a spreadsheet because that's how SSNs are conventionally displayed. It only fails at the XML layer.
How to catch it:
Strip all non-digit characters from the TIN field during validation, then confirm the resulting string is exactly nine digits long and passes the standard SSN/ITIN format check. Do this before generating XML, not after.
Error 2: AccountHolderType — Wrong Classification Code
What the client entered:
FATCA_104
What the correct code was:
FATCA105
Why it matters:
The AccountHolderType field determines how the IRS classifies the account holder in the reporting schema. FATCA104 and FATCA105 represent different entity categories. Getting it wrong doesn't always cause an immediate rejection — which is what makes it dangerous.
Instead, a misclassified record can trigger downstream IRS queries, or silently affect how the account is processed. The filing "succeeds" and the correction only surfaces months later during an audit.
How to catch it:
Validate every code in this field against the schema enumeration for the reporting year. Better: validate against your own internal chart of account classifications so the code isn't just "valid" but "correct for this client."
Error 3: DocTypeIndic — Test Mode in a Production Filing
What the client entered:
FATCA11
What the correct indicator was:
FATCA1
Why it matters:
This is the most consequential error of the four, and the least obvious.
FATCA11 is a test-mode indicator. FATCA1 is the production indicator. If a record is filed with the test-mode indicator in a production submission, the IRS treats it as test data — and silently excludes it from the actual filing.
The submission may still return RC001 (successful upload). Nothing looks broken. But the account is not reported.
How to catch it:
The indicator should never be manually entered. It should be set programmatically by the system, based on which environment (test or production) the filing is going to. If the value is in a spreadsheet cell that a human can edit, that's the bug.
Error 4: Post Code — Placeholder Where the Schema Requires Blank
What the client entered:
00000
What the schema required:
(blank)
Why it matters:
When no valid postal code exists for an account holder, the FATCA schema requires the field to be left empty. A placeholder value like 00000 is not a valid post code — it fails validation.
Compliance teams often enter 00000 or 99999 as "we don't have this" markers. But to a schema validator, that's a data value, not a missing one.
How to catch it:
Maintain a list of known placeholder values (00000, 99999, N/A, UNKNOWN, -) and reject them during validation. If a field genuinely has no value, the fix is to leave it blank — not to enter a flag.
The Pattern Behind All Four Errors
Look at what these have in common:
-
They're all formatting or classification errors, not data errors — the client had the right account holder, the right entity, the right address. The values just didn't conform to the schema.
-
They're all invisible in the spreadsheet — the data looked complete and correct to a human reviewer.
-
Three of the four would have failed validation only at the XML or IDES layer — meaning the failure would surface days after submission, with the filing deadline at risk.
This is the structural problem with FATCA filing: the schema expects a very specific format, the spreadsheet is designed for human readability, and the gap between the two is where rejections live.
Why Validation Has to Happen Before XML Generation
A common workflow mistake is to validate after generating XML — treat the XSD validator as the check.
That works, but it means you're finding errors after they've already propagated into a schema structure, which makes diagnosis harder. More importantly, if the tool you're using generates XML first and validates second, the rejection cycle looks the same as it would with a manual process — just automated.
The stronger workflow is:
-
Validate the source data against schema rules before any XML exists
-
Show the client exactly what's wrong, in their spreadsheet format, so they can fix it
-
Generate XML only after the source data passes
-
Validate the generated XML as a second check
-
Build the IDES package only after both passes succeed
In the Hong Kong filing, all four errors were surfaced in the first validation pass — before any file was generated. The client corrected them within hours. The filing went out on the first submission, with no rejection cycle at all.
What This Means If You're Filing FATCA This Year
If you're filing under Model 1, most of the same errors apply — the schema requirements for TIN format, AccountHolderType, and post code handling are the same whether the file goes to IDES or to a local tax authority portal like HMRC, CRA, or the Indian Insight Portal.
The differences are in the transmission layer, not the data layer.
If your current process is:
-
Fill in a template
-
Generate the file
-
Submit
-
Wait for the rejection
-
Fix and resubmit
…then the errors above are going to happen to you eventually. Not because your team is careless, but because these are the errors that live in the gap between human-readable data and schema-required format.
The workflow that catches them looks like this: validate the source, then generate. Not the other way around.
Related Reading
-
IRS IDES Error Codes Guide — every RC001–RC029 alert and ICMM notice (NKS, NSC, NDW, NSF), with the exact fix for each
-
FATCA Missing TIN Relief Codes — the eight relief codes, their precedence rules, and which ones require a BirthDate
-
FATCA Reporting Guide — full walkthrough of Model 1 vs Model 2, deadlines, and the filing process
-
FATCA Reporting Services — how Novus handles both models from a single Excel upload
Filing FATCA This Year?
If you want to see what your own data would catch before it reaches the IRS, we'll run a sample file through the validation engine live. Twenty minutes, no commitment.