Redemption process design: what the decision maker looks at

A decision maker approving redemption process design checks four things: who can trigger redemption, how the token is taken out of circulation, what evidence proves the transfer, and how long settlement takes. Everything else in the file exists to support one of these four points, and a file that skips any of them usually comes back for rework.

What sits behind the process

Redemption is not decided on the spot. It runs against the token's own terms and the issuer's internal redemption policy, and both documents have to agree with each other before a request is processed. Where the two disagree, the token terms win, because they are what the holder relied on when acquiring the token.

The person signing off does not read the whole file line by line. They look for three markers: a named trigger event, a named signatory, and a named deadline for each stage. If a marker is missing, the file stalls at review, not at execution — which is the more expensive place for it to stall.

What changes in practice

A clear redemption process shortens the gap between request and settlement. An unclear one does not fail outright; it drifts, because nobody is willing to sign an instruction that is not clearly theirs to sign. Drift is the real cost, more than any single missing document.

There is also a point of no return in every redemption file: the moment the burn or transfer instruction is issued. Before that point, a request can still be withdrawn or corrected. After it, the file is closed and reopening it is a separate exercise, not a continuation.

What to do

1. Pull the current token terms and check the redemption clause has not been superseded by a later version.
2. Have compliance confirm the trigger event actually occurred, in writing, before anyone drafts an instruction.
3. Ask legal counsel to match the holder's request wording against the terms, sentence by sentence.
4. Route the settlement instruction to the one person authorised to sign it — not to a shared inbox.
5. Log the confirmation the moment settlement completes, with a timestamp, not after the fact.
6. Keep a copy of every version of the token terms used during the process, in case the holder disputes which version applied.

Who decides and by when

The issuer's own governance body decides whether a redemption request is valid — not the exchange, not the custodian. That body is usually named in the token terms, and if it is not named, the file is incomplete before it reaches redemption at all.

Timing runs on business days rather than calendar days once a request is accepted. A file with a single jurisdiction and no counterparty dispute moves fastest; a file spanning several jurisdictions or several token classes takes longer, because each class can carry its own trigger conditions.

If the timeline in your file looks open-ended, that is worth raising early. Ask a partner directly rather than waiting for the next scheduled review — a stalled redemption file rarely fixes itself.

Common scenarios

If the holder requests redemption before the trigger event occurs, the request is held, not rejected outright, pending confirmation that the condition is later met. If it is never met, the request lapses and the holder is notified in writing.

If two versions of the token terms conflict because of an undocumented update, the version in force at the time the holder acquired the token generally governs. This is why version records matter more than most teams expect.

If the counterparty side of a multi-party redemption does not respond within the agreed window, the file moves to escalation rather than staying open indefinitely. Escalation means a named deadline for a second request, not an informal reminder.

What this page does not cover

This page describes the shape of the redemption process. It does not price the work of designing or reviewing one — that sits in a separate part of the file, sized to the number of token classes and jurisdictions involved.

It also does not cover related but separate questions that come up in the same file. When a subprocessor is added mid-process, the decision runs on a different track — see the Counterparty report when a subprocessor is added for how that is handled.

Disputes over a translated version of the token terms are also handled separately, because the question there is which language version controls, not who can trigger redemption. That is covered in the Document report when a translation is disputed.

For a sense of how findings on a related question are actually delivered, rather than described in the abstract, see the Sample jurisdiction report, as delivered.

Verified

This page describes process mechanics rather than statutory requirements, and it carries no citation to a specific regulation or article for that reason. It was last reviewed for accuracy against current internal redemption practice. Where a client's file raises a question tied to a specific national requirement, that question is addressed separately, on a page built for that jurisdiction.

Related publications

Redemption process design usually sits next to a change in the offering document itself, and the two are reviewed together more often than not. See Update of the offering document step by step for the parallel process.

FAQ

How long does redemption process design take in practice?
Most files close within a few weeks. The main variables are how many token classes are involved and whether the counterparty responds without prompting.

Which documents are needed to start?
The current token terms, the internal redemption policy, and a written record of the trigger event. Without these three, review cannot begin.

What happens if the other side does not respond?
The file moves to escalation on a named deadline rather than staying open. A second request is sent, and if that also goes unanswered, the matter is raised with the governance body directly.

— Aleks Vaher, AURELIS