什麼是虛擬 IBAN？
虛擬 IBAN（vIBAN）是一組真實、可定址的國際銀行帳號，從專屬號段發行，並路由至單一主帳戶。它和一般 IBAN 一樣可以收款——付款人從自己的銀行發出一筆普通的 SEPA 轉帳即可——但它本身不持有任何餘額。它的任務是識別：每個虛擬 IBAN 都只對應一位付款人或一種用途，因此一筆款項入帳時，就已經說明了是誰付的、為了什麼而付。資金會自動匯集到主帳戶；虛擬 IBAN 是貼在款項上的標籤，而不是資金存放的第二個地方。
「每位付款人一個 IBAN」這一點，就是整個構想的核心。要理解它為何值得專文介紹，先從它消除的問題談起。
真正的問題：把款項對應到付款人
想像一家企業以銀行轉帳收款到單一帳戶：租金、訂閱費、帳單。所有入帳都落在同一個 IBAN 上，要判斷是誰付的，唯一的線索就是付款人在備註欄裡填了什麼。備註可能打錯、在傳遞過程中被截斷，或乾脆留白。一筆備註亂碼的 €49.00 轉帳，還不能算是 €49.00 的已確認營收——它只是一張待處理的工單。在結帳之前，必須有人查出這筆款項屬於哪位客戶、哪張帳單。
交易量小的時候，這只是個麻煩。到了平台等級的交易量，它就成了一個部門。比對引擎會依金額、日期和模糊的備註文字替候選帳單評分；無法歸屬的，就進入人工處理佇列。而且這種失敗是結構性的：當兩位訂閱者在同一天付了相同金額、又都沒填備註，任何引擎都無從區分——能區分兩者的資訊，打從一開始就不在這筆款項裡。
每位付款人一個 IBAN：身分由結構決定
虛擬 IBAN 方案翻轉了設計思路。與其要求每位付款人把款項標註正確，不如給每位付款人一個專屬的收款位址。每位租戶、訂閱者或市集賣家，都付款到只屬於自己的 IBAN。備註可以錯、可以空白、甚至用另一種文字書寫——入帳款項依然能自行表明身分，因為身分是由帳號本身承載的。
帳號是比備註可靠得多的載體。IBAN 內建檢查碼，因此輸入錯誤的 IBAN 在轉帳送出之前，就會在付款人的銀行端驗證失敗。輸入錯誤的備註卻能一路暢行，然後變成你的問題。把身分從自由輸入的欄位移到位址上，就等於把錯誤檢查從你的後台，移到了匯款銀行。
對付款人來說，一切照舊：和以往一樣，從網路銀行 App 付款到某個 IBAN。所有的不同都在收款端——款項到達時已經標好身分，備註欄也回到它本來該有的樣子：一則留言，而不是一套識別系統。
當每位付款人都付款到自己的 IBAN，一筆入帳款項就只可能代表一件事。對帳問題並不是被解決了——而是不再存在。
資金實際存放的位置
底層其實每種幣別只有一個主帳戶。虛擬 IBAN 從方案專屬的號段發行，匯入其中任何一個的款項，都會結算進主帳戶。無需管理每位付款人的餘額，也不需要日終歸集作業把資金從成千上萬個小帳戶搬到同一處——資金匯集靠的是路由，而不是額外的轉帳，那些轉帳反倒還得另外對帳。
這也讓虛擬 IBAN 成為真正的帳號，而不是障眼法。任何銀行都能對它定址，它和一般 SEPA 轉帳一樣完成清算，並且在付款人自己的對帳單上，顯示為他們所付款的帳戶。它缺少的，正是完整帳戶會附帶的負擔：自己的餘額，以及指派與停用之外的生命週期。
虛擬 IBAN 不是什麼
它不是子帳戶：子帳戶持有餘額，需要入金與出金，還會讓你要維護的帳本成倍增加。它不是虛擬參考號碼：那種做法仍然依賴備註欄，仍然得靠付款人正確複製字串。它也不是錢包：vIBAN 本身不儲存任何資產。它是一個背後帶有路由的位址——是讓入帳款項能自我識別的最精簡構造。
退回款會附帶原因
款項不只會進來。帳戶會關閉、銀行會拒收入帳、付款人會撤回轉帳。在單一收款帳戶的情況下，一筆退回款就是一場小型調查：哪筆款項被退回、是誰的、當初比對到的帳本分錄需不需要沖回？
在 vIBAN 方案中，退回款就是資料。它帶有原因代碼，以 payment.returned 事件的形式，落在原始入帳所用的同一個虛擬 IBAN 上，並在對帳單中單獨計數。在任何人開立工單之前，你就知道是誰的款項被退回、為什麼被退回。退回款成為待處理的資料列，而不是需要追查的謎團。
需要的是例外佇列，而不是對帳團隊
沒有任何設計能做到百分之百對帳。款項可能匯入已停用的 vIBAN，重複付款會發生，總有人會以某種方式直接付款到主帳戶。目標不是讓例外不可能發生——而是讓它們稀少且可計數。在 Protocore vIBAN 示範中，99.6% 的入帳款項自動完成對帳；其餘的進入待審佇列，並附上付款人的完整歷史，因此處理例外時是從脈絡出發，而不是從一份銀行對帳單和一張試算表開始。
這個差異會重塑團隊。對帳作業的規模隨交易量成長：入帳越多，未比對的入帳越多，人力就越多。例外處理的規模則隨例外數量成長，而這個數量已被設計壓向趨近於零。留下來的人處理的是真正的異常，而不是重新輸入備註。在我們的技術堆疊中，這個佇列位於 Protocore Center（/products/center），也就是營運主控台，每一項特權操作都必須填寫原因，並記錄到稽核日誌中。
批次發行、用途標籤與平台
每位付款人一個 IBAN，前提是發行一個 IBAN 幾乎沒有成本。擁有十幾位租戶的房東可以手動建立 vIBAN；要讓數千名賣家加入的市集就不行了。因此發行是批次作業。在 vIBAN 示範中，一份包含 2,400 位付款人的 CSV 會經過驗證，在每一列預覽將發行的 IBAN，再一次操作全部發行——2,400 位付款人，一次作業，中間還有一道審核步驟。
用途標籤在位址層級就把資金流區隔開來：租金在這裡，訂閱費在那裡，市集撥款則自成一條通道。依用途出報表只需要一個篩選條件，不必再當成專案處理；每個 vIBAN 都有自己的對帳單——CSV 或 PDF——而底層的主帳戶仍然是唯一的事實來源。付款人離開時，他們的 vIBAN 會被停用：歷史紀錄保留，但該位址不再接受新的入帳。
它在支付架構中的位置
虛擬 IBAN 是收款基礎設施。它讓銀行轉帳入帳具備了信用卡支付向來擁有的特性——身分附著在款項本身，而不是另外手動輸入。在 Protocore 生態系中，Gateway 的轉帳支付訂單帶有 vIBAN 參考，而 Center 則處理比對後遺留的各種例外。/products/viban 的產品頁面使用與本文相同的示範資料，完整走過整個流程——發行、分享、比對、例外、報表。
也要坦白說明適用範圍：如果你每月只收幾筆轉帳，一套備註慣例加上十分鐘的記帳就夠了。虛擬 IBAN 的價值，體現在交易量已讓對帳變成一套流程的場景——租金收取、訂閱收款、市集平台——凡是「是誰付了款」這個問題每月要被問上數千次的地方。