為鼓勵金融產業之創新,同時使其遵循應有之責任,並讓歐盟金融消費者與商業機構享有更多之利益,歐盟執委會於2020年10月24日提出數位金融包裹法案(Digital Finance Package),並提出以下2項數位金融立法提案:
一、加密資產立法提案(Proposal for Markets in Crypto-assets)
為促進金融創新並同時保有金融穩定性與保護投資人,歐盟執委會提出加密資產管制框架立法提案,並將加密資產分為已受監管與未受監管兩類,前者將持續依據既有規範進行管理。而針對尚未管制之加密資產,該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制,要求取得核准後始可提供服務。具體而言之,立法提案包含以下項目:
(一)針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。
(二)針對向公開市場提供加密資產進行管制,例如,依據提案第4條,供應商應為法人,第5條則要求供應商應製作加密資產白皮書,並將其提供給主管機關後始可於公開市場提供相關服務。
(三)針對代幣資產發行人以及其加密資產之審核程序,依據提案第15條,代幣發行者必須為歐盟境內之法律實體。另外,該法要求加密資產發行人應誠實、公平且專業,並完成加密資產白皮書之出版與制定市場溝通規則。
(四)針對加密資產之收購,該法第4章亦設有相關規範,於第37條及38條規定收購之評估機制。
(五)針對加密資產服務供應商之授權與營運條件,該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。
(六)針對市場秩序維護之部分,該法於第6章規範相關預防市場濫用之禁止事項與要求,並於第7章賦予歐盟成員國各主管機關相關權力,例如第94條之監督與懲處權限。
二、歐盟數位營運韌性管制框架立法提案(Proposal for Digital Operational Resilience)
數位化總伴隨資安風險,歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案,以確保相關企業可應對所有與通訊技術有關之干擾與威脅,另外,銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊,另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含:
(一)ICT風險管理要求:該立法提案參照相關國際標準,於第5至第14條制訂相關ICT風險管理要求,惟未要求應遵循具體國際標準。
(二)ICT相關事件報告:該提案於第15至20條規範相關報告義務,將整合歐盟金融機構之ICT相關事件報告與監測程序。
(三)數位運作韌性測試:該提案於第21至第24條要求ICT風險管理框架應定期進行測試,惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。
(四)第三方單位風險:該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測,例如,第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範,另外,ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。
本文為「經濟部產業技術司科技專案成果」
日本政府於6月29日召開關於賦予國民每一個人一個編號以便掌握每個人所得的「共通編號制度」的檢討會,會中決定將以利用於納稅與社會保障給付為軸心,朝引進制度推動的三種選擇方案。會中也討論到利用於減緩使低收入群負擔愈加沈重的消費稅的「逆進性」上。目前提出相關方案也有緩和參議院改選中有關增稅批評的目的。 從之後的1個月內會開始募集國民的意見後,到年底會將三種方案綜合為一案,以明年的一般國會會期中提出相關法案的方向推動。 有關共通編號制度,當然被指出會有個人資訊外洩與侵害隱私權的憂慮。菅直人首相在檢討會中提到「希望是立於國民本位制度上的來思考,也必須得到國民大眾的瞭解」。在檢討會中承認僅供稅務使用的A案、用於稅務與社會保障的B案及用於大範圍的行政領域上的C案,使用範圍各自不同的三種方案。 也出現希望所賦予的新編號能與目前正在使用中的「住民票號」能夠接軌的想法。利用編號制度正確掌握國民的所得情形,進而在增加消費稅之時,就有可能適切地對低收入群進行減稅與用現金補助。 消費稅是對包含生活必需品等大範圍的物品及服務課稅,所以愈是對將收入用於消費的比例龐大的低收入群會對增稅的負擔愈感沈重。 對減緩此一逆進性的有效制度,就是對有繳納的所得稅給予減稅,沒繳納所得稅的給予現金補助的「附給付的稅額扣減」。充分利用編號制度,將可補足反映所得所能退補的金額。
歐盟如何打擊「非現金支付」詐欺?有鑑於「非現金支付」(non-cash payment)──包含信用卡、電子錢包、行動支付和虛擬貨幣──之詐欺犯罪率有增加之趨勢,歐洲議會公民、司法與內政委員會 (Committee on Civil Liberties, Justice and Home Affairs)於2018年9月3日批准一修正草案,更新2001年通過之理事會框架決定(Council Framework Decision)2001/413/JHA,提高非現金支付詐欺之刑責,同時強化被害人保護。此一修正草案旨在消弭歐盟成員國間之法律落差,以強化對非現金支付詐欺之預防、偵查及懲罰。 此一草案最重要者為將虛擬貨幣交易納入犯罪之構成要件,並提高刑責。如法官認定犯罪情節該當國內非現金支付詐欺最重之罪,則最低應處以三至五年之有期徒刑。而其他新增及修正之內容包含: 改善歐盟區域內之合作,以利跨境詐欺之訴追。 強化對犯罪被害人之援助,如心理支持、財務及法律問題之諮詢,並對缺乏足夠資源者提供免費法律扶助。 透過宣導、教育與網路資源(如詐欺之實際案例)提供,提升民眾認知及預防之意識。 於委員會投票批准修正草案後,其後將待歐洲議會通過,並與歐盟理事會開啟非正式對談。
美國FDA更新軟體預驗證計畫,以明確化數位健康科技的軟體器材審查流程美國食品及藥物管理局(the U.S. Food and Drug Administration)於2019年1月更新「軟體預驗證計畫(Software Precertification Program)」及公布該計畫「2019測試方案(2019 Test Plan)」與「運作模式初版(A Working Model v1.0)」,使審查流程更加明確及具有彈性,並促進技術創新發展。 在更新計畫中,FDA聚焦於審查架構的說明,包含考量納入醫療器材新審查途徑(De Novo pathway)及優良評估流程(Excellence Appraisal process)的審查內涵。在優良評估流程中,相關研發人員須先行提供必要資訊,以供主管機關驗證該軟體器材之確效(validation)及是否已符合現行優良製造規範(current good manufacturing practices)與品質系統規範(Quality System Regulation, QSR)的要求。而由於以上標準已在此程序中先行驗證,主管機關得簡化上市前審查的相關查證程序,並加速查驗流程。 在測試方案中,則說明FDA將同時對同一軟體器材進行軟體預驗證審查及傳統審查,並比較兩種途徑的結果,以確保軟體預驗證審查途徑中的每一個程序都可以有效評估產品上市前所應符合的必要標準。最後,FDA綜合軟體預驗證計畫及測試方案,提出「運作模式初版」,以協助相關人員了解現行的規範架構與處理程序,並期待藉此促進技術開發者及主管機關間的溝通。FDA並於運作模式文件中提到,將在2019年3月8日前持續接受相關人員的建議,而未來將參酌建議調整計畫內容。
法國CNIL重罰微軟因搜尋引擎Bing違法運用cookie法國國家資訊自由委員會(Commission Nationale de l'Informatique et des Libertés, CNIL)基於cookie聲明(cookie banner)違反法國資料保護法(Act N°78-17 of 6 January 1978 on Information Technology, Data Files and Individual Liberties)裁罰微軟愛爾蘭分公司(Microsoft Ireland Operations LTD,下稱微軟)搜尋引擎Bing,並根據cookie蒐集資料間接產生的廣告收入、資料主題數量及處理的資料範圍定出6千萬歐元之罰鍰額度,且要求微軟應於3個月內限期改正,如逾期按日處以6萬歐元罰鍰。本案是繼2022年1月6日以來,CNIL以相同理由分別對Google與Facebook裁罰1.5億及6千萬歐元罰鍰後,再增1件科技巨頭因違法運用cookie遭受裁罰之案例。本案對我國隱私執法機關參酌於數位環境中,應就cookie聲明如何進行管理之理由與細節,具有參考價值。 而本案微軟之搜尋引擎Bing遭受裁罰之理由,主要可分為二面向: 一、未經使用者事前同意,逕於使用者設備中設置cookie 依法國資料保護法第82條規定,業者利用cookie或其他追蹤方式針對使用者終端設備上的資料進行讀取或寫入資料前,應盡告知義務並取得使用者同意。惟搜尋引擎Bing在使用者造訪網站時,未經使用者同意便設置一種具有安全及廣告等多種用途的cookie(MUID cookie)於其電腦設備,且當使用者繼續瀏覽網站時,將會另設置其他廣告cookie,然微軟亦未就此取得使用者同意。 二、拒絕設置cookie與給予同意之方式便利性應相同 在有效同意的標準與具體判斷上,由於搜尋引擎Bing的cookie聲明第一階層僅提供「接受」與「設定」兩類按鈕,並未提供「拒絕」按鈕,因此使用者同意或拒絕設置cookie之流程便利性有其差異,並未一致,如下說明: (一)使用者同意設置cookie 如使用者同意設置cookie,僅需於cookie聲明的第一階層點擊「接受」按鈕,即完成設置。 (二)使用者拒絕設置cookie 若使用者欲拒絕設置cookie,需於cookie聲明的第一階層點擊「設定」按鈕;其後進入第二階層,使用者可於各類型cookie選擇開啟或關閉,再點擊「保存設定」按鈕,始完成設置。 是以使用者拒絕同意設置cookie與給予同意之方式,兩者的便利性並未一致。又因第二階層顯示默認未設置cookie,恐導致使用者誤以為網站並未設置cookie,故CNIL認為此種同意欠缺自願性而屬無效者。