银行卡数据制作管理

银行卡数据制作管理（共8篇）

篇1：银行卡数据制作管理

一、实验目的1． 掌握sql server的基本用法

2． 熟悉掌握asp语言的应用

3． 掌握asp的页面结构和内置对象

4． 掌握asp与sql server数据库的连接和应用

5． 掌握asp 另外一个重要的语言——javascript,并熟悉它的应用

6．制作一个功能完善的考务管理系统

7．能够独立的完成系统策划，系统分析和程序的编写

8.提高发现问题，解决问题的能力

二、实验内容

制作一个考务管理系统，用于从考生报名、产生准考证到录取考生和打印成绩单即对考生考试和录取全过程的考务管理，系统要实现的功能有：考生报名，按报名顺序产生报名号；产生准考证号和打印准考证；输入考生成绩和输入录取合格标准；根据合格标准录取上线考生；打印考生成绩单和录取通知书；设置系统用户和系统初始化。

三、实验环境

1、windows xp或 windows XX；

2、安装 microsoft sql server XX 个人版。

3、iis 5.0及以上版本和浏览器ie5.5及以上版本

4、macromedia dreamwezver8等相关软件

四、实验步骤

首先：配置环境，安装sql server，macromedia dreamwezver8。

第二：对要做的系统进行构思、策划、布局。

第三：建立数据库kaoshi及数据表：学生信息表（student），用户表(yonghu)，考生表(biaozhun)。

第四：建立连接数据库的文件conn.asp,其代码如下所示：

<%

set conn=server.createobject(“adodb.connection”)

conn.open “provider=sqloledb;” & “data source=localhost;initial catalog=ksd;user id=sa;password=100200;”

%>

第五：制作各个网页并联接所有需要联接的网页。

第六：运行整个系统，查找是否有错误，并进行修改直至整个系统运行无误。

五、实验过程与分析

（一）系统分析与总体设计

现在用计算机来进行考生的管理及考生的录取已普遍存在。因如果用人来进行这项工作将十分烦琐，系统管理员需要划分很多的时间和精力，而且还不能保证其正确率。

而用考务管理系统可以简化管理员的工作，还会提高工作的正确率。以下将对考务管理系统进行系统分析和设计。

（1）系统的功能描述

考务管理系统包括学生报名管理、考生成绩管理系统维护三大模块。

考生报名管理 包括报名处理、产生准考证、打印准考证和退出系统等4项功能。

考生成绩管理 包括考生成绩录入、合格标准录入、录取考生、打印成绩单和打印录取通知单等5项功能。

系统维护 包括用户设置和系统初始化等2项功能。

用户通过系统菜单执行相应的操作。

（2）数据库设计

本系统以sql server XX作为数据库平台。在sql server XX中设计一个数据库kaoshi，其中包含如下数据表。

1.student表

该表用于存放所有考生记录，包括基本数据.表的结构如图2所示。

2biaozhun表

该表用于存放录取考生的合格标准，其中只有一个记录，该记录指出各门课程的最低分和总分的最低分。只有各门成绩和总分都超过这个标准的考生才能被录取。该表的结构如图3所示。

3.yonghu表

该表用于存放本系统用户的信息。包括用户的用户名、密码和级别（只分“一般操作员”和“系统管理员”两类）。该表结构如图4所示。

六、实验结果与总结

实验中的考务管理系统是经过很多次的测试、修改再测试、再修改才完成的。也就是在多次的测试修改的过程中使我学发现了很多平时上课发现不了的问题，也发现了自己学习这门课程的薄弱的地方和学的不足的地方。通过实验期间的发现问题、分析问题、查找问题原因、解决问题及进一步完善考务管理系统的过程，我的能力和水平有一定程度的提高。经过一次独立完成系统给我以后编程打下了基础，让我面对的不再是茫然和无措，而是有条不紊的思绪和完成的信心。所以这次实验对我来说是一笔极大的财富。

当然，在实验中我也有很多不足的地方，系统也有需要进一步完善的地方，这主要是我对asp与sql server数据库的连接和应用不熟悉和经验不足的原因造成的。所以我还要在以后继续学习，以求做的更好。

篇2：银行卡数据制作管理

第一章

总

则

第一条 为规范数据管理工作，提高我行数据质量，确保数据准确性、完整性、及时性，特制定本暂行办法。

第二条 相关概念

应用系统，是按照信息一体化的要求，用于处理我行经营管理的应用软件系统，主要包括客户交易类系统、业务管理类系统、管理信息类系统、技术保障类系统等。

数据是指**银行实施信息化管理过程中产生的所有电子数据。数据质量是指数据的及时性、完整性以及准确性。第三条 数据质量管理应遵循以下原则：

（一）统一规范原则。各类应用系统采集和处理的数据，应符合各自应用系统所要求的数据标准。

（二）全程监控原则。建立数据从采集、审核、处理到维护的全过程监控体系，重点把好数据的采集录入关，确保各类应用系统数据真实、准确、完整。

（三）层级考核原则。总、分行对各自直接下属单位的数据质量管理工作进行严格的目标管理考核，奖优罚劣。

第二章

部门分工及职责

第四条 总行合规部是全行数据质量管理的牵头部门，主要负责：

（一）、制定全行的数据质量管理的相关规章制度

（二）、对各应用系统管理部门的履职情况进行考核、监督

（三）、根据需要，参与对全行各应用系统数据质量管理的检查监督

（四）、对违反数据质量管理规定，造成数据错误、失真、延误、漏填等违规行为进行问责

（五）、向高管层报告我行数据质量管理执行情况

第五条 总行各部门是应用系统的管理部门，负责管理各自的应用系统，是本应用系统数据质量的主责任人，主要负责：

（一）、贯彻落实总行制定的数据质量管理的相关规章制度；

（二）、制定本应用系统录入、维护、审核的基本标准和规范性要求，并适时开展检查监督，保障数据管理符合规范性要求；

（三）、制定本单位的数据质量监控指标体系，定期对本级数据质量评估分析，及时解决数据质量管理中出现的问题；

（四）、指导、监督系统使用部门或相关岗位的数据质量管理工作，督查对错误数据进行更正和清理的情况；

（五）、制定本应用系统数据质量的考核标准和评分体系，按时对应用系统使用部门的数据质量进行考核；

（六）、提交本应用系统数据质量管理报告；

（七）、负责本职责范围内的数据采集、录入和审核工作。

第六条 应用系统使用部门主要指数据的采集和录入单位，是应用系统数据采集、录入质量的责任人，主要负责：

（一）、加强对采集、录入人员的业务培训和管理，提高数据录入的准确率；

（二）、严格执行数据管理规章制度，确保数据采集、录入真实、准确和及时；

（三）、按照规定，对数据采集录入工作进行质量考核；

（四）、对采集录入人员的工作情况进行监督检查；

（五）、向应用系统管理部门报告数据质量管理执行情况；

（六）、负责本职责范围内的数据采集、录入和审核工作。

第七条 应用系统采集录入人员是应用系统数据质量的直接责任人，主要负责

（一）、按照原始记录，准确将数据录入系统；

（二）、按照信息系统的要求，将涉及的相关内容全部录入系统，不得缺省；

（三）、在规定期限内，根据各自的权限，及时将数据录入系统；

（四）、按照上级机关的规范要求录入各类数据。

第八条 科技信息部负责应用系统的安全、维护责任，参与对各应用系统数据考核工作。

第二章

数据采集、录入与审核

第九条 数据采集是通过应用软件进行数据录入、使用各种工具软件进行数据导入的数据收集、整理、传输的行为

第十条 数据采集应遵循真实、完整、规范、及时的原则。

（一）真实：应严格依据经营管理原始资料所记载的内容准确录入相关数据，如实反映，不得随意修改、增减。

（二）完整：要按照各类应用系统的有关要求进行数据采集，保证数据齐全，避免数据的缺失。

（三）规范：数据采集应按照应用软件系统的相关标准进行。

（四）及时：数据要在规定的时间内采集，确保应用系统数据及时反映经营管理实际。

第十一条 数据采集程序

（一）接收：操作人员根据各应用系统的要求，及时对相关原始资料进行审核整理。

（二）录入：原始资料审核无误后，应在规定的时间内录入或导入应用系统；对审核有误的，必须修正后再录入或导入。

