トークン化ファンドの申込から償還まで｜締切とNAVの当て方・訂正・償還停止

ある資産運用会社が、自社のファンドの持分をトークンにして販売することになりました。プロダクト責任者が申込から償還までの流れを書き出すと、ほかの資産のトークン化にはない、ファンドならではの問いが2つ出てきます。

1つめは、締切とNAV（基準価額）の問いです。たとえば、投資家が締切の直前にウォレットで申込に署名し、その注文がサーバーに届いたのは締切の後だったとします。この注文は、どの日の、どの評価時点のNAVで約定させるのか。後からNAVが訂正されて、発行した口数が変わったらどう直すのか。

2つめは、償還の問いです。償還の制限・繰延・停止が起きたとき、持分と資金をどの状態で持っておき、どう再開するのか。

どちらも、トークンを発行するだけの仕組みでは答えられません。申込、入金、当てるNAV、持分の発行を、別々の段階として記録しておく必要があります。分配と償還も同じ取引の記録に結びつけておけば、NAVの訂正や支払の失敗が起きても、照合してから再開できます。以下では、この2つの問いを軸に、適格性の確認から申込、NAVの確定、発行、移転、分配、償還、訂正・障害への対応までを1本の流れとして見ていきます。

扱うのは、決まった商品条件をシステムに組み込むための技術・業務の設計です。後半には、アーキテクトが使う状態表や項目名をまとめています。

この記事でわかること

• どの記録が何を確定するかの決め方と、申込から発行までの段階
• 締切とNAVの当て方、NAVの訂正、分配と償還の進め方
• 障害時の確かめ方と、本番前の10の受入条件

RWA（現実資産）トークン化全体の構造はRWAトークン化の入門記事、移転制限をトークン側で強制する規格はERC-3643の設計記事が前提知識の補いになります。

最初に決める：どの記録が何を確定するか

英国Investment Associationの実装指針は、ファンドの記録を3つに分けて整理しています。顧客の名簿、ファンド持分の原簿、ファンドの資産台帳です。そのうえで、初期の段階では、DLT（分散型台帳技術）を持分の原簿の正本にしながら、資金の決済と日次等の価値の評価は今の仕組みに残す構成を示しています（UK Fund Tokenisation: A Blueprint for Implementation）。つまりトークン化は、今のファンドの全業務を1つのスマートコントラクトに置き換えることではありません。

日本でも、金融庁は、トークン化した有価証券にも元の権利に応じた規制がかかると説明しています。一定の信託受益権や集団投資スキームの持分をトークン化した場合は、電子記録移転権利（トークン化された権利として規制される区分）として扱われえます（金融庁 FinTechサポートデスク Q7-2）。

金融庁の研究会では、帳簿の書換えと権利の移転が一連であるかが、法的な区分にも関係すると議論されています。今の国内のST（セキュリティトークン）では、役割を分けている構成も示されました。売買の約定はチェーンの外、権利の移転はブロックチェーン、資金の決済は今までの手段という分け方です（デジタル・分散型金融への対応のあり方等に関する研究会 第11回議事録）。

このように記録ごとに担い手が違うので、設計書では最初に次の4つの問いに答えます。

1. トークンの残高は、法的な受益者原簿そのものか。それとも原簿を更新するための入力か。
2. NAVを確定するのは誰か。
3. 銀行の入金が確定したこと（ファイナリティ）を、何で判定するか。
4. 分配・償還の債務を、どの台帳が確定するか。

DLTを正本にする場合も、管理者が誤記の訂正、裁判所の決定、投資家への対応を実行できなければなりません。ネットワークが止まったときに残高を復元できる統制も要ります。FCAが2026年4月30日に公表した方針書も、ファンドの運用会社が受益者原簿をDLT上で管理するための指針を示す一方で、原簿を管理する権限と事業継続計画を持ち続けるよう求めています（FCA PS26/7）。

申込から発行までを、段階に分けて記録する

銀行の決済、ファンドの会計、DLTは、確定するタイミングも、失敗のしかたも違います。そこで全工程を、いくつもの仕組みにまたがる一連の処理として扱います。段階ごとに、入力、次へ進む条件、やり直す条件を保存します。

申込から発行までは、次の6段階です。

