# Fund dealing

Source: https://docs.settlemint.com/docs/concepts/issuing-and-markets/fund-dealing
Fund dealing groups requests by UTC dealing day, closes each day at 12:00 UTC, and settles subscriptions and redemptions at one published net asset value.

An open-ended fund takes in and pays out money continuously, but it cannot price each request separately. Fund dealing gives every request a dealing day, closes the day at a fixed cut-off, and lets the fund operator settle the day's requests together at one net asset value (NAV) per unit. A dealing day is a weekday counted in UTC. The cut-off is 12:00 UTC on that day.

Dealing applies to a fund token that can settle a cash buyback and whose units are not on register lines. Register lines are the holder register that the [Booked movements](https://docs.settlemint.com/docs/console/asset-management/manage/booked-movements) feature keeps, and [Token features](https://docs.settlemint.com/docs/concepts/modeling-assets/token-features) lists the features a token carries. The platform refuses a request on any other token, including a bond.

The platform keeps two books for each fund token. The subscription book holds investors' requests to put in a cash amount. The redemption book holds holders' requests to give back a number of units. The books live in the platform and move no units. Requests, cancellations and rejections are platform records with no chain event, and only the settlement transactions reach the chain. The Console page [Fund subscriptions and redemptions](https://docs.settlemint.com/docs/console/asset-management/manage/fund-dealing) covers the screens. This page covers the model behind them.

Fund dealing belongs to the Primary market licensed module, together with offerings ([Switch application layers on or off](https://docs.settlemint.com/docs/deployment/install/values-secrets#switch-application-layers-on-or-off)). An organisation that opts out of it keeps its requests readable, and the platform refuses new requests, cancellations, term changes and settlements until the module is back on. A buyback that a settlement drafted before the opt-out stays a corporate action, and its approval and confirmation still run.

## The dealing calendar [#the-dealing-calendar]

Every request, in both books, takes its dealing day from the instant the platform records it, so the same instant always gives the same day and a client cannot choose its own. The calendar reads no holiday list, so a bank holiday on a weekday is still a dealing day.

| When the platform records the request | Dealing day it belongs to |
| --- | --- |
| Monday to Friday, before 12:00:00 UTC | That same day |
| Monday to Thursday, at or after 12:00:00 UTC | The next day |
| Friday, at or after 12:00:00 UTC | The following Monday |
| Saturday or Sunday | The following Monday |

The cut-off of a request is 12:00 UTC of its own dealing day. A holder or investor can cancel an open request until that instant. The cut-off follows from the request's dealing day alone, and the platform compares it with its own clock, never with a time the client sends. A cancel at 12:00:00.000 UTC or later is refused.

## Subscriptions record a cash amount [#subscriptions-record-a-cash-amount]

A subscription request names a wallet of the investor and a cash amount in the fund's subscription [stablecoin](https://docs.settlemint.com/docs/concepts/modeling-assets/stablecoin). It records the amount, not a number of units. The Console and the Investor portal take the amount in the same field as a transfer, which shows its value in the stablecoin's price currency when the stablecoin has a price. Before anyone can subscribe, a supply manager, a holder of the token's supply management role, sets the subscription terms: the stablecoin, the treasury that receives the cash and an optional minimum amount. A fund with no terms refuses every subscription request. A supply manager can change the terms at any time, the receiving treasury included, and the change needs no second approval.

The platform checks the request when the investor lodges it. The amount must be more than zero and at least the minimum. The wallet must belong to the investor. The platform also checks that the token's identity and compliance rules would let the wallet receive units. It refuses the request when they would not, or when it cannot complete the check.

A subscription request does not move or lock cash when the investor lodges it. The cash stays in the investor's wallet until the settlement pulls it, on the allowance the investor gave the receiving treasury. That allowance is not tied to any request on chain, so the treasury wallet can draw on it up to its limit. An investor who approves only what their open requests need limits that exposure. The request stays open until the investor cancels it before its cut-off or the operator settles its dealing day.

A supply manager settles a subscription day through the API, signing with the wallet that is the receiving treasury of the terms. A call from any other wallet is refused with [DALP-14081](https://docs.settlemint.com/docs/api-reference/errors/platform-api-error-reference#domain-rule-errors). Subscription settlement takes no second approval. The platform reads the fund's NAV for that day from the price feed and prices each open request of that day or an earlier one. In one transaction per batch of up to ten investors, it pulls each investor's stablecoin to the receiving treasury and mints the units. A priced request is settling until its transaction is on the chain, then settled.

A request the settlement leaves out is rejected with its reason:

- The investor's cash, after their earlier requests in the same settlement, no longer covers the request.
- The investor's allowance to the receiving treasury, after their earlier requests in the same settlement, does not cover the request.
- The investor cannot receive the fund token.
- The cash buys less than the smallest unit of the fund token at that NAV.
- The request was lodged in another stablecoin than the terms now name.

When a batch's transaction is refused or reverts on the first call, that batch's requests and every later batch's requests return to open and the call fails. 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, and the other batches are still sent. A batch that does not land in time stays settling until the operator repeats the call with the same key. The next settlement takes the reopened requests.

## Redemptions settle at the NAV of the dealing day [#redemptions-settle-at-the-nav-of-the-dealing-day]

A redemption request names a holder wallet and a number of units. The platform checks it against the units the wallet has available, less the wallet's other open and settling requests on the token and less any frozen units. An amount up to that figure is accepted and an amount over it is refused. A request does not lock units on chain, because a lock would need a transaction for every request, and the wallet can still move them. The platform checks the units again when the operator settles, and rejects the request if they are gone.

A redemption request has five statuses.

[Figure] The five statuses of a redemption request. A request starts open. The holder can cancel it before the cut-off, which makes it cancelled. A settlement can reject it, which makes it rejected. A settlement can take it, which makes it settling. A settling request becomes settled once its payment is on the chain, and returns to open if the buyback that would pay it completes without paying it or is aborted before its confirmation starts a transaction. Labels: Open; until cancelled or settled; Cancelled; holder, before cut-off; Settling; a buyback is drafted; open again if unpaid; Rejected; the settlement refuses it; Settled; payment on chain.

A request starts open and ends cancelled, rejected or settled, and a settling request returns to open when its buyback does not pay it.

Cancelled, settled and rejected are final statuses, and a rejected request is not retried, so the holder lodges a new one.

### How the operator settles a day [#how-the-operator-settles-a-day]

After the cut-off, a supply manager settles a redemption day. The call names the dealing day, a stablecoin and the paying treasury. The platform then works in this order.

1. It takes every open request of that dealing day or an earlier one. A day missed earlier is therefore settled with the next one.
2. It reads the NAV: the latest value the fund's price feed published, by block time, from the dealing day's cut-off up to the next dealing day's cut-off, and never later than the moment of settlement. The NAV belongs to the day being settled, so a request from an earlier day is priced at that NAV too. Once a request of the day has been paid, every later settlement of that day uses the same NAV. See [Market data](https://docs.settlemint.com/docs/concepts/records-and-evidence/market-data) for how a fund takes its price from a feed.
3. It turns the NAV into a price per unit in the smallest unit of the stablecoin, rounded down. The NAV and the stablecoin's own reference price must name the same currency.
4. It covers each holder's requests in creation order against the units the holder has available. A request the units do not cover is rejected as `insufficient-units`. A holder whose cash rounds to zero has its requests rejected as `zero-cash`. A holder the stablecoin would refuse to pay from the treasury has its requests rejected as `cash-not-receivable`. The cash of a holder is its units times the price per unit, rounded down, so the remainder stays in the paying treasury.
5. It drafts one buyback corporate action with a cash leg. The buyback names each paid holder once, with its units, and carries the one price per unit. The covered requests become settling, each with its cash.

The platform stores the settlement, the rejected requests, the settling requests and the corporate action in one transaction. If the open requests changed while it prepared the plan, it stores nothing and refuses the call with [DALP-14103](https://docs.settlemint.com/docs/api-reference/errors/platform-api-error-reference#domain-rule-errors), which a caller can retry. If every request is rejected, the settlement is stored without a corporate action.

The settlement does not move money. The buyback is a corporate action. The Corporate actions row under Approvals in the [General](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals) organisation settings starts off. Once an owner or a platform administrator turns it on, the buyback needs [maker-checker](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker) approval: an organisation owner or platform administrator other than the supply manager who settled the day approves it. While it is off, or while the organisation has no other owner who could approve, the buyback runs without a second signature. The approval holds back the platform's own submission. The token checks only the supply management role, so it does not bind a supply manager who calls the token directly. A supply manager then confirms the buyback, which burns the units and pays the cash. The Console page [Corporate actions](https://docs.settlemint.com/docs/console/asset-management/manage/corporate-actions) covers that review.

Only one corporate action can run at a time on a token, so a settlement is refused with [DALP-12067](https://docs.settlemint.com/docs/api-reference/errors/platform-api-error-reference#domain-rule-errors) while an earlier buyback is still unfinished.

### The requests follow the buyback [#the-requests-follow-the-buyback]

The platform reads the buyback again whenever someone settles, lists or creates a redemption request on the token. A holder whose payment is on the chain has its settling requests marked settled, with the transaction hash and the time the platform recorded the payment. When the buyback completes, or is aborted before its confirmation starts a transaction, a holder's unpaid requests return to open with their original dealing day and cut-off. The next settlement takes them again. 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 read that fails is logged and does not block the call.

## Frequently asked questions [#frequently-asked-questions]

### Does the platform calculate the NAV?

No. A trusted issuer of the fund's price feed topic publishes it, and the settlement reads the value published for the dealing day. The platform does not keep that publisher apart from the supply manager who settles, so separate the two in your own controls if they require it. A request is never priced before its cut-off, and a dealing day with no NAV published between its cut-off and the next cut-off cannot be settled. A redemption settlement is refused with [DALP-14099](https://docs.settlemint.com/docs/api-reference/errors/platform-api-error-reference#domain-rule-errors) and a subscription settlement with [DALP-14081](https://docs.settlemint.com/docs/api-reference/errors/platform-api-error-reference#domain-rule-errors) and the reason `nav-unavailable`, until someone publishes one.

### Can a supply manager cancel an investor's request?

No. A cancellation works only for the wallets of the holder or investor who made the request. A request that belongs to another wallet, belongs to another token or does not exist answers as not found, for a supply manager too.

### What if the same request is sent twice?

A redemption request call is idempotent per holder and idempotency key. A repeat with the same token and amount returns the stored request as it stands now, even when it was cancelled in the meantime, and never reopens it. A repeat with another token or amount is refused.

A subscription request call is idempotent per token and key. A repeat with the same investor and amount returns the stored request while the token, the terms, the wallet and the amount still pass their checks, and a repeat with another investor or amount is refused.

### When does an investor use fund dealing instead of a Primary Offering?

A [Primary Offering](https://docs.settlemint.com/docs/concepts/issuing-and-markets/primary-offering) is a one-time first sale of a token on fixed terms. Fund dealing serves an open-ended fund after that, taking subscriptions and redemptions every dealing day at that day's NAV.

### How does a bank transfer payout relate to this?

It does not. A fund redemption pays in a stablecoin through a buyback. The redemption requests of the bank rail are a separate flow with their own roles, and [Bank rail](https://docs.settlemint.com/docs/console/asset-lifecycle/bank-rail) covers them.

## Related concepts [#related-concepts]

- [Corporate Action](https://docs.settlemint.com/docs/concepts/issuing-and-markets/corporate-action): The buyback lifecycle that pays a settled redemption day.
- [Primary Offering](https://docs.settlemint.com/docs/concepts/issuing-and-markets/primary-offering): The first sale of a token at a fixed price.
- [Market data](https://docs.settlemint.com/docs/concepts/records-and-evidence/market-data): The feed that publishes the NAV.
- [Maker-Checker](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker): The second approval a buyback can require.