第十二条 数据采集的责任部门

（一）通过业务软件进行数据录入的数据采集行为，其责任部门是业务软件各子系统的使用部门。

（二）对于使用工具软件进行数据导入的数据采集行为，其责任部门是工具软件的使用部门。

第十三条 数据采集必须严格按相应的业务规范以及软件使用要求进行，不得违反业务规范以及软件使用要求对数据进行采集。

第十四条 数据采集必须依据不同业务办理的要求在规定时间内完成，不得无故拖延或推迟数据采集时间，确保数据采集的及时性。

数据采集必须按有关业务规范要求以及软件使用要求规定的格式进行录入，不得缺省，确保数据的完整性。

采集的数据必须与原始材料一致，确保数据的准确性。

第十五条 在各类应用软件系统中，要严格按照规定进行岗位设臵和授权，严格按照岗位和权限操作。严禁在未按规定授权的情况下委托他人以本人的账户和口令进行有关的数据录入和修改。各系统用户应当定期更改自己的口令，确保系统数据的安全。

第三章

数据维护

第十六条 数据维护是按照应用系统的有关规定对错误的数据进行数据修改的行为。

第十七条 数据维护由各应用系统管理部门按照各自应用系统的有要求，明确数据维护的权限和职责，制定数据维护的程序。凡是采集进入应用系统的数据，不得擅自修改、删除。

第十八条 数据维护前应做好相应数据和系统的备份工作。能够通过系统模块解决的，经过审批后按照各类应用系统的操作规范进行维护；需要通过技术手段解决的，由 责任人提出书面申请，由相关业务部门和技术部门审核确认，经主管行领导审批同意后，方可进行数据维护。

第十九条 数据维护工作应严格备案，科技信息部对各应用系统管理部门报送的每项数据维护的时间、内容、维护原因、责任人等记录进行备案，涉及的书面材料必须登记存档。

第二十条 数据维护人员在进行数据维护时，必须认真负责，避免在数据维护过程中产生新的错误数据。

第四章、数据检查

第二十一条 数据检查是按照有关应用系统数据管理规定对数据及时性、完整性以及准确性进行的数据质量检查的行为。

第二十二条 数据检查采取应用系统使用部门自查和应用系统管理部门检查的方式。数据检查的方法有：

（一）通过统计、查询等系统进行检查；

（二）在业务软件使用过程中对数据库中已有数据进行检查；

（三）用数据质量检查工具进行检查；

（四）抽取原始档案材料与数据库中数据进行对比；

（五）其它数据检查的方法。第二十三条 检查的内容：

1、纸质资料与信息系统内资料进行检查核对，数据采集录入是否全面、及时、规范。

2、数据的处理是否及时、正确、全面。

3、数据的传输是否规范、及时。

第二十四条 应用系统使用部门在业务软件使用过程中发现错误数据，必须及时告知相应的数据采集的责任人或部门进行维护。

第二十五条 应用系统管理部门应定期通过使用统计、查询等系统进行数据检查，仔细分析检查结果，识别其中不符合规律和常理的数据，查找存在的数据问题。

第五章

数据质量考核

第二十六条 各应用系统管理部门应建立本系统的数据质量的考核体系。第二十七条 考核指标至少包括比率指标和数量指标。比率指标按未达标的百分点扣分，数量指标按错误数据的数量和问题的严重程度扣分。

第二十八条 考核的比率指标是：

1、信息采集率。已经采集进入应用系统的信息与应该采集进入应用系统信息的比率。

2、信息采集准确率。录入应用系统的正确信息与录入的所有信息的比率。

3、信息传输及时率。规定时期内传输的信息与检查期限内所有传输信息的比率。

4、信息处理率。考核期内处理的符合规定的信息与考核期内处理的所有信息的比率。

第二十九条 数量指标是指分级列出问题数据的数量，根据问题的严重程度，确定扣分标准，进行扣分。根据数据的重要程度具体分为四级：

1、只影响数据本身的完整性而不影响其他数据。

2、只影响本工作环节质量。

3、不仅影响本工作环节质量，而且影响后面工作环节数据处理质量。

4、数据质量错误造后面工作无法处理或无法工作。

第三十条 各应用系统主管部门应根据本办法制定各应用系统的数据质量考核细则，并报总行合规部备案。

第六章、责任追究

第三十一条 凡违反本办法相关规定，造成数据录入不及时、不完整、不准确等数据质量问题的，对数据质量责任部门和相关责任人实行数据质量责任追究。

第三十二条 数据质量追究的原则

（一）“以谁的用户名录入，谁负责”；

（二）实事求是、有错必纠、责罚相当、教育与处罚相结合。第三十三条 数据质量责任追究范围

（一）因数据质量问题导致统计数据不能生成或生成错误的；

（二）因数据质量问题导致其他部门工作不能正常开展的；

（三）因数据质量问题影响经营决策行为的及时性、正确性的；

（四）因数据质量问题损害客户合法权益的；

（五）因数据质量问题造成财产、声誉损失的；

（六）其他应当追究的数据质量责任。第三十四条 数据质量责任划分

（一）数据采集的责任部门即为数据质量的责任部门；

（二）从数据库后台记录中确认的数据录入人员是数据质量的直接责任人；

（三）将自己的用户名、密码提供给他人使用，或因保管不善导致他人盗用、冒用用户名、密码的，用户名所有者是数据质量责任人。

第三十五条 数据质量责任按照《**银行员工违规行为处理办法》的规定进行追究。第三十六条 对主动发现错误并及时纠正，尚未造成不良影响的，可以从轻或者免于追究责任。

第三十七条 有下列情形之一的，应当从重追究责任：

（一）因玩忽职守、徇私枉法、受贿、索贿等原因造成过错的；

（二）二次以上发生同一或类似过错的；

（三）其他应从重追究责任的情形。

第六章

附则

第三十八条 本办法由**银行总行负责解释。第三十九条 本办法自印发之日起执行。

篇3：VF数据库管理系统制作

由于总体人员比较少, 有正式员工50人, 人员结构比较简单, 基本上学历在大专以上, 部门划分也很清晰, 而且人员流动性也不高, 所以对工资管理要求也不高。根据以上情况最终确定了工资系统设计方案。

1.1 系统基本功能

基本的工资核算系统需要包含三张数据表, 即员工表、基本工资表和奖金表, 三张数据表分别存放员工的个人基本信息 (如员工号、姓名、性别、年龄和所在部门等) 、员工的基本工资信息 (员工号、姓名、性别、所在部门、所在岗位、工龄和工资等) 和员工的奖金情况, 员工的奖金是按照当月业绩来核算的。

工资核算系统除了维护员工的基本个人信息、基本工资和奖金数据外, 有的时候还要利用相关数据核算员工的公积金、保险和实发工资等项目。

1.2 系统操作流程

先为系统设计一个系统登录界面, 让用户输入正确的用户名和密码后, 才能进入系统工作界面, 显示系统菜单。一般如密码输入三次错误, 则自动退出该系统。

系统菜单包含:主菜单项、子菜单项。主菜单项应包括 (系统管理、信息浏览、数据维护、工资核算等) 、子菜单应包括 (SQL操作、退出系统、员工信息、信息查询、基本工资、奖金、工资核算、工资打印、更新、输出等) 。

启动系统界面后, 进入系统主界面, 操作人员选择“登录”按钮, 输入正确的用户名和密码, 即可进入系统工作界面。进系统进入界面后, 出现工资核算系统菜单。各个菜单命令对应启动相应的功能模块, 执行对应的表单或命令。

1.3 系统功能模块

(1) 系统管理。显示欢迎界面, 供用户登录系统、用户密码验证。

(2) 信息浏览。浏览员工 (包括基本信息、基本工资和奖金等) 全部信息。

(3) 数据维护。员工信息、基本工资、奖金等变动。对其增加、删除、修改等信息。

(4) 工资核算。计算并显示员工工资、预览和打印工资。

1.4 系统使用的数据库和数据表

“工资核算”数据库-------组织各数据表。

员工表-------存放员工的基本信息。

基本工资表-------存放员工的基本工资数据。

奖金表-------存放员工奖金数据。

用户表-------存放工资核算系统中的操作员信息和密码。

工资核算表-------临时存放工资单上的数据信息。