1. 受付：注文の原文と受付の時刻を保存する。商品・投資家・ウォレットの適格性を確かめ、合わなければ理由を付けて断る
2. 受理：どの締切の区分に入るかと、商品条件の版を固定する。取消の期限内だけ取り消せる
3. 入金確認：入金を、対象のファンド・クラスに結びつける。出どころの分からない入金は保留にし、別のファンドに回さない
4. 価格の確定：NAVの版と発行する口数を固定する。NAVが訂正されたら、古い版を無効にして計算し直す
5. 発行の送信：署名したデータと、二重実行を防ぐ番号を固定する。タイムアウトしても、やみくもに送り直さない
6. 決済完了：原簿、トークンの供給量、資金、口数がそろったことを照合する。差があれば例外として切り分ける

どの段階を通っても、次の3つの関係は必ず成り立つようにします。

• 発行した口数＝確定した入金額÷当てたNAV
• クラスの総発行量＝投資家の残高の合計＋管理された仮勘定
• 1つの業務目的から成功する発行・消却は、1回だけ

小数の処理には、浮動小数点を使いません。NAV、通貨、口数それぞれの小数の桁と丸めのルールを、商品条件の版に固定します。投資家ごとに丸めた後の合計と、まとめて処理した総額が合わないときの端数の扱いも、先に決めておきます。

どの注文に、どのNAVを当てるか

申込画面が見せる参考のNAVと、約定の口数の計算に使う正式なNAVは、同じ値として扱ってはいけません。また注文には、受付の時刻だけでなく、次のことを保存します。

• タイムゾーン、営業日のカレンダー
• 締切のルールの版、対象の評価時点

冒頭の、締切の直前に署名し、締切の後に届いた注文を思い出してください。これを「日付が同じだから」という理由で前のNAVに入れてしまわないよう、サーバーが受け取った時刻と署名した時刻のどちらを優先するかも決めておきます。

NAVをチェーン上へ届ける例として、DTCCのSmart NAV実証があります。今ある価格・金利のデータを標準の形にしてチェーン上へ配り、履歴を取り出せる仕組みを検証しました。これはNAVの算定そのものをスマートコントラクトへ移す提案ではありません。確定したデータを、確かめられる形で下流へ届ける設計です（DTCC Smart NAV Pilot Report）。NAVを届ける経路の正本・鮮度・訂正の扱いは、RWA・金融システムのオラクル設計で詳しく扱っています。

NAVの記録には、少なくとも次のものを持たせます。

• ファンド、持分クラス、評価の日時、タイムゾーン
• 1口あたりのNAV、通貨、小数の桁、丸めの方式
• NAVの版、状態（暫定・確定・訂正）、算定した人・承認した人
• 元のファイルか算定結果のハッシュ、公開の時刻、訂正前の版への参照

NAVを訂正するときは、過去の記録を上書きしません。影響する注文を版ごとに取り出し、どう直すかを商品条件と管理者の判断に従って決めます。差額の入金・返金、追加の発行、消却、金銭での調整です。

すでに外へ移された持分は、一方的に書き換えられないこともあります。そのため訂正の手順には、通常の発行より強い権限と監査の記録が要ります。

申込は、入金を確かめるだけでは発行しない

申込のときに確かめるのは、投資家のKYC（本人確認）だけではありません。

• 対象の持分クラス、販売地域、投資家の区分、最低金額
• ウォレットの管理の形、制裁・凍結、注文を受け付けられる日

適格性の結果は、「はい／いいえ」だけにしません。判定したルールの版、確かめた人、期限、判定の理由を保存します。個人情報や審査資料は、公開のブロックチェーンに書きません。トークンのスマートコントラクトには、ウォレットの許可の状態や失効を確かめるための最小限の参照だけを渡します。

資金も、「残高が増えた」だけでは確かめたことになりません。送金した人、金額、通貨、受渡日、対象のファンド・クラス、返金できるかまで照合します。名義の食い違い、多すぎ・少なすぎ、複数の注文の合算、出どころの分からない入金は、自動の発行から外します。オムニバス口座を使う場合も、どのサブファンドの資金かを社内の台帳で分けます。

FCA PS26/7も、投資家がファンドと直接取引する任意の方式（Direct to Fund）を検討する中で、資金の扱いを重視しています。資金の動きをサブファンドに結びつけること、結びつかない入金を返金等の対象にすること、オムニバスの資金口座を照合することです。

