設計可擴展的 KYC 審核佇列
KYC 審核佇列是後台的工作流程，將機器無法自行放行的身分檢核交到真人面前。多數申請應該自動通過；佇列是為那些無法通過的案件而存在。它的整個設計目標就是保持精簡——只容納真正模糊不明的案件，別無其他——因為一個塞滿本該由機器決定之案件的佇列，不是控管機制，而是隨註冊量線性成長的瓶頸。把佇列做對，後台就能隨例外案件而非交易量擴展。
「刻意保持精簡」這一個特性，決定了後續的每一項設計。先從能讓它保持精簡的分流說起。
目標是全自動處理，佇列只處理例外
全自動處理（STP，straight-through processing）指申請從頭到尾不經人工：證件讀取、身分比對、制裁與 PEP 篩查無異常、活體檢測通過，決策並留下紀錄。這應該是常態路徑，而走這條路徑的申請占比——STP 率——正是決定佇列能否擴展的關鍵數字。如果有九成多自動通過，人工佇列只會是可控的細流；如果有一半落入審核，你就得隨業務成長不斷增聘審核人員。佇列不是 KYC 發生的地方，而是自動化 KYC 承認自己沒把握的地方。把 STP 率拉高，其他所有指標都會跟著改善：進佇列的案件更少、等待時間更短、需要聘用的審核人員也更少。這值得正面攻克——在用戶端改善證件拍攝、在拍照前給出更清楚的指引、調整比對門檻，避免真正的客戶被過度謹慎的規則擋下——因為在這裡每多挽回一個百分點，就少一個會占掉某人一個下午的案件。
哪些案件會進佇列，以及原因
案件落入審核，都有具體、可命名的原因，而原因正是案件最重要的屬性。證件照片太模糊無法辨識；證件上的姓名與申請姓名不符；制裁或 PEP 篩查出現可能命中，需要真人確認或排除；地址無法對任何來源查證；活體檢測失敗，或同一張臉或同一份證件已存在於另一個帳戶。每一種都是不同性質的工作，需要不同的判斷——而把它們混成一堆不加區分，正是審核佇列犯的第一個錯誤。同樣的原因，分量也可能天差地別：姓名不符可能只是再平常不過的冠夫姓差異，也可能是身分遭盜用的第一個跡象；佇列的任務，是把案件送到分辨得出差別的人手上，而不是對值得仔細審視的案件逼出倉促的結論。
一個佇列不夠：依原因分流
單一佇列迫使每位審核人員都成為通才，也讓每個案件都得排在不相干的案件後面。依原因分流可以同時解決這兩個問題。制裁可能命中的佇列，由受過篩查與處置訓練的人員處理；證件品質佇列只是快速的目視檢查，資淺審核人員幾秒內就能完成；重複帳戶佇列則是一場詐欺調查。每個分流都有自己的派送規則、所需技能與服務水準目標，因為模糊的照片應在幾分鐘內處理完，而真正的制裁命中則值得謹慎、不急不躁地處置。分流讓處理量與嚴謹度得以並存，而不是此消彼長。
審核佇列無法靠增聘審核人員來擴充。真正的擴充之道，是正確判斷哪些案件根本不需要人工審核，並讓需要的案件在送達時，就已依原因分類完畢。
須附理由、可稽核的操作
審核人員做出的每一項決定——核准、拒絕、升級處理、要求補充文件——都必須填寫理由，且必須留下紀錄。理由不是事後隨手補上的自由文字，而是在操作當下記錄的結構化選項，說明為何採取該項操作。這不是官僚作風，而是讓審核佇列經得起檢驗的關鍵。當監管機關、稽核人員或後續的審核人員問起，為何帳戶在有警示的情況下仍獲核准，答案會是具名的審核人員、時間戳記與明載的理由，而不是一聳肩。稽核軌跡採僅可附加（append-only）的方式，決定無法事後被悄悄改寫；更正會以新紀錄呈現，而不是覆蓋舊紀錄。在我們的架構中，這個佇列及其稽核模型位於 Protocore Center（/products/center），也就是營運人員的管理主控台，每一項特權操作都必須附上理由，並寫入無法被悄悄竄改的日誌。
四眼原則的案件
有些決定的影響太大，不該由一個人拍板。例如排除真正命中的制裁名單、核准高風險客戶資料，或推翻自動化拒絕的結果，都應由第二位審核人員確認——也就是 maker-checker，或稱四眼原則。第一位審核人員提出建議並說明理由；第二位具備相應權限的審核人員則確認或駁回，並說明自己的理由。兩項操作都會記錄在案。這並非不信任審核人員，而是因為風險最高的核准，正是一旦出錯代價最大的決定，而多一雙眼睛是最便宜的保險。佇列設計應依原因自動將這類案件導向兩步驟處理，而不是仰賴審核人員自己記得。不過，兩步驟流程應刻意只留給影響重大的案件；若套用在所有案件上，整個佇列的成本會倍增，還會讓審核人員養成對第二道簽核蓋橡皮圖章的習慣，悄悄抵銷了設置這道簽核的意義。
為處理量而設計：滯留時間、優先順序與 SLA
只增不減的佇列，就是失敗的佇列。要在設計中內建讓它持續流動的壓力。案件的滯留時間清楚可見，不會有案件被遺忘；每個客群都有各自的服務水準目標，因此一件照片模糊、須在數分鐘內處理的案件一旦違反 SLA，與一件期限較長的制裁案件，會以不同方式浮現。優先順序是真正的取捨：先進先出公平又簡單，但風險優先——潛在風險敞口最大者排最前面——往往才是正確選擇，並以滯留時間作為同級時的判準，讓低風險案件仍能被處理而不致被餓死。審核人員的畫面應直接呈現下一件已完成分派與排序的案件，而不是一份任人挑選的清單——因為由人挑著處理的佇列，棘手的案件永遠不會被挑中。沒有可見滯留時間的佇列會悄悄腐壞：困難案件沉到底部，簡單案件在上方不斷週轉，而唯一能揭露問題的指標——最舊未結案件的滯留時間——偏偏是在客戶抱怨之前沒有人盯著的數字。
衡量佇列
四個數字能告訴你設計是否有效。STP 率顯示有多少案件完全不需要人工；佇列深度及其趨勢顯示你是跟得上還是越積越多；依客群對照 SLA 追蹤的決策時間，顯示客戶等待開戶的時間是否過長；而重開率——事後被推翻的決定占比——則顯示審核人員是判斷正確，還是只是判斷很快。這幾項要一起看，因為它們彼此牽制：決策時間下降、重開率卻攀升，代表你是用錯誤換來速度。健康的佇列規模小、持續流動、決定正確，並如實呈現其中仍未結的案件。
人們想像中的後台——一屋子員工逐筆鍵入申請——是自動化處理得太少、佇列又是一大堆未分類案件時的結果。能夠擴展的後台恰恰相反：多數申請根本不會送到人工手上，送達的案件已依原因與優先順序分類，每項操作都帶著理由寫入僅可附加的日誌，需要四眼原則的決定也有把關。為例外情況打造佇列，它就會在你成長時維持小規模。若把它當成 KYC 發生的地方，它就會隨著每一位新增註冊用戶而膨脹。