中國電信融合支付產(chǎn)品技術規(guī)范總冊

1、<p>　　中國電信融合支付產(chǎn)品</p><p>　　——技術規(guī)范總冊V1.0</p><p><b>　　（討論稿）</b></p><p><b>　　中國電信集團</b></p><p><b>　　2009-12</b></p><p>

2、;<b>　　版 本 歷 史</b></p><p><b>　　目錄</b></p><p><b>　　1.總則7</b></p><p><b>　　1.1背景7</b></p><p>　　1.2文檔說明7</p><

3、;p>　　1.3名詞解釋7</p><p><b>　　2.業(yè)務描述9</b></p><p>　　2.1業(yè)務目標9</p><p>　　2.2賬戶設計10</p><p>　　2.2.1賬戶需求分析10</p><p>　　2.2.2賬戶層級架構12</p&g

4、t;<p>　　2.2.3電信消費類賬戶13</p><p>　　2.2.4電信通信類賬戶14</p><p>　　2.2.5其他關聯(lián)類賬戶14</p><p>　　2.2.6其他說明15</p><p>　　2.3賬戶體系演進階段建議15</p><p>　　2.3.1第一階段1

5、5</p><p>　　2.3.2第二階段16</p><p>　　2.4支付場景16</p><p>　　2.4.1互聯(lián)網(wǎng)支付場景17</p><p>　　2.4.2電話POS支付場景17</p><p>　　2.4.3電話語音支付場景（IVR）17</p><p>　　2

6、.4.4移動支付場景17</p><p>　　3.總體架構設計19</p><p>　　3.1總體架構圖19</p><p>　　3.2周邊平臺19</p><p>　　3.2.1UDB平臺19</p><p>　　3.2.2積分平臺20</p><p>　　3.2.3

7、NSAG平臺20</p><p>　　3.2.4OTA平臺20</p><p>　　3.2.5銀行（第三方支付）平臺20</p><p>　　3.2.6業(yè)務平臺20</p><p>　　3.2.7卡管理平臺21</p><p>　　3.3組網(wǎng)要求21</p><p>　　3

8、.3.1組網(wǎng)原則21</p><p>　　3.3.2組網(wǎng)結(jié)構22</p><p>　　3.4全國平臺功能架構24</p><p>　　3.5省級平臺功能架構24</p><p>　　4.對賬、清分與結(jié)算25</p><p>　　4.1日切前的處理25</p><p>　　

9、4.2賬戶管理模塊的處理25</p><p>　　4.3支付處理模塊的處理25</p><p>　　4.4其他業(yè)務平臺26</p><p>　　5.沖正機制的要求26</p><p>　　5.1沖正適用范圍26</p><p>　　5.2沖正處理要求27</p><p>

10、　　5.3需要自動沖正的交易27</p><p>　　6.網(wǎng)管要求27</p><p>　　6.1網(wǎng)絡管理方式27</p><p>　　6.2網(wǎng)絡管理的主要功能28</p><p>　　6.2.1性能管理28</p><p>　　6.2.2故障管理28</p><p>　

11、　6.2.3安全管理29</p><p>　　6.2.4配置管理29</p><p>　　7.系統(tǒng)性能要求29</p><p>　　7.1賬戶數(shù)30</p><p>　　7.2日均交易量30</p><p>　　7.3端到端交易處理時延Tａ（遠程支付）30</p><p>

12、;　　7.4系統(tǒng)交易處理時延Ｔｂ（遠程支付）31</p><p>　　7.5系統(tǒng)吞吐量31</p><p>　　7.6系統(tǒng)內(nèi)交易成功率31</p><p>　　7.7系統(tǒng)并發(fā)處理能力31</p><p>　　7.8批處理時長32</p><p>　　7.9客服系統(tǒng)性能要求32</p>

13、<p>　　7.10其他32</p><p>　　8.系統(tǒng)數(shù)據(jù)管理要求32</p><p>　　8.1業(yè)務數(shù)據(jù)管理33</p><p>　　8.1.1數(shù)據(jù)內(nèi)容33</p><p>　　8.1.2保管介質(zhì)要求33</p><p>　　8.1.3保管期限要求建議33</p>

14、<p>　　8.2安全數(shù)據(jù)管理33</p><p>　　8.2.1數(shù)據(jù)內(nèi)容33</p><p>　　8.2.2保管介質(zhì)要求33</p><p>　　8.2.3管理期限要求建議33</p><p>　　8.3交易清算數(shù)據(jù)管理34</p><p>　　8.3.1數(shù)據(jù)內(nèi)容34</p

15、><p>　　8.3.2保管介質(zhì)要求34</p><p>　　8.3.3保管期限要求建議34</p><p>　　8.4賬務數(shù)據(jù)管理34</p><p>　　8.4.1數(shù)據(jù)內(nèi)容34</p><p>　　8.4.2保管介質(zhì)要求34</p><p>　　8.4.3保管期限要求建議

16、34</p><p>　　8.5日志數(shù)據(jù)管理35</p><p>　　8.5.1數(shù)據(jù)內(nèi)容35</p><p>　　8.5.2保管介質(zhì)要求35</p><p>　　8.5.3保管期限要求建議35</p><p>　　9.系統(tǒng)安全要求35</p><p>　　9.1安全體系模型

17、35</p><p>　　9.1.1安全威脅35</p><p>　　9.1.2安全模型36</p><p>　　9.2應用層安全要求37</p><p>　　9.2.1密碼體系37</p><p>　　9.2.2訪問控制37</p><p>　　9.2.3數(shù)據(jù)存儲安全

18、37</p><p>　　9.2.4通信安全38</p><p>　　9.2.5可用性38</p><p>　　9.2.6安全審計38</p><p>　　9.2.7防攻擊/防病毒38</p><p>　　9.3系統(tǒng)層安全要求39</p><p>　　9.3.1訪問控制3

19、9</p><p>　　9.3.2可用性39</p><p>　　9.3.3安全審計39</p><p>　　9.3.4防攻擊/防病毒39</p><p>　　9.4網(wǎng)絡層安全要求40</p><p>　　9.4.1訪問控制40</p><p>　　9.4.2可用性40&

20、lt;/p><p>　　9.4.3安全審計40</p><p>　　9.4.4防攻擊/防病毒40</p><p>　　9.5物理層安全要求41</p><p>　　9.5.1環(huán)境安全41</p><p>　　9.5.2媒體安全41</p><p>　　9.5.3設備安全41&

21、lt;/p><p>　　10.系統(tǒng)備份與恢復41</p><p>　　10.1備份范圍41</p><p>　　10.2備份目標與性能要求41</p><p>　　10.3存儲介質(zhì)與備份方式42</p><p>　　10.4備份策略43</p><p>　　10.5其他要求與建

22、議43</p><p><b>　　總則</b></p><p><b>　　背景</b></p><p>　　近來我國電子商務發(fā)展訊速,電子支付經(jīng)過幾年的發(fā)展，從金融機構的銀行卡支付、網(wǎng)銀支付、第三方支付，再到電子錢包,已經(jīng)成為電子商務交易中關鍵的支撐環(huán)節(jié)。隨著3G時代的到來，移動支付越來越成為電子商務的重要支付渠道。