発行の処理には、注文とNAVの版と「発行」という操作を組み合わせた、二重実行を防ぐ番号（冪等性キー）を持たせます。送信がタイムアウトしても、ブロックチェーン上ではすでに成功しているかもしれません。そのため、同じnonce（取引の通し番号）、イベント、実行結果、対象のウォレットの残高を確かめます。「まだ反映されていない」と確定するまで、新しい取引を作りません。

Swift、UBS Asset Management、Chainlinkの実証も、今の法定通貨の決済を使いながら連携させる処理を示しています。支払の前提条件がそろったときにファンドのトークンを発行し、償還のときに消却する処理です（Swiftによるトークン化ファンドの申込・償還実証）。

持分を移すときは、トークン残高と受益者原簿を同じ結果にする

持分の移転を許す場合、受け取る側のウォレットが技術的に受け取れるだけでは足りません。次のことを判定します。

• 受け取る人の適格性、移転の制限、ロックアップ
• 残高の上限、取引の停止
• 差押え・相続などの例外

そのうえで、法的な権利者の記録とトークンの残高が同じ結果になる順番を決めます。日本銀行のデジタル通貨フォーラムの資料も、国内のSTでは、ブロックチェーン上の投資家情報と受益権の原簿を連動させて、法律上の保有者を管理する構成を説明しています（「セキュリティ・トークン（ST）とCBDCについて」）。

チェーン上を主な記録にしても、チェーンの再編、インデクサー（ブロックを読んで社内に取り込む部品）の遅れ、複数のネットワーク、ウォレットの復旧を考えます。原簿に反映するのは、確定したブロックまでにします。確定の判定のしかたはチェーン再編とファイナリティの設計を参考にしてください。イベントの処理は、ブロックのハッシュとログの番号で重複を除きます。

同じクラスを複数のチェーンに発行する場合は、注意が要ります。全チェーン合計の供給の上限と、ブリッジのときの消却・発行（またはロック・発行）を、1つの供給量の管理機能でまとめて管理します。そうしないと、同じ権利を二重に表示してしまうおそれがあります。

トークンが24時間移転できても、ファンドの会計や原簿の管理が24時間確定するとは限りません。次のことを、投資家向けの条件と運用手順書にそろえて書きます。

• 週末の移転が、法的・業務上いつ有効になるか
• 表示するNAVの新しさ、ネットワーク手数料の負担
• 止まったときの扱い

FCAも、ほぼ連続して投資家どうしで移転できる場合について、明確にすべき点を挙げています。決済の確定性、週末の取引の扱い、参考価格の提供と費用の開示です。

分配は、残高を固定してから計算・支払・照合する

分配は、トークンの保有者へ今の残高の割合ですぐに送金する処理ではありません。まず、権利が確定する日時、対象のブロック、除く残高、分配の原資、通貨、源泉・手数料などの業務条件を確定します。残高のスナップショットを固めてから、計算します。法務・税務・会計の扱いと投資家ごとの控除は商品条件の側で決め、システムはそのルールの版を再現できる形で当てはめます。

1. 権利が確定する日を決める：タイムゾーンと、対象の確定したブロックを対応させ、遅れて届いたイベントも取り込む。
2. 分配の対象の残高を作る：自社の保有、仮勘定、凍結、償還の処理中などを、商品条件に従って分ける。
3. 受け取る額を計算する：1口あたりの分配額、通貨の小数の桁、丸め、端数をどこに帰すかを、版で管理する。
4. 支払う：銀行振込、トークン化預金、ステーブルコインなど、決済の手段ごとに指図の番号を振る（トークン化預金の仕組みはトークン化預金のシステム開発を参照）。
5. 結果を照合する：届かない、戻ってきた、ウォレットの凍結、宛先の誤りを例外として処理し直す。支払済みのものを二重に送らない。

分配の方式には、トークンの残高そのものを増やす方式、追加のトークンを発行する方式、トークンの残高を変えずに現金を払う方式があります。どれを選ぶかで、原簿、会計、税務、外部のシステムとの連携の意味が変わります。BISのトークン化MMF（マネー・マーケット・ファンド）の整理でも、収益を追加のトークンで払う構成と、NAVの上昇に反映する構成が区別されています（BIS Bulletin No.115）。

BlackRockのBUIDLなど、代表的なトークン化MMFの概要はRWAトークン化の入門記事で紹介しています。方式の名前だけで決めず、持分クラスの権利と今の事務を基準に選びます。

償還は、持分を先に動かせなくしてから進める