2 系统工作路径设置

系统默认目录是VF系统进行数据库操作时, 表、索引、程序等各种文件的存储位置。文件操作时如不指明路径, 系统从该默认目录下查找、存取指定文件。系统以安装目录:C:Program FilesMicrosoft Visual StudioVfp98为默认目录。所以这里设置为D:gzglvfpfrom。

3 结论

单击“登录”按钮, 在“系统登录”窗口中选择用户名并输入正确的密码后, 即可打开系统菜单界面。通过相应的菜单命令, 用户可以正常地维护数据、查询信息以及生成工资报表。

摘要：了解VF的人都知道, VF具有界面友好, 工具丰富, 速度较快等优点。在数据操作、查询、汇总及管理方面也具有较强的功能。那么今天我们就借助于VF这些优异的特点, 完成一个简单的小系统。

篇4：富滇银行实现数据管理一体化

信息化

与业务发展俱进

近年来，富滇银行借助先进的信息技术管理平台和手段，实现银行信息化管理，为商业银行的业务拓展和战略发展保驾护航。富滇银行信息技术部总经理杨平生介绍说：“富滇银行加大对IT基础设施的建设以及系统架构改造的投入，采购了大批服务器和存储设备，同时，在管理软件方面也下足了功夫。”

面对金融行业日益严格的数据保护监管要求以及银行自身业务迅速发展的需求，全面、可靠、高效地对各个应用系统进行数据保护管理已经成为富滇银行一个亟待解决的问题。

富滇银行副总经理赵武刚表示：“一直以来，富滇银行都非常重视数据中心基础设施的合理规划和建设，经过多年的不懈努力，系统资源得到了有效的整合优化。”据了解，富滇银行现有两个数据中心：生产中心和异地灾备中心。目前，数据中心部署了上百台计算存储服务器，运行着包括业务、渠道、管理和办公等方面70多个应用系统，所采用的操作系统有AS400、AIX、Linux和Windows，数据库包括DB2、Oracle和SQLServer，硬件环境包括IBM、EMC和Dell的设备。生产中心的局域网被划分成生产、办公、测试和开发等不同功能区，并进行安全隔离，其中重要系统已普遍实现本地高可用或异地的在线数据保护。在数据的离线保护方面，绝大部分系统都采用了内置磁带机或本地硬盘，其余部分系统数据通过FTP进行异机转储，所有的数据备份操作依赖手工或脚本方式完成。异地灾备中心目前设在富滇银行在某县的支行中，对生产中心进行数据备份，其核心业务系统可以做到应用级的切换，数据基本可以做到零丢失。

一体化管理

实现数据万无一失

数据已经成为各家银行最重要的资产之一，只有做到对数据万无一失地安全保护和自动化管理，才能保证银行业务系统的正常运营。杨平生认为，在这个过程中，一体化的数据保护管理解决方案尤为重要。

在富滇银行，原有的数据保护方式，不但要求系统维护人员具备高标准的技术能力和管理经验，还会增加额外的工作压力和误操作概率。另外，部门主管无法及时全面地掌握真实的数据保护状况，长期运行下来，系统中积累了很多疏漏和风险。银行的日常业务运营面临着数据丢失，甚至可能无法恢复的挑战。

对于数据的保护，富滇银行信息技术部潘瑞深有感触。“富滇银行之前在数据保护上存在着几个问题：数据备份不能覆盖整个生产区域；缺乏专用的备份设备和备份介质，以及全面有效的备份、归档和恢复策略；以在线备份和本地存储为主，缺少离线备份和异地转储；缺乏影像文件、日志文件的归档管理；过度依赖人工管理，存在较高的操作风险；数据状态和操作历史的审计记录不完善。”

因此，富滇银行迫切需要一个统一的数据保护管理平台，以期能够在现有的网络环境和系统架构下，制定全面有效的备份归档策略、自动实现数据按时定期的存储保护、共享存储资源、降低投资成本和运营风险，进而改善系统运维人员管理效率。

潘瑞说，通过多次的方案选型、产品测试和厂商对比，最终，CommVault的一体化数据管理解决方案打动了他们。随后，富滇银行与CommVault双方的技术人员针对银行系统环境及数据管理要求进行分析和论证，制定了完整周全的数据管理策略，针对不同网络域环境、多数据库平台、高可用系统和虚拟化架构采用了最优化的配置方案，并通过采用Simpana 9软件实现对富滇银行所有业务系统的生产数据进行自动化的备份和归档，多路径冗余自动切换，统一操作界面、统一管理策略，还能提供数据管理统计分析和资源使用预测的报告。

现在，一体化数据保护管理平台部署完成后，富滇银行仅需要一名系统管理员就能够实现全面系统的数据日常集中保护管理，系统管理员、应用管理员以及部门领导都能通过图形化的报告随时了解全面、真实的数据保护现状。

潘瑞介绍说，首先，在实际的系统运行中，已全部实现数据库的在线备份，满足了不同期限的数据保存需求，并能实现任意时间点的数据恢复，丢失数据的时间段从过去的一天甚至几天减少到几分钟；其次，利用一体化管理平台，对海量文件数据实施了“备份+归档”的一体化管理，对历史数据实现了分级存储管理；第三，全图形化的数据保护管理界面不再需要管理人员编写复杂的命令运行脚本或程序等，既降低了IT管理人员的操作复杂度，也极大地提升了工作效率。

目前，富滇银行通过采用一体化数据管理解决方案，全行业务系统的生产数据保护覆盖面从过去的不足50%提升到了95%以上，数据保护的可靠性从不足70%提升到98%以上。另外，Simpana 9跨防火墙统一管理技术还避免了在多网络功能区域内备份系统的重复建设问题，节约了50%以上的投资和运维成本。

背景资料

富滇银行

富滇银行最早始于1911年蔡锷创办的云南全省公钱局，1912年改组为省立富滇银行，除经营一般商业银行业务外，还具有发行货币的特殊职能，并代表云南省政府执行地方金融政策、统制外汇，实质上起到了地方央行的作用，在云南的发展史上起过重要作用。

2007年底，富滇银行股份有限公司正式成立，是经中国银监会批准成立的云南省省级地方性股份制商业银行。截至2012年6月底，富滇银行本外币资产总额893.34亿元，实现净利润5.77亿元。目前，富滇银行已在云南省绝大部分地州市和重庆直辖市成立了分支机构，并设立了4家村镇银行和3家金融服务中心，还在老挝成立了境外代表处。

篇5：XX银行数据标准管理办法

第一章 总则

第一条 为规范我行数据标准管理工作，明确管理职责，推动数据标准在业务领域和技术领域的应用，提高我行整体业务运行和管理效率，提升IT实施能力，特制定本办法。

第二条 本办法适用于我行及分支机构所有与数据标准有关的管理活动，包括数据标准的制定、评审、发布、执行、变更及复审等工作。

第三条 本办法所称数据标准，是指针对我行各种重要数据制定的规范性文件，以确保这些重要数据在全行内外共同使用和交换中的一致性和准确性，是实施数据治理、提升数据质量的重要基础。

第四条 本办法所称重要数据，是指我行跨业务部门或跨系统多处使用的数据。

第五条 数据标准按照数据加工程度划分为基础类数据标准和分析类数据标准两大类型，本办法主要针对基础类数据标准。

第六条 本办法所称基础类数据，是指日常业务开展过程中所产生的具有共同业务特征的基础性数据，可进一步划分为不同的数据主题，包括客户、产品、协议、交易、资产、财务、地址、组织、渠道、营销十个数据主题。

第七条 数据标准内容可以划分为业务和技术两部分：

第1页

（一）业务规范是指从业务层面对数据的统一定义，包括数据项的业务涵义和数据项处理加工的业务规则等；

（二）技术规范是指从技术实现层面对数据的统一规范和定义，包括字段长度、数据格式等。

第八条 XX银行数据标准制定遵循以下原则：

（一）以业务为导向。基于我行实际业务情况制定数据标准，并根据业务需求分阶段推进制定工作。

（二）全面性及完整性。数据标准立足于我行整体业务架构，覆盖未来所有经营范围内的相关业务。

（三）前瞻性及科学性。既满足现阶段业务需求，更应结合国内外先进经验，考虑未来我行业务类型逐步发展所带来的数据标准需求。