23、</p><p>　　部分電信省公司在支付工作上有所試點，并有規(guī)模型推廣。但整體突顯以下問題：</p><p>　　除目前4個統(tǒng)一支付試點省已實現(xiàn)支付平臺的統(tǒng)一，其余非試點省的支付平臺仍分散，支付業(yè)務分散在多個業(yè)務平臺上；</p><p>　　不同單位建設、經(jīng)營，不同的建設、經(jīng)營模式，導致用戶感知度不一致、缺乏黏性；</p><p>　　資源

24、分散，缺乏統(tǒng)一業(yè)務發(fā)展模式，各地業(yè)務發(fā)展水平、營銷及支撐能力參差不一，尚未形成全網(wǎng)的規(guī)模效益</p><p>　　缺乏業(yè)務發(fā)展指導規(guī)劃，各省期待集團在業(yè)務發(fā)展方面提供指導意見</p><p>　　缺乏統(tǒng)一支付品牌，專業(yè)運營能力欠缺。</p><p><b>　　文檔說明</b></p><p>　　本規(guī)范規(guī)定了中國電信融

25、合支付平臺在業(yè)務開展中需要規(guī)范的內(nèi)容，供中國移動內(nèi)部和廠商共同適用；適用于在融合支付平臺在業(yè)務開展、招標選型，工程建設和運行維護為集團公司和省公司提供技術依據(jù)。</p><p><b>　　名詞解釋</b></p><p><b>　　業(yè)務描述</b></p><p><b>　　業(yè)務目標</b>&l

26、t;/p><p>　?。壑袊娦湃诤现Ц镀脚_］旨在實現(xiàn)接入網(wǎng)的通信功能與支付功能的分離，把支付能力從目前的各種業(yè)務系統(tǒng)中獨立出來，形成相對獨立的能力引擎和管理核心，建立與中國電信運營服務體系相適應的集中維護、統(tǒng)一管理的基于自有賬戶的多帳戶多媒介的立體化電信融合支付運營服務體系。</p><p>　　通過推進組織結(jié)構、流程制度和信息系統(tǒng)的優(yōu)化完善，形成與電信融合支付運營服務體系相互支撐，相互作用

27、的可持續(xù)優(yōu)化的運作機制，促進電信融合支付運營服務水平的不斷提升。</p><p>　?。壑袊娦湃诤现Ц镀脚_］服務于電信自有業(yè)務對支付功能需求的基礎上，將擴展服務于電子商務支付、手機移動支付等業(yè)務需求，具備多種支付手段和渠道能力。遠程支付能夠支持實現(xiàn)互聯(lián)網(wǎng)（WEB）、WAP、短信、語音支付等應用；現(xiàn)場支付能夠?qū)崿F(xiàn)大額有密聯(lián)機交易、小額無密脫機交易功能。</p><p>　　［中國電信融合支

28、付平臺］業(yè)務的總體架構如下圖所示： 圖中去掉通信賬戶</p><p><b>　　賬戶設計</b></p><p><b>　　賬戶需求分析</b></p><p>　　中國電信支付產(chǎn)品定位于以消費類賬戶為主的多賬戶多媒介 (WEB、WAP、IVR、SMS、RFID等)的支付應用。</p><p>

29、　　中國電信的用戶消費賬戶與電信通信賬戶相分離，使消費賬戶成為獨立于電信通信計費賬戶體系，并確立以消費賬戶進行支付的核心賬戶。電話支付所采用的通信話費小額支付功能隨著消費賬戶的建立，支付功能逐步由用戶消費賬戶代替。電信用戶還可以使用電信積分在合作商戶進行消費。</p><p>　　中國電信用戶還可以通過其它關聯(lián)賬戶（如銀行賬戶、第三方行業(yè)賬戶等）進行各種支付和消費。這樣，用戶就可以通過固話、移動和互聯(lián)網(wǎng)等多種接入

30、手段，保證支付賬號及相關聯(lián)的賬戶在任意交易場景均可融合使用，方便用戶隨時隨地快捷方便地使用電信支付業(yè)務。</p><p>　　隨著電信消費賬戶的建立，電信融合支付平臺的逐步壯大，更多的第三方應用商依附于電信的支付平臺進行支付，逐步建立電信在支付產(chǎn)品價值鏈中的核心地位。</p><p>　　互聯(lián)網(wǎng)接入、語音接入、短信接入及手機支付等不同接入媒介對于賬戶的需求如下表如示：</p>

31、<p>　　注1：表中所述小額定義為單筆支付金額小于100元</p><p>　　注2：表中所述大額定義為單筆支付金額大于500元</p><p><b>　　賬戶層級架構</b></p><p>　　中國電信融合支付平臺賬戶架構根據(jù)歸屬和管理的平臺層級分為全國和省兩級。</p><p><b>　

32、　電信消費類賬戶</b></p><p><b>　　用戶支付賬戶</b></p><p>　　在線支付賬戶是用戶支付賬戶的核心子賬戶，由電信融合支付全國平臺建設和管理，用戶可以使用在線支付賬戶進行各類遠程支付或現(xiàn)場支付。</p><p>　　各省可以根據(jù)省內(nèi)需求，確定是否設立省內(nèi)離線支付賬戶。省內(nèi)離線支付賬戶由省級平臺進行建設和管

33、理，主要用于省內(nèi)各類現(xiàn)場離線支付?？紤]未來跨省的支付，省級平臺進行離線支付賬戶建設時，應遵循集團公司統(tǒng)一的卡技術和AID應用規(guī)范，采用全國平臺統(tǒng)一的密鑰管理體系。</p><p>　　全國平臺應制定統(tǒng)一的卡技術和應用規(guī)范，建設統(tǒng)一的密鑰管理平臺，并在未來離線支付賬戶開通跨省支付應用時，負責離線支付賬戶相關的商戶交易的清分結(jié)算以及跨省支付應用的清分和路由管理。</p><p><b&g

34、t;　　積分賬戶</b></p><p>　　電信客戶積分賬戶包含電信各省CRM生成積分、集團號百業(yè)務平臺生成的積分和積分平臺匯總積分。</p><p>　　1）電信融合支付平臺建設第一階段中，積分賬戶暫時定位為電信消費類賬戶的關聯(lián)賬戶，仍按目前已存在的積分管理模式由集團號百和各省級積分平臺進行管理。</p><p>　　目前積分賬戶的管理分為模式一（積

35、分賬戶在各省管理）和模式二（積分賬戶在集團號百積分平臺管理）。</p><p>　　如該號百客戶已與品牌客戶歸并，則該客戶的號百積分需要下發(fā)到省內(nèi)（模式一），匯入各省積分平臺賬戶統(tǒng)一管理。</p><p>　　根據(jù)各省實際情況，電信CRM生成積分也可匯聚到集團號百積分平臺進行統(tǒng)一管理。</p><p>　　2）電信融合支付平臺建設第二階段中，當積分賬戶可實時匯聚到全

36、國積分平臺后，將積分賬戶納入到電信消費類賬戶體系，作為消費類賬戶下的子賬戶。</p><p><b>　　代金券/優(yōu)惠券賬戶</b></p><p>　　代金券賬戶由電信融合支付全國平臺建設和管理，由融合支付全國運營機構發(fā)行，配合在線支付賬戶和離線支付賬戶進行用于各類遠程和現(xiàn)場代金抵扣支付應用。代金券可以由積分平臺統(tǒng)一管理。</p><p>　

