KYB 測試是針對企業准入流程的驗證工作,它檢的是企業主體,而不是操作的那個人。與個人身分驗證相比,它多了一層麻煩:一個主體可能有多個層級的股東與關聯方,資料要一層一層往上追。以下說明這條流程該涵蓋哪些狀態、測試資料怎麼準備,以及哪些捷徑絕對不能走。
KYB 驗的是什麼?
企業准入的核心是確認往來的是一個真實存在、可辨識、可追責的主體以及它背後的人。常見要取得的資料包括註冊證明、稅務號或增值稅號、註冊地址證明、實際控制人資訊與經營資質。實際要求依管轄區與業務類型而不同,但不外乎這幾類。
與個人驗證相比,差異在結構。個人是一條紀錄;企業是一棵樹,樹上還有其他企業。這使得比對工作變重:註冊資料上的名稱要與稅務資料上的名稱一致,實際控制人的持股要能串起來,地址要與註冊地相符。任何一環對不上,都可能需要人工複核。
流程該涵蓋哪些狀態?
一個可用的流程至少要能表現五種狀態:尚未提交、審核中、通過、駁回、複核中。少了複核,人工介入的案子就沒有地方落腳;少了駁回後的可重試路徑,使用者只能重新建立一份申請,所有已上傳的資料都要重來一次。
| 狀態 | 觸發條件 | 使用者該看到什麼 |
|---|---|---|
| 尚未提交 | 資料未齊 | 還缺哪些項目 |
| 審核中 | 已送件待處理 | 預計處理方式,不含期限承諾 |
| 通過 | 全部檢查完成 | 可以進行的下一步 |
| 駁回 | 有項目不符 | 具體原因與可否補件 |
| 複核中 | 需要人工判斷 | 正在處理,不需要重複送件 |
駁回原因必須是可以重試的。測試時特別要確認一件事:補件之後,先前已經通過的檢查會不會被重新執行、會不會出現同一份資料被要求上傳兩次的狀況。
實際控制人為什麼是難點?
因為它需要的是穿透關係,而不是單一欄位。一個主體可能由另一家公司持有,那家公司又由其他人持有;流程必須能把這條鏈條記錄下來,並在股權結構變動時重新確認。這在測試上意味著樣本不能只有一層。
比較務實的做法是把實際控制人建模成一個可展開的清單,每一項包含身分、持有關係與證明文件,並允許標註「已確認」與「待補」。這樣流程就能在資料尚未齊全時先進入複核,而不是直接卡住。
本站產生的虛構主體能測什麼
在本站的公司資訊產生器裡,指定國家或地區後會產生公司名稱、行業、規模、法律形式、登記資本地址、聯絡電話,以及該國的登記號與增值稅號。這些欄位屬於同一條紀錄,可以直接拿來當企業准入的填表樣本。內容全部為合成的虛構資料,不對應任何真實企業,也不存在於任何登記體系。
用它來跑各種狀態特別合適:你可以準備「資料齊全」「缺稅務號」「名稱與註冊資料不符」幾種樣本,確認流程分別進入不同的狀態。若你需要先確認稅務欄位的檢查層次,可讀稅號校驗規則;哪些情境絕對不能用虛構資料,整理在虛構公司資料的邊界。
需要特別說明的是:這些內容只供測試、沙箱演練與示範使用,不得用於向任何機構申請真實開戶或資質,也不得用來冒用他人企業身分。測試環境中的風控規則也不應該為了讓測試通過而被關掉。
給開發者:狀態機、材料與環境隔離
狀態機要有明確的轉移表,每個轉移都要說明觸發條件與可回退的目標。狀態不應該由多處程式各自設定,否則很快就會出現互相矛盾的紀錄。每一次轉移都要留痕,包含時間、操作者與當時的資料版本。
材料欄位要記錄來源、上傳時間與到期時間。到期不是裝飾,它決定何時需要重新確認;沒有到期機制的流程,會在數年後仍以當年的資料做判斷。材料的存取權限也要收斂,能看到的角色應該比一般客服更少。
沙箱與正式環境必須完全隔離。測試用的主體、文件與查詢結果都不能出現在正式環境的資料流裡;反過來,正式環境的資料也不應該被複製到沙箱。環境隔離不只是資料庫分開,還包括外部查詢通道、儲存空間與日誌。
最後一條是不要為了測試而停用風控。風控規則一旦被關掉,很容易忘記開回來;正確的做法是提供可控制的測試模式,讓規則存在但對明確標示的測試主體走模擬結果,並且在日誌裡清楚標示這是模擬。
常見的駁回原因怎麼分類?
把駁回原因分組,比逐一列出訊息文字更有用,因為分組決定了流程要提供什麼樣的補救動作。實務上大致可以分成三組,每組的處理方式不同。
第一組是資料本身不齊,例如缺少註冊證明、缺少稅務資料或缺少地址證明。這一組的特點是使用者可以自行補件,流程應該直接指出缺哪一項,並允許在原申請上補齊,而不是要求重新送件。
第二組是資料之間不一致,例如名稱與註冊證明上的寫法不同、地址與註冊地不符、實際控制人的持股比例對不上。這一組需要使用者確認哪一份是正確的,因此流程要能標示出互相衝突的兩個欄位,而不是只說驗證失敗。
第三組是需要人工判斷的個案,例如股權結構複雜、註冊地資訊取得困難或文件語言需要翻譯。這一組應該進入複核,並保留目前為止已完成的所有檢查結果,讓接手的人不用從頭再跑一次。
| 分組 | 典型情況 | 使用者能做的事 |
|---|---|---|
| 資料不齊 | 缺註冊證明或稅務資料 | 在原申請上補件 |
| 資料不一致 | 名稱、地址或持股對不上 | 確認並修正衝突欄位 |
| 需人工判斷 | 結構複雜或文件需翻譯 | 等待複核結果 |
分組還有一個好處:它讓你能統計哪一類原因最常發生。若多數駁回集中在資料不一致,問題通常出在表單的提示不清楚,而不是使用者不配合;若集中在需人工判斷,則可能是自動檢查的門檻設得太嚴。這兩種情況的改善方向完全不同。
下一步
先把五種狀態列出來,逐項確認每一種都有對應的測試樣本與可觀察的介面反應,特別是駁回後補件的路徑。接著檢查沙箱與正式環境的查詢通道是否真的分開。
流程通過之後,資料該怎麼標記與回收,整理在虛構公司資料的邊界。本系列文章僅供軟體測試與示範使用,所有企業主體與文件均為虛構,不對應任何真實企業,也不得作為任何開戶、資質或准入審核的依據。