償還の注文を受けたら、対象の口数を、通常の移転に使えない「償還のためにロック」した状態に移します。締切とNAVが確定した後に償還の金額を計算し、消却と支払を対応させます。

ここで、消却と支払のどちらかだけが失敗することがあります。

• 消却が先に確定して、支払が失敗した → 債務を持ち続け、支払を送り直せるようにする
• 支払が先に確定して、消却が失敗した → 同じ持分を、もう一度償還できないようにする

資金とトークンを同じ台帳の上で一度に交換できない場合は、完全に同時に実行できるふりをしません。途中で失敗したら、逆向きの処理で埋め合わせる作り（saga）にします。各段階に埋め合わせの処理を持たせ、ロック → 価格の確定 → 消却の確定 → 支払の送信 → 支払済み → 照合済み、と進めます。

支払の送信がタイムアウトしたら、銀行側の指図の番号で問い合わせます。処理されていないと確かめるまで、送り直しません。消却した後に支払えなくなったケースは、勝手に発行し直しません。承認を付けて債務を持ち続けるか、取り消す手順へ回します。同じ台帳の上で資金と証券を同時に交換できる場合の設計は、アトミックDvPの設計記事で扱っています。

冒頭の2つめの問いは、ここで答えます。商品に償還の制限、停止、繰延償還、現物償還があるなら、それぞれを通常の失敗の種類と混ぜません。受け付けたが次回へ繰り越す数量、当てる予定のNAV、取り消せるかを、投資家の画面と社内の台帳で一致させます。

IOSCOの2025年の報告も、トークン化を、債券・MMFの発行、取引と取引後の処理、資産の管理というライフサイクルで評価しています。技術を変えただけで、今ある市場のリスクや役割が消えるわけではない、という整理です（IOSCO「Tokenization of Financial Assets」（FR/17/2025））。

障害のときは、やり直す前に今どこまで進んだかを確かめる

複数の仕組みにまたがる処理では、全体を取りまとめる機能が応答を受け取れなくても、銀行の指図やブロックチェーンの取引は成功していることがあります。つまりAPIのタイムアウトは、失敗を意味しません。

そこで、やり直す前に次のものを照合し、今どこまで進んだかを分類します。注文の台帳、決済の手段、NAVの版、チェーン上の実行結果、原簿、カストディのウォレットです。症状ごとに確かめることは次のとおりです。

どうなったら元に戻してよいかは、後半にまとめています。

日次の照合は、合計だけでなく、投資家、ウォレット、持分クラス、注文ごとに行います。差が出ても、自動で「チェーン上が正しい」とも「基幹システムが正しい」とも決めません。事前に決めた正本の対応表と、法的な記録の位置づけに従います。

管理のための操作には、申請の番号、申請者、承認者、署名者、変更の前後、根拠の文書のハッシュを残します。通常の処理と同じ鍵で、無制限に実行できないようにします。

本番の前に確かめる10の受入条件

1. 商品・持分クラスごとに、法的な権利、原簿、トークン残高、資金、NAVの正本が決まっている。
2. 締切の時刻、評価の時点、タイムゾーン、休日、遅れて届いた注文の境目をテストしている。
3. NAVの版、通貨・口数の小数の桁、丸め、訂正の手順を再現できる。
4. 多すぎ・少なすぎ・名義の食い違い・出どころの分からない入金から、自動で発行しない。
5. 発行、消却、支払、分配が、業務目的ごとに冪等である。
6. 移転の前後で適格性と権利者の記録が一致し、失効・凍結・ウォレットの復旧を扱える。
7. 権利が確定した日の残高のスナップショットから、分配の対象と端数を計算し直せる。
8. 償還中の持分を二重に移転・償還できず、支払の失敗から安全に再開できる。
9. ネットワークの停止、チェーンの再編、インデクサーの遅れ、鍵の紛失、NAVの訂正について、運用手順書と権限の分離がある。
10. 投資家ごとの残高、総供給量、原簿、資金、ファンドの会計を、日次でも例外のときでも照合できる。

技術の選定は、この受入条件を満たすための手段です。許可型か公開型のブロックチェーン、特定のトークン規格、銀行のAPI、ステーブルコインのどれを選んでも、次のことは自動では決まりません。締切の時刻やNAVの意味、権利者の原簿、資金の決済の確定性、訂正の権限です。

よくある質問

ブロックチェーン上の残高をそのまま受益者原簿にできますか？

