TIN structure rules by country
One identifier class in detail, with what a structural check can and cannot prove.
See the reference →
Resource center · Platform
Reference data: the code lists every filing depends on.
Almost every rejected filing fails on a coded field rather than on a number. These are the standards involved, what each one identifies, and how each one goes wrong.
Two classes of reference data
Static code lists enumerate a closed set of values — countries, currencies, and similar. They change rarely and predictably, and the failure mode is using the wrong representation rather than a stale one.
Registered identifiers identify a specific entity, instrument or product, and they have a lifecycle: issued, maintained, renewed, lapsed, retired. The failure mode is time. An identifier correct at capture can be invalid at filing, with nothing in your own systems changing.
Static code lists
| Standard | Identifies | Failure mode |
|---|---|---|
| ISO 3166-1 | Countries and territories | Three-letter codes, country names or region labels used where the two-character form is required. |
| ISO 4217 | Currencies | Symbols instead of codes; historic codes for currencies that have been replaced. |
| ISO 8601 | Dates and times | Local date formats; missing timezone where an instant rather than a date is required. |
| ISO 17442 | The structure of the legal entity identifier | Wrong length, or a check-digit failure from a transcription error. |
Registered identifiers
| Identifier | Identifies | Failure mode |
|---|---|---|
| Legal entity identifier | Legal entities that transact in financial markets | Lapsed registration. The code is structurally valid and the record still fails. |
| International securities identification number | Securities | Missing for newly issued instruments, or drawn from an internal catalogue rather than reference data. |
| Business identifier code | Financial institutions and branches | Eight-character and eleven-character forms used interchangeably where one is required. |
| Unique product identifier | Over-the-counter derivative products | Product not yet registered, or the wrong product selected for a bespoke structure. |
| Unique transaction identifier | A specific derivative transaction, shared between counterparties | Generated by both sides, or generated late, so pairing fails. |
| Taxpayer identification number | A person or entity in a tax jurisdiction | Structure not matching the issuing jurisdiction; jurisdiction not stored with the number. |
Framework-specific vocabularies
Alongside the general standards, most frameworks publish their own closed lists — service types and function categories in the DORA register, account and payment types in the automatic exchange schemas, transaction categories in the crypto-asset framework, and template and dimension members in the supervisory taxonomies. These are versioned with the framework, so a value valid for one release may not exist in the next.
The correct response to “none of the values fit” is to choose the closest and document the reasoning. Free text in a coded field does not produce a warning; it produces a rejection, and it removes the comparability the list exists to create.
How reference data fails
- Staleness. An identifier valid at capture and lapsed at filing.
- Representation. The right entity, the wrong form of its code.
- Locality. A number stored without the jurisdiction or issuer that gives it meaning.
- Internal substitution. A firm’s own product or counterparty code used where a registered identifier is required.
- Version drift. A framework vocabulary value carried across a release without revalidation.
- Silent enrichment. A downstream system helpfully filling a blank identifier with a default, which then reports.
Owning it properly
Reference data degrades unless someone owns it. Three arrangements make the difference: a named owner for each identifier class rather than a shared assumption; a scheduled currency check for registered identifiers, run against the register rather than against internal records; and validation at capture rather than at filing, so a defect is corrected while the counterparty relationship is live.
Official sources
Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.
- Commission Implementing Regulation (EU) 2024/2956 — register of information data format requirements and closed listsEUR-Lex · Implementing Regulation · coded values in the DORA register
- Commission Delegated Regulation (EU) 2017/590 — identifiers required in transaction reportsEUR-Lex · Delegated Regulation · entity, person and instrument identification
- Commission Implementing Regulation (EU) 2022/1860 — reporting standards and formats, including the unique transaction identifier standardEUR-Lex · Implementing Regulation · derivative reporting identifiers
- The maintenance bodies for each standard — including the Global Legal Entity Identifier Foundation and the relevant ISO registration authoritiesStandards bodies · authoritative for currency and structure of each identifier
REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.
Keep reading
More on this framework, and the module that produces the filing.
Reading a REGREP validation report
The layer that catches coded-value defects, and how to triage it.
Read the guide →Capabilities
Frameworks covered and checks applied.
See capabilities →Catch coded fields at capture.
Run your population through validation and see every coded-field defect before a portal returns it to you.