Subscription and Token Issuance

AI-assisted educational manuscript. This is an invented subscription protocol, not a live financial service.

Learning objectives

• Specify subscription transitions and completion evidence.
• Prevent duplicate issuance and preserve unresolved cash.
• Handle partial success without guessing a transaction outcome.

A request is not an issued interest

Subscription combines a participant's request, acceptance under the instrument's rules, a payment process and recording of the resulting interest. These events can happen in different systems. A fund share represents an interest in a pooled investment; the number issued must follow the actual valuation and subscription arrangement, not merely the amount typed into a form. SEC: Mutual Funds

Define authoritative states such as requested, under review, payment pending, payment reconciled, authorized, submitted, issued, rejected and refund pending. These are a teaching design. Their purpose is to distinguish facts and expose exceptions, not impose a universal financial process. The BIS's tokenization framework supports examining platform rules with the external arrangement. BIS

Worked example: uncertain transaction confirmation

Imagine a participant subscribes 12,000 currency units to a fictional fund. The assumed dealing price is 12 per share and a stated one-off subscription charge is 120. If the agreement deducts that charge from the contribution, investable cash is 11,880 and authorized issuance is 11,880 / 12 = 990 shares. The example assumes whole shares and no other costs.

The operator submits an issuance transaction and loses its network connection before receiving a receipt. It must not infer failure from the connection error. Record the transaction identifier and business subscription ID, query the authoritative ledger outcome and reconcile the authorized 990 shares before retrying.

If the transaction succeeded and the receipt was missed, another mint could create an extra 990 shares. If it failed, the 11,880 cash remains associated with an unresolved subscription; it should not vanish from accounting. A retry must refer to the same authorized business case and preserve the history.

SUB-72: requested 12,000
  → accepted terms and eligibility
  → reconciled payment 12,000
  → charge 120, investable 11,880
  → authorized 990 shares
  → submitted TX-A → unknown receipt → inspect authoritative state
                                   → issued / confirmed failed / unresolved

An “unresolved” state is useful. It prevents an operator from manufacturing certainty simply to advance a workflow.

What must be invariant

In this teaching protocol, one accepted subscription must not produce more than its authorized shares. Every received payment must remain matched to an issued interest, a documented outstanding case or a reconciled refund. A refund request is not completed until payment evidence confirms the relevant result. An authorization change must record why the number changed and who had authority.

Use a business identifier for deduplication across systems. A transaction hash identifies one ledger transaction; it does not by itself identify all attempts to satisfy one subscription. Likewise, “payment sent” and “payment received” are different evidence. A third-party notification should be authenticated and reconciled under the relevant integration design rather than trusted as an instruction to mint.

Test duplicate requests, wrong currency, underpayment, overpayment, stale prices, expired eligibility, partial service outages and unauthorized issuance. The expected outcome should preserve balances and explain the next permitted action. Tests should not fabricate a legal entitlement to keep or return funds on unspecified terms.

Common misconceptions

“A failed screen means the financial operation failed.” Presentation and authoritative execution can diverge.

“Idempotency means every attempt uses the same hash.” The business invariant is no duplicate entitlement; retries can require separate technical attempts under controlled rules.

“Receiving money authorizes minting.” Acceptance, price and eligibility remain separate conditions.

Risks and limits

This simplified protocol omits real finality, reversibility, currency conversion, legal acceptance and safeguarding requirements. The fee and price are fictional. Production design requires actual documents, authorized operators and payment-system evidence. No subscription or refund was directly tested here.

Exercise and answer

Exercise: Payment is reconciled, 990 shares are authorized, and the network receipt is missing. Should the operator immediately mint again?

Answer: No. First resolve the original transaction's authoritative status and reconcile it with the subscription. Preserve an unresolved case if that evidence is unavailable.

Related learning

Continue in product architecture with trading and settlement, and test request-versus-completion distinctions in Labs.

Source map

sec-funds provides U.S. fund-share basics; bis-tokenisation provides international arrangement research. Retrieval evidence is dated 2026-10-18. All states, charges, identifiers and invariants above are original educational design choices, not claims that a specific product uses this process.