37、　優(yōu)惠券賬戶由電信融合支付升級平臺建設和管理，由各融合支付省級運營機構發(fā)行，用于優(yōu)惠券發(fā)行商戶指定的特約商戶進行現(xiàn)場支付時的優(yōu)惠折扣應用。</p><p><b>　　電信通信類賬戶</b></p><p>　　電信通信賬戶仍然按照目前的運行的管理層級進行管理，由各省CRM系統(tǒng)進行建設和管理。融合支付平臺建設和運營后，此類賬戶仍然保持原有模式和層級不變。 </p

38、><p><b>　　其他關聯(lián)類賬戶</b></p><p>　　全國性金融類關聯(lián)賬戶</p><p>　　包括：工行、建行、中行、農(nóng)行、交行、招行、民生銀行、中信銀行、廣發(fā)、深發(fā)展、上海浦發(fā)等銀行以及支付寶、財付通等全國性或跨省區(qū)域性金融類賬戶，原則上該類賬戶接入、管理維護和清分結(jié)算由全國平臺承擔。</p><p>　　地

39、方性金融類關聯(lián)賬戶</p><p>　　包括：寧波銀行、杭州銀行等地方性商業(yè)銀行。因該類賬戶業(yè)務范圍一般僅限于某個城市或某個省內(nèi)，故該類金融賬戶將直接接入省級平臺，并由省級平臺進行管理維護和結(jié)算。</p><p>　　但如果所屬省未建設融合支付省級平臺或因全國業(yè)務和技術管理需要，也可直接接入融合支付全國平臺，接入管理方式和范圍同全國性金融類賬戶。</p><p>&

40、lt;b>　　第三方行業(yè)賬戶</b></p><p>　　包括：校企內(nèi)部賬戶、市政/公交/市民等一機通賬戶、第三方行業(yè)消費卡</p><p>　　此類關聯(lián)賬戶根據(jù)省及地市電信的需要，將直接由省電信進行根據(jù)規(guī)范進行系統(tǒng)建設和管理。</p><p><b>　　其他說明</b></p><p>　　融合支付

41、全國平臺和省級平臺對賬戶建立和管理的關系：1）對于沒有建設省平臺的省份，全國中心平臺承擔虛擬省賬戶管理功能，建立和實現(xiàn)省平臺所需的所有賬戶管理功能；2）對于建設省平臺的省份，以上歸屬省平臺管理的賬戶，將由省平臺建設和管理，全國平臺不再管理該省所屬的相關省級平臺賬戶。</p><p>　　賬戶體系演進階段建議</p><p>　　根據(jù)賬戶設計預期目標和當前實際情況，賬戶和平臺的建設可以分兩個

42、階段建設和實施。</p><p><b>　　第一階段</b></p><p>　　第一階段主要是建設以用戶支付賬戶為主的賬戶平臺，主要實現(xiàn)基于現(xiàn)金方式的消費支付應用，消費類賬戶僅由在線支付賬戶和離線支付賬戶組成。離線支付賬戶由各省平臺根據(jù)需要建立和管理，但需要考慮未來跨省使用的可能性，采用統(tǒng)一的密鑰和應用ID（AID）。</p><p>　　

43、考慮到目前積分賬戶主要由各省積分平臺管理和維護；積分賬戶在當前第一階段暫時定位為電信消費類賬戶的關聯(lián)賬戶，由全國積分平臺和省積分平臺管理；目前過渡階段用戶在消費時需明確選擇使用積分賬戶還是使用用戶支付賬戶扣款。</p><p>　　過渡階段賬戶架構圖如下：</p><p><b>　　第二階段</b></p><p>　　第二階段將逐步向目標賬

44、戶結(jié)構進行演進。本階段當積分賬戶可實時匯聚到全國積分平臺后，將積分賬戶納入到電信消費類賬戶體系，作為消費類賬戶下的子賬戶。</p><p>　　全國平臺適時建立代金券賬戶，省平臺根據(jù)業(yè)務開展需求建立優(yōu)惠券賬戶，用于抵扣現(xiàn)金或者優(yōu)惠折扣應用。</p><p><b>　　支付場景</b></p><p>　　中國電信支付業(yè)務支持客戶通過多種終端接

45、入使用、允許客戶使用不同的賬號進行支付，對應產(chǎn)生的支付場景如下。</p><p><b>　　互聯(lián)網(wǎng)支付場景</b></p><p>　　用戶通過互聯(lián)網(wǎng)接入支付平臺時，可以對電信業(yè)務進行充值/繳費，也可以使用融合支付平臺支付網(wǎng)上商城選購的商品。主要的支付場景有以下四種：</p><p>　　銀行卡網(wǎng)上支付：利用融合支付平臺的統(tǒng)一銀行接口，根據(jù)銀

46、行卡輸入信息的位置，分為網(wǎng)銀模式和支付平臺模式；</p><p>　　在線支付賬戶（電信自有）網(wǎng)上支付：用戶利用申請的電信在線支付賬戶進行網(wǎng)上支付；</p><p>　　積分賬戶網(wǎng)上兌換：利用電信的積分賬戶在互聯(lián)網(wǎng)上進行商品的兌換，只能用于特定場景和特定商品；</p><p><b>　　電話POS支付場景</b></p><

47、;p>　　用戶通過電話POS接入融合支付平臺時，可使用的支付方式如下：</p><p>　　銀行卡刷卡支付：支付賬單下發(fā)到電話支付終端或用戶選擇支付訂單后，通過刷銀行卡完成支付；</p><p>　　在線支付賬戶支付：支付賬單下發(fā)到電話支付終端或用戶選擇支付訂單后，通過輸入電信在線賬戶信息完成支付。</p><p>　　電話語音支付場景（IVR）</p&

48、gt;<p>　　用戶通過固話、手機IVR方式接入融合支付平臺時，只能應用于以下場景：</p><p>　　銀行卡（信用卡）支付：通過IVR，利用銀行卡（信用卡）開展實名商品（訂房、訂餐、訂機票）的商旅應用或其他應用；</p><p>　　在線支付賬戶支付：利用電信在線支付賬戶，支付自有業(yè)務充值繳費、商品訂購等支付應用。</p><p><b&g

49、t;　　移動支付場景</b></p><p><b>　　短信支付場景</b></p><p>　　用戶通過短信方式接入融合支付平臺時，可采用的支付方式如下：</p><p>　　銀行卡（第三方支付卡）支付：通過短信方式，利用銀行卡（第三方支付卡）（可以設定綁定關系）開展電信充值繳費、公共事業(yè)費繳費、小額商品購買等應用；</p

50、><p>　　在線支付賬戶支付：利用在線支付賬戶進行電信產(chǎn)品充值繳費、公共事業(yè)費繳費、商品購買等應用。</p><p><b>　　WAP支付場景</b></p><p>　　用戶通過WAP接入融合支付平臺時，可以對電信業(yè)務進行充值/繳費商品購買等業(yè)務。具體可采用的支付方式有：</p><p>　　銀行卡（第三方支付卡）支付

