CRS XML generator vs building the XML by hand
You can build CRS XML by hand, because the OECD schema is public, but for most FIs a generator is faster and less risky. Schema v3.0 adds fields and business rules. A hand-built file can pass the XSD and still fail those rules, and every correction has to reference the right earlier DocRefId. Building it yourself makes sense if you already have developers and an XML pipeline. Otherwise a generator usually costs less than the staff time.
Side by side
| Generator (e.g. AEOIkit) | By hand or in-house script | |
|---|---|---|
| Setup | Open the file in a browser | Read the OECD v3.0 user guide, map your data, then write and test the code or template |
| Schema validity | Checked against the v3.0 schema rules before download | You run an XSD validator yourself |
| Business rules | Checked, with plain-language errors | Not caught by the XSD. You find them yourself or from the portal’s response |
| Identifiers | MessageRefId and DocRefId generated to DITC conventions | You design and track them, and they must stay unique across years |
| Corrections | Generated with references to the original records | You keep the earlier DocRefIds and build the correction records |
| When rules change | If the DITC’s v3.0 portal rules require changes, licensed customers get an updated copy at no charge | You update and re-test your own code |
| Cost | CI$1,500 per FI per year | Staff or developer time, every year |
Where hand-built files go wrong
- The new v3.0 elements are missing or in the wrong order, such as account type, new or preexisting, and joint-account details.
- Combinations the schema allows but the business rules do not, such as a payment type that is not permitted for the account type.
- A DocRefId used twice, or a correction that references a record that was never filed.
- Characters that must be escaped in XML text, such as an ampersand in a company name.
Corrections to earlier years
After the DITC Portal reopens, corrections and deletions must be in v3.0, including corrections to returns filed under v2.0 (DITC advisory, 17 June 2026). The OECD user guide describes transitional measures for fields that did not exist in the original filing. AEOIkit offers the transitional “not reported” values, such as CRS800, for corrections of records first filed under v2.0, and warns you whenever one is used, because they are only for corrections of records first filed under v2.0. By hand, you read the guidance and apply it yourself.
When building it yourself is the right call
If you file a very large volume from a core system, you may want the XML written straight from that system. In that case, build to the OECD v3.0 user guide, validate every file against CrsXML_v3.0.xsd, and test the business rules separately. For a handful of FIs, or a few hundred accounts, a generator is usually the cheaper route.
Sources: OECD, Amended Common Reporting Standard XML Schema: User Guide for Tax Administrations, version 4.0 (CRS schema version 3.0), 2024 · DITC, Industry Advisory: Common Reporting Standard (CRS) and Economic Substance (ES) Updates, 17 June 2026. Last checked 23 October 2026. Dates the DITC gives as “anticipated” may move; check ditc.ky for the latest.
Related answers
Dates and deadlines in one place: CRS in the Cayman Islands, 2026–2027.