仮想IBANとは？
仮想IBAN（vIBAN）は、専用のレンジから発行され、1つのマスター口座に紐づけられる、実在する送金先の国際銀行口座番号です。ほかのIBANと同じように入金を受け付け、支払者は自分の銀行から通常のSEPAクレジット送金を行えます。ただし、vIBAN自体は残高を持ちません。役割は識別です。仮想IBANはそれぞれ1人の支払者または1つの目的にだけ割り当てられるため、入金された時点で、誰からの何の支払いかがわかります。資金は自動的にマスター口座へ集約されます。仮想IBANは支払いに付くラベルであり、資金が置かれる2つ目の場所ではありません。
この「支払者ごとに1つのIBAN」という性質こそが、発想の核心です。記事にする価値がある理由を知るには、まずそれが取り除く問題から見ていきましょう。
本当の課題：入金と支払者の突き合わせ
家賃、サブスクリプション、請求書など、銀行振込で1つの口座に入金を集めている事業者を想像してください。入金はすべて同じIBANに着金し、誰が支払ったかを示す手がかりは、支払者が参照欄に入力した内容だけです。参照欄は入力ミスがあったり、途中で切り詰められたり、空欄だったりします。参照が文字化けした49.00ユーロの振込は、まだ49.00ユーロの確定売上ではなく、1件のチケットです。決算前に、どの顧客のどの請求書に対する入金かを誰かが突き止めなければなりません。
取引量が少なければ、これは煩わしい程度で済みます。プラットフォーム規模になれば、1つの部署が必要になります。消込エンジンは、金額、日付、あいまいな参照テキストをもとに請求書の候補をスコアリングし、判定できなかったものは人の作業キューに回ります。しかも、この失敗は構造的なものです。同じ日に同じ金額を、参照なしで2人の契約者が支払った場合、どんなエンジンでも区別できません。両者を見分ける情報が、最初から支払いに含まれていないからです。
支払者ごとに1つのIBAN：設計で担保する識別
仮想IBANのプログラムは、この設計を逆転させます。すべての支払者に支払いへ正しくラベルを付けてもらうのではなく、支払者ごとに専用の宛先を渡します。入居者、サブスクライバー、マーケットプレイスの出店者は、それぞれ自分だけのIBANに支払います。参照欄が間違っていても、空でも、別の文字体系で書かれていても、入金は自ら身元を示します。識別情報を運ぶのが口座番号だからです。
口座番号は、参照欄よりはるかに優れた識別の担い手です。IBANにはチェックディジットが含まれているため、入力ミスのあるIBANは、振込が実行される前に支払者側の銀行で検証エラーになります。一方、参照の入力ミスはそのまま通過し、こちらの問題になります。識別情報を自由記入欄から宛先そのものへ移すことで、エラーチェックを自社のバックオフィスから送金元の銀行へ移せます。
支払者にとっては何も変わりません。これまでどおり、銀行アプリからIBANに支払うだけです。新しいのは受け取る側だけで、支払いはあらかじめラベル付きで届き、参照欄は本来あるべき姿、つまり識別システムではなくメモに戻ります。
すべての支払者が自分専用のIBANに支払えば、入金が意味するものは1つだけになります。消込の問題は解決されるのではなく、存在しなくなります。
資金が実際にある場所
内部には、通貨ごとにマスター口座がちょうど1つあります。仮想IBANはプログラム専用のレンジから発行され、どの仮想IBANへの入金も、すべてマスター口座に着金します。支払者ごとの残高を管理する必要はなく、何千もの小口座から1つの口座へ資金を移す日次の集約処理も不要です。集約は追加の振込ではなくルーティングで行われるため、その振込自体を消し込む手間も生じません。
だからこそ、仮想IBANは小手先の仕掛けではなく、本物の仕組みと言えます。どの銀行からも宛先として指定でき、通常のSEPAクレジットと同様に決済され、支払者自身の明細にも、支払った口座として表示されます。持たないのは、通常の口座に付いてくるもの、つまり自身の残高と、割り当てから廃止までを超えるライフサイクルです。
仮想IBANではないもの
サブ口座ではありません。サブ口座は残高を持ち、入出金の資金移動が必要で、運用する元帳も増えます。仮想参照番号でもありません。参照番号は結局、参照欄を使うもので、支払者が文字列を正しくコピーしてくれることに依存します。ウォレットでもありません。vIBAN自体には何も保管されません。仮想IBANは、ルーティングを背後に持つ宛先です。入金に自己識別性を持たせる、最小限の構成要素です。
返金は理由付きで戻ってくる
支払いは届くだけではありません。口座が解約され、銀行が入金を拒否し、支払者が振込を取り消すこともあります。回収用口座が1つだけの環境では、返金は小さな調査になります。どの支払いが戻ってきたのか、誰の支払いか、突き合わせた元帳の仕訳を取り消す必要があるのか、といった具合です。
vIBANのプログラムでは、返金はデータです。理由コードが付き、元の入金と同じ仮想IBANに対するpayment.returnedイベントとして届き、明細にも独立した1件として計上されます。誰の支払いが、なぜ戻ってきたのかが、チケットが開かれる前にわかります。返金は、追いかける謎ではなく、処理する行になります。
必要なのは消込チームではなく、例外キュー
100パーセント消し込める設計はありません。廃止済みのvIBANに入金が届くこともあれば、二重入金も起こります。誰かが何かの拍子にマスター口座へ直接支払うこともあります。目標は例外をなくすことではなく、例外を少なく、数えられる状態にすることです。ProtocoreのvIBANデモでは、入金の99.6%が自動で消し込まれます。残りは、支払者の履歴一式を添えて確認キューに入るため、例外対応は、銀行明細とスプレッドシートではなく、文脈から始められます。
この違いは、チームのあり方も変えます。突き合わせ業務は支払件数に比例して増えます。入金が増えれば未消込も増え、人手も必要になります。例外処理は例外の件数に比例しますが、その件数は設計によってすでにゼロに近づけられています。残る担当者が扱うのは、入力し直された参照ではなく、本当の異常です。私たちのスタックでは、このキューはProtocore Center（/products/center）にあります。すべての特権操作に理由が必須で、監査ログに記録されるオペレーションコンソールです。
一括発行、目的タグ、プラットフォーム
支払者ごとに1つのIBANという方式は、発行にコストがかからないことが前提です。入居者が十数人の大家なら、vIBANを手作業で発行できるでしょう。しかし、何千もの出店者を受け入れるマーケットプレイスには無理です。そのため、発行は一括処理で行います。vIBANデモでは、2,400人分の支払者のCSVを検証し、各行にIBANをプレビュー表示した上で、1回の操作で発行します。2,400人の支払者を、確認ステップを挟んだ1つの操作で処理します。
目的タグを使えば、宛先のレベルでフローを分けられます。家賃はこちら、サブスクリプションはあちら、マーケットプレイスの支払いは専用のレーンといった具合です。目的別のレポートはプロジェクトではなくフィルターで済み、各vIBANにはCSVまたはPDFの専用明細が付きます。その背後では、マスター口座が唯一の正本であり続けます。支払者が退会すると、そのvIBANは廃止されます。履歴は残り、宛先は新たな入金を受け付けなくなります。
決済スタックのどこに位置するか
仮想IBANは、入金回収のためのインフラです。カード決済が昔から備えてきたもの、つまり、支払いと一緒に入力するのではなく、支払いそのものに付随する識別情報を、銀行振込の入金にも与えます。Protocoreのエコシステムでは、Gatewayの振込払い注文にvIBANの参照が付与され、消込で残った例外はCenterで処理します。/products/vibanの製品ページでは、この記事と同じデモデータを使って、発行、共有、消込、例外処理、レポートという一連の流れを最初から最後まで確認できます。
正直な線引きもしておきます。月に数件の振込しか受けないなら、参照ルールと10分の記帳作業で十分です。仮想IBANが真価を発揮するのは、取引量が増え、消込が一つの業務プロセスになっている場面です。賃貸の家賃管理、サブスクリプションの回収、マーケットプレイスなど、「誰が支払ったのか」という問いが月に何千回も発生する現場です。