（四）遵循外部标准。充分遵循各类成熟的外部标准，并按照国家标准/国际标准、金融行业标准、监管报送要求的顺序进行采纳。

第九条 我行数据标准信息项及代码的选择遵循以下准入原则：

（一）已有的内外部成文规范纳入数据标准，包括：行业、国家或国际组织正式发布的数据标准；监管部门管理指引、监管统计规范等已经明确提出要求的相关数据规范；行内已经发文进行明确的相关数据规范。

（二）未有外部成文规范，但我行当前已经在广泛使用

第2页 的，尤其是跨业务条线和系统使用的信息项和代码纳入数据标准。

（三）针对未在现有信息系统中出现，但依据我行信息规划或者同业相关经验，在未来信息系统中会多处使用的数据和代码纳入数据标准。

第二章 组织与职责

第十条 数据标准管理组织分为数据管理协调层和数据管理执行层。

第十一条 数据管理协调层是数据管理各领域工作的直接领导与组织部门，设立数据管理领导小组及秘书。数据管理领导小组的人员组成参见《XX银行数据管理办法》。数据管理领导小组直接领导与组织数据管理各领域工作，负责组织各领域业务专家及总分支机构数据管理相关部门开展工作，协调并推进数据管理相关工作并监督落实。其涉及数据标准管理的具体职责包括：

（一）监督并评审数据管理执行组开展数据标准的制定、评审、执行、变更、复审等工作；

（二）发布新版本数据标准。

第十二条 数据管理执行层设立数据管理执行组，负责全行数据管理工作的具体执行。数据管理执行组的人员组成参见《XX银行数据管理办法》。数据管理执行组中的数据标准管理岗（暂由数据质量管理岗兼任）总体协调与管理数据标准工作，负责组

第3页

织、推动数据标准相关工作的开展，具体职责包括：

（一）负责制定数据标准工作计划及工作方案；

（二）负责制定和维护数据标准定义模板；

（三）负责收集数据标准的新增及变更需求并协调相关部门参与数据标准制定、变更、评审；

（四）牵头制定数据的业务标准并审核技术标准；

（五）负责组织开展数据标准评审、执行及复审工作；

（六）负责维护数据标准；

（七）审核IT项目组在系统建设中的数据标准落地范围与落地方案等；

（八）监督各部门对数据标准的执行情况；

（九）定期向数据管理领导小组汇报重大事项。第十三条 信息项归口管理部门是数据标准的业务标准的权威认定部门，负责本部门管理的信息项业务标准和标准代码的解释和指导。

第十四条 总行各部门是数据标准需求提出方与执行者，负责提出数据标准制定及变更的需求。其涉及数据标准管理的具体职责包括：

（一）参与数据标准的制定；

（二）参与数据标准的变更与评审工作；

（三）负责落实并执行相关数据标准；

（四）向数据标准的系统落地方案提供建议。

第4页

第十五条 分支机构是数据标准的需求提出方与执行者。其涉及数据标准管理的具体职责包括：

（一）根据日常运营统计及监管报送的需要通过总行分管条线业务部门向数据管理执行组提出数据标准需求；

（二）在数据获取阶段按数据标准的管理要求开展工作。第十六条 IT项目组是数据标准落地的主要执行者，也是需求的提出方。其涉及数据标准管理的具体职责包括：

（一）制定数据标准在本项目的系统落地范围与落地方案；

（二）参照数据标准进行相关数据字典和数据模型设计；

（三）在系统设计与开发过程中按照数据标准落地方案实施；

（四）根据需要，在IT系统建设或改造的需求分析、设计过程中，提出数据标准的新增或变更需求。

第三章 数据标准的制定

第十七条 数据标准制定，是指按照数据标准需求，定义各类数据的业务标准（包括信息项分类、信息项中文名称、信息项英文名称、业务定义等）、技术标准（包括标准类型、长度、精度等）、以及标准代码（包括代码编号、代码取值、代码含义、代码规则、代码说明等）。

第十八条 总行各部门均可根据业务运行管理及监管要求的需要，提出数据标准制定的需求，填写《数据标准需求申请

第5页

表》（附件一），经所在部门主管负责人批准后提交数据管理执行组。各分支机构如提出数据标准的制定需求，经总行分管条线业务部门初审后，由总行分管条线业务部门提交至数据管理执行组。IT项目组在全行改造或新建IT系统的需求分析、系统设计过程中，可以根据需要提出数据标准的新增需求，填写《数据标准需求申请表》（附件一）并提交至数据管理执行组。

第十九条 数据管理执行组负责汇总并分析全行数据标准新增需求，编制数据标准制定工作方案与模板，组织相关部门制定业务/技术标准，并明确主题。

第二十条 数据管理执行组组织相关业务部门制定相关信息项/代码的业务标准，明确该信息项所属主题；组织开发中心，制定相关信息项/代码的技术标准。

第二十一条 数据管理执行组对制定的业务/技术标准进行初审，并汇总各部门意见后形成数据标准审议稿，用于数据标准评审。

第四章 数据标准的评审与发布

第二十二条 数据标准评审，是指在数据标准管理过程中开展的审议审批工作。

第二十三条 数据标准发布，是指按不同主题，向全行发布最新的数据标准版本的工作。

第二十四条 数据标准评审工作依据数据标准制定原则进行，评审参考标准如下：

第6页

（一）数据标准是否满足业务需求，分类标准、信息项和代码等内容必须满足各标准相关方的迫切需求；

（二）数据标准是否具有业务前瞻性，分类标准、信息项的设置和代码的编排等内容必须考虑未来我行业务发展可能产生的标准需求；

（三）数据标准是否明确无歧义，标准信息项和代码的定义必须反映我行实际业务情况，在我行范围内有一致的理解；

（四）数据标准是否具有权威性，标准的定义必须充分参考各类成熟的外部标准，将遵循的外部标准出处、内容进行明确的标注和解释。

（五）数据标准是否具有可落地性，数据标准在定义时必须考虑技术层面的实现难度，在各相关系统可以落地。

第二十五条 数据管理执行组根据总行业务部门或IT项目组提出的相关数据标准需求，组织相关业务部门召开数据标准评审会议，评审数据标准的制定成果，协调解决数据标准制定过程中出现的问题，并形成会议纪要。数据管理执行组应将数据标准评审会议的会议纪要提交相关与会部门确认。

第二十六条 具体评审方式可酌情多样化，如对新增需求内容较少或未能采取会议评审形式的数据标准，也可采取会签形式进行评审。

第二十七条 对于新增主题的数据标准，须提请数据管理领导小组审批。对于已发布主题数据标准的新增内容，数据管理

第7页

执行组可根据业务影响范围、重要性等因素酌情提请数据管理领导小组审批。

第二十八条 数据管理执行组组织参与评审部门填写《数据标准发布审批表》（附件二），形成最终的审议审批意见。

第二十九条 数据标准评审通过后，数据管理领导小组在全行范围内发布。

第五章 数据标准的执行

第三十条 数据标准执行，是指已发布的数据标准在具体业务操作及IT系统中的实施和运用，以及对落地实施的监督。

第三十一条 全行各单位是数据标准的使用者和执行者，应依照业务发展和管理需要，配合数据管理执行组开展数据标准的落地实施工作。

第三十二条 总行各业务部门及各分支机构在业务需求编写、业务信息采集表和统计分析报表的设计中要遵照数据标准的要求。

第三十三条 各分支机构在进行数据采集、维护、应用、归档等操作时，应遵循数据标准的要求。

第三十四条 各IT项目组在进行新建或改造IT系统时，均应遵循已发布的数据标准制定落地方案，经数据管理执行组、信息项归口管理部门及相关业务部门审核后依此开展系统的设计与实施工作。

（一）对于合作开发和委托开发的IT系统，其数据模型

第8页

开放程度及我行数据标准的采纳程度应纳入招标采购评价标准中，作为招标采购的评标依据。

（二）对于IT系统（包括自主开发类、合作开发类、委托开发类）的建设，IT项目组应按照落地方案建立该IT系统数据项与已发布数据标准（包括已有代码）之间的映射关系，按此映射关系进行详细需求分析与数据模型设计并开发。

