Key takeaways include a strict adherence to a defined XML structure comprising MessageSpec, ReportingFI, and ReportingGroup elements. The instructions establish distinct procedures for submitting new returns, replacing returns before the 31 July deadline, and filing corrections after 1 September using specific DocTypeIndic codes. The Ilmoitin.fi service performs a series of automated checks that will reject non-compliant files, covering everything from file encoding and character sets to the logical consistency of reported data, such as ensuring a closed account’s balance is zero.
Version 3.1 introduces several critical updates. It formally removes all references to the legacy “Katso” authentication system in favor of Suomi.fi authentication. It also announces three new validation checks scheduled for implementation in June 2025, which will enforce mandatory reporting of self-certification data for new accounts and require the date of birth if self-certification has been provided. Reporting for CRS/DAC2 is explicitly separate from, and must not duplicate, information reported under FATCA regulations.
Overview of CRS/DAC2 Reporting Framework
The technical instructions are founded on the legal requirements of Sections 17 b and c of Finland’s Assessment Procedure Act (1558/1995). The framework is designed to implement the OECD’s Common Reporting Standard and the European Union’s AEOI DAC2 technical specifications for the automatic exchange of financial account information.
• Purpose: To provide Reporting Financial Institutions (filers) with the technical specifications for submitting annual returns detailing reportable financial accounts.
• Scope: The instructions apply exclusively to CRS and DAC2 reporting. Information concerning U.S. account holders, reportable under the FATCA rules (Section 17 a of the Assessment Procedure Act), must be filed on separate, dedicated FATCA returns.
• Application Date: The instructions detailed in this memorandum have been applicable to all CRS and DAC2 returns since 17 December 2018, with subsequent updates detailed in the version history.
Filing Process and Technical Requirements
All CRS and DAC2 returns must be submitted electronically through the Ilmoitin.fi e-service. The service has both a live production environment (www.ilmoitin.fi) and a test environment (https://testi.ilmoitin.fi).
Authentication and Access
• Authentication Method: The only permitted login methods are Suomi.fi authentication and Suomi.fi authorisations. The legacy Katso sign-in system is no longer supported as of Version 3.1.
• Authorisation: Currently, submitting CRS/DAC2 returns does not require any specific Suomi.fi roles or rights beyond standard e-identification.
File Specifications
Files submitted to Ilmoitin.fi must meet strict technical criteria to be accepted.
• File Size: Maximum file size is 100MB. Larger data sets must be divided into multiple files, each under the 100MB limit and assigned a unique MessageRefId.
• Encoding: Files must use UTF-8 encoding without a Byte Order Mark (BOM). The character set must be ISO-8859-1, with characters encoded as per UTF-8. Cyrillic characters are not permitted.
• Special Characters: A specific set of characters must be converted to their corresponding XML entity formats.
| Character | Description | Required Format |
& | ampersand | & |
< | smaller than | < |
> | greater than | > |
’ | apostrophe | ' |
” | quotation | " |
• Forbidden Character Combinations: The combinations --, /*, and &# are not allowed within the XML file.
Submission Deadlines and Procedures
• Annual Deadline: The deadline for reporting information for the preceding calendar year is the end of January.
• Nil Returns: If a financial institution has no reportable accounts for a given year, it must file a “nil” return. This is accomplished by:
1. Completing the MessageSpec and ReportingFI structures with the filer’s details.
2. Setting the MessageTypeIndic element value to CRS703.
3. Excluding all AccountReport structures from the file. Ilmoitin.fi will reject a nil return that contains account data.
Core XML Schema and Data Structure
The CRS/DAC2 return is built upon a specific XML schema with three primary structures that must appear in the correct order. The namespace for the scheme is taxfi.
1. MessageSpec: Contains metadata for the entire return, including the filer’s identity, contact details, and unique message identifiers.
2. ReportingFI: Contains the reportable data of the Reporting Financial Institution itself, such as its name, address, and identification numbers.
3. ReportingGroup: A container for one or more AccountReport structures. A file can contain from zero (for a nil return) to ‘n’ AccountReport blocks. Each AccountReport contains the comprehensive data for a single reportable account and its holder(s).
Key Data Elements and Structures
MessageSpec
This structure identifies the filing and the filer.
• SendingCompanyIN: Mandatory. The filer’s Finnish Business ID.
• MessageRefId: Mandatory and must be unique across all CRS/DAC2 and FATCA filings, except when submitting a full replacement. The format must include the Business ID, reporting year, and a sequential number (e.g., 6606611-7-2018-1).
• MessageTypeIndic: Mandatory. Defines the filing type:
◦ CRS701: New information or a full replacement return.
◦ CRS702: Corrections to a previously sent return.
◦ CRS703: A nil return.
• ReportingPeriod: Mandatory. The last day of the reporting year in YYYY-12-31 format.
• Timestamp: Mandatory. A timestamp for when the file was saved, which must be later than the original file’s timestamp when submitting a replacement.
ReportingFI
This structure identifies the financial institution submitting the report.
• ResCountryCode: Mandatory. Must be “FI” for Finnish institutions.
• IN: Mandatory. The institution’s identifier, preferably a GIIN. If no GIIN exists, the Finnish Business ID is used.
• DocSpec: A mandatory structure containing metadata about the ReportingFI block itself, including its own DocRefId and DocTypeIndic.
AccountReport
This is the central structure containing all information about a single reportable account.
• AccountNumber: Mandatory. The account number or other unique identifier (e.g., insurance contract number). Attributes specify if the account is undocumented, closed, or dormant.
• AccountHolder: Contains detailed information about the account holder, with separate structures for Individuals and Organisations.
◦ TIN/IN: The tax identification number is mandatory for new accounts. If unavailable, “000000000” must be entered, and the issuedBy attribute must be omitted.
◦ Name: For individuals, if a first name is unknown, “NFN” (No First Name) must be entered in the FirstName element and all known names placed in the LastName element.
◦ Address: This is a mandatory element. AddressFix should be used for structured addresses. AddressFree can be used for unstructured addresses or to note non-disclosure for personal safety reasons.
◦ AcctHolderType: Mandatory for entity accounts, specifying the entity type (e.g., CRS101 for a passive NFE with reportable controlling persons, CRS102 for a Reportable Person).
• ControllingPerson: This structure is mandatory only for account holders reported with AcctHolderType = CRS101. It contains the same data elements as the AccountHolder/Individual structure and requires a CtrlgPersonType to specify the nature of control (e.g., ownership, settlor, trustee).
• AccountBalance: Mandatory. The balance at the end of the calendar year. Negative values are not permitted; a zero or negative balance should be reported as 0.00. For closed accounts, the balance must be 0.00.
• Payment: Reports payments such as dividends (CRS501), interest (CRS502), gross proceeds (CRS503), or other income (CRS504).
Corrections, Replacements, and Deletions
The instructions define a strict, date-sensitive process for amending previously filed returns.
Replacements (Before 31 July)
• Method: A filer can submit a complete replacement return up to 31 July.
• Requirements: The replacement file is treated as a full substitute for the original. It must use the exact same MessageRefId as the original return.
Corrections (From 1 September)
• Method: After the replacement deadline, changes must be submitted as correction filings. Corrections are accepted starting 1 September.
• Requirements: A correction file must have a new, unique MessageRefId and must reference the MessageRefId of the original file in the CorrMessageRefId element. Corrections are made at the level of individual structures (ReportingFI, AccountReport), each of which requires a CorrDocRefId pointing to the specific structure being corrected.
• DocTypeIndic Values: The DocTypeIndic element within each structure dictates the action being performed:
◦ OECD1: Reporting entirely new data (e.g., a new account).
◦ OECD2: Correcting previously submitted data.
◦ OECD3: Deleting previously submitted data.
◦ OECD0: Resending data with no changes (used for the ReportingFI structure when only AccountReport structures are being corrected).
• Restrictions: A single correction return cannot mix new data (OECD1) with corrections (OECD2) or deletions (OECD3).
Specific Correction Scenarios
• Correcting a ResCountryCode: The filer must first submit a deletion (OECD3) for the original entry and then submit a new record (OECD1) with the correct country code.
• Removing an Entire Return: To remove an entire unnecessary return after 31 August, all of its structures must be deleted by setting their DocTypeIndic values to OECD3.
Ilmoitin.fi Validation System
The Ilmoitin.fi service runs an extensive set of automated checks. Failures in the first category result in rejection of the file, while messages in the second category are informational warnings.
Mandatory Checks (Rejection on Failure)
These checks prevent the submission of a file containing structural errors, formatting issues, or logical inconsistencies.
| Data Element / Area | Description of Check |
| File Integrity | The file must be identified as a valid CRS/DAC2 XML report. It must not contain forbidden characters (--, /*, &#) and must use UTF-8 encoding. |
| Identifiers | MessageRefId and SendingCompanyIN must contain a correctly formatted Finnish Business ID. The Business ID in MessageRefId must match the one in SendingCompanyIN. A DocRefId cannot be reused. |
| Correction Logic | A correction filing (MessageTypeIndic=CRS702) must contain a CorrMessageRefId. DocTypeIndic values OECD2 or OECD3 must be accompanied by a CorrDocRefId. |
| Nil Returns | A return with MessageTypeIndic=CRS703 cannot contain any AccountReport structures. |
| Account Data | For a closed account (ClosedAccount=true), the AccountBalance must be 0.00. |
| TIN/IN Placeholders | If TIN or IN is “000000000”, the issuedBy attribute must not be included. If a real TIN/IN is provided, issuedBy is mandatory. |
| Account Holder Type | If AcctHolderType is CRS101, at least one ControllingPerson must be reported. If AcctHolderType is CRS102 or CRS103, no ControllingPerson data is allowed. |
Upcoming Checks (June 2025 Implementation)
• If self-certification was provided (Self-Certification = CRS972), the date of birth becomes a required field.
• If an account is new (AccountTreatment=CRS982), information on self-certification (CRS971 or CRS972) is mandatory.
• If an account is marked as undocumented (UndocumentedAccount=true), it cannot simultaneously be reported as having provided self-certification (Self-Certification=CRS972).
Informational Messages (Warnings)
These messages appear in the user interface to alert the filer to potential issues but do not prevent submission.
• Re-used MessageRefId: A warning is displayed that the submission will overwrite any previous filing with the same ID.
• “NFN” Usage: If FirstName is set to “NFN”, a message reminds the filer that this is only permissible when the first name is genuinely unknown or non-existent.
• “FI” as ResCountryCode: If an account holder’s residence country is “FI”, a message prompts the user to double-check this, as it is only allowed in specific circumstances (e.g., for undocumented accounts).
• TIN Format: A warning is issued if a TIN for an EU country does not match the expected format.
Key Updates in Version 3.1 (21 March 2025)
Version 3.1 of the instructions introduces targeted changes primarily focused on authentication and data validation.
• Authentication System: All references to the obsolete “Katso” sign-in system have been removed, solidifying Suomi.fi as the sole method of authentication.
• Validation Rules:
◦ A new check was added to prevent the use of the value OECD201 for the nameType attribute within the Name structure.
◦ Three new check processes concerning self-certification for new and undocumented accounts are scheduled for implementation in June 2025.
• Element Clarification: The description of the BirthDate element within the BirthInfo structure was revised for clarity.