CONDITIONAL DESIGN NOT AN ANNOUNCED PRODUCT
XRP中立作業在庫は、
機関FXの内部で
どう動くのか。
- 表企業のUSD→JPYを決済銀行・送金銀行・条件が合えばCLSなどで、元の法定通貨債務を完了する。
- 裏業者側のUSDが目標超過・JPYが目標割れDealer、MM、Prime／PBなどの通貨別業務残高が、必要Bufferから外れ得る。
- 条件その偏りを戻す最安経路を選ぶ通常FXよりUSD→XRP→JPYが使えて安いときだけ、XRP在庫が動く。
この記事の答え本稿の中心仮説では、XRPを顧客Fiat債務の直接決済Railにしない。法的純債務の履行に伴うPool偏りだけを、別取引として最安なら再調整する在庫候補です。
この記事は、「もしXRP中立作業在庫が機関FXで本当に成立するなら、内部で誰が何を担当し、XRPはどこからどこへ動くのか」を、条件付きの完成設計から逆算します。
Pool＝業者が決済に使えるUSD・JPY等の残高を、通貨別の資金箱として見たもの。必ずしも一つの共同口座ではありません。中立＝発行体債務ではないXRPへ、複数の独立参加者が共通ルールで接続できる設計。価格・信用条件は各社で異なり、MM・保管者・銀行への依存は残ります。在庫＝実際に保有・管理するXRP残高。借入枠は、必要時に在庫へ変えられる調達能力です。
投資助言ではありません。 青・黒・緑の実線は既存業務または仕様上の移転、紫の点線は機関要件から導く未確認のXRP設計です。情報は2026年7月21日時点です。
01 / WHO IS WHERE
まず、登場人物を
同じ地図へ置く。
混乱の原因は、価格を出す人、信用を与える人、資産を保管する人、最後に台帳を動かす人を混ぜることです。一件の取引Ticketが誰の設備を通るかから見ます。
一社が複数の役を兼ねることはあります。それでも、役割を分けて考えると「誰がXRPを持つのか」が見えます。
XRPは通常意識しない
通常、資産は保管しない
XRP Pair提供は条件付き仮説
全取引に入るとは限らない
価格Risk主体とは限らない
Railごとに主体が変わる
役割の境界DealerとMMは重なり得るが同義ではない。Venueから出るのは主に約定情報。Native XRPはAccount holderまたは権限を持つCustodianがTransactionへ署名・提出し、XRPLが台帳状態を確定します。
02 / ONE TRADE
顧客レートは最初に決まる。
XRPは、まだ登場しない。
説明用に「企業がUSDを渡し、JPYを受け取りたい」一件を追います。最初に動くのは注文情報と信用です。この時点で顧客がXRPを買う必要はありません。
顧客のUSD／JPYレートはここで確定します。XRP経路を後から使っても、顧客レートを付け直す話ではありません。
企業が条件を送る
取引目的、金額、受渡日、口座。
Dealerが「この価格なら売買する」と提示
市場価格、手数料、在庫、Hedge費用を反映。
PBを使うなら、掛け取引できる枠を事前確認
与信枠を利用可能にし、約定前から監視する。
典型的なGive-up型なら、約定後にPBへ移管
Give-up＝顧客がPBの信用で行った約定を、PBが正式に引き受ける手続き。
二つの時計Quote・取消・与信はミリ秒級で更新される。XRPLは通常約3〜5秒ごとにLedgerが閉じ、TransactionがValidated Ledgerへ入ると結果が確定する。これは価格発見ではなく、選ばれた資産状態を確定する時計です。
03 / TWO BOOKS · THREE OUTPUTS
同じ約定を、二つの問いで見る。
XRP候補は、その後の在庫差だけ。
取引を二回行うのではありません。同じ約定データを、「相場が動くと損益はいくら動くか」と、「期日に誰へ何通貨をいくら渡すか」という二つの目的で見ます。前者は市場Exposure、後者は法的な支払Instructionを計算する。さらに全Cash flowを通貨別Poolへ合算して初めて、Treasuryの在庫差Δが現れます。
Riskの残り①、Settlementの残り②、Treasuryの残り③は、単位も目的も違います。上から流れる一つの残渣ではありません。
二回約定するのではない。同じ経済イベントを、価格変動と資産受渡しという二つの管理目的で参照します。
100−反対方向
82＝ 18概念例・普遍値ではない
反対Flowを内部化し、残ったPositionをRisk policyに照らします。
法的にNetできるInstructionだけを、通貨別の支払へまとめます。
CLS利用時の実Cash movementは、この例だけでなくSettlement Memberの他Instructionも合算した各通貨別Net pay-in／outです。
全部を通貨別Cash Poolへ合算
Δ補充必要量
在庫差ΔはSettlement Bookそのものの出力ではない。残り②を含む全Cash flowと目標Bufferを、Treasuryが別に比較して初めて生まれます。
図は理解の順序。実務では見込み残高からValue date前に先回りし、Fiat履行と並行、または事後にRebalanceできます。
この例のXRPは、残り①のHedgeでも残り②の元債務でもなく、残り③を戻す別建てRebalanceの候補です。
この階層の結論内部化は外で行う反対売買を減らす。支払相殺は銀行等で実際に払う額を減らす。法的純債務は既存Fiat Railへ。Fiat受渡しを含む全Cash flow合算後の目標差だけを、別建てで通常FXまたはXRP経路へRouteします。
04 / FIAT SETTLEMENT
PB-BにはUSD受取・JPY支払が帰属する。
実Cashは決済方式で変わる。
前図の「支払帳簿→残り②」だけを拡大します。本例ではPB-AをUSD支払／JPY受取側、PB-BをUSD受取／JPY支払側の決済当事者と仮置きします。実際のTreasury／在庫主体はPB、Dealer／MM、Hub等の構成次第です。PB-A→PB-BのUSD 8.0Mと逆向きのJPY 1.24Bはこの取引群のInstruction。非CLSの二者間決済ならCash movementも対応し得ますが、CLSでは他のInstructionもまとめ、Settlement Memberごとの各通貨別Net pay-in／outを各RTGS経由で履行します。
利益・損失ではなく、取引群の通貨別帰属です。Treasuryは実Cash movement、既存残高、全予定入出金を合わせ、目標から外れる分だけ補充します。
非CLSの二者間Cashならこの数字と対応し得ます。CLS利用時の実口座入出金は、他Instructionを合算したMember全体の各通貨別Net pay-in／outです。
補充の時点は一つではありません。 見込み不足を受渡日前に先回りする、法定通貨決済と並行する、決済後に戻す――いずれもあり得ます。
この合算でこの帰属、実Cash movement、他の予定入出金を合算し、目標を下回るJPYだけ補充候補になる。通常FX、資金移動、Token、XRP経路を比較します。
05 / WHEN XRP ENTERS
PB-BのJPYを戻す経路として、
使えて、最安なら選ぶ。
前図の「Treasury→残り③」だけを拡大します。PB-B側の資金管理担当（Treasury）がJPY補充の目標・USD上限・期限を出し、取引経路を比較するExecution／Route engineが通常FXとXRP経路の実行可能価格を比べる――これが条件付き設計です。誰がこの比較装置を運営するかは未公表で、PB、MMの取引部門、Agent Router等が候補です。Settlement Orchestratorは、取引成立後の受渡しを進めます。
一つでも満たさなければ、XRPの方が速そうに見えても選ばれません。
Δ JPY 補充必要量純支払全額ではなく、目標との差だけ
信用・資本・運用費
COST
借入・保管・法定通貨接続
成立条件主要通貨・流動時間帯では通常FXや資金移動が勝ちやすい。薄いPair、時間外、Prefunding負担などで、追加されるXRP費用よりPool補充コストの削減額が大きい場合だけ候補になります。
1,000万ドル相当なら、差の2 bpは2,000ドル。三つの適格条件を満たし、同じ時点・数量でXRP経路が本当に安い場合だけ選びます。数値は仕組みを示す架空例であり、実勢価格・実績・予測ではありません。
06 / WHO MAKES · WHO TAKES
XRPを選ぶのはSettleではない。
取引経路を約定させるExecutionで決まる。
PB-B側が「USDをいくらまで使い、JPYをいくら補充したいか」を出す。MM-AはUSD／XRP、MM-BはXRP／JPYの実行可能価格を出す。Direct型ならPB-B側が二本をTakeし、One-window型ならPB-BはPrime／HubのAll-in価格をTakeして、Hubが裏で二本を成立させる。いずれもXRP経路を選ぶのは取引成立時です。Settleは、その結果できた債務を履行する後工程です。
元の適格なUSD／JPY取引は、Settlement Memberと各通貨のRTGSを通じてCLSのPvP対象になり得ます。一方、このXRP補充例ではUSDとJPYは銀行、Native XRPだけがXRPLを通ります。CLSはXRPを決済しません。Take後は、移転前でも債権債務と経済Positionが生じます。
JPY業務残高を補充したい
USD上限・JPY目標・受渡期限をExecution deskへ渡す。
Q XRPを渡す価格・数量・期限・受渡口座
まだ移転しない
JPYを渡す価格・数量・期限・受渡口座
Firm＝提示条件の範囲で取引意思を伴う価格。ただしLast Look、信用・Validity確認、Venue規則が適用される場合があります。各Legの成立時点は契約とProtocolで決まり、Confirmationは通常、約定後に条件を照合する工程です。
二本は自動では同時成立しません。 Linked／All-or-noneの仕組みがあれば全体成立か不成立。独立にTakeすれば一方だけ成立するLegging Riskがあり、PB-B側またはHubが再Hedge・Close-out等を担います。
各口座管理者が成立済みInstructionを実行し、Settlement Orchestratorが確認を照合する。三Rail全体は自動Atomicではなく、実行順序・失敗時処理は契約次第です。
PB-B ↔ MM-BPB-Bが二本を直接Take。経済的にはMM-AからXRPを買い、MM-Bへ売る。両契約、SSI、Custody、AML／制裁対応が認める場合だけ、物理移転をMM-A側→MM-B側へ指定する。
Prime / Hub ↔ 各MakerPB-Bは一つのAll-in価格をTake。Hubが自己名義で裏のXRP取引を行うため、PB-B自身はXRP取引の当事者にならない場合がある。Matched principalを含み得る。
公表済みの近い役割分業： Ripple Primeのデジタル資産向けRoute 28では、Maker価格からAll-in価格を作り、Takerの約定時にPrimeがPrincipal取引とMakerへの反対取引を行います。これは仕組みの類例であり、機関FXのXRP中立在庫が稼働中という証拠ではありません。
Quoteを出す／受ける機関要件からの設計推論
二本を同数量・同期限で束ねる未公表
XRP本番Network・運営主体
一件の答えXRP経路は、XRPLへ送った瞬間ではなく、権限ある取引主体が経路を約定させたExecution時点で選ばれる。送金は、その取引で生まれた債務を履行する結果です。
07 / WHO HOLDS WHAT
共通在庫は巨大Walletではない。
分散残高を、同じ手順で予約する。
前図のCHECKを、ここで拡大します。 XRP在庫を共同利用する本番Networkは未公表です。成立させるなら、MM、保管者、貸し手等の残高は別口座のまま、Take前に価格・信用・必要XRP・JPY受渡し条件を同じ有効期限まで確認する構成が考えられます。
各通貨どうしの全組合せを厚くする代わりに、USD↔XRP、JPY↔XRPの在庫をHubとして使う狙いです。ただし二回の交換費用まで含めて安い場合に限ります。
- 1PB-BのUSD支払額
- 2MM-Aが出す必要XRP
- 3MM-Bが出すJPY
- 4PB・各社の信用枠
必要XRPは、その瞬間の二つの実行価格から計算します。Take前に条件を揃えても、独立した二本は自動では同時成立しません。Linked／All-or-none設計なら全体成立か全体不成立。別々にTakeするなら片脚だけ成立するRiskを引き受け、再Hedge・Close-out手順を備えます。
誰が何を持つかMMは価格Risk、PBは信用枠、Custodianは鍵・口座記録、貸し手は返済を求める権利を担い得る。すべてを同じ会社が持つ必要はありません。
08 / WHO CAN MAKE IT CHEAPEST
Rippleが安値を決めるのではない。
Primeが原価を下げ、MMが価格を作る。
在庫を予約できても、それだけでは通常FXに勝てません。PB-BのTreasuryが欲しいのはXRPではなく、「USDを渡したら、期限までにJPYがいくら確実に届くか」という一本の価格です。二つのXRP取引、信用枠、Hedge、銀行入出金をPrime／Hubが束ね、独立MMの競争価格をAll-in Quoteへ変換できたとき、XRPは初めて現実的な候補になります。
どの一社も、単独ではXRPを最安にできません。最安を持続させる最後の条件は、逆方向の実需を集め、同じ在庫を何度も再利用できることです。
- 得る
- 製品収益・利用量・Network価値
- 下げる
- 接続・標準化・導入の固定費
- 負う
- 開発・統合・初期施策の費用
- 得る
- 融資・清算・執行等の収益
- 下げる
- 信用・担保・Netting・二Leg管理
- 負う
- 信用・資本・Legging・運用Risk
- 得る
- XRP・Fiatの貸出利回り
- 下げる
- MMのFunding・自己資本負担
- 負う
- 信用・流動性・契約上の価格Risk
- 得る
- Spread × 在庫回転率
- 下げる
- 競争・内部化で二本のQuote幅
- 負う
- 在庫・逆選択・Hedge Risk
- 得る
- 保管・決済・入出金手数料
- 下げる
- Fiat接続・失敗・Cutoffの摩擦
- 負う
- 運用・Compliance・相手方Risk
- 得る
- 最終着金増・Buffer／資本削減
- 下げる
- Prefunding・時間・経路選択費
- 負う
- 約定失敗・切替・実装Risk
Rebateや初期補助は、鶏と卵を越える起動策にはなり得ます。しかし、補助を外した後も各社のRisk調整後損益が成立し、実約定後TCAで勝たなければ「最安経路が成立した証拠」にはなりません。
誰が実現を始められるか接続・信用・資本・初期Flowを束ねられるRipple／Prime側は起点を作りやすい。ただし、持続性を証明するのは独立MMの競争Quoteと、XRPに忠誠を持たないTreasuryが補助金なしで繰り返しTakeする事実です。
「USDを出す。JPYはいくら届く？」
金額・期限・最低受取額・確実性を指定最安の適格QuoteだけTAKE二Legを、一つの保証価格にする
顧客には一本、裏側では複数Maker。
- CREDIT取引相手枠
- MARGIN担保・融資
- ROUTER全経路比較
- NETTING逆方向Flow
在庫・Hedge費を価格へ
現地Fiat費用を価格へ
接続と原価条件MAKE独立MM
実行可能価格COMPARERouter
全経路の総費用TAKETreasury
最安時だけ約定SUSTAIN双方向Flow
在庫を再利用
MM-BのXRPは増える
NETTING全顧客Flowを束ねる
在庫偏りを戻す
最も現実的な完成形Ripple側が接続条件を設計し、Prime／Hubが信用・担保・在庫・二Legを一本化する。独立MMが競争して価格を作り、Treasuryは最安時だけTakeする。QuoteはOff-ledger、Native XRPの受渡しは選択後にXRPL、USDとJPYは銀行等です。
- ＋
- USD／XRPとXRP／JPY、二つのSpread
- ＋
- Market impact・Slippage
- ＋
- XRP在庫のFunding・Borrow
- ＋
- Hedge・Basis・価格変動Risk
- ＋
- Custody・Compliance・運用
- ＋
- Fiat入出金・Settlement・Counterparty Risk
- −
- Prefunding・遊休Buffer・時間・Nettingの削減効果
- −
- 導入時のRebate等。ただし補助金依存は持続的な安さの証明にならない
- 直接FX＋Bank／CLS
- Stablecoin経路
- USD等を介する既存三角取引
- Dealer／Correspondent経路
XRP経路が追加する二つの板と暗号資産運用費より、Prime内Netting、在庫回転、信用・担保の共通化、Nostro／Prefunding削減の価値が大きいときだけ勝ちます。同条件の実約定後TCA（Transaction Cost Analysis）で最終JPY着金額が最大だったかが、安さの証明です。
勝ち筋を検証しやすい回廊
- 直接Pairが薄く、既存経路もUSD等を介している
- Nostro・Prefunding・Correspondent費用が重い
- 小中規模の残渣で、二Legを吸収できる深さがある
- 逆方向FlowをPrime内で集めやすい
- 時間外でも両端のFiat入出金が実際に動く
勝ちにくい条件
- 流動時間帯のG10など、直接FXとCLSが極めて効率的
- 二つのXRP板の深さを超える大口注文
- 片方向Flowが続き、毎回外部補充が必要
- 現地銀行・Payout Railが閉じている、または高い
- XRPのFunding・Hedge・規制資本コストが高い
09 / XRP REBALANCE
PB-BがUSDを出す。
MM間でXRPが動き、JPYが戻る。
Section 06で示したDirect二MM型が成立し、三者受渡指図を置く仮想例を追います。PB-BはUSDをMM-Aへ、MM-A側口座はNative XRPをMM-B側口座へ、MM-BはJPYをPB-Bへ渡す。Native XRPだけがPublic XRPLを通り、USDとJPYは銀行またはTokenの経路を通ります。
PB-Bが自前のXRPL口座を運用せず、購入したXRPの受渡先をMM-B側へ指定する構成も可能です。ただしBridge中の経済的所有者、Custody、価格Risk、直接送付の可否は契約次第です。
この履行と、下のXRP補充は別の債務・別の取引です。XRP移転だけで元のUSD・JPY債務が自動消滅するわけではありません。
Take前に二つの価格・信用・受渡し条件を確認し、Take後は成立済みの二取引と三つの資産受渡しを、契約の期限・Default規則に従って実行・照合します。XRPだけ送ればJPY Poolが自動で増えるのではありません。
現実的な中心仮説元の法定通貨決済を置き換えず、その履行に伴う見込みまたは実現済みの業者側在庫偏りだけを、別建てでXRP Rebalanceする。
BOUNDARY
Shared DLTの位置複数社で共同正本が必要な状態だけを共有する候補。Privateであることは高速性やXRP利用を自動的に意味しません。
10 / WHAT EXISTS TODAY
部品は見える。
完成施設は、まだ見えない。
公式資料から確認できるのは、Ripple Primeの信用・清算・担保機能、デジタル資産でのMaker→All-in価格→Taker→反対取引という分業、段階的なPost-trade統合方針、RLUSD担保、XRPの機関OTC Spot取扱いなどです。XRPを機関FXの共通在庫として本番運用する完成Networkは未公表です。
まだ確認できないのは、二つのFX価格、信用枠、分散XRP在庫、法的契約を一つに束ね、複数の独立機関が反復利用する上部構造です。
現在地「作れそうな部品」と「機関FXでXRPが中立在庫として共同採用された証拠」は別。この記事の施設は、後者を検証するための設計図です。
11 / HOW VALUE REACHES PRICE
XRPが使われても、
利用量はそのまま市場取得量ではない。
一社All-in型なら、PB-BはXRPを買わず、裏側のDealer／HubがXRPを使う場合があります。二MM型でもBridgeの買いと売りだけならXRP純Positionは概ね戻り得ます。実需として市場へ届くのは、MM・PB等の在庫主体が外部保有者から取得した量が、外部へ処分した量を上回る在庫主体群の純取得です。
価格は実需だけでは決まりません。投機・投資商品・Treasury取得などの買いと、既存保有者・実際の市場供給・在庫解消などの売りが、板の厚さの上でぶつかって決まります。
実需の境界見るべきは決済量でも期末在庫だけでもない。在庫主体群の外部からの取得−処分と、取得方法・速度・板の厚さです。
Escrowの解除だけでは市場売却とは数えません。誰かの買い約定には必ず売り手がいますが、どちらが価格を追って約定を急ぐか、どの価格帯にどれだけ注文があるかで価格変化が決まります。
XRP中立作業在庫は、技術機能だけでは成立しない。既存FXの役割分担へ接続でき、法的に使え、Risk調整後の総コストで勝ち、複数の独立参加者が同じ規則を受け入れたとき、初めて市場になる。
利用仮説が弱くなる事実 XRP経路が高い、法的債務消滅を構成できない、独立MMが共同採用しない、Post-trade資産がRLUSD等だけ。
価格仮説が弱くなる事実 既存在庫・借入だけで足りる、在庫主体群が外部保有者から純取得しない、同時期の実売却が補充需要を上回る。
PRIMARY SOURCES
実線と点線を、
一次資料で分ける。
既存FXの役割分担、Maker／Taker／Principal構造、CLSとXRPLの決済境界、Ripple Primeの公表範囲を確認しています。分散XRP在庫Networkは、公式な本番採用開示がない限り設計仮説です。