（三）如数据标准落地实施涉及系统改造及历史数据处理等工作，数据管理执行组、系统业务牵头部门及相关信息项的归口管理部门需共同商议系统改造和数据标准落地的具体工作方案，并制定历史数据处理方案。

（四）数据管理执行组组织评审项目设计阶段数据标准的执行情况。对于不满足数据标准落地方案要求的，数据管理执行组有权要求IT项目组进行整改，直到评审通过后方可进入项目开发阶段。

（五）对于自主开发类系统，IT项目组按照落地方案及已发布的数据标准开展实施，进行规范编码；对于外购成熟系统，IT项目组应分析系统和外围系统交互的数据，在系统接口上进行标准落地，保证与此系统交互的数据遵循数据标准。

（六）在系统验收阶段，数据管理执行组按照数据标准进行严格检测，出具数据标准符合性审核报告并报数据管理领导小组审批，经数据管理领导小组批准同意后方可验收投产。

第六章 数据标准的变更

第9页

第三十五条 数据标准变更，是指由于业务运行与发展需要，或外部监管要求，或引用的国家标准等外部标准的变化，对已发布的数据标准进行变更的工作。

第三十六条 数据标准变更的范围包括数据标准分类的修改，数据标准信息项业务定义与技术定义的修改，标准代码的修改，以及数据标准的废止。

第三十七条 数据标准的变更既要反映数据标准业务含义和业务规则的变化，又要保持数据标准的相对稳定，减少由于数据标准的频繁变动对业务应用和IT系统建设造成的影响。

第三十八条 总行各部门及各分支机构均可提出数据标准变更需求。总行各部门填写《数据标准需求申请表》（附件一）后由本部门负责人审批后提交数据管理执行组。各分支机构如提出数据标准的制定需求，需由总行分管条线业务部门初审后，由总行分管条线业务部门提交至数据管理执行组。

第三十九条 数据管理执行组、总行信息项归口管理部门及总行相关部门共同对变更事项进行确认。

第四十条 数据标准变更事项经总行各业务部门确认同意后，数据管理执行组组织参与评审部门填写《数据标准发布审批表》（附件二），形成最终的审议审批意见。由数据管理领导小组发布变更。

第七章 数据标准的复审

第四十一条 数据标准复审，根据业务发展及IT系统建设情

第10页

况，对数据标准适用性进行复审的工作。原则上复审周期为一年。

第四十二条 针对已发布的数据标准在系统与业务管理中的执行情况，数据管理执行组应每年组织开展标准复审工作，通过征求总行相关部门意见，了解数据标准的适用性，对不适用的数据标准及时进行废止或修订。

第四十三条 对于复审结果为废止的数据标准，数据管理领导小组应在全行发布数据标准废止通知。

第四十四条 对于复审结果为修订的数据标准，应根据修订的范围开展后续工作。如果数据标准修订范围较小，参照本办法第六章规定完成变更工作；如果数据标准修订范围较大，参照本办法第三、四章规定完成重新制定、评审与发布工作。

第八章 监督管理

第四十五条 数据管理领导小组负责对数据标准管理进行监督和检查。总行相关部门对制度建设和执行情况，定期或不定期开展自查和检查。

第九章 依据文件

第四十六条 《银行监管统计数据质量管理良好标准》

第十章 附则

第四十七条 如果数据标准管理工作中出现争议或分歧，由数据管理执行组协调解决。对无法解决的重大争议或分歧，由数据管理执行组报数据管理领导小组决策。

第11页

第四十八条 本办法由信息科技管理委员会批准，信息科技部负责制定、修订和解释。

第四十九条 本办法自20XX年XX月XX日起执行。

附件：

附件一：数据标准需求申请表 附件二：数据标准发布审批表

附件三：数据标准制定、评审与发布流程 附件四：数据标准执行流程 附件五：数据标准变更流程 附件六：数据标准复审流程

篇6：银行卡数据制作管理

摘要：随着利率市场化改革的完成及互联网金融的快速发展，商业银行正面临着传统业务空间收缩等诸多挑战。引入大数据思维，则有助于商业银行加快转型升级，打造核心竞争优势。本文从引入大数据思维的意义入手，探究将大数据思维应用于商业银行经营管理工作的基本策略。

关键词：大数据思维;商业银行;信息整合;产品管理

随着外部经济环境的改变，商业银行在传统信贷业务中的存贷利差优势日趋缩小，拓展业务格局、完善业务体系、创新业务模式已成为银行打造核心竞争能力的重要要素。而大数据、云计算、智能整合等对接互联网技术优势的发展路径，则是银行谋求变革、创新发展、拓展利润空间、提升经营管理水平的重要抓手。

一、引入大数据思维的意义

(一)拓展客户渠道

引入大数据思维，可对存量客户进行深度分析、整合，更有助于获取新客户。通过对客户的结构化、半结构化、非结构化信息进行集中分析，可使银行更理解客户的真实需求，进而优化服务体验与营销内容，构筑起交互式双向互动链条，获取更多有效客户。

(二)细化经营管理模式

