Metadata verification: what the decision maker looks at

A decision maker checks four things in tokenised-rights metadata: when it was created, who created it, whether it matches the on-chain record, and whether it has changed since issuance. The file is judged on internal consistency, not on the label attached to the token. A clean, dated audit trail moves the review forward; gaps or later edits invite further questions. This page sets out the stages of that check, what to prepare, and where it stops.

Stages of the review

Most reviewers work through the same four stages, whatever the venue. The order rarely changes, because each stage depends on the one before it. Skipping a stage does not shorten the process; it only means the decision maker fills the gap themselves, usually by asking you for it later.

The table sets out what each stage looks for in isolation, but the stages are read together at the end. A record that passes every stage individually can still fail if the dates across stages contradict each other — issuance dated after the first custody statement, for instance. Reviewers flag that kind of contradiction before anything else, because it undermines the whole file rather than one entry in it.

Why metadata carries weight here

A token itself does not prove who is entitled to the right behind it; the ledger records a transfer, not a justification for it. Metadata is where that justification is supposed to live — who issued the record, on whose instruction, and under what custody arrangement. When metadata is thin or was assembled after the fact, the decision maker has nothing independent to check the claim against, and the file effectively falls back to the word of whoever submitted it.

What changes in practice

Metadata verification decides how fast a file moves and how much weight it carries afterwards. If the record is dated at issuance and stored by an independent party, the decision maker treats it as reliable and moves on to the substance of the case. If dates or custodians are unclear, the file is set aside and the sender is asked for the missing pieces.

Each round of clarification adds weeks rather than days, because this stage runs before the rest of the review, not alongside it. A file that arrives complete typically clears this stage in a single pass, and the substantive question — who is entitled to what — can be addressed straight away. A file that arrives incomplete effectively restarts the clock each time something new is requested.

Common gaps that slow the file down

• A summary export instead of the underlying system log, which cannot be checked line by line.
• A custody statement covering the wrong period, usually because nobody checked the exact issuance date first.
• Metadata edited after the fact without a separate note explaining when and why the edit happened.
• Two versions of the same record in circulation, with no indication of which one is current.

What to do

1. Collect the original issuance record together with its timestamp; the issuer or its administrator holds this file.
2. Request a custody statement from whoever held the underlying asset at the time of issuance, not at the time you happen to be asking.
3. Compare the stored metadata against the public ledger entry line by line; a technical adviser usually runs this check rather than the client directly.
4. Write down every discrepancy instead of resolving it informally, so the decision maker sees the complete picture rather than a cleaned-up version.
5. Put the file together in chronological order and submit it as one package, not as separate attachments sent over several days.
6. Keep your own copy of everything submitted; the decision maker works from the copy, not from your working file, and versions can drift.

None of these steps require special access. Anyone holding the asset, the issuance record, or the custody chain can produce the underlying document; the work is in assembling it correctly, not in obtaining permission.

Who decides

The body handling your matter — a court, an arbitration panel, or the compliance function inside the platform — reviews the metadata file and decides whether it is sufficient. No outside clock fixes how long this review takes; the pace depends on the venue's own caseload and on how complete the file was on arrival.

A file with gaps goes back to the sender before any decision on the substance is made. This is a preliminary check, not a ruling on ownership, and it is usually handled by a different person or team than the one who will eventually decide the underlying question. Treat a request for more metadata as a procedural step, not as a sign the case is going badly.

If your situation differs

• If the issuer created the metadata itself, ask for the underlying system log rather than a summary export, because the log carries the timestamps the export usually strips out.
• If a custodian added information after issuance, that addition is treated as a separate, dated event, not as part of the original record.
• If Reserve assets are held by a third party token, the review adds a step to confirm when that holding began and who recorded it.
• If more than one custodian has held the asset over time, the file needs a separate entry for each handover, not a single summary line covering the whole period.
• If the metadata was generated automatically by a platform with no human sign-off, expect the decision maker to ask who is accountable for that automated process.

What this page does not cover

Metadata verification is a gatekeeping step, not the decision itself. It settles whether the file is fit to be reviewed, not who ultimately holds the right.

This page does not establish who owns the underlying right; it only checks whether the metadata supporting a claim is internally consistent. For a jurisdiction-specific view of what can actually be confirmed about a particular asset, see Asset in Estonia.

It also does not resolve a dispute with a counterparty whose obligations sit elsewhere. Where the other side is a debtor rather than an asset holder, the relevant limits are different, and worth checking before you rely on this procedure — see Debtor in Sweden and its limits.

Finally, this page does not tell you how much detail your specific case needs. That choice depends on scope and depth, and it is set out in Three tiers, and the question each of them answers.

Verified

This page was checked against our internal procedural notes on how metadata review currently works in practice across the venues we deal with. It does not cite external legal provisions, because the steps described here are set by each venue's own internal rules rather than by a single public source.

Where a specific act applies to your case, your reviewing body will point to it directly, and that reference will sit outside the scope of this page.

Related reading

For the on-chain side of the same question, see How chain of title reconstruction on-chain tokenised rights what. Both pages describe what a reviewer checks; this one covers the metadata layer, the other covers the transaction history behind it.

FAQ

How long does metadata verification take in practice?

There is no fixed clock. A complete file usually clears this stage in a single pass. Each additional round of clarification adds time, typically measured in weeks rather than days, because the file has to go back to whoever holds the missing piece before it can move forward again.

Which documents are needed to start?

The issuance record with its timestamp, a custody statement covering the relevant period, and an export of the matching ledger entry. Any earlier correction notices should be included as well, dated on their own rather than folded into the original record.

What happens if the other side does not respond?

The decision maker proceeds on the record already in the file. Silence does not stop the review, but it removes the other side's chance to add its own version before a decision is made, which usually works against whoever stayed silent.

— Aleks Vaher, AURELIS