Resource center · Tax Transparency

Reportable account fields by framework.

Name: Reportable account fields by framework
Creator: REGREP Regulatory Team
Published: 2026-02-26

The two frameworks overlap enough to invite one data model and differ enough to punish a careless one. This sets the fields side by side.

Dataset CRS / DAC2 · FATCA · Multi-jurisdiction REGREP Regulatory Team · Reviewed 2026-04-22

The shape of a reported record

Both frameworks report the same four blocks: who is filing, who the account belongs to, what the account held, and what moved through it — each carrying provenance data that lets a single record be corrected later. The differences are in what triggers reporting and in a small number of framework-specific structures.

Identity and residence

Identity fields
Field	CRS / DAC2	FATCA
Name	Reported for the account holder, and for each controlling person of a passive non-financial entity.	Reported for the account holder, and for each substantial owner that is a specified person.
Address	Reported.	Reported.
Residence	One or more reportable jurisdictions of tax residence. Drives which jurisdictions receive the record.	Not the trigger — the test is United States citizenship or tax residence, which citizenship satisfies wherever the person lives.
Identification number	The number issued by each reportable jurisdiction, where held.	The United States taxpayer identification number.
Date of birth	Reported for individuals.	Reported for individuals.
Entity classification	Drives whether controlling persons must be identified and reported.	Drives owner reporting and the filer category.

The residence field is not interchangeable. A model that stores a single “reportable jurisdiction” per holder works for one framework and quietly fails the other. Store residence as a set, and store citizenship separately.

Account and balance

Account number — as it identifies the account in the institution’s systems, or a functional equivalent where none exists.
Account category — custodial, depository, equity or debt interest, or cash value insurance and annuity, which determines which payment fields apply.
Balance or value — at the end of the reporting period, or at closure for accounts closed during it. Not an average and not the value at the filing date.
Currency — from the controlled code list, applied consistently with the balance.
Closure — both frameworks require closed accounts to be identifiable rather than simply absent.

Payments

Payments are reported by type, and the types that apply depend on the account category: interest, dividends, other income arising in respect of the assets held, and gross proceeds from sales or redemptions. For insurance and annuity contracts the reported amount is the amount paid or credited. FATCA adds pooled reporting, which carries aggregate figures for defined categories of holder rather than account-level detail, and which has no counterpart in the other framework.

Provenance and corrections

Provenance fields
Field	Function
Message reference	Unique across every message the filer has sent to that jurisdiction. Anchors the transmission.
Document reference	Unique across every record the filer has ever created, permanently. Anchors the record for correction.
Document type indicator	States whether the record is new data, a correction, a deletion or a resend.
Corrected references	The message and document references of the record being replaced or withdrawn.
Reporting period	The period end date the message relates to.

Designing one model for both

Store residence as a set, citizenship as a flag. One field cannot serve both triggers.
Model controlling persons as first-class records, not as attributes of the account, so an entity can carry several.
Keep document references outside the file generator, persisted against the source record, so a regenerated file reproduces them.
Capture the period-end balance as a snapshot rather than recomputing it later from a rolling position.
Hold payment types separately rather than as a single total, because the applicable set varies by account category.

Official sources

Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.

Council Directive 2014/107/EU (DAC2) amending Directive 2011/16/EU as regards mandatory automatic exchange of information in the field of taxationEUR-Lex · Directive · reportable information and due diligence
Internal Revenue Service — About Form 8966, FATCA ReportIRS · the reported dataset and its instructions
Internal Revenue Service — FATCA XML reporting schema: correcting, amending and voiding recordsIRS · the provenance fields and their semantics
OECD — Common Reporting Standard XML Schema and User GuideOECD · field-level specification · consult the current edition and any national variant

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.

At a glance

Purpose: A field-level comparison for teams building one data model to serve both frameworks.
Shared spine: Account holder identity, residence, account number, balance and payments.
Key divergence: The residence test, the controlling-person requirement and the pooled-reporting concept.
Provenance fields: Both carry message and document references that make record-level corrections possible.
Authority: The schema and user guide for each framework, plus any national variant.