CRS reporting
CRS reporting software, ready for CRS 2.0.
Complying with the OECD Common Reporting Standard means navigating a mosaic of local rules and schemas. Novus generates validated CRS XML for every jurisdiction you report to, from one dataset and one secure workspace.
- CRS XML v3.0
- OECD + local schemas
- Multi-jurisdiction
- Audit trail
01The challenge
One standard, a hundred local dialects.
-
01 / Hurdle
Schema variations
The OECD schema is the base, but jurisdictions add their own variations and required elements.
-
02 / Hurdle
Multiple files
Each jurisdiction you report to may need its own XML file, envelope and portal.
-
03 / Hurdle
Evolving rules
Local requirements and portal protocols change year to year, now including the move to CRS 2.0 and schema v3.0.
02CRS 2.0
Schema v3.0 vs v2.0: what changes in your XML.
The amended Common Reporting Standard introduces CrsXML_v3.0.xsd, replacing v2.0. Most jurisdictions apply it from the 2026 reporting year, with first filings in 2027; check your own authority’s timetable.
Field-by-field comparison
| Element | Legacy v2.0 | CRS 2.0 · v3.0 | How Novus handles it |
|---|---|---|---|
| Root schema version | version="2.0" · CrsXML_v2.0.xsd | version="3.0" · CrsXML_v3.0.xsd Portals reject v2.0 headers once the CRS 2.0 mandate applies. | Dedicated v3.0 engine generates compliant XML. |
| Self-certification (SelfCert) | Not reported | Mandatory boolean for account holders and controlling persons You must declare whether a valid self-certification is on file for every reportable record. | SelfCert columns in the Excel template, validated row by row. |
| Account lifecycle | Not differentiated | Pre-existing vs. new account flag Report whether each account was opened before or after the cut-off date. | Lifecycle status mapped to the v3.0 element automatically. |
| Joint accounts | No structured count | Joint account flag + joint holder count A boolean for joint accounts plus the total number of holders. | The flag is checked against the holder count. |
| Account category | Not required | Mandatory account type enumeration Classify as Depository, Custodial, Equity/Debt Interest, Cash Value Insurance or E-Money. | Type codes validated against the v3.0 XSD enumeration. |
| Controlling person roles | One role per person | Multiple roles (CRS801–CRS813) Every ownership or control role a person holds must be reported. | Multi-role mapping without duplicating accounts. |
| Tax residency | Single tie-breaker residency | All tax residencies reportable Treaty tie-breaker rules can no longer exclude a second residence. | Multiple ResCountryCode and TIN pairs per person. |
| E-money & CBDCs | Largely excluded | Specified e-money products and CBDCs in scope Brings e-money institutions, digital wallets and CBDC providers into CRS. | Templates for banks and funds, and for e-money providers. |
Migration checklist: v2.0 → v3.0
-
Update the root schema declaration
Any file with version="2.0" is rejected by portals that have moved to v3.0.
-
Add SelfCert flags
An explicit boolean for every reportable account holder and controlling person.
-
Classify every account by type
Depository, Custodial, Equity/Debt, Cash Value Insurance or E-Money. No exceptions.
-
Map multi-role controlling persons
If one person is both a beneficial owner and a settlor, both roles appear in the XML.
-
Report all tax residencies
Don’t rely on treaty tie-breakers; report every residence country on the self-certification.
-
Add joint account metadata
A boolean flag plus an integer count of joint holders.
-
Update self-certification forms
CRS 2.0 expects self-certifications at or before account opening, with stronger reasonableness checks.
-
Validate against the v3.0 XSD
Catch schema errors before filing, not at the portal.
Migrated already? The
free XML validator
checks any file against CrsXML_v3.0.xsd, with every error and its line number.
03The platform
Every jurisdiction, one encrypted workspace.
Whether you generate one file or a hundred, every jurisdiction’s data is processed in the same encrypted environment, held to the same standard.
-
Jurisdiction-specific schemas
Select the countries you report to and the engine applies each one’s format rules.
-
Intelligent sorting
Upload one dataset with accounts for many jurisdictions; Novus splits it into a correctly formatted file per tax authority.
-
One master dataset
Review, update and generate every period’s reports in one place, instead of a spreadsheet per country.
-
Code validation
Account holder types (CRS101–CRS103) and tax residence codes are checked on every record.
-
Multi-currency balances
Balances are reported in their original currency, following each jurisdiction’s rules.
-
Audit trail
Every data change, generated file and user action is logged for internal and external audit.
Filing FATCA too? Novus produces both from the same validated source data.
FATCA reporting servicesFAQ
Frequently asked questions
Something else? Ask our team
Who has to file CRS returns?
Generally all financial institutions: banks, funds, insurers and custodians. Many trusts and passive non-financial entities with foreign account holders or controlling persons also have obligations.
What is the difference between FATCA and CRS?
FATCA is a US law: you report accounts held by US persons. CRS is the OECD standard: you report accounts held by residents of partner jurisdictions to your local tax authority, which exchanges the data. Novus handles both from the same source data.
What changes with CRS 2.0 and schema v3.0?
New mandatory data (SelfCert flags, account type, new-account and joint-account indicators, multiple controlling person roles, all tax residencies) and a new root schema version. Files still in v2.0 are rejected where v3.0 applies.
Do I need to write XML myself?
No. Fill in the Excel template (names, TINs, balances, and so on) and upload it. Novus converts it to the OECD XML standard and validates it.
How do you handle different currencies?
Balances are reported in the account’s original currency, with conversion rules applied per jurisdiction where required.
Can you process bulk filings for multiple entities?
Yes. Thousands of account holders, or several reporting entities, can be processed in one validated batch, which suits consultants managing multiple clients.
How is my data protected?
Data is encrypted in transit with TLS 1.3 and stored with per-customer 256-bit field encryption. It is processed only to prepare your filing and is never sold or shared.
How do I correct a filing?
Through the same channel as the original, with a new DocRefID and a CorrDocRefID referencing the original record. Novus keeps the link between them.
CRS 2.0 is a data problem first. Start with clean data.
See how Novus prepares v3.0-ready CRS files for every jurisdiction you report to, in a 20-minute demo.