Documentation for regulators: where the package falls apart during review
Supervision rarely rejects a project because of the model itself. A rejection in approval more often comes where the set of materials has ceased to be a single whole: the product description, technical part, and legal wording exist in different editions and diverge in details.
The inspector reads this not as an oversight but as a mismatch between what is claimed and what is actual.
The first point of rupture is versions. The product description was revised for the new issuance mechanics, the legal section remained in its previous edition, and the appendix on fund allocation was not updated at all.
A version discrepancy is caught on the very first reconciliation question: a quote from the package does not match what the project shows on the network.
Second — traceability.
Regulator requirements for a crypto project almost always come down to the chain "what is claimed — how it works — what confirms it." If issuance is described, but the package lacks key handling procedures, accounting for user funds, and separation of administrator roles, these gaps are already closed by correspondence with the supervisor, not by the package itself.
Third — unsubstantiated wording. Public materials promise one thing, internal regulations record another, and there is no evidence — operation logs, reports, procedures — for any statement.
Each such place turns into a separate item in a request for clarification and pushes the review into another round.
Next we explain how a coherent package is assembled: a single source of truth for wording, versioning with a change history, and a traceability matrix from claim to supporting document.
The effect of a prepared package: approval timelines and removed rejections
When the package is assembled from a single source and tagged by requirement sections, the approval cycle goes from weeks to days: the reviewer finds the answer to a specific item rather than assembling it from a dozen files.
The approval timeline is reduced many times over precisely because the correspondence-with-clarifications stage is removed.
A return for revision almost always falls into three classes of reasons: a discrepancy between turnover in reporting and on-chain data, an unconfirmed source of funds at addresses, and a mismatch between the token description and the stated economics.
Such comments are removed not by text but by reconciliation — every figure in the document is tied to a transaction and confirmation time, so a disputed item is closed with a reference rather than a new promise.
The share of manual statement compilation falls to isolated cases: address movements are already aggregated in a repository by wallet and counterparty, and the engineer does not reconcile tables but confirms the correctness of the sample.
In a batch run, this removes the class of double-counting and rounding errors that most often trigger a repeat request.
A single source of versions is the condition under which an edit does not create a second truth.
The package is versioned as a whole, together with the address registry, fund flow diagrams, and control descriptions, so when changes occur one branch is updated rather than five copies.
This is the level of traceability expected by FATF and national supervisory authorities: version, date, and composition match in every section, and resolved comments do not return in the next review.
Operating modes: one-time package, package for a license, ongoing support
The package preparation mode is chosen based on the project stage and the audience for the documents, not the team size.
The same set — model description, token handling, client identification procedures, security report — is assembled differently depending on whether it is read by a partner platform, a regulator, or a bank's internal control service.
| Mode | When it fits | Limitations |
|---|---|---|
| One-time package preparation | First entry to a platform, partner onboarding, response to a bank request | Captures the state as of the delivery date: a change of model or jurisdiction devalues part of the sections |
| Package for a license | Submission to a regulator, legal entity registration, obtaining status | Tied to the requirements of a specific jurisdiction — transferring it requires rework, not translation |
| Ongoing support and updating | The product evolves, token parameters and partner requirements change | Requires access to product changes and a process owner on the client side |
We state the mode limitations before the start. A one-time package answers questions as of the delivery date but does not survive a model change; a package for a license cannot be reused in another country by translation. Keeping documents in a live state is separate work, not a side effect of the first two modes.
Ongoing support without an internal regulation degenerates into chaotic edits. A process owner, a change procedure, and versioning are needed — then it is clear which edition the partner has and which is in progress.
In practice, the modes form a ladder: a one-time package, then expansion to a package for a license, then continuous updating once external control appears.
Work stages: material audit, outline, assembly, review, handover
The workflow is structured so that the package is not rewritten from scratch and every fact in it relies on a confirmed source. First we analyze what already exists: technical description, token economics, smart contract logic, correspondence with the bank or trading platform. Then come seven steps, and the client is involved in two of them.
- Material audit. We collect everything already written and launched on the network, and reconcile the documents with the actual state of the code. The output is a list of discrepancies and outdated wording.
- Gap map. We compare what exists with the requirements of the chosen jurisdiction and license profile: it shows which documents are missing and which will have to be rewritten.
- Package outline. We agree on the structure, table of contents, and owners for each block. Here the client confirms the legal and operational framework of the project.
- Package assembly. We write what is missing, rewrite what diverges, and bring everything to unified terms, metrics, and role designations.
- Internal review. A second engineer independently verifies figures, references, and compliance with the code; discrepancies are returned for rework until resolved.
- Fact confirmation. The client reviews disputed items — token allocation, roles, governance procedure. We record the approved wording.
- Handover by act. We deliver the final versions, document registry, and change log so that further changes are made in a controlled manner.
Documentation package for regulators: composition, versions, handover by act
The package is assembled not "for a review" but as an operating contour: any document can be presented to a regulator, partner bank, or auditor without urgent additional assembly.
Below is what exactly remains with the client after delivery, with source files and the right to edit.
- Tokenomics description — issuance, allocation, unlock schedule, liquidity sources, and calculation assumptions, not just the final schedule.
- Policies and procedures — client checks, risk assessment, complaint handling, escalation of suspicious transactions: with roles, timelines, and decision points.
- Ownership structure diagram — legal entities, shares, reporting lines of divisions, and an explicit indication of who signs documents and is responsible for data.
- Operations register — which logs are maintained, what is recorded in them, retention period, and which query exports a sample for the required period.
- Compliance matrix — regulator requirement → document → section → owner: it shows what closes each item and where gaps remain.
- Version update regulation — numbering, approval procedure, change recording, and effective date of the new edition.
- Handover act — an inventory with the version of each document, date, and signatures of the parties.
Versions are stored in one place, previous ones are not deleted: upon request, it is clear which edition was in effect on a specific date. Handover is done by an act with an inventory, so the client retains both editable source files and the approved package.
Review case: what changed in the package after rework
The project underwent supervisory review twice, and the difference between these attempts was in the packaging of materials, not in the product itself.
Before rework
The package was assembled for a specific request: the tokenomics description lived in one file, client identification and anti-money laundering policies were separate attachments, and the roadmap was in an investor presentation.
For half the documents, several versions with different dates and edits circulated simultaneously, and supporting materials were searched for in correspondence.
During review, this produced a predictable effect: some comments concerned not the substance of the project but discrepancies between documents.
What was changed
The materials were consolidated into a single package with a table of contents and registry: each document received an owner, version number, approval date, and reference to the original decision.
Supporting materials — monitoring reports, transaction exports, request logs — are linked to the policy items they close. The package structure, rather than a specific employee's memory, now answers the supervisor's question.
What was achieved
The number of comments decreased from two dozen to seven, and almost all were on the substance of the product rather than on presentation.
The average closure time fell from nine weeks to three: the inspector no longer needs to ask which file is current, and repeated comments on the same items have disappeared.
The package relies on FATF recommendations and the requirements of local regulators, but the gain comes not from compliance with the letter but from tracing: any statement can be traced to a procedure and confirmation.
How does a package for a license differ from a notification procedure?
The choice between a license and notification determines the scope of documentation, not just the form of submission. Licensed activity arises where the project gains access to client funds: custodial storage, exchange, raising funds in exchange for tokens.
A notification procedure is suitable when there are no such obligations — consulting, development, analytics, services without access to assets.
The difference in requirements is not in the list of sections but in the presence of external confirmations. A notification is a description of activities, responsible persons, and internal rules.
A package for a license adds client identification and transaction monitoring procedures, a risk assessment model, accounting and reporting procedures, audit, a key management scheme, and access separation.
Therefore, the scope of the package differs many times over. A separate difficulty is consistency: the described procedures must match the actual behavior of the system.
A discrepancy between the document and the implementation is the most common cause of regulator requests and rejections, so process descriptions are assembled together with the architecture, not afterward.
We begin choosing the submission mode by analyzing the product model: whether there is custody of client funds, exchange, or public token issuance.
If there are no signs of licensed activity, a full package means extra months and disclosure of technology to the regulator where it is not needed. If there are, notification does not close the issue, and the scope is immediately built around confirmations.
Doubts and limitations: jurisdictions, data, version validity periods
The project jurisdiction defines the rest: where the legal entity is registered, where users come from, and where data is physically processed.
We assemble the package for a specific set of regimes, not "just in case" — otherwise the document contradicts itself: one part describes a non-custodial service, another describes fiat flow operations.
Personal data in a blockchain project almost always lives off-chain: pseudonymous addresses and hashes remain on-chain, while names, documents, and addresses are in an external contour with access separation.
We record responsibility boundaries with a matrix: who is the data controller, who is the processor, what we cover, and what remains with the client. We reconcile requirements with FATF recommendations and the relevant regimes of target countries.
How to handle the right to erasure if the blockchain is immutable?
We do not write personal data to the network — a hash or identifier from an external database remains in the transaction. Deleting the record in the external contour invalidates the on-chain reference, and the information ceases to be recoverable.
We describe such a contour explicitly so that the regulator has no questions about "non-deletable" data.
What happens if the requirements in the jurisdiction change?
The package is versioned: date, revision number, list of changed sections. When requirements change, we update the affected blocks rather than rewriting the entire document, and provide the delta with an explanation.
Access to versions is role-separated, and grants and revocations are logged — upon request, it is clear which revision was transferred to whom and when, while outdated ones remain archived with a mark.
Let's discuss the task: we will return with an estimate, plan, and scope of work
So that the estimate of the scope of work relies on facts rather than assumptions, at the start a few inputs are sufficient: jurisdictions of registration and target markets, project stage — idea, working product, or live network, token purpose and its role in the product economics, whether contract audits have been conducted, and whether there is already correspondence with the regulator.
If some data is not recorded, this does not block the start: we will record assumptions in the preparation plan and clarify them during the work without redoing documents that have already been agreed.
In response to the input data, we send a specific set:
- An estimate of the scope of work: a list of documents for your jurisdictions, effort per block, and the order in which it makes sense to close them.
- A preparation plan: stages, responsible parties on both sides, approval points, and dependencies between documents — from the technical description of the project to compliance policies.
- Package composition: tokenomics description, client identification and anti-money laundering procedures, risk disclosure, contract audit reports, internal regulations for the team.
- Division of responsibility zones: what we cover, what remains with your lawyers and finance function, and what data is needed from them at each stage.
- Handover and support regulation: in what form we deliver source files, how we version edits, and what we do when regulator requirements or the product itself change.
Describe the task in free form — we will return with an estimate, preparation plan, and package composition, after which we will fix timelines and control points.