随着金融脱媒趋势加速，互联网与科技对银行业的影响日趋深入，客户面临的产品选择日趋丰富，客户对产品消费与资金管理的需求日趋多元，传统的`以存贷利差为利润核心的粗放式经营管理模式已难以适应当下的激烈竞争。将大数据思维贯穿于覆盖资产端、负债端的全面链条，可助力银行将资产规模化管理转变为资产效率化、增值化、精细化、品牌化管理，剥离低效率资产，强化产品输出，打造核心实力。

(三)提升风险管理水平

在现代银行经营管理工作中，客户存量丰富，且客户的信息变化速度很快，其核心业务、财务指标、关联企业、资产质量、未来现金流预期等要素的变迁均存在较强的时效性特征。应用大数据思维，则可以整合历史情况、平衡当前数据、挖掘未来信息，进而构筑起纵横联动的立体化、多维度风险管理体系，有效管控风险源头，提高风险管理水平。

二、应用大数据思维的基本策略

(一)打造集成式产品线

立足银行在产品设计、资金管理、风险防控等方面的优势，打造集成式产品线，可为客户提供开放、多元、立体的产品与服务，有效整合“信息流”与“资金流”。比如，工商银行推出的“电子供应链”产品、中信银行研发的“上下融通”产品、平安银行的供应链金融2.0系统等，就是通过整合企业在供应链中的交易信息，动态管理其现金流量，以上下游企业的核心商品为授信着力点，打造贯穿整条供应链的集成式授信产品，实现了价值共享。此外，还可以对接大数据思维，打造“商圈类”集成式授信产品。即在存量客户中挖掘出某个商业集合体中的核心企业，以其自身所有的产品资源与资金流为主导，对接其周边企业，围绕此客户生态圈，整合海量数据，并利用数据分析结果高效筛选新客户，科学防控风险，打造出轻资产产品线。通过构筑此类集成式产品线，为客户提供产品增值、资产管理、融资保理、综合授信、信息咨询等综合服务，以开放的产品体系有效降低沟通与营销成本，提高授信效率，简化产品审批环节，加快客户资金回流速度，形成集成优势，节约管理资源。

(二)全面整合客户信息

科学地获取、分析客户，打造交互式沟通模式，进而使客户对银行整体品牌产生认同感、建立忠诚度，才能使产品营销、品牌价值输出、内控与风险管理等其他环节成为有本之木、有源之水。而大数据具有数量大、数据类型多样、时效性强、价值密度低、真实性难保证这五个显著特征，在应用大数据思维整合客户信息、描摹客户蓝图时，要格外注意对数据进行科学收集、筛选、加工、分析、分享，保证数据整合的系统性、专业性、精准性、有效性、时效性、实践性。一方面，要积极拓展合作渠道，对接人民银行及第三方征信机构、税务与工商等行政管理部门掌握的企业信息，结合银行内部获取的企业现金流量沿革、大额资金流向、销售与成本数据变迁、主营业务及管理人员变化等信息，动态整合数据，实时调整服务模式和产品战略。另一方面，还可以进一步深挖用户习惯，以情景惯性、用户属性、使用习惯与偏好等多个考量要素分解客户需求，使产品设计、营销、管理、反馈等环节更加精准、到位，进而提高资源利用效率，将“以人为本”的服务理念融入差异化、个性化、多样化服务中，提高客户粘性，打造品牌效应。

(三)构筑智能驱动体系

将大数据思维应用于银行经营管理的多个环节，使智能分析、数据整合成为银行发展的内在驱动力，可更好地发挥信息化优势。一方面，要纵向联动产品设计、客户营销、风险管控、定价管理等多个内部经营环节，将量化分析思维贯穿于多个环节，做到数据采集、加工、分析、反馈一体化，实现交互管理。另一方面，要横向联动多个职能部门，强化沟通机制，不断对产品模式和客户评级进行动态调整，构筑实时化、智能化业务驱动体系。

三、结束语

在科技高速发展的信息时代，信息技术为银行业的发展带来了新机遇，也带来了新挑战。引入大数据管理思维，深挖数据价值、实现数据增值，对提升当前商业银行的综合竞争实力具有重要的实践性意义。打造集成式产品线、整合客户信息、构筑智能驱动体系等策略的应用，可助力商业银行实现精细化管理，提高经营管理水平，为银行的持续发展注入源源不断的生命力。

参考文献：

[1]王萍.大数据时代商业银行转型发展[J].商场现代化,，(30):139-140.

[2]许佳馨,刘晓星,崇章.大数据对商业银行的影响分析[J].调查研究,2016，(05):51-52.

[3]蔚赵春,凌鸿.商业银行大数据应用的理论、实践与影响[J].上海金融,，(09):28-32.

篇7：银行卡数据制作管理

（试行DOC版）

本标准适用范围为根据《银行业监管统计管理暂行办法》(2004年第6号主席令)开展监管统计工作的全部银行业金融机构（下文简称“银行”）。标准的总体框架包含5方面要素，分别为：组织机构及人员，制度建设，系统保障和数据标准，数据质量的监控、检查与评价，数据的报送、应用和存储。5方面要素下共有15项原则，每项原则下有若干具体标准，共61条标准。

（一）组织机构及人员 原则1 组织领导

银行董事会和高级管理层高度重视并积极推动本行数据质量管理和监管统计工作，明确政策和目标，建立机制和流程，落实各环节责任。

具体标准：

1.1银行董事会制定明确的政策，将本行数据质量管理纳入内控合规体系和战略规划之中，并定期对其有效性和执行情况进行评估。

1.2银行高级管理层确立数据质量管理的目标，建立机制和流程，明确职权和责任，定期对本行数据质量管理水平进行评估，并有效落实数据质量问责制。

1.3银行法定代表人或主要负责人对本行监管统计数据的真实性负责，亲自或委派领导班子成员（以下简称“主管领导”）组织领导监管统计工作，对制度性变革等重大监管统计事项能够及时研究部署，在资源调配方面予以充分支持和保障。

原则2 归口管理

银行对监管统计工作实行统一管理、分级负责的管理体制，确定归口管理部门组织管理本机构的监管统计工作。

具体标准：

2.1银行总行确定监管统计归口管理部门，授权其负责全行监管统计领导、组织、协调和管理工作。

2.2总行归口管理部门根据授权负责制定全行监管统计工作制度和流程，提出监管统计数据质量管理措施，协调和督促其他相关业务部门，共同做好监管统计工作，定期检查并发现监管统计数据质量存在的问题，提出合理化建议，向主管领导报告。

2.3银行各级分支机构确定相应的归口管理部门，负责本级机构监管统计工作，在总行归口管理部门统一领导下，有效履行监管统计相关职责。

原则3 岗位设置

银行在监管统计归口管理部门和其他相关业务部门设立相应的监管统计岗位，岗位职责明确，并配备能满足岗位履职所需的资源。

具体标准：

3.1银行在监管统计归口管理部门设立与本行业务规模和复 杂程度相适应的、满足监管统计工作需要的监管统计专职岗位。

3.2银行在其他监管统计相关业务部门设立与其部门业务规模和复杂程度相适应的、满足监管统计工作需要的监管统计专职或兼职岗位。

3.3 银行对监管统计岗位的设置涵盖监管统计所有的工作任务和内容，分工明确，职责清晰，各岗位均设立A、B角。

3.4银行对监管统计岗位的财务预算满足各岗位履职所需，包括设备、差旅、培训等支出。

3.5银行监管统计岗位薪酬水平能够吸引和留住合格的工作人员，岗位设置能体现职业成长发展的良好通道。

原则4 团队建设

银行建设一支满足监管统计工作需要的专业队伍，并建立有利于提高监管统计人员工作积极性和促进其职业成长发展的激励约束机制。

具体标准：

4.1银行应根据监管统计岗位职责要求，配备一定数量的满足监管统计工作需要的监管统计人员。

4.2监管统计人员应具有良好的职业操守、专业知识和操作技能，熟悉银行业务，具备必要的协调沟通能力。

4.3银行对监管统计人员定期进行科学、系统的培训，培训的内容、方式和频度能满足监管统计工作的需要。

4.4银行建立对监管统计人员合理有效的激励约束机制，创 3 造有利于提高监管统计人员工作积极性和促进其职业成长发展的良好环境。

（二）制度建设 原则5 管理制度

银行建立全面、科学和有效的监管统计管理制度，保证监管统计工作的规范性和严肃性。

具体标准：

5.1监管统计归口管理部门牵头其他相关业务部门建立符合银行监管要求的统计管理制度。统计管理制度的内容包括但不限于组织管理、部门职责、协调机制、安全保密、系统保障、监督检查、数据质量控制以及监管统计数据源管理等方面，并以文件的形式下发执行。

5.2监管统计归口管理部门根据监管要求和管理实际，持续评价和及时更新统计管理制度。

5.3监管统计归口管理部门将本行的统计管理制度报银行业监督管理机构（以下简称监管机构）备案，管理制度若有重大调整或变化，及时向监管机构报告。

原则6 业务制度

银行建立适应本行业务实际的监管统计业务制度，做好监管统计数据源和统计项目的归属管理。

具体标准：

6.1监管统计归口管理部门组织其他相关业务部门制定符合本行实际的统计业务制度。统计业务制度覆盖所有的监管统计报 表和数据要求，并正式发布。

6.2统计业务制度对监管统计的内容、方法和口径等方面做出统一规定，保证监管统计报表和数据中每一个统计项目的归属关系及取数路径清晰、准确。

6.3监管统计归口管理部门根据监管要求和管理实际，组织其他相关业务部门持续评价和及时更新统计业务制度。

6.4监管统计归口管理部门将本行的统计业务制度报监管机构备案，业务制度若有重大调整或变化，及时向监管机构报告。

（三）系统保障和数据标准 原则7 基础系统

银行业务及管理基础系统实现对监管统计涉及的各项基础业务和管理信息的全面覆盖，数据维护管理制度和流程完备，具有较强的数据质量控制功能，保证系统信息全面、及时、准确反映业务实际。

具体标准：

7.1业务及管理基础系统的设计、建设和升级改造征询并充分考虑监管统计业务需求，系统功能支持监管统计信息自动采集。

7.2业务及管理基础系统涵盖监管统计涉及的全行各业务领域及各类相关机构。如由于新的监管要求变化而暂时无法实现全覆盖，要有明确的系统完善时间安排。

7.3业务及管理基础系统有完备的数据维护管理制度和流程，尤其是要有对质疑信息明确核查和纠正的相关规定。7.4业务及管理基础系统信息及时录入，经过复核，并动态更新，保证全面、及时、准确地反映业务实际。对监管统计人员及系统管理人员反馈的存在完整性、准确性等缺陷的质疑信息，及时予以核查并纠正。

7.5业务及管理基础系统具有良好的可拓展性，满足新业务、新产品和监管新要求的需要，并为监管统计管理系统预留能够灵活加载的数据接口。

原则8 监管统计系统

银行建立适应监管统计工作需要的、完善的监管统计系统，实现流程控制的程序化，能够自动提取和加载所需数据，有良好的质量控制与错误信息提示功能，保障数据安全和规范操作，并具有可拓展性和灵活性。

具体标准：

8.1银行将监管统计系统建设纳入本行信息系统建设整体规划，系统框架设计符合监管统计业务及管理要求，并配备充足的信息科技支持资源。

8.2银行监管统计系统实现流程控制的程序化，综合处理监管统计业务，能够自动提取相关系统所涵盖的全部监管要求数据，能够加载标准化的外部数据。

8.3监管统计系统具有良好的质量控制功能，能自动实现总分、表内、表间检验和预警提示的需要，能灵活设定参与检验的机构、指标的逻辑关系，自动提示异常变动及错误情况。

8.4银行采取适当的安全防范措施，建立应急处置机制，保 证监管统计系统安全稳定运行，保证数据安全。

8.5监管统计系统附有完备的系统取数规则及系统操作说明，为统计人员提供操作规范。

8.6监管统计系统具备较强的可拓展性和灵活性，能根据监管要求，灵活、方便地增加新的监管指标或报表数据采集，具有灵活定制分析报表、合理管理各类口径数据等统计应用分析功能。

原则9 数据标准

银行数据标准化规划统筹考虑监管统计数据标准化，全面覆盖监管统计数据及指标。数据标准符合国家标准化政策及监管统计规定，在监管统计相关的业务领域及系统中规范执行。

具体标准：

9.1银行充分考虑监管统计要求，将监管统计所涉及的数据标准纳入本行信息标准化规划。

9.2监管统计相关的银行数据标准符合国家标准化政策及监管统计规定。数据标准明确，文档规范。

9.3银行与监管统计相关的业务领域及系统遵循统一的业务规范和技术标准，建立全行统一的监管统计数据架构，客户、产品、机构、账户等基础信息跨系统保持名称、定义、口径、来源等方面的一致性。各系统建立统一的数据交换标准，实现系统间信息共享。

（四）数据质量的监控、检查与评价 原则10 日常监控

银行建立有效的数据质量监控体系，对监管统计数据质量实施持续监测，采取有力措施，落实各环节责任，确保数据质量。

具体标准：

10.1银行建立有效的覆盖监管统计数据生产报送全流程的数据质量监控机制。

10.2监管统计相关业务部门对本部门监管统计的数据源信息质量适时监控，对监管统计归口管理部门提出的数据源质量问题及时整改，保证数据源信息的准确性和完整性。

10.3监管统计归口管理部门对监管统计数据实施有效的跟踪监控，强化总体复核，发现数据质量问题，反馈到相关责任部门并督促其及时纠正。

10.4监管统计归口管理部门建立与报表频度相适应的数据质量监测台账，对监管统计数据质量问题实时记录，定期分析。

10.5监管统计归口管理部门定期通报相关业务部门和分支机构提供的监管统计数据质量情况，总结交流经验，并提请实施问责。

原则11 监督检查

银行将数据质量检查纳入内控合规检查范围，建立监管统计现场检查制度，定期组织实施。

具体标准：

11.1银行将数据质量纳入内控合规检查范围，内控合规管理部门在制定检查计划时充分考虑监管统计归口管理部门 的意见和建议。

11.2银行建立监管统计现场检查制度。归口管理部门定期牵头组织行内监管统计现场检查，检查内容包括监管统计法规制度的执行及其数据质量等情况。

11.3归口管理部门将统计现场检查报告报主管领导，对影响数据质量的重大问题，提交内控合规部门跟踪检查，并报监管机构。

11.4银行督促被查单位根据统计现场检查发现的问题以及归口管理部门的要求实施整改，及时对整改情况跟踪评价，确保整改落实到位。

11.5监管统计相关业务部门定期对监管统计的数据源信息质量进行检查，及时组织整改，并将检查整改结果抄送监管统计归口管理部门。

11.6银行对监督检查发现的重大问题，依据有关规定对相关部门及责任人予以问责和处理。

原则12 考核评价

银行建立有效的考核评价体系和奖惩机制，保障全系统监管统计工作的有效落实。

具体标准：

12.1监管统计归口管理部门定期对相关业务部门和分支机构提供数据的质量情况进行考核和评价，考评结果在行内公布。

12.2监管统计相关业务部门按照业务范围对监管统计数据源管理工作进行考核评价，落实相应的激励约束措施。12.3银行将监管统计数据质量的考核结果纳入本机构绩效考核体系。

（五）数据的报送、应用和存储 原则13 数据报送

银行加强向监管机构报送数据环节的管理，积极落实各项报送要求，认真审核，减少迟报、漏报和差错。

具体标准：

13.1银行建立数据报送流程管理制度和报送联系人制度，保障与监管机构联系畅通。

13.2银行与监管机构建立网络连接，实现监管统计报表和数据的快速、安全传输，按监管统计制度规定的频度和时间要求及时报送数据信息，并建立监管统计报送应急预案。

13.3数据报送符合监管统计制度要求，不存在漏报的数据信息，保证填报地区、机构范围和统计数据的完整性。

13.4数据报送的文件格式正确，系统能正常读取数据，符合逻辑校验关系要求。对数据异常变化的质询能做出合理解释；对历史数据进行修改，说明缘由，并报送监管机构备案。

原则14 分析应用

银行在保密安全的前提下充分共享和使用监管统计信息，为本机构经营决策和风险管理服务，同时通过扩大共享、加强分析、适时披露，促进数据质量提升。

具体标准：

14.1监管统计归口管理部门对监管统计信息合理分类，对 相关业务部门设定合理的用户权限，充分实现机构内的统计信息共享，扩大应用范围。

14.2监管统计归口管理部门牵头建立全面、科学的监管统计信息分析框架，做好监管统计信息的监测、分析和风险预警工作。

14.3相关业务部门有效分析使用监管统计信息，为本行合规审慎经营提供决策参考，并以此推动数据质量不断提高。

14.4银行应关注报送监管机构的监管统计信息与对外披露的相关信息间的差异，并将其中重大差异主动向监管机构做出说明。

原则15 资料存储

银行按照规定加强对监管统计资料的存储管理，保证监管统计数据信息的安全性和连续性。

具体标准：

15.1银行对监管统计资料统一管理，根据保密规定和档案管理要求，建立全面、严密的管理流程和归档制度。

15.2当内部职能变更、人员变动时，做好监管统计资料交接存档工作。

篇8：银行业风险管理数据平台建设探索

一、银行业风险管理数据平台的现状

目前我国银行之间风险管理数据平台的建设水平差距很大。一部分信息化程度较低的银行没有完成业务和总账数据大集中，风险管理数据的来源主要是各分支机构的报表，经总行汇总后进行风险分析、评估、控制、处理;一部分信息化建设比较领先的银行在数据大集中的基础上已经建立了企业级的数据仓库，各种风险管理的应用正在展开;其他大多数银行已经完成数据大集中，正在考虑建设新一代全面风险管理信息系统，但仍然缺乏统一的风险管理数据平台。对于这部分正在进行风险管理数据平台的银行来说，以下几个方面的问题值得关注。

（一）风险数据平台缺乏整体规划

1. 风险管理数据平台未和银行总体风险管理规划实现统一

风险管理信息数据平台只有能够为风险管理提供量化识别、分析的支持才能产生价值，才是有生命力的。不少银行，特别是一些中小银行的业务总体规划比较模糊，风险偏好不明确，难以产生正确的风险管理要求。这导致风险管理数据平台的规划往往只有IT部门独立完成，甚至交付给外部咨询公司或者供应商，高管层和风险管理人员只进行审批而实务参与度低。这些问题必将影响风险管理信息系统的实用价值。

2. 风险管理数据平台未和IT整体规划统一

很多银行缺乏IT治理和规划，IT作为一个支持手段，被动服务于业务部门，没有持续和统一的规划。实践中可以发现，银行高管层对于IT的理解，很大程度上制约IT治理和规划，而这也是国内银行的一个软肋。已经建立了IT治理和规划制度的银行，对于数据平台这样的基础性设施也缺乏足够的重视。调研结果显示，很多中小银行投入了大量的资金，针对信用、操作等各种风险购买了各种专门管理软件，但是由于运营数据获取和管理的难题，不得不又一次面临升级换代。

3. 风险管理数据平台落后于全面风险管理的要求

在后金融危机时代，银行业对全面风险管理的要求，已经不仅仅局限于对单个风险类别的度量识别。巴塞尔委员会和其他机构的研究表明，各种风险之间存在非常高的相关性，在一定条件下甚至会发生转化。目前国内许多银行的风险管理信息系统依赖于购买现有产品，需要治理哪一种风险就购买什么，系统之间的数据没有互访性，形成了新的“信息孤岛”。没有统一数据平台的支持，风险管理得出的结论往往是不全面的，甚至是错误的。

（二）风险数据平台信息化程度有待提高

1. 原始数据对风险管理支持程度较低

衡量银行风险管理系统的信息化程度，需要看其对于应用和决策的自动化及智能化程度。风险管理信息系统对风险的管理能力，取决于风险数据的数量和质量。对于已经完成核心业务信息化的银行来说，业务系统中已经包含了几乎所有的营运数据，数量上完全可以满足风险管理的需要。但是这些数据往往只是为了完成业务而存储在内，其对风险管理应用的支持价值值得怀疑。很多银行反映，业务数据质量不高，缺乏客户信息等一些关键性信息，数据格式没有统一，风险管理信息系统能够利用的数据有限，部分数据仍然要依靠人工干预甚至事后补全。“有数据，无信息”是风险管理数据平台建设的普遍难题，制约着风险管理系统的信息化水平。

2. 风险数据平台集成化程度低，数据源分散

对于很多银行特别是一些经营时间较长的大行，由于历史的原因，IT架构难以统一，业务系统老中青多代并存。业务数据存在于各种结构、接口完全不同的数据库和文件系统中。对于任何一个想要从两个以上数据源中获取风险管理数据的系统来说，这种数据源的异构性是一道难以逾越的障碍。对于想要在风险数据平台建设上有所突破的银行来说，如何提高数据的集中度，为访问各种异构的数据源提供统一的接口，是一个非常紧迫和重要的任务。

（三）风险数据平台缺乏合适的建设途径

数据仓库是异构数据集成的有效方法。数据仓库与传统数据库的区别在于，数据库中的数据仅仅是用作存储的，面向处理本身，而数据仓库中的数据是面向特定主题(往往是管理)而组织的。数据仓库并不单纯是一种IT产品或技术，而是一系列组织数据的方法。从某种意义上，数据仓库可以理解为“数据库的数据库”，其关键技术是如何从异构的业务数据库中抽取数据(Extract)、转换(Transform)为统一的、便于特定目的利用(Load)的高度信息化数据。

数据仓库的风险管理数据平台虽然十分适合银行这样的数据密集型企业，但是在具体建设实施上却有很大的难度，主要表现在以下几个方面。

1. 数据仓库的建设成本高昂

数据仓库是一项远比传统数据库建设复杂的工程，其建设费用往往达到数千万元以上，这个数字超过了很多中小银行的整体IT预算。而在系统层面上，数据仓库仅仅只是风险管理信息平台的基础设施之一，要展开具体应用还需要更多的投入。风险管理的基本原则是风险控制产生的效益必须要高于风险控制的投入，从这个意义上来说，很多规模较小的银行没有数据仓库实施的基本前提。除了一些远景意识较为强烈、发展较快的银行以外，绝大多数银行还不能把数据仓库建设纳入到IT规划日程中。

2. 数据仓库缺乏合适的技术和方案

数据仓库是一种新兴的技术，本身也是许多高新技术的集合。除了工行、建行等少数大行具有自主开发实施的能力以外，绝大多数的银行需要依赖外部供应商的产品。国内软件和系统厂商由于软件行业本身的原因，缺乏实施的经验和技术力量，解决方案不够成熟;而国外的大型厂商，其方案没有经过很好的本地化，难以适应特定银行，特别是一些特色比较明显的中小银行的应用。因此数据仓库的外包建设缺少成功的例子，具有比较高的技术风险，这也是大多数中小银行至今仍在观望的重要原因。

二、对策和建议

（一）科学规划风险数据平台

完善合理的规划，是风险数据平台成功建设的前提。风险数据平台的规划，必须从银行全面风险管理的要求出发，落实三个方面的内容。

1. 要建立起切合实际需要的风险管理IT规划

把风险管理IT规划落到实处，首先，要把风险管理信息系统的建设与风险管理的要求有机的统一起来。全面风险管理的理念告诉我们，银行业的风险是银行业务成本的一部分。对风险的管理取决于该风险对银行运行的影响程度和银行的风险偏好，只有从成本效益角度出发，正确识别和度量风险，才能采取合适的措施，包括控制、转移等，形成对风险管理信息系统的具体要求。其次，风险管理IT规划必须服从于风险管理的大局，反映风险管理的实际需要。从国际上银行治理的经验来看，现代银行的IT战略规划已经不可避免地成为银行整体战略规划的一部分，而不仅仅是一个实现分支。风险管理IT规划要建立相应的制度，在初次完成规划的基础上，根据银行风险管理的变化，不断更新规划内容，保持与风险管理的紧密联系。

2. 要把风险管理信息系统作为一个有机的整体进行规划

风险管理信息系统的统一规划，需要在纵横两个方向上进行。纵向上，需要把风险数据平台和风险管理应用平台的规划结合起来。风险数据平台的元数据(metadata)，是风险管理应用的关键。只有正确识别管理应用的需求，特别是风险管理人员的应用特点，合理制定元数据结构，才能在风险管理信息系统建设初期掌握先机，避免因数据信息量过少影响风险管理应用效果。横向上，应当十分重视各种不同风险管理子系统数据之间的联系，如零售风险计量系统和欺诈交易识别系统，在IT规划上采用适当的技术如相似的架构和技术规范，为数据间的互操作提供条件，提高数据平台的可重用性。

3. 要将风险数据平台规划与IT总体规划统一起来

风险管理信息系统是银行管理信息系统的一部分，风险数据平台应当从全行数据平台的层次进行考虑和规划，才能达到最大的效用。如建立全面的客户数据平台，对零售信用风险管理和客户关系管理都具有高度的价值。风险管理数据平台的规划要从多个维度量化分析投入和效益，才能完整发掘风险管理数据平台的价值，得到管理层的理解和重视。

（二）加强源数据质量管理

要以全面风险管理为内在要求，控制数据采集的质量。银行IT规划者必须认识到，数据平台和数据质量是相辅相成的，只有建立了完整的数据平台，冗余数据(如客户办理多项业务时每次需要填写的基本信息)才能避免，数据采集的工作才能最小化，质量才会提高;另一方面，数据质量是数据平台建设的基础，很难想象一个数据质量低下、错误丛生的平台会对业务和管理有价值。

影响数据质量的问题主要有两类，一是数据缺失或者无意义的默认值，二是数据错误。解决数据缺失需要制定合理的数据结构，结构上体现完成业务的基本需要的同时也要考虑风险管理的信息要求，既要全面又要避免冗余和无用信息。在录入系统上增加强制性要求，把控制信息完整性作为流程的一部分来处理，建立相应的考核标准，提高一线业务人员理解信息系统的水平和规范录入积极性。解决数据错误的问题，应当以预防为主、事后更正为辅的策略。在录入控制上增强验证逻辑的严密性，如利率不可能为负数等，对关键性的数据要采取双重输入或者双重验证。银行IT规划者应当识别哪些数据容易出现质量问题，如客户信息、抵押品信息等，做到有的放矢。

（三）采取合理的平台建设手段

银行的数据源种类繁多，可以是业务数据、财务人力数据、外部数据等，但这些数据源所采用的平台、技术和结构不尽相同，如何集成这些数据是数据平台建设不可回避的问题。而数据仓库虽然是针对异构数据库的集成方案，但对于银行来说，由于受到财力、技术等多方面的因素制约，并不一定是最合适的。特别是对于中小银行来说，需要探索其他建设途径。

1. 先建立独立数据集市，再过渡到全行级别数据仓库

数据集市也是面向应用主题的数据组织形式。与面向各类管理应用的数据仓库相区别，数据集市的应用面更加专门和狭窄，比如专门为风险管理部门订做的风险数据集市。数据集市规模小，能快速实现和回收投资，工具更加完善和便于使用，甚至可以由业务部门定义、设计、开发、管理和维护，在一定条件下可以升级到完整的数据仓库。需要注意的是，多个独立的数据集市的累积，是不能自然形成一个全行级别的数据仓库，这是由数据仓库和数据集市本身的特点决定的。要减少日后数据集市升级到数据仓库的问题，必须在建立数据集市时要在元数据设计阶段把关，确保各个数据集市之间元数据结构不互相冲突。

2. 先建立同构的数据源，再建设数据仓库