51、：通過融合支付平臺的統(tǒng)一銀行接口支持WAP方式的支付業(yè)務；</p><p>　　在線支付賬戶支付：利用在線支付賬戶支持WAP上的支付業(yè)務；</p><p>　　積分賬戶兌換：利用積分賬戶兌換WAP上的商品。</p><p><b>　　RFID支付場景</b></p><p>　　用戶通過RFID接入支付平臺時，采用的是

52、RFID的刷卡支付方式，可以采用的支付方式有：</p><p>　　離線支付賬戶：利用電信離線支付賬戶支持離線支付應用。</p><p><b>　　總體架構設計</b></p><p><b>　　總體架構圖</b></p><p><b>　　周邊平臺</b></p&

53、gt;<p><b>　　UDB平臺</b></p><p>　　用戶通過WEB、WAP、營業(yè)廳開通支付功能及建立支付賬戶，必須先開通或激活通行證賬戶。激活操作由UDB平臺完成</p><p><b>　　積分平臺</b></p><p>　　此處提到的積分平臺是存放管理積分賬戶的平臺，不包含積分商城等應用部

54、分。在支付體系中的作用主要是作為一種支付資金源——積分賬戶。</p><p>　　當用戶采用積分賬戶支付時，平臺將用戶輸入的積分賬戶信息發(fā)送給積分平臺，由積分平臺對積分賬戶進行認證和扣款，然后將處理結(jié)果返回給支付平臺。</p><p>　　另外，積分平臺中的積分賬戶可以在一些特殊情況中與支付平臺發(fā)生關聯(lián)。比如自有賬戶消費產(chǎn)生積分（需要集團另行規(guī)定），則支付平臺將產(chǎn)生的積分和積分賬戶信息發(fā)送

55、給積分平臺，由平臺完成充值操作。</p><p><b>　　NSAG平臺</b></p><p>　　NSAG平臺是支撐支付平臺的一種能力引擎，負責短信/彩信方式的信息發(fā)送。在支付體系中的作用主要有：支付行為發(fā)起、支付結(jié)果通知、商品信息發(fā)送、二維碼應用、認證信息發(fā)送等。</p><p><b>　　OTA平臺</b>&l

56、t;/p><p>　　OTA平臺是卡資源操作能力平臺。主要功能有：空中圈存、應用下載、應用存儲、安全域的操作（創(chuàng)建、刪除等）、安全域相關信息存儲、應用個人化操作、卡片應用狀態(tài)管理、卡密鑰（安全域密鑰、應用密鑰）更新操作等。</p><p>　　銀行（第三方支付）平臺</p><p>　　銀行及第三方支付平臺是中國電信通道型支付應用的重要資金來源。在支付流程中，實現(xiàn)銀行/

57、第三方支付賬戶的認證和扣款。若支持銀行/第三方支付賬戶與自有賬戶的綁定，支付系統(tǒng)也需要將相關信息發(fā)送給銀行/第三方支付平臺。根據(jù)不同的支付方式，需要提供多種支付接口。</p><p><b>　　業(yè)務平臺</b></p><p>　　業(yè)務平臺根據(jù)業(yè)務性質(zhì)可以分為自有業(yè)務平臺和其他商戶系統(tǒng)，根據(jù)適用范圍可以分為全國級業(yè)務平臺和省級業(yè)務平臺。一機通平臺屬于省級業(yè)務平臺范疇

58、。業(yè)務平臺主要提供支付商品或支付業(yè)務，在支付流程中，承擔支付發(fā)起、商品確認等功能。</p><p><b>　　卡管理平臺</b></p><p>　　卡管平臺負責制卡數(shù)據(jù)的生成。主要功能包括：制卡基礎數(shù)據(jù)管理、安全域管理、碼號資源管理、預置密鑰管理、訂單管理、卡片數(shù)據(jù)生成和卡管系統(tǒng)管理。</p><p><b>　　組網(wǎng)要求<

59、/b></p><p><b>　　組網(wǎng)原則</b></p><p>　　中國電信融合平臺采用兩級組網(wǎng)：全國融合支付平臺（簡稱全國平臺）和省級融合支付平臺（簡稱省平臺）。</p><p><b>　　全國融合支付平臺</b></p><p>　　全國融合平臺主要由以下部分組成：</p&g

60、t;<p>　　賬戶子系統(tǒng)（包括在線支付賬戶管理模塊）</p><p>　　支付服務子系統(tǒng)（包括：前置模塊、支付處理模塊、支付管理模塊、清分清算模塊、門戶）</p><p>　　集團中心平臺的主要功能包括：</p><p>　　負責在線支付賬戶的集中管理、統(tǒng)一支付處理和支付管理；</p><p>　　提供集中清算和結(jié)算的功能；&

61、lt;/p><p>　　負責接入所有的全國級自有業(yè)務平臺或者商戶平臺；</p><p>　　負責銀行總行、銀聯(lián)總部、銀行網(wǎng)銀或第三方支付平臺的接入；</p><p>　　負責與電信積分平臺的接入；</p><p>　　負責與OTA平臺、NSAG、UDB平臺、卡管平臺的接入</p><p>　　查看和監(jiān)控所有中國電信自行布放

62、的POS終端的運行狀態(tài)信息、交易信息以及相關的統(tǒng)計報表；</p><p>　　對于沒有建設省平臺的省份，集團中心平臺承擔虛擬省功能，實現(xiàn)省平臺的所有功能。</p><p><b>　　省級融合支付平臺</b></p><p>　　省平臺主要由以下部分組成：</p><p>　　賬戶子系統(tǒng)（離線支付賬戶管理模塊）</

63、p><p>　　支付服務子系統(tǒng)（包括省級平臺的：前置模塊、支付處理模塊、支付管理模塊、清分清算模塊、門戶）</p><p>　　省平臺的主要功能包括：</p><p>　　負責本地業(yè)務平臺、本地商戶系統(tǒng)的接入；</p><p>　　負責本省離線支付賬戶的管理及相關的支付處理</p><p>　　負責本省POS的接入和管理；

64、 </p><p>　　負責本省商戶的管理，對離線商戶的清結(jié)算；</p><p><b>　　提供交易轉(zhuǎn)發(fā)功能。</b></p><p><b>　　組網(wǎng)結(jié)構</b></p><p>　　全國平臺通過CTNET與NSAG連接，實現(xiàn)短信/彩信業(yè)務的一點接入；</p><p>　

65、　全國平臺通過CTNET與WAP GW連接，實現(xiàn)WAP方式的接入；</p><p>　　全國平臺通過專線與UDB連接，實現(xiàn)統(tǒng)一認證功能；</p><p>　　全國平臺通過專線與OTA平臺連接；</p><p>　　全國平臺通過專線與網(wǎng)管系統(tǒng)連接；</p><p>　　全國平臺與銀聯(lián)/銀行之間通過專線進行連接；</p><p

66、>　　全國平臺通過專線與積分平臺連接；</p><p>　　省平臺通過專線（采用主備線路方式）與集團中心平臺連接；</p><p>　　省平臺通過專線與充值SCP一點連接，然后將充值數(shù)據(jù)透傳到全國融合支付平臺，實現(xiàn)充值卡向在線支付賬戶的充值；</p><p>　　全國或省級平臺與商戶/業(yè)務平臺可通過Internet或?qū)＞€進行連接。</p><

