Preparing a crypto-asset whitepaper for iXBRL tagging.

What the white paper is

Under Regulation (EU) 2023/1114, a crypto-asset white paper is a regulatory disclosure document. It carries prescribed content, is notified to the competent authority, and is published. Where the requirement applies, it is also produced in a machine-readable form, so the same file serves a human reader and an automated one.

The obligation attaches to the offeror or the person seeking admission to trading. A platform admitting an asset should establish who carries it for that asset rather than assuming the question does not arise.

Content requirements

The required content varies by token category — crypto-assets other than asset-referenced and electronic money tokens, asset-referenced tokens, and electronic money tokens each have their own set — but the structural blocks recur.

The prescribed warning statements and the management body statement on compliance are part of the content, not front matter, and they are tagged like everything else.

Structuring a document for tagging

Inline tagging attaches structured meaning to elements of a human-readable document. That only works where the element to be tagged exists as a discrete, identifiable piece of the document. Four drafting habits make the difference:

• One fact, one element. A sentence that states the issuer’s legal form, address and registration number together has to be decomposed before any of the three can be tagged cleanly.
• Use real headings. Sections identified by formatting rather than by heading structure cannot be located reliably.
• Keep numbers out of prose. Amounts, dates and quantities that need tagging belong in fields or tables, not embedded mid-sentence with surrounding qualification.
• Write the required blocks as blocks. Where content is scattered across the document because it read better that way, the tagging pass has to gather it, and every subsequent revision re-scatters it.

The tagging pass

The pass itself is mechanical once the document is structured: each required item is located, matched to the corresponding element of the taxonomy in force, and tagged with the appropriate context — the entity, the period or point in time, and the unit where the value is numeric. Text blocks are tagged as blocks; individual values are tagged individually.

Two judgement calls recur. Where the document says something the taxonomy has no element for, it is left untagged rather than forced into an approximate element. Where the document is silent on a required item, that is a content gap to resolve with the drafter, not a tagging problem to work around.

Validation and publication

The tagged file is validated for well-formedness, for taxonomy conformance, and for completeness against the required content. It is then notified to the competent authority and published, in a location that remains accessible for as long as the offer or admission requires. Keep the validation output with the published file; it evidences what was checked at the point of publication.

Amendments and versions

Where the white paper is modified, the modified version carries the same content and tagging obligations and is notified and published in the same way. Version control matters more here than in most reporting work, because earlier versions remain relevant to holders who acquired on the basis of them. Keep each published version, its tagged file and its validation output together as a set.

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.