# Dealing

Source: https://docs.settlemint.com/docs/console/asset-management/manage/fund-dealing
Set a fund's subscription terms, follow investors' requests before the 12:00 UTC cut-off, and settle a dealing day's redemptions at the published NAV.

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](https://docs.settlemint.com/docs/console/asset-management/manage/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](https://docs.settlemint.com/docs/console/asset-management/manage/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/v2/tokens/{assetId}/subscription-settlements`: 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 of a fund with open redemption requests and the Settle dealing day button](https://docs.settlemint.com/docs/screenshots/console-fund-dealing.light.en.webp)

[Screenshot] 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.

## Before you start [#before-you-start]

- **A fund without register lines.** The Features tab of the token shows whether Booked movements is attached. The "Dealing" tab and the Dealing requests card appear only for a token of the fund type that does not use register lines. Any other token has no "Dealing" tab. The platform also refuses a request on a fund token that cannot settle a cash buyback: a redemption request with DALP-14076 and a subscription request with DALP-14081 and the reason `token-not-subscribable`.
- **The Primary market module.** Fund dealing belongs to the Primary market licensed module, which the deployment switches on with `features.tokenSale` ([Switch application layers on or off](https://docs.settlemint.com/docs/deployment/install/values-secrets#switch-application-layers-on-or-off)). With it off for the deployment, the "Dealing" tab, the Dealing requests card and the Funds section of Invest are absent and the dealing routes answer `404`. When your organisation switched it off, the requests and terms stay readable under a read-only banner, the write buttons are hidden, and every dealing write refuses with `403` and `platform.module.DISABLED` ([DALP-20531](https://docs.settlemint.com/docs/api-reference/errors)).
- **The Supply management role.** A supply manager holds the Supply management role on the token. The token's Permissions tab shows who holds it.
- **Subscription terms.** Settling a redemption in the Console pays in the stablecoin of the subscription terms, so a fund needs terms before its first settlement. The API takes the stablecoin in the settle call and does not read the terms.
- **A NAV after the cut-off.** The fund's price feed must publish a NAV after the cut-off of the dealing day and before the cut-off of the next dealing day. A value published before the cut-off does not count. [Market data](https://docs.settlemint.com/docs/concepts/records-and-evidence/market-data) explains how a fund takes its price from a feed.
- **A stablecoin.** The settlement pays in an ERC-3643 token of the stablecoin type that the platform has indexed, which is a token it has read from the network. The terms sheet lists every indexed stablecoin, but a settlement accepts only an ERC-3643 one and refuses any other with DALP-14101. Choose an ERC-3643 stablecoin when you set the terms. The stablecoin's price feed must name the same currency as the NAV.
- **A second approver, if you want one.** A redemption buyback waits for a second person only while the "Corporate actions" approval in [General](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals) is on. An organisation owner or a platform administrator turns it on.
- **Wallet verification.** Setting the terms, requesting a redemption, cancelling a redemption request and settling a day each ask you to confirm with your wallet. Lodging or cancelling a subscription request does not.

## Who can do what [#who-can-do-what]

A bank rail redemption is a separate flow that [Bank rail](https://docs.settlemint.com/docs/console/asset-lifecycle/bank-rail) covers.

| Task | Who can do it |
| --- | --- |
| Read the subscription terms | Any signed-in user |
| Set the subscription terms | A supply manager of the token |
| Lodge a subscription request | An investor, for one of their own wallets. From Invest any wallet of the investor can subscribe. From the holding page the wallet must already hold units. |
| Request a redemption | A holder, for their own wallet, with no token role needed |
| Cancel a request | The holder or investor who made it |
| Read every request of a token | A supply manager of the token |
| Read your own requests | Any holder or investor, for their own wallets |
| Settle a dealing day | A supply manager of the token. A subscription day settles only from the receiving treasury of the terms. |

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 [#steps]

### Set the subscription terms [#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 [#investors-lodge-and-cancel-requests]

An investor who holds no units yet subscribes from [Invest](https://docs.settlemint.com/docs/console/my-assets/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](https://docs.settlemint.com/docs/console/my-assets/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 [#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 [#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](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals), 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](https://docs.settlemint.com/docs/console/asset-management/manage/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 [#settle-a-subscription-day]

A supply manager settles a subscription day through the API, with `POST /api/v2/tokens/{assetId}/subscription-settlements`. 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/v2/tokens/{assetId}/approvals` 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 [#what-the-platform-checks]

### On a subscription request [#on-a-subscription-request]

Every refusal by the subscription rules answers HTTP 409 with [DALP-14081](https://docs.settlemint.com/docs/api-reference/errors/platform-api-error-reference#domain-rule-errors). 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.

| Reason | What it means and what to do |
| --- | --- |
| `token-not-subscribable` | The token is not a fund without register lines. The platform checks this first. Use a fund token that takes dealing. |
| `terms-not-found` | The fund has no subscription terms. A supply manager sets them first. |
| `investor-not-caller` | The wallet is not one of the caller's wallets. Send one of your own. |
| `amount-not-positive` | The amount is zero or less. Send a larger amount. |
| `below-minimum` | The amount is under the minimum of the terms. Send at least the minimum. |
| `investor-ineligible` | The investor cannot receive the token under its identity and compliance rules, or the platform could not verify that. Resolve the identity or compliance cause first. |
| `idempotency-conflict` | The key already recorded a request for another wallet or amount. Use a new key. |
| `request-not-found` | On a cancellation, no request of this token with that identifier belongs to the caller. List your requests and use an identifier from the list. |
| `request-not-open` | On a cancellation, the request is no longer open: it is cancelled, settling, settled or rejected. Read the request for its status. |
| `cut-off-passed` | On a cancellation, the cut-off of the request's dealing day has passed. The request stays open. |

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 [#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.

| Reason | What it means and what to do |
| --- | --- |
| `terms-not-found` | The fund has no subscription terms. A supply manager sets them first. A repeat of a stored idempotency key is answered before this check. |
| `token-not-subscribable` | The token is not a fund without register lines, or it does not take subscription settlements. The platform checks this after it finds the terms. Use a fund token that takes dealing. |
| `not-a-dealing-day` | The date is a Saturday or Sunday. Send a weekday. |
| `nav-unavailable` | The feed published no NAV in the day's window, the fund has no price feed set up, the platform has no feed directory, the NAV value cannot be read as a positive decimal, or the NAV prices one unit at zero of the stablecoin. Publish the NAV, then settle again. |
| `no-open-requests` | No subscription request is open for this dealing day or an earlier one. Settle a day that has open requests. |
| `stablecoin-unsupported` | The terms name a stablecoin that is not an indexed ERC-3643 token of the stablecoin type, or is the fund token itself. Set the terms again with another stablecoin. |
| `currency-mismatch` | The NAV and the stablecoin are not priced in the same currency, or one of them names no currency. Choose a stablecoin priced in the NAV's currency. |
| `treasury-not-executor` | The call executes from another wallet than the receiving treasury of the terms. Settle from the receiving treasury, so the allowance each investor gave is the one spent. |
| `requests-changed` | Open requests changed while the platform prepared the settlement. It stored nothing. Send the same call again. |
| `settlement-key-reused` | The idempotency key belongs to a settlement of another dealing day. Use a new key. |

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:

| Reason | What it means |
| --- | --- |
| `insufficient-cash` | The investor no longer holds the cash. |
| `cash-not-allowed` | The investor's remaining allowance to the receiving treasury does not cover the cash. |
| `investor-ineligible` | The fund token would not let the investor receive units. |
| `stablecoin-changed` | The request was lodged in another stablecoin than the terms now name. |
| `zero-units` | The cash buys less than the smallest unit of the fund token at that NAV. |

### On the subscription terms [#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.

| Reason | What it means and what to do |
| --- | --- |
| `stablecoin-is-token` | The stablecoin is the fund token itself. Choose another stablecoin. |
| `stablecoin-not-indexed` | The platform has not indexed the stablecoin on this network. Choose one the picker lists. |
| `treasury-invalid` | The receiving treasury is the zero address or the fund token. Choose another wallet. |
| `amount-not-positive` | The minimum is zero or less. Leave it empty or set a positive amount. |

### On a redemption request [#on-a-redemption-request]

Every refusal answers HTTP 409 except DALP-14074, which answers HTTP 404. None is retryable as sent.

| Code | Reason | What it means and what to do |
| --- | --- | --- |
| DALP-14074 | `request-not-found` | No such request belongs to your wallets on this token. This covers another holder's request, another token's request and an unknown identifier. List your requests and use an identifier from the list. |
| DALP-14075 | `holder-not-caller` | The holder is not the wallet that signs the request. Leave the holder out or send the signing wallet. |
| DALP-14076 | `token-not-redeemable` | The token is not a fund that can settle a cash buyback without register lines, or the platform could not read it. Use a fund token that takes dealing. |
| DALP-14077 | `exceeds-available-units` | The amount is over the available units less the wallet's open and settling requests. Frozen units are not available. Send a smaller amount or cancel an open request. |
| DALP-14078 | `cut-off-passed` | A cancellation came at or after the cut-off. The request stays open. |
| DALP-14079 | `request-not-open` | A cancellation hit a request that is not open. The platform answers this before it checks the cut-off. Read the request for its status. |
| DALP-14080 | `idempotency-key-reused` | The key belongs to a request for another token or amount. Use a new key. |

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 [#on-a-settlement]

Every refusal answers HTTP 409. Only DALP-14103 is retryable by sending the same call.

| Code | Reason | What it means and what to do |
| --- | --- | --- |
| DALP-14098 | `not-a-dealing-day` | The date is a Saturday or Sunday. Send a weekday. |
| DALP-14099 | `nav-unavailable` | The feed published no NAV in the day's window, the fund has no price feed set up, the platform has no feed directory, or the NAV gives a price of zero. Publish the NAV, then settle again. |
| DALP-14100 | `no-open-requests` | No request is open for this dealing day or an earlier one. Settle a day that has open requests. |
| DALP-14101 | `stablecoin-unsupported` | The asset is not an indexed ERC-3643 token of the stablecoin type, or it is the fund token. Send another stablecoin. |
| DALP-14102 | `currency-mismatch` | The NAV and the stablecoin are not priced in the same currency, or one of them names no currency. Choose a stablecoin priced in the NAV's currency. |
| DALP-14103 | `requests-changed` | Open requests changed while the platform prepared the plan. It stored nothing. Send the same call again. |
| DALP-14104 | `settlement-key-reused` | The idempotency key belongs to a settlement of another day, stablecoin or treasury. Use a new key. |

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."

## You should see [#you-should-see]

- On the **Dealing** tab, the redemption requests of the settled day change from "Open" to "Settling" once you settle, and to "Settled" once each holder's payment is on the chain.
- A settled row shows the "NAV" and the "Cash" the holder received, and a rejected one names its "Reason".
- Subscription terms you saved show on the "Subscription terms" card, with "Last updated".
- Check the buyback in [Corporate actions](https://docs.settlemint.com/docs/console/asset-management/manage/corporate-actions) for the units burned and the cash paid.
- After a subscription day, the "Subscription requests" list shows each settled request as "Settled" or "Rejected", and the API record of each request carries its NAV, units, cash and transaction hash.

## Troubleshooting [#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](https://docs.settlemint.com/docs/console/asset-management/manage/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 [#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](#settle-a-redemption-day) says who approves and confirms the buyback.

### Which NAV prices a request?

Both kinds of request get the latest NAV that 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 platform refuses the day when the feed published none. A request from an earlier day is priced at the NAV of the day you settle.

For a redemption, once a request of the day has been paid, every later settlement of the day uses the same NAV. The price per unit and each holder's cash are rounded down. For a subscription, the units are the cash divided by the NAV, rounded down to the token's decimals. The cash taken is those units multiplied by the NAV, rounded up to the stablecoin's smallest unit, so it is never more than the requested cash. A request whose cash buys less than the smallest unit of the token is rejected and mints nothing.

### 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 [#api-routes]

| Task | Route |
| --- | --- |
| Read the terms | `GET /api/v2/tokens/{assetId}/subscription-terms` |
| Set the terms | `PUT /api/v2/tokens/{assetId}/subscription-terms` |
| Lodge a subscription request | `POST /api/v2/tokens/{assetId}/subscription-requests` |
| List subscription requests | `GET /api/v2/tokens/{assetId}/subscription-requests` |
| Cancel a subscription request | `POST /api/v2/tokens/{assetId}/subscription-requests/{requestId}/cancellations` |
| Request a redemption | `POST /api/v2/tokens/{assetId}/redemption-requests` |
| List redemption requests | `GET /api/v2/tokens/{assetId}/redemption-requests` |
| Cancel a redemption request | `POST /api/v2/tokens/{assetId}/redemption-requests/{requestId}/cancellations` |
| Settle a redemption day | `POST /api/v2/tokens/{assetId}/redemption-settlements` |
| Settle a subscription day | `POST /api/v2/tokens/{assetId}/subscription-settlements` |

The request and response fields of each route are in [the v2 API reference](https://docs.settlemint.com/docs/api-reference/v2).

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.