67、;p>　　POS機通過CDMA 1X/EVDO或PSTN網(wǎng)絡接入省級融合支付平臺。</p><p>　　建議融合支付平臺的所有網(wǎng)絡設備和主機設備都采用雙機熱備的方式來配置，與外圍網(wǎng)元的連接雙路連接，保障無單點故障，提高系統(tǒng)的可靠性。同時通過負載均衡等機制，保障網(wǎng)絡的可用性，提高系統(tǒng)性能。</p><p>　　全國平臺負責所有與在線支付賬戶相關的交易處理和賬戶管理，必須保障全國平臺的可

68、靠性。全國平臺建議采用主備方式建設，并提供完善的數(shù)據(jù)（尤其是賬戶及帳務數(shù)據(jù)）備份和恢復機制。</p><p>　　省級平臺負責本省離線支付賬戶相關的交易處理和賬戶管理。也建議采用主備方式建設，并提供完善的數(shù)據(jù)（尤其是賬戶及帳務數(shù)據(jù)）備份和恢復機制。</p><p>　　在融合支付平臺組網(wǎng)中，通過采用內(nèi)外網(wǎng)隔離機制（如防火墻），防止通過通信手段對內(nèi)部網(wǎng)絡中的重要數(shù)據(jù)和業(yè)務滲透和操縱。另外通過

69、局域網(wǎng)VLAN的劃分來實現(xiàn)不同子平臺、不同級別用戶之間的訪問控制。</p><p>　　在網(wǎng)絡中部署網(wǎng)絡防病毒系統(tǒng)、入侵檢測系統(tǒng)、安全掃描、加密機等安全相關系統(tǒng)，為平臺提供全方位的立體安全保障。</p><p><b>　　全國平臺功能架構</b></p><p><b>　　省級平臺功能架構</b></p>

70、<p><b>　　對賬、清分與結(jié)算</b></p><p><b>　　日切前的處理</b></p><p>　　對于POS、WEB、WAP、電話IVR上送的交易數(shù)據(jù)，在日切之前需進行以下交易數(shù)據(jù)的處理：</p><p>　　支付處理模塊按照日切的時間點，從渠道、業(yè)務、資金源等標識對交易數(shù)據(jù)分類統(tǒng)計（分類標準

71、以實際的業(yè)務需求為準）；</p><p>　　在賬戶日切前上送的交易，納入當日的清分處理；未在日切前上送的交易，納入日切后的工作日進行清分處理。</p><p><b>　　賬戶管理模塊的處理</b></p><p>　　發(fā)起日切請求：賬戶管理模塊日切，并通知支付處理模塊；</p><p>　　生成對賬文件：賬戶管理模塊

72、照約定的格式生成當日的對賬文件，并發(fā)送到指定目錄；</p><p><b>　　支付處理模塊的處理</b></p><p>　　進行日切：支付處理模塊接受到賬戶管理模塊的日切通知后，進行日切；</p><p>　　產(chǎn)生交易明細文件：按照約定的格式生成交易明細文件，并發(fā)送到指定的目錄；</p><p>　　與賬戶管理模塊對

73、賬：支付處理模塊用自己產(chǎn)生的交易明細文件和賬戶管理模塊生成的對賬文件進行對賬，以賬戶管理模塊生成的對賬文件為基準對賬，并生成對賬差錯文件；之后進行差錯處理。在對賬的過程中，系統(tǒng)可以繼續(xù)進行清分、結(jié)算工作；</p><p>　　清分：根據(jù)交易明細文件，按省、按渠道、按商戶、按業(yè)務等參數(shù)匯總交易；</p><p>　　生成其它平臺對賬文件：根據(jù)清分的結(jié)果對其他業(yè)務平臺如電信計費域系統(tǒng)、商戶等按

74、照約定的格式分別生成對賬文件，并發(fā)送到指定的目錄。</p><p>　　內(nèi)部結(jié)算準備，生成相應的結(jié)算文件：</p><p>　　對電信計費域系統(tǒng)結(jié)算，分別對各省的繳話費交易進行軋差處理，計算出各省級電信計費域系統(tǒng)的劃撥資金，并生成各省電信計費域系統(tǒng)的結(jié)算文件；</p><p>　　跨省交易，包括跨省交易的手續(xù)費，以及傭金進行再分配，并生成各省的結(jié)算文件等；</

75、p><p>　　生成銀行往來的結(jié)算文件（已發(fā)生），送交財務。</p><p>　　生成統(tǒng)一充值付費卡的結(jié)算文件（已發(fā)生），送交財務。</p><p><b>　　商戶結(jié)算準備：</b></p><p>　　對商戶結(jié)算包括消費交易，撤銷交易，退貨交易等進行軋差處理，計算出應該支付給商戶的金額，以及應該扣收的傭金，并生成各個商戶

76、的結(jié)算文件。根據(jù)和商戶約定資金劃撥時間，T+N天時往銀行發(fā)送資金劃撥指令，進行資金劃撥；并對資金劃撥成功后生成資金劃撥清單。</p><p><b>　　其他業(yè)務平臺</b></p><p>　　對賬處理：以賬戶管理系統(tǒng)的日切周期為準，其他相關系統(tǒng)，根據(jù)支付交易模塊提交的對賬文件進行對賬，如不平生成差錯文件，并進行差錯處理 。</p><p>

77、　　銀行資金劃撥：如果銀行系統(tǒng)收到支付處理模塊對商戶資金劃撥的指令，便對商戶進行資金劃撥；</p><p>　　內(nèi)部資金劃撥：內(nèi)部財務系統(tǒng)收到對省級計費域系統(tǒng)、省間結(jié)算文件，處理內(nèi)部資金劃撥。</p><p><b>　　沖正機制的要求</b></p><p><b>　　沖正適用范圍</b></p><

78、;p>　　系統(tǒng)沖正，是指由系統(tǒng)自動發(fā)起對原交易進行反向操作的過程。</p><p>　　系統(tǒng)沖正的使用情況如下：</p><p>　　1．支付系統(tǒng)中，對于非現(xiàn)金賬務類交易，在交易轉(zhuǎn)發(fā)的各個節(jié)點間都應設有超時控制機制。當檢測到有超時發(fā)生時，應拒絕該交易的繼續(xù)處理并自動發(fā)送沖正消息；</p><p>　　2．對于多方參與的賬務交易（如銀行卡轉(zhuǎn)賬充值），當一方交易成

79、功，而后續(xù)交易失敗時，應向交易成功的一方發(fā)起自動沖正交易，以保證賬務的一致性；</p><p>　　3．沖正交易僅在同一結(jié)算日內(nèi)有效，對隔日沖正（被沖正交易日期與當前業(yè)務日期不一致）應予以拒絕，沖正交易應不能出現(xiàn)在客戶的賬單上；</p><p>　　4．沖正交易本身不能被沖正。</p><p><b>　　沖正處理要求</b></p>

80、;<p>　　沖正交易的發(fā)出方收不到?jīng)_正應答時，應重新發(fā)送沖正交易，直到收到應答或者達到系統(tǒng)約定的最大沖正次數(shù)（根據(jù)雙方協(xié)議）為止；如果沖正交易最終不能成功，平臺按照不短款原則進行異常處理，POS終端不允許進行后續(xù)聯(lián)機交易，必須由人工進行處理。</p><p>　　對于多方交易，自動沖正交易應考慮資金風險，按照先借后貸的原則進行沖正；通常情況下，沖正采用與正交易相反的交易順序進行沖正。</p&

