The Dealing tab of a fund token is where its supply manager sets the subscription terms, follows the investors' requests and settles each dealing day at the NAV, the net asset value that the fund's price feed published. Investors lodge subscription and redemption requests before the 12:00 UTC cut-off of a dealing day. A fund token takes these requests only when it does not use register lines, the holder register that the Booked movements feature keeps. The Fund dealing concept page explains the model: the calendar, the five redemption request statuses and the settlement order. Corporate actions covers the buyback review.
A redemption day settles from the Console or the API and pays out through a buyback corporate action. A subscription day settles through the API only, with POST /api/: the platform prices each open request at the NAV, pulls the investor's cash and mints the units. The Subscription requests list in the Console is read-only and has no settle button.
The “Dealing” tab as a supply manager sees it.
Under the “Settle dealing day” button, “Redemption requests” lists one row per request with “Holder”, “Units”, “Status”, “Dealing day”, “Cut-off”, “NAV” and “Cash”. Below it, “Subscription requests” starts with the line “This list is read-only.”, and its rows continue below the frame.
Who can do what
A bank rail redemption is a separate flow that Bank rail covers.
A supply manager cannot cancel an investor's request. A cancellation by anyone but the investor or holder who made the request answers as not found.
Steps
Set the subscription terms
Open the fund from “All assets” and select Dealing under “More”. The “Subscription terms” card shows “Stablecoin”, “Receiving treasury”, “Minimum cash per request” and “Last updated”. While the fund has no terms, the card says “No subscription terms are set yet.”
A supply manager sees Set terms while no terms exist and “Edit terms” afterwards. The sheet asks for the stablecoin investors pay in, the treasury wallet that receives the cash and an optional minimum. Leave the minimum empty for no minimum. “Save terms” asks for your wallet verification and then saves.
The platform refuses terms in these cases:
- The stablecoin is not a token indexed on the same network, or it is the fund token itself.
- The receiving treasury is the zero address or the fund token.
- A minimum is set and is zero or less.
- The token is not a fund without register lines. The Console says “This fund does not accept subscriptions.”
Investors lodge and cancel requests
An investor who holds no units yet subscribes from Invest. Its “Funds” section lists every fund that has subscription terms and does not use the register lines feature, and each fund card has a Subscribe button. The card also lists the investor's own subscription requests for that fund, with “Cancel” before the cut-off.
The “Dealing requests” card sits on the holding page of the fund, which an investor opens from Wealth, then Portfolio, once a wallet holds units. It has two buttons, “Subscribe” and Request redemption. The Investor portal shows the same “Funds” section on Invest and the same card on its holding page. The API serves the same requests to an integration.
Subscribe opens a sheet with the cash amount in the subscription stablecoin. The amount field reads your number in your language and accepts the suffixes k, m and b. Under it, a line shows the amount in the stablecoin's price currency, or “No price set for …, so no fiat equivalent.” when the stablecoin has no price. From Invest the sheet uses the investor's main wallet and has no wallet picker. From the holding page it shows a wallet picker when the investor has more than one wallet that holds units. An investor the fund's rules exclude sees “This fund isn't open to your account. Ask the fund manager to check your eligibility, then try again.” The sheet shows “Minimum: …” when the terms set one and “This is below the fund's minimum.” when the amount is under it. When the fund has no terms the sheet says “This fund has not opened subscriptions.”
Request redemption opens a sheet with the units to redeem, the same amount field with its fiat line, and the line “Available: …”. The request locks no units on the chain, so a holder who moves the units away before settlement has the request rejected with “The holder no longer had enough units”. The button is off while no wallet of the holder has available units. An amount over the available units shows “This is more than your available balance.” The sheet asks the holder for wallet verification before it sends the request.
Both sheets say that the request can be cancelled until the cut-off of its dealing day. The request takes its dealing day from the moment the platform records it. A request recorded before 12:00 UTC on a weekday belongs to that day. A request recorded later, and any request on a weekend, belongs to the next weekday.
The card lists each request as “Subscription” or “Redemption” with its amount, a status badge with the text “Open”, “Cancelled”, “Settling”, “Settled” or “Rejected” and the line “Dealing day … · cut-off …”. A subscription request stays Open until a supply manager settles its dealing day through the API. It then shows “Settling” until the cash and the units are on the chain, then “Settled” or “Rejected”. The card shows no NAV, units or reason. The API record of the request carries the NAV, the units, the cash and the rejection reason. The settle sheet in the Console settles a redemption day only.
While a request is open and its cut-off is ahead, its row shows Cancel. A redemption cancellation asks for wallet verification first. A subscription cancellation does not. After the cut-off the button is gone, and a call to the API is refused.
Follow the request lists
The Dealing tab of the fund has up to four sections:
- Redemption requests with the columns “Holder”, “Units”, “Status”, “Dealing day”, “Cut-off”, “NAV”, “Cash” and “Reason”.
- Subscription requests with “Investor”, “Cash”, “Dealing day”, “Status” and “Cut-off”. This list is read-only.
- Subscription terms, from the first step.
- Fund register with each holder's units and value, and “Export CSV”. It is the list of holders, not the register lines feature. It shows only to a platform administrator, an organisation owner, or a holder of the Permission manager, Auditor, Compliance manager or System manager system role.
A supply manager sees every request in the two lists and the buttons “Edit terms” and “Settle dealing day”. Anyone else who can open the tab sees the requests of their own wallets.
A rejected redemption shows one of three reasons in Reason: “The holder no longer had enough units”, “The units were worth no cash at this NAV” or “The holder cannot receive the stablecoin”. A rejection is final, so the holder lodges a new request once the cause is fixed. The new request takes its dealing day from the moment the platform records it.
Settle a redemption day
After the cut-off, and after the fund's price feed has published a NAV for the day, a supply manager selects Settle dealing day on the redemption list. The sheet asks for:
- Dealing day. It opens on the last weekday before the current date in your local time and cannot be moved later than the current date. Open requests up to and including this day settle together.
- Stablecoin. This is read-only. It is the stablecoin of the subscription terms. With no terms the sheet says “Set the subscription terms first. They name the stablecoin.”
- Paying treasury. Pick the wallet that holds the stablecoin for the payments.
The review step shows “Settlement” with the three values. Settle dealing day asks for your wallet verification and sends the call. The Console confirms with “Dealing day … settled”. That message means the platform stored the plan. No cash has moved.
The settlement prices the requests and drafts one buyback corporate action that burns the units and pays each holder in the stablecoin. The requests it takes show as Settling. A settlement that finds every request rejected is stored without a buyback.
The buyback follows the organisation's approval policy for corporate actions. That approval is off by default. Once an organisation owner or a platform administrator turns on the Corporate actions approval in General, an organisation owner or platform administrator approves the previewed buyback, and that person cannot be the supply manager who settled the day or the person who last previewed the buyback. While the approval is off, or while the organisation has no other owner who could approve, the buyback runs without a second signature. A supply manager then confirms the buyback, which burns the units and pays the cash, as Corporate actions describes.
The status of a request updates the next time someone settles, lists or creates a redemption request on the token. When a holder's payment is on the chain, that holder's requests change to Settled. The API record of the request carries the transaction hash.
If the buyback completes, or is aborted before its confirmation starts a transaction, the unpaid requests return to Open with their original dealing day and cut-off, and the next settlement takes them again.
Settle a subscription day
A supply manager settles a subscription day through the API, with POST /api/. The Console has no control for it. The call names the dealing day only, and the stablecoin and the receiving treasury come from the subscription terms.
The call must come from the receiving treasury of the terms, and that wallet must be a smart wallet, because each batch goes out as one transaction. When it is not, select Edit terms and name a smart wallet as “Receiving treasury”.
Before the day settles, each investor approves the receiving treasury to spend at least the total cash of all their open requests in the stablecoin. No dealing screen asks for this approval. The investor sets it with POST /api/ on the stablecoin, naming the receiving treasury as the spender. This is an ordinary stablecoin allowance. The receiving treasury can spend it outside a settlement too, and what is left of it stays after a request is cancelled or settled, so an investor approves no more than the open requests need.
The platform prices every open subscription request of that day or an earlier one at the day's NAV, pulls the cash from each investor and mints the units in one transaction per batch of up to ten investors. The platform rejects a request, records its reason and settles the rest of the day when the investor no longer holds the cash, has not approved the receiving treasury to spend it or cannot receive the fund token, or when the cash buys less than the smallest unit of the fund token. The API record of each request carries its NAV, units, cash and transaction hash.
What the platform checks
On a subscription request
Every refusal by the subscription rules answers HTTP 409 with DALP-14081. None is retryable as sent. The reason field says which rule applied. A new request can return one of the first seven reasons, and a cancellation one of the last three.
The request records the stablecoin of the terms at that moment.
A retry with the same idempotency key returns the first request only while the token, the terms, the wallet and the amount still pass their checks. The platform runs those checks before it looks for the key and does not repeat the eligibility check on a retry.
On a subscription settlement
Settling a subscription day answers HTTP 409. Every reason except requests-changed comes back as DALP-14081, which is not retryable as sent. requests-changed comes back as its own code, DALP-14749, which is retryable: send the same call again.
A subscription settlement drafts no corporate action. It sends the transfers and the mint itself, and no row under Approvals holds it, so the supply manager who settles from the receiving treasury takes the cash and mints the units with no second person. A repeated call with the same key and dealing day sends again only the batches whose requests are still settling, under the same transaction keys, and then returns the stored settlement. It mints no unit twice. A new key for a day that is already settled takes only requests that are still open through that day. When there are none, the call is refused with no-open-requests.
When a batch's transaction is refused or reverts on the first call, the platform returns that batch's requests and every later batch's requests to Open and fails the call. Batches that landed before it stay settled. On a repeat call with the same key, a refused batch returns only its own requests to “Open”. The platform still sends the other batches, then fails the call. The next settlement takes the reopened requests.
Each request the settlement leaves out records one reason:
On the subscription terms
Setting the terms answers HTTP 409 with the same DALP-14081 and returns token-not-subscribable or one of these four reasons.
On a redemption request
Every refusal answers HTTP 409 except DALP-14074, which answers HTTP 404. None is retryable as sent.
The amount of a redemption request is a positive whole number of base units, with no minimum. When you send the create call again with the same token and amount, it returns the stored request as it stands. A create call without an idempotency key gets one from the server and cannot be repeated. Both a new request and a repeat answer HTTP 201.
On a settlement
Every refusal answers HTTP 409. Only DALP-14103 is retryable by sending the same call.
A settlement is also refused with DALP-12067 while another corporate action on the token is unfinished, including the buyback of an earlier settlement. Wait for it to complete or stop it, then settle again.
A settlement on a token that does not take redemption requests is refused with DALP-14076. A repeat with the same key and values returns the stored settlement even when the day or the token would now be refused.
The settle sheet shows a message for each refusal. For example, nav-unavailable reads “No NAV is published for this dealing day, or it cannot price this stablecoin. Publish a NAV on the fund's price feed, then settle again.” and requests-changed reads “A request changed while the settlement was being prepared. Check the list, then settle again.”
Troubleshooting
The token has no Dealing tab
The tab shows only for a fund token that does not use register lines. Opened from a link on any other token, the screen says “Dealing is not available for this asset”. Use Booked movements for a fund with register lines.
A redemption request stays Settling
The buyback has not paid that holder, or the platform has not read the payment. The platform reads the buyback when someone settles, lists or creates a redemption request on the token, and marks the request Settled once the holder's payment is on the chain. If the buyback was aborted after its confirmation started a transaction, the platform does not reopen the unpaid requests. They stay “Settling” and their units stay counted against the holder's available units. A “Settling” request cannot be cancelled, so the holder cannot request a redemption of those units again.
Frequently asked questions
Who approves a redemption, and how is the cash paid out?
The holder's request needs no approval. The settlement turns the day's open requests into one buyback corporate action, which burns the units and pays each holder in the stablecoin from the paying treasury. Settle a redemption day says who approves and confirms the buyback.
Can a settlement include requests from earlier days?
Yes. A settlement takes every open request of the chosen dealing day or an earlier one, so a day missed earlier is settled with the next.
API routes
The request and response fields of each route are in the v2 API reference.
A supply manager lists every request of the token. Any other caller lists only requests for their own wallets. The lists filter by dealingDay and status, and by investor for subscriptions or holder for redemptions. A holder that is not one of the caller's wallets gives an empty page, not an error.
The redemption list is paginated, sorted by creation time with the newest first and never cached.
The redemption settle call answers HTTP 201 with the NAV, its feed, block time and transaction, the price per unit, the corporate action, and the totals of holders, settling requests, rejected requests, units and cash. The subscription settle call answers HTTP 200, or HTTP 202 while a batch is still queued, with the settlement's NAV, its feed, block time and transaction, the price per unit, the stablecoin and receiving treasury, and the same totals.