CRS Reporting: Complete User Guide for Financial Institutions

What is CRS reporting?

The Common Reporting Standard (CRS) is the global standard for automatic exchange of financial account information between tax authorities. Developed by the OECD in 2014, CRS requires financial institutions to identify accounts held by non-residents and report those accounts to their local tax authority — which then exchanges the data with the account holder's country of residence.

More than 100 jurisdictions have committed to CRS. It's the global equivalent of FATCA, but broader in scope: while FATCA targets US persons, CRS covers residents of every participating jurisdiction. Most financial institutions file both FATCA and CRS returns — from the same source data.

Under CRS, financial institutions must:

• Identify reportable accounts held by non-resident individuals and entities
• Apply due diligence rules — including self-certification and reasonableness checks
• Validate TINs against the account holder's jurisdiction of residence
• Report account holder and account data annually using the OECD CRS XML schema
• Submit to the local tax authority via the prescribed portal and schema

Why CRS reporting matters

Non-compliance carries escalating consequences. Financial institutions that fail to report — or that report incomplete or inaccurate data — risk:

• Penalties under local implementing legislation — these vary widely by jurisdiction
• Reputational damage — CRS compliance is a standard expectation for correspondent banks and counterparties
• Rejection by tax authorities — most portals return invalid XML with error codes that require re-filing. Use our XML validation tool to catch errors before submission.
• Enhanced regulatory scrutiny — repeated failures can trigger audits

Who must file CRS reports?

CRS reporting obligations fall on Reporting Financial Institutions (RFIs) — the CRS definition of entities that hold, manage, or administer financial accounts. The categories are broadly similar to FATCA's FFI definition, with a few jurisdictional variations.

What changes under CRS 2.0?

CRS 2.0 is the OECD's 2023 update to the Common Reporting Standard. It expands the scope of reportable accounts, updates the schema, and aligns CRS more closely with the Crypto-Asset Reporting Framework (CARF) and the EU's DAC8 directive.

What CRS 2.0 changes

• Digital assets: Certain crypto-asset holdings become reportable — including Central Bank Digital Currencies (CBDCs) and relevant digital financial products
• Self-certification: Additional fields required for tax residency and controlling person data
• Zero and negative balances: Clarifications on how (and whether) these accounts must be reported
• Expanded account scope: Broader definitions for certain investment entities and trusts
• Schema update: New XSD version (commonly referred to as CRS 3.0) with added elements for digital assets and updated data types
• TIN validation: Stricter requirements for validating TIN formats against the account holder's jurisdiction of residence

CRS 2.0 timeline

• 2026 reporting year: First year of CRS 2.0 reporting for most early-adopting jurisdictions
• 1 January 2027: Schema v3.0 becomes mandatory in Luxembourg, Ireland, and other EU jurisdictions
• 2027 reporting year: Widespread adoption across CRS-participating jurisdictions

How CRS 2.0 interacts with CARF and DAC8

CRS 2.0 is designed to work alongside two related frameworks:

• CARF (Crypto-Asset Reporting Framework): OECD framework for reporting crypto-asset transactions, filed alongside CRS in most jurisdictions
• DAC8 (EU Directive on Administrative Cooperation 8): EU-specific rules that incorporate both CRS 2.0 and CARF into a single reporting obligation for EU member states

Novus supports all three frameworks. See our CRS Reporting Services for details.

CRS reporting deadlines by jurisdiction

CRS deadlines vary by jurisdiction, but most fall between May and September each year. The table below summarises current deadlines for major jurisdictions — click any jurisdiction to see jurisdiction-specific filing details.

Deadlines shown are based on current published guidance. Local authorities may extend or vary deadlines — always confirm with your jurisdiction's tax portal before filing.

CRS XML field reference

The tables below describe every field required in a CRS XML report. Each section maps to a specific part of the schema — the Submitting Entity, Reporting Financial Institution, Account Holder, Report Destination, Financial Account, and Controlling Persons.

Common CRS reporting errors (and how to avoid them)

Most rejected CRS XML submissions fail for the same handful of reasons. The list below covers the errors we see most often in support — and how to prevent them.

1. Invalid TIN format for the account holder's jurisdiction

CRS requires the account holder's TIN to match the format expected by their country of residence. A US SSN doesn't validate as a UK UTR, and vice versa. Validate TIN formats before filing — mismatches trigger portal rejections in most jurisdictions.

2. Missing or incorrect Report Destination Country

The Report Destination Country element tells the receiving authority which jurisdiction to exchange the data with. If it's wrong, the report is filed against the wrong jurisdiction — a compliance failure even if the schema passes.

3. Wrong AH Type or CP Type codes

Entity classifications must match the enumeration values in the schema. Using CRS101 (Passive NFE) for an active entity, or omitting the CP Type for a controlling person, will fail validation.

4. Element ordering violations

The CRS XSD uses xs:sequence, which requires child elements in a specific order. Even if your data is correct, mis-ordered elements (e.g., Address fields before Name fields) will fail validation.

5. CRS 2.0 schema mismatch

If you're filing for the 2026 reporting year or later and your jurisdiction has moved to the CRS 3.0 schema, submitting against the older schema will fail. Confirm the schema version with your local authority — and validate against the correct XSD.

6. Numeric formatting errors

Account balances and payments must use a period as the decimal separator and no thousands separators. 1000.00 is valid; 1,000.00 and 1000,00 will fail.

7. DocRefID and CorrDocRefID issues on corrections

When correcting an earlier filing, the DocRefID must be unique and the CorrDocRefID must point to the exact original document being corrected. Mismatched references are a common cause of correction rejections.

How Novus Compliance helps

Novus automates the entire CRS reporting workflow — from source data ingestion to XML generation, validation, and filing.

Related tools & resources

Frequently asked questions