□王寧江
要堅守“一數一源”底線,建立一套流程規范、高效流轉的信用異議協同處理系統
今年,有幸參加了信用建設高峰論壇“信用平臺與網站建設”分論壇的圓桌對話,其中一個話題便是信用異議的協同處理。
講信用異議,有必要把信用異議、信用投訴和信用修復這三組詞擺在一起,簡單做一下比較。近些年,這三組詞在言語間曝光的頻度明顯增加。共同點就是,所稱異議、投訴還是修復,都是一種申訴途徑,都是圍繞信息主體權益保護的一種制度設計。關于不同點,可以從兩方面看。從對象看,信用投訴的對象主要是他人;信用異議的對象可能是自身或他人;信用修復的對象主要是自身。從特征看,信用投訴主要是針對行為,因為他人失信行為對自身權益產生侵害,所以才有對他人行為的投訴;信用異議主要是針對信息,因為主觀認為信用數據的記錄有差錯,才有了異議的需求;信用修復主要是先有失信行為的改正,然后才提出要更新失信記錄。
基于以上理解,對于信用投訴,個人的建議是信用平臺和網站可以開設信用投訴窗口,但其基本定位應該是受理,而非處理。主要理由:一是目前各地政府針對群眾投訴的渠道已經比較多,而且各種渠道也比較通暢,如果從救濟制度設計的整體性考慮,還需要保留信用投訴,因此,可在網站或現場留個受理窗口,定位就是受理信用投訴;二是信用管理部門職責所限,往往沒有行政處罰權,很難實際去處理某起信用投訴,所以,受理投訴后,主要是轉有權機關處理;三是信用投訴的邊界很難界定,有時候信用投訴“就是個筐,什么都可以往里裝”。從實踐看,的確也有這個問題,有時候即使受理了投訴,發現確定轉哪個部門辦理都很難,反而耽擱了事,影響政務誠信形象。
對于信用修復,實在是爭議較大,本文暫不做討論。個人覺得在理論和實踐層面都還需要好好梳理,以便形成較為統一的認識。
回歸信用異議主題,正是因為各級信用工作機構在做的基本都是信用信息歸集、處理和應用的工作,打交道的是信息和數據,所以,無論怎么繞,各地也繞不開異議這塊工作。辦理信用異議,應堅持“誰發布、誰受理,誰產生、誰處理”的原則。
在以往,辦理信用異議并不是什么問題,因為信用數據的產生主體(即數源單位)和發布主體往往是同一個主體,前臺受理,后臺便能處理。但是,隨著信息化的推進、政務數據的共享和統一發布機制的建立,出現了幾個新問題:一是數源單位和發布單位大概率不是同一個主體;二是發布單位不僅會是多家,而且還可能是跨地域、跨領域、跨時空的多家。譬如,一條處罰記錄,數源單位可能是某基層工商所,而發布主體可能是信用中國網和全國各地的信用地方網、各地省級政務網等,這也為我們辦理信用異議增加了難度。
要堅守“一數一源”底線。無論是國家級平臺還是地方信用平臺,無論是采取集中式存儲信用數據還是分布式管理信用數據,均要建立起“一數一源”規則。只有這樣,才能確保數據在清洗比對、集中建庫時入庫數據的有效性。只有這樣,才能確保在生成信息主體信用檔案時從各個平臺抽取數據的唯一性。只有這樣,才能確保信息主體閱讀信用檔案時,知道哪條數據是由哪個數源單位產生。只有這樣,才能做到發布單位在受理信用異議之后,知道數源單位是哪一家,應轉給誰辦異議。
要建立一套流程規范、高效流轉的信用異議協同處理系統。任何一家發布主體收到異議申請之后,應當第一時間標注信息的異議狀態,同時,核對在發布環節有無出現信息偏差。確認無誤之后,發布主體將異議申請通過協同系統流轉到數源單位核實。雖然就是“流轉”這么一個簡單的用詞,背后實際上需要有大量標準化和數字化的工作作為支撐。所以,在這里再次強調統一社會信用代碼和“一數一源”的基礎性和關鍵性作用。
數源單位反饋的異議處理結論無非是信息無錯或信息有誤需要改錯兩種,發布單位據此做相應的更新即可。此時,如果信息主體依舊不認可異議處理結論的,從保護信息主體權益的角度,發布主體可把所異議的信息和異議處理結論同時標注在信用檔案中,供使用者甄別。