RippleNetには、送金のどの工程を担う製品があったのでしょうか。まずは、銀行間の情報交換と決済を支える仕組みから見ていきましょう。
見えない送金を見えるようにする
銀行が送金人から国際送金の依頼を受けたとき、いきなりお金を送るわけではありません。最初に、相手の銀行がその支払いを受け入れられるかどうかを確かめる必要があります。「受取人の口座は本当に存在するか」「必要な情報はすべて揃っているか」「通貨の種類や手数料の条件に違いはないか」などを確認するのです。
もしこの確認作業を飛ばして資金だけを動かしてしまうと、後になって受取先の銀行に拒否され、原因の問い合わせや返金の手間がかかってしまいます。そこで、こうした情報を銀行間でやり取りして送金状況を追跡し、ILPを用いて参加銀行の台帳間の決済を連動させるソフトウェアとして「xCurrent」が説明されました。
送金する側の銀行にとっては、取引がどの段階で止まっているのかが分かるという大きなメリットがあります。一方、受け取る側の銀行にとっても、資金が届く前に必要な情報を確認できるため、事務処理の準備をスムーズに進められます。送金人に事前に提示した条件と、実際の処理状況のズレがなくなることで、確認作業に費やす時間も減らすことができます。
xCurrentは、既存のコルレス関係などを活用しながら、銀行間の双方向の連絡と台帳間のリアルタイム決済を支える仕組みです。XRPを売買して流動性を調達することは、xCurrentの利用に必須ではありません。もちろん、こうした仕組みが整ったからといって、各国の法律による規制や銀行の定休日がなくなるわけではありません。支払いを無事に完了させるための、参加する金融機関の責任はしっかりと残ります。
銀行の業務は台帳の速度だけでは変わらない
2017年のRipple社の製品紹介では、こうした従来の銀行向けソフトウェアが「xCurrent」という名前で発表されました。ただし、Ripple社と銀行との協力関係は、この名前が発表される前から始まっていました。
たとえば、2014年のFidor Bankやアメリカの銀行とのシステム接続には、その後の製品群へとつながる取り組みが見て取れます。当時の資料に後の製品名が載っていないのは、ごく自然なことです。のちにxCurrentと呼ばれることになる銀行向けの機能は、こうした初期の現場での経験をもとに整理されていったものなのです。
流動性との役割分担
さらに重要なポイントがあります。それは、「xCurrentを導入した金融機関が、自動的にXRPを使っていたわけではない」ということです。
xCurrentによる情報交換と決済の連動と、送金先の現地通貨をどこから調達するかは、区別して考える必要があります。送金元の銀行が海外の口座にあらかじめ置いた資金を使う場合もあれば、第三者の流動性供給者が現地通貨を用意する場合もあります。流動性供給者が送金先銀行に預金を置く場合、その預金については流動性供給者が送金先銀行の信用リスクを負います。一方で、XRPを橋渡し役として使い、必要なタイミングで資金（流動性）を調達するという仕組みは、「xRapid」という別の製品として展開されていました。
つまり、xCurrentに参加している金融機関の数と、xRapidの採用事例を同じものとして混同しないことが、Rippleの製品を正しく理解するための第一歩となります。