81、gt;<p><b>　　需要自動沖正的交易</b></p><p>　　對賬務類交易發(fā)生超時時需要自動沖正：如</p><p>　　在線支付賬戶銀行卡充值</p><p>　　在線支付賬戶充值卡充值</p><p>　　離線支付賬戶銀行卡充值</p><p>　　離線支付賬戶充值卡

82、充值</p><p><b>　　支付消費</b></p><p><b>　　轉(zhuǎn)賬</b></p><p><b>　　POS消費撤銷</b></p><p><b>　　網(wǎng)管要求</b></p><p><b>　　網(wǎng)

83、絡管理方式</b></p><p>　　融合支付平臺必須提供相應的網(wǎng)管功能，按照一級網(wǎng)管中心的標準建設，必須要納入到IP網(wǎng)絡管理之中，制定必要的管理制度。網(wǎng)管系統(tǒng)需要實現(xiàn)對網(wǎng)原級設備的管理，還需要實現(xiàn)應用級的網(wǎng)管。</p><p>　　融合支付平臺應支持網(wǎng)管接口要求。</p><p><b>　　網(wǎng)絡管理的主要功能</b></

84、p><p>　　對融合支付平臺的性能、故障、安全、配置進行管理，以保證整個系統(tǒng)的穩(wěn)定性、健壯性、高可用性、高效性、安全性，主要包括性能管理、故障管理、安全管理、配置管理等幾個方面。系統(tǒng)應提供網(wǎng)管功能模塊，對外提供網(wǎng)管接口。</p><p><b>　　性能管理</b></p><p>　　性能管理是向網(wǎng)絡運營者提供網(wǎng)絡設備的性能特征，以供網(wǎng)絡趨勢分

85、析、網(wǎng)絡擴建、網(wǎng)絡控制時參考。</p><p>　　監(jiān)視網(wǎng)絡性能，定期收集網(wǎng)絡中所有網(wǎng)源設備的性能參數(shù)統(tǒng)計數(shù)據(jù)，最好通過SNMP方式提供各自的MIB值；</p><p>　　監(jiān)視服務器的運行狀況，如響應速度、用戶連接并發(fā)度、用戶訪問分布等；</p><p>　　檢查其他相關服務的運行狀況，如數(shù)據(jù)庫的響應性能；</p><p>　　在性能分析的

86、基礎上，對制約網(wǎng)絡性能的相關參數(shù)如路由表和性能門限等參數(shù)進行調(diào)整，提高網(wǎng)絡性能。</p><p><b>　　故障管理</b></p><p>　　故障管理負責監(jiān)視網(wǎng)絡設備的故障告警，進行故障診斷及定位分析。平臺提供對各個網(wǎng)絡設備及網(wǎng)絡的狀態(tài)跟蹤，在某個網(wǎng)絡設備出現(xiàn)故障或異常時，能夠及時醒目的通知管理人，迅速的恢復故障。</p><p>　　實

87、時監(jiān)視網(wǎng)絡運行狀態(tài)和設備故障，以圖形和文本方式顯示網(wǎng)絡告警；</p><p>　　所有網(wǎng)絡設備都必須提供狀態(tài)通知功能，定期將各自的各項狀態(tài)指標通知相關的管理人員；</p><p>　　所有網(wǎng)絡設備都必須要有報警功能，設置必要的報警條件，另外報警手段也不能過于單一；</p><p>　　對產(chǎn)生的故障告警及事件信息進行記錄，以便用戶對歷史告警進行查詢。定期進行告警日志的

88、維護及刪除；</p><p>　　當一個物理設備發(fā)生故障時，可能產(chǎn)生多個失效告警，網(wǎng)管系統(tǒng)應能夠進行故障定位，確定與實際失效有關的告警。故障可定位到設備的端口級；</p><p>　　為便于故障定位分析或鏈路性能分析，各種服務器應接收網(wǎng)管系統(tǒng)發(fā)來的連通性測試要求，并返回測試結(jié)果。</p><p><b>　　安全管理</b></p>

89、<p>　　平臺通過必要的手段在各個層次上進行安全防范，使得用戶能放心使用，商戶能安心提供應用和服務，系統(tǒng)管理員能全面的對平臺進行控制。</p><p>　　網(wǎng)絡級安全，通過防火墻實施一定的安全策略；</p><p>　　系統(tǒng)級安全，關閉平臺不必要的服務，減少可能引起安全問題的原由；</p><p>　　應用級安全，必要的防病毒軟件；</p>

90、;<p>　　采取一定的認證和授權機制，對無權操作人員進行控制，規(guī)范管理人員的行為；</p><p>　　網(wǎng)絡鏈路傳送的信息加密/解密；</p><p>　　配置及修改各管理用戶的管理范圍；</p><p>　　為增加網(wǎng)絡的安全系數(shù)，對于關鍵的服務器應冗余備份；</p><p>　　需要有用戶級權限管理，管理整個平臺的用戶級別；

91、</p><p>　　需要能夠?qū)υL問平臺的客戶進行IP限制；</p><p>　　需要提供幾類不同的備份/恢復策略，如系統(tǒng)級、應用級和數(shù)據(jù)級；</p><p>　　需要詳細地記錄用戶的動作，用戶在和平臺信息交互的全過程都是被監(jiān)控的；</p><p><b>　　配置管理</b></p><p>　

92、　配置管理是指通過網(wǎng)管接口接入所能實現(xiàn)的網(wǎng)絡資源和配置管理功能。配置管理的功能主要包括：</p><p>　　提供網(wǎng)元級的配置管理，包括對服務器、數(shù)據(jù)庫服務器等網(wǎng)元設備進行配置。支持簡單的SNMP方式配置信息查詢；</p><p>　　創(chuàng)建并維護配置數(shù)據(jù)庫，其中包含網(wǎng)絡設備、軟件、操作級別、負責維護設備的人員等信息；</p><p>　　用戶可逐級進入而進行拓撲信息

93、查詢；</p><p>　　對網(wǎng)絡互連信息進行配置和查詢；</p><p>　　網(wǎng)絡業(yè)務配置，網(wǎng)絡節(jié)點各種數(shù)據(jù)的初始配置與修改，網(wǎng)絡各種業(yè)務政策的配置與管理；</p><p>　　當服務器的某些配置發(fā)生改變時應向網(wǎng)管系統(tǒng)報告。</p><p><b>　　系統(tǒng)性能要求</b></p><p>　　

94、本章的性能要求給出了性能指標的定義及一些必須的性能指標數(shù)值。隨著業(yè)務的發(fā)展，支付業(yè)務系統(tǒng)應能夠平滑升級和擴容，不影響業(yè)務的開展。</p><p>　　本文僅給出端到端系統(tǒng)的性能要求，單設備的詳細性能要求在相應的設備規(guī)范中定義。</p><p><b>　　賬戶數(shù)</b></p><p>　　賬戶數(shù)指標是指手機支付業(yè)務系統(tǒng)支持的已開立賬戶數(shù)量，包

