File assembly and submission: what the decision maker looks at

A decision maker reviewing a digital asset file checks three things before anything else: whether the applicant can be identified beyond doubt, whether the described business model matches the supporting evidence, and whether every document in the file tells the same story. Gaps in dates, mismatched signatures or an unexplained change of structure cause more delay than a single missing certificate. Readers new to this area may want the broader Tokenised rights and digital objects overview before working through the steps below.

This page sets out the stages of assembling and submitting a file, who looks at it, and where files most often stall. It does not name a specific regulation or article — the point here is the sequence of work, not the statutory basis behind it.

What changes once the file is submitted

Submission is the point of no return in one specific sense: after that moment, the file cannot be quietly rewritten. Any correction becomes a visible amendment, dated and logged. Before submission, a team can restructure freely. After it, every change adds a step to the review rather than removing one.

This is why the assembly stage matters more than the drafting stage. A file that is internally consistent before submission moves faster once it reaches the decision maker. A file that is submitted to "start the clock" while gaps remain usually loses more time than it saves.

Assembling the file: the steps

Confirm the applicant entity. The legal name, registration details and ultimate beneficial owners must match across every document, not just the covering letter.
Map the activity to the evidence. Each described activity — custody, exchange, transfer of value — needs a document that shows how it is actually carried out, not only how it is described.
Assemble governance evidence. Internal policies, escalation lines and the person responsible for each control area should be named, not left as a job title with no name attached.
Check cross-references. Where one document refers to an annex, the annex must exist, be dated consistently, and use the same terminology.
Run an internal read-through as if by an outsider. The person who assembled the file is the worst judge of whether it reads clearly to someone seeing it for the first time.
Submit through the designated channel. A file sent through the wrong channel, or without the required covering index, is often treated as incomplete rather than late.

Who reviews the file, and how long it takes

Review is rarely a single reader. A first-line reviewer checks completeness; a substantive reviewer checks whether the activity and the evidence match; a decision is then issued or a question is sent back. The table below sets out the typical sequence.

Stage	What happens	Typical outcome
Intake check	The file is checked for completeness against the required document list.	Accepted for substantive review, or returned with a list of missing items.
Substantive review	The reviewer compares the described activity with the supporting evidence.	Questions issued, or the file moves to a decision.
Clarification round	The applicant answers specific questions, usually in writing.	File closed for review, or a further round is opened.
Decision	A decision is issued and communicated to the applicant.	Authorisation granted, granted with conditions, or refused.

Duration depends far more on how complete the file was at intake than on any fixed calendar deadline. A file that returns at the intake stage restarts the clock; a file that passes intake but triggers a clarification round usually takes longer than either extreme.

Common variations

The steps above assume a straightforward case. Several situations change the sequence.

If the activity also touches security duties for the underlying systems, the file assembly should run in parallel with a separate exercise: see Scope assessment for security duties step by step for what that second file needs to contain.

If a third party has raised a trade mark or design objection against materials used in the offering, that dispute follows its own track and should not be folded into the authorisation file. The relevant sequence is described in Platform takedown procedure step by step.

If ownership of the underlying code or design is contested — for example, a dispute over where an idea ends and a protectable expression begins — that question needs resolving before the file states who owns what. The relevant boundary is set out in Idea and expression boundary in ownership of results.

What drives the cost of assembly

There is no fixed price for file assembly, because the work varies with the file itself. The factors that drive time and cost are consistent across cases:

the number of registries and jurisdictions the applicant's structure touches;
whether a statutory clock has already started, which compresses the time available for corrections;
whether the file must be assembled from scratch or reconciled from documents drafted for other purposes;
whether an opposing party or a parallel dispute is already active.

A team assessing a new file gives a first indication of scope quickly, once these four points are known, and a fixed estimate follows once the file's actual state has been reviewed.

How the file is structured internally

A well-assembled file is not a bundle of documents in the order they were produced. It follows the order the reviewer will read it in: identity first, activity second, controls third, and supporting annexes last, each referenced from the section that relies on it. An index at the front, listing every document and its date, saves more review time than any single piece of drafting.

Version control matters here more than in most legal work. A file assembled over several weeks by different contributors needs one person checking, at the end, that every reference still points to the current version of the document it names.

What this page does not cover

This page covers the sequence of assembling and submitting a file and the points where review typically stalls. It does not set out the specific statutory basis for any authorisation requirement, the applicable fee, or the exact calendar deadline that applies in a given case — those depend on the applicant's specific circumstances and are confirmed once the file itself is known. It also does not cover what happens after authorisation is granted; that is a separate stage, addressed on its own terms.

Frequently asked questions

How long does assembling and submitting a file usually take?

It depends far more on how complete the file is at intake than on any fixed calendar figure. A file that passes intake without a clarification round is resolved noticeably faster than one that triggers a second round of questions.

Which documents are needed to start assembly?

At minimum: proof of the applicant's identity and structure, a description of the activity that matches the evidence, and the governance documents naming who is responsible for each control area. Everything else is built around these three.

What happens if the decision maker does not respond within the expected time?

Silence is not the same as a decision. The applicant should follow up in writing, referencing the submission date and the covering index, before assuming any outcome. Escalating too early, before a reasonable review period has passed, usually slows matters rather than speeding them up.

Verified. This page reflects internal file-review practice as observed across current engagements. It does not cite a specific statutory deadline or fee, because those depend on the applicant's own jurisdiction and structure and are confirmed once the file is known.

If your file already spans more than one jurisdiction, or a service is being added across a border, the assembly sequence changes. See When cross-border services are added for what to check first.

— Aleks Vaher, AURELIS