構成によってはできます。英国FCAのPS26/7も、受益者原簿をDLT上で管理するための指針を示しています。ただしその場合も、別に用意するものがあります。誤記の訂正や裁判所の決定に対応する管理の権限と、ネットワークが止まったときに残高を復元できる事業継続の手順です。日本銀行の資料が説明する国内のSTでは、ブロックチェーン上の投資家情報と受益権の原簿を連動させる構成がとられています。

分配や償還金をステーブルコインやトークン化預金で支払えますか？

決済の手段の1つとして組み込めます。ただし、決済の手段が変わっても、手順は変わりません。権利が確定した日の残高のスナップショット、指図の番号の採番、届かない・戻ってきたときの処理のし直し、二重送金の防止です。受け取る側のウォレットがその決済の手段を受け取れるかも、事前の適格性の確認に含めます。

実装する人向けの詳細

ここからは、この運用会社で仕組みを組むアーキテクト向けの詳細です。

業務の相関IDと、申込から発行までの状態

最低限、order_id、investor_id、fund_id、share_class_id、cash_instruction_id、nav_version、token_tx_hashを1つの業務相関IDに紐付けます。全工程は分散トランザクションとして扱い、状態機械で管理します。

必ず成り立つ関係（不変条件）

• settled subscription units = confirmed cash / applicable NAV
• class total supply = investor balances + controlled suspense balances
• 同じ業務目的から成功する発行・消却は一度だけ

NAVの記録の項目と、注文・発行のキー

• NAVの記録：fund_id、share_class_id、評価日時、タイムゾーン、1口当たりNAV、通貨、小数桁、丸め方式、nav_version、状態（暫定・確定・訂正）、算定者・承認者、元ファイルまたは算定結果のハッシュ、公開時刻、訂正前版への参照
• 適格性の結果：policy_version、検証主体、期限、判定理由
• 発行処理の冪等性キー：order_id + nav_version + action=mint

償還の状態の進み方

償還注文を受けた口数はREDEMPTION_LOCKEDへ移し、sagaとして LOCKED → PRICED → BURN_CONFIRMED → PAYMENT_SUBMITTED → PAID → RECONCILED と進めます。PAYMENT_SUBMITTEDのタイムアウト時は銀行側の指図IDを照会し、未処理を確認するまで再送しません。

障害ごとの復旧条件

関連記事

同じ骨組みを、資産ごとの論点で掘り下げた記事があります。

• 貸付の延滞・回収：プライベートクレジットのトークン化設計
• 物件の運営費と二次流通：不動産トークン化プラットフォームの設計
• 株主名簿と譲渡の承認：未上場株のトークン化設計

XTELAができること

私たちは、注文・NAV・原簿・トークン・決済をまたぐデータモデルと状態遷移を設計し、スマートコントラクト、照合処理、鍵と権限の分離、障害からの再開手順までをPoC（概念実証）で動かして確かめます。締切時刻やNAV訂正、償還の繰延といった境界条件を試験項目に落とし、本番の運用手順書まで一緒に作ります。法的な判断は弁護士と連携して進めます。貴社の商品条件に合わせた技術構成の検討はお問い合わせからご相談ください。

主要参考資料

• 金融庁「FinTechサポートデスク Q7-2 有価証券のトークン化」（2026年8月13日確認）
• 金融庁「デジタル・分散型金融への対応のあり方等に関する研究会 第11回議事録」
• 日本銀行デジタル通貨フォーラム「セキュリティ・トークン（ST）とCBDCについて」
• FCA PS26/7: Progressing Fund Tokenisation（2026年4月30日公表、2026年9月24日確認）
• The Investment Association: UK Fund Tokenisation — A Blueprint for Implementation
• IOSCO「Tokenization of Financial Assets」（FR/17/2025）（2025年11月）
• DTCC Smart NAV Pilot Report
• Swift, UBS Asset Management and Chainlink: tokenized fund settlement pilot
• BIS Bulletin No.115: The rise of tokenised money market funds（2025年11月）

資料の確認日と注意

制度と資料は2026年8月13日に確認しました。FCA PS26/7の公表日は、2026年9月24日に確かめ直しています。ここに書いたのは、一般的な技術・業務の設計の解説です。個別の商品の法的な分類、登録が要るか、税務・会計の扱いは、実装する時点の一次資料と専門家の判断で決めてください。