95、括主賬戶和子賬戶。</p><p><b>　　日均交易量</b></p><p>　　該指標是指支付業(yè)務系統(tǒng)平均每日需處理的交易總數(shù)，包括交易額、交易次數(shù)、交易類型等。</p><p>　　端到端交易處理時延Tａ（遠程支付）</p><p>　　該指標是指在網(wǎng)絡及設備正常工作的情況下，用戶發(fā)起交易指令到交易完成的時延，

96、該指標不包括網(wǎng)絡連接（如PDP激活）建立時間及用戶操作時間（如輸入支付密碼）。</p><p>　　如上圖所示，端到端交易處理時延Tａ=T0+T1+T2+T3+T4+T5，其中：</p><p>　?。裕埃壕W(wǎng)絡傳輸時延。</p><p>　?。裕保壕W(wǎng)絡網(wǎng)元處理響應時間，如ＩＳＭＧ，ＳＭＣ等。</p><p>　　Ｔ２：網(wǎng)絡到融合支付平臺傳輸時

97、延。是毫秒級，可以忽略不計。</p><p>　?。裕常浩脚_內(nèi)部處理響應時間。</p><p>　?。裕矗褐Ц镀脚_到第三方系統(tǒng)的傳輸時延，如ＢＯＳＳ，銀行；是毫秒級，可以忽略不計。</p><p>　?。裕担旱谌较到y(tǒng)內(nèi)的處理響應時間。</p><p>　　對于基于SMS/STK方式： </p><p>　　平均單筆交

98、易響應時間不超過20秒；</p><p>　　單筆最大響應時間不超過120秒；</p><p>　　WAP方式\WEB方式\IVR\POS： </p><p>　　平均單筆交易響應時間不超過10秒；</p><p>　　單筆最大響應時間不超過120秒。</p><p>　　系統(tǒng)交易處理時延Ｔｂ（遠程支付）</p&

99、gt;<p>　　該指標是指在網(wǎng)絡及設備正常工作的情況下，單筆交易從手機支付業(yè)務系統(tǒng)接收到交易請求至返回響應需要的時間，該指標不包括網(wǎng)絡連接（如PDP激活）建立時間及用戶操作時間（如輸入支付密碼）。</p><p>　　如果涉及第三方系統(tǒng)，則Ｔｂ＝Ｔ３＋Ｔ４＋Ｔ５</p><p>　　平均單筆交易處理響應時間不超過6秒；</p><p>　　單筆最大處

100、理響應時間不超過60秒；</p><p>　　如果不涉及第三方系統(tǒng)，則Ｔｂ＝Ｔ３</p><p>　　平均單筆交易處理響應時間不超過4秒；</p><p>　　單筆最大處理響應時間不超過30秒；</p><p><b>　　系統(tǒng)吞吐量</b></p><p>　　該指標是指在單位時間內(nèi)融合支付平臺

101、成功處理的交易總數(shù)。</p><p><b>　　系統(tǒng)內(nèi)交易成功率</b></p><p>　　該指標是指在給定的交易處理時延內(nèi)處理成功的交易數(shù)占交易請求總量的百分比。</p><p>　　交易成功率不低于99.9%。</p><p><b>　　系統(tǒng)并發(fā)處理能力</b></p>&l

102、t;p>　　該指標是指在某個時刻，融合支付平臺支持的TCP連接數(shù)。</p><p>　　要求同時處理的TCP連接并發(fā)數(shù)不少于500個。</p><p><b>　　批處理時長</b></p><p>　　該指標是指融合支付平臺完成相關批量處理業(yè)務，如清分清算、報表、對賬、結(jié)算、備份所需要的最長時間。</p><p>

103、;　　系統(tǒng)批處理時長不長于３小時。</p><p><b>　　客服系統(tǒng)性能要求</b></p><p>　　系統(tǒng)可用性：≥99.999%；</p><p>　　MTBF（平均故障間隔時間）：≥5000小時；</p><p>　　MTTR（平均故障處理時間）：≤30分鐘；</p><p>　　停機

104、時間：≤3分鐘/年；</p><p><b>　　客服質(zhì)量要求：</b></p><p><b>　　7*24小時服務</b></p><p>　　客戶服務響應速度：在48小時內(nèi)解決客戶投訴并回復，直至客戶滿意；</p><p>　　30秒客戶服務電話接通率不低于95%，應答時限<=4秒；&l

105、t;/p><p>　　排隊等待時間<=20s；</p><p><b>　　其他</b></p><p>　　系統(tǒng)支持至少100個外部網(wǎng)元的同時連接；</p><p><b>　　7×24小時服務；</b></p><p>　　系統(tǒng)擴容：系統(tǒng)處理能力基本與硬件的擴

106、容成線形增長。</p><p><b>　　系統(tǒng)數(shù)據(jù)管理要求</b></p><p>　　對于系統(tǒng)內(nèi)保存的業(yè)務數(shù)據(jù)、安全數(shù)據(jù)、賬務數(shù)據(jù)，交易數(shù)據(jù)和日志數(shù)據(jù)記錄都應使用專門的管理工具進行數(shù)據(jù)加密、備份、歸檔、核對和恢復等管理維護，便于數(shù)據(jù)查詢、修改、更新與擴充，同時保證數(shù)據(jù)的獨立性、可靠性、安全性與完整性。</p><p><b>　　

107、業(yè)務數(shù)據(jù)管理</b></p><p><b>　　數(shù)據(jù)內(nèi)容</b></p><p>　　紙質(zhì)交易憑證：客戶協(xié)議、支付交易憑證等。</p><p>　　電子交易憑證：電子客戶協(xié)議、網(wǎng)絡交易記錄等。</p><p><b>　　保管介質(zhì)要求</b></p><p>　

108、　使用專用協(xié)議格式協(xié)議，由用戶填寫協(xié)議并簽字保存。</p><p>　　交易憑證必須統(tǒng)一規(guī)范要求，信息要求完整、準確。</p><p><b>　　保管期限要求建議</b></p><p>　　交易類憑證保管期限，建議為12個月；</p><p>　　協(xié)議類憑證保管6個月；</p><p>　　到

109、期的憑證應該安全處理或者備份。</p><p><b>　　安全數(shù)據(jù)管理</b></p><p><b>　　數(shù)據(jù)內(nèi)容</b></p><p>　　密鑰口令：主密鑰，分散密鑰，密鑰加密密鑰，應用工作密鑰、系統(tǒng)口令、管理員口令；</p><p>　　用戶信息：用戶信息、姓名、身份證號碼、手機號碼、住宅

110、號碼、家庭住址、賬戶號碼、交易信息；</p><p><b>　　保管介質(zhì)要求</b></p><p>　　主密鑰應該用IC卡保存，或者書面多人異地保存，保存在加密機中，整個流程必須以密文傳輸；</p><p>　　分散密鑰數(shù)據(jù)應該保存在專門的加密設備設備中，不可讀出明文；</p><p>　　系統(tǒng)操作員分級管理，并制定

111、相應的管理制度；</p><p>　　關鍵系統(tǒng)口令更新后應該建立紙質(zhì)備份，異地專人保管；</p><p>　　用戶敏感信息、賬戶信息不得泄露，經(jīng)過授權的人員可以查看。</p><p><b>　　管理期限要求建議</b></p><p>　　關鍵系統(tǒng)口令變更需要進行登記管理；</p><p>　　

