Redemption process design: documents to prepare
Redemption process design turns a token's exit mechanism into a working procedure. It sets out which documents prove the right to redeem, who checks each one, and in what order they are reviewed. Preparing this file before the first request arrives avoids delay at the point where a holder actually wants funds back. The sections below list what to prepare, who signs off, and where the point of no return sits.
What redemption process design covers
A token's offering document usually states that holders may redeem under certain conditions. That statement is not a process on its own. Redemption process design is the work of turning it into steps: who receives a request, who checks the holder's identity, who confirms the balance, who authorises payment. Without this work, the first real request becomes an improvised decision rather than a routine one.
The design work sits with the issuer, not with the holder. A holder submits a request against rules that already exist. If the rules do not exist yet, the request forces the issuer to write them under time pressure, which is the situation this page helps avoid.
Stages of the process
A redemption moves through four stages once the mechanism is live. Each stage produces one document and one decision point, and each decision has a named owner.
| Stage | Document produced | Who signs off |
|---|---|---|
| Request intake | Redemption request form, holder identification file | Compliance officer |
| Verification | Register extract, token balance confirmation | Registrar or transfer agent |
| Calculation | Redemption value statement, fee schedule reference | Finance function |
| Settlement | Settlement instruction, confirmation of extinguished tokens | Issuer's authorised signatory |
A file missing any one of these documents does not move to the next stage. This is by design: settlement without a confirmed balance is the most common source of disputed redemptions.
Documents to prepare
Before the first request lands, assemble a template file with the following documents ready to be filled in per holder:
- Redemption policy extract from the offering document, stating eligibility windows and any minimum holding period.
- Holder identification file: passport or company extract, plus proof of control over the wallet holding the tokens.
- Token balance confirmation, extracted from the register at the date of the request, not an earlier date.
- Redemption request form, signed by the holder or by a representative holding a valid mandate.
- Settlement instruction, naming the bank account or wallet address to receive the return of funds or assets.
- Internal sign-off record, naming the reviewer at each stage and the date of approval.
Two lawful bases apply once identification documents start moving through this file: one for the holder's own personal data, a separate one for any third party named further along the wallet chain. Keeping the two bases apart matters for how long each document is kept and who may see it. See Privacy notice: two roles, two bases explained for how the two bases are structured.
Practical consequence for timing and risk
A file assembled in advance shortens the gap between a request and a payout. Missing one document, most often the holder identification file, is the single most frequent cause of delay observed across redemption requests. A holder chasing a payout rarely blames the missing document; they blame the process.
Once the settlement instruction is issued and the tokens are extinguished on the register, the process reaches its point of no return. A later correction to the file, even a genuine one, does not reinstate tokens already extinguished. This is why verification happens before settlement, not after.
Steps to take
The steps below assign each action to a named function, in the order they normally run:
- Compliance officer collects the holder identification file before accepting the redemption request.
- Registrar or transfer agent extracts the token balance and confirms it against the request.
- Finance function calculates the redemption value and records the fee schedule applied to it.
- Authorised signatory reviews the completed file and signs the settlement instruction.
- Settlement team executes the transfer and confirms the tokens as extinguished on the register.
- Compliance officer archives the completed file for the retention period set in the issuer's own policy.
Each step depends on the document produced by the one before it. Skipping the order, for example calculating value before the balance is confirmed, is the usual cause of a redemption having to be reopened.
Who decides and how long it takes
The issuer's authorised signatory holds final sign-off on settlement; the registrar or transfer agent controls the technical step of extinguishing tokens on the register. Neither function should sign off on a file it did not itself review.
In practice, a complete file moves from request to settlement within one to two weeks. An incomplete file adds however long it takes to obtain the missing document, and that wait is not bounded by any fixed deadline unless the offering document sets one.
Two or three scenarios
The general steps above cover most requests. A few situations change the order or add a step.
- If the holder cannot produce proof of wallet control, settlement is paused until the registrar confirms control through another accepted method, such as a signed message from the wallet.
- If the request arrives outside the window stated in the offering document, it is logged and answered at the next open window rather than processed early.
- If a third party is named further along the wallet chain, a separate identification file is opened for that party before settlement proceeds.
What this page does not cover
This page does not establish who a counterparty actually is, verify where a supporting document came from, or confirm what a given jurisdiction permits for the return of funds. Those are separate questions, each answered by a single-purpose registry report rather than by a procedure page.
For a sample check on the counterparty side of a redemption, see Counterparty in Sweden.
For a check on the origin of a supporting document submitted with a request, see Document in United Kingdom.
For a check on what a jurisdiction actually permits in a return of this kind, see Jurisdiction in Switzerland and its limits.
Related reading
The offering document that sets the redemption policy does not stay fixed. It changes under its own procedure, with its own documents and its own notice period to holders. See Update of the offering document step by step for how those amendments are logged and communicated.
Verified
Checked on 21 May 2025. Sources: issuer governance documents, registrar procedures, and standard redemption practice observed across current token issuances. No statute is cited on this page by design. The steps described here sit with the issuer's own documentation and internal sign-off chain, not with one specific article of law, and should be checked against the issuer's current offering document before use.
FAQ
How long does redemption process design take in practice?
Building the template file, agreeing sign-off owners, and testing it against one sample request usually takes one to two weeks. Processing an individual redemption once the template exists takes far less time, typically one to two weeks itself if the file is complete.
Which documents are needed to start?
At minimum: the redemption policy extract from the offering document, a holder identification file, and a token balance confirmation dated at the request. Everything else in the file builds on these three.
What happens if the other side does not respond?
If a holder does not supply a missing document within the deadline stated in the issuer's own request, the file is closed and the request must be resubmitted. The clock for any redemption window restarts only once a complete request is received.
Next step
If a redemption has already turned into a formal complaint rather than a routine request, the documents to prepare are different. See When a complaint triggers a review in practice for what to gather first.