112、主密鑰只有必要才進行更換；</p><p>　　系統(tǒng)用戶口令每倆個月修改一次，20次不得重復；</p><p>　　操作員口令6個月修改一次。</p><p><b>　　交易清算數(shù)據(jù)管理</b></p><p><b>　　數(shù)據(jù)內(nèi)容</b></p><p>　　各個平臺的交

113、易流水記錄；</p><p>　　各個平臺的管理類交易記錄；</p><p>　　參與清算的機構、商戶、銀行賬戶信息數(shù)據(jù)；</p><p>　　與銀行交易的記錄明細。</p><p><b>　　保管介質(zhì)要求</b></p><p>　　交易流水記錄保存在機器數(shù)據(jù)庫表中，硬盤保存；</p&g

114、t;<p>　　歷史數(shù)據(jù)保存在數(shù)據(jù)庫歷史流水表中，硬盤保存；</p><p>　　商戶、機構、終端數(shù)據(jù)保存在單獨的數(shù)據(jù)表內(nèi)，硬盤保存；</p><p>　　備份的數(shù)據(jù)保存在備份硬盤、磁帶、光盤中做冗余備份。</p><p><b>　　保管期限要求建議</b></p><p>　　交易數(shù)據(jù)聯(lián)機保存：0.5年

115、。</p><p>　　交易數(shù)據(jù)脫機保存：重要交易備份數(shù)據(jù)永久保管。</p><p><b>　　賬務數(shù)據(jù)管理</b></p><p><b>　　數(shù)據(jù)內(nèi)容</b></p><p><b>　　用戶賬戶數(shù)據(jù)；</b></p><p><b>　

116、　商戶賬務數(shù)據(jù)；</b></p><p><b>　　賬務操作記錄；</b></p><p>　　銀行相關賬務交易信息；</p><p>　　各機構間的賬務數(shù)據(jù)；</p><p>　　與BOSS系統(tǒng)相關賬務處理數(shù)據(jù)。</p><p><b>　　保管介質(zhì)要求</b>

117、;</p><p>　　系統(tǒng)硬盤保存?zhèn)浞輸?shù)據(jù)；</p><p>　　備份的賬務數(shù)據(jù)保存在備份硬盤、磁帶、光盤中做冗余備份；</p><p>　　每天對賬務數(shù)據(jù)進行備份處理。</p><p><b>　　保管期限要求建議</b></p><p>　　賬務數(shù)據(jù)保留10年；</p><

118、;p><b>　　關鍵數(shù)據(jù)永久保管。</b></p><p><b>　　日志數(shù)據(jù)管理</b></p><p><b>　　數(shù)據(jù)內(nèi)容</b></p><p><b>　　系統(tǒng)運行日志；</b></p><p><b>　　交易日志；<

119、/b></p><p><b>　　通訊日志；</b></p><p><b>　　異常日志。</b></p><p><b>　　保管介質(zhì)要求</b></p><p>　　系統(tǒng)硬盤保存?zhèn)浞萑罩緮?shù)據(jù)數(shù)據(jù)；</p><p>　　備份的日志數(shù)據(jù)保存在備

120、份硬盤、磁帶、光盤中做冗余備份。</p><p><b>　　保管期限要求建議</b></p><p>　　系統(tǒng)保存3個月的日志記錄信息。</p><p><b>　　系統(tǒng)安全要求</b></p><p><b>　　安全體系模型</b></p><p>

121、;　　為了便于對手融合支付系統(tǒng)的安全要求進行描述，將整個融合支付系統(tǒng)劃分為四個層次，即：應用層、系統(tǒng)層、網(wǎng)絡層和物理層（后面三層可統(tǒng)稱為基礎設施層）。</p><p><b>　　安全威脅</b></p><p>　　融合支付系統(tǒng)中的每個層次都面臨著不同的安全威脅，每種安全威脅都需要采取相應的安全措施進行防范。</p><p>　　融合支付系統(tǒng)

122、四個層次面臨的安全威脅如下表所示：</p><p><b>　　安全模型</b></p><p>　　為了應對以上各類安全威脅，本系統(tǒng)采用如下安全體系模型：</p><p>　　該模型要求每個層次都需要提供相應的安全功能，包括密碼體系、訪問控制、存儲安全、通信安全、可用性、安全審計、防攻擊/防病毒等，說明如下：</p><p

123、>　　密碼體系：系統(tǒng)的加解密、完整性保證措施及相關的密鑰管理機制</p><p>　　訪問控制：對移動手機支付業(yè)務中的各種應用、系統(tǒng)、網(wǎng)絡進行訪問控制</p><p>　　數(shù)據(jù)存儲安全：包括密鑰存儲、數(shù)據(jù)存儲安全（加密）以及數(shù)據(jù)完整性等內(nèi)容</p><p>　　通信安全：通信過程中的安全，包括加密、不可否認性、完整性等</p><p>

124、　　可用性：各種保證應用、系統(tǒng)、網(wǎng)絡的可用性的措施</p><p>　　安全審計：包括應用層、系統(tǒng)層、網(wǎng)絡層的安全審計功能</p><p>　　防攻擊/防病毒：對各類攻擊和病毒的防范措施</p><p><b>　　應用層安全要求</b></p><p><b>　　密碼體系</b></p&g

125、t;<p>　　融合支付系統(tǒng)涉及多類業(yè)務、用戶、網(wǎng)元的交互，為了保證所有這些交互過程中的信息的機密性、完整性和不可否認性等，需要設計一套完整的密碼體系，該體系至少應該考慮如下要求：</p><p>　　密碼體制：需要根據(jù)業(yè)務需求選擇對稱、非對稱密碼體制，選擇加解密/完整性算法，密鑰長度等。對于對稱密碼體制，需要為不同的業(yè)務、不同的目的提供不同的密鑰。</p><p>　　密鑰

126、管理：為了保證密鑰的安全性，需要充分保證密鑰的生成、傳輸、更新和銷毀整個密鑰生命周期過程的安全性。同時，密鑰管理系統(tǒng)為管理部門提供操作上的權責管理、管理上的人員相互制約的機制。確保系統(tǒng)的安全性。</p><p><b>　　訪問控制</b></p><p>　　對于應用業(yè)務流程，必然涉及多個不同的對象之間的相互訪問。為確保訪問的安全性、正確性和有效性，需要采用如下訪問

127、控制措施：</p><p>　　角色管理與權限劃分：對訪問業(yè)務/應用的所有角色進行劃分和管理，并按照角色分配相應的權限。其原則是每個角色只能訪問其業(yè)務相關的信息，而無關信息則禁止訪問。</p><p>　　身份認證：根據(jù)應用和業(yè)務的安全級別分別采用相應級別的身份認證方式，如高級別的用戶（系統(tǒng)管理員用戶）則可以采用基于雙因素的身份認證方式，如USB Key+口令的方式。</p>

128、<p><b>　　數(shù)據(jù)存儲安全</b></p><p>　　在融合支付系統(tǒng)中，所有應用級數(shù)據(jù)存儲都需要保證其安全性。數(shù)據(jù)存儲安全性主要包括：</p><p>　　機密性：關鍵敏感數(shù)據(jù)需要采用加密存儲</p><p>　　完整性：所有應用級數(shù)據(jù)存儲，對于需要保證數(shù)據(jù)完整性的數(shù)據(jù)需要采取進行完整性措施